Overview
Amazon Virtual Private Cloud (Amazon VPC) provides customers with tremendous network routing flexibility. This document describes how a customer can create a secure IPSec tunnel to connect multiple VPCs into a larger virtual private network that allows instances in each VPC to seamlessly connect to each other using private IP addresses.
Amazon Virtual Private Network Components
Please reference the Amazon Virtual Private Cloud Network Administrator Guide for complete VPC networking documentation; however, the following definitions, example configuration, and diagram may be helpful for understanding the content of this paper.
Internet Gateway (IGW)
The IGW is an egress point from a customer's VPC that allows public Elastic IP (EIP) addresses to be mapped to VPC instances. IGW provides public address mapping that allows ××× instances in each VPC to communicate with each other. When communicating between VPCs in different AWS Regions, the Internet gateway routes the ××× connections over the Internet. However, when communicating between VPCs in the same AWS Region, the IGW routes traffic directly between the VPCs using the AWS network.
IPSec Connection
An IPSec ××× connection between two EC2 ××× instances that is used to virtually connect the two VPC networks.
Example VPC Setup
This guide will use the following VPC configuration for illustrative purposes:
Additional Considerations
The IPSec connections require each ××× instance to live in a public subnet and have an EIP address.
××× instances are a potential single point of failure. Please see the appendix for a high-level High Availability design for this component
This lab provides examples using Amazon Linux and standard Amazon Linux packages.
This guide assumes you already have two or more VPCs created. For instructions on creating VPCs, please see the Amazon Virtual Private Cloud Getting Starting Guide.
In this scenario, AWS manages the IGW and the customer is responsible for managing their EC2 instances and the IPSec connections.
Configuration Walkthrough
In this walkthrough, we will perform the following steps:
1. Launch EC2 ××× instances
2. Configure ××× server software on the EC2 instances
3. Connect additional VPCs (if needed)
To launch Amazon EC2 ××× instances
1. Launch two Amazon Linux instances, one in each VPC public subnet, with the following characteristics:
1). Assign the ××× instance a static private IP address (not required, but makes setting up the configure files much easier). In this example we will use 10.0.0.5 and 172.16.0.5.
2). Allocate two VPC EIPs (or one VPC EIP in each region) and associate an EIP to each ××× instance. In this example we will use EIP1 and EIP2 to represent the EIPs for VPC 1 and VPC 2 respectively.
3). Ensure the Security Groups associated with each instance allow UDP 500, UDP 4500, IP 50, and IP 51 between each other's EIP.
2. Disable Source/Dest checking on both instances by right-clicking on the instances and selecting Change Source/Dest. Check.(Personal note: this step is very important)
3. Configure Routing Tables in both VPCs to send traffic to the "other" VPC through the VPC EC2 instances.VPC #1 Main Route Table
VPC #1 Main Route Table
VPC #2 Main Route Table
To configure ××× server software on Amazon EC2 instances
1. Connect to each EC2 ××× Instance and install the openswan package with the following command:
Prompt> sudo yum install openswan
2. Edit the /etc/ipsec.conf file (as root) to include files in /etc/ipsec.d/*.conf (uncomment the last line by removing the '#' on the first character of the last line so it looks like the following):
Prompt> sudo vi /etc/ipsec.conf
# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual: ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
# plutodebug="control parsing"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
virtual_private=
oe=off
# Enable this if you see "failed to find any available worker"
# nhelpers=0
#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this.
include /etc/ipsec.d/*.conf
3. Create the following files in /etc/ipsec.d (as root)
(1) VPC1/EIP1 Instance
Prompt> sudo vi /etc/ipsec.d/vpc1-to-vpc2.conf
conn vpc1-to-vpc2
type=tunnel
authby=secret
left=%defaultroute
leftid=
leftnexthop=%defaultroute
leftsubnet=
right=
rightsubnet=
pfs=yes
auto=start
Prompt> sudo vi /etc/ipsec.d/vpc1-to-vpc2.secrets
(2) VPC2/EIP2 Instance
Prompt> sudo vi /etc/ipsec.d/vpc2-to-vpc1.conf
conn vpc2-to-vpc1
type=tunnel
authby=secret
left=%defaultroute
leftid=
leftnexthop=%defaultroute
leftsubnet=
right=
rightsubnet=
pfs=yes
auto=start
Prompt> sudo vi /etc/ipsec.d/vpc2-to-vpc1.secrets
4. On both instances, perform the following steps:
1). Start IPSec/Openswan
Prompt> sudo service ipsec start
2). Configure IPSec/Openswan to always start on boot
Prompt> sudo chkconfig ipsec on
3). Configure the Linux instances to route traffic by editing /etc/sysctl.conf and change the net.ipv4.ip_forward, net.ipv4.conf.all.accept_redirects, and net.ipv4.conf.all.send_redirects variables.
Prompt> sudo vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
4). Restart your network settings for the network forwarding settings to take effect
Prompt> sudo service network restart
Checking ××× Status
The following commands can be helpful in checking or troubleshooting your ××× status:
Prompt> sudo ipsec verify
(checks the status of the services required for OpenSWAN to run properly)
Prompt> sudo service ipsec status
(checks the status of the OpenSWAN service and the ××× tunnels)
Connecting Additional VPCs
You can connect additional VPCs by simply repeating the steps above while creating additional IPSec configuration and secrets files in /etc/ipsec.d. For example, on VPC1/EIP1 instance, /etc/ipsec.d could have the following files to connect a 3rd and 4th VPC via ×××:
vpc1-to-vpc2.conf
vpc1-to-vpc2.secrets
vpc1-to-vpc3.conf
vpc1-to-vpc3.secrets
vpc1-to-vpc4.conf
vpc1-to-vpc4.secrets
The EC2 ××× instances in these additional VPCs would have corresponding files like those created for VPC #2 above.
Appendix: High-Level HA Architecture for ××× Instances
Creating a fully redundant VPC connection between VPCs in two regions requires the setup and configuration of four ××× instances and monitoring instances to monitor the health of the ××× connections.
We recommend configuring your VPC route tables to leverage all ××× instances simultaneously by directing traffic from all of the subnets in one Availability Zone through its respective ××× instances in the same Availability Zone. Each ××× instance will then provide cross-VPC connectivity for instances that share the same Availability Zone.
××× Monitoring Instance(s)
The ××× Monitor is a custom instance that you will need to create and develop monitoring scripts to run on. This instance is intended to run and monitor the state of ××× connection and ××× instances. If a ××× instance or connection goes down, the monitor will need to stop, terminate, or restart the ××× instance while also rerouting traffic from one subnet to the working ××× instance until both connections are functional. High Availability for Amazon VPC NAT Instances: An Example provides an example of a script that could be modified to run on the ××× instances or a separate monitoring instance to preform this function.
source address: https://aws.amazon.com/articles/5472675506466066