Re: [fw-wiz] Strange Pix behavior.
From: Jim MacLeod (jmacleod_at_gmail.com)
To: Paul Melson <email@example.com> Date: Thu, 16 Jun 2005 09:43:39 -0700
Paul Melson wrote:
>I'm sorry. You're absolutely correct. It is not an RST+ACK, but rather a
>FIN+ACK from the server in response to a FIN+ACK sent by the browser.
Hrm, that could explain why the other folks that have seen this problem
have fixed it with a code upgrade, if the PIX is purging the table entry
>I would wager that if George looks through his logs, he is only seeing these
>entries for TCP connections. The example he gave was specific to HTTP, so I
>think this still applies.
The problem could be caused on UDP traffic with a session timer set too
short. Come to think of it, that could also cause the TCP session
errors. This assumes that these protocols have periods of time when
there's no data being transferred. If the remote server is heavily
loaded and not sending responses quickly, could that do it?
>As far as the normalcy of this behavior, I think that nearly any stateful
>firewall that has multiple clients behind it experiences session state
>mismatch, which these log messages are a symptom of. It's part of the
>nature of stateful firewalls.
Although your explanation makes sense, it doesn't explain why this
behavior is only observed on occasional firewalls, such as George's. It
definitely sounds like state mismatch, but I still think it's possible
the HA setup is part of the problem by causing delays in state table
updating at the beginning of the session.
>I wouldn't suggest that anybody eliminate all
>'drop' messages from their log stream, but if you know that any drop message
>from [someaddr]:80 to [nataddr]:[>1023] is erroneous, why not keep it out of
It's a good filter suggestion, but I personally prefer to include all
data in the monitoring and discard known oddities as part of the
analysis. Call it an additional debug level of paranoia. :-)
firewall-wizards mailing list