3 ms·

> Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in

> Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. Or they are centrally/corporate-controlled and do not allow hole punching.

max-privatevoid 1y ago
You can't disallow hole punching.
- mikepurvis 1y ago
  From TFA: "Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. While most NATs are well-behaved, some aren’t. This is one of the sad facts of life that network engineers have to deal with." In this scenario, the article goes on to describe a convention relay-based approach. I would guess that most consumer routers are very cooperative as far as hole punching because it's pretty critical functionality for bittorrent and many online games. Corporate firewalls wouldn't be as motivated to care about those use-cases or may want to actively block them.
  - embedding-shape 1y ago
    > Corporate firewalls wouldn't be as motivated I think parents point is a bit like "you can't disallow lock picking"; the term "hole punching" being used to describe techniques that are intentionally trying to bypass whatever thing others (particularly corporations) try to put in the way, sometimes for good reasons and sometimes for kind of shit reasons.
- throw0101d 1y ago
  > You can't disallow hole punching. Try doing it over a network that only allows connections through a SOCKS/Squid proxy, or on a network that uses CG-NAT (i.e., double-NAT). See also: > UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint. * https://en.wikipedia.org/wiki/UDP_hole_punching#Overview https://en.wikipedia.org/wiki/UDP_hole_punching#Overview
  - immibis 1y ago
    TCP Simultaneous Open. If two clients happen to connect to each other's ephemeral ports at exactly the same moment, they connect to each other with no server involved. It should work the same as UDP hole punching but with a much smaller time window.
- crote 1y ago
  Why not? Doesn't it depend on the type of NAT used? As I understand it, most consumer devices will set up a port mapping which is completely independent of the destination's IP and port. It's just "incoming packet for $wanip:567 goes to $internal:123, outgoing packet from $internal:123 get rewritten to appear from $wanip:567". This allows any packet towards $wanip:567 to reach the internal host - both the original server the client initiated the connection to, and any other random host on the internet. Do this on two clients, have the server tell them each other's mappings, and they can do P2P comms: basic hole punching. I believe this is usually called "Full Cone NAT". However, nothing is stopping you from setting up destination-dependent mapping, where it becomes "incoming packet from $server:443 to $wanip:456 goes to $internal:123, outgoing packet from $internal:123 to $server:443 gets rewritten to appear from $wanip:567". This would still work totally fine for regular client-to-server communication, but that mapping would only work for that specific server. A packet heading towards $wanip:456 would get dropped because the source isn't $server:443 - or it could even get forwarded to another host on the NATed network. This would block traditional hole punching. I believe this is called "Address Restricted Cone NAT" if it filters only on source IP, or "Port Restricted Cone NAT" if it filters on both source IP and source port.
  - toast0 1y ago
    If your NAT allows arbitrary connections out, and you're patient enough, you can probably finagle a peer to peer connection, eventually. Here's a discussion about that [1]. But that math is based on each NAT having a single external address; if your NAT spreads you over multiple addresses, the math gets much worse. And there's a lot of other considerations; chances are your NAT won't be happy if you send all those probe packets at once, and your user may not be either. It's probably only worth it to do exhaustive probing if the connection is long lived, and proxying is expensive (in dollars because of bandwidth or in latency) [1] https://github.com/danderson/nat-birthday-paradox/tree/master https://github.com/danderson/nat-birthday-paradox/tree/maste...
    - zamadatix 1y ago
      The feasibility of this assumes one peer is always behind an endpoint dependent mapping. That's great if you only care about peers working with you and you control your style of NAT, but it's still pretty broken for the case you want this to work for any 2 peers. In practical terms, the success rate goes from something like the 64% with 256 probes down to something less than 0.01%. If you can manage to bump it up to 65536 probes without getting blocked, hitting a NAT limit, or causing the user to fall asleep waiting, then it should hit the same success rate :D. I'm not sure many would like to use that P2P service though, at that point just pay for the TURN server.
ekropotin 1y ago
Isn’t a concept of TURN server from RFC 5766 a solution for this problem?
- zamadatix 1y ago
  TURN means it's no longer P2P: > Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) > Abstract > If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.
  - r9295 1y ago
    It really depends on the implementation? From my understanding, WebRTC uses it to broker the connection and nothing more. Then it's p2p
    - zamadatix 1y ago
      The "The Traditional Way" section of the article covers the shortcomings of the WebRTC approach (i.e. ICE) and why it does not always result in a P2P session forming/the TURN server leaving the picture. The tldr is having a TURN server enables more hole-punching methods to be attempted, but that's not the same thing as a guarantee the session will succeed in switching to P2P.
tbocek 1y ago
UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. In that spirit, we are currently exploring this with: https://github.com/tbocek/qotp https://github.com/tbocek/qotp and https://github.com/qh-project/qh https://github.com/qh-project/qh The main idea is to have a simple encryption (ed25519/chacha20+poly1305) for encryption in the transport layer, on top of that then qh, where certs are use for signing content. With out of band key exchange, you can establish a connection after you successfully punched a hole. However, its not QUIC compatible in any way (https://xkcd.com/927 https://xkcd.com/927)
- Imustaskforhelp 1y ago
  the https://github.com/qh-project/qh https://github.com/qh-project/qh link doesn't work for what its worth.
- jcelerier 1y ago
  > UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. ... how does that work when the network disallows UDP altogether?
  - octoberfranklin 1y ago
    That is not as common as you think, and will get less common as QUIC grows in popularity. If you're really really desperate you can send UDP packets with fake TCP headers (i.e. you aren't actually doing any congestion control or retransmission) but you have to control both ends of the connection for that. And there's ICMP.
    - bnjms 1y ago
      Blocking UDP to Outside and non-ping udp to Outside is common. It will remain common as long as servers fall back. And exceptions will be made for problem domains.
- throw0101d 1y ago

max-privatevoid 1y ago

You can't disallow hole punching.

mikepurvis 1y ago
From TFA: "Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. While most NATs are well-behaved, some aren’t. This is one of the sad facts of life that network engineers have to deal with." In this scenario, the article goes on to describe a convention relay-based approach. I would guess that most consumer routers are very cooperative as far as hole punching because it's pretty critical functionality for bittorrent and many online games. Corporate firewalls wouldn't be as motivated to care about those use-cases or may want to actively block them.
- embedding-shape 1y ago
  > Corporate firewalls wouldn't be as motivated I think parents point is a bit like "you can't disallow lock picking"; the term "hole punching" being used to describe techniques that are intentionally trying to bypass whatever thing others (particularly corporations) try to put in the way, sometimes for good reasons and sometimes for kind of shit reasons.
throw0101d 1y ago
> You can't disallow hole punching. Try doing it over a network that only allows connections through a SOCKS/Squid proxy, or on a network that uses CG-NAT (i.e., double-NAT). See also: > UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint. * https://en.wikipedia.org/wiki/UDP_hole_punching#Overview https://en.wikipedia.org/wiki/UDP_hole_punching#Overview
- immibis 1y ago
  TCP Simultaneous Open. If two clients happen to connect to each other's ephemeral ports at exactly the same moment, they connect to each other with no server involved. It should work the same as UDP hole punching but with a much smaller time window.
crote 1y ago
Why not? Doesn't it depend on the type of NAT used? As I understand it, most consumer devices will set up a port mapping which is completely independent of the destination's IP and port. It's just "incoming packet for $wanip:567 goes to $internal:123, outgoing packet from $internal:123 get rewritten to appear from $wanip:567". This allows any packet towards $wanip:567 to reach the internal host - both the original server the client initiated the connection to, and any other random host on the internet. Do this on two clients, have the server tell them each other's mappings, and they can do P2P comms: basic hole punching. I believe this is usually called "Full Cone NAT". However, nothing is stopping you from setting up destination-dependent mapping, where it becomes "incoming packet from $server:443 to $wanip:456 goes to $internal:123, outgoing packet from $internal:123 to $server:443 gets rewritten to appear from $wanip:567". This would still work totally fine for regular client-to-server communication, but that mapping would only work for that specific server. A packet heading towards $wanip:456 would get dropped because the source isn't $server:443 - or it could even get forwarded to another host on the NATed network. This would block traditional hole punching. I believe this is called "Address Restricted Cone NAT" if it filters only on source IP, or "Port Restricted Cone NAT" if it filters on both source IP and source port.
- toast0 1y ago
  If your NAT allows arbitrary connections out, and you're patient enough, you can probably finagle a peer to peer connection, eventually. Here's a discussion about that [1]. But that math is based on each NAT having a single external address; if your NAT spreads you over multiple addresses, the math gets much worse. And there's a lot of other considerations; chances are your NAT won't be happy if you send all those probe packets at once, and your user may not be either. It's probably only worth it to do exhaustive probing if the connection is long lived, and proxying is expensive (in dollars because of bandwidth or in latency) [1] https://github.com/danderson/nat-birthday-paradox/tree/master https://github.com/danderson/nat-birthday-paradox/tree/maste...
  - zamadatix 1y ago
    The feasibility of this assumes one peer is always behind an endpoint dependent mapping. That's great if you only care about peers working with you and you control your style of NAT, but it's still pretty broken for the case you want this to work for any 2 peers. In practical terms, the success rate goes from something like the 64% with 256 probes down to something less than 0.01%. If you can manage to bump it up to 65536 probes without getting blocked, hitting a NAT limit, or causing the user to fall asleep waiting, then it should hit the same success rate :D. I'm not sure many would like to use that P2P service though, at that point just pay for the TURN server.

ekropotin 1y ago

Isn’t a concept of TURN server from RFC 5766 a solution for this problem?

zamadatix 1y ago
TURN means it's no longer P2P: > Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) > Abstract > If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.
- r9295 1y ago
  It really depends on the implementation? From my understanding, WebRTC uses it to broker the connection and nothing more. Then it's p2p
  - zamadatix 1y ago
    The "The Traditional Way" section of the article covers the shortcomings of the WebRTC approach (i.e. ICE) and why it does not always result in a P2P session forming/the TURN server leaving the picture. The tldr is having a TURN server enables more hole-punching methods to be attempted, but that's not the same thing as a guarantee the session will succeed in switching to P2P.

tbocek 1y ago

UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. In that spirit, we are currently exploring this with: https://github.com/tbocek/qotp https://github.com/tbocek/qotp and https://github.com/qh-project/qh https://github.com/qh-project/qh The main idea is to have a simple encryption (ed25519/chacha20+poly1305) for encryption in the transport layer, on top of that then qh, where certs are use for signing content. With out of band key exchange, you can establish a connection after you successfully punched a hole. However, its not QUIC compatible in any way (https://xkcd.com/927 https://xkcd.com/927)

Imustaskforhelp 1y ago
the https://github.com/qh-project/qh https://github.com/qh-project/qh link doesn't work for what its worth.
jcelerier 1y ago
> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. ... how does that work when the network disallows UDP altogether?
- octoberfranklin 1y ago
  That is not as common as you think, and will get less common as QUIC grows in popularity. If you're really really desperate you can send UDP packets with fake TCP headers (i.e. you aren't actually doing any congestion control or retransmission) but you have to control both ends of the connection for that. And there's ICMP.
  - bnjms 1y ago
    Blocking UDP to Outside and non-ping udp to Outside is common. It will remain common as long as servers fall back. And exceptions will be made for problem domains.
throw0101d 1y ago