Hacker News Reader

Comment by ktta | Hacker News Reader

Adam Ierymenko (@api here and reddit) has a modern and concise take on NAT

https://www.zerotier.com/blog/state-of-nat-traversal.shtml

That's still the blog article that gets the most hits. I wrote it in response to someone on HN claiming that "you can't do peer to peer because of NAT" when we were doing it.

There's the standard ways -- hole punching as described there, uPnP/NAT-PMP, etc. -- and then there is a long tail of hacks for getting to that 90%+ success rate you want. Here's an incomplete list:

* Port prediction for symmetric NATs that increment ports

* Creating multiple sockets to work around buggy NATs that can't hole punch if multiple devices have the same local port, etc. There are also buggy NATs where hole punching breaks if you also open a port with NAT-PMP or uPnP. There are a lot of buggy NATs. (Factoid: we have found zero correlation between the cost of a NAT device and its buggitude.)

* Getting the timing as tight as possible -- we use a triangular three-party rendezvous method to try to get it so both sides see a send before the "reply."

* Sending UDP packets with incrementing TTLs ahead of the real hole punch message to open multiple layers of NAT, and randomizing the few-byte payload of those low-TTL packets because some NATs care about this. Yes people plug NATs into NATs into NATs. It's pretty common. Ugh. As long as none are symmetric it works.

* If at first you don't succeed try try again... forever. For long-lived links (common with ZeroTier since they are virtual LANs) if you keep trying and include some random port trials you will eventually punch a symmetric NAT. There are only 65535 ports.

ZeroTier still has to relay though if both parties are behind hostile NATs, but we can provide free relaying for everyone since it's only a small percentage of traffic and cloud bandwidth is cheap.

Edit: there are more sophisticated methods that work more of the time, but those unfortunately can trip intrusion detection systems. We try to walk the line with ZeroTier between high success and not tripping your IDS.

Edit #2: wow there's a lot of outright nonsense on this thread. I continue to be saddened by how few developers (even top notch ones) know so little about networking and have so many misconceptions about it. Networking is still such a black art. Of course if it wasn't maybe there would not be a niche for us. :)

That's a good list of hacks I've come across. But I thought we stopped using the 'symmetric nats' terminology a decade ago when the IETF Behave specification came out? https://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-18 The specification tries to classify Nat behaviour into 3 classes: (1) when a port mapping can be reused (for any outgoing connection, for an outgoing connection to the same IP, for an outgoing connection to the same IP:Port endpoint), (2) what port is allocated when a new mapping is created (same as the private IP if possible, a contiguous port generated by a global counter, or a random port), and (3) how are incoming packets filtered/dropped based on the source IP:port (not filtered, ok from same IP, must be from same IP:port). Most Nats can be described using some combination of these behaviours. See this paper for details: https://www.hivestreaming.com/natcracker-nat-combinations-ma...

Implementing a TCP/IP stack used to be a rite of passage. I think the fact that everything is now layered on top of HTTP is what causes the problems observed in this thread, in a sense HTTP replaced TCP even though it sits at a higher level layer people are shoehorning everything into it because it tends to be passed on transparently if a proxy or some other gateway doesn't know what to do with the payload.

First, Zero Tier is fantastic. Second, there is tons of nonsense here. When I wrote Firestr (http://firestr.com) I used the simplest thing that could work, udp hole punching, and it works most of the time. Zero Tier does even more magic and it just works. P2P is possible, but the art is almost lost. We must keep it alive!

Reading that, I was prompted (translation: nerdsniped) into thinking about the Same Network Problem: how do you identify two machines that are actually on the same LAN and can communicate without NAT, without the risk of revealing any information about your LAN to a third party? (See the article linked above for a fuller explanation of why this is nontrivial.) Here's my plan:

The client enumerates all the machines it can see on its local LAN, and for each one, assembles a list of information about it, probably something like IP address, machine name, assigned user, maybe MAC address, etc. Hash this using SHA256 or something (unlike the suggestion in the ZeroTier article about IP addresses, this approach has enough information that brute force reversal is out of the question). Assemble a list of, say, 20 of these hashes - the client's own hash is first, followed by the rest of the LAN. If you have less than 20 nodes, fill out the list with random numbers; if you have more than 20, include yourself and 19 others at random (it's important that you pick them at random, not just the first 19 in your LAN listing). Send the list to the server - this reveals nothing about your LAN to it.

The server compares the hash lists sent by clients. If any two lists have any hashes in common, send a message to each of the clients that sent those lists: "You seem to be on the same LAN as the client with hash XYZ." The client can then look up the hash in its local table, and try to contact the corresponding node. (The list intersection check is why it's important to pick your sample at random - the birthday paradox is now working for us, and there's a good chance of at least one match even if your LAN has hundreds of nodes.)

Reply on news.ycombinator.com