Connecting to Amazon VPC


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

Figure 1: Amazon’s VPN architecture
Figure 1: Amazon’s VPN architecture

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 For redundancy reasons amazon builds up two VPN tunnels with endpoint ip for tunnel #1 and for tunnel #2. You will need an ISAKMP daemon listening on your public ip which will manage the two IPSec connections.

For each tunnel you need to set up an internal network device in the net for tunnel #1 and for tunnel #2. On Amazon’s side of each VPN tunnel there is a BGP router for tunnel #1 and for tunnel #2. From your internal ip for tunnel #1 you need to establish a BGP peering with that BGP router 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 will use tunnel #1 and any packet that gets routed over will be sent over tunnel #2.

So a packet from our internal net (let us say which is addressed to our subnet in Amazon’s VPC (let us say 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 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 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 any -P in ipsec

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

spdadd any -P in ipsec

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, destination (, 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 ). 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.


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.

11 thoughts on “Connecting to Amazon VPC

  1. Pingback: Kindle Refurbished
  2. Pingback: filmy download
  3. Hi, thank you for this summary. I have run across the same issue and could not believe, that this simple setup cannot be done with linux standard tools. However, I succeeded to establish one connection with openswan and the mentioned patches. I would be happy, if we could discuss this issue via mail?

    Best regards,

    1. Establishing just one of the two connections is no problem. But two connections and failover is not that easy.

  4. Hey, thanks for the article. Would you please clarify what you mean by “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.” AFAIK once you insert and entry for your home network in the routes table of your subnet, traffic flowing from instances within that subset should reach your home network and this does not require individual configuration of each vpc instance. Am I wrong?

    1. I think as I wrote that post I was thinking about the operating system route tables of each host. I think your solution would work. Would be nice to hear from you if you try it.

  5. Thanks for this article. I’ve been following the instructions on and it’s been driving me nuts because setkey wouldn’t let me have double security associations. And the fact that it was the top search result on google made me think it worked. I mean the tunnels are up but obviously, one of the SA’s errors out and it says “file exists.” I guess there’s real no good solution with Linux servers. We’re deciding on how we’re going to script automatic failover or maybe just buy another network device.

    1. Hi Andrew,

      take a look at the tool cfgvti of the vyatta router.

      Best regards,

  6. Thanks for the article. I reached here after successfully setting up the tunnel using OpenSwan and static routes but trying to switch to use BGP instead of static routes while trying to decipher the configuration provided by the VGW proves tricky. Would you know how to map the VGW configuration to OpenSwan’s ipsec.conf terms?

Comments are closed.