Establishing a secure connection from anywhere–including hotels, coffee shops, and other public wired or wireless connections—can be a problem for anyone sending and receiving sensitive information.  For setting up simple point-to-point connections with for-fee services, online proxy services are a good solution.  But what if you need more?  What if what you really need is true peer-to-peer file, print, and application sharing across 2, 10, or 20 devices?  Probably the best solution for establishing a secure network using the Internet is LogMeIn’s Hamachi (no, not the tuna). 

In this post, we’ll walk through how Hamachi works, look at some additional free tools you can run over Hamachi connections, and, of course, the risk it presents to your business network.  We’ll close with a few suggestions for blocking its use.

What is Hamachi and how does it work?

Hamachi establishes a secure peer-to-peer connection for up to 50 devices per network.  Each user can establish up to 256 networks.  To this requires a simple download and a short auto-configuration step.

Each participating system must download the Hamachi client.  Microsoft Windows platforms are supported today, but unsupported beta versions are available for Linux and OSX.  If the network is for non-commercial use, no fees are required.  As far as I can tell, the only thing you won’t get with the free version is high-bandwidth relay services, described later in this post.  Non-commercial entities are described on the LogMeIn licensing page as:

…individuals using the product for personal use, such as a gaming or family network, and non-profit institutions (as defined by the IRS as a 501c corporation or similarly situated international non-profits).

Non-commercial users may use Hamachi free of charge and without the need to pay any subscription fee.

Even if you are a commercial user, you can use Hamachi for a short time for free.  If you decide to purchase licenses, the cost is reasonable.  See Figure 1.

 Hamachi Licensing/Pricing

Figure 1 

Once the client is downloaded, you start the install process.  During the installation, the device running the client is assigned an IP address in the 5. range.  This address range is reserved by the IANA.  So there is currently no danger that an address used for the virtual NIC, which is part of the Hamachi client, will conflict with other home or office networks.  In addition to the address, a unique public/private key pair is also assigned.  The address, which never changes, and the key pair are used by the client to authenticate to the Hamachi servers. 

As part of the installation process, the client’s public key is stored on the Hamachi server farm.  Post install, the client authenticates to the Hamachi server, establishing a control connection.  Once the control session is established, a list of networks to which the client can connect are listed.  If there are no available networks, you can create one.  It takes two minutes or less.

Access to networks you create is controlled by authentication to the Hamachi servers and possession of a network password you assign.  The password is only needed when a client first enters a network. Once a client gains access, the Hamachi  server aids in establishing secure connections with all other clients in the same network.  A Hamachi network works like a normal peer-to-peer local area network.  For more details about Hamachi security, see the Hamachi security overview.

Packets exchanged between Hamachi clients cannot be accessed by the Hamachi servers.  The servers are only controllers, authenticating clients and building/monitoring user networks.  Clients use shared keys to communicate with each other.  These keys are unknown to the servers.  Further, unless a relay is necessary, no actual packet forwarding takes place. 

For more information about how to setup and configure Hamachi networks, see the user manual.

One of the strengths of Hamachi is its ability to establish a connection in even the most difficult environments.  The client initially attempts to connect to the Hamachi servers via TCP ports 12975 (initial connection) and 32976 (actual session).  If this fails, server connection fails over to TCP port 443 (SSL). 

Client-to-client transactions take place over dynamic UDP ports.  LogMeIn claims this will work 95 percent of the time.  When it doesn’t, the Hamachi client will try to establish a relay using Hamachi servers.  Non-commercial users are provided relay bandwidth of 8 Kbps.  There is no bandwidth cap for commercial license users.

Complementary applications

Hamachi only provides a connection for file and print sharing.  What if you want to use it for remote support, application execution, etc.?  This is not a problem.  Free third party applications exist to provide additional functionality.  For example, UltraVNC provides remote control capabilities.

This is all good news for small or home office (SOHO) network administrators.  Users in and out of the office can connect and share data from anywhere.  However, for organizations concerned with uncontrolled use of Hamachi, use which can lead to serious data leaks, this is a big problem.  For many enterprises, blocking peer-to-peer connections is a security requirement.  Is it possible to prevent unauthorized use of Hamachi?

Blocking Hamachi

As we’ve seen, Hamachi is very robust.  Blocking it is not easy.  Let’s start with the initial server connection.  You can block the standard TCP ports, but the client will try to connect over SSL.  Blocking TCP ports 443, 12975, and 32976 for * should effectively shut down connection to mediation servers.

You can also try blocking the servers by IP address.  However, you have to ensure server information doesn’t change.  For example, according to an Experts Exchange post the Hamachi server address was on December 7, 2007.  When I ran nslookup for the same Hamachi server name ( for this article, the IP address was different.  See Figure 2.

 Hamachi server nslookup

Figure 2 

 Blocking installation of Hamachi client software is much harder than blocking server access if your users are still granted local administrator privileges.  If you have a Web filtering solution in place, you should already have peer-to-peer sites blocked.  This works at my office where we’re still using SurfControl.  Attempts to download the client from the Hamachi site are blocked.  But this isn’t good enough.

After receiving the SurfControl block message, I went to  I was able to download the client software with no problem.  However, we also use WebSense Client Policy Manager.   This is a centrally managed agent residing on all our desktops.  It’s also configured to disallow installation and execution of peer-to-peer software.  So when I kicked off the Hamachi client install, I immediately received a message informing me that the software was not allowed on my machine.

It isn’t impossible to prevent client installation, but without the right tools it can be difficult.  Of course, you could take the leap and deny local admin access…

The final word

Hamachi is a fantastic product.  It allows SOHO owners to provide remote access to office systems.  It provides laptop users with access to home or office desktops.  And the cost is right.

However, Hamachi can also be a big vulnerability, blowing large holes through data leakage protection frameworks.  I’m not advocating blocking Hamachi everywhere.  But make a conscious decision to allow it.  Don’t just let it happen without giving some thought to the potential consequences.

What do you think?

In addition to answering the following poll questions, please leave a comment letting me know how you deal with Hamachi on your network.