PIX/VPN Tunnel Question

[dm318]

Hi folks, can someone help? Say there's a VPN tunnel between 2 PIXes and the tunnel drops occasionally, is there a way to get the PIXes to recover and re-establish the tunnels automatically without human intervention? Thank you.

 

[cchipman]

As far as I can tell, my Pix does that for our IPSec VPN tunnel.

 

[dm318]

cchipman, does that mean VPN tunnels on PIXes are supposed to self recover when connection drops? I suspect so, right?

 

[cchipman]

Yes. I'd have to search to see if its a timeout, or upon a connection request. I do know that there is some kind of time based maintenance (based upon watching the debug output of establishing IPSec tunnels)

You might start investigating using the "debug IPSEC" commands to troubleshoot.

 

[yizhar]

HI.

I agree with "cchipman" - it could be a timeout configuration issue.
You should compare the configuration and the output of several "show crypto" commands and verify that all the timeouts match.
You can see here some sample of "debug" commands for VPN:

http://www.cisco.com/warp/public/110/37.html#tshoot

And here are some "show crypto" samples:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/cmdref/c.htm#28772

It could also be related to MTU.
You can test this with "ping -f -l NNNN" using different valuse for NNNN (in the range 500 to 1500).
The default MTU for Ethernet on your internal hosts is 1500. If this does not pass unfragmented via the VPN tunnel, you should consider configuring the servers (and maybe workstations) involved with VPN traffic to a lower value like 1400 or even lower.

It can also be a network issue (the Internet). Try unencrypted traffic when you have a problem. For example ping results to the other pix (or to the other router if the pix is configured to block ping).


Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[dm318]

I see. I get what you mean - not so much that the tunnel has dropped, just that if certain machine's MTU settings is set too high, it may cause a false time-out reply thus giving the impression the tunnel has dropped.

Thanks Folks.

 

[rickh9]

I have seen this behaviour with the PIX far more often than VPN Concentrators in the same situation. My conclusion is that the pix is slightly less robust when it comes to sustaining inactive tunnels. In testing downed vpn tunnels I did discover that pinging from the far side would always bring the tunnel back up.

My solution PIX to PIX is to use a keepalive IE: isakmp keepalive 10 10
In cases where the remote hardware does not have a keepalive function, I use task scheduler on a remote server to ping a local server every 10 mins.

Now my VPN tunnels rarely go down. I should point out that in several cases I really don't care if the tunnel drops out, since any network traffic from those locations to the PIX always reconnects the tunnel.