<iframe src="//www.googletagmanager.com/ns.html?id=GTM-MRFNVD" height="0" width="0" style="display:none;visibility:hidden">

Something Powerful

Tell The Reader More

The headline and subheader tells us what you're offering, and the form header closes the deal. Over here you can explain why your offer is so great it's worth filling out a form for.


  • Bullets are great
  • For spelling out benefits and
  • Turning visitors into leads.

Soha Blog

VPNs Are Not As Secure As You Think

[fa icon="calendar"] Jan 20, 2015 5:30:04 AM / by Seetharama Sarma Ayyadevera

So you set up a number of new applications in AWS and want to enable access for your entire user base. In your situation, 9 out of 10 infrastructure teams will select a Virtual Private Network (VPN) based solution to enable user access to applications. But are VPNs really the right choice? I think not.

Let’s first agree that the end-user experience with VPNs is usually quite poor. Most VPNs require a client to be installed on the end point, which is a challenge for a variety of reasons, e.g. client distribution to end points and troubleshooting the client on a variety of end points if it doesn’t initially work. VPNs illicit a visceral reaction from most users; it’s a rare bird who hasn’t suffered at least once when trying to access a critical application while in an airport or in a hotel room.

Now let’s examine some of the security issues that VPNs may expose you to:

Issue # 1: VPNs provide network access to all devices

VPNs are essentially a way to extend your data center network all the way to an end point, e.g. a laptop or a smart phone. When you give users VPN access, are you trying to give them access to anything and everything in the network, or do you really want to give them access to a handful of applications? Consider that some of your users may have malware-infested devices that may start looking for vulnerabilities within your network once they gain network access over the VPN.

Network-level access should never be allowed for remote devices under any circumstance, and any solution you use to enable application access must comply with this statement.

Issue # 2: VPNs do not control access based on user identities

Although VPNs require end users to identify themselves through some form of credentials, the user identity is usually not used to manage authorization policies. Just because John has been authenticated doesn’t mean he should have free-range access to everything in this network.

All access control should be based on who the user is and not which IP they are connecting to/from. IP/port qualifiers are a poor substitute for access control at best, and leave the company wide open to information leakage at worst.

Issue # 3: VPNs are a bad solution for third party access

If you routinely interact with consultants and contractors who need access to applications hosted in your cloud environment, then the VPN is absolutely the wrong solution for you. As discussed above, VPNs give all users network access, and user-specific access control is hard, if not impossible, to implement.

Many companies attempt micro segmentation to solve this problem. Micro segmentation results in a complex design and implementation exercise that requires a serious investment of time and money. Even when it works, it does so for a fixed application group and a fixed set of end users. If you add one more application to the mix, you may have to go back and change a number of network policies. Furthermore, if a typical 3rd-party user only needs access for two weeks at a time on average, should you really be spending hours at a time enabling access for each such user? Life is too short to waste time on such hacks.

If a 3rd-party user needs access to a specific application, you should easily be able to set a policy to bind the user to the given application without making massive changes to your network.

Issue # 4: VPNs result in fragmented security policies when apps are distributed across locations

If your applications are deployed in a number of VPCs across multiple cloud providers, you have two options when it comes to VPNs:

  1. Deploy VPN gateways in each VPC, in which case you need to ensure that all policies are applied religiously to all gateways. You don’t want to be in a situation where some applications are not as secure as others in a different location. This is usually a manual exercise. In this case, end users must have a priori knowledge of which VPN gateway to connect to if they want to access a given application, which probably means you are going to get a flood of support calls all the time because people will forget all the mappings.
  2. Build a perimeter in one VPC and drive all user traffic through this VPC. Traffic destined for other VPCs will then need to be routed via an overlay network and routed back again before it is sent to the end point. Consider that in this scenario, you are building a complex routing environment that you will have to manage on an ongoing basis, and the fact that by running all traffic through a single VPC, you are building a bottleneck into your infrastructure that goes against the spirit of a distributed, scalable cloud.


If you’re deploying applications in the public cloud and are evaluating a VPN solution, you should talk to us first. Not only have we addressed the issues I have outlined above, we have built a solution that is fundamentally more secure than a VPN. I can guarantee that the engineer in you is going to love the elegance and security model of our solution.

Questions? Comments? Please feel free to get in touch.

Topics: Blog