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.

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  --  *      *       0.0.0.0/0            12.12.12.5         to:10.7.0.5 

Chain POSTROUTING (policy ACCEPT 288 packets, 18672 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 SNAT       all  --  *      eth0    10.7.0.5             0.0.0.0/0           to:12.12.12.5 
    0     0 SNAT       all  --  *      eth3    10.7.0.5             0.0.0.0/0           to:12.12.12.5 
    8   550 MASQUERADE  all  --  *      eth0    172.16.14.0/30       0.0.0.0/0           
    0     0 MASQUERADE  all  --  *      eth0    10.7.0.0/24          0.0.0.0/0           

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 12.12.12.5 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 10.7.0.5 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...

share|improve this question
1  
Do the DNAT then SNAT to the address on the interface on which the traffic is departing. –  topdog Jul 26 '10 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. –  Kyle Brandt Jul 26 '10 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 :-) –  Kyle Brandt Jul 26 '10 at 21:35
add comment

2 Answers

up vote 1 down vote accepted

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).

share|improve this answer
    
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. –  Kyle Brandt Jul 26 '10 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. –  Evan Anderson Jul 26 '10 at 20:48
    
@Evan: Well updated it with NAT tables and explanation of the context they fit in which should help... –  Kyle Brandt Jul 26 '10 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. –  Evan Anderson Jul 26 '10 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 ... –  Kyle Brandt Jul 26 '10 at 22:42
show 5 more comments

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.

share|improve this answer
    
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 :-) –  Kyle Brandt Jul 26 '10 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. –  Kyle Brandt Jul 26 '10 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 '10 at 17:25
    
Trying to make it work while it is asymmetric –  Kyle Brandt Jul 26 '10 at 19:25
add comment

Your Answer

 
discard

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.