I have two Amazon AWS accounts, each with a VPC. Can I connect two VPCs is different accounts together?
Amazon doesn’t provide a manner to route traffic between VPCs in different accounts, but you can set up a “tunnel” yourself using two EC2 servers as “gateways” using the OpenSWAN VPN.
OpenSWAN is a free, open source, software VPN package for Linux. It can be used to establish a VPN tunnel between two Amazon AWS virtual networks (VPCs), even if those networks are in different Amazon regions/datacenters (“availability zones”)/accounts. A tested and working configuration example is provided here that connects two VPCs (which we will refer to as “Side A” and “Side B”) in two different Amazon accounts.
Each “side” of the VPN tunnel (each VPC) has an EC2 Linux server that functions as the VPN gateway server for it’s side, respectively. The gateway server is essentially an IP router to the “other side” of the tunnel using an AES-encrypted IPsec tunnel.
The example that follows uses the following IP addresses and IP subnets. It’s recommended that you make a similar table of addresses before you attempt to begin configuration:
|Side A||Side B|
|Gateway's Internal IP||192.168.1.0||192.168.2.0|
|Gateway's Elastic IP||184.108.40.206||220.127.116.11|
VPN Gateway servers
For starters, we need an EC2 Linux server configured on each side to serve as each side’s VPN gateway server. Each gateway machine needs an Amazon Elastic IP (EIP) assigned to it.
We need to ensure that Linux iptables firewalls and AWS Security Groups do not interfere with OpenSWAN. (Allow UDP 500 and UDP 4500 to enter from the other side’s Public IP, and you’ll probably want to allow TCP/22 also, so you can SSH in.) The easiest solution is to open all IP traffic in the firewalls between the two VPN servers, and once the VPN is configured and tested,
secure the servers with firewall rules appropriate to the application.
Before we configure the VPN, we need to install OpenSWAN on the EC2 VPN-gateway machine on each side:
We need to enable IP routing (“forwarding”) at bootup, on each side:
Edit /etc/sysctl.conf and add:
/etc/sysctl.conf on both sides
..and activate forwarding immediately by running:
Create identical /etc/ipsec.conf files on both sides (NOTE: indentation MATTERS!):
version 2.0 # conforms to second version of ipsec.conf specification config setup protostack=netkey nat_traversal=yes virtual_private=%v4:192.168.0.0/16 oe=off include /etc/ipsec.d/*.conf
Now we need to create the file on each side that defines this VPN connection. Note that “left” on “Side A” uses Side A’s “internal IP” and “right” on “Side A” uses Side B’s external EIP. (Note – indentation MATTERS!)
conn account1-account2 authby=secret left=192.168.1.10 leftsubnet=192.168.1.0/24 right=18.104.22.168 rightsubnet=192.168.2.0/24 pfs=yes auto=start leftid=192.168.1.10 rightid=192.168.2.10
..and vice-versa. “left” on “Side B” uses Side B’s “internal IP” and “right” on “Side B” uses Side A’s external EIP.
conn account1-account2 type=tunnel authby=secret left=22.214.171.124 leftsubnet=192.168.1.0/24 right=192.168.2.10 rightsubnet=192.168.2.0/24 pfs=yes auto=start leftid=192.168.1.10 rightid=192.168.2.10
Each side requires a “secrets” file on, so that both sides share a common password to establish the VPN link. Note that the order of the “this side” then “that side” IP addresses are reversed between the “secrets” file on “Side A” and “Side B”.
Make up a long password and copy it to each side’s “secrets” file (NOTE! On Debian/Ubuntu, just append this one line to each respective /etc/ipsec.secrets file instead):
192.168.1.10 192.168.2.10: PSK "ThisIsAReallyGoodPassword"
192.168.2.10 192.168.1.10: PSK "ThisIsAReallyGoodPassword"
Now we’re ready to activate it. Start the IPsec service on both sides:
..and make it start up automatically after boot:
Try to ping the internal (192.168.x.x) IP address of the gateway on the other side.
Root shell prompt on “Side B”
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=2.64 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=2.52 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=2.65 ms
--- 192.168.1.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2278ms
rtt min/avg/max/mdev = 2.520/2.606/2.655/0.085 ms
(NOTE: you will not see anything different in the output of ‘ifconfig -a’, nor will you see a route to the “other side’s” network in your routing table.)
It’s advisable to reboot the gateway servers to ensure that the VPN tunnel comes up automatically upon reboot.
If the tunnel is up, you should see:
Root shell prompt
IPsec running - pluto pid: 1310
pluto pid 1310
1 tunnels up
some eroutes exist
Check the /var/log/messages and /var/log/secure (Debian/Ubuntu: /var/log/syslog and /var/log/auth.log) for VPN messages. Note that on “Side A” the VPN will reach STATE_MAIN_R3, but on “Side B” it will reach STATE_MAIN_I4.