> disabling NAT results in "exposed" LAN devices
"In theory, theory and practice are the same. In practice, they are not."
NAT was used as a blocking method for all incoming connections for SOHO networks for decades.
"In theory, theory and practice are the same. In practice, they are not."
NAT was used as a blocking method for all incoming connections for SOHO networks for decades.
And so have stateful/SPI firewalls,[1] and with those you don't need the convoluted rigamarole of STUN/TURN/ICE infrastructure: a whole class of technology that had to be invented to deal with NAT.
Meanwhile, if you have globally addressable (but not necessarily globally reachable) IPv6 on your clients all of that goes away, and it's just PCP [2][3] that's needed to hole punch on your CPE. Much less convoluted.
[1] https://en.wikipedia.org/wiki/Stateful_firewall
[2] https://en.wikipedia.org/wiki/Port_Control_Protocol
[3] https://en.wikipedia.org/wiki/Hole_punching_(networking)
Good luck gaming then, or using BitTorrent (and probably other services). All consumer CPEs support PCP/UPnP for 'dynamic punching'.
And if the app in question doesn't use PCP/UPnP, then you have to stand up an entire STUN/TURN/ICE infrastructure.
Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.
That action creates a public side mapping on the NAT, being Proto/IP/Port - Proto generally being TCP or UDP.
While that mapping exists, any packet within that protocol, from any source address or port in the whole IPv4 Internet can be directed at that mapping, and received by the client computer.
Generally TCP syn's will be dropped by the client (unless they explicitly opened a fixed mapping, and are hence running a TCP server), but any UDP packet for an open UDP mapping will be received.
AFAIK, the various gaming programs tend to run over UDP...
The punching per-se is to coordinate between two clients, each behind NATs, and/or each behind actual firewalls (as opposed to the NAT filtering function).
That is not what is meant by "hole punching":
> Networked devices with public or globally accessible IP addresses can create connections between one another easily. Clients with private addresses may also easily connect to public servers, as long as the client behind a router or firewall initiates the connection. However, hole punching (or some other form of NAT traversal) is required to establish a direct connection between two clients that both reside behind different firewalls or routers that use network address translation (NAT).
* https://en.wikipedia.org/wiki/Hole_punching_(networking)
* https://en.wikipedia.org/wiki/Port_Control_Protocol
* https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...
If those applications want to be reached over the network, they can use Hole Punching to turn what would otherwise be an inbound connection into an outbound one. But that requires an effort on both ends of the conversation: if I want a remote client with IP 1.2.3.4 to connect to my server that's behind a NAT, then my server first needs to send a packet to 1.2.3.4. (That's the hole that's punched.) But that doesn't change anything about the reliability of the NAT's protection, because other clients on the internet still can't reach my server. If 1.2.3.4 is not malicious, then nothing bad can happen here. If 1.2.3.4 is malicious, then I was already in trouble when I punched the hole in the NAT, before an inbound connection from 1.2.3.4 even arrives - simply because I created an outgoing connection to 1.2.3.4, over which they could have sent me exploits anyway.
I know you know all of this, but I wanted to add some context to your misleading and pedantic comment for other readers of this thread.
i.e. assume 192.168.0.1:4567 sends a packet to 12.13.14.15:25, creating a mapping, and keeping that mapping session active. Assume the public translation for that client is 5.6.7.8:7777
Now anyone, e.g. 23.24.25.26:7654 can send a packet to 5.6.7.8:7777 and it will be received by 192.168.0.1:4567.
That behaviour is what is relied upon in order to make the NAT hole punching work.
It is only 5-tuple stateful firewall punching (of ADPF NAT - which are uncommon) which require that the return packets come from a target punched first. Hence needing the coordinated punching from both sides to the public address:port mapping of the peer.
However, continue with your belief...
This is a new and unfamiliar term/acronym to me. It seems to be from RFC 7857, "Updates to Network Address Translation (NAT) Behavioral Requirements":
* https://datatracker.ietf.org/doc/html/rfc7857
People may be more familiar with the various "cone" NAT variation definitions:
So once the BEHAVE terms came out, I adopted them, as they were (at least to me) more obvious. They're also more flexible in that they can describe real behaviours which can not be mapped to "cone" terms.
It is the state tracking that does the protection, which you do not need NAT to do:
* https://en.wikipedia.org/wiki/Firewall_(computing)#Connectio...
* https://en.wikipedia.org/wiki/Stateful_firewall
And by getting rid of NAT, you also remove the need for the convoluted bullshit of STUN/TURN/ICE, and all you're left with is PCP:
Trying to be pedantic about this isn’t adding anything to the conversation – people have been trying to make this seem like a useful distinction for decades but it’s never worked because anyone who cares about security is focused on “can an attacker initiate a connection to my system?” rather than “did I lovingly handcraft the packet filtering rule which dropped their attempt?”
If you don't have NAT:
- the packet with your IP in dst_ip would be thrown out
If you do have NAT:
- the packet with your IP in dst_ip would be thrown out
In both cases the decision to drop the packet were carried out by the firewall and not NAT.
So puh-lease, stop.