Replace/Supplant/Overwrite Hamachi with ZeroTier-One

Wait there just one moment -- you mean to tell me I never posted about replacing Hamachi for something in “orders of magnitude” better?!!? How absurd of me.

Purge that crippled software and reconstitute with ZeroTier-One immediately! ZeroTier is cross-platform and even works on my obsolete Synology 410j. Forget Hamachi FOREVER!

Free Versions of	Hamachi	ZeroTier-One
Nodes per network	5	100
Bandwidth	Low	High
Dropped Connection	Often	Rare †
IP Assignment	Auto-assigned	Auto-assigned or Static
IPv4 Subnets	25.*.*.*	10.147.17.* 10.147.18.* 10.147.19.* 10.147.20.* 10.144.*.* 10.241.*.* 10.242.*.* 10.243.*.* 10.244.*.* 172.22.*.* 172.23.*.* 172.24.*.* 172.25.*.* 172.26.*.* 172.27.*.* 172.28.*.* 172.29.*.* 172.30.*.* 192.168.191.* 192.168.192.* 192.168.193.* 192.168.194.* 192.168.195.* 192.168.196.*
IPv6	yes	RFC4193 (/128) & 6PLANE (/80)
Traffic Filtering	Client Firewall	Custom traffic and protocol (“Flow”) rules with v1.2.x
SourceCode	Closed Source	Open Source and freedom loving
Free Support	Forums; but often goes unanswered	Support button on website, Knowledge-Base, and Forums; Super responsive

† The only time my connection dropped, was when ZeroTier versioned from 1.1.4 to 1.2.x and a couple of my clients had to be re-authorized & re-IP’d via WebUI. Doing so put them back online without touching the clients. Now that’s cool.

I'm syncing files over my ZeroTier VPN now.  You could consider replacing DropBox and BTSync with SyncThing. See my previous post for a quick and dirty install.

Other cross-platform Hamachi alternatives that I have not tried (because ZeroTier-One just works!) :
- SoftEther VPN
- tinc vpn
- FreeLAN
- NeoRouter Free (as opposed to the Mesh and Pro versions)

~~~~~~~~~~~





meanwhile back at the batlab

$ sudo aptitude purge logmein-hamachi
The following packages will be REMOVED:
logmein-hamachi{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 2,867 kB will be freed.
Do you want to continue? [Y/n/?] YYYYYYY
(Reading database ... 105225 files and directories currently installed.)
Removing logmein-hamachi (2.1.0.86-1) ...
Stopping LogMeIn Hamachi VPN tunneling engine logmein-hamachi *
Removing any system startup links for /etc/init.d/logmein-hamachi ...
/etc/rc0.d/K49logmein-hamachi
/etc/rc1.d/K49logmein-hamachi
/etc/rc2.d/S11logmein-hamachi
/etc/rc3.d/S11logmein-hamachi
/etc/rc4.d/S11logmein-hamachi
/etc/rc5.d/S11logmein-hamachi
/etc/rc6.d/K49logmein-hamachi
Purging configuration files for logmein-hamachi (2.1.0.86-1) ...

Current status: 5796 new [-1].
$ echo "joy"

~~~~~~~~~~~

Partially written with StackEdit.

Automated Hamachi Reset BASH Script

On occasion, Hamachi may be in a failed state on your always-on device. Alternately, maybe when awaking from sleep-mode, Hamachi may not be functional but still reporting online.

Thusly, it might be very useful for a cronjob to check the state and reset. This might especially be useful on your remote machines that you need connectivity to. For example maybe a remote machine that is in sleep mode, but WOL is possible from another remotely-accessible LAN device.

I have written a BASH script for checking Hamachi and forcing re-login if necessary. Maybe this script is not all-encompassing, but it’s a good start.

Let’s assume you have 2 or more client IP’s and also assume they are in an always-on state. (If for example you have 4 clients, but only 3 remain always-on, you will only use the 3 that you expect to be on.)

Below is my script which you will need to edit (IP addresses and hamachi network name). It will ping each hamachi neighbor and only reset if ALL are unreachable.  Alternatively it will go-online-only if failures>0 and failures<neighbors.

This script uses bash installed from Entware-NG or Optware or Optware-NG. You will have to heavily modify this script if you prefer the built-in ash shell that is default with Synology.

You should edit, save, and mark the script executable.  (e.g. chmod +x ~/scripts/check-hamachi.sh).

Since the script executes sudo /etc/init.d/logmein-hamachi start , you must add the command to your sudoers file:

Run the command EDITOR=nano sudo visudo and AT THE VERY LAST LINE (or elsewhere if you know what you are doing) add:
 username ALL=(root) /etc/init.d/logmein-hamachi , where username is your account.

Lastly cronjob (crontab -e) it to every 5 minutes under your own user account. (e.g.:*/5 * * * * ~/scripts/check-hamachi.sh)

As always, Good luck!

---

Please consider crypto tipping:
  

Replacing LogMeIn with TeamViewer on OSX and Linux

LogMeIn is no longer free and I'm not paying!

There are many remote desktop solutions and I have multiple ways of seeing my Linux desktop in emergency, but I've found TeamViewer (free for personal use) is a great replacement of LogMeIn on OSX.

I was accustomed to LogMeIn on OSX because it was always running and quite simple to remote from the web-console, LogMeIn Ignition, or even Android and iOS.  TeamViewer, although not the prettiest interface, works the same, supports multiple monitors, and even supports Linux. It also has advanced features such as file-transfer, meeting-mode, and video/audio conferencing -- but I'm not one to utilize such. TeamViewer does indeed have Android and iOS clients as well.

Go ahead and install the "All-In-One: TeamViewer full version" from TeamViewer.com/en/download for either Linux or OSX or both. If you choose, make them run at startup (as a daemon (service)). I also have a way around this as you will see further down.

Now the key settings to make TeamViewer work like LogMeIn is the following:

1) Create an account on TeamViewer.com !
2) Assign your client(s) to your account: TeamViewer>Preferences>General>Assign to account.
3) Set your client to unattended mode: TeamViewer>Preferences>Security>Password.

Presto change-o -- a LogMeIn replacement!

===============================================================


* The issue mentioned below seems to be fix in recent versions; However, I'll keep this info available: 


I had one issue that bugged me: On Linux, the client constantly bugged me with a pop-up and reported "click to disable" (the pop-up).  But it would never disable, no matter what.  So my solution is to NOT run TeamViewer upon startup; HOWEVER, I can still launch it via remote SSH login.

The key to this is that I still run LogMeIn Hamachi (Mesh VPN) on all my machines so that I always have SSH access to any of them (as long as Hamachi doesn't fail).

Now, from a remote machine, SSH into the Linux machine and perform the following:

env DISPLAY=:0 teamviewer

Don't close your SSH (preferably, run it from screen). This will set the GUI of TeamViewer to the default display (the monitor) and launch it properly -- now TeamViewer should be ready for a client connection.  (If it does not launch, see below regarding the daemon start command)

------------------------------------------------------------------------------------------------------------

Similarly, this can be done with OSX, but there seems to be a bug that requires a particular work-around that I was lucky to notice.  TeamViewer will need to be run twice -- once as sudo, and another as the user:

SSH into the OSX machine and run TeamViewer like so:

sudo /Applications/TeamViewer.app/Contents/MacOS/TeamViewer 

It should fail and report:
com.teamviewer.desktop: Invalid argument
com.teamviewer.teamviewer: Invalid argument

Now run it again without sudo:

/Applications/TeamViewer.app/Contents/MacOS/TeamViewer

This should launch TeamViewer and make it ready for a client connection.

If for some reason it fails to launch, try setting the display first with:

export DISPLAY=:0

===============================================================

I've had some occasions where the programs stay running or won't relaunch properly.  It's probably best to quit the program from the desktop GUI, but if all else fails, in Linux, we can use the killall command to stop the processes:

killall teamviewer
killall wineserver
killall TeamViewer.exe
sudo killall teamviewerd

(It turns out TeamViewer for Linux actually runs a custom version of wine to emulate the windows version.)

You should restart the daemon service after any kills, as the GUI client will not run without:

sudo teamviewer --daemon start

In OSX, it seems I could only quit TeamViewer from the Desktop and unfortunately not use the killall nor the kill commands.

You may have better success, you can find the processes with the following command:

ps aux | grep [Tt]eam[Vv]iewer

===============================================================

Other free options that you may research -- but likely require direct network connectivity or VPN and therefore do not work like LogMeIn or TeamViewer for "from anywhere" remote access:

Both Linux and OSX:
X11 Forwarding over SSH
NoMachine.com (NXRemote) -- I had played with version 3 which was SSH secure and as fast as RDP.  It created virtual desktops like RDP, but I had issues keeping it working.  Version 4 is now available and works differently -- it now connects to the actual desktop much as LogMeIn or x11vnc.  It is, however, direct access only until they release "NoMachine Anywhere." Android and iOS clients are in Alpha and not yet released.

OSX:
Preferences>Sharing>Screen Sharing (VNC) (There commandlines/files to enable, but different versions of OSX have different commands, so you may research that on your own.)

Linux (likely in your repositories) :
xrdp - RDP for X !
A ton of different VNC servers, but i like x11vnc best.

===============================================================

Related to the subject, here are RDP Clients:

OSX:
Microsoft RDP Client v2.1.1
Microsoft RDP Client v8.x (on a domain, use the "DOMAIN\username" syntax) ; Available on iOS also!

Linux (likely in your repositories):
Remmina+freerdp (xfreerdp) -- supports Microsoft's Network Level Authentication (NLA).

===============================================================

Related to the subject, here are alternatives to Hamachi (listing only cross-platform solutions):

ZeroTier One (RECOMMENDED - i have move off of hamachi onto this; with great success)
n2n - a Layer Two Peer-to-Peer VPN
SoftEther VPN Project
tinc vpn
freelan (no redhat, et al?)
Remobo -- I had tried this a long time ago, but didn't like it so much.  It might be worth a revisit.
NeoRouter Free (as opposed to the Mesh and Pro versions)

=========
Good Luck!
=========


Please consider crypto tipping:
  

Holy X11 Batman (RDP via ssh X11Forwarding from an OSX host over VPN -- it's true!)

Can it be true??? YES it IS... with a caveat I hope you solve for me...
The caveat is with a Linux client; I've verified OSX to OSX has no issue.

Scenario: I wanted to ssh into my Mac Pro at work from my Linux box at home and launch RDP via X11Forwarding.  Of course, from-Linux to-Linux is a non-issue, but in this case my host is OSX.  I got to playing, and the surprise was joyous.

Setup/Prerequisites:
 Client: Linux or OSX
 Host: OSX 10.8
 VPN: Hamachi (Hamachi for Linux in Labs)
 RDP Client: FreeRDP via OSX HomeBrew
 X11: XQuartz will be required for both OSX Hosts and OSX Clients.  Of course X11 is already part of any Linux Desktop Environment.
 Host firewall's ssh port 22 open for NIC "ham0"


Assumptions/Prerequisites:
 Let's assume you've installed XQuarts on the OSX host already.
 Let's assume you have Hamachi fully operational on both machines. (i.e. hamachi logged in, VPN created, joined on both machines, firewall open for ham0) -- ("hamachi list" to see your IP's, "hamachi -h" for other options).
 Let's assume you've installed Homebrew on the host already. (or you can do it while ssh'd in).

We will do this remotely through the hamachi VPN.

From your linux client, ssh into your OSX host: (If on an OSX client, XQuartz's xterm is necessary)
 ssh -XC user@hostIP #(-X is for X11 forwarding, -C is for compression)

Edit the ssh server config:
 sudo nano /etc/sshd_config
Adding the following 3 lines to the end of the config file:
 AddressFamily inet #(required when IPv6 is disabled on any client or host)
 X11Forwarding yes
 X11DisplayOffset 10

Restart the sshd service:
 ps -ef | grep sshd | awk {'print $2'} | sudo xargs kill -HUP
 
This will have disconnected you, so ssh in again:
 ssh -XC user@hostIP

Let's install FreeRDP:
 brew install freerdp

Setup the display for the X11Forward:
 export DISPLAY=localhost:10.0

Now run xfreerdp:
 xfreerdp serverIP #(where serverIP is a legitimate internal network IP)
 #OR
 xfreerdp -u username -d domain serverIP  #(where -d domain is only needed for Active Directory members)

Proof:

Caveat:
  I've found a significant issue strictly when on Linux client-side --  When i type into the RDP session I get completely different characters making the session unusable.

Here I type "Administrator":

I'm sure it's a keyboard or character set issue.  I'm looking into the xfreerdp -k option, but have not solved it yet.  If you solve my problem, PLEASE post it in a comment.  Thank you, and good luck!
------------
Please consider crypto tipping: