Configuring and Administering Multi-site Installations
Using Hamachi for a group of offices
Hamachi can be installed to ease interoffice networking to allow overnight backup/consolidation to a central server and/or remote user access especially where static ips arent available.
The central office or central backup computer should create the hamachi network(s) in order to assign the network joining password and retain the ability to evict other hamachi users when required.
Nightly backup/consolidation to the central office can be configured to try both direct ip and via hamachi in case either fails.
Security risks
There is a potential security risk in granting users access to a hamachi network in that it by default grants them network access to all other members of the same hamachi network with the consequent risk of cross infection by malware and viruses. To reduce this risk you can create lots of hamachi networks and let servers and users join whichever they know the joining password.
Hamachi totally bypasses hardware firewalls but fortunately software firewalls in the server are still effective since hamachi appears like a network adapter.
The well known Logmein company provides the software and a directory service so you need to trust them.
Central office router configuration
At least one side of a hamachi connection needs a port mapped on the router in order for full speed communication regardless of which side initiates the connection.
Hamachi can sometimes work at full speed even without the router being configured but it is not advisable to rely on this. The technique is called "udp hole punching".
NEOSYS' standard for the hamachi port is udp 19500 (or 19501 etc where there are multiple computers behind the router)
The port must be configured in hamachi "advanced" menu and mapped in the router.
Other offices router configuration
In a star configuration where most interoffice access is from the central office to the other offices the following is advisable but not required.
It is better to configure all offices hamachi to directly reach each other using the same port mapping as for the central server.
Having both the central and other offices configured in the same way will eliminate "single point of failure" type problem in case hamachi/mapping in the central office doesnt work properly at some point in time.
Configuring the free version of hamachi like a service
The free version cannot be installed as a windows service so automatic reboots of any kind on windows servers eg for windows updates and power failures result in disconnection of hamachi. Configure hamachi as a scheduled task "on windows startup". Autostarted hamachi is unfortunately not visible in the notification area unless you kill it in task manager and start it manually.