Iptables ESTABLISHED,RELATED chain problems

iptables

I have iptables setup on a Fedora box of mine. I'm allowing all inbound HTTPS traffic, all outbound traffic, and I also have an allowed estbalished,related rule. However I am seeing drop entries in my logs like this:

Traffic Dropped: SRC=X.X.X.X DST=My_Server_IP DF PROTO=TCP SPT=443 DPT=Random_High_Port

Why isn't my established/related related rule picking this up and allowing it? My only thought is that it's timing out the connection before this reply is received. If that is the case, does anyone know what this timeout window is or if it can be modified? Thanks.

EDIT:

Here is a full packet

Dropped Traffic: IN=eth0 OUT= MAC=_____________ SRC=X.X.X.X DST=Y.Y.Y.Y LEN=81 TOS=0x00 PREC=0x00 TTL=46 ID=11862 DF PROTO=TCP SPT=443 DPT=50680 WINDOW=6235 RES=0x00 ACK PSH FIN URGP=0

Here are the 3 IP table rules that matter to this scenario

/sbin/iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m state –state NEW –dport 443 -j ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

This should be incoming traffic related to an outbound connection since the source is 443. I just need to know why it is failing and/or what the time out is.

Best Answer

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.

Related Topic