THE AWS CERTIFIED ADVANCED NETWORKING – SPECIALTY EXAM OBJECTIVES COVERED IN THIS CHAPTER MAY INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING:

• Domain 1.0: Design and Implement Hybrid IT Network Architectures at Scale
•  1.1 Apply procedural concepts for the implementation of connectivity for hybrid IT architecture
•  1.2 Given a scenario, derive an appropriate hybrid IT architecture connectivity solution
•  1.4 Evaluate design alternatives leveraging AWS Direct Connect
•  1.5 Define routing policies for hybrid IT architectures
• Domain 5.0: Design and Implement for Security and Compliance
•  5.4 Utilize encryption technologies to secure network communications

Introduction to Virtual Private Networks

This chapter is intended to provide you with an understanding of how to design Virtual Private Networks (VPNs) on AWS. We will go into detail on the various options available and various scenarios for VPN creation.

A VPN is a network that allows hosts to communicate privately over an untrusted intermediary network like the Internet as if they were all colocated in an isolated private network. A common reason for creating a VPN is to allow on-premises servers to communicate with servers in a Virtual Private Cloud (VPC) over the public Internet in a private and secure manner. In this scenario, we create what is called a site-to-site VPN connection. Another type of VPN, called a client-to-site VPN, or remote access VPN, can be created when individual remote users want to connect to the server resources inside a VPC from their client devices (like laptops) in a secure manner. As we go through this chapter, we will explore how to architect an approach for each of these scenarios.

A VPN can be set up using different protocols and technologies, each with its own advantages. The most widely-used VPN technology is a set of protocols called the Internet Protocol Security (IPsec) protocols, often referred to as an IPsec VPN. According to RFC 6071, IPsec is a suite of protocols that provides security to Internet communications at the IP layer. Some other VPN technologies are Generic Routing Encapsulation (GRE) and Dynamic Multipoint Virtual Private Network (DMVPN).

Site-to-Site VPN

A site-to-site VPN connection allows two networking domains, referred to as sites, to communicate securely with each other over an untrusted intermediary network, such as the public Internet. These two sites can be a VPC and an on-premises data center, or two different VPCs in different or the same AWS Regions. In order for the two sites to set up a VPN connection, a VPN termination endpoint is required at each site. This endpoint is responsible for running the VPN protocols and the associated packet processing, including encapsulation and encryption. All the traffic flow between the two sites is passed via these endpoints, and hence it is important to think about the availability and scalability of these endpoints in hybrid architectures.

A VPN connection to AWS can only be used to access resources inside a VPC. This excludes services such as Amazon S3 that sit outside the boundaries of a VPC. Since every VPC is its own isolated network, you will require a VPN connection per VPC.

Let’s discuss the VPN termination endpoint options available in the context of creating a site-to-site VPN between AWS and an on-premises data center (customer network). There are two ways to terminate a VPN connection to a VPC: a Virtual Private Gateway and an Amazon Elastic Compute Cloud (Amazon EC2) instance.

Virtual Private Gateway as a VPN Termination Endpoint

The Virtual Private Gateway (VGW) is a managed gateway endpoint for your VPC. It is responsible for hybrid IT connectivity leveraging VPN and AWS Direct Connect. The VGW is a self-sustainable entity, and it can be created without the requirement of a preexisting VPC. Once created, it then can be attached to any VPC in the same account and region. A key point to remember here is that each VPC can have only one VGW attached to it at any given point in time, but you have the ability to detach one VGW and attach another one to a VPC. You can create a VGW by navigating to the Amazon VPC dashboard in the AWS Management Console or by making an Application Programming Interface (API) call.

When creating a VGW, you will have an option to define an Autonomous System Number (ASN) for the AWS side of the external Border Gateway Protocol (BGP) session. You can choose any private ASN. Ranges for 16-bit private ASNs include 64512 to 65534. You can also provide 32-bit ASNs between 4200000000 and 4294967294. AWS will provide a default ASN for a VGW if you don’t choose one.

Once a VGW is created, you can terminate a VPN connection on it. The VGW supports only IPsec VPN in the Encapsulating Security Payload (ESP) mode. Figure 4.1 depicts this connection architecture.

Availability and Redundancy

The VGW has built-in high availability and redundancy for VPN connectivity. Upon VPN creation, AWS automatically creates two highly available endpoints, each in a different Availability Zone. As shown in Figure 4.2, each endpoint has an IP address associated with it that will be used to terminate the VPN at the AWS end. Both of these endpoints are available and can be used to set up VPN tunnels in Active/Active mode. These two tunnels are collectively denoted as a Single VPN connection in AWS terminology.

Each tunnel contains an Internet Key Exchange (IKE) Security Association (SA), an IPsec SA, and a BGP Peering (optional, used in route-based VPNs). You are limited to one unique SA pair per tunnel (one inbound and one outbound) and therefore two unique SA pairs in total for two tunnels (four SAs). Some devices use policy-based VPNs and will create as many SAs as there are Access Control List (ACL) entries.

Policy-based VPNs that are configured with more than one security association will drop existing VPN tunnel connections when initiating a VPN tunnel connection that uses a different SA. This problem will be perceived as intermittent packet loss or connectivity failure because new VPN connections with one security association interrupt VPN tunnel connections established with a different security association.

You can overcome this problem by considering either of these two approaches:

• Limit the number of encryption domains (networks) that are allowed access to the VPC and consolidate. If there are more than two encryption domains (networks) behind your VPN termination endpoint, consolidate them to use a single security association.
• Configure the policy to allow “any” network (0.0.0.0/0) from behind your VPN termination endpoint to the VPC Classless Inter-Domain Routing (CIDR). Essentially, this allows any network behind your VPN termination endpoint that is destined to the VPC to pass through the tunnel. This will only create a single security association. This improves the stability of the tunnel and allows future networks not defined in the policy to have access to the AWS VPC. This is the generally-recommended best approach.

Route-based VPN leveraging BGP for routing doesn’t have this problem.

VPN Features

The VPN features discussed in this chapter refer to the new AWS VPN service.

Security

From a security standpoint, VGW supports the following cryptography suites:

• Advanced Encryption Standard (AES) 256
• Secure Hash Algorithm (SHA) 2
• Phase 1 Diffie Hellman(DH) groups: 2, 14-18, 22, 23, and 24
• Phase 2 DH groups: 1, 2, 5, 14-18, 22, 23, and 24

VGW also has backward compatibility for older cryptography protocols. The cryptography used in Internet Key Exchange (IKE) Phase 1 and 2 is automatically determined at the time of IPsec negotiations. It is important to make sure that your VPN termination endpoint is enabled/configured for using these cryptography standards. Otherwise, the tunnel might be negotiated using older standards.

Routing

The VGW supports both static route VPNs and those based on the BGP dynamic routing protocol. The BGP routing protocol allows your on-premises device to advertise multiple IP prefixes dynamically to the VGW using BGP route advertisements. The VGW advertises the IP ranges of the VPC to which it is attached via BGP route advertisements to your VPN termination endpoint. A VGW runs the standard BGP protocol over Transmission Control Protocol (TCP) port 179 and honors common BGP parameters like AS (Autonomous System) prepends and BGP MED (Multi-Exit Discriminator).

You can have up to 100 propagated routes per VPC subnet route table. This is a hard limit, and it cannot be raised; therefore, you should limit the number of routes that you are advertising to VGW using BGP route advertisements to less than 100 total. In the event that you have more than 100 prefixes, it is recommended that you summarize your routes or even advertise a default route if that fits your use case. Within a VPC, you can enable VGW route propagation, which will allow the VPC subnet route table to ingest routes learned by the VGW automatically via BGP.

Two tunnels are created per VPN connection by default, and you can establish multiple VPN connections for high-availability purposes. These conditions can increase the probability of asymmetric routing for a given prefix (that is, inbound traffic from on-premises to AWS flows through one tunnel while return traffic flows through the other tunnel). To mitigate this, we recommend that you use VPN tunnels in Active/Standby mode using as-path prepends or MED BGP parameters as shown in Figure 4.3.

Network Address Translation (NAT) Traversal (NAT-T) Support

AWS VGWs also have support for Network Address Translation (NAT) Traversal (NAT-T). Traditionally, the IPsec protocol does not work very well when traversing a NAT device. Due to the encrypted nature of the ESP header, NAT translations fail. NAT-T solves this problem by encapsulating the packet in a User Datagram Protocol (UDP) header using port 4500. By enabling this option, IPsec traffic can pass through a NAT device with successful port/IP translations.

AWS VPN CloudHub

An AWS VGW supports functionality called AWS VPN CloudHub, which acts as a hub router connecting multiple remote networks. A VGW supports this functionality irrespective of whether it is attached to a VPC, or if it is running in a detached mode. This design is suitable for customers with multiple branch offices and existing Internet connections who want to implement a convenient, potentially low-cost hub-and-spoke model for primary or backup connectivity between these remote offices.

To use the AWS VPN CloudHub, you must create a VGW and set up a VPN connection to all of the sites to which you want to connect via the CloudHub. You can use different or the same BGP ASNs for each site based on your preference and use case. Customer gateways advertise the appropriate routes (BGP prefixes) over their VPN connections. These routing advertisements are received and re-advertised to each BGP peer, enabling each site to send data to and receive data from the other sites. The sites must not have overlapping IP ranges. If the VGW is attached to a VPC, each site can also send and receive data from the VPC as if they were using a standard VPN connection. Figure 4.4 depicts this functionality.

VPN Creation Process

It is simple and quick to set up a VPN connection. You’ll use the AWS Management Console or make an API call to create a VPN connection. You will have to specify the following details during this step:

• The VGW to which you want to set up the VPN connection
• A customer gateway (the IP address of the VPN termination endpoint at your end)—more details on the customer gateway are provided later in this chapter.
• Routing Method
  • Option 1: Static Tunnel (routing via static routes). Specify routes that you want to advertise to AWS.
  • Option 2: Dynamic Tunnel (routing via BGP). Specify BGP ASN.
• Tunnel Configurations
  • AWS Default: Values shown below will be automatically generated.
  • Custom: Manually specify the below values.
    • Inside IPv4 Addresses for the Tunnels: (2 x /30 range within 169.254.0.0/16 CIDR block). When creating multiple VPN connections to a single VGW, ensure that the inside tunnel IP address for each VPN connection is distinct. The VPN inside tunnel addresses can be the same as the peer IP addresses on AWS Direct Connect.
    • Custom Pre-Shared Key (PSK).

Based on the values you enter, the VGW will automatically be configured for this VPN connection. You do not have access to the VGW internals because it is a managed service— you cannot make changes to the VGW IPsec parameters once the VPN connection is created. If you want to change one of the parameters, you must delete the existing VPN connection and create a new VPN with new parameters.

The AWS Management Console will allow you to generate a configuration for your device automatically. The AWS Management Console has information pertaining to many VPN vendors, including Cisco, Juniper, Fortinet, Palo Alto Networks, and more. If your vendor is not listed there, you can download a generic configuration file and use that to configure your device.

Once you have created the VPN connection at the AWS end, use the AWS-generated configuration file to configure your device. Two VPN tunnels should be created: one to each of the VGW public IP endpoints. This completes the creation of a VPN connection with high availability and redundancy at the AWS end. We encourage you to have redundancy at your end as well by having multiple VPN termination devices. A separate VPN connection per device will be required to accomplish this. We will explore this configuration in more detail in later sections of this chapter.

After you create a VPN connection, the VPN tunnel activates when traffic is generated from your side of the VPN connection. The VGW is not the initiator; your customer gateway must initiate the tunnels. If your VPN connection experiences a period of idle time (usually 10 seconds, depending on your configuration), the tunnel may go down. This is because AWS uses an on-demand DPD mechanism. If AWS receives no traffic from a VPN peer for 10 seconds, AWS sends a DPD “R-U-THERE” message. If the VPN peer does not respond to three successive DPDs, the VPN peer is considered dead and AWS closes the tunnel.

Monitoring

As shown in Figure 4.5, you can monitor the status of the VPN tunnels using Amazon CloudWatch metrics. Amazon CloudWatch is a monitoring service for AWS Cloud resources and the applications that you run on AWS. The supported Amazon CloudWatch metrics for VPN connections are as follows:

• TunnelState: The state of the tunnel. 0 indicates DOWN and 1 indicates UP.
• TunnelDataIn: The bytes received through the VPN tunnel.
• TunnelDataOut: The bytes sent through the VPN tunnel.

Check the AWS documentation for the latest and complete list of Amazon CloudWatch metrics for VPN.

Amazon Elastic Compute Cloud (Amazon EC2) Instance as a VPN Termination Endpoint

An alternative to using a VGW as a VPN termination endpoint at the AWS end is to terminate the VPN on an Amazon Elastic Compute Cloud (Amazon EC2) instance running VPN software. There are a few special scenarios in which you may choose to do this. They are as follows:

• You require a special set of features on your VPN termination endpoint, such as advanced threat protection or transitive routing capabilities.
• Your on-premises device is not compatible with running IPsec VPN, and you want to run a different VPN protocol, such as DMVPN or GRE VPN.
• You want to support complex networking requirements, such as connecting two networks with an overlapping CIDR range, setting up multicast between Amazon EC2 instances, or enabling transitive routing.

As shown in Figure 4.6, there is no VGW involved, and VPN is terminated directly on the Amazon EC2 instance.

Availability and Redundancy

The availability and redundancy of this option is your responsibility. There are four ways that the availability and redundancy of your VPN connection can be affected. It can be due to a VPN configuration error, a problem with the VPN software that you are using, an operating system error, or the Amazon EC2 instance becoming unhealthy. The first three causes are within your control, and you should have checks in place to rectify them. An Amazon EC2 instance failure can be rectified by the Amazon EC2 auto recovery feature.

In any case, it is recommended to have two Amazon EC2 instances active at any given time for VPN termination in an Active/Standby mode.

In order to achieve failover from the primary Amazon EC2 instance to the secondary, you will have to set up a monitoring script. This script will detect the failure of a VPN tunnel and then make changes to the subnet route table to point to the secondary instance wherever the primary instance was initially referenced. This automated failover configuration is depicted in Figure 4.8.

Once the route table entry is changed and the data path has been shifted to the secondary Amazon EC2 instance, the next step is to get the failed Amazon EC2 instance back to a healthy state. If the hardware that hosts a particular Amazon EC2 instance becomes impaired, Amazon EC2 auto recovery will reboot your instance into a healthy state. If your instance is configured to store the VPN configuration on persistent Amazon Elastic Block Store (Amazon EBS) storage, and you have enabled automated restart of the IPsec process at boot, your VPN connection should come up without manual effort. If the problem was at the VPN software level because of an incorrect configuration or software crash, it is your responsibility to fix the problem. Because creating new instances is easy, it might be easier to terminate the old instance and launch a new instance to recover from failure. In the event that the Amazon EC2 instance was public facing with an Elastic IP mapped to it, make sure that the failed instance and recovered instance have the same Elastic IP mapped to them.

If you are using a partner VPN solution from the AWS Marketplace (for example, Cisco, Aviatrix, Riverbed, Juniper, Sophos, Palo Alto, or Checkpoint), many of the automation and failover efforts described here are already built into the solution, and so no manual effort or scripting would be required to achieve high availability and recovery from failure scenarios. Note that features will vary by vendor.

Amazon EC2 Features

One of the biggest advantages of VPN termination on an Amazon EC2 instance over a VGW is the capability to have additional feature sets on top of just VPN termination and routing. The actual features offered are dependent on the VPN software that you are using on the Amazon EC2 instance.

VPN Creation Process

Because this option is based on running VPN software on an Amazon EC2 instance, the first step in VPN creation is choosing the VPN software you wish to run and the size of the Amazon EC2 instance that will run this software. The vendor whose software you choose for VPN creation dictates the feature set of the VPN solution and the out-of-the-box automation around failure and high availability. The size of the Amazon EC2 instance will determine the network bandwidth of the instance as well as the compute power required for packet encapsulation and encryption.

Once you have decided on a vendor, you can set up the VPN software in one of two ways:

Use AWS Marketplace As shown in Figure 4.9, AWS Marketplace is an online store where you can sell or buy software that runs on AWS. If the VPN software of your liking is available as an AWS Marketplace offering, you can directly deploy the software on an Amazon EC2 instance type that fits your needs using a single click in the AWS Marketplace console. An Amazon EC2 instance will be launched from an Amazon Machine Image (AMI) with the VPN software preinstalled and optimized by the vendor. Depending on the license model, you can use an AWS-provided license or Bring Your Own License (BYOL).

Manual Install on an Amazon EC2 Instance If the software is not available on AWS Marketplace, you can manually install it. First launch an Amazon EC2 instance of a type and size that meets your needs, which is loaded with an operating system that is recommended for the VPN software. Then install the VPN software directly from the vendor’s repository. You will have to interact directly with the vendor regarding any licensing contracts for their VPN software.

You need to make sure that the Amazon EC2 instance has the right connectivity to reach the VPN termination device at your end. If this requires Internet access, assign an Elastic IP address to the Amazon EC2 instance and make sure that a route to the Internet gateway exists in the subnet route table. Ideally, you would also have the right ports opened in the instance security group for inbound IPsec traffic to pass from the on-premises device to the Amazon EC2 instance, but you can skip this if the Amazon EC2 instance initiates the IPsec negotiation. Due to the stateful nature of security groups, return traffic for an existing stateful connection is automatically allowed.

Once the Amazon EC2 instance is set up with proper connectivity and loaded with the VPN software, you will have to configure IPsec parameters and the associated routing on both the Amazon EC2 instance and the VPN device at the remote end (on-premises data center) to bring up the VPN tunnel. To enable routing of traffic, make sure that the source/destination check is disabled on the Amazon EC2 instance and IP forwarding is enabled at the operating system level.

For high-availability configurations, you will need to launch multiple Amazon EC2 instances and set up automation for failover. The steps for setting this up will vary in effort and might require minimal effort depending on the vendor you choose.

Monitoring

You can monitor the metrics of the Amazon EC2 instance (for example, health, network in/out) using Amazon CloudWatch. Because AWS doesn’t have visibility into the operating system or vendor software, VPN- and operating system-related metrics won’t be visible in Amazon CloudWatch by default. If supported by the vendor, you can push custom VPN metrics to Amazon CloudWatch using the AWS Command Line Interface (AWS CLI) or an API. You can view statistical graphs of your published metrics within the AWS Management Console. You can also leverage third-party monitoring tools to monitor the VPN setup.

Performance

Performance depends on the size of the Amazon EC2 instance and how efficiently the VPN software can use the Amazon EC2 instance infrastructure capabilities (compute and memory).

Refer to Chapter 9, “Network Performance,” to gather more details on the capabilities of an Amazon EC2 instance from a networking standpoint. In general, the bigger the Amazon EC2 instance size, the better average networking performance you will get from the instance, with the maximum bandwidth being 25 Gbps inside a placement group and 5 Gbps outside the placement group.

Vertical Scaling

You should establish the correct instance type needed for the Amazon EC2 instance running the VPN software through testing. You can use the agility of the Amazon EC2 to scale vertically by changing the instance to a larger size in the event that you need more network throughput.

Vertical scaling may require downtime, typically a few minutes, because an Amazon EC2 instance being scaled up has to be restarted. If you have designed your system for high availability (Active/Backup), you should be able to avoid downtime or minimize it by first upgrading the secondary (Backup) instance, promoting it to master (Active), and then upgrading the primary which then becomes the backup.

Note that after a certain threshold, the VPN throughput becomes fairly constant even with an increase in the Amazon EC2 instance size. This is due to the limits on the speed at which IPsec packet processing can be performed in software. One way to increase the VPN throughput above this threshold is to offload the encryption to multiple Amazon EC2 instances. In this scenario, you will have one Amazon EC2 instance configured as the next hop for all VPN traffic. This Amazon EC2 instance will not provide VPN termination but is instead responsible for load balancing traffic to a fleet of Amazon EC2 instances that are responsible for VPN termination. Since the intermediary Amazon EC2 instance is not responsible for IPsec encryption, it can transmit packets at a much faster rate. There are two ways to set this up as follows:

Single Availability Zone Within the same subnet, the intermediary Amazon EC2 instance runs BGP (or a similar protocol that can used for L3 load balancing of traffic) with a fleet of Amazon EC2 VPN instances to keep track of routing information and to insert the VPN instances as the next hop for remote networks in its host routing table. BGP multipath can be used for load balancing traffic. This architecture is depicted in Figure 4.10.

Multiple Availability Zones Place the VPN Amazon EC2 instances in different Availability Zones and establish GRE tunnels from the intermediary instance to the VPN instances. GRE tunnels are used as EC2 instances cannot establish BGP peering with an instance in a different subnet. This is a limitation of the way BGP neighbor relationships are established. A GRE tunnel creates a virtual network connecting the two instances in the same virtual network. If you are using your own load balancing protocol, then you might be able to load balance traffic to instances in a different subnet without the need to use a GRE. Like the previous option, this intermediary Amazon EC2 instance runs BGP with the VPN instances to keep track of routing information and to insert the VPN instances as the next hop for the remote network in its routing table. BGP multipath can be used for load balancing traffic. This architecture is depicted in Figure 4.11.

Horizontal Scaling

From a horizontal scaling point of view, you can launch multiple Amazon EC2 instances and use them simultaneously (Active/Active) for VPN traffic. Due to the way VPC routing tables work, only one Amazon EC2 instance can be used as a next hop for a given prefix. You will have to design the way you want to distribute outgoing VPN traffic carefully among multiple Amazon EC2 VPN gateway instances. As shown in Figure 4.12, one approach is to have one Amazon EC2 instance VPN gateway per VPC subnet.

Another way to distribute traffic across multiple Amazon EC2 instances is based on the destination prefix. The idea is to split the on-premises network prefix into multiple sub-prefixes and use a different Amazon EC2 instance to reach each prefix. This is depicted in Figure 4.13.

VPN Termination Endpoint for On-Premises Networks (Customer Gateways)

At the non-AWS end of a VPN connection, the VPN is terminated on a customer gateway. A customer gateway is the AWS term for the VPN termination device at the customer’s on-premises end. A customer gateway can also be hosted in AWS as an EC2 instance running VPN software that meets the requirements given in the next section.

Most customers don’t require the purchase of an additional device and can reuse an existing on-premises VPN termination device to create a tunnel to a VPC.

Figure 4.14 shows an architectural representation of a customer gateway.

Third-Party VPN Device

You can use any third-party VPN device that supports Layer 3 VPN technologies. AWS does not support Layer 2 VPN technologies.

IPsec is used for the VGW at the AWS end of VPN termination, and so the IPsec protocol must be supported by your VPN device. You will set up two VPN tunnels per VGW. Support for BGP routing protocol is optional but recommended for advanced routing capabilities. Other routing protocols like Open Shortest Path First (OSPF) are not supported by AWS. You must ensure that you have opened the right ports in your on-premises firewall for the IPsec traffic to flow.

When using the Amazon EC2 instance-based VPN termination option, the choice of VPN protocol is dependent on the VPN software that you install on the Amazon EC2 instance. Common protocols like GRE, DMVPN, and others can be used as an alternative to IPsec. The routing protocols that are supported again depend on the VPN software running on the Amazon EC2 instance.

You are responsible for the availability and redundancy of the third-party device. As depicted in Figure 4.15, we recommend using multiple VPN termination devices at your end. If possible, these devices should be located in different physical data centers for a higher level of redundancy. You can use BGP parameters like local preference to designate primary/secondary exit points for the VPN traffic destined to AWS. For return traffic from AWS to your data center, use as-path prepends or MED to influence traffic path.

Client-to-Site VPN

A client-to-site VPN (also referred to as a remote access VPN) allows single hosts to gain access to resources inside a given network in a secure and private manner across an untrusted intermediary network. This is typically useful in the case of remote workers who are trying to gain access to corporate resources. In an AWS Cloud scenario, this can be useful for a remote laptop or PC to gain access to Amazon EC2 instances inside an Amazon VPC over the public Internet. Note that every end host will have to set up a VPN tunnel to the VPN gateway. If you have a remote office/site that consists of multiple end-user hosts/devices on their own internal network that all require access to VPC resources, you should set up a site-to-site tunnel between the remote site and the VPC.

As shown in Figure 4.16, to set this up, you need a gateway inside of the VPC that will be responsible for accepting VPN connections from remote hosts. Unlike site-to-site VPN, AWS currently does not offer a managed gateway endpoint for this type of VPN setup. You will have to use an Amazon EC2 instance as a client-to-site VPN gateway.

Similar to the Amazon EC2 instance-based VPN termination option for site-to-site VPN, setting up client-to-site VPN termination on an Amazon EC2 instance can be done in one of two ways:

Use AWS Marketplace You can use a pre-baked AMI with both software and license preinstalled to launch an Amazon EC2 instance and configure it as a VPN termination endpoint for remote clients. OpenVPN, Cisco CSR (with Cisco AnyConnect clients), Aviatrix, Sophos, and Palo Alto are examples of client-to-site VPN products on AWS Marketplace.

Manual install on an Amazon EC2 instance If the software is not available on AWS Marketplace, you can manually install it on an Amazon EC2 instance.

The arguments made regarding the availability, redundancy, and performance of the Amazon EC2 instance-based VPN termination option for site-to-site VPNs hold true for client-to-site VPN as well. Many client-to-site VPN solutions, like Cisco AnyConnect or Aviatrix, support load balancing client VPN connections to multiple VPN servers. This can be done by either using Network Load Balancer to send VPN traffic to multiple EC2 instances (for example, OpenVPN in TCP mode), DNS based load balancing (client DNS queries resolve to different VPN servers), or just specifying multiple VPN server IP addresses in the client.

Additional features like split tunneling, threat protection, endpoint compliance, profile based authentication, and so forth can be implemented, but that depends on the software vendor you choose for the client-to-site VPN solution.

Design Patterns

Now that you are aware of the various options for setting up VPN connections on AWS, let’s look at some scenarios requiring the use of VPN.

Connecting an on-premises network to a VPC This is the standard and the most common scenario for which VPN is used. In their journey to AWS, most customers operate in a hybrid mode, where on-premises applications need to be able to communicate with the applications in the VPC. By creating a VPN connection, you can enable this communication in a secure way without much setup lead time. It is recommended that you use AWS-managed VPN endpoints (VGWs) at the AWS end.

Connecting an on-premises network to a VPC: very high VPN throughput If you are looking for very high throughput for your hybrid IT connectivity to AWS, it is recommended that you set up AWS Direct Connect. AWS Direct Connect, which will be discussed in greater detail in the Chapter 5, “AWS Direct Connect,” is a service that allows you to set up dedicated connectivity between your data center and AWS, providing you with bandwidths up to 10 Gbps over a single circuit. If you require a high-speed VPN over the Internet and have an Internet connection to support it, you should use the Amazon EC2 instance-based VPN connection option with horizontal scaling.

Connecting an on-premises network to a VPC: non-IPsec protocol If you have set up an existing VPN infrastructure for your remote sites using a different Layer 3 VPN protocol like DMVPN or GRE, you can use the same protocol to connect a VPC to your network. This connection can be achieved using the VPN termination on an Amazon EC2 instance option. The VPN software running on the Amazon EC2 instance should support this protocol.

Connecting an on-premises network to a VPC: advanced threat protection Under some scenarios, you may want to enable advanced threat protection on your VPN termination endpoint in the VPC. For example, you want a third-party vendor to have access to resources inside your VPC using VPN, but you want to run threat analysis on every packet that comes from the remote site because you consider the third-party vendor network an untrusted zone. In this scenario, you will want to terminate the VPN on an Amazon EC2 instance and load the Amazon EC2 instance with software that can perform this threat analysis.

Layer 3 encryption between Amazon EC2 instances A VPC is a private network, and traffic within a customer’s VPC is completely isolated and not visible to any other customer. Some compliance requirements might dictate that all traffic between Amazon EC2 virtual machines should be encrypted, however. The ideal way to do this is to enable TLS communication between Amazon EC2 instances in the VPC. In the event that Layer 3 encryption is desired, a VPN mesh will have to be set up between all Amazon EC2 instances. Every instance will have an inside tunnel IP address that will belong to the overlay VPN network. You will have to use this IP address for data flow between instances. For this implementation, VPN software will have to be installed on each Amazon EC2 instance. The VPN software can be open source software or third-party software of your choice. You are responsible for the set up and maintenance of the solution.

Enable multicast in Amazon VPC The Amazon VPC service doesn’t presently permit multicast or broadcast traffic. In the event that you have an application that uses multicast to function, you can leverage GRE tunnels to create a mesh VPN overlay network between your Amazon EC2 instances. Multicast traffic can flow over this overlay network. Multicast is simulated by leveraging many unicast flows. This can be easily achieved using the available IP_GRE tunnel module or built into the kernel when using Linux operating systems. This is also a customer-managed solution. You are responsible for the set up and maintenance of the solution.

L3 encryption over AWS Direct Connect Traffic over AWS Direct Connect is not encrypted by default because the link is completely private and isolated. There are some compliance standards that might require data to be encrypted, however. As mentioned earlier, a common way to solve this problem is to use Layer 4 encryption protocols like Transport Layer Security (TLS). In the event that Layer 3 encryption is desirable, an IPsec VPN can help. An IPsec VPN connection can be easily set up over AWS Direct Connect. You will create an IPsec connection to the VGW as explained in the AWS-managed VPN option, but the actual traffic flow will be over AWS Direct Connect. A VIF has to be created over AWS Direct Connect for accessing resources inside AWS. VGW endpoints can be accessed over public VIF. Chapter 5 provides more details on how VIFs work. Further details on encryption over Direct Connect can be found in Chapter 5, “AWS Direct Connect” and Chapter 12, “Hybrid Architectures.”

Transitive routing Transit is a word most commonly used to describe scenarios where traffic originating from network A reaches network C by crossing, or “transiting,” through network B. This scenario is useful in cases where you want network B to have visibility into all communications between networks A and C for security reasons. As shown in Figure 4.17, such functionality doesn’t natively exist in AWS as of this writing. Traffic from VPC A destined to VPC C cannot flow via VPC B. This is due to the non-transitive functionality of AWS networking endpoints like VPC Peering, VGW, VPC Endpoints, and Internet gateway. In general, these endpoints allow traffic to flow only to VPCs to which they are directly connected (and in the case of VGW, also to the remote networks for which it has routes). Any other VPC traffic will be automatically dropped.

As shown in Figure 4.18, one way to overcome this is to set up an overlay network using VPNs. Let’s take the scenario where VPC A wants to communicate with VPC C but all traffic must pass through VPC B for traffic monitoring and threat assessment. In order to enable this flow, an Amazon EC2 instance-based VPN termination endpoint in VPC B will act as the transit point. Traffic originating in VPC A will be tunneled to this Amazon EC2 instance in VPC B, where it will then be tunneled to VPC C.

Within VPCs A and C, you can use either a VGW or an Amazon EC2 instance as the VPN endpoints. This transitive flow is made possible because the actual destination of the packet (VPC C) in this case is hidden and encapsulated inside an outer VPN header that contains VPC B as its destination. This outer header is allowed to pass via the AWS gateway endpoints like VGW or a peering gateway.

Note that although VGW is used as a VPN termination endpoint, it is a non-transitive endpoint, hence the transit point has to be an Amazon EC2 instance. This Amazon EC2 instance can also be your security and threat protection endpoint. You should consider high availability and scalability when designing such a solution because this transit point will be the weakest link in your architecture with regard to throughput and availability. Additional details on the transit VPC architecture is covered in Chapter 12.

Summary

There are two kinds of VPN architectures discussed in this chapter. The first is site-to-site VPN, which allows you to set up a VPN connection between a VPC and your data center. Any resources inside your data center should then be able to access resources inside the VPC. There are two general ways to terminate a site-to-site VPN connection on AWS. The first is by using an AWS-managed VPN endpoint called a VGW. The second is by using an Amazon EC2 instance-based VPN termination.

A VGW is a managed gateway endpoint for your VPC, and it is responsible for all hybrid IT connectivity involving VPN and AWS Direct Connect. You can create a standalone (detached) VGW without a preexisting VPC, and it will behave like a router/gateway. VGW has high availability built into it, and it can span multiple Availability Zones. Uptime, high availability, patching, and maintenance is all taken care of by AWS. AWS VPN leveraging VGW comes with support for the latest cryptography suite. It also supports both static and dynamic (BGP) routing as well as NAT-T. The VPN creation process is very simple and requires no IPsec or BGP configuration at the AWS end. You can download a prepopulated configuration file for your VPN device from the AWS Management Console.

You can also terminate a site-to-site VPN on an Amazon EC2 instance rather than use an AWS-managed VPN. You may choose this option if you are looking to leverage a different VPN technology than IPsec for your tunnels, or if you have a requirement demanding additional features on the VPN device (for example, advanced threat protection). To set this up, you will have to launch an Amazon EC2 instance and manually install the VPN software. You can also leverage AWS Marketplace to launch an Amazon EC2 instance automatically with pre-deployed VPN software. The high availability and scaling of this option is your responsibility. Using automation, you can build a failover cluster consisting of multiple Amazon EC2 instances that will act as VPN termination endpoints. If one instance fails, automated scripts should be able to make changes to the VPC route table to point the VPN traffic to the secondary instance. Only one Amazon EC2 instance can be used as a VPN gateway for a given destination prefix per VPC subnet. When planning for Active/Active setup or when horizontally scaling the number of Amazon EC2 VPN instances, you need to plan a traffic distribution strategy by splitting traffic bound for multiple prefixes among the Amazon EC2 instances.

At the customer end, you can leverage your on-premises VPN termination device to terminate a VPN connection. It is recommended that you use two physical devices spread across multiple data centers for redundancy.

The second VPN architecture we discussed was client-to-site or remote access VPN. This architecture allows remote end devices to access resources inside your VPC. You will have to use an Amazon EC2 instance as the VPN termination endpoint for this option. Deployment, high availability, and scaling for this option are similar to the site-to-site VPN termination for an Amazon EC2 scenario.

There are several design patterns relevant to the usage of VPN in the cloud, which vary by use case and customer requirements. For the standard use case of connecting your on-premises data center to a VPC, it is recommended to use the AWS-managed VPN option. If you require the same connectivity but with support for very high VPN throughput, you should leverage Amazon EC2-based VPN termination. For scenarios requiring the use of non-IPsec VPN protocol or advanced features on the VPN device, you should leverage an Amazon EC2-based VPN termination endpoint as well. If encryption or multicast is required inside a given VPC between Amazon EC2 instances, an overlay network will be required using Amazon EC2-based VPN termination. Amazon VPC does not natively allow transitive routing (that is, VPC A cannot communicate to a different network by transiting an intermediary VPC B), though a VPN overlay can be used to enable it. An Amazon EC2 instance will act as a transit point for the transitive routing. The high availability and scalability of this Amazon EC2 instance is your responsibility, although it can be automated using scripts.

Exam Essentials

Know the different VPN termination options available. You can terminate VPN on a VGW or on an Amazon EC2 instance. An AWS VPN terminating on a VGW is a managed solution; AWS takes care of IPsec and BGP configuration as well as uptime, availability, and patching/maintenance of the VPN termination endpoint. When terminating a VPN on an Amazon EC2 instance, you are responsible for deploying the software, VPN configuration, routing, high availability, and scaling.

Know the features of an AWS-managed VPN. An AWS-managed VPN offers a strong cryptography suite, including AES 256. It also supports BGP protocol and NAT-T. It can act as a hub router for connecting multiple remote networks, a configuration known as AWS VPN CloudHub.

Know the high-availability model of an AWS-managed VPN. An AWS-managed VPN comes with built-in redundancy across two Availability Zones. When you create a VPN connection, two endpoints on the VGW are made available. VPN tunnels to both of these endpoints should be created for high availability. Failover is automatic and taken care of by AWS behind the scenes.

Know the steps required to establish a VPN connection to VGW. Creating an AWS-managed VPN is quick and easy. You navigate to the AWS Management Console or use an API to create a VPN connection. You will be prompted to enter various IPsec and routing parameters. You can also download a configuration file for your on-premises device from the AWS Management Console.

Know the steps required to terminate a VPN on an Amazon EC2 instance. VPN connection termination on an Amazon EC2 instance option requires you to create an Amazon EC2 instance and install the VPN software on it. This can be done manually or by using AWS Marketplace. You will have to configure IPsec and routing on the instance.

Know the failover architecture for Amazon EC2-based VPN termination. You will have to set up multiple Amazon EC2 instances for the purpose of high availability. Only one Amazon EC2 instance can be used per subnet for a given destination prefix. For that destination prefix, you have to set up Amazon EC2 instances in Active/Standby mode with a monitoring script to detect failure and perform failover steps.

Know the scaling architectures for Amazon EC2-based VPN termination. Vertical scaling can be achieved by stopping the Amazon EC2 instance and changing its size. For horizontal scaling, you have to decide on a strategy to divide traffic among multiple Amazon EC2 instances. You can also use architectures where your next hop is a single Amazon EC2 instance, which then sends all traffic over GRE to multiple Amazon EC2 instances for actual IPsec encryption.

Know the advantages and disadvantages of Amazon EC2-based VPN termination. You may choose to terminate a VPN on Amazon EC2 if you desire to use a non-IPsec VPN protocol (such as GRE) or if you want additional features on the VPN device (for example, advanced threat protection). The Amazon EC2-based VPN option is also applicable when very high VPN throughput is required or transitive routing architectures will be built.

Know the details of how to set up VPN on the customer side. VPN setup on the customer’s on-premises side can be achieved using an existing VPN termination device.

Know the options available to set up a client-to-site VPN. A client-to-site VPN can be set up by terminating a VPN on an Amazon EC2 instance.

Know the various scenarios in which a VPN can be leveraged. A VPN is used to connect on-premises networks to AWS. It can also be leveraged when encryption is required over AWS Direct Connect or for all traffic between Amazon EC2 instances. A VPN mesh overlay can enable multicast. You can also leverage a VPN to enable transitive routing on the Amazon VPC service.

Know the transitive routing restrictions within a VPC. Amazon VPC does not natively allow transitive routing (for example, VPC A cannot talk to VPC C or another remote network by transiting VPC B). Transitive routing is blocked at all gateway endpoints (for example, peering gateway, VGW, VPC, and Internet gateway).

Know how to create a VPN overlay to enable transitive routing functionality. To enable transitive routing, you will have to set up VPN connections between VPCs and use an Amazon EC2 instance as a transit point.

Resources to Review

• VPN Sections of the Amazon VPC User Guide: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ug.pdf
• VPN Connections Documentation: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpn-connections.html
• Multiple-VPC VPN Connection Sharing: https://aws.amazon.com/answers/networking/ aws-multiple-vpc-vpn-connection-sharing/
• AWS Global Transit Network: https://aws.amazon.com/answers/networking/aws-global-transit-network/
• Single Region Multi-VPC Connectivity: https://aws.amazon.com/answers/networking/ aws-single-region-multi-vpc-connectivity/
• You can follow these re:Invent networking talks on the AWS YouTube channel:
• AWS re:Invent 2017: Deep Dive: AWS Direct Connect and VPNs (NET403): https://www.youtube.com/watch?v=eNxPhHTN8gY
• AWS re:Invent 2017: Extending Data Centers to the Cloud: Connectivity Options and Co (NET301): https://www.youtube.com/watch?v=lN2RybC9Vbk

Exercises

The best way to learn about Virtual Private Network (VPN) connectivity options in AWS and how they compare to each other is to set them up and perform various tests against them. As part of the exercises in this chapter, we will set up the various VPN connectivity options that we discussed in this chapter.