Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a router performing simple NAT translation using iptables iptables -t nat -o -j MASQUERADE

This works fine almost all of the time except for one particular case where some TCP RST and FIN packets are leaving the router un-NAT'd.

In this scenario I setup 1 or 2 client computers streaming Flash video (eg At the router I then tear down and re-establish the public interface (which is a modem) As expected the Flash streams stall out. After the connection is re-established and I try to refresh the Flash pages, I see some TCP RST and [FIN,ACK] packets leaving the public interface (I assume as Flash attempts to recover its stream).

I don't know how these packets can leave the router non-NAT'd

share|improve this question

This might be a bug in the MASQUERADE target of iptables. In your scenario, it appears that you have the following co-inciding events:

  • the packets happen to belong to a connection already present in the state table
  • the state entry includes a NAT address source no longer owned by the system

So an attempt to masquerade the packet might fail due to an invalid address to masquerade to, thus the packet is being routed out unchanged.

The expected behavior from the MASQUERADE target would be to have the according state entries cleared when an interface goes down or gets the address changed, so this situation should not have occurred. But there has been an ancient bug reported for iptables which sounds like it could trigger a similar kind of behavior.

To do some further troubleshooting, note the public IP address of your router, reproduce the issue and take a look at the state table by using egrep /proc/net/ip_conntrack (where is the IP address you previously noted). If you get conntrack lines with the old IP address despite of the public interface address having changed, you probably are running into an iptables bug - consider updating your kernel/iptables and reporting the issue to the netfilter team.

share|improve this answer

Dropping the [RST,ACK] and [FIN,ACK] will not work. There are many application like ftp upload that will simply fail to ack the completion of the FTP transfer. The comments by gscott are the correct method, but one additional requirement is needed. You must make them strict by applying the policy

iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -P INPUT DROP

With this, you need to specify all your rules, or the packets will be dropped.

share|improve this answer
up vote 0 down vote accepted

Thanks for the tip. I was just what I needed to set me on the right track.

The root cause was unfiltered forwarding between lan and public interface. When the public interface got torn down it cleared the conntrack entries. The clients then tried to revive their connections and ended up sending out RST and FIN packets. Since NAT gets setup only on NEW connections, these packets then left the router unmodified.

I had to change my forwarding rule to only allow NEW,ESTABLISHED,RELATED packets to get forwarded from private lan.

share|improve this answer


An other way to prevent the FIN,ACK and RST,ACK packages going in the public network is to block them in the outgoing chain

iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST,ACK -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN,ACK -j DROP 
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST -j DROP

This helped me to prevent spoofed packages.

share|improve this answer

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.