12-14-2006 06:02 AM - edited 02-21-2020 01:20 AM
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?
12-20-2006 06:34 AM
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
04-03-2008 04:14 AM
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!
04-29-2008 05:12 PM
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.
05-04-2008 10:24 PM
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...
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: