Re: VPN NAT and routing issue

naive.naive · ‎12-17-2012

Diagram and configs as attached..order of the devices..

1800 --- 2800 --- 3750

The tunnel is up and I can access to 10.66.0.0/16 from 172.55.0.0 but not from 10.55.0.0

No idea what went wrong.. hope to get some ideas from experts here..

Another this i noticed, if i ping from 10.55.0.0, it will not build the tunnel..(which means 10.55.0.0 is not considered as interesting traffic)

BTW, nothing other than the VPN config can be amended, as im just helping to setup the tunnel..

Mitchell Dyer · ‎12-17-2012

Without sorting through the VRFs and convoluted routing:

I'm assuming you are trying to get 10.55.0.0/16 and 172.55.0.0/16 to be able to communicate with 10.66.0.0/16 via the VPN.

That being said, it looks like you're not exempting 10.55.0.0 from NAT on the 2800

Your NAT ACL should look something like this:

ip access-list extended Nat-Add

deny ip 10.55.0.0 0.0.255.255 10.66.0.0 0.0.255.255 ! Exempts traffic from NAT

deny ip 172.55.0.0 0.0.255.255 10.66.0.0 0.0.255.255 ! Exempts traffic from NAT

permit ip host 172.55.4.33 any ! Permit NAT of these networks/nodes

permit ip host 172.55.4.10 any

permit ip host 172.55.4.11 any

permit ip 172.55.6.0 0.0.0.63 any

permit ip 172.55.100.0 0.0.0.255 any

permit ip 172.55.3.0 0.0.0.255 any

permit ip 172.55.4.0 0.0.1.255 any

permit ip 172.55.8.0 0.0.0.255 any

permit ip 10.55.0.0 0.0.255.255 any

The missing NAT exemption will result in the behavior you are seeing where the tunnel doesn't come up as NAT is processed before the crypto engine is engaged to check for "interesting traffic". As a result, the traffic IS NAT'd and doesn't match the crypto ACL, so technically -- not interesting traffic.

I don't see that you posted the config for the other end of the tunnel.

Hope that helps.

naive.naive · ‎12-17-2012

but why 172.55/16 can bring up the tunnel when i try to ping to 10.66/16, without the additional lines you suggested ?

and the below lines already exempt the traffic from being NATted

ip access-list extended Nat-Add

deny ip any 10.0.0.0 0.0.0.255 (NO MATCHES)

deny ip any 172.55.0.0 0.0.255.255 (xxx matches)

btw, 10.55/16 default gateway is on 1800, then 1800 will forward the traffic to 2800, then it should pass the traffic to the tunnel.. but it doesnt..

Mitchell Dyer · ‎12-17-2012

From what I can tell pings sourced from 172.55.0.0/16 destined for 10.66.0.0/16 are matching the first NAT exemption statement (deny ip any 10.0.0.0 0.0.0.255). I don't have a good explaination as to why traffic from 10.55.0.0/16 is not being exempt, but my guess is that it has something to do with the fact that 10.66.0.0/16 and 10.55.0.0/16 are both subnets of 10.0.0.0/8.

The existing lines will NOT exempt the traffic you are attempting to pass from being NAT'd (as indicated by your test results). They WILL exempt traffic that matches the ACL statements though (i.e. any traffic destined for 10.0.0.0/8 or destined for 172.55.0.0/16).

On a side note, the lines I suggested would not be additional, but replacements for the existing exemption statements.

Alternatively you can use "debug ip nat" to see how traffic is (or isn't) NAT'd.

Hopefully that was a little bit clearer.

naive.naive · ‎12-17-2012

added the 2 lines, but still no matches..

did a debug ip nat, these networks are not being natted

i did a traceroute from 1800 to 10.66/16 from 10.55 interface, it seems that it will pass to 2800 then to 3750 and then back to 2800.

im not sure its the routing that causing this.. or the NAT .. as the traffic did get forwarded to 2800, but it just handle as normal packet and route to 3750 and not to the tunnel..

Mitchell Dyer · ‎12-17-2012

They aren't being NAT'd after you added the lines I suggested? If so, that's good.

Can you provide "sh ip route" from the 1800, 2800 and 3750?

naive.naive · ‎12-17-2012

actually after i added the 2 additional line, 172.55/16 cant reach to 10.66/16, just notice when i ping again..

1800

1800#show ip route static

172.55.0.0/16 is variably subnetted, 2 subnets, 2 masks

S 172.55.0.0/16 [1/0] via 172.55.255.1

10.0.0.0/8 is variably subnetted, 8 subnets, 5 masks

S 10.66.0.0/16 [1/0] via 172.55.255.1

S* 0.0.0.0/0 [1/0] via 225.253.110.1

1800#

2800

2800#sh ip route static

172.55.0.0/16 is variably subnetted, 5 subnets, 3 masks

S 172.55.0.0/16 [1/0] via 172.55.253.12

10.0.0.0/12 is subnetted, 1 subnets

S 10.0.0.0 [1/0] via 172.55.255.254

S* 0.0.0.0/0 [1/0] via 172.55.253.4

2800#

3750

3750#sh ip route vrf 172-55 static

S* 0.0.0.0/0 [1/0] via 172.55.253.9

3750#sh ip route vrf Public static

172.55.0.0/16 is variably subnetted, 2 subnets, 2 masks

S 172.55.0.0/16 [1/0] via 172.55.253.1

S 10.0.0.0/8 [1/0] via 172.55.253.1

225.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S 225.253.96.144/29 [1/0] via 172.55.253.1

S* 0.0.0.0/0 [1/0] via 225.253.110.1

3750#

Mitchell Dyer · ‎12-17-2012

Just noticed the route map at the end of the config of the 2800 which also uses the Nat-Add ACL, not sure what its purpose is, move back to your original statements in the ACL. I'm having trouble wrapping my head around the routing here -- thoroughly confused by what you are trying to accomplish.

Walking through the routing from the 1800, the route for 10.66.0.0/16 points to 172.55.255.1 which doesn't appear on any of your other equipment -- does that seem correct?

naive.naive · ‎12-17-2012

sorry my fault, 172.55.255.1 supposed to be in 2800 fa0/0 (removed the hsrp configs for easy viewing) below are the interfaces ip address..

interface FastEthernet0/0

ip address 172.55.255.1 255.255.255.0

duplex auto

speed auto

interface FastEthernet0/1.997

encapsulation dot1Q 997

ip address 172.55.253.9 255.255.255.248

ip nat inside

ip virtual-reassembly

ip policy route-map Nat-Add

interface FastEthernet0/1.998

encapsulation dot1Q 998

ip address 172.55.253.1 255.255.255.248

ip nat outside

ip virtual-reassembly

crypto map vpn-dynamic

im having trouble understanding the exsiting configs as well..as im being told to add vpn configs to bring up the tunnel.. other configs cant be removed..

Mitchell Dyer · ‎12-17-2012

That makes more sense. I'm not getting consistent results in my lab following the same guidelines as your configs. (When the crypto map is bound to Lo0 the tunnel will come up but NO traffic will pass). Lets try from a little bit different approach...

With your original configs:

You mentioned previously that you could ping 10.66.0.0/16 from 172.55.0.0/16, when doing so do you see both the encaps and decap counters increment under "sh cry ipsec sa"?

When pinging 10.66.0.0/16 from 10.55.0.0/16, do you see the encaps and/or decaps increment?

naive.naive · ‎12-17-2012

172.55/16 to 10.66/16 => yes the counters increased

10.55/16 to 10.66/16 => nope, counter still 0 and doest bring up the tunnel..

Mitchell Dyer · ‎12-17-2012

When you are pinging from those networks what interfaces or addresses are you sourcing from?

Sent from Cisco Technical Support iPhone App

naive.naive · ‎12-17-2012

im pinging from a PC on 10.55/16 and 172.55/16 respectively..not from the router interface..

Mitchell Dyer · ‎12-17-2012

And those addresses would be...?

Sent from Cisco Technical Support iPhone App

naive.naive · ‎12-17-2012

172.55.4.121 and 10.55.0.133