top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

iptables fails to NAT some packets

+1 vote
520 views

I have a gateway application which I am using iptables to NAT from a LAN interface to a WAN interface (linux 3.2.6). This mostly works well, except that I sometimes see (via wireshark) IP packets being sent out
the WAN interface that originated from the LAN interface that iptables fails to apply NAT.

These packets seem to usually be FIN, FIN/ACK, or RST packets. I suspect that these are for IP connections from the device connected to the LAN interface that were setup prior to being connected to the
gateway on which I am running iptables. After some time, I think the application on the connected device decides to close these connections (FIN), but iptables fails to NAT these packets. Why?

From the iptables man page:

nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of three built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering locally-generated packets before rout-ing), and POSTROUTING (for altering packets as they are about to go out).

I'm concerned about the statement that says, "when a packet that creates a new connection is encountered". Since the SYN packet for the problem FIN,RST packets was not seen by iptables, does this mean that iptables will not NAT the FIN packet? This would seem wrong to me.

posted Oct 10, 2013 by Kumar Mitrasen

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

If your gateway haven't seen the SYN packet that creates the session, it is not able to FIN (or RST) the established session. That's what a FIN does: terminate an existing tcp session. If it would decide to create a new NAT translation on a FIN packet, the receiving host would not know the tcp session coming from the new NAT translation. It would probably respond with a RST.

So: starting a NAT translation on a FIN or RST packet services no purpose imho.

Other possibility would be that the SYN packet did go through the gateway and that it was correctly natted, but the session has been idle for too long and was deleted from the NAT table.

My guess is this sysctl setting: 

net.netfilter.nf_conntrack_tcp_timeout_established
answer Oct 11, 2013 by Abhay Kulkarni
Similar Questions
+3 votes
iptables redirects packets to local proxy

consider this scenario:

PC1 wants to telnet to SRV1 tcp 40000.

I would like to put a proxy in the middle that receives the connection, rewrites the destination, sends packet to a local socks proxy (redsocks).

So the scenario would be:

PC1 --> PROXY tcp 20000 [iptables rewrites destination to SRV tcp 40000 --> redsocks 127.0.0.1 tcp 12345] --> SRV1 tcp 40000

I tried:
iptables -t nat -A PREROUTING -p tcp -s $MYSOURCEIP --dport 20000 -j DNAT --to $SRV1:40000

It works, but I know it doesn't go through redsocks. I just changed the destination for the packets but how can I force them to flow into redsocks?

+1 vote
iptables DNAT reply packets with RST flag are sent using private ip?

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

+1 vote
Only allow packets match interface ip using IPTables

I have multiple wan port and multiple routing table in a box. The wan port should be the final destination of outside word. (eg: all the packets come from internet should have destination IPAddress of my wan port, there are no further routing beyond the wan IPAddress).

rp_filter seems not work correctly under multiple routing table situation, so I need to set rp_filter to 0.

I want to know if there are simple setup method to secure the wan port ? or I need to use iptables to drop the incoming packet not matching the wan interface IP?

The problem is I have dynamic PPP interface, so matching the ip via iptables is a little complicated. so I want to know if there are smarter ways to do the job.

0 votes
same MAC, same IP, different interface - NAT possible?

I have a setup* in which I have a server with multiple virtual network interfaces (vif1 .. vifX) that are connected (bridged) to one virtual machine each (vm1 .. vmX) which all have the same IP and MAC (let's say 192.168.1.100 resp. 00:11:22:33:44:55). In addition to that my server also has one regular network interface (eth0) connected to the rest of my network (10.0.0.0/16).

Now I would like to be able to provide NAT-like capabilities such that every packet coming from vm1 reaches the regular network as coming from 10.0.1.1, every packet coming from vm2 as 10.0.1.2 and so on. Of course, packets coming from the network destined towards 10.0.1.x should also be correctly translated by the server such that vmX will receive them.

From what I understand I could use ebtables with the snat-target to rewrite the MAC addresses for the vifX bridges, such that the remaining network would see at least a different MAC address per VM. However, I cannot see an easy solution to rewrite the IP. Using iptables nat-table and the snat-target will not work, since I would need to also filter on the source-mac or incoming device, but the snat-target is only available on the POSTROUTING chain.

One possible to solution would be to write a small program that listens on a rawsocket on every interface, rewrites packets and re-sends them on the correct interface, but I'd rather avoid that and use standard tools instead.

I would be very grateful for ideas/tips,

...