VPN solutions are a pain in the *ss

I’m often amazed at the amount of man-hours Humanity spends on troubleshooting VPN links.

It is probably one of the most common issues for every IT department of certain size out there, and let’s be frank with each other: Most of us hardly understand how that VPN really works.

The Problem: I need to securely access and manage my remote assets.

SSH and RDP are quite secure protocols, and leave them publicly reachable is not the end of the world; but at the same time we should be reducing attack surface. It’s also a PITA to deal with brute-force attacks if they get too insistent. There are some solutions for that (e.g. fail2ban), but then again we’re adding layers of complexity for a problem that could be solved in a much more elegant way.

The Solution: Close public access and setup a VPN link.

If your services are not publicly reachable and you require authentication on a previous system (VPN), you’re limiting the attack surface and increasing security overall. You’re also adding an extra layer of encryption, which is usually nice.

The New Problem: VPNs are complex.

Have you ever heard that someone who tries to solve an issue with regex, suddenly has two issues? Well, with VPNs you could say something similar.

A VPN link is not always managed by a sole team or by the same company, even though the remote resources might belong to the same company or project. Also, a VPN link often implies fairly expensive hardware, expensive support contracts with vendors and expensive skilled personnel. Even with all that covered, downtime still happens and it’s not uncommon to spend hours if the teams at both ends of the VPN can’t agree on a diagnosis.

Of course any reader could show me a hundred and one examples of working VPN links untouched for years. I’ve seen them, too; but let’s be honest, only the mention of the VPN acronym makes some support engineers sweat. Running a maintenance on VPN hardware (usually a firewall) without the collaboration of the team responsible for every single VPN peer connected is nothing short of a nightmare.

Why are VPNs so complex? Why is interoperability more often than not a real PITA? Why nobody seems to give a flying f*ck about it? Who the f*ck really wants to deal with VPN pains?

I can’t answer all those questions, but I can help with easing some of the frustration.

The New Solution: Cloud VPN service

I’ve been successfully running a Cloud VPN service called Wormhole Network for a while now. It has been promoted as an overlay networking solution, but it really excels at removing all the complexity present on a VPN solution. Why?

• You don’t need expensive hardware.
• So you don’t need expensive support contracts.
• Which means that you don’t need highly skilled staff to run it.
• It uses well-known technologies like SSL and only needs outbound traffic permissions.
• So it works out of the box!
• And it doesn’t require you to change any firewalls configurations. Anywhere.
• All traffic is encrypted using well-known standards.
• You can control which servers join the network, regardless of their physical or logical location.
• You can add servers with overlapping IP addresses and it still works as it should.

All this out of the f*cking box. It is so amazing that you only need to sign up for free, create a hub (our lingo for network) in one of our servers, download the agent (SoftEther!), download the configuration file, load it into the agent and you’re already connected. Actually, it’s even shorter with our Linux autosetup script.

It’s an extremely flexible solution. So flexible that I’ve worked on some concepts to add multi-host networking to Docker containers, create hidden Minecraft servers and test network performance between Docker containers (Client | Server). Wormhole also has an API under development, so you can potentially join your servers to your network as soon as they’re deployed.

A multi-site VPN could look like this:

The stuff nightmares are made of. Also known as potential clusterf*ck.

Configuring and maintaining multiple VPN links like the above is complex and costly, especially when remote access gets also in the mix with site to site links. The above also requires that [1] you have VPN hardware and [2] your cloud providers have compatible VPN hardware. As you can see, some VPS or bare metal servers could be left out of the equation if their provider can’t offer you a way of setting up a VPN with them.

Why don’t we make it easy?

Complexity? Gone!

Et voilà! All the resources are on the same flat network. OK, that was a bit overkill, but it’s actually a scenario some customers like to have for management, like an out of band management network or an extended private LAN. You might prefer other scenarios, though.

Again, there’s no need to have VPN hardware, configure VPN software or deal with 3rd party teams to setup a tunnel. Wormhole makes it transparent and removes all the complexity.

Try it now for free and please let me know your thoughts by sending an e-mail to pedro@wormhole.network