4 ms·

It cannot work reliably, that's why Hole Punching is a thing.

mschuster91 2y ago
It's enough to keep the Shodan skiddies at bay. I distinctly 'member the modem/ISDN era and trolls shooting off unpatched machines of other gamers. In ye olde days remote RCE exploits were a regular issue...
vachina 2y ago
If you don’t punch there’s no hole.
- throw0101d 2y ago
  > If you don’t punch there’s no hole. 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.
  - LargoLasskhyfv 2y ago
    One does NOT play with https://en.wikipedia.org/wiki/Phencyclidine https://en.wikipedia.org/wiki/Phencyclidine !1!!
  - vachina 2y ago
    Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole. Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.
    - dfawcus 2y ago
      The nature of an EIM/EIF NAT is that the hole exists without punching, as soon as the device behind the NAT connects to anywhere public. 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).
    - throw0101a 2y ago
      > Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole. 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/Hole_punching_(networking) * https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol * https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...
- deleted 2y ago
  [deleted]
indigo945 2y ago
No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them. 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.
- blueflow 2y ago
  "Applications" including malicious javascript in your browser.
- dfawcus 2y ago
  Nope, the hole created in the NAT is generally endpoint independent. It does not matter what the target is, anyone can now send packets to that mapping. 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.
  - 2y ago

It's enough to keep the Shodan skiddies at bay. I distinctly 'member the modem/ISDN era and trolls shooting off unpatched machines of other gamers. In ye olde days remote RCE exploits were a regular issue...

vachina 2y ago

If you don’t punch there’s no hole.

throw0101d 2y ago
> If you don’t punch there’s no hole. 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.
- LargoLasskhyfv 2y ago
  One does NOT play with https://en.wikipedia.org/wiki/Phencyclidine https://en.wikipedia.org/wiki/Phencyclidine !1!!
- vachina 2y ago
  Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole. Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.
  - dfawcus 2y ago
    The nature of an EIM/EIF NAT is that the hole exists without punching, as soon as the device behind the NAT connects to anywhere public. 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).
  - throw0101a 2y ago
    > Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole. 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/Hole_punching_(networking) * https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol * https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...
deleted 2y ago
[deleted]

indigo945 2y ago

No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them. 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.

blueflow 2y ago
"Applications" including malicious javascript in your browser.
dfawcus 2y ago
Nope, the hole created in the NAT is generally endpoint independent. It does not matter what the target is, anyone can now send packets to that mapping. 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.
- 2y ago