Pascal Hambourg wrote:
Le 02/07/2017 à 12:33, Robert White a écrit :
On 07/02/2017 07:29 AM, Pascal Hambourg wrote:
Le 01/07/2017 à 22:26, Robert White a écrit :
I think you missed the point and focused on an irrelevant detail in the
OP. This topic is about advanced routing.
Read the OP again. Traffic is coming in on ppp0, hitting a server
hanging off eth1, and then the replies are supposed to go back to eth1
and go out on ppp0.
There is literally no simpler task in DNAT.
This was not an "advanced routing" question, this was an "introduction
to DNAT" level question.
Again, you missed the important point : reply packets must go out
through ppp0 but the default route is through eth0, not ppp0. Without
advanced routing, reply packets will go out through eth0.
First, let me say I'm very grateful to all of you that has taken the
time to answer me, and I will study the rather comprehensive replies in
detail. I'm clearly no expert, but I'm trying to learn so the
information is appreciated.
To perhaps clarify a few things:
My device is not meant to be a system (or full blown) router per se. It
is a specialized custom device that for some cases needs to be able to
act as a router. It does not act as a DNS server, and in most cases
there will be other routers in the system (at least on the eth0 network,
and my device is usually set up as a DHCP client on eth0).
The device behind eth1 is not guaranteed to have my device as it's
default route (in fact it will most likely not), which is why I believe
I need SNAT/masquerading to have it send the replies back to my device.
But for the sake of argument, let's assume that the device will send the
replies back to my device at eth1 even with SNAT off. I'll try to use an
example with fictious IP-addresses to clarify:
Assume ppp0 has an address of 10.10.10.10
Assume eth0 has an address of 192.168.10.10
Assume eth1 has an address of 192.168.100.100
Assume the device behind eth1 has an address of 192.168.100.200
Say that I want to forward inbound (UDP or TCP) traffic destined for
10.10.10.10:1111 to 192.168.100.200:1111, so I add a DNAT rule for that.
Then when a packet comes in on ppp0 from 100.100.100.100:2222, and my
DNAT-rule rewrites the destination address to 192.168.100.200:1111. This
packet then leaves eth1 for the device, and the device replies. Without
SNAT, the addresses in the reply are:
Dst: 100.100.100.100:2222
Src: 192.168.100.200:1111
The packet is then routed, and after the routing decision the DNAT is
reversed, so when the packet actually leaves my device, it has these
addresses:
Dst: 100.100.100.100:2222
Src: 10.10.10.10:1111
However, since the routing decision is made *before* the source address
has been rewritten, this packet leaves out eth0, where it is lost.
If I have SNAT/masquerading, the reply from the device has these addresses:
Dst: 192.168.100.100:2222
Src: 192.168.100.200:1111
The SNAT is then reversed for the packet:
Dst: 100.100.100.100:2222
Src: 192.168.100.200:1111
And now the routing happens, but again the packet takes the default
route out eth0 and is lost.
In none of these cases my source routing rule is hit, because the source
address of my ppp0 device is not being rewritten until *after* the
routing decision has been made.
I could of course add a explicit source routing rule for any packets
coming from the external device to go out ppp0, but that's undesirable,
because I also want to allow incoming traffic on eth0 to talk to this
device (again using DNAT/port forwarding). In this case the replies will
work without any special routing rules, since eth0 is in fact the
default route.
Not sure if this clarified anything, but it still seems to me I need to
leverage the connection tracking with packet marking to be able to
ensure the reply packets that should go back out a non-default route
actually does that.
--
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
