In this document, we examine a VPN setup to meet the needs of a fictitious company. A startup has employees in Europe. Their employees need remote access to private resources running on AWS.
Owen is in charge of IT and Networking for this company. Owen is looking for a VPN solution that employees can use for secure access to the AWS private network. He does not want to manage, install, and maintain VPN servers but wants to ensure that the access is very reliable so that there is no loss in employee productivity due to VPN being down.
To improve reliability, Owen wants to provide access to the private network from two different OpenVPN Cloud’s VPN Regions: London and Frankfurt. This will ensure that access is maintained even if one of the Connectors running on the private network goes down. Even though both London and Frankfurt VPN Regions will provide connectivity for the private network, to improve network access performance, Owen wants to ensure that traffic to the private network is routed via the London VPN region for employees that connect to London and for employees that connect to Frankfurt, the Frankfurt Connector is used to access the private network. This optimized routing will automatically be taken care of by the smart routing feature of OpenVPN Cloud.
Owen completes the signup process as shown here. During the signup process, Owen selects technop.openvpn.cloud as the web domain for the user portal. This domain uniquely identifies the VPN that will be set up by Owen and is used by Connect Client applications (VPN Client software) to identify the VPN that it needs to connect to.
A Network can be configured to have one or more Connectors. OpenVPN Cloud will use Smart Routing to route traffic from the VPNto one of the connectors belonging to the Network based on:
- The geographic proximity of the VPN Region that is the source of the traffic to the VPN Region of the Network’s Connector
- Network characteristics of the connectivity between source and destination VPN Regions
- Load balancing is used when multiple destination Connectors are connected to the same VPN Region
- If one or more of the multiple Connectors of the Network is down, the remaining Connectors that still provide connectivity to the private network will be used
Owen followed the steps shown below to make the AWS VPC with IP address range of 10.0.0.0/16 part of the VPN.
- Configured a Network to represent the AWS VPC and enters 10.0.0.0/16 as the Subnets for the Network. See, How to add a Network
- Owen configured the VPN Region of the first Connector as Frankfurt
- Clicked on the download icon next to the Connector created for the Network to reveal various options and selected Launch Connector on AWS from the options list. This started the process of using the CloudFormation template to instantiate a Connector VM in the AWS VPC. See, Launch Connector on AWS
- Owen then added another Connector to the same Network by clicking on the Add (+ icon) on top of the Connectors section of the Network
- Owen configured the VPN Region of this second Connector as London
- Clicked on the download icon next to the second Connector to reveal various options and selected Launch Connector on AWS from the options list. This started the process of using the CloudFormation template to instantiate a Connector VM in the AWS VPC. See, Launch Connector on AWS
- Now Owen uses Connect Client and connects to London VPN Regions of OpenVPN Cloud (see, Connecting to OpenVPN Cloud). On connection, Owen can access the application server on the AWS via the 2nd London Connector.
- Owen uses AWS console to stop the EC2 instance connected to London VPN Region. Owen can still access the application server on the AWS via the 1st Frankfurt Connector.
This VPN has one Network configured with two Connectors. The video shows smart routing at work demonstrating the selection of the optimum Connector for routing, continued functioning when one of the Connectors goes down, and load balancing when both Connectors use the same VPN Region.