VPNs

I have customers ranging from the very large to the very small all over the world and I'm seeing some rapid change in the way that I "remote into" customers. I'm also seeing product use that doesn't make any sense to me.

I've been thinking about this since I was posed this as a quora question: "How will the VPN industry evolve over the next 10 years?"

Here's what I wrote:

The majority of sales of VPN products today are for staff connecting into a company's private network. As companies hollow out their internal infrastructure and rely more on third-party cloud-delivered solutions, this will become less necessary. I would predict sales for end-point VPN solutions to drop off quite dramatically.

VPNs between networks on the other hand will become much more common. Companies may choose to spread their virtual servers across multiple cloud hosting providers. These will be joined by VPNs. However, as these will be configured by experienced technicians they are probably more likely to use the built-in capabilities of OpenBSD, Linux, Cisco or Huawei to do this.

So in summary: I would predict a major collapse of the VPN marketplace over the next 5 years.

For this post I'll ignore the part about network-to-network VPNs. Stepping back, what are we trying to do with host-to-network VPN? We're trying to connect to some resources at a different site. So here's my list of how I currently connect to my different customers, in decreasing order of common-ness:

• A Cisco VPN service, which can be accessed through the built-in OS X VPN client. This seems to be the majority among large corporates.
• A Cisco VPN service, which only works with the Cisco VPN client. I don't understand how this can happen, but I have customers where this is the case.
• Juniper Secure Gateway. This seems to be the only one where two-factor authentication is used regularly, and it seems to be more government rather than commercial.
• Fully cloudy: the customer has essentially no internal infrastructure, so I just log into whatever web-based application it is that they need my help with. This seems to be more common with smaller companies, because they are the ones that tend to be the early adopters for having a cloud.
• A plain RDP server accessible over the internet. Usually this is behind a firewall, but the firewall port forwards to the RDP server. This used to be the standard for almost all small organisations, but I see fewer and fewer Windows servers in small organisations now. Now it's the mid-size organisations that are using RDP gateways.
• No remote access whatsoever, or nothing I'm allowed to use. This is not that unusual.
• Just log into the router and forward whatever ports you need. Generally this is for customers where I've helped them with their network infrastructure.
• PPTP to a Microsoft server
• TeamViewer and/or other connect-to-a-webservice-screensharing, such as Chrome Remote Desktop.
• Guacamole which then proxies an RDP or VNC session.
• Some other ipsec solution from someone other than Cisco or Juniper (usually something open source like openvpn)
• Lastly, as the least common option: secure shell sometimes combined with mosh.

Reflecting on that list, it's quite odd. 

The one solution where the auditing for security is well known (secure shell) is the one least used.

The solutions that can be audited (because they are open source) take the bottom three places of least use.

Everything above the open source solutions relies on trusting the vendor completely. But the solution that is the easiest to set up among the trust-the-vendor-completely options (TeamViewer, Chrome Remote Desktop, and their ilk) is the least used.

The point of the exercise is almost always to support connecting to a Windows-based application. If it were a intranet-based application, then it will generally be possible to find some way of securing it to make it accessible to the internet. So the resources that people access remotely are almost always going to be supported by a team of Microsoft-trained admins. So why is it so rare to see RDP gateways, which would be the Microsoft solution?

The answer is of course, that collectively, the world appointed their networking teams to be in charge of remote access. The network admins did as they knew best and provided layer 2/3 access delivered by their favourite networking vendors. What we have works, and it isn't terribly insecure. But isn't it odd that that's how we do things?

Why were the world's CCNEs appointed guardians of internal corporate access in the first place, and not (say) the MSCEs in charge of directory services? Or the sysadmins in charge of the actual applications?


Greg Baker is an independent consultant who writes, programs, thinks and fixes things to do with computers, IT and all things technical for customers who don't want to pay for expensive consulting firms. Contact him (gregb@ifost.org.au) if you have challenging problems you need solved.