Pix problem:without any reason, pix stop sending traffic to inside and outs

[sguerrero]

Here´s the problem: I have 6.3.1 version running and have had this problem: Without any change, pix stop sending traffic trough their inside and outside, it does not block, CPU remains under 50%, While in this status, I can access pix, check ports, traffic (performing shows), no crahinfo detected, no memory lacks, and reviewing interfaces, they don´t show error counts, the same with the ports from switch connected to them, I mean, no error status and both (pix and switch) show ports are up and traffic passing, but I lose connection. After reseting the ports in switch sometimes, or in pix and switch in other cases, I recover connection. What kind of troubleshooting can I practice in order to realize where the failure is? Switch ports already changed.

While the process of device blocking, I am passing around 14 MB trough the firewall.

Thanks in advance.

[nkhawaja]

Hi,

any syslog messages? Are you using SYSLOG server?, can u send output of show interfaces. When the pix stops passing traffic, have you tried doing a "clear xlat"

Thanks

Nadeem

[hossam.hassan]

pls check all pc under firwall and clean by anti-virues

[l.mourits]

Hi,

I once had a similar problem at a customer location, where the outside interface, or sometimes the dmz interface, stopped passing traffic very regularly.

I also did not see high CPU, no chrash info or other strange things. because we had a support contract at it we made it a TAC-case. We did replace the hardware and upgraded the thing, but nothing helped.

Because of the strange behaviour TAC requested more and more logging, but this PIX started to show the behaviour more often (sometimes a few times a day).

After months the TAC-engineer asked me to get rid of the local logging (logging buffered). That did the trick. The PIX never stopped forwarding traffic or showing other strange behaviour anymore.

The moral of this story? Maybe it is worth a shot to see if you have logging buffered on, and if so, see what happens when you remove this command. It helped me out and I still have this very happy customer.

kind regards,

Leo

[s.gilbrook]

Have you been trying to set-up the syslog facility on the PIX ?

When a syslog server/port is specified with the command: PIX(config)#logging host inside x.x.x.x tcp/1047 - the PIX will send messages ONLY to the PIX syslog server.

If you specify a TCP port on the above command, but you are using a different type of syslog server eg. Kiwi, then the PIX assumes that there is a security breach so stops sending packets between interfaces.

Have a look in the config and check that the logging is not set to a TCP port (it may be worth changing the port to UDP/1025).

Thanks.

[sguerrero]

Thanks a lot for all your advises. I upgraded firewall to version 6.3.3 two days ago and haven´t had the problem since that change, anyway, already enable syslog and I am monitoring, any other change, I will let you know.

Regards,

[moriarty7]

I would like to caution you that you may still be close to the capabilities of the PIX. 6.3(3) code has proven faster to me when doing testing with a SmartBits traffic generator. Syslogging and local logging also increase the load. Here is the brief basics of what I have found:

Most of the statistics out there on PIX performance are marketing numbers (and therefore now wholly true). You can (mostly) reach those numbers under ideal circumstances and in reality will never get close. There seems to be a correlation between how many services you have enabled on your PIX (Syslogging, Local Logging, Failover, Statefull Failover, etc...), the amount of traffic you are putting through the PIX and the size of the packets. A great example is that a 515 should handle 188Mbps throughtput, and yet I have been able to drown them with as little as 4.5 Mbps.

I would be wary if you are running a 515 on more than two T1's, as the box truly cannot always handle the loads. What you were seeing before may have been evidence that you are nearing the capability of the PIX and the upgrade to 6.3(3) may have given you a bit more room. I would keep an eye on your software buffers (from a show int). If these numbers start to get above 150 you are nearing the maximum capacity of the PIX. When they start spiking higher than this, you should seriously consider upgrading.

Hope this has helped!