All of lore.kernel.org
 help / color / mirror / Atom feed
From: <imnozi@gmail.com>
To: Joshua Moore <j@jcm.me>
Cc: netfilter-devel@vger.kernel.org,
	Reindl Harald <h.reindl@thelounge.net>,
	"Kevin P. Fleming" <lists.netfilter@kevin.km6g.us>,
	netfilter@vger.kernel.org
Subject: Re: How to configure "full cone" NAT using iptables
Date: Tue, 16 May 2023 14:36:18 -0400	[thread overview]
Message-ID: <20230516143618.6ad67810@playground> (raw)
In-Reply-To: <F42FAE74-FDFE-4DC8-896A-2CFBDCCB6D84@jcm.me>

Would an example of full cone NAT be the following?
  - Site A uses 192.168.100.0/24 internally
  - Site B uses 192.168.100/0/24 internally
  - There is a VPN between the two sites
  - Site A addresses hosts at Site B using 10.168.255.0/24
  - Site B addresses hosts at Site A using 10.168.1.0/24
  - Site A SNATs packets sent from 192.168.100.0/24 to 10.168.1.0/24, and Site B
    DNATs packets sent to 10.168.255.0/24 to 192.168.100.0/24
  - Site B SNATs packets sent from 192.168.100.0/24 to 10.168.255.0/24, and Site A
    DNATs packets sent to 10.168.1.0/24 to 192.168.100.0/24

The result is that packets at either site have a 192.* and a 10.* address, and packets in transit between the sites have only 10.* addresses. In short, each site uses the same LAN address and cannot ordinarily exchange packets using normal packet routing. But they *are* able to exchange packets by using full-cone NAT to translate their addresses to and from intermediary LAN addresses.

Full cone NAT allows Linux to do the impossible right away.

N


On Tue, 16 May 2023 07:59:40 -0700
Joshua Moore <j@jcm.me> wrote:

> Full cone isn’t about accepting incoming connections on the same public IP:port and then translating to different local IPs. This is a misunderstanding. It’s about accepting connections from different REMOTE IPs and allowing it to the same local IP on the same original source port.
> 
> The practical purpose here is for a more transparent connection and allowing NAT pinholes to poke a hole through the firewall so any destination on the Internet can now communicate on that port to the host.
> 
> > On May 16, 2023, at 7:48 AM, Reindl Harald <h.reindl@thelounge.net> wrote:
> > 
> > 
> >   
> >> Am 16.05.23 um 16:32 schrieb Joshua Moore:
> >> “Full cone” NAT simply means that there is no longer a strict connection tracking or enforcement of what IPs can connect back to the ports that are associated with the internal IP.
> >> Traditional NAT:
> >> - TCP connection to 1.1.1.1 from 192.168.1.10 over outside translated TCP source port 45619. All packets destined to port 45619 MUST come from 1.1.1.1.
> >> Full cone NAT:
> >> - TCP connection to 1.1.1.1 from 192.168.1.10 over outside translated TCP source port 45619. All packets destined to port 45619 are allowed from ANY IP.
> >> Another word for this behavior is “endpoint independent” NAT/filtering.  
> > 
> > but it can not work like that which don't make any sense:
> > iptables -t nat -A PREROUTING -i eth0 -j DNAT --to-destination 10.0.0.1
> > iptables -t nat -A PREROUTING -i eth0 -j DNAT --to-destination 10.0.0.2
> > 
> > offlist the OP pointed me to https://github.com/Chion82/netfilter-full-cone-nat where i ask myself who needs that nonsense which sounds to be written by someone which hasn't more clues about networking/NAT the the OP
> > 
> > Implementation of RFC3489-compatible full cone SNAT
> > https://www.rfc-editor.org/rfc/rfc3489 = STUN
> >   
> > >> iptables -t nat -A POSTROUTING -o eth0 -j FULLCONENAT
> > >> #same as MASQUERADE  
> > 
> > so who needs that module?
> >   
> > >> iptables -t nat -A PREROUTING -i eth0 -j FULLCONENAT
> > >> #automatically restore NAT for inbound packets  
> > 
> > restore WHAT based on WHAT for new packets?
> > 
> > it's simple: when you only have a single public IP there is no way to accept NEW incoming packets to different local machines without explicit port-forwarding
> > 
> > and ESTABLISHED/RELATED is the job of conntrack
> >   
> >>>> On May 16, 2023, at 4:46 AM, Kevin P. Fleming <lists.netfilter@kevin.km6g.us> wrote:  
> >>> 
> >>> On Tue, May 16, 2023, at 07:07, Shane Wang wrote:  
> >>>> Thanks for your reply.
> >>>> I think the "--to-destination 10.0.0.1" rule will be matched, and the
> >>>> "--to-destination 10.0.0.2" rule will never be matched.
> >>>> Does iptables unsupported "full cone" NAT for multiple internal IP addresses?  
> >>> 
> >>> Does *any* platform support such a configuration? Based on my understanding of what 'full cone' means, every internal address needs a separate external address to be fully mapped to it. Your example shows that you have one external address,   


  parent reply	other threads:[~2023-05-16 18:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16 14:32 How to configure "full cone" NAT using iptables Joshua Moore
2023-05-16 14:48 ` Reindl Harald
2023-05-16 14:59   ` Joshua Moore
2023-05-16 15:11     ` Reindl Harald
     [not found]       ` <CAKbpK3xkw5oryaxGdgFmNyxRpgGsh5OnZXsDEjN9DKaJZqhnsw@mail.gmail.com>
2023-05-16 15:16         ` Reindl Harald
2023-05-16 18:36     ` imnozi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-05-16  9:58 Shane Wang
2023-05-16 10:15 ` Reindl Harald
2023-05-16 11:07   ` Shane Wang
2023-05-16 11:17     ` Reindl Harald
2023-05-16 11:18     ` Kevin P. Fleming

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=20230516143618.6ad67810@playground \
    --to=imnozi@gmail.com \
    --cc=h.reindl@thelounge.net \
    --cc=j@jcm.me \
    --cc=lists.netfilter@kevin.km6g.us \
    --cc=netfilter-devel@vger.kernel.org \
    --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.