VPNs have been around for quite some time and are the preferred method for securing communication over the public internet. Most VPN solutions meant for the cloud, are in reality legacy VPNs built for on-premise and corporate networks. As such they tend to be clunky, hard to setup, manage and monitor.
Most IPsec VPN solutions available today read more like “guides” than easily deployable solutions built for the cloud. These guides include multiple pages with instructions on making configuration changes, creating and tagging VPCs, setting up VGW’s, deploying IPsec VPN tunnels and then making some more configuration changes. And good luck keeping track of all the changes or figuring out how to ensure high availability and put in place a management and monitoring paradigm.
The cloud needs a different type of VPN: one which is fully managed, completely automated, requires no new hardware, software or configuration changes and can be setup in a couple of clicks.
It scales automatically to ring in all the AWS VPCs distributed across regions into a full-mesh IPsec VPN connectivity topology. VPCs inside a region are connected via a transit VPC (hub VPC). Each hub or transit VPC is connected to transit VPCs in other regions via a full-mesh network.
It does not require any new hardware or VPN software to be installed. The VPNs tunnels that are created are highly available with built in redundancies, multi AZ active passive instance deployments, self-healing properties and automated failover.
This is what creating IPsec VPN tunnels on AWS looks like with Datapath.io:
Step 1: Sign-up
Step 2: Choose the AWS regions that you want to connect via IPsec VPN tunnels
Step 3: Fire up the cloudformation stack
Step 4: Accept payment terms
Step 5: Voila! Your IPsec VPN tunnels are good to go!
Now let’s take a closer look at what is happening behind the scenes, when the cloud formation stack is triggered.
IAM user and policy
The AWS cloudformation stack kicks off by creating an IAM user and a policy. The policy allows the newly created user to access AWS resources. These include access to DirectConnect, ec2 and lambda among others.
VPCs that are to be connected via IPsec VPN tunnels are tagged.
Next the instance types that are to be spun up to manage the IPsec VPN tunnels are chosen. These instances act as VPN appliances running the proprietary VPN software from Datapath.io. The default instance type is t2.medium, which can handle up-to 250 Mbit/s of bandwidth. Other instance types are also supported including t2.nano, m3.medium, m4.large, m4.xlarge, m4.2xlarge. Once the instances are spun up they automatically detect other VPN instances running in other AWS regions and deploy IPsec VPN tunnels.
Number of VPN gateway instances
By default, the CloudFormation stack spins up two VPN gateway instances, in each region. Each instance is placed in a separate availability zone and are arranged in an active/passive setup. Whenever an instance fails or an availability zone goes down the VPN tunnels seamlessly failover to the stand-by instance in the other availability zone. Users can also choose to spin up up-to 5 instances per region.
Leveraging spot instances as VPN gateway instances
The managed IPsec VPN solution also allows users to use spot instances as VPN Gateway instances. By default, all VPN gateway instances are spot instances expect one. Users can also choose between a VPN gateway instance setup which leverages only on-demand instances, only spot instances or a hybrid setup with a mix of on-demand and spot instances. In the hybrid setup primary or active VPN gateway instances are all on-demand instances whereas stand by instances are spot instances.
Spot instance pricing is determined by the launch configuration where users can fine tune the maximum spot bidding price they are willing to pay for the VPN gateway instances. We have also identified the spot market pricing for the highest pay-out, which is used as the default bid amount for spot instances. As long as the price for the spot instance is lower than the bid amount the VPN gateway instances keep on running. In cases where the spot price goes above the bid amount the spot instance will terminate. When this happens, scaling groups kick in and re-instantiate the spot instance. Spot instances are configured per scaling group and we make sure that the instances are highly available.
KMS key management
Sets up the KMS key management service which allows users to create and manage the encryption keys used to encrypt data. Users create a master key and the VPN solution derives connection keys from that master key. We store the encrypted key in our management system, which in turn decrypts those keys with the AWS API, when creating VPN connections.
Next Amazon machine images are specified for the instances that are spun up. AMIs include specifications for an operating system, configuration information and software for launching the instances.
High availability and fail-over
Now a word about how we ensure high-availability for the IPsec VPN tunnels. Every guide to ensuring a highly available architecture on AWS, starts off with instructions on a multi-AZ deployment, so that is where we started too.
VPN Gateway instances are tagged in primary and secondary roles and are placed in separate availability zones. But we did’nt stop there. We also developed a custom routing protocol to ensure seamless 200 ms fail-over whenever an availability zone or an instance failed.
The Managed IPsec VPN solution actively manages AWS routing tables in the back ground. This also means that every subnet that is managed by the routing table has access to the VPN tunnel. Instances themselves take care of leader election and write themselves into the routing table whenever they are able to receive traffic for the VPN tunnel. Whenever the primary instances goes down the secondary instance takes over and manages the routing table to direct traffic to itself.
To learn more download the Managed IPsec VPN Whitepaper