Have you ever had to access a device or VM behind NAT and what would you use to do it? Say a raspberry pi running a web server. Would you use port forwarding or something else?
Create a network with automatic IPv6 addresses and start the management access service (likely ssh) on the zt0 interface. then it "just works", regardless of NAT in between.
This is a completely userland solution however. You probably don't want to put real service traffic on it if you care about throughput. It's perfect for management however. (or just test it, maybe you can saturate your link anyway)
This works either by using the public servers for discovery, or you can set up your own dedicated endpoint(s). Either way, the traffic takes the direct route through the NATs, or within the local netowrk if possible.
Zerotier is a great solution. I've been using it for a few months now.
I can't say if it is right for businesses, or services, but if you just need to be able to connect to any of your devices, from any of your devices, no matter where you are; then zerotier works wonders.
Sadly I can't seem to get it to compile under OpenBSD.
For VNC-style full desktop access, Teamviewer just works...it runs on Windows and Linux, is very fast, and (usually) doesn't need any special firewall/NAT rules set up. I believe on Windows at least, it can be used to establish a VPN as well.
Might be overkill if you just need to reach one particular service (e.g. HTTP(S)) though, in which case you could consider setting up a reverse proxy (e.g. using nginx) on a DMZ'd server?
Is remote access by TeamViewer established through the VNC protocol? I use RealVNC when I want to remotely control my computer but it's not as fast as I'd like in most cases. Also I'd prefer it if the connection between me and the server I'm connecting to was direct and wasn't being routed through the servers of a third party. I checked Wikipedia and it says direct P2P connections happen 70% of the time but I'm not so sure.
I tunnel everything through ssh (both local and remote port forwarding) and in some cases for the exact use-case you have mentioned (web server running on a raspberry pi that is behind a NAT). It works for me.
I've never set up a VPN and I'm not too knowledgable about them. Should I set one up? I don't know. Toyed with the idea a few weeks ago up until I read this post on StackOverflow (http://serverfault.com/questions/653211/ssh-tunneling-is-fas...) - TLDR (VPNs are slow)
I don't think that's correct. There are multiple kinds of VPNs and multiple things that slow them down. Specifically:
- OpenVPN and other tun/tap handlers send more wrappers and suffer from slow userland networking
- SSH tunneling sends the least amount of unnecessary encapsulation / wrappers
- IPSec, wireguard and other services that do actual traffic processing in the kernel are likely to be faster than the rest, but still has some encapsulation overhead
On a slow link (sending things over internet) the packet overhead matters the most. On a local network, you should be able to saturate 100mbps even with openvpn without a lot of issues.
Out of those SSH is not a "real vpn". There's no persistence and you only get a point-to-point tunnel which needs to be started always from side behind the NAT. Also, you can't connect full networks, or make mDNS work with remote endpoints this way.
> Should I set one up?
If you need just a tunnel that you can set up on demand - probably not. If you need something more - you should definitely try a VPN instead.
This won't work if the firewall is blocking SSH traffic. Now, if it's just port 22 being blocked, then you setup your sshd to run on something like port 80. At an internship where I had a lot of downtime, I had to setup my sshd to run on 443 since work was blocking pretty much anything that wasn't web traffic. Luckily my domain wasn't on the company URL blacklist.
The easiest to setup should be port-forwarding on the router. If you trust putting your server on the internet, then that's the way to go.
But it really depends on the use-case. HTTP from behind NAT - that's easy, just port-forward. If you're talking about SSH access, then you have a few more options that you might want to explore (port forward, or tunneling to an external host). If you're talking more than one host behind the NAT, then you have another set of possible solutions (reverse-proxy HTTP servers, SSH gateways, etc...).
Either the machine is routed to the internet because there's an IPv6-aware router properly set up with an ISP that provides a prefix, or you can create a 6in4 tunnel through a broker such as Hurricane Electric[0] or SixXS[1] (either on a router or on the machine itself).
If your ISP gives you a native IPv6 address you can connect to it remotely.
If not you'll need to configure a tunnel. You could find this is as easy as installing `miredo`, for example a debian system run:
apt-get install miredo
That will then automatically give you a globally routable IPv6 address - which you can view via "ip -6 addr list", and which you can connect to remotely, again you'll need IPv6 on the remote system.
(e.g. I have IPv6 on my home network, and on my laptop. When traveling I can SSH to my home network via the IPv6 address I've got.)
I must be missing something - if the tunnel is only on the PC, and outwards it's just ipv4, how does the router know to route it back without some fkrwrding configuration?
I was using a combination of a VPN and NAT rules to do so.
Basically, machine A (the machine behind the firewall I want to connect to) would connect to machine B (a VPS or AWS instance - free tier micro instances are awesome for that matter!) using a VPN connection (pptp or openvpn or l2tp or whatever - pptp has the advantage of being super easy to setup and working out of the box on most linux distros. Not the most secured though, but to run SSH on it, it's good enough). I had a script to periodically check (every 1 minute or so) if the VPN connection was up and if not, try to reconnect.
Then, I had some iptables NAT forwarding rules on machine B (let's call it gateway) to send all TCP traffic on a defined port to the machine A, port 22, using the VPN interface.
It had the advantage of being quite easy to setup for me as I'm quite used to setup VPNs and NAT forwarding rules (for having living in China, bypassing firewalls is almost an everyday routine exercise :)
Also, it worked perfectly well and the performances were reasonable. I could access my server at home, in Beijing, behind a NAT, a dynamic IP and the country's firewall, from anywhere in the world. I was happy!
There are surely other (better?) ways to do it though, and the autossh/reverse tunnels option looks very interesting.
Use case is important, to determine what resources+tools you have access to/can deploy.
However, assuming this device/VM runs "unix", and to K.I.S.S., use reverse SSH tunnelling. Once an SSH tunnel is established on your side, you can do whatever you want... e.g. tunnel VNC through for GUI.
You can of course add more layers of security e.g. non-standard SSH port, dedicated VM/server for the SSH entry point, refresh SSH keys regularly etc.
When I'm on the road, I use tinc from the server in my home office out to a bastion server I have in the cloud. Separate keys and passphrases, no ssh-agent to keep the passphrases around for anyone who gets their hands on my laptop. Super simple to set up, and hasn't failed me once in several years. I guess you could argue that tinc isn't the most secure option, but I'm not too concerned about somebody managing to be in the middle of that path. The bastion's the thing that has to be most hardened against attack.
All you need is SSH and SSH config. There are a lot of tutorials out there, but I find many of them are based on older versions of SSH which lack a bit more sugar around proxying.
Essentially you will add a directive to SSH config for the NAT host, and the host that you want to access. In the directive for the host to access, you will specify that you're proxying through the NAT host.
You can then leave out all of the port forwarding options when connecting to the target host, SSH will pick that up from the config file.
A very "low-tech" solution but Chrome Remote Desktop is very easy to setup and works well if you want to use an Android Phone/Tablet to connect to the device/VM.
probably tmi but any / all of the following:
- SSH (direct or tunnels)
- VNC (usually over ssh or VPN)
- RDP (usually over ssh or VPN)
- VPN (openvpn or ipsec)
- MicroTik Router at home with site-to-site VPN to my DC and Office
- Mobile Hotspot (always a must when traveling)
- Last resort: Dial direct with 56.6kbps modem to DC when there is an internet uplink failure or DDoS attack.
I usually use sshuttle. It requires you to be able to SSH into a box with Python that’s behind the NAT, which is usually the router or something already exposed through port forwarding. On the client, it then uses iptables or pf to tunnel TCP and UDP through an SSH tunnel. No complicated network setup is required and it is easy to set up limited subnets for tunneling, for example.
I use GateOne (https://github.com/liftoff/GateOne) running on a vps (served with https and htaccess). Sometimes all I have is web access (even SSH is blocked) and so I can login to anything from here. Works great on any device too.
Be sure to use 2FA on TeamViewer. 3 months ago accounts were bruteforced and thousands of PC's were hacked as a result of guessing the one-time-user-password (4-digits).
TeamViewers response was to bury their head in the sand until Ars interviewed them to which they said "none of this is our fault, 2FA is working fine, people being hacked is unrelated to TeamViewer".
In reality TeamViewer wasn't properly rate limiting or blacklisting IP's for making too many guesses at the one-time-password. They made no customer outreach to suggest using 2FA. They didn't acknowledge the attack for 2 weeks until the Ars article, aside from replies to emails saying they should talk to their local police department.
TeamViewer is still the best tool out there for remote access for Windows computers on corporate networks and personal use I find. However their handling of the attack was pathetic.
Also impossible to properly firewall. By design you give the whole world the opportunity to send you traffic to forward. This does not work for any kind of professional deployment.
This depends on what you mean by "properly" and "impossible" and "professional" and "forward".
Many professional name-brand corporations use Tor daily.
The only ports opened are those you configure to have onion services. Port limiting is one of the major features of firewalls.
You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.
Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Also, barring the recent attacks on discovery of onion services, connecting to a tor onion service allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes.
> You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.
IP ranges are just another layer of security controls. They may be easily spoofed one way. They may be even spoofed in a two-way communication in some situations. But it doesn't mean it's a useless control. If you can filter more traffic you should and Tor makes that hard to achieve.
> Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Even if you don't participate in the relay of traffic, you're still connecting to the nodes that can send you anything and you need to process it, because it could be traffic addressed to you. I said you may get traffic to forward (or random traffic in general) - it doesn't matter if you're going to actually do it or not. I wouldn't be comfortable running that service. This does not help to reduce your attack surface.
> allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes
It's a tradeoff. You're substituting tested routing mechanism should not be trusted (so we do the AuthN/Z in higher layers), for a relatively new routing mechanism which in duplicates some of the AuthN checking, but at the same time exposes and advertises a new service on your network. You may think it's better, I would disagree.
If I understand what you mean correctly, you end up with just a private onion network. What's the gain in that case over setting up a dedicated VPN network instead?
That's not how reliability works. If you use 3 different layers that the traffic needs to pass through, you have 3 different layers that can fail. That means less reliability, not more.
I built Wormhole Network https://wormhole.network with the idea of making remote access very easy and as secure as possible.
Disclosure: This is SaaS and I've built it.
Wormhole builds an overlay network where you can run any L3 protocol really. By default we provide DHCP for IPv4 within the 100.64.0.0/24 (yes, just a /24 by default as it suits most users, it can be customised or even disabled under request). We have chosen this address space to increase the chances of non-overlapping with your own networks.
The advantage of running an overlay network like Wormhole are:
- No need to open ports anywhere or do any inbound NAT or PAT. All traffic is outgoing. By default UDP, but the protocol would fall back to 443/TCP if needed.
- The above means it works pretty much anywhere with an Internet connection that lets you browse the web.
- Your devices' IP addresses inside Wormhole could be always the same, regardless of where they are. Think of migrating your servers to a new hosting? Keep the same IP. Do you team mates move frequently, work from home at times or even from their favourite coffee place? No problems, they'll keep the same IP address.
- Full access between devices inside the network. It works like a real LAN. No need to open ports to reach out to your development server nor leave any other services reachable from the internet. You could lock down all inbound access from Internet to your servers and still reach them through Wormhole.
- All traffic is encrypted. Note: We don't roll our own crypto. We rely on SoftEther's (see below).
- No need to configure a VPN with your cloud/hosting provider, provision VPN hardware nor anything like that.
- Multiplatorm Linux, Windows and macOS.
- It all runs on free, open source software: SoftEther https://www.softether.org so you can audit the software (and it's not ours, people are using it all over the world for VPN)
The architecture is based on central servers that route the traffic among the peers in your network, hence why full connectivity can be accomplished always with only outbound connections. It is important to choose in which server you want to create your connection, so the latency is as low as possible.
We currently have a few hundred users and are looking into making the product better by listening to your feedback. We have a free tier without time or traffic limits, available in three regions (US East, Netherlands and Singapore); it just has user limits. No credit card needed to use it.
I'll be extremely happy to receive criticism, suggestions and any other feedback in general here or directed to pedro /at/ wormhole.network
OpenVPN on the bastion host, and ssh over the VPN. If you don't control the bastion, then you need something that 'phones out' (could use a reverse ssh session for small scale stuff)
Create a network with automatic IPv6 addresses and start the management access service (likely ssh) on the zt0 interface. then it "just works", regardless of NAT in between.
This is a completely userland solution however. You probably don't want to put real service traffic on it if you care about throughput. It's perfect for management however. (or just test it, maybe you can saturate your link anyway)
This works either by using the public servers for discovery, or you can set up your own dedicated endpoint(s). Either way, the traffic takes the direct route through the NATs, or within the local netowrk if possible.