AWS Transit Gateway VPN to VPC
AWS Transit Gateway was launched at Re:Invent November 2018 — it can massively simplify networking that involves multiple VPCs, VPNs, and shared services.
Use Case (Simplified)
I have separate AWS accounts for staging and prod. I also need VPNs so that my on-prem resources can get bi-directional access to both the staging and prod. This includes my on-prem VPN access for operations tools.
There must be no connectivity between staging and prod.
Transit Gateway Concepts
The Transit Gateway is (mostly) well described in the AWS Transit Gateway
transit gateway- a network transit hub that you can use to interconnect your virtual private clouds (VPC) and on-premises networks.
attachment- You can attach a VPC, and AWS Direct Connect gateway, or a VPN connection to a transit gateway.
transit gateway route table- A transit gateway has a default route table and can optionally have additional route tables. A route table includes dynamic and static routes that decide the next hop based on the destination IP address of the packet. The target of these routes could be a VPC or a VPN connection. By default, the VPCs and VPN connections that you attach to a transit gateway are associated with the default transit gateway route table.
associations- Each attachment is associated with exactly one route table. Each route table can be associated with zero to many attachments.
route propagation- A VPC or VPN connection can dynamically propagate routes to a transit gateway route table. With a VPC, you must create static routes to send traffic to the transit gateway. With a VPN connection, routes are propagated from the transit gateway to your on-premises router using Border Gateway Protocol (BGP).
I found route propagation unclear — so here is my alternative, less formal and more verbose explanation!
A transit gateway route table has a set of routes (a mapping of CIDR blocks to destinations, so AWS can determine the next hop for routing an IP packet). In the route table’s configuration, if you choose to “propagate” a VPC, it will automatically add the CIDR block of that VPC to the route table. Similarly if you “propagate” an end-to-end VPN, it automatically adds the CIDR blocks for that VPN (which could be statically defined in the VPN, or dynamically if using BGP).
When you “associate” a VPC with a route table, you are telling it to use that route table for packets coming from that VPC (i.e. it will be able to route to everything that propagates to that route table, and to other statically defined routes that you add).
A VPC (or VPN) can be associated with at most one route table. However, a VPC (or VPN) can “propagate” to multiple route tables.
To allow an EC2 instance within a VPC to send traffic via routes defined in the transit gateway, you have to reconfigure the VPC subnet’s route table. You need to add static routes for the desired CIDR blocks, pointing at the transit gateway.
Let’s look at a concrete example.
Network Topology
I’ll use one AWS accounts, along with AWS Organizations:
- staging: contains a VPC with CIDR block 172.0.0.0/16
- production: contains a VPC with CIDR block 172.1.0.0/16
I already have a VPN device on-prem, where the on-prem address range is 172.24.0.0/16.
Create Transit Gateway
- To create the transit gateway in the ‘production’ account, I go to the VPC service, choose `Transit Gateways`, and choose `Create Transit Gateway`. I fill in the details as shown below:
Configured Open Swan on-premises network
If you use AWS Cloud services and want to connect Amazon Virtual Private Cloud (Amazon VPC) from your on-premises network, you can use Openswan for this purpose.
In this article, we will be showing you how you can configure site-to-site VPN between Openswan and AWS VPN. We will be launching Openswan Instance in AWS itself (as an on-premise environment) and create a VPN connection using the Elastic IP address of Openswan in the AWS VPN console. We will then download the VPN configuration from the AWS VPN console and configure it in the Openswan instance.
STG Environment:
1. Launch an instance using an Amazon Machine Image (AMI) in your Openswan VPC.
2. Attach an Elastic IP address in the network interface (Eth0) of the instance you just launched. If you choose to auto-assign the IP address when launching the instance, the IP address changes after the instance is restarted. Be sure to note the instance’s public IP address.
3. Now we will be configuring the prerequisite for VPN in AWS. We will need to create CGW(Customer gateway, in our case Openswan), VGW(Virtual Private gateway which is AWS VPN), and then create a VPN connection between CGW and VGW.
In your preferred AWS region, create a customer gateway for your Amazon VPC. Be sure to choose the Amazon VPC that you want to connect to over a virtual connection using Openswan. Be sure to use the IP address you noted in the previous step.
4. Disable source destination check on Openswan instances.
5.Attach VPN
I’ll attach the VPN to the transit gateway.
First I create a Customer Gateway:
Next, I create the VPN Connection. Note this is created and managed via the Transit Gateway Attachment, rather than in the VPN section of the AWS console (even though it is subsequently listed in the VPN section). However, if you need to delete the VPN connection then it must be done through the VPN section.
STG Environment
PRD Environment
VPN
5.Connect to your Openswan instance
- $ yum install openswan lsof -y
- $ vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
- $ sysctl -p
- $ cd /etc/ipsec.d/
STG Environment
- $ vim aws.conf
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=13.236.175.157
right=18.139.245.20
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
keyingtries=%forever
keyexchange=ike
leftsubnet=172.24.19.0/24
rightsubnet=0.0.0.0/0
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
- $ vim aws.secrets
3.104.53.150 3.1.43.139: PSK “Db_Se5dCCCT.aveMNFq7M9E74.rYCtHZ”
PRD Environment
- $ vim aws.conf
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=54.253.163.40
right=52.76.145.99
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
keyingtries=%forever
keyexchange=ike
leftsubnet=172.24.19.0/24
rightsubnet=0.0.0.0/0
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
- $ vim aws.secrets
54.253.163.40 52.76.145.99: PSK “13ji1dCYIWHVhRWMVT7jUJK0x_EeLVj3”
- $ ipsec verify
- $ systemctl start ipsec.service
- $ systemctl enable ipsec.service
- $ ipsec auto –status
Check Site-to-Site Tunnel Status
STG Environment
PRD Environment
- Attach VPCs
I then attach my two VPCs to the transit gateway.
STG Environment
PRD Environment
8.Create Transit Gateway Route Tables: for VPN
I create the first route table that the VPN will use. I’ll “associate” the VPN so that it can make use of this route table; I’ll “propagate” the VPCs so that their CIDR block(s) are added to the route table. This allows packets from the VPN to be routed to the VPCs.
- Associations
- Propagations
- Routes
This shows that the VPN is “associated” with the transit gateway route table so traffic coming from that VPN can use this route table. The two VPCs “propagate” their CIDR blocks into the route table, so the VPN’s traffic can be routed to these two VPCs.
Create Transit Gateway Route Tables: for VPCs
Next, I repeat these steps for a route table that the VPCs will use. I’ll “associate” the VPCs so that they can make use of this route table; I’ll “propagate” the VPN so that its CIDR block(s) are added to the route table.
- Associations
- Propagations
- Routes
VPC Subnet Route Tables
We still need to tell the VPC subnets’ route tables to route traffic to the transit gateway.
I open the route table for the first VPC subnet (in the VPC service, I click on subnets, find my subnet and click the “route table” link).
I add a route so that traffic being sent from the VPC to on-prem will go via the Transit Gateway. I choose the on-prem CIDR (172.24.19.48/32) and from the drop-down, I choose “Transit Gateway” and then my transit gateway’s ID.
STG Environment
PRD Environment
Openswan VPC Subnet Route Tables
Testing
We’re done! Let’s test if this works.
I have three private VMs, each listening on an open TCP port: one VM in each VPC and one on-prem. I check that from the on-prem VM I can reach each of the VPC VMs, and vice-versa. I check that from the ‘staging’ VM I cannot reach the ‘production’ VM, and vice-versa.
