Saturday, December 24, 2005
More on Hamachi's NAT traversal
Last time I talked about Hamachi, I posted the method that people assumed Hamachi was using for NAT traversal. It seems that UDP punching, which is already used in other apps like Skype, isn't anything new. It also only gets about an 80% success rate for the reason that a comment to my last post suggested: Some firewalls and NAT devices don't like having their UDP streams redirected from the mediation server to eachother. This also, it turns out, is not the method that Hamachi uses (Hamachi gets something like a 95 to 97 percent success rate, not 80).
The latest hypothesis about how Hamachi does it is via synchronised connections. The idea is that the mediation server would be use to synchronize the two computers to have them send UDP packets to eachother as close to simultaneously as possible. Presumably the mediation server synchronizes the clients, the clients then send UDP packets to the mediation server, the mediation server figures out what kind of NAT is being used to determine what public UDP ports will be opened when the clients send data to eachother. The clients are then instructed to send UDP packets to eachother at exactly (or close enough) the same time to the ports that are expected to be open.
Each client sends a UDP packet, which results in (hopefully) the guessed port being opened in expectation of return data. Since the packets are sent at the same time, the port should be open by the time each packet eventually arrives at its destination.
This concept is similar the the STUN protocol, but a bit different.
The thing is, this is how people GUESS Hamachi does it. The author of Hamachi won't tell because his business model relies on keeping the protocol under wraps. It is unfortunate, since 97% effective NAT traversal would be a big improvement over current techniques, and would really benefit the public.
The latest hypothesis about how Hamachi does it is via synchronised connections. The idea is that the mediation server would be use to synchronize the two computers to have them send UDP packets to eachother as close to simultaneously as possible. Presumably the mediation server synchronizes the clients, the clients then send UDP packets to the mediation server, the mediation server figures out what kind of NAT is being used to determine what public UDP ports will be opened when the clients send data to eachother. The clients are then instructed to send UDP packets to eachother at exactly (or close enough) the same time to the ports that are expected to be open.
Each client sends a UDP packet, which results in (hopefully) the guessed port being opened in expectation of return data. Since the packets are sent at the same time, the port should be open by the time each packet eventually arrives at its destination.
This concept is similar the the STUN protocol, but a bit different.
The thing is, this is how people GUESS Hamachi does it. The author of Hamachi won't tell because his business model relies on keeping the protocol under wraps. It is unfortunate, since 97% effective NAT traversal would be a big improvement over current techniques, and would really benefit the public.
