High Availability / Failover VPN in AWS using libreswan
Introduction
This HOWTO was written by Matt Woodson of Red Hat
The Openshift Operations team at Red Hat deploys services in Amazon Web Services (AWS). Openshift Nodes and related infrastructure are located in multiple AWS regions, so that users can place apps in a region geographically close to them. We needed a way to to inter-connect all of our regions via a VPN, but at this time, AWS does not provide a way to connect regions together.
First, we devised a list of requirements:
- We wanted to use Red Hat technologies.
- We wanted our VPN’s to be highly available (HA).
- We wanted to be able to monitor the VPN connections.
As a quick note, we investigated using libreswan to connect to AWS VPC VPN . We quickly found that AWS VPC is broken and moved on to design other solution.
Overview
Here is a simple diagram of what we are going to achieve. For the sake of this article, I am going to give our VPC’s and nodes example IP space and addresses so it can help us in coming up with valid configurations.
| VPC 1 - Region 1 | VPC 2 - Region 2 | |||
|---|---|---|---|---|
| VPC 1 Network | 172.16.0.0/16 | VPC 2 Network | 172.20.0.0/16 | |
| vpn1.vpc1.example.com | 172.16.0.1 | vpn1.vpc2.example.com | 172.20.0.1 | |
| vpn2.vpc1.example.com | 172.16.0.2 | vpn2.vpc2.example.com | 172.20.0.2 | |
| VPN ENI (internal) | 172.16.0.10 | VPN ENI (internal) | 172.20.0.10 | |
| VPN ENI (external) | 50.0.0.1 | VPN ENI (external) | 100.0.0.1 | |
| ENI Subnet | 172.16.0.0/24 | ENI Subnet | 172.20.0.0/24 | |
| ENI Subnet GW | 172.16.0.254 | ENI Subnet GW | 172.20.0.254 | |
 | The config files will be using these example IP ranges |
AWS Configuration
The first requirement is to configure some options in AWS. I will be specifying addresses here for the work in VPC1. This process will need to be repeated in both VPC’s. I will assume that the VPC has been created and subnets are created inside of the VPC.
Security Groups
A security group is needed to allow the clustering software to communicate as well as the IPsec communication.
| “VPN” Security Group | |||
|---|---|---|---|
| Protocol | Ports | Source | Notes |
| TCP | 2224 | “VPN” SG (itself) | Cluster |
| TCP | 3121 | “VPN” SG (itself) | Cluster |
| TCP | 21064 | “VPN” SG (itself) | Cluster |
| UDP | 5405 - 5405 | “VPN” SG (itself) | Cluster |
| UDP | 500 | 100.0.0.1/32 | Remote IPsec gateway |
| UDP | 4500 | 100.0.0.1/32 | Remote IPsec gateway |
| All Traffic | ALL | 172.16.0.0/16 | Need to pass traffic into VPN |
Other SG’s will need to be modified to allow traffic into the other nodes within the individual VPC’s. For example, for services on VPC 1 that are accessed by VPC 2, VPC 1 SG’s will need to allow the traffic from 172.20.0.0/16. Configuring these SG’s is beyond the scope of this document.
Elastic Network Interface (ENI)
The next step is to configure an ENI that will be used to go between our instances, controlled by the clustering software.
In the AWS EC2 Console under “Network & Security” there is a Network Interfaces. Create an interface that is on the desired subnet. Add the “VPN” Security group we created to it.
The “Source/Destination Check” on the ENI needs to be disabled. This is a very important step as network traffic will not pass through this interface if this check is not disabled. To disable, right-click on the newly created ENI and select “Change Source/Dest. Check”. It needs to be in the disabled state.
can we get some more explanation of why the default is wrong?