AWS VPN – Lasso Your VPC w/ AWS VPN Connections (Part 1 of 2)

By Tyler Holmes

What IaaS Means To You

These days Infrastructure-as-a-Service has almost become as common-place as the ubiquitous Software-as-a-Service. Particularly in the last decade as the concept of Cloud Computing has evolved to become a more mainstream, affordable and sensible option. Small organizations looking to leverage economies of scale are no longer faced with stacking costly servers into environmentally controlled back rooms along with the payroll of the IT staff required to maintain said servers. For the price of the monthly power bill used to run on-premise equipment, organizations can deploy their infrastructure into the cloud, and immediately gain all of the benefits of a large-scale data center, boasting features such as “geographic redundancy” and “high availability” which were terms previously limited to an exclusive club of deep-pocketed organizations.

As organizations begin to migrate infrastructure to a permanent home in the clouds, certain questions often come into play. How much of an organization’s infrastructure can be moved? What equipment should remain on-premise and why? As internet service providers continue to offer increasingly speedy connections (a business-class Comcast connection at 100/20mbps in my area comes in at about 25% the cost of a traditional T1), it becomes completely feasible to operate practically all of your back office infrastructure in the cloud.

Needs of the Local Area Network

The ability to shift back office infrastructure into a highly available cloud environment is great, but the aforementioned questions still remain. How much of that infrastructure makes sense to migrate? Despite the advancements in technology, organizations still have offices with employees that require computer workstations to perform their jobs. These systems require network connectivity not only to the internet, but to each other and to the back office infrastructure for simple things such as file sharing, centralized IT management, authentication, and last but not least – the mission-critical applications a business runs on such as CRM and ERP systems.

Picking up the entire back office and moving it to the cloud would wreak havoc on an office full of workstations pining for a server to talk to. Unless those workstations were unable to tell that the back office was anywhere other than the next room over.

Lassoing the Cloud with VPN

Fortunately for the sake of the office, VPN is here to save the day. The concept of always-on site-to-site VPNs is nothing new – they have been used to connect remote offices to each other and to corporate HQ since the advent of leased lines and frame relays. Thankfully most cloud service providers, such as Rackspace and AWS, provide VPN Gateway products to establish a cloud end-point to connect your office to the cloud in an always-on fashion. If your cloud service provider does not have this product available, it is possible to roll your own VPN Gateway using OpenVPN, which I will cover in part 2 of this article.

For this article, I’ll be covering the process and procedure to connect an office LAN behind a ZyXEL USG 50 to an AWS VPC. When setting up a VPN with AWS it is often noted that the ready-made configuration files offered by AWS are suited for a class of device on par with a Cisco ASA device, and don’t really cater to the smaller organizations who favor more affordable options such as SonicWalls and ZyXELs. We will be picking apart these configuration files and extracting the useful bits to enable our smaller-scale equipment to stand up a reliable connection.

Establishing the VPC

I will be configuring a VPC in AWS that consists of 2 subnets. One subnet will be public and serve as somewhat of a DMZ. The servers in this subnet will have their own elastic IP addresses by which they’ll access the internet. The other subnet will be private and obscured behind an EC2 instance serving to provide NAT services. EC2 instances in both subnets will be protected by general AWS security policies, as well as their own firewalls. EC2 instances within the private subnet will have an additional layer of protection afforded by the instance providing NAT.

Topology and Network Considerations

Before you begin, it is absolutely critical to be thoughtful about your topology and network approach/strategy. Once the VPC is created and filled with EC2 instances, you cannot alter the network configuration without tearing the whole thing down. Again, I cannot stress this enough – give careful consideration to how you plan to layout your network. My local office uses a 10.0.0.0 with a 24 bit subnet mask (10.0.0.0/255.255.255.0) for the network ID. All hosts in the 10.0.0.x network are considered “local” and will send/receive traffic on the 10.0.0.x network segment without bouncing through a default gateway.

To stay within my class-A address space, but to differentiate enough to be easily recognizable (and allow for large growth on my local and remote office LAN side), I’m going to establish my VPC at AWS using a CIDR of 10.254.0.0/16. Within that VPC, I will establish two subnets – one at 10.254.0.0/24 for public/DMZ servers and one at 10.254.1.0/24 for private/NAT’ed servers. Both subnets will be readily available to my office LAN as I will be utilizing both tunnels to route traffic to both the 10.254.0.0/24 network and the 10.254.1.0/24 network, so fear not, faithful reader.  The reason I’m not routing to the 10.254.0.0/16 network is due to a limitation with the ZyXEL router, which we’ll cover in a moment.

Using the AWS VPC Wizard makes it quick and easy to spin up this VPC configuration. Just look for the option to create a VPC with a public and private subnet, with the private subnet accessing the internet by way of a NAT instance.

Once you have the configuration set the way you’d like, click the “Create VPC” button and AWS will tee up your public and private subnets along with an EC2 instance in the public subnet complete with a public Elastic IP that will act as a NAT instance for your private subnet.

Setting Up VPN Endpoints

Configuring the Far End

Now that our VPC is up and running with public and private subnets, we’ll begin setting up the various bits that will make connectivity to our local office via IPSec tunnel possible.

  1. The first step is to create a customer gateway in AWS. The customer gateway represents the WAN side of our local office.
    • From the VPC Dashboard, click the “Customer Gateways” option, and then click the button to “Create Customer Gateway.”
    • Enter the details about our local office. I’ve entered the WAN IP address of the local office router along with a name identifying the local office. I will also be specifying static routing as my office’s router does not support Border Gateway Protocol (BGP).
    • Click the “Yes, Create” button and after a moment your Customer Gateway appears in the list as “available.”
  2. Next we’ll create a Virtual Private Gateway. This represents the router on the AWS side of the equation.
    • From the VPC Dashboard, click on “Virtual Private Gateways” and then “Create Virtual Private Gateway.”
    • Give it name and click the “Yes, Create” button. After a moment, the new gateway appears in the list with a status of “detached.”
    • Select the gateway and click the “Attach to VPC” button. Choose the VPC from the list and click “Yes, Attach.”
  3. Now we’ll create our VPN connection tying our customer gateway we created in step 1 to the virtual private gateway we created in step 2. With each office that we connect to the VPC, we’ll need to establish an additional customer gateway and an additional VPN connection. Unless you’re wanting to employ some specific access rules or routing strategies, you can stick with a single virtual private gateway for now.
    • From the VPC Dashboard, click on “VPN Connections” and then the “Create VPN Connection” button.
    • Name your new VPN connection in a manner that describes what it is connecting (I called mine Beaverton_AWS_Tunnel).
    • Select the virtual private gateway created in step 2 and the customer gateway created in step 1. Again, since my router doesn’t support BGP, I’m opting for static routing.
    • Since I’ve chosen to employ static routes, I’ll need to specify the network ID in CIDR notation of the local office that should be advertised to the VPC. In my case, I’ve entered 10.0.0.0/24.
    • Click the “Yes, create” button, and after a few moments your VPN connection should appear in the list as available.

    I have occasionally run into issues here where AWS indicates an error citing that the VPN connection was created, but it was unable to setup the static routes. If the VPN connection fails to appear after a few moments, you may have to try creating it again. Otherwise, if it appears as expected, select it in the list and then click on the “Static Routes” tab below to verify that the static route you specified is indeed listed. If it is not, you may enter it manually here.

  4. The final step in configuring the VPN is to have a look at our routing tables and security policies. After we created the VPC, an EC2 instance was created for us in the public subnet to serve as a gateway for any instances we spin up in the private subnet. In setting up this NAT instance, a couple of routing tables and a security group was created.The security group was flagged as the default security group for the entire VPC, allowing any EC2 instances that are members of this group to have all-traffic access to each other across both private and public subnets within the VPC. In order to allow access to the machines in this security group from machines on the other side of our VPN connection, we’ll need to add an additional rule that opens the door for our local office network.Additionally some route tables have been setup.  There’s are two – one is used to route traffic out of the internet gateway for the VPC.  This route table is used by machines in the public subnet to bounce traffic heading for non-local networks to the standard gateway.  The other route table is used by the private subnet, and routes traffic to the network interface on the NAT instance.
    • From the VPC Dashboard, click on “Security Groups” and locate the default security group for your VPC.
    • Select the security group and then click on the “Inbound Rules” tab below.
    • Click the “Edit” button and then the “Add Another Rule” button.
    • Set this new rule up to allow “All Traffic” and “ALL” protocols from a source that is the CIDR of the local office, in my case – 10.0.0.0/24.
    • Next, click on the “Route Tables” section and examine your route tables – there should be two.  Ensure that your subnets are explicitly associated with the appropriate table.  Often times, the private subnet does not have an explicit association and defaults to the “main” route table – which forwards traffic bound for 0.0.0.0/0 to the network interface attached to the NAT instance.  Define this association explicitly.
    • Select each subnet and examine the Route Propagation tab.  This is used to advertise the Virtual Private Gateway created in step 2 within this route table.  Determine if you’d like visibility to the VPN gateway and if so, edit and click the checkbox to propagate the Virtual Private Gateway within the appropriate route tables.

Now that we’ve configured all the pieces on the AWS side, the next step is to configure our local office to connect. We’ll need some configuration settings to do this, and thankfully those settings are pretty easy to find.

From the VPC Dashboard, click on VPN Connections and then select the VPN connection you created in step 3. Note the “Download Configuration” button above the list. Click on this button and choose a configuration format that matches your hardware at your local office. If you’re like me and using small business class equipment that isn’t listed, choose the generic option and download the file.

Configuring the Local Office

At the local branch office, we’re using a ZyXEL USG 50. This router is not listed in the available configuration files to download from AWS, so we’ll be using the generic/platform-agnostic version of the configuration file. The generic config isn’t really a configuration file per se, it’s just a simple document that provides the settings necessary for setting up IPSec tunnels on any device capable of supporting an IPSec VPN.

Amazon’s VPN sets up two IPSec tunnels to provide failover.  Unfortunately the ZyXEL USG 50 is not capable of keeping both tunnels open at the same time when they route to the same subnet.  In order to make use of both tunnels, we’ll use one tunnel to route traffic to our public subnet, and the other to route traffic to our private subnet.  The ZyXEL doesn’t seem to mind if a packet sent down one tunnel is responded to over the other, and there’s the added bonus of both tunnels being online at the same time – which removes the warning message on the AWS VPC dashboard that one tunnel is down, and also allows us to quickly establish a manual route if one of the tunnels should fail.

  1. First we’ll need configure a couple of address objects to represent our different VPC subnets.  In the ZyXEL configuration page, navigate to Object -> Address and click “Add.”
  2. Define an address of type subnet, one for each VPC subnet.  I created an “AWS_Public” and “AWS_Private” address subnet object of 10.254.0.0 / 255.255.255.0 and 10.254.1.0 / 255.255.255.0 respectively.
  3. Next we’ll need to create the gateways.  In the ZyXEL configuration page, navigate to VPN -> IPSec VPN and click the “VPN Gateway” tab. Add a new VPN gateway.
  4. We’ll setup a VPN gateway for each one of the AWS tunnels.  Click the link to “Show Advanced Settings,” and then using the generic configuration document we downloaded at the end of the previous section, enter in the following elements:
    1. Peer Gateway Static Address (this is the outside IP address of the AWS Virtual Private Gateway for tunnel #1)
    2. Pre-Shared Key
    3. SA Lifetime (should be 28800)
    4. Proposal (should switch to AES128 / SHA1)
    5. Key Group (should be DH2)
  5. Repeat this same sequence of steps for Tunnel #2.  In the end you should have two VPN Gateways – one for each tunnel.
  6. Now it’s time to setup the actual VPN Connections.  On the ZyXEL Configuration page, click VPN -> IPSec VPN. Click “Add” to create a new VPN Connection.
  7. We’ll create a new VPN connection for each of the VPN Gateways we created in step 4 and 5.  The difference is that the remote policy for each will be slightly different – one VPN connection will route traffic to our public VPC subnet, and the other will route traffic to our private VPC subnet. Click the “Show Advanced Settings” and then enter the following elements:
    1. MSS Adjustment – Custom Size (as specified by the configuration doc from AWS – should be 1387).
    2. VPN Gateway (choose one of the tunnels created previously).  I’ve chosen to route traffic on my Tunnel 1 to the public subnet.
    3. Set the Local Policy to your LAN subnet.
    4. Set the Remote Policy to the corresponding AWS subnet (e.g. AWS_Public) you wish to route traffic to over this tunnel.
    5. SA Lifetime (should be 3600)
    6. Proposal (should switch to AES128 / SHA1)
    7. Perfect Forward Secrecy (should be DH2)
    8. Ensure zone is IPSec_VPN zone.
    9. Additionally – we’ll need to enable a connectivity check to prevent AWS from tearing down the VPN tunnel after a period of inactivity (nothing like users coming into the office in the morning and not being able to connect to servers in the VPC).  This is done easily – just establish a period ICMP packet sent to a host within the subnet you’re routing traffic to.  This ping will keep the tunnel open.  I’ve set mine to ping the NAT instance every 30 seconds.
  8. Repeat these same steps for the second tunnel, only be sure to route your traffic to the second AWS tunnel and subnet.  If you try to route traffic to the same subnet as the previously created connection, the ZyXEL will refuse to keep both connections up and running at the same time.
  9. The final step is to allow traffic back to our LAN from the VPC.  In the ZyXEL configuration page, click the Firewall link and “Add” a new rule to allow traffic from the IPSec_VPN zone to the LAN zone (LAN1 in my case).

Validating the Connection

At this point, you should have a fully functional site-to-site VPN connection to your AWS VPC subnets from your local office ZyXEL router.  Most routers that are capable of constructing IPSec VPN tunnels should be able to perform this feat, but depending on the router’s feature-set, your mileage may vary.

Note the Blue/Purple “Connected” status icons on each VPN connection in my ZyXEL.

 

AWS reports the both tunnels are online.


Pings being sent / received from my LAN to machines in both private and public subnets.


Pings being sent / received from machines in both private and public subnets on the VPC to a machine my LAN


In the next article, we’ll discuss setting up an OpenVPN server to handle VPN connections from dynamic clients.  This will help to serve the members of your office who may be working from home or working in the field.  Until then, happy VPNing!

What next?
Let Axian come to the rescue and help define your custom application strategy, develop a roadmap, work with your business community to identify the next project, and provide clarity and direction to a daunting task. For more details about Axian, Inc. and the Custom Application practice click here to view our portfolio or email us directly to setup a meeting.