All of lore.kernel.org
 help / color / mirror / Atom feed
From: zrm <zrm@trustiosity.com>
To: Robert White <rwhite@pobox.com>,
	oyvind@dynator.no, netfilter@vger.kernel.org
Subject: Re: Full NAT forward and source routing - possible without packet marking?
Date: Sat, 1 Jul 2017 18:17:07 -0400	[thread overview]
Message-ID: <ea023673-d0c6-f8d8-0399-203a71e7fa62@trustiosity.com> (raw)
In-Reply-To: <4c60ba2e-3e52-f55d-96e1-699c7821940d@pobox.com>

On 07/01/2017 04:26 PM, Robert White wrote:
> So, for instance, once you DNAT the incoming packet you _don't_ want to
> SNAT it.

What about hairpin NAT?

Suppose you have a port mapping from the router's public IP (2.2.2.2) to 
some private IP on the LAN (10.2.2.2). Then 2.2.2.2 is published in a 
rendezvous server and some other device (10.2.2.3) on the same LAN 
segment learns that address and opens a connection.

Now you need the SNAT rule, otherwise the router would translate the 
packet for 2.2.2.2 to 10.2.2.2 and 10.2.2.2 would send its response to 
10.2.2.3. 10.2.2.3 is local so it doesn't pass through the router to be 
translated back and the connection fails because 10.2.2.3 is expecting a 
response from 2.2.2.2 rather than 10.2.2.2.

It would obviously be better for the applications to use the private 
addresses directly but you might not be in control of that.

So you need to know the in-interface or similar because you should only 
do the SNAT for hairpin if the client is internal.

The interesting question is whether that can be done without marking.

  reply	other threads:[~2017-07-01 22:17 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 [this message]
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
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=ea023673-d0c6-f8d8-0399-203a71e7fa62@trustiosity.com \
    --to=zrm@trustiosity.com \
    --cc=netfilter@vger.kernel.org \
    --cc=oyvind@dynator.no \
    --cc=rwhite@pobox.com \
    /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.