IPsec clients can not ping internal hosts

[oldcreek12]

Hi, I am setting a new branch office, IPsec L2L tunnel is set between branch ASA 5505 and HQ ASA 5520. HQ ASA is the gateway to software IPsec clients and ezvpn clients operating in network extension mode. HQ (and software IPsec clients) is using 10.0.0.0/8 address space, while ezvpn clients and this branch office will be using 172.16.0.0/12 address space. Branch office uses 172.30.0.0/20 exclusively.

I also configured IPsec RA on branch office, the RA pool is 172.30.1.0/24, full mesh IP connectivity is achieved except that IPsec clients from branch office can not ping hosts in branch office but can ping anywhere else. Specifically, branch office IPsec client is getting ip address 172.30.1.1 and there is a live host in branch office with ip address 172.30.0.253 in inside VLAN, debug capture on ASA5505 of ping from 172.30.1.1 shows that 172.30.0.253 received echo request from 172.30.1.1 and ASA received echo reply from inside VLAN.

This really puzzles me, since ASA5505 has IPsec SA for remote access client, and 172.30.1.1/32 is in the routing table, ASA should simply look at security policy database, and sent the echo reply to the right IPsec peer.

I do have a rather loose access-list defined for L2L ipsec tunnel,

access-list traffic_to_HQ extended permit ip 172.30.0.0 255.255.240.0 10.0.0.0 255.0.0.0

access-list traffic_to_HQ extended permit ip 172.30.0.0 255.255.240.0 172.16.0.0 255.240.0.0

I am wondering maybe the echo-reply is being sent to L2L tunnel because the traffic matches the access-list. But due to longest match rule, IPsec should not use L2L SA to send a packet destined to 172.30.1.1 to L2L tunnel, correct? is there any way to know where the echo reply packets go? any other configuration I might have missed?

Thanks a lot.

[husycisco]

Can you temporarily put a permit ip any any in outside interface before running packet-trace? Btw sometimes reloading the device resolves weird issues like this one. What do you see in capture if you ping VPN client from router?

[oldcreek12]

permit ip any any did not help, I didn't think it would help because the traffic is coming from IPsec tunnel... ping from inside has the same results, aka, ping packets loop inside ASA. I reloaded several times, still no go, this is really frustrating... I will try to upgrade to 8.04 next week.

[husycisco · Accepted solution]

"permit ip any any did not help, I didn't think it would help because the traffic is coming from IPsec tunnel"

My intend was "run packet-tracer again after permitting any to any at outside interface"

Assuming that you have logging enabled, what syslog messages show up when you try to telnet into that router?

Can you create a tunnel-group test and assign a pool which is not covered by any of your inside networks, then create exempt nat and split tunnel acls accordingly? Are results the same in test group with new pool?

Also try

no crypto isakmp nat-traversal 10

crypto isakmp nat-traversal 30

[oldcreek12]

Changing RA pool to 192.168.100.0/24 resolved the problem, what does this mean?

[oldcreek12]

Hi,

This is extremely helpful, I reconfigured all ACLs (nat 0, split-tunnl and ACL for L2L) to be very specific, instead of the loose ones I originally configured, and the problem is resolved. Looks like ASA is not doing longest-match for destination when looking up security policy database.

[husycisco]

Hello Jian,

Nice to hear that problem is resolved. I usually recommend people to use a VPN subnet which is not covered by any other subnets, that causes issues, subordinal routing and hard troubleshooting, but in your issue, you had reverse-route, which should have created a static route in routing table and should be preferred since it has /32 prefix. I am still curious about the packet-tracer output of your non-workng config. I will load your config in my lab when I have time and work on it, I couldnt find a bug close to yours in bug database, we might have discovered a new bug.

[JORGE RODRIGUEZ]

Im curious as well to find out why these two nets 172.30.0.0/20 and 172.30.1.0/24 did not route properly.. this is code 7.2(4) and as you said it could very well be a newly discovered bug.. definately grants a lab test .

Points well diserved Huseying !

Always good to see your around.

Rgds

Jorge

[oldcreek12]

I don't think reverse-route makes a difference though in my case, as I am not redistributing the static route out to other network devices. The reason I choose loose ACLs is for convenience, because this way whenever a new subnet is added, I don't have to touch network devices, I assume ASA will always to longest match, that has been working fine,

Thank both of you very much for your time.