What is the proper way to handle DNAT when traffic leaves a different interface than it arrived on? When this happens it seems the reply doesn't have the source address replaced automatically as it would if it were going out the same interface it arrived on.

Edit -- SNAT not working out for me:

Chain PREROUTING (policy ACCEPT 386 packets, 23372 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       all  --  *      *           to: 

Chain POSTROUTING (policy ACCEPT 288 packets, 18672 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 SNAT       all  --  *      eth0              to: 
    0     0 SNAT       all  --  *      eth3              to: 
    8   550 MASQUERADE  all  --  *      eth0           
    0     0 MASQUERADE  all  --  *      eth0           

Chain OUTPUT (policy ACCEPT 23 packets, 1572 bytes)
 pkts bytes target     prot opt in     out     source               destination

So in the above both routers have the same tables and same interface layout. eth0 on both routers are Internet connections and eth1 on each router connects to the same LAN (10.7.0/24). eth3 connects the two routers to each other.

What is happening is am pinging the address from a location on the Internet. The replies go in Router B via eth0 and out eth1 with the destination nat working fine. The replies are entering eth1 on Router A and exiting the Internet via eth0 on router A. However, the source address is not being overwritten and the replies make it back to the device sending the pings with address*.

*Yes, they actually make it across 20 hops with a private source IP and don't get squashed anywhere -- kind of amazing).

Even More Edit:
Okay, apparently SNAT (at least it seems from the iptables manual) only matches if it is stateful. So I need stateless nat. This can be done with iproute2, but according to http://linux-ip.net/html/nat-dnat.html#ex-nat-dnat-full it can also be simulated by using --to-destination with SNAT in iptables. However, my ubuntu 10.04 just says unknown option --to-destination...

  • 1
    Do the DNAT then SNAT to the address on the interface on which the traffic is departing.
    – topdog
    Jul 26, 2010 at 16:49
  • Those packet counters are not going up for the egress traffic on router A either for any of the nat chains. I do see the FORWARD rule incrementing as I would expect though. Jul 26, 2010 at 21:32
  • The packets do seem to be going out as I describe as well based on the tcpdump output ... I keep checking this because it seems like I am just crazy :-) Jul 26, 2010 at 21:35

2 Answers 2


To my knowledge, the address rewriting behaviour you're describing will happen so long as the outbound response packet is routed by the same router that routed / DNAT'ed the incoming request. If any other of the N+1 routers in the highly-available router pool are handling the outbound response packet, though, they're not going to "see" that connection in the Netfilter state database.

It sounds like you want a highly available Netfilter router that shares NAT state machine information. The ct_sync tool mentioned in that paper has been mostly abandoned, but the conntrackd tool from conntrack-tools has been developed to do some of the same things as ct_sync.

If you're planning on doing stateful packet filtering (or NAT, which is really just a superset of stateful packet filtering) then you're going to need a method to distribute the state database (or, alternatively, go with stateless filtering in the network and do stateful filtering on each host).

  • Hmm... I think I can make this work without stateful sharing as long as I can have some sort of simple nat without state tracking as I am going to be using an inbound model for the filtering. The stateful tracking will be for less critical production traffic. So I am going to see if I can manage this with the SNAT. In general I am going to try to engineer it so it doesn't go on wonky paths but it is nice if the critical production traffic works even if it is. Jul 26, 2010 at 19:45
  • @Kyle: I wouldn't mind discussing the NAT requirement offline in more detail at some point. I miss the chat site already. Jul 26, 2010 at 20:48
  • @Evan: Well updated it with NAT tables and explanation of the context they fit in which should help... Jul 26, 2010 at 21:00
  • @Kyle: Your link re: "simulating stateless NAT" doesn't jibe with any use of the SNAT target that I've ever heard of. SNAT can take an argument "--to-source", but not "--to-destination" (at least that I've ever seen). I see what the article is trying to do, but I think they want "--to-source" in their second command-line. I'm at a loss, right now, as to why your NAT table rules aren't showing incrementing packet counts. Jul 26, 2010 at 22:38
  • @Evan: Ya I think you probably need to use the iproute2. I am now debating between conntrackd and stateless nat. The thing with conntrackd is that if the connection I am using to sync the tables breaks then it might get messed up and I got the single point of failure I am putting all this effort into avoid. If I can use conntrackd to sync over multiple paths it just might work (looking into that now). But right now I might lean toward the iproute2 dumb nat so to avoid the overhead ... Jul 26, 2010 at 22:42

With Web traffic, this is becoming more common. Is there a particular scenario you are concerned about? I do not have SNATs reflect all my DNATs.

Scenarios I care about..

  • I separate the SNAT on office/development traffic.
  • I make sure the DNAT and the SNAT match for the MX and all outgoing MTA.

From what I understand, the rule of thumb is to avoid it when reasonably possible. But with modern implementations and dynamic routing I believe this perspective is becoming more obsolete.

  • Well there are two routers where each are connected to each other, and each is connected to the internet. There are public address which will be NATed to address on a LAN which exists on both routers as well. So in the end traffic arrives on either Internet interface. There are then multiple paths it can take, it can go the LAN on the same router, or cross over and go to the LAN via the other router. Then the reply can basically go out the same router or cross over. The result is there are lot of possible paths :-) Jul 26, 2010 at 17:08
  • It could even arrive on WAN on Router A, cross over to Router B for LAN. The reply could enter on the LAN on Router A, and then exit Router B. Whatever path it takes, the NAT translation need to work both ways. Jul 26, 2010 at 17:14
  • Are you asking if asymmetric routing is okay or are you trying to get the routing to be symmetric?
    – Warner
    Jul 26, 2010 at 17:25
  • Trying to make it work while it is asymmetric Jul 26, 2010 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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