Blocked packets that should be accepted by iptables

Pastorino · 09-23-2005, 08:15 AM

Hi everyone,

I noticed that iptables is blocking a few packets that it should accept because they're ESTABLISHED,RELATED packets.

While researching for it, it seems that it is because of connection tracking.

For example: someone opens my web site, and iptables lets it all pass. But the person leaves the browser open for a long time. When he closes the browser, a packet is blocked... sometimes is an ACK FIN packet... sometimes is a FIN packet.... sometimes is a RST packet.

Is this normal? Does it compromise the connection from my customers? How long is the connection tracking timeout? (I mean, after how long does the connection tracking stops seeing the packet as an ESTABLISHED packet).

Thanks.

jonlake · 09-23-2005, 09:43 AM

Quote:

For example: someone opens my web site

Right there it is going to be a syn packet, initial state, not established. So I don't think the problem is with packet states. If you are hosting a website, it would be best to allow all port 80 packets to your web server, regardless of state.

Mainly you only want to worry about state on connections coming back in from a connection you initialized from your LAN.

I know this doesn't answer the question you asked, just my

Pastorino · 09-27-2005, 08:56 AM

My firewall is configured like this (showing only the important information, so I'm not showing destination, source, and protocol):

IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

IPTABLES -A INPUT --syn --dport http -j ACCEPT

IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

I don't think it's wise to open the port 80 regardless of state. I think it's more secure the way above.

I still need my original question answered, please. Anyone?

Thanks.

unSpawn · 09-27-2005, 11:06 AM

IIRC the kernel conntrack table flush is equiv of aprox 3 days (kernel headers), so I don't think there's a problem there. Locally and client-side set values like OS TCP connection timeout, daemon or browser session timeout or keepalives will probably time out much earlier. What you're probably seeing is an attempt by the clients OS to close the connection properly and has no effect on any by then already closed browsing session.