Re: Strange Pix behavior.

[Jim MacLeod <jmacleod () gmail com>]

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 
too soon.

> 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
> your monitoring/analysis?
>  
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. :-)

-Jim
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards