5 ms·

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

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

blueflow 2y ago
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
justsomehnguy 2y ago
I hate to be that guy, but: there is no 'deny' action in NAT.
- acdha 2y ago
  Resist the urge to be that guy. There actually is a deny: it’s what your NAT system does when an incoming packet doesn’t match a connection initiated by a device behind it. 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?”
  - justsomehnguy 2y ago
    > There actually is a deny 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.
- detuur 2y ago
  NAT essentially has a "default deny" rule.
throw0101a 2y ago
> 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 https://en.wikipedia.org/wiki/Stateful_firewall [2] https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol [3] https://en.wikipedia.org/wiki/Hole_punching_(networking) https://en.wikipedia.org/wiki/Hole_punching_(networking)

blueflow 2y ago

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

justsomehnguy 2y ago

I hate to be that guy, but: there is no 'deny' action in NAT.

acdha 2y ago
Resist the urge to be that guy. There actually is a deny: it’s what your NAT system does when an incoming packet doesn’t match a connection initiated by a device behind it. 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?”
- justsomehnguy 2y ago
  > There actually is a deny 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.
detuur 2y ago
NAT essentially has a "default deny" rule.

throw0101a 2y ago

> 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 https://en.wikipedia.org/wiki/Stateful_firewall [2] https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol [3] https://en.wikipedia.org/wiki/Hole_punching_(networking) https://en.wikipedia.org/wiki/Hole_punching_(networking)