Engineered a Virtual Private Network
I recently created a secure site-to-site VPN connection between my employer’s instances and a customer’s on-premises network. This was done using Amazon Web Services (AWS) services and an instance running Openswan’s IpSec tunnel as the customer gateway on the client-side network.
This VPN connection allows for secure communication between these two networks over the internet, and its connection was securely successful by pinging from the employer’s network to the client-side instance and reciprocating a ping from the client-side to the employer’s instances.
The architecture of the site-to-site VPN connection is depicted in the diagram provided as proof of concept. The diagram clearly shows the two environments connected securely, with the client-side instance acting as the customer gateway for the client’s on-premises server.
Overall, my successful creation of a site-to-site VPN connection between my employer’s instances and the customer’s on-premises server network highlights the importance of a secure communication in today’s digital world. With the use of AWS services and Openswan’s IpSec tunnel software, I was able to create a secure and reliable connection that met the needs of my employer and their customer.
My Personal Site-to-Site VPN Instruction Notes:
# STEP 1 – Launch EC2 in ON-PREMISES VPC (Production Account)
# Launch EC2 instance:
# • Disable source/destination checks
# • Public subnet
# • Security group: 22, ICMP=ALL
# • Make a note of the public IP
# STEP 2 – AWS VPC Configuration (Management Account)
# Launch EC2 instance:
# • Public or private subnet
# • 22, ICMP=ALL
# Create a customer gateway:
# • Name: AWS-VPC-CGW
# • Routing: static
# • IP: public IP of on-premises EC2
# Create VGW
# Name: AWS-VPC-VGW
# Attach to VPC
# Create a VPN connection:
# • Name: ON-PREM-AWS-VPN
# • Target type: Virtual Private Gateway
# • Select the CGW and VGW
# • Routing: static – enter prefix: e.g. 172.31.0.0/16, 10.0.0.0/16
# Download VPN configuration as OpenSwan type
# STEP 3 – Enable route propagation for AWS VPC route table selecting the VGW (Management Account)
# STEP 4 – Configure OpenSwan on ON-PREMISES VPC EC2 Instance (Production Account)
# Run commands:
sudo su
yum install openswan -y
nano /etc/sysctl.conf
# Add:
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
sysctl -p
nano /etc/ipsec.d/aws.conf
# Paste the tunnel configuration for TUNNEL 1. This can be obtained from the file we downloaded last task of step 2. Example:
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=<Public IP of OpenSwan/CGW>
right=<Public IP of VGW – Tunnel 1>
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
keyingtries=%forever
keyexchange=ike
leftsubnet=172.31.0.0/16
rightsubnet=10.0.0.0/16
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
## IMPORTANT: REMOVE auth=esp from the code above if present
nano /etc/ipsec.d/aws.secrets
# Add single line: 54.169.159.173 54.66.224.114: PSK “Vkm1hzbkdxLHb7wO2TJJnRLTdWH_n6u3”
# ** The above can be found in the downloaded config file – MUST be updated with correct values ***
# Run commands:
systemctl start ipsec
systemctl status ipsec
# Connection should now be up
# Test by pinging in both directions and use additional host in on-premises DC to ping EC2 instance in AWS VPC (update route table)
code
Amazon Web Services
Virtual Private Cloud Config File: Openswan demo
AWS utilizes unique identifiers to manipulate the configuration of
a VPN Connection. Each VPN Connection is assigned an identifier and is
associated with two other identifiers, namely the
Customer Gateway Identifier and Virtual Private Gateway Identifier.
Your VPN Connection ID : vpn-< connection id >
Your Virtual Private Gateway ID : vgw-< virtual private gateway id >
Your Customer Gateway ID : cgw-< customer gateway id >
This configuration consists of two tunnels. Both tunnels must be
configured on your Customer Gateway, but only one of those tunnels should be up at any given time.
At this time this configuration has only been tested for Openswan 2.6.38 or later, but may work with earlier versions.
——————————————————————————————————————–
IPSEC Tunnel #1
——————————————————————————————————————–
This configuration assumes that you already have a default openswan installation in place on the Amazon Linux operating system (but may also work with other distros as well)
1) Open /etc/sysctl.conf and ensure that its values match the following:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
2) Apply the changes in step 1 by executing the command ‘sysctl -p’
3) Open /etc/ipsec.conf and look for the line below. Ensure that the # in front of the line has been removed, then save and exit the file.
#include /etc/ipsec.d/*.conf
4) Create a new file at /etc/ipsec.d/aws.conf if doesn’t already exist, and then open it. Append the following configuration to the end in the file:
#leftsubnet= is the local network behind your openswan server, and you will need to replace the <LOCAL NETWORK> below with this value (don’t include the brackets). If you have multiple subnets, you can use 0.0.0.0/0 instead.
#rightsubnet= is the remote network on the other side of your VPN tunnel that you wish to have connectivity with, and you will need to replace <REMOTE NETWORK> with this value (don’t include brackets).
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=< Public IP of OpenSwan/CGW >
right=< Public IP of VGW – Tunnel 1 >
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
auth=esp
keyingtries=%forever
keyexchange=ike
leftsubnet=<LOCAL NETWORK>
rightsubnet=<REMOTE NETWORK>
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
5) Create a new file at /etc/ipsec.d/aws.secrets if it doesn’t already exist, and append this line to the file (be mindful of the spacing!):
< Public IP of OpenSwan/CGW > < Public IP of VGW – Tunnel 1 >: PSK “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
——————————————————————————————————————–
IPSEC Tunnel #2
——————————————————————————————————————–
This configuration assumes that you already have a default openswan installation in place on the Amazon Linux operating system (but may also work with other distros as well)
1) Open /etc/sysctl.conf and ensure that its values match the following:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
2) Apply the changes in step 1 by executing the command ‘sysctl -p’
3) Open /etc/ipsec.conf and look for the line below. Ensure that the # in front of the line has been removed, then save and exit the file.
#include /etc/ipsec.d/*.conf
4) Create a new file at /etc/ipsec.d/aws.conf if doesn’t already exist, and then open it. Append the following configuration to the end in the file:
#leftsubnet= is the local network behind your openswan server, and you will need to replace the <LOCAL NETWORK> below with this value (don’t include the brackets). If you have multiple subnets, you can use 0.0.0.0/0 instead.
#rightsubnet= is the remote network on the other side of your VPN tunnel that you wish to have connectivity with, and you will need to replace <REMOTE NETWORK> with this value (don’t include brackets).
conn Tunnel2
authby=secret
auto=start
left=%defaultroute
leftid=< Public IP of OpenSwan/CGW >
right=< remote network IP >
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
auth=esp
keyingtries=%forever
keyexchange=ike
leftsubnet=<LOCAL NETWORK>
rightsubnet=<REMOTE NETWORK>
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
5) Create a new file at /etc/ipsec.d/aws.secrets if it doesn’t already exist, and append this line to the file (be mindful of the spacing!):
< Public IP of OpenSwan/CGW > < remote network IP >: PSK “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
——————————————————————————————————————–
(OPTIONAL CONFIG) Tunnel Healthcheck and Failover
——————————————————————————————————————–
Openswan does not provide a built-in tunnel failover functionality. However, there are some third-party workarounds to this.
=== DISCLAIMER ===
Please be aware that AWS is in no way responsible for any of the use, management, maintenance, or potential issues you may encounter with the third-party workarounds. It is strongly recommended that you thoroughly test any failover solution prior to implementing it into your production environment
Additional Notes and Questions
– Amazon Virtual Private Cloud Getting Started Guide:
http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide
– Amazon Virtual Private Cloud Network Administrator Guide:
http://docs.amazonwebservices.com/AmazonVPC/latest/NetworkAdminGuide
Ralph Quick Cloud Engineer
Ralph Quick is a professional Cloud Engineer specializing in the management, maintenance, and deployment of web service applications and infrastructure for operations. His experience ensures services are running efficiently and securely meeting the needs of your organization or clients.
