All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Øyvind Kaurstad" <oyvind@dynator.no>
To: netfilter@vger.kernel.org
Subject: Re: Full NAT forward and source routing - possible without packet marking?
Date: Sun, 2 Jul 2017 17:58:01 +0200	[thread overview]
Message-ID: <e5a4184c-19db-7d36-f247-7e7bfe235e50@dynator.no> (raw)
In-Reply-To: <f297920c-6ca4-d912-a870-099c24674bcc@plouf.fr.eu.org>

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.


  reply	other threads:[~2017-07-02 15:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-30 13:55 Full NAT forward and source routing - possible without packet marking? Øyvind Kaurstad
2017-07-01 10:05 ` Pascal Hambourg
2017-07-01 20:26 ` Robert White
2017-07-01 22:17   ` zrm
2017-07-01 23:50     ` Robert White
2017-07-03 18:07       ` Hairpin NAT " zrm
2017-07-04  1:14         ` Robert White
2017-07-04  5:48           ` K
2017-07-04  7:07             ` Neal P. Murphy
2017-07-04 10:21               ` Robert White
2017-07-04 20:53           ` Pascal Hambourg
2017-07-04 21:20             ` Neal P. Murphy
2017-07-05  5:28             ` Robert White
2017-07-08 19:54           ` zrm
2017-07-08 21:55             ` Robert White
2017-07-02  7:29   ` Full NAT forward and source routing " Pascal Hambourg
2017-07-02 10:33     ` Robert White
2017-07-02 11:19       ` Pascal Hambourg
2017-07-02 15:58         ` Øyvind Kaurstad [this message]
2017-07-02 17:10           ` Pascal Hambourg
2017-07-02 23:20             ` Øyvind Kaurstad
2017-07-02 21:10           ` Robert White
2017-07-02 23:09             ` Øyvind Kaurstad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5a4184c-19db-7d36-f247-7e7bfe235e50@dynator.no \
    --to=oyvind@dynator.no \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.