Connecting to Amazon VPC

Overview

Amazons virtual privacy cloud service (VPC) offers great outsourcing possibilities for your less private (but still private) services.

Consider a Jenkins build server. You have got one on your local machine but sometimes it’s just too much load for your hardware. It would be nice in such a case to just push some load into the cloud. Clearly you can not just put a Jenkins server into the cloud because it will need access to various services like at least some repository (Git, SVN). To protect that cloud-internal traffic (you do not want other Amazon customers to see your source code) one should use VPC. And for a seamless integration into your existing infrastructure you will need a VPN tunnel from the Amazon VPC to your local network.

Amazon offers the possibility to create such a VPN connection to your VPC. You may set up your own VPN server in your VPC but in our opinion it is easier and cheaper to use Amazons solution. Because it seemed less pricy we first tried to just use open-source software for that VPN server.

How Amazon builds up a VPN

In figure 1 you see an overview of the VPN connection, how Amazon requires it. Let us say our VPN server has a public ip 1.2.3.4. For redundancy reasons amazon builds up two VPN tunnels with endpoint ip 87.238.85.40 for tunnel #1 and 87.238.85.44 for tunnel #2. You will need an ISAKMP daemon listening on your public ip 1.2.3.4 which will manage the two IPSec connections.

For each tunnel you need to set up an internal network device in the net 169.254.254.0/30 for tunnel #1 and 169.254.254.4/30 for tunnel #2. On Amazon’s side of each VPN tunnel there is a BGP router 169.254.254.1 for tunnel #1 and 169.254.254.5 for tunnel #2. From your internal ip for tunnel #1 169.254.254.2 you need to establish a BGP peering with that BGP router 169.254.254.1 and for tunnel #2 you need to do the same with the other two ips.

This is a route based VPN that means in our case any package that gets routed over the net 169.254.254.0/30 will use tunnel #1 and any packet that gets routed over 169.254.254.4/30 will be sent over tunnel #2.

So a packet from our internal net (let us say 192.168.1.0/24) which is addressed to our subnet in Amazon’s VPC (let us say 10.0.1.0/24) will get routed to one of the two BGP servers on Amazon’s side. To get there it will use the appropriate VPN tunnel and from the BGP server it will be sent to some Amazon-internal router. From there it will finally be delivered to our VPC. Sending a packet from the VPC to our home net is just the reverse way.

Amazon leaves no room for individual configuration. According to Amazons VPC-FAQ your device must be able to: (requirement list copied from there)

• Establish IKE Security Association using Pre-Shared Keys
• Establish IPsec Security Associations in Tunnel mode
• Utilize the AES 128-bit encryption function
• Utilize the SHA-1 hashing function
• Utilize Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode
• Establish Border Gateway Protocol (BGP) peerings
• Bind tunnels to logical interfaces (route-based VPN)
• Utilize IPsec Dead Peer Detection
• Perform packet fragmentation prior to encryption

Most points are supported by nearly all VPN servers that use IPSec for their tunnels. The most important points to look out for are:

• Establish Border Gateway Protocol (BGP) peerings
• Bind tunnels to logical interfaces (route-based VPN)
• Utilize IPsec Dead Peer Detection

Even if you look at the officially supported Cisco hardware like the Cisco ISR 880 series, you have to watch out for BGP support. Sometimes you need a software upgrade like (in case of the Cisco 880 series) the “Advanced IP Services”- upgrade. Whether a device or software supports route-based VPNs or not is oftenly not stated directly. You will have to look deeper into the manuals and descriptions to find out about that. If it just supports policy-based VPNs, it will not support route-based VPNs out of the box. Dead Peer Detection sometimes is not available on older devices (or software).

The Choice of VPN Servers

There is a list of officially supported VPN servers:

• Cisco ISR running Cisco IOS 12.4 (or later) software
• Juniper J-Series Service Router running JunOS 9.5 (or later) software
• Juniper SSG running ScreenOS 6.1, or 6.2 (or later) software
• Juniper ISG running ScreenOS 6.1, or 6.2 (or later) software
• Yamaha RTX1200 router

If you start using VPC you maybe just want to test it and do not want to spend much money for it (like for the above hardware). So it seems a good idea to use some linux box as VPN server. IPSec is implemented in the kernel and for ISAKMP you may want to use some daemon like racoon, Openswan, FreeS/WAN, or strongSwan.

Using Linux as VPN Server

Let us say you have decided to use some linux for your VPN server. For an IPSec newbie there is no obvious reason that this is a bad idea. And because one soon finds a tutorial like http://openfoo.org/blog/amazon_vpc_with_linux.html it seems possible to perform that task. Following this tutorial you should be able to ping the two BGP servers from your VPN server. And that means your IPSec tunnels are both up and working. But after that point you will start to get in trouble. Maybe you are able to connect to a server in your VPC. But there is one thing you won’t get working stable: Connecting from the VPC to some server in your home net 192.168.1.1/24. That is because linux has a policy-based IPSec implementation.

To connect your home net to the VPC net you need a policy like

spdadd 10.0.0.0/24 192.168.1.0/24 any -P in ipsec
    esp/tunnel/87.238.85.40-1.2.3.4/require;

If a packet from your VPC net gets routed over the tunnel #1 (over 87.238.85.40) everything
works fine. But if a packet from your VPC get’s routed over the other tunnel (over 87.238.85.44)
you’ve got a problem. Because you would need an additional policy like

spdadd 10.0.0.0/24 192.168.1.0/24 any -P in ipsec
    esp/tunnel/87.238.85.44-1.2.3.4/require;

to make your linux box unpack and forward that IPSec packet. That is a problem because you can not have two policies with the same source (here 10.0.0.0/24), destination (192.168.1.0/24), protocol (any), direction (in), and method (ipsec). This is why amazon requires a route-based VPN.

One workaround would be to connect just one tunnel. But this is not a good idea because you sacrifice the reliability of the VPN connection. As another workaround there are some dirty tricks to simulate a route-based VPN with Openswan (like http://lists.openswan.org/pipermail/users/2011-February/020123.html ). This, in our opinion, is not a good idea as well. This is because: First you need to use KLIPS (an older IPSec implementation) which has a rather bad reputation in the community. Second you need to apply a patch from some newsgroup. And the last and most important reason is that Openswan is not intended to be used that way. Abusing software in a security relevant place doesn’t seem to be a good idea.

Conclusion

There are two important things you won’t achieve going the linux-as-VPN-server way:

1. an easy to administer and supported solution
2. having a cost effective solution

The first point is because the linux IPSec implementation is not meant to be used for route-based VPNs. If it is possible, you’ll need some really dirty tricks. The second point is because for the officially supported devices Amazon offers generated configuration files. And these hardware routers are not as pricy as you think. For example a Cisco ISR 880 series CISCO881-SEC-K9 is available between 350-400€ (incl. VAT).

Our next step is to try an Amazon-supported solution. We will also post our experiences with that solution.

If you just want to try out VPC for a short time (like a few days) you may set up an OpenVPN server on a cloud instance in your VPC (and another OpenVPN server in youre home net). This solution will only cost less than the hardware solution if you are familiar with OpenVPN. This OpenVPN solution is only suitable for very small VPCs because you will need to adjust the routes on every instance inside the VPC manually.