We were able to get windows 7 working but not with the homegroup. We switched the windows 7 machines to a workgroup and matched the machines that have XP and vista. They all are working fine being served from the main office's router DHCP address server.
We did experience some of our remote sites losing the mapped network drives after the recent update. The Hamachi adapters seem to be coming up with an itermediate address scheme 10.x.x.x. After several hours of testing, we determined that the Hamachi adaptors didn't seem to be working as expected because both offices' Local address scheme was 192.168.1.x. We modified the remote office to 192.168.2.x and the 10.x.x.x addresses disappeared and were replaced by the home office 192.168.1.x address which allowed the mapped drives to begin working again.
We would like a solution where the 2 segments being attached via a VPN-Gateway network can have the same address ranges as we can not control the address scheme at all of the locations we have computers(customer locations, etc).
For now the unique segment address solved our immediate problem of it was working and when we got back from Thanksgiving holiday it was not working.
The computer cannot have access to two locations with the same address schema. You system will not allow this to occur without throwing numerous errors.
We alter the address range your gateway sends out in this scenario.
IP Range of the Gateway: 220.127.116.11
IP on gateway you want to access: 192.168.1.50
we will alias the network to 10.40.1.0, with any and all addresses on the gateway's LAN addressable by changing the first 2 octects (the numbers separated by dots are called octets) from what you know them to be (say 192.168.1.50) to 10.40 (so 10.40.1.50).
I learned a valuable lesson too: Never configure a network for "Gateway" - it simply does not work.
At least, not with a unix server.. Just go for hub-and-spoke instead..
I installed the current Labs Unix Hamachi client... which had zero instructions on how to do it... thankfully I found something on Google search on how to. But once I did that, configured as Gateway on the LogMeIn site and approved the Join request on the Logmein Central website, my Linux based gateway immediately made that Gateways subnet available to my remote Hamachi clients (also Join/Approve via LogMeIn Central).
Absolutely brain dead simple. Ran some Remote Desktop Connection from a Mac to a Windows machine behind the Hamachi Linux Gateway... instantly worked with decent response. Pings my house the Windows machine on the LAN is 15msec. Not bad. The Linux Hamachi Gateway is running on a pretty old Dell Pentium server... no problems at all... it uses a CentOS 4 or 5 distro.
We will load up this Gateway with more clients doing RDP and see how it goes.
p.s. my Linux Hamachi client is on 192.168.1.190 (inside the office, a static reserved IP), and immediately it routes all other Hamachi clients on that same Gateway network to 192.168.5.0 ... perfectly. I am told, though I did not try it, that Hamachi Linux client is even resolving Windows network host names. In other words remote users with Hamachi connected clients are using Windows Explorer at their homes with addresses like \\Diskstation\folder and it just works. Wow.
Hi Sean, just a suggestion that this would be helpful to have in the documentation - it took me a while to find this answer buried in the community.
A couple of things learned in setting up a gateway on a Windows PC on a LAN with static IPs:
- The "Network Bridge" (go to Windows "Network Connections") must be configured with a static IP on the LAN. Hamachi seems to do that automatically sometimes and sometimes it doesn't.
But that makes no sense. If the gateway is a laptop that moves about ... as soon as it leaves the home network, it will become inaccessible. DHCP has to work!
(Not saying it does, I've seen other references that it doesn't, merely that it makes no sense for functionally / practically for it to not work with DHCP!)
Here are a few things that I've learned in setting up Hamachi Gateways...
- It's easier to install the client on the gateway before creating a Hamachi Network. This makes it available to select during the "Create Network" wizards.
- At least for gateways, it is easier to create the network from the LogMeIn.com site, not the Hamachi client.
- The Hamachi Client not only runs on all client computers, it also runs on the Gateway computer.
- Running the gateway on VMWare vSphere ESX 4.0 (also ESX 3.x) requires the network adapter in ESX to be configured in "Promiscuous Mode". If it is not configured, network connectivity on the server VM will be lost when the Hamachi Client on the Gateway is installed.
- Based on the above, I suspect "Promiscuous Mode" would need to be turned on when using a more advanced SOHO or business grade switch like an HP ProCurve. Consumer grade switches already have it turned on.
- Must "Disable UAC" on Vista and Server 2008. Google to find out how. On 2008 this can be done by Start -> Run -> msconfig -> Tools tab -> "Disable UAC"
- I've gotten Hamachi to works on Server 2003, Server 2008, and XP as gateways.
- I've been able to get Hamachi to work as a client on Windows 7 Ultimate, Vista, and XP.
- On Windows 7 Hamachi required my RSA key to be authenticated. This showed up as a blocked connection. Right click -> Details... -> then double click Authentication and click "Trusted"
- If the client running on the gateway is "Powered Off" it disconnects all Hamachi connections essentially turning the entire Hamachi Gateway network off.
Tunnel notes - Under connection "details... " in the Hamachi client
- "Direct" links are the best tunnels and I typically see Round-trip times of 45-60ms where I'm at.
- "via Relays" is the next best tunnel and I typically see 100-200ms Round-trip times.
- "via Servers" is the slowest and with the free Hamachi product I've seen 500+ms Round-trip times.
- When Hamachi first connects it finds the fastest link then if the fast link drops off for whatever reason, it reconnects with the next fastest tunnel until it connects "via Servers"
Add comments as needed.