Weird PIX problem again

Hi, I'm experiencing the same annoying problem on our PIX reported to this group a few weeks ago.

Inbound smtp connections to our email server from the Internet is fine, except that in certain situations, an Internet client sends a reset-O and immediately, the PIX goes berserk, with the Deny messages in the log below.

When this happens, cpu utilization goes through the roof. Disconnecting the mail server (with an internal address a.b.c.d in the log below) did not help; somehow the PIX still thinks that the mail server is swamping the dmz interface (even though the mail server has been removed from the network). The only way to stop this is to reboot the PIX.

This probably happens a few times a week; at other times when this is not happening, inbound/outbound mails get delivered without problems.

The PIX version is 6.3(5). I've tried turning off mailguard (by removing smtp fixup), but the problem persists.

Is anyone experiencing the same problem? Any ideas/suggestions much appreciated.

TIA.

Nov 07 12:50:19 10.1.1.1 %PIX-6-302013: Built inbound TCP connection

485068 for outside:e.f.g.h/3854 (e.f.g.h/3854) to dmz:a.b.c.d/25 (i.j.k.l/25) Nov 07 12:50:29 10.1.1.1 %PIX-6-302014: Teardown TCP connection 485068 for outside:e.f.g.h/3854 to dmz:a.b.c.d/25 duration 0:00:10 bytes 1984 TCP Reset-O Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz Nov 07 12:50:29 10.1.1.1 %PIX-6-106015: Deny TCP (no connection) from a.b.c.d/25 to e.f.g.h/3854 flags ACK on interface dmz
Reply to
centaury_utopian
Loading thread data ...

Try using 'capture' to examine the packets it thinks it is getting. See whether there are real packets there (or if the PIX is stuck processing the same packet), and if there are real packets there then crosscheck the MAC in case somehow there is an IP spoof.

Let's see... do I recall correctly that you are using a PIX 501? If so then look at memory usage near the time the problem happens; strange things can happen on a PIX that runs out of memory, and the 501 is more prone to running out of memory than the other 5xx models.

Reply to
Walter Roberson

Thanks for your suggestions.

I may have found the solution. It may be that an inline device is wreaking havoc by flooding the PIX when certain SMTP patterns are detected. The IDS has been disabled and there hasn't been a similar incidence since - but I'm monitoring the situation.

Walter Robers> > >I'm experiencing the same annoying problem on our PIX reported to this

Reply to
centaury_utopian

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.