Hi,


I have the following rule to forward packets coming externally from server A to external server B.

I have the following rule to do this for me.

iptables -t nat -A PREROUTING -p tcp --dport <server_a_port> -j DNAT --to-destination <server_b_ip>:<server_b_port>
iptables -t nat -A POSTROUTING -j MASQUERADE

It works fine with one exception: the source IP coming into server B is changed to that of server A. Is there a way to do this without changing the external source IP - i.e. I want server B to see the same source IP that comes into server A.

I tried doing:

iptables -t nat -A POSTROUTING -j ACCEPT

...but it didn't work.

Comments/ideas?

Thanks in advance.

just remove the MASQUERADE entry completely. The NAT table doesn't accept or deny packets, that's the FILTER table. Just don't NAT it at all.

If I remove it completely then the forwarding doesn't work. That is I cannot connect to server B through server A. I have to add the MASQUERADE entry for it to work.

I have tried this without having any other entries in the table.

No, you don't. The POSTROUTING table is after the forwarding has been done. It's already been routed by that stage.

if you tcpdump on the outbound interface, does the packet not show up?

Actually it does, but on server B it seems like it's trying to return the reply packet directly to the source IP. And since it connected to server A, the client is expecting a reply from server A, not server B.

I guess that's why you need a MASQUERADE (or SNAT) rule.

Am I correct in thinking about this? Can I add some additional rules on server B to return packets via server A back to the client?

Well yes, that's what IP routing is. That's the exact specific precise reason NAT exists!

This presumably IS a routed network with DIFFERENT address ranges? What do you mean by "direct" here? That suggests it's on the local subnet... the return route is usually defined by the stateless routing table on the destination host, so you would usually identify the sub-range of addresses that need to go back via this intermediate devices and put that in the routing table.

Yes, server A and server B are on different networks - both external.

Right, so how do I do that? Let's say server A is 1.1.1.1, server B is 2.2.2.2. What is happening with the packet at the moment is:

Incoming packet:
1.2.3.4 (source IP) >>> 1.1.1.1 (server A) >>> 1.2.3.4 source is changed to 1.1.1.1 >>> 2.2.2.2 (server B)

Reply back:
2.2.2.2 (server B) >>> 1.1.1.1 (server A) >>> 1.2.3.4

Without SNAT - incoming packet
1.2.3.4 (source IP) >>> 1.1.1.1 (server A) >>> 1.2.3.4 source IP is not changed >>> 2.2.2.2 (server B)

Reply back:
2.2.2.2 (server B) >>> 1.2.3.4 ...bypassing server A. Therefore the packet never reaches the initiating client.

And I want it like so - incoming packet:
1.2.3.4 (source IP) >>> 1.1.1.1 (server A) >>> 1.2.3.4 source IP is not changed >>> 2.2.2.2 (server B)

Reply back:
2.2.2.2 (server B) >>> 1.1.1.1 (server A) >>> 1.2.3.4

If I was to set up a route, then that means ALL packets going out of server B would go via server A. I don't want that - I only want packets going out via server A if they came in via server A. Is there a way to do that using IP tables?

You should stick with MASQUERADE. There are ways to do it, using iptables to force packets to use alternative routing tables, but those solutions just end up hacky and obscure. This might be of interest to you though... http://parkersamp.com/2010/02/howto-...vlan-in-linux/ Again, I would try to avoid this kind of meddling though.

Fair enough. I thought it was getting a little complicated but if there's a simpler way of doing this, I'd love to hear.

Thanks for your help so far, Chris.

Alex

Just been reading about it. Looks like I can mark forwarded packets and using the marks route them back using different routing tables (like you said). Seems a little complicated for my little brain though.

See, now I spend all day working with F5 BigIP load balancers and they just have a lovely tick box in the config called "auto last hop" which ensures that all traffic coming in to a given service goes back on the network with the MAC of the device it came from, totally ignoring the routing tables, which is clearly exactly what you want. Not sure what's actually going on under the hood for that. I think it's probably bespoke code, not iptables or anything not generically Linux. So if you want to spend $100,000 on a pair of BigIP's it's a doddle!

Hah, I am not that desperate to see the source IP - as nice as it would have been. For $100,000 I will learn ip routes and iptables - but again, it's not essential.

But yes, it looks like exactly the thing I would need.