PIX 515 VPNs drop

[dayhawk]

I have 2 PIX 515s running in failover with about 100 VPNs configured. The PIX will drop all VPNS including VPN clients and i can't get them back up by clearing SAs or xlate or anything. The only thing that will fix the issue is to force a failover to the other pix or reboot both pixes. Any ideas?

BTW, I've already replaced the VAC in the primary PIX hoping that was the issue, but apparently that isn't it as the problem is still happening.

 

[dayhawk]

Oh, and it isn't just VPNs that stop working. All static translations quit working as well. Outside hosts cannot hit any of the addresses configured in a static statement. Inside hosts are all able to still get out to public internet.

 

[robrichardson]

Do your VPNs terminate at the same interface your inside hosts use for the internet?

Have you checked to see which interfaces shutdown when this happens?

 

[RobEng]

Don't suppose you have

Sysopt noproxyarp applied do you?

 

[dayhawk]

Some of my VPNs terminate to my DMZ interface and other terminate to my INSIDE interface. None of the interfaces shut down when this happens as regular internet traffic still passes. What does that sysopt command do and why would i want to apply it?

Thanks!

 

[RobEng]

If you have sysopt noproxyarp "interface" applied then your pix interface won't reply to arp requests. I had a similar problem where static nattings were not accessible from the outside Internet, but you could browse the web outbound through the firewall without a problem. As soon as I removed the "Sysopt noproxyarp inside" command, all seemed fine.

 

[dayhawk]

Here's my current sysopt config:
I don't have the noproxyarp applied.

no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
no sysopt uauth allow-http-cache
no sysopt connection permit-ipsec
no sysopt connection permit-pptp
no sysopt connection permit-l2tp
no sysopt ipsec pl-compatible

 

[chicocouk]

Run debug crypto ipsec and debug crypto isakmp on the pix while you try to bring the vpns back up, and see what they tell you. If that doesn't help, run a debug packet on the interface where the vpn terminates (on the inside? Sounds odd ...) specifying the ip address of one of your vpn peers, and check the traffic actually arrives at that interface on the pix. You could do the same for one of the static translations. Try show cpu usage to see if the pix is under a heavy load, if so, show processes may let you track down what's causing it.


CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP