TerryG:
This sounds familiar, because I've had similar things happen to me.
As it turns out, different games use different methods to find and "negotiate" a connection across a LAN or across the Internet. Some games were written with worldwide TCP or UDP Internet connections in mind. Those games don't need Hamachi at all. A good example is the "YsFlight" flight simulator, described here:
http://techvideoreview.com/FlightSimMov ... llPage.htmFor those games, all players are expected to know, in advance of any connection request, the IP address of a compatible server, and the TCP or UDP ports on which it is listening for connections. (The IP address is always required, but designation of the TCP or UDP port is usually only required if it has been customized; a server that's listening on the game's own "default" ports won't demand this from connecting clients).
However, it's possible for programmers to design a game just for "LAN" use, in the expectation that it will never be played beyond the boundaries of your own home or small office. The "Aces High" flight simulator is a good example. It's described here:
http://techvideoreview.com/FlightSimMov ... llPage.htmIn those cases, an Internet-spanning VPN like Hamachi can generally be used to "trick" the clients and servers into believing that they are all on the same "Virtual" LAN segment, even if they are located thousands of miles apart. In those cases, when you set up a game client, you generally aren't required to know the IP address of the associated game server; the logic uses LAN-compatible tricks to discover it.
And that can be a problem.
These tricks generally rely on LAN "broadcast" or "multicast" messages. Typically, the client will send a message to every station in the LAN along these lines:
"HEY: Everybody listen up! I'm a lonely client of the "XYZ" flight simulator protocol, version 2.12.24, and I'm looking for any servers on this LAN that understand that protocol. If you are a server that hears and understands this message, please respond back to me on my randomly-selected UDP port: 2250."
On a simple LAN workstation with just one network connection, this is easily handled. If a server is present, it will respond with a broadcast or multicast message like this:
"I am running version 2.12.24 of the "XYZ" service. My IP address is 192.168.1.2. Let's continue this conversation using your UDP port 2250 and my UDP port 3110." The client, now aware of the IP address and ports used by the server, can request a direct connection, and the game is on.
However, if the server is running a VPN like Hamachi, it has become convinced (by Hamachi's clever logic) that it has TWO network connections: the conventional LAN on the 192.168.1.x subnet, and Hamachi's "Virtual" LAN on the 5.x.x.x subnet. The server can't be sure which of these 2 networks to use to respond back, so it has to take an educated guess. If the original multicast request came in over a Hamachi network, then the server should respond back via Hamachi. If the original multicast request came in over the local 192.168.1.x subnet (from a workstation within the same house), then the server should not use Hamachi.
And here's the rub: Multicast and broadcast requests look exactly the same, whether they arrive via Hamachi or not! So the server asks the operating system for help. All modern operating systems manage a "Routing Table" that is expected to know which network connections to use in differing circumstances. Usually this is managed automatically, but with Hamachi, it is sometimes necessary to "help" the routing table figure out situations like this.
This entire subject is documented in greater detail in the "Security->VPN->Hamachi" section at AskMisterWizard.com. Here's a direct link:
http://www.askmisterwizard.com/EZINE/Se ... llPage.htmI hope this helps!
-Bob Bosen-