Late ACKs from torn-down HTTP connections
-
I noticed several entries like this in /var/log/filter.log:
000077 rule 69/0(match): block in on fxp0: 209.85.171.165.80 > x.x.x.x.54337: F 0:0(0) ack 1 win 8190
7. 971085 rule 69/0(match): block in on fxp0: 66.102.7.104.80 > x.x.x.x.53173: F 0:0(0) ack 1 win 8190grep 'fxp0..80.: F' /var/log/filter.log | wc -l
20I think these are related to late ACKs – mostly from torn-down HTTP connections. PF (and IPF) sometimes expire connections faster than the other end can tear them down, resulting in erroneous block msgs which clutter the logs.
A long time ago, this was related to a known problem with IPF state code.
http://www.sigmasoft.com/~openbsd/archive/openbsd-misc/199912/msg00906.html
I remember PF having the same issue when PF first came out. Maybe PF still has the issue. (SonicWall firewalls have a similar problem -- except that they send irritating e-mails accusing you of trying to hax0r them whenever this event occurs.)
As the above post suggests, it's easily solved with:
block in quick on $wan inet proto tcp from any port = 80 to any port > 1023 flags F/F
block in quick on $wan inet proto tcp from any port = 80 to any port > 1023 flags R/RHowever, the pfsense WebGUI doesn't let you create rules which refer to specific flags.
Are these two rules candidates for inclusion into the default pfsense config? Or perhaps a future version of the GUI could allow us to reference TCP flags?
-
Try a recent RELENG_1_2 snapshot which has the tcp.established timeout parameter fixed. You might be able to up this value a bit.
-
I just noticed RELENG_1 snapshots seem to have been deprecated. Should we start moving to 1_2?
-
Yep.
-
How/where do I access the tcp.established timeout parm? Is it "State Timeout in seconds" in the Advanced Options of any rule?
-
How/where do I access the tcp.established timeout parm? Is it "State Timeout in seconds" in the Advanced Options of any rule?
Yep, that's the one.