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

Single subnet fails VPN connection

richmorrow624
Level 1
Level 1

We have a cisco 2811 series router set up with a VPN tunnel to a remote site. The router is configured to allow 5 different subnets through.

We are passing traffic on several subnets with one single subnet the bulk of the traffic.

Before there was a 3005 VPN concentrator in place of the router and there was not this problem.

The problem is that the subnet with the most traffic looses connectivity. No pings, nothing, while all others stay connected. It has only happened three times in the past two months, so it is not bad as it could be.

All other subnets pass traffic fine.

It takes a router reload to re-establish connection.

As I said, it never happened on the concentrator even though it was bogged down with all of the traffic.

Debugs while the subnet is down shows nothing.

I did a "clear crypto isakmp sa" it cleared and I never saw any debug information as if the tunnel did not try to rebuild, even though the working subnets could still pass traffic.

"sh crypto session" showed all subnets up and active.

I cleared the access-lists and tried to ping the dead subnet and I can see the packets match the access-list leaving the interface, but nothing.

Any thoughts out there?

4 Replies 4

s.jankowski
Level 4
Level 4

If your replay window size has not been set to a number that is high enough for the number of packets received, you will receive this error message.Refer URL

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455ad4.html

jan.marsman
Level 1
Level 1

Did you ever got this issue resolved? I have a similar case where a single subnet is not reachable for a couple of minutes.

Every 5 minutes we get the:

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed

message in the log and changing the replay window has not an effect.

Thanks!

This problem was actually related to a non Cisco appliance on the peer end of the VPN tunnel.

I do not remember the name of the firewall/router that we peered with, but the OS had a problem that caused this issue.

Also, my end was a Cisco Router, I did not see this problem with the 3005 concentrator that was previously in place, so the problem was related to the peer and IOS.

Is by chance your peer a non Cisco appliance of some kind?

Perhaps reduce the tunnel lifetime to something shorter than what the remote end is configured for.

Thanks!

After quite some troubleshooting we found that indeed the Linux based end point on the far end was creating the issue. Access-lists where not exactly the same...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card