Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

pix-vpn3000 ipsec tunnel initiation

i have a number of ipsec lan to lan tunnels configured from our central site's vpn3000 concentrator to remote pix 501s. as a general rule they work quite well. however, if for some reason, one of the machines gets rebooted, i can only re-establish the tunnel by pinging a device at the remote site from the central site. how can i give both sides the ability to re-establish connectivity or make the tunnels automatically re-establish and stay nailed up permanently



New Member

Re: pix-vpn3000 ipsec tunnel initiation


Only way to make the tunnels reestablish in a L2L is to send traffic destined for the tunnel. No way to have the devices automatically reestablish automatically. Could run a continous ping from a server. If what your also saying is that the tunnels cannot reestablish period, from the pix side, even when sending traffic and can only establish the tunnel if pinging from the 3000 side its usually because policies aren't matching up. Specifically one side is more restrictive than the other. In this case it would be the 3000 thats has a more restrictive policy than the pix. For ie, tunnel traffic defined on the 3000 is to allow traffic from to Traffic defined on the pix says to allow traffic from to So when establishing the tunnel from the pix to the 3000, pix says it wants to connect to a class A network but the 3000 is only allowing class C, tunnel is rejected. Send traffic from the 3000 to the pix, 3000 wants to connect to class C and pix is ok with that because its actually allowing the entire class A, tunnel established.

Another note, some versions of 3000 code have a "feature" where it doesn't realize that the peer went down and so when peer tries to reestablish it says the tunnel is still up, so it rejects the new request. But when pinging from the 3000 to the peer, the peer tells the 3000 that there is no tunnel, so it tears down its old tunnel and creates a new one. This feature should have been removed in 3.6.3.

Debugs would tell you which problem you are actually running into though, could be something else but these 2 are the most typical. Hope this helps.

Kurtis Durrett

CreatePlease to create content