This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FW dropping ACK, RST/ACK & FIN/ACK packets though packets are from valid sessions

Does the ASG function in this manner?

When the firewall receives a TCP RST for an existing session it immediately clears the session from the session table. This means there is no longer a valid session for the TCP RST/ACK to pass through. Hence, the firewall will treat the TCP RST/ACK as a non-SYN first packet and drop it.



Thanks,

Jim


This thread was automatically locked due to age.
Parents
  • When the firewall receives a TCP RST for an existing session it immediately clears the session from the session table. This means there is no longer a valid session for the TCP RST/ACK to pass through. Hence, the firewall will treat the TCP RST/ACK as a non-SYN first packet and drop it.


    FWIW, I've been seeing a lot of ACK RST (and ACK FIN) drops lately for http traffic. I've noticed this before and posted about it, and I've always wondered if they were due to timed-out sessions or something else.

    Barry
Reply
  • When the firewall receives a TCP RST for an existing session it immediately clears the session from the session table. This means there is no longer a valid session for the TCP RST/ACK to pass through. Hence, the firewall will treat the TCP RST/ACK as a non-SYN first packet and drop it.


    FWIW, I've been seeing a lot of ACK RST (and ACK FIN) drops lately for http traffic. I've noticed this before and posted about it, and I've always wondered if they were due to timed-out sessions or something else.

    Barry
Children
  • Like you Barry,
     I have noticed the same over a number of versions and posted threads on the subject, but did not get any answers.

    Ian M
  • I'm seeing more and more of these type of packets filling up my logs, e.g.

    2010:02:19-17:17:37 (none) ulogd[2724]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" dstmac="00:06:5b:04:bd:2f" srcmac="00:13:1a:66:e0:00" srcip="random.ip.address" dstip="EXT.ADDRESS" proto="6" length="40" tos="0x00" prec="0x00" ttl="244" srcport="2328" dstport="80" tcpflags="ACK RST"

    Unfortunately, I can't find a way to exclude them from the logs... creating a drop rule for all http traffic, and putting it at the bottom of my rules, does nothing.
    Note we are hosting public webservers so I wouldn't want to put a rule like this at the top.

    Any ideas?

    Thanks,
    Barry
  • Hey Barry, have you tried starting a case with Astaro on this? I'm sure they'd be interested in getting to the bottom of it.