501 inside freezes

[randy-clark]

Hello, I have just implemented a 501, and am having a strange issue. Seemingly intermitantly, the inside interface stops responding/passing traffic. I cannot ping the inside interface nor can I pass traffic to the Internet/VPN tunnel. After anywhere from 30 seconds to 1.5 minutes, the PIX will respond once again to a ping, and traffic flows normally. This has been duplicated on PIX OS 6.3(1) and 6.3(3). An IPSEC LAN-to-LAN tunnel is up to my corporate office, and the PIX is handling PPPoE negotiations with my DSL provider. Other than this strange behavior everything is working as confgured/expected. I have an additional PIX 501 and a 506E to implement in production shortly, and would like to resolve this issue prior to moving these other two firewalls into production. Any help you all could provide will be appreciated. I can provide configs if needed.

thanks,

Randy

[gfullage]

Are you sure the PIX isn't rebooting? We have had power connection problems with earlier 501's, where the power cable wouldn't connect properly and just touching the 501 would cause it to reboot. Do a "sho ver" and check the uptime the next time it happens, if it's only been up for a few seconds then that's your problem.

The power connector and cable were both modified a while ago now and very few customers actually ran into this problem, so no field notice was ever issued. If this is your problem then open a TAC case and you'll be able to get a new one sent out.

[randy-clark]

Good Idea, but the pix isn't rebooting. System uptime is 4 days and my VPN tunnel has been up for 4 days. which corresponds to when I placed it in production on my DSL connection in the lab. I have had a ping going to the inside interface (from inside) and have had no dropped packets. Usually a ping prevents the symptom from occuring, so I have stopped the ping for now to see if I can reporduce again. Of course I'm not seeing anything in the external syslog for this because the inside interface is unavailable.....The symptom just happened during the ellipses in this reply.

System uptime is still 4 days, and the VPN tunnel has been up 4 days.

[jsalminen]

This may not apply, but are you connecting the pix to a switch on either side? If so, you could have a duplex mismatch or speed mismatch and the pix or switch port is disabling temporarily. I have two 501s in use and they are quite stable. I made sure that the port speed matched in the pix and switch. No auto-detect allowed.

[randy-clark]

thanks for the reply. I had thought of that and manually set the inside interface to 10 half for hub it was connected to, then replaced the hub with a 10/100 switch and set the interface to 100/full. a "show int" shows no errors accumulating on the ports.

[r.state]

Is there a chance of a duplicate IP address on your inside network? - I have seen the same results you are experiencing and a dupe address was the cause.

When succesfully pinging the PIX, do an "arp -a" from the CLI of your PC to record the PIX mac address, repeat the same command when the pix isn't responding. - Alternativent the pix may be faulty...

Rowan

[randy-clark]

no duplicate IPs. The inside network is actually my lab at home, and right now consists of only three computers and two addressable network devices, one of which is the PIX. Very simple design as it's in its early stages.

If I have a constant ping going to the inside interface, I don't see this behavior, but if I stop the ping, the behavior returns albeit intermitantly....it's bizarre.

thanks for the thought. Any other ideas out there?

Randy

[mostiguy]

i would follow up on the arp table. connect with a rollover cable, and check the arp table when the problem occurs. enable buffered debug logging when it happens, and look at what is doing

if you were to enable debug logging, and log to a syslog server on the inside, the problem probably would not happen because you would be sending enough traffic that it would be similar to when you continually ping it. if you could set it up to debug log to a syslog server on the outside interface, that might be able to log everything while keeping conditions right for the problem to occur