Iptables: How to read this OPT string

I have seen a very similar issue on my own systems and I may have an answer as to what is happening.

Apparently, TCP allows the client to send a FIN packet, and you to ACK that FIN packet, but still keep your end of the connection open and push more data through it, sending your own FIN packet at some time in the future. I remember reading that this was implemented at some point in Kernel 2.6 although my memory on this point may be inaccurate/irrelevant.

Many firewalls, including IPTables, don't seem to have implemented this yet or implement it incorrectly and consider the connection closed as soon as they see a FIN followed by an ACK. The result of this is that every so often, my server sends a packet out to a client that the firewall thinks is not part of an established connection and is not new and so drops it.

In practice, I haven't seen any important data in those final few packets that are being dropped, so the effect is a few extra reset packets getting thrown around and some extra connections left in the FIN_WAIT state but no broken or half-loaded pages.

I don't know about the 20 minute timings you are seeing but I would guess that it's a client of some sort that runs regularly every 20 minutes and does a request that causes your server to do the FIN ACK PSH FIN RST sequence.

This post may offer more information about exactly why IPTables drops these packets: http://lists.netfilter.org/pipermail/netfilter/2005-August/062059.html

According to Chris Brenton, it's a mismatch between the timeouts of the client, the server and the firewall for packets in the one-side-closed state.

Netfilter has dropped the connection from the state table. One of the timeouts in /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_* has expired. I'm guessing it is nf_conntrack_tcp_timeout_last_ack.

Here is a scenario: Your web server sends a final packet with some data and fin set. The client goes comatose for 30 seconds. Netfilter removes the entry from the state table. The client wakes up and sends a fin ack that is not part of a tracked connection anymore.

I see this all the time on web servers. It is client problem.

If you want to verify that you could record the state table (/proc/net/nf_conntrack) and correlate that with the firewall log.

Edit: I had the direction reversed but the concept applies. In this case his server is making outgoing https connections so it is actually the client and the remote web server may be slow to respond.

The rule

/sbin/iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT 

has nothing to do with it. It is about DST port 443 and this is SPT 443.