Re: How to configure "full cone" NAT using iptables

Re: How to configure "full cone" NAT using iptables

[Joshua Moore]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8-sig", Size: 1363 bytes --]

“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.

> 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, which means you can only provide 'full cone' mapping for one internal address, no matter which tool you use.

Re: How to configure "full cone" NAT using iptables

[Reindl Harald]

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, 

Re: How to configure "full cone" NAT using iptables

[Joshua Moore]

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, 

Re: How to configure "full cone" NAT using iptables

[Reindl Harald]

Am 16.05.23 um 16:59 schrieb Joshua Moore:
> 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.

i know that but the OP seems to think it's some magic bullet which makes 
his multiple machines reachable with a single public-ip

see his ruleset which can't work no matter what
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

>> 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

Re: How to configure "full cone" NAT using iptables

[Reindl Harald]

Am 16.05.23 um 17:13 schrieb Joshua Moore:
> Well, looking at it from the *correct* interpretation, is that even 
> possible with IPTABLES as well? Does IPTABLES support a way to relax the 
> connection tracking?

irrelevant - look at the OP

he wants "full cone" without understanding what that means and hence 
there is nothing like a "correct interpretation"

> On Tue, May 16, 2023 at 8:11 AM Reindl Harald <h.reindl@thelounge.net 
> <mailto:h.reindl@thelounge.net>> wrote:
> 
>     Am 16.05.23 um 16:59 schrieb Joshua Moore:
>      > 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.
> 
>     i know that but the OP seems to think it's some magic bullet which
>     makes
>     his multiple machines reachable with a single public-ip
> 
>     see his ruleset which can't work no matter what
>     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
> 
>      >> On May 16, 2023, at 7:48 AM, Reindl Harald
>     <h.reindl@thelounge.net <mailto: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
>     <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
>     <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
>     <mailto: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

Re: How to configure "full cone" NAT using iptables

[imnozi]

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,   

How to configure "full cone" NAT using iptables

[Shane Wang]

Hi folks,

I have found a solution on
https://www.joewein.net/info/sw-iptables-full-cone-nat.htm, which
works fine for a single internal IP address. However, I am struggling
to configure "full cone" NAT for multiple internal IP addresses using
iptables.

I have tried the following rules, but they do not seem to work:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.170
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

Could you please advise me on how to configure "full cone" NAT for
multiple internal IP addresses using iptables? If this is impossible,
are there any alternative solutions to achieve this goal?

Re: How to configure "full cone" NAT using iptables

[Reindl Harald]

Am 16.05.23 um 11:58 schrieb Shane Wang:
> Hi folks,
> 
> I have found a solution on
> https://www.joewein.net/info/sw-iptables-full-cone-nat.htm, which
> works fine for a single internal IP address. However, I am struggling
> to configure "full cone" NAT for multiple internal IP addresses using
> iptables.
> 
> I have tried the following rules, but they do not seem to work:
> 
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.170
> 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

how do you imagine two contradicting rules to work?
roll a dice between 10.0.0.1 and 10.0.0.2?

Re: How to configure "full cone" NAT using iptables

[Shane Wang]

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?

Reindl Harald <h.reindl@thelounge.net> 于2023年5月16日周二 18:15写道：
>
>
>
> Am 16.05.23 um 11:58 schrieb Shane Wang:
> > Hi folks,
> >
> > I have found a solution on
> > https://www.joewein.net/info/sw-iptables-full-cone-nat.htm, which
> > works fine for a single internal IP address. However, I am struggling
> > to configure "full cone" NAT for multiple internal IP addresses using
> > iptables.
> >
> > I have tried the following rules, but they do not seem to work:
> >
> > iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.170
> > 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
>
> how do you imagine two contradicting rules to work?
> roll a dice between 10.0.0.1 and 10.0.0.2?

Re: How to configure "full cone" NAT using iptables

[Reindl Harald]

Am 16.05.23 um 13:07 schrieb Shane Wang:
> 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?

what you want is simply not possible at all - no matter what software

either you have specific port-forwardings or you need different 
public-ips for a 1:1 mapping of all ports

common sense: when you have only one public IP how do you imagine a 
decision for NEW packets and how do you imageine a ruleset working when 
it can't make decisions?

ESTABLISHED/RELATED are different beasts but they don't need forwarding 
at all - conntrack knows where they belong

but for forwarding of NEW packets you need to make rules based on unique 
criteria which you don't have when you don#t use specific portforwarding 
or don#t have a distinct public IP

> Reindl Harald <h.reindl@thelounge.net> 于2023年5月16日周二 18:15写道：
>>
>> Am 16.05.23 um 11:58 schrieb Shane Wang:
>>> Hi folks,
>>>
>>> I have found a solution on
>>> https://www.joewein.net/info/sw-iptables-full-cone-nat.htm, which
>>> works fine for a single internal IP address. However, I am struggling
>>> to configure "full cone" NAT for multiple internal IP addresses using
>>> iptables.
>>>
>>> I have tried the following rules, but they do not seem to work:
>>>
>>> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.170
>>> 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
>>
>> how do you imagine two contradicting rules to work?
>> roll a dice between 10.0.0.1 and 10.0.0.2?

Re: How to configure "full cone" NAT using iptables

[Kevin P. Fleming]

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, which means you can only provide 'full cone' mapping for one internal address, no matter which tool you use.