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,
