from the systemd service file:
ExecStart=/usr/bin/autossh -M 0 -N -q -o "ServerAliveInterval 60"
-o "ServerAliveCountMax 3" -o "ExitOnForwardFailure yes"
-p 3004 -l pi exampmle.org
-R 3006:127.0.0.1:3006 -R 8080:127.0.0.1:8080
I opted (some months ago when the problem arose), to simply set up a private VPN server, and every device I have at customers connects to it. That way, I can simply `ssh device.cust.vpn.mycompany.tld` and I'm in.
I use the 184.108.40.206/16 zone. It's not a good practice at all, but in this case it's very useful (doesn't conflict with any network map, only routed inside my devices, which only talk to each other).
But I would love to take a look at it if you share it ;-)
Sure, you could use 192.168/24, or 172.16/12 but you'll run into the same problem. Once it'll be a hotel that uses this space, and another time it'll be an industry.
So that's why I use 220.127.116.11/16. Yes it's allocated, but my devices will (never) need to talk to it (they only talk with me, and I'll never install devices in the DoD, so there won't be a conflict).
I don't really see how I'm setting up for these kinds of problems as these devices only talk to my infra, but I'm on the other way avoiding a lot of problems.
If you're already using SSH you can use it to forward ports. You can SSH into that SSH server (with Mosh you'd achieve low latency) and craft a SSH config (at ~/.ssh/config or /etc/ssh/config), make a bunch of shell scripts (including ProxyCommand if needed). You could even run your SSH server over Tor, or as I briefly suggested above you could go with a SSH server as VPN. One disadvantage that has, is that on Android it will not work with without root. Tor also won't work with Mosh (uses UDP), so you'd have higher latency.
See also this recent HN post "SSH vs. OpenVPN for Tunneling" 
Agreed. That is why I love sshuttle:
Any host that is running plain old sshd is now a potential VPN endpoint. No config or settings (or even permission) necessary. Supports --dns.
1) you have to know which ports you want to forward before you ssh into the remote host and
2) you have to change configurations (hostname and ports) in all the programs you use (for example, instead of pointing your browser to http://foo, you're going to have to go and type http://localhost:8888 - not to mention all the scripts or other pieces of software that "just work" using the canonical name and standardized port to connect, and would require customizations to change that)
I just tried ZeroTier yesterday and it is nice indeed, basically an advanced, open source Hamachi. But it is not rocket science. What I especially like is that you can completely self host.
And while your method works, I think it's also more manual and involved than a simple VPN setup. At the minimum, you just set it up, connect all your devices to the server and write down the IPs.
To add to irq-1's excellent response, another autossh method is to autossh from the device into a remote relay server (ie jumpbox) that forwards the local port back to the local ssh server running on the device, which can now be listening on localhost.
You can try this out in literally ONE COMMAND LINE (below) and automate it quickly without installing any additional software (except perhaps autossh, which is usually in your distribution's repositories).
device (autossh) -> jumpbox <- you
Use RemoteForward (-R) on the autossh command line for this. See man page for ssh(1) and especially the RemoteForward section under ssh_config(5) for details.
# on the device:
$ ssh jumpbox -R 22001:localhost:22
That's all. You can automate this with ssh_config, autossh, etc, and also lock down the remote host authorized_keys file and use a restricted shell.
You have to log into jumpbox (presumably still running on port 22) in order to log into the device who's SSH listening port has been forwarded from port 22 on the device itself across the encrypted tunnel to port 22001 on the localhost of the jumpbox.
If instead you prefer to expose the 22001 to the entire world (so you don't need to log into the jumpbox first), try this:
device$ ssh jumpbox -R 22001:*:22
laptop$ ssh jumpbox -p 22001
Keep in mind that, with this method, any potential attacker can now directly try to break into the device itself through the jumpbox rather than have to break into the jumpbox first, so make sure that you harden both the jumpbox and the end device (which is always a good idea anyway - don't deploy an IOT device that isn't hardened!)
It has also been audited by third parties (example: https://www.theregister.co.uk/2017/05/16/openvpn_security_au...) which is reassuring as it has passed with minor issues which were fixed FDQ. I don't know if that is the case for the other options you've listed.
If you find 3rd party apps unrelibale, perhaps you could try setting up a server that uses one of the protocols that are officially supported out-of-the-box (https://support.apple.com/en-us/HT201533) and see if they are less troublesome?
If they are on the same LAN then they should be able to see each other through the local interface.
If connections between them using local addresses are going through the VPN then you have a routing issue - even with the OpenVPN interface set as your default gateway the gateway for the local subnet should still be the local, presumably physical, network interface.
If you are using VPN provided addresses (or public addresses) for the connections then that is the issue. It shouldn't be the VPN's job to say "I think this should be routed locally instead".
If you are using non-local local addresses, i.e. if you have two subnets on your physical network are talking between them, then you need to set the gateways for those subnets appropriately. The VPN will see them as separate networks (they are addressing-wise) and again it is not its job to decide routing apart from for its own virtual network.
I also don't want to pass the traffic over a remote gateway if a local link is available.
I don't know and don/t care if it's a "VPN proper" or something else, as long as it gives me an IP interface with these properties, and is open-source.
ZeroTier provides that. Tinc provides that. OpenVPN provides something more narrow, which I happen to prefer less.
Either that or the names are not getting mapped to local addresses as you expect, so the second possibility is a name resolution problem. If you have a split-DNS setup this could be because DNS requests are getting sent out through the VPN your the DNS servers are seeing you as external and giving out public addresses instead of local ones.
# curl -sSL https://get.ondevice.io/|sudo - bash
A fairly balanced post and mitigation options:
apt-key add [key]; apt-apt-repository [repo]; apt-get update; apt-get install [program]
I've recently developed a utility to help simplify setting up hidden services w/client auth for this purpose, you might find interesting.
via reverse proxy: `ssh -NT -R 1234:localhost:22 email@example.com`
Now if you connect to firstname.lastname@example.org you can then ssh to your inaccessible machine with `ssh inaccessibleuser@inaccessiblemachine:1234 `
That's what happens internally (so yes, you could for example use `ProxyCommand ondevice pipe %h ssh` for other tools in the ssh ecosystem - e.g. in your `.ssh/config`).
Zerotier seems to be an overlay network with a custom addressing layer above virtual L2 networks. There's also an appliance in the works that will presumably work as a "hardware vpn" type of gateway on your network. There's no easy setup for ssh access like ondevice.
The on-prem part is really neat.
Disclaimer: I work at StrongDM.
Edit: fixed typo
Here's a rough explanation:
- ondevice makes use of `ssh`'s `-oProxyCommand`, which makes ssh send its protocol data to a command's stdin and expect the responses on its stdout (you can use that for example to get around certain proxy servers using `nc`)
- `ondevice ssh` basically executes `ssh -oProxyCommand=ondevice pipe %h $@` (there's a bit more to it, but that's the gist)
- internally `ondevice pipe` creates a websocket connection to the ondevice API servers, who in turn tell the device (where `ondevice daemon` is running) that there's a connection incoming.
pretty much the same goes for `ondevice rsync` (and the - not yet released... - `scp` and `sftp` subcommands)
So for some scenarios, using websockets seems to be not enough
 for ex, see here https://www.cyberciti.biz/faq/linux-unix-ssh-proxycommand-pa...
BTW, just curious is there any other alternative apart from this ?
It's Open source!
Disclaimer: I am employed by gravitational
Plug: If you want adhoc peer to peer port forwarding, you can try https://github.com/selvakn/p2p-port-forward (which uses zerotier-sdk)