Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.


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.

share|improve this question
That looks like your server computer accessing a remote computer via HTTPS. Is that what you're expecting? –  Evan Anderson May 23 '11 at 16:40
Could you update your post with the output of "iptables -nv -L", please. That would allow us much better analysis of the situation. –  wolfgangsz May 23 '11 at 16:46
@Evan Anderson: If it was his server accessing a remote computer via HTTPS, then surely his server's IP would be the source? –  Zayne S Halsall May 23 '11 at 18:05
@Zayne: This is a response from a remote computer to the OP's server. The source IP address is the remote computer and the source port is 443. That destination is the OP's server's IP address and a random high port. That sure sounds like a response packet from an HTTPS server on a remote computer to an outbound connection from the OP's server. –  Evan Anderson May 23 '11 at 21:17
@Evan: Right. This computer talking outbound via HTTPS is not a problem at all. Just that communication needs to be allowed back in and apparently isn't in all cases. –  user75696 May 23 '11 at 21:31

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.