Hamachi

The virtual private networking system

Hamachi emulates LAN over the Internet.

It allows arranging multiple computers into a private network that functions just as if these computers were connected by a physical network cable and it requires virtually no manual configuration in the process. The VPN for the masses if you will.

Great. So what?

In practical terms, With the program installed, Bonjour apps, iTunes included, start seeing remote computers as their neighbors, native Windows shares become accessible over the Internet, and LAN games can be played between computers that are not on the same LAN.

Status

I wrote the first version of Hamachi in 2004. The launch was utterly unremarkable and consisted of uploading a setup package to the FileForum.

And then, it went viral.

It accumulated 3 million users in 18 months, at which point LogMeIn came along and acquired it. I continued actively working on Hamachi for another 3 years. The last thing I wrote for the project was the tunneling engine for Hamachi 2 -- a new version beefed up for the professional IT use. This was in 2009.

Zero-conf

What defined Hamachi as a product was its "just works" nature. Install it on a pair of computers, put them both into the same Hamachi group and - click - these two can now "see" each other. Users were not exposed to any manual network configuration - be it opening perimeter firewalls, setting up port forwarding or entering IP addresses - the program was smart enough to work around most of technical hurdles on its own. Which would've not been much of a feat if Hamachi weren't...

Peer-to-peer

Hamachi connected its users directly.

Direct connections typically meant the shortest network path between the users and the lowest achievable latency. On the server side it also translated into very very modest bandwidth expenses as there were virtually no traffic flowing through the servers. In fact, the hosting costs prior to the LogMeIn acquisition were a bit over $500 a month, and this was just the rack fee with basic bandwidth allocation.

An added benefit of this arrangement was that users could keep on talking even if central servers went down for... erm... an unscheduled maintenance.

The P2P connectivity was established using an elaborate version of hole punching that was driven from the server side.

The user interface

Not something that I would've designed today, but the UI had some visual distinction and it was uncomplicated. Essentially it was a good old IM client repurposed to list Hamachi networks and peers. The UI also doubled as a peer status indicator and included very simple, but functional and convenient chat. Few hand-drawn icons that were decorating otherwise boring Network Preferences window:

Technical details

The "just work" nature of the program was a sum of several components - p2p connectivity, fallback traffic relaying, broadcast/multicast forwarding, the use of virtual network adapter and the allocation of virtual IPs from a non-standard Class A range.

1. The direct connectivity module established peer to peer tunnels and made the networking over Hamachi responsive.

2. When p2p didn't work, the system sent the client-to-client traffic through a pool of relay servers. For each pair of clients a relay was selected separately to minimize the end-to-end latency of their communication.

3. The client software picked up and forwarded broadcasts and multicasts sent by the user's computer. This is something that a traditional VPN does not normally do, but which is essential to proper emulation of the LAN environment. Broadcast and multicasts is what drives various network discovery processes, including those used by Windows networking, Bonjour and multiplayer games.

4. Hamachi added new network adapter to the computer that it configured and managed. This kept the regular network traffic separate from the Hamachi one, and made things easier to comprehend and to manage.

5. The adapter was assigned an IP address from 5.0.0.0 - 5.255.255.255 range, and not from one of standard private address ranges. This helped avoiding conflicts with an IP addresses that the user already had and it created single broadcast domain between all Hamachi clients.

The use of 5.x range was a controversial design decision, because it is a part of a public IP space, meaning that a Hamachi user won't be able to communicate with anyone who is using the "real" 5.x.x.x IP on the Internet. However the range was unassigned back then and remained that way until 2010, giving plenty of time to switch the system to - now matured and much better supported - IPv6.

Credits

- 1 -
The idea of using Instant Messenger UI for managing a list of network peers comes from a company called eTunnels - a Vancouver-based dot-com era start-up that I had a pleasure to work at before it closed down in '02. It was developing a centrally managed VPN service software and aimed at selling it to the telcos.

- 2 -
The name - Hamachi - is due to Stephen Bevan.

eTunnels created a piece of technology for getting IPsec traffic through NAT devices. It was internally called the tunnelling architecture or tuna. Then at some point Steven developed a revised version and proposed to call it Hamachi, which is a Japanese name for yellowtail, another tasty fish. With eTunnels gone soon after, the name became vacant and Steven generously allowed for it to be used for this project.

Links

»   Current Hamachi website
»   An evolution of Hamachi as recorded by archive.org

»   A review on LifeHacker
»   A mention on TechCrunch (never heard of TC before that)
»   A dedicated Security Now! episode with Steve Gibson and Leo Laporte