'http', 'https' (and other TCP?) helpers shouldn't drop related traffic.

[mikemol]

On the tail end of TCP connections, unless both ESTABLISHED and RELATED packets are allowed via the conntrack module, we seem to be chopping off the final FIN packet.

This not only clutters up logs, it can change the way applications behave. For example, I've seen this interfere with early versions of Pandora's HTML5 interface; the song reached its end, but Pandora's server kept sending more data.

http and https helpers, and possibly most TCP helpers, should be configured to not drop that tail-end FIN packet.

[mikemol]

Here's a basic example, coming from my web server (with things that I'm certain are unrelated removed, such as IPv6 considerations):

#!/sbin/firehol
interface eth0 pubifc
        policy reject

        server http accept

        protection strong
        client all accept

I see a lot of logged messages like these:

Jan  4 16:19:35 prgmr2 kernel: [8393384.760065] OUT-pubifc:IN= OUT=eth0 SRC=[server IP] DST=[client IP] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=62172 DF PROTO=TCP SPT=80 DPT=57467 WINDOW=8576 RES=0x00 ACK FIN URGP=0

I don't have a great deal of IPv6 traffic on that machine; both [server IP] and [client IP] are IPv4 address for this line and others I've seen like it.

[mikemol]

.Just noticed that this is related to FIREHOL_DROP_ORPHAN_TCP_ACK_FIN: http://firehol.sourceforge.net/commands.html#FIREHOL_DROP_ORPHAN_TCP_ACK_FIN