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

do you have an example that we can see (logs or wireshark packet)?

I've not checked the sessions table, but I sure I'm seeing a lot of dropped packages on the packetfilter log with the "ACKRST " flags set up. So, is this a normal behaviour? Sorry, but running 7.003 (customer not wanting to buy renewal).

Not willing to buy renewal?  If you can access WebAdmin, then you should be able to Up2Date to 7.405.  Don't go to 7.5 until 7.501 is out sometime in thenext week, I expect.

I don't think there will be much help available for 7.003.

Since Jim never posted on this thread again, my guess is that he found no real problem.

Cheers - Bob

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

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.

I haven't. 
I need to play with it a little more though; I was trying something else with a PF rule today, and it took a LONG time (~5mins) before the rule went into effect, so I need to re-test the rule for the http traffic.
(this was on 7.306; I have no idea why it took so long, the cpu load is low)

Thanks,
Barry

I am getting a lot of "ACKRST" as well but I wasn't sure that other people face the same issue. I thought It was my configuration causing this. I will investigate more

I've re-added my PF rule:
source: ANY
service: HTTP
dest: ANY (also tried LAN)
DROP (without logging)

However, this isn't making a difference... I still have over 300k log entries per day like: 

2010:02:22-15:58:56 (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.addr" dstip="one.of.our.external.ip.addresses" proto="6" length="40" tos="0x00" prec="0x00" ttl="241" srcport="1198" dstport="80" tcpflags="ACK RST"

and

2010:02:22-15:58:57 (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.addr" dstip="one.of.our.external.ip.addresses"  proto="6" length="40" tos="0x00" prec="0x00" ttl="119" srcport="59067" dstport="80" tcpflags="ACK FIN"

I'll open a support case too.

Barry