What would make a site-to-site VPN go down after a couple of hours?
mrblackmamba343
Inactive Imported Users Posts: 136
Both peers have all timers set to 24 hours in both the isakmp policy and the crypto map but unless I initiate connection to bring up the tunnel remote users can't. I always have to initiate communication. Why can't remote users do the same thing?
Comments
-
dtlokee Member Posts: 2,378 ■■■■□□□□□□Need more information to help, but one thought - is there a firewall in the path between the VPN endpoints?The only easy day was yesterday!
-
Daniel333 Member Posts: 2,077 ■■■■■■□□□□Not sure about your envionment... We had a point to point that kept going down. Turned out we were loosing packets here and there. Called the ISP, in a few days they replaced some wiring and hasn't had a problem since.-Daniel
-
Ahriakin Member Posts: 1,799 ■■■■■■■■□□There are multiple reasons, what do your logs tell you (look for anything at that time period, not just VPN related).
Does the crypto policy allow both sides to initiate (they can be set to initiate or respond only aswell as the usual 'both').
If you clear the tunnels on both sides can the other site then initiate the tunnel at least to begin with? (I've seen re-key'ing issues between Cisco and Juniper due to the anti-replay window falling out of sync that had similar results, best to see what happens with fresh phase 1 aswell).
Does the tunnel attempt to form at all on their appliance when they initiate? If so how is NAT being handled on both sides? If you are NAT'ing but using a NAT/Global pair instead of the Static command then the translation is only allowed one way, i.e. if you are NAT'ing your site using NAT/Global the translation will be made outbound and the connections will form correctly, if they try to initiate the connection inbound to your NAT'd hosts it will fail. Ditto for PAT.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?