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@xxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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,
