cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
853
Views
0
Helpful
4
Replies

L2L VPN communication issues for random subnets in cryptomap

synack000
Level 1
Level 1

We are experiencing random communication failures between two sites over our VPN tunnel. Both sites have the same hardware specs (5585) and software version (8.4(3)9). Both sides have matching cryptomap ACLs, just mirror images of each other.

The problem is that over a random period of time, both sides will not be able to ping specific networks that are allowed to cross the tunnel. The issue is cleared by resetting the tunnel (clear crypto ipsec sa peer x.x.x.x). It doesn't matter what side the tunnel is cleared, to fix the problem. The problem I have is what is causing this behavior to occur? Has anyone experiencing this behavior before? If so, please share.

What is interesting as well is that say for example one time 10.10.10.1/24 (site A) can't ping 10.20.10.1/24 (site B) (this has worked before. Say on site A firewall I then reset the tunnel and now host 10.10.10.1 can ping 10.20.10.1. Now say another instance, 10.10.100.1 (site A) can't ping 10.20.100.1 (site B). This has also worked before. But what is interesting is that even though 10.10.100.1 can't see 10.20.100.1, 10.10.10.1 can ping 10.20.10.1. Again to clear the issue the site to site tunnel needs to be reset. If this were related to tunnel problems you would think all the networks allowed to pass the tunnel would be affected but they are not.

And yes, all settings have been verified to match on both ends.

4 Replies 4

synack000
Level 1
Level 1

I'm surprised this issue has not occured to other folks who use L2L tunnels.

Shaoqin Li
Level 3
Level 3

can you get both sides configuration?

Sent from Cisco Technical Support iPad App

James Leinweber
Level 4
Level 4

I had similar problems occasionaly on 5520's running 8.2(2); some subnets would in effect drop out of the IPsec L2L tunnel.   This happened every 3-10 weeks for months.  I had not tried your "clear crypto ipsec sa peer xxxx" fix; we were using a more brute force approach and reloading.   It was a different pair of non-communicating subnets each time, always one on each side of the tunnel.  I never did resolve it, but I haven't seen it recur so far since I upgraded to 9.0(2) two months ago.

-- Jim Leinweber, WI State Lab of Hygiene

Yeah reloading is not ideal in my production environment.

Do you know of any useful troubleshooting commands? I tried packet-tracer, but that was not useful for Cisco tac since they didn't find anything of the root cause.

They recommended running the following debug cmds next time this occurs:

deb cry cond peer

deb cry isa 200

deb cry ipse 200

The problem is I don't want this to occur again. Tech also recommended upgrading to 8.4.6. However, I'm contemplating upgrading to 9 based on what James mentioned earlier.