12-17-2012 07:45 PM - edited 03-04-2019 06:26 PM
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..
12-17-2012 07:52 PM
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.
12-17-2012 08:26 PM
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..
12-17-2012 08:58 PM
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.
12-17-2012 09:06 PM
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..
12-17-2012 09:17 PM
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?
12-17-2012 09:24 PM
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#
12-17-2012 09:57 PM
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?
12-17-2012 10:04 PM
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..
12-17-2012 10:55 PM
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?
12-17-2012 11:29 PM
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..
12-17-2012 11:47 PM
When you are pinging from those networks what interfaces or addresses are you sourcing from?
Sent from Cisco Technical Support iPhone App
12-17-2012 11:50 PM
im pinging from a PC on 10.55/16 and 172.55/16 respectively..not from the router interface..
12-17-2012 11:53 PM
And those addresses would be...?
Sent from Cisco Technical Support iPhone App
12-17-2012 11:54 PM
172.55.4.121 and 10.55.0.133
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide