How to connect your LAN to Amazon Virtual Private Cloud

Last updated on September 5, 2020 by Sarmed Rahman

If you have a lot of your services hosted in the Amazon AWS public cloud, and are looking for ways to access your leased AWS resources in a secure way, this article is for you. Initially you started out accessing Amazon AWS over the public Internet. Over time, you have migrated more and more services to your AWS Virtual Private Cloud (VPC) using the architecture of your choice ‒ multi-tiered servers, load balancers, auto-scaled, managed database, hosting services internal to your organization, and so on. Now you realize that routing all your traffic to and from AWS over the public Internet is no longer viable because of security concerns and/or company policies. Moreover, it makes more sense to access services internal to your company using private IP addresses.

Amazon AWS provides multiple options if you want to access your Amazon VPC's private IP address space directly from your LAN. All these options are secure as the traffic either goes over an encrypted tunnel or over an isolated dedicated connection.

In a nutshell, you have the following two options to seamlessly and securely connect your LAN to Amazon VPC.

Virtual Private Network (VPN)
AWS Direct Connect

We will be exploring both options in details in this article.

Option 1: VPN Tunnels

In most cases, the easiest option would be to connect your LAN to your Amazon VPC via a site-to-site VPN tunnel, which would carry encrypted traffic between your LAN and Amazon VPC. Personally, I consider VPN tunnels as one of the safest methods in routing traffic over public networks as there are multiple measures in place against eavesdropping and spoofing, such as IPSec, SSL, periodic renegotiation of keys, peer verification, message integrity verification, periodic re-establishment of the tunnel via new keys, and so on.

In Amazon AWS, there are several ways to hook up your LAN with Amazon VPC via VPN tunnels.

Option 1.1: Using a VPN Capable Instance in AWS

You can easily set up an instance within your Amazon VPC, that can be configured as a VPN endpoint. On-premise VPN endpoint (firewall/router/server) on your LAN will then connect to this instance via a site-to-site VPN tunnel. When preparing a VPN capable instance, you can choose either of the following options.

Open source VPN software: You can launch a regular Linux instance and turn it into a VPN server by settting up open-source VPN software on it. Popular choices of VPN software include Openswan, OpenVPN and StrongSwan.
Virtual router/firewall appliance: Alternatively you can create a VPN-capable virtual router appliance with necessary VPN capabilities. After launching a virtual router, you can configure it as a VPN endpoint within your Amazon VPC. Example of such virtual appliances are Cisco CSR or Cisco ASA which come with enterprise-class VPN capabilities. Similar virtual appliances from Checkpoint, Sonicwall and Sophos are also available.

As far as cost is concerned, the only change that you would incur is the standard instance usage charge and data transfer charge. Please keep in mind that some instance types have some additional charges for running software, e.g., RHEL, Cisco (other than BYOL).

A VPN tunnel can be set up in either of the following two modes.

Policy-based VPN: A tunneling policy defines what kind of traffic will go over the tunnel. Typically the traffic between your LAN's subnet and Amazon VPC's subnet is sent via the tunnel. In policy based VPN, if the tunnel remains idle over an extended period of time due to the absence of traffic matched with the policy, the tunnel might not renegotiate keys automatically and get torn down. It is thus recommended to have a router/gateway send keepalive packets or probe packets periodically over the tunnel.
Route-based VPN: In a route based VPN, both VPN endpoints in the LAN and VPC have virtual tunnel interfaces configured (e.g., tunnel0, tunnel1), and assigned IP addresses from the same subnet. The tunnel then remains up as long as the the IKE and IPSec negotiations are successful, whether or not there is traffic over the tunnel. VPN traffic is treated as regular routed traffic. For example, you can add static routes for the VPN traffic, or even configure something dynamic like OSPF or BGP.

There are a couple of things to note when operating a VPN-capable instance.

Depending on your country, your ISP may be filtering VPN traffic.
Always use an "elastic" IP address with your instance. This ensures that the IP address will not change due to a stop/start of an instance.

Depending on your configuration, the port used by the tunnel needs to be opened in your AWS security group and VPC ACL. Common VPN ports are:

Description	Protocol	Port
ESP (Encapsulated Security Protocol)	IP (Neither TCP or UDP)	50
AH (Authentication Header)	IP (Neither TCP or UDP)	51
Key negotiation and traffic	UDP	500
In case NAT-T is configured	UDP	4500

Option 1.2: Using AWS Managed VPN Gateway

The second option for connecting your LAN to Amazon VPC via a VPN tunnel is to leverage AWS managed VPN gateways. If you choose this option, you no longer need to maintain VPN endpoints in your Amazon VPC, and hence there is no need to run a VPN-capable instance.

The AWS VPN gateway is officially called a Virtual Private Gateway (VGW). AWS will provide two public IP addresses for each VGW, and you can use these IP addresses to set up two separate VPN tunnels for your Amazon VPC. It is up to you how you can use these tunnels (e.g., for load balancing and high availability).

The VGW is then connected with one or more routers on your premises, called Customer Gateway (CGW). For example, you may want to connect two or more branch offices to the same Amazon VPC. Alternatively, you can connect one customer router to multiple VGWs from different Amazon VPCs. For example, you may want to connect your LAN to five different VPCs.

If you are considering using AWS Managed VPN Gateway, there are a couple of things you should keep in mind.

Each Amazon VPC supports only one VGW.
You can connect more than one customer router (your own router) to a single VGW.
You can connect one customer router with multiple VGWs.
VGW supports NAT traversal, multiple encryption options and Diffie-Hellman key exchange scheme.
VGW supports both policy based and route based VPN.
VGW settings cannot be changed once the VGW has been activated. However, you can replace a VGW anytime when you want to make a change. In that case, be ready to reconfigure the IP addresses at your router as the IP addresses of the VGW will change.
AWS supports a pair (one inbound and one outbound) of security associations per tunnel. This becomes especially important for firewalls (e.g., Cisco ASA) that create a security association for each LAN subnet.

Option 2: AWS Direct Connect

The second option for connecting your LAN to Amazon VPC is using AWS Direct Connect. In this case, you would connect your LAN to AWS data center over dedicated fiber optic cables. This option is particularly popular for enterprises who have their own infrastructure located in close proximity to AWS data centers. Some enterprises choose to lease fiber optic backbone from service providers to connect to AWS via AWS Direct Connect.

In case you are considering AWS Direct Connect, you should keep the following factors in mind.

You will be connecting to your Amazon VPC using dedicated network connections (e.g., leased or dedicated fiber optic cables), not via VPN tunnels created over the public Internet. For some enterprises, such non-shared dedicated connections are a security requirement.
The throughput of your direct connect link solely depends on owned/leased fiber optic connectivity and its bandwidth.
AWS does not provide physical connectivity as a service. The customer is responsible for arranging and maintaining fiber optic connectivity to AWS 'Meet Me Room' (MMR) in the data center.
1000BASE-LX or 10GBASE-LR connections over singlemode fiber is supported. The endpoint on your premises should support BGP and 802.1q VLANs.

AWS Direct Connect Types: Private and Public

You can choose to use a private or public direct connect. A private direct connect is used when both your VPC and local LAN are using private IP addresses. You can use any private AS number along with private IP address space for BGP peering. The private direct connect link would advertise only the VPC's private IP address range.

If you have a pool of public IP addresses in your LAN which you want to hook up with your VPC over the direct connect link, you would need to use public direct connect peering. For example, you could be a telecom provider with a /8 public IP space, or have a content delivery network that has a /21 public IP prefix. The AS number that you would use during BGP peering must be a public AS number allocated by the Internet Registry with your public IP prefix.

Procedure for Ordering AWS Direct Connect

When you order AWS Direct Connect, you go through the following steps.

Step One: Physical Connectivity

AWS issues a Letter of Authorization (LOA) and Connecting Facility Assignment (CFA) to you, containing the port details so you know where to connect the fiber. The LOA-CFA is valid for 90 days. In case it expires, you have to request for the LOA-CFA to be reissued. You need the LOA when you/your partner completes the connectivity at the AWS MMR. Typically, a physical connection is established via fiber optic cables between AWS designated ports and the router interfaces on your premises.

Step Two: Virtual Interfaces

Once the physical link is complete, you can create one or more virtual interfaces in your AWS Direct Connect Console. When creating a direct connect virtual interface, you would have to provide the following information.

/30 peering IP block, typically provided by the customer. Depending on the use case, AWS might also provide a peering IP block.
VLAN ID for the virtual interface.

Based on the provided information, a virtual interface is created. You can now access the downloadable configuration template that you will find helpful in configuring the virtual interface at your own router. Ideally, you would configure a virtual interface with an IP address in the /30 range and the VLAN of the subinterface.

Step Three: BGP Peering

Once the point to point connectivity using the virtual interface has been created, you can move forward with the BGP peering. Based on whether you have chosen public or private direct connect, you would use a private or a public AS number for BGP peering.

Once the BGP peering is up, you can start advertising your LAN prefixes towards AWS. You can advertise public prefixes as long as you have obtained the prefix from an RIR. You cannot advertise private prefixes on a public BGP peering.

In case you have a private BGP peering over the direct connect link, you can advertise your private prefixes towards AWS. Traffic towards public prefixes will always go via the Internet gateway, even if you advertise those prefixes over the private direct connect link.

In a public peering, AWS will advertise the AWS public prefixes of that region through BGP. In case of private peering, AWS will advertise only the private CIDR of the Amazon VPC.

There are a couple of things to note when setting up AWS Direct Connect.

The physical interface of your router should not have any IP address. The IP addresses are to be assigned to virtual sub-interfaces.
In case you are using dual core fiber and your physical link is not coming up because of too much loss in the optical signal, try swapping the TX and RX cables to your SFP.
BGP needs TCP port 179 open to establish the session.
You might run into asymmetric routing in case you advertise identical prefixes over both BGP peering.

Adding Routes to VPC Route Tables

To route traffic between your LAN and your Amazon VPC, necessary routes need to be added to the VPC's route table. This applies to both VPN and AWS Direct Connect cases. Here are two options to populate the VPC route tables.

Routing	Typical Route Table Entry	Characteristics
Static routing	Your LAN subnets are statically routed with the next hop set to software VPN instance, the VGW or the AWS Direct Connect link.	Easy to configure when you have a few subnets in your LAN. Harder to manage when you have a lot of LAN subnets.
Dynamic routing	Your CGW has BGP peering with the VPN endpoints/Direct Connect router. Routes are exchanged over BGP peering.	Highly scalable, adaptable and less prone to human error.

A VGW can be set to propagate any routes that it learns from the CGW throughout the VPC. This comes in very handy in case you have many subnets in your VPC that have their own route tables.

Conclusion

To summarize, you have many options when you want to connect your LAN or servers to Amazon AWS. The cost and complexity of the connection depends on how you want your traffic to be routed and how you plan for disaster recovery. If you choose a VPN tunnel option, you can either maintain a VPN-capable router instance within Amazon VPC for a single VPN tunnel, or have multiple VPN tunnels with AWS-managed VPN gateway. If the cost is not limitation, you can choose high performance dedicated direct connect links. In short, the flexibility in designing and implementing a connectivity that matches your specific needs is one of the primary reasons why many of us love working with AWS.