John Madden a écrit :
The NAT box and the mail server
are on different VLAN's, but that's about all that separates them --
Do you mean that they are in different subnets ?
Sure. But they could easily be on the same subnet.
Ok. That may be useful.
What I want instead is for the NAT box to change the destination
IP to direct the flow to the mail server. I don't care where the reply
traffic goes (back through the NAT box is fine), I just need to maintain
the source IP's
Then do not use SNAT.
(which implies not going back through the NAT, but
rather directly back to the real client)
On the contrary, it implies going back to the NAT, else the reply
traffic arrives at the client with the wrong source address. See Grant's
reply about the triangle ABC.
Imagine troubleshooting Outlook POP3 clients when everyone's coming from
the same IP.... *shudder*...
I'd rather not. :-s
Without SNAT, the mail server could use the NAT box as a gateway at
least for SMTP reply traffic (this could be done with advanced routing
if the mail server runs Linux) if they are in the same subnet or if a
tunnel can be established directly between them.
The box does run Linux, but let's assume it doesn't. I really don't
want to be horking with that machine in this manner.
Ok, then the easiest solution is to put the NAT box and the server in
the same subnet and use the NAT box as the default gateway on the
server. You may have trouble with ICMP "Redirect" messages sent by the
NAT box if its own default gateway is also in the same subnet, but you
can disable them on the NAT box or ignore them on the server.
If the box could just modify the headers to change the destination IP
and drop the packets back on the wire without any change to the source
IP happening, I think I'd be happy.
That's just what DNAT does. The rest is about routing.
-
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
