Re: [fw-wiz] Strange Pix behavior.

From: Jim MacLeod (jmacleod_at_gmail.com)
Date: 06/16/05

  • Next message: Paul Melson: "RE: [fw-wiz] Strange Pix behavior."
    To: Paul Melson <psmelson@comcast.net>
    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
    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


  • Next message: Paul Melson: "RE: [fw-wiz] Strange Pix behavior."

    Relevant Pages

    • Re: [fw-wiz] Firewall Load balancing solution
      ... It's actually possible to do rudimentary load balancing with VRRP by using ... splitting the traffic between the firewalls. ... With additional boxes you may as well not use VRRP. ... the session state, so splitting a single TCP session between two firewalls ...
      (Firewall-Wizards)
    • Re: Apparent session crosstalk
      ... The first thing to check is to make sure you are using Session() and not ... > personal information, and sometimes, they will go to different page ... We have had the users hit one of the servers ... > have put in a bunch of log messages to determine if the person id is ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: Session variables and Databind
      ... As a guess from your description - Proxy/cache servers and some firewalls ... have a nasty tendency to consume your NTLM credentials, ... cant maintain the session. ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: session functions not working with windows XP, php 4.3.4
      ... my session save path is set to /tmp. ... > as i mentioned in the title, im using windows xp with PHP ... disable any firewalls such as ZoneAlarm and try again. ...
      (comp.lang.php)