How can I connect two AWS accounts together?

Introduction

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.

Topology

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
AWS Account Account1 Account2
Internal Subnet 192.168.1.0/24 192.168.2.0/24
Gateway's Internal IP 192.168.1.0 192.168.2.0
Gateway's Elastic IP 34.193.20.150 34.193.47.24

Installation

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.

Firewalls

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.

Packages

Before we configure the VPN, we need to install OpenSWAN on the EC2 VPN-gateway machine on each side:

$ yum install openswan

Routing
We need to enable IP routing (“forwarding”) at bootup, on each side:

Edit /etc/sysctl.conf and add:

/etc/sysctl.conf on both sides

net.ipv4.ip_forward=1

..and activate forwarding immediately by running:

$ sysctl net.ipv4.ip_forward 1

Configuration

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=34.193.47.24
     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=34.193.20.150
     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:

$ /sbin/service ipsec start

..and make it start up automatically after boot:

$ chkconfig ipsec on

Testing

Try to ping the internal (192.168.x.x) IP address of the gateway on the other side.

Root shell prompt on “Side B”

$ [ec2-user@ip-192-168-2-10 ~]$ ping 192.168.1.10
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
^C
--- 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
[ec2-user@ip-192-168-2-10 ~]$

(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.

Troubleshooting

If the tunnel is up, you should see:

Root shell prompt

$ [root@ip-192-196-1-10 log]# service ipsec status
IPsec running - pluto pid: 1310
pluto pid 1310
1 tunnels up
some eroutes exist
[root@ip-192-196-1-10 log]#

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.

$ [root@ip-192-196-1-10 log]# ipsec verify

References

http://aws.amazon.com/articles/5472675506466066

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Reddit
  • StumbleUpon

Leave a Reply

Your email address will not be published. Required fields are marked *