Network and Computer Security Section: VPNs
Hamachi Broadcasts and "Invisible
Many Hamachi gamers have suffered from a well-known and confusing set of inter-related problems. They set up a game server, but their buddies can't see it. Or they can see it, but they can't connect. Or game users can see some servers but not others. Or game users can't connect to a desired server even though they know for sure that other people are able to do so.
I've certainly seen these symptoms from time to time. In my case, my Hamachi network management GUI tool was showing green - "OK" - connection status for all of the stations within my virtual LAN, and regular pings worked, both from within Hamachi, and through a conventional DOS prompt.
Eventually I solved the problem, but I had to dig deep to do so, and I discovered the general principles that trouble a lot of folks.
I found that the problem is related to the way my Windows-based server host was choosing routes for packets. Instead of using the Hamachi private network, Windows was telling my game server host to use my own local IP subnet, because it thought it could get a better connection that way. I had to manually adjust a parameter that Microsoft calls - "Metric" - associated with my wireless LAN interface so it would show a less favorable connection than my Hamachi interface. Once I did that, my game server became visible to my Hamachi friends. I've also seen similar problems with other games. Sometimes I've been able to solve the problem by reconfiguring the operating system's "localhost" definition to use my Hamachi IP address.
From time to time, some of my friends have had to do similar things in order to get their game clients to use Hamachi to find one or more game servers, even when other people could find them.
What's really going on here?
When you install Hamachi to play a LAN game with people out on the worldwide Internet, your operating system will discover and configure a new, virtual Hamachi network interface. Unlike your Ethernet or WiFi adapter, this network interface is not a physical device, but a - "virtual" - one. That's OK; from the perspective of Windows routing, it is real enough to be treated in the same way. This turns your computer into what network experts call a - "multi-homed" - machine, which means that the operating system has to choose from among two or more interfaces on which every outgoing packet will be sent. The routing table is consulted to make these decisions, and the information it contains is supposed to help Windows decide to send the Hamachi packets on the Hamachi network and the other packets on your local IP subnet. Unfortunately, it doesn't always work out that way because of the way LAN game clients generally use broadcast packets to find LAN game hosts. As it turns out, it isn't easy to determine whether a broadcast or multicast packet originated from a Hamachi virtual private network.
When you start a typical game server, it begins listening for client requests. For our purposes in analyzing these Hamachi problems, there are two different kinds of game servers:
1 of 2: Game servers that were designed to work on the worldwide Internet,
2 of 2: Game servers that were designed to work only on a Local Area Network (LAN).
If the game server was designed for modern Internet work, it will listen on a specific TCP or UDP port, but the clients are expected to know the IP address in advance. These kinds of games don't generally need Hamachi.
On the other hand, if your game server was designed only for LAN operation, it may listen on a multicast address (18.104.22.168), or on the general broadcast address, (255.255.255.255), so game clients don't need to know the server's IP address in advance. When it receives an appropriate request, the server will try to respond back to the client with a summary announcement advertising its availability and services. Under designs that were intended for LAN-only access (unaware of or hostile to Hamachi), the server's response will generally include details about the IP-address and port(s) that clients should use for responses, and any application-specific details that may be needed in order to begin to communicate. This is where my problem started: When my server tried to tell the clients the IP address to use for further communication, Windows had already advised it to use an IP address from my local IP subnet (192.168.0.2, which was assigned to my WiFi card) instead of my Hamachi IP address.
Windows uses its own routing table to choose the best interface. In this case, I needed it to choose the Hamachi interface, since my game buddies are not in my home and can't be reached by WiFi. But my game server had no way of knowing that the client was using Hamachi, since the original, incoming request had come via a broadcast address and not from the Hamachi subnet. The routing table had been automatically configured by Windows, and the result was incompatible with the way my game server had been written. The routing table showed a lower - "Metric" - for the routes associated with my WiFi adapter than for routes associated with Hamachi. My game server had originally been written only for LAN access, without regard for Hamachi or any other kind of wide-area connection. Accordingly, when it needed to learn its own IP address so it could pass that information back to requesting game clients, it just asked Windows for the IP address of the adapter that benefitted from the most efficient local connection. When game clients got that information, they discarded it because it referenced my local IP subnet, and their routing tables showed no way to reach it. Frustration!
Depending on the environment in which it is installed, the Hamachi virtual interface will have a - "route priority" - or - "metric" - that may be either higher or lower than your real network card. Depending on this ordering of network interfaces, Windows will send the game client's general broadcasts either on the Hamachi interface or on your real connection, and Windows may advise the server to advertise its own address from either the Hamachi subnet (desired), or on the local LAN subnet (not good). If the server and other players are listening on the Hamachi interface, but the server advises them to attempt further communication sent on the other interface, it will not show up in the server list of the other players. Even if the client can see the server, it may tell the server to use an IP address from its own local IP subnet (instead of a Hamachi address) for further communication, and the server will discard that. These are fairly common problems with Hamachi.
The routing table consists of printable text that you can understand with a little help. Separate lines represent routes to every network or subnetwork that Windows has figured out how to reach. Some networks may be listed more than once, in adjacent lines of text, indicating two or more routes can be used to reach it. Each line represents a separate route, containing 5 fields separated by spaces or tabs. From a DOS command window, you can see your routing table by typing 'netstat -rn' or 'route print'.
For example, if your game client broadcasts on 255.255.255.255 and your Hamachi IP address is 22.214.171.124, what you would ideally like to see is a line representing the appropriate broadcast definition with 5 fields as follows:
Field 1 of 5: 255.255.255.255 (Destination Network)
Field 2 of 5: 255.255.255.255 (Destination Netmask)
Field 3 of 5: 126.96.36.199 (Gateway to use for that destination network)
Field 4 of 5: 188.8.131.52 (Interface to use for that destination network)
Field 5 of 5: 1 (Hop count or - "Metric" - for that destination network)
What this means is:
For a broadcast destination of 255.255.255.255 with Netmask 255.255.255.255, the Gateway should be 184.108.40.206 (your Hamachi IP address), the Interface should be 220.127.116.11 (also your Hamachi IP address), and the hopcount (metric) should be 1 to ensure a higher routing priority than any other interface(s). This will cause Windows to use the Hamachi interface every time it needs to respond to a broadcast.
There may be other lines referencing the same destination network (255.255.255.255 or 18.104.22.168) but referencing a different default gateway and interface. You need to make sure that these other lines all show a hop count higher than the Metric associated with your Hamachi interface, to make sure that the Hamachi route is chosen.
It's tricky to make changes to the Windows routing table. If you try to do it from a DOS command box under Windows XP, you are probably going to have trouble. Don't try it yet; I'll show you an easier way at the end of this article.
Any changes that you make to accomodate gaming may need to be undone later, for compatibility with other processes, so it would be a good idea to take notes before you change anything, for future reference.
Unfortunately, you probably won't be able to set the Metric to "1" for the broadcast or multicast addresses through the Hamachi interface, even though that might be the best and simplest way to solve the problem if it were possible. In the real (Microsoft) world, you'll have to be satisfied with any value that's lower than the metric to the same addresses via other interfaces. In my experience, most interfaces are automatically configured with Metric values of about 25, so if you can get the Hamachi routes to show a Metric value of 24 or lower, you should be OK. (Or you could raise the Metric value of those other interfaces so that they are higher).
I haven't found any way to directly alter the routing table for the general broadcast address or for the multicast address, but it is usually possible to get these broadcasts to go on the Hamachi interface via a simple, indirect workaround. If you go to the - "Networks" - settings in the Windows Control Panel and disable your real network card, wait a few seconds and enable it again, the internal ordering of network interfaces will change, and Windows will be forced to configure one of the remaining interfaces for broadcasts, resulting in a new ordering of network destination priorities. If this does not work for you, you may have better luck if you disable and then reactivate the Hamachi interface instead.
Check your routing table ( with - 'netstat - -rn' or - 'route print' ) after enabling the interface again to see if Windows has set up workable Metric values for your Hamachi route versus other routes.
Remember that a higher "metric" indicates a slower route, so you want to see lower "metric" values associated with Hamachi routes than with other routes.
If you don't see this after disabling and then reactivating network interfaces as described above, then you can edit at least some of the metric values manually, and this might cause Windows to automagically re-order the ones that you can't edit. With luck, the combination will start working, especially if you tinker a bit.
From the Windows - "Control Panel" - go to "Network Connections" (or in Windows Vista, go to - "Network and Sharing Center" - then - "Manage Network Connections"). Right-click on - "Local Area Connection" or some other desired link such as your WiFi card, and then select - "Properties". You should see a list box entitled - "This connection uses the following items". Select - "Internet Protocol (TCP/IP)", and then click on - "Properties".
In the IP protocol Properties dialog, click on the - "Advanced" - button. Several tabbed selections will be displayed. Click on the one labeled - "IP Settings". From there you need to uncheck the - "Automatic Metric" - checkbox located after the IP addresses and default gateways sections. This will disable the automatic Metric logic and allow you to configure the associated metric value manually. You'll see a prominent text box for your new value. Using the principles discussed above, configure this value for all of your interfaces so that your game clients and servers will see a preferred route for your Hamachi network. Because you can't directly edit the Metric values associated with any of the broadcast or multicast networks, you will need to nudge Windows into doing it for you by making tactical changes to the other routes and then disabling/enabling various interfaces until the automagic Windows logic ends up with a workable arrangement. In my experience, it is cumbersome, but it's always possible.
If all else fails, sometimes it's helpful to edit your "hosts" file, because some games consult it when they need to advertise their own IP address. On Windows XP, that file is located at:
Use "Notepad" to edit that file. You'll see a prominent line like this:
Try changing the "127.0.0.1" value to your own Hamachi IP address. For example, if your Hamachi IP address is 22.214.171.124, the line would look like this after you edit it:
Save the file and try your game again.
With luck and patience, these techniques have proven succesful for many folks. I hope they work for you!