We have 9 small sites connected using Pix 501s to a central location over the Internet. All of these sites are running VPN tunnels (IPSec esp-3Des esp-md5-hmac) and using IKE 3Des, MD5, DH group 2 with preshared keys. The central location is a VPN 3030 concentrator. All of the sites except 1 seem to be fine but one of them goes down (i.e. the tunnel is dropped but the remote pix stays up). This happens frequently, between an hour and a day and no traffic will bring the tunnel back up again. I can log onto the remote pix remotely using SSH to the outside interface and issue the command 'show crypto isakmp sa' and there is an IKE association that looks fine (QM_IDLE) but there is nothing on the concentrator. If I issue the command 'clear crypto isakmp sa' on the remote pix the tunnel comes back up. Then an hour or two later it will go down again.
Does anyone have a clue what might be causing this? We've tried reboots of the remote pix and it makes no difference. Could there be a problem with that device? It is running version 6.3(5) as are the others. How could I go about trying to find out the cause? Thanks.
The issue can be that the PIX is not dropping the IKE association when the timer expires but the Concentrator is doing so. This makes PIX to think that the tunnel is still alive. Check the tunnel timers in the configuration of the PIX.
Hi, thanks, I just replied to the last message before I saw this one! I put keepalives on last weekend on the advice of a support person and the tunnel comes up again (usually in between 30 seconds and 2 minutes) rather than staying down for ages. The other 9 tunnels terminated on the concentrator are shown on it as being up for several days each but the problematic one never stays up for more than a few hours. I do think there are connectivity problems rather than it being a problem with the Pix or concentrator and just need to do some testing to prove it to show the service provider of the adsl line. It's interesting to note however though that we didn't have these problems while all the tunnels were terminating on a central Pix before we moved the termination points to the concentrator (and keepalives were not enabled on the central or remote pixs either). Maybe the concentrator is more sensitive to bad connections. I did notice in the logs that the concentrator sends dead peer detection packets frequently so I think that if it doen't get a reply back fairly quickly it just deletes the tunnel.
Hi, thanks for the reply. The timers are all ok. I'm still investigating and have got some testing to do over the next week or so but it's currently better than it was. I put isakmp keepalives on the Pix firewall and now when the tunnel is dropped it doesn't stay down for very long as it was doing before. I think that the root cause is a bad adsl line but need to do some tests to prove it. Cheers.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...