Amazon Virtual Private Cloud
Network Administrator Guide (API Version 2014-02-01)
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.Did this page help you?  Yes | No |  Tell us about it...

Your Customer Gateway

Your Role

Throughout this guide, we refer to your company's integration team, which is the person (or persons) at your company working to integrate your infrastructure with Amazon VPC. This team might consist of just you, or might not include you at all, depending on how your company allocates network engineering resources. The important thing to know is that someone at your company must use the AWS Management Console to get the information that you need to configure your customer gateway, and someone must actually configure the customer gateway. Your company might have a separate team for each task (an integration team that uses the AWS Management Console, and a separate network engineering group that has access to network devices and configures the customer gateway). Or your company might have a single person who does both tasks, or some other arrangement entirely. This guide assumes that you're someone in the network engineering group who receives information from your company's integration team so you can then configure the customer gateway device.

What Is a Customer Gateway?

Your company has decided to use an optional Amazon VPC VPN connection that links your data center (or network) to your Amazon VPC virtual private cloud (VPC). A customer gateway is the anchor on your side of that connection. It can be a physical or software appliance. The anchor on the AWS side of the VPN connection is called a virtual private gateway.

The following diagram shows your network, the customer gateway, the VPN connection that goes to the virtual private gateway, and the VPC. There are two lines between the customer gateway and virtual private gateway because the VPN connection consists of two tunnels. We chose this design to provide increased availability for the Amazon VPC service. If there's a device failure within AWS, your VPN connection automatically fails over to the second tunnel so that your access isn't interrupted. When you configure your customer gateway, it's important you configure both tunnels.

Basic peering diagram

The address of the external interface for your customer gateway must be a static address. We recommend that you don't put your customer gateway behind a device performing network address translation (NAT).

From time to time, AWS performs routine maintenance on the virtual private gateway. This maintenance may disable one of the two tunnels of your VPN connection for a brief period of time. Your VPN connection automatically fails over to the second tunnel while this maintenance is performed. To ensure uninterrupted service, it's important that you configure both tunnels.

To protect against a loss of connectivity if your customer gateway becomes unavailable, you can set up a second VPN connection. For more information, see Using Redundant VPN Connections to Provide Failover.

Summary of What You Need to Do

The overall process of setting up the VPN connection is covered in the Amazon Virtual Private Cloud User Guide. One task in the process is to configure the customer gateway. The following table summarizes what you need to do to configure the customer gateway.

Process for Configuring the Customer Gateway

1

Designate an appliance to act as your customer gateway (for more information, see Customer Gateway Devices We've Tested and Requirements for Your Customer Gateway).

2

Determine the following information about the customer gateway:

  • The vendor (for example, Cisco Systems), the platform (for example, ISR Series Routers), and the software version (for example, IOS 12.4)

  • The Internet-routable IP address for the external interface.

Note

We assume that the BGP ASN for the customer gateway is 65000.

3

Give the preceding information to your integration team. The integration team creates your VPN connection and gets the information that you need to configure the customer gateway.

4

Get the configuration information from the integration team.

5

Configure your customer gateway using the configuration information that you received from the integration team.

6

Notify your integration team when you're done configuring the customer gateway.


You can create additional VPN connections to other VPCs using the same customer gateway appliance. However, each VPN connection requires a separate public IP address on the customer gateway.

Determining Your Network Information

The first task for your integration team is to determine the set of information in the following table. This table includes example values for some of the items. You can use the example values or determine real values. You must obtain real values for all the other items.

Tip

You can print the table and fill in the values you plan to use in the column on the far right.

ItemHow UsedCommentsYour Value

VPC CIDR block

Used in a customer gateway configuration.

Example: 10.0.0.0/16

Subnet #1 CIDR block (can be same as the CIDR block for the VPC)

Example: 10.0.1.0/24

(Optional) Subnet #2 CIDR block

Example: 10.0.2.0/24

(Optional) Subnet #N CIDR block

Customer gateway type (for example, Cisco ISR, Juniper J-Series, or Juniper SSG)

Used in an API call to specify the format of the returned information that you use to configure the customer gateway

Internet-routable IP address of the customer gateway's external interface

Used in customer gateway configuration (referred to as YOUR_UPLINK_ADDRESS)

The value must be static.

(Optional) Border Gateway Protocol (BGP) Autonomous System Number (ASN) of the customer gateway

Used in customer gateway configuration for devices that use BGP (referred to as YOUR_BGP_ASN)

You can use an existing ASN assigned to your network. If you don't have one, you can use a private ASN (in the 64512–65534 range). For more information about ASNs, go to the Wikipedia article.

If you have a firewall between your customer gateway and the Internet, see If You Have a Firewall Between the Internet and Your Customer Gateway.

Four Main Parts to Customer Gateway Configuration

There are four main parts to the configuration of your customer gateway. Throughout this guide, we use a special symbol for each of these parts to help you understand what you need to do. The following table shows the four parts and the corresponding symbols.

IKE Security Association (required to exchange keys used to establish the IPsec security association)

IPsec Security Association (handles the tunnel's encryption, authentication, and so on.)

Tunnel interface (receives traffic going to and from the tunnel)

Optional

BGP peering (exchanges routes between the customer gateway and the virtual private gateway) for devices that use BGP

AWS VPN CloudHub and Redundant Customer Gateways

You can establish multiple VPN connections to a single virtual private gateway from multiple customer gateways. This configuration can be used in different ways; you can have redundant customer gateways between your data center and your VPC, or you can have multiple locations connected to the AWS VPN CloudHub.

If you have redundant customer gateways, each customer gateway advertises the same prefix (for example, 0.0.0.0/0) to the virtual private gateway. The gateways will be used in an active/active mode, but if one customer gateway fails, the virtual private gateway directs all traffic to the working customer gateway.

If you use the AWS VPN CloudHub configuration, multiple sites can access your VPC or securely access each other using a simple hub-and-spoke model. You configure each customer gateway to advertise a site-specific prefix (such as 10.0.0.0/24, 10.0.1.0/24) to the virtual private gateway. The virtual private gateway routes traffic to the appropriate site and advertises the reachability of one site to all other sites.

To configure the AWS VPN CloudHub, use the AWS Management Console to create multiple customer gateways, each with the unique public IP address of the gateway and a unique autonomous system number (ASN). Then create a VPN connection from each customer gateway to a common VPN gateway. Use the instructions that follow to configure each customer gateway to connect to the virtual private gateway.

To enable instances in your VPC to reach the virtual private gateway (and then your customer gateways), you must configure routes in your VPC routing tables. For complete instructions, see the Amazon Virtual Private Cloud User Guide. For AWS VPN CloudHub, you can configure an aggregate route in your VPC routing table (for example, 10.0.0.0/16), and use more specific prefixes between customer gateways and the virtual private gateway.

Configuring Multiple VPN Connections to Your Amazon VPC

You can create up to ten VPN connections for your VPC. You can use multiple VPN connections to link your remote offices to the same VPC. For example, if you have offices in Los Angeles, Chicago, New York, and Miami, you can link each of these offices to your VPC. You can also use multiple VPN connections to establish redundant customer gateways from a single location.

Note

If you need more than ten VPN connections, complete the Request to Increase Amazon VPC Limits form to request an increased limit.

When you create multiple VPN connections, the virtual private gateway sends network traffic to the appropriate VPN connection using statically assigned routes or BGP route advertisements, depending upon how the VPN connection was configured. Statically assigned routes are preferred over BGP advertised routes in cases where identical routes exist in the virtual private gateway.

When you have customer gateways at multiple geographic locations, each customer gateway should advertise a unique set of IP ranges specific to the location. When you establish redundant customer gateways at a single location, both gateways should advertise the same IP ranges.

The virtual private gateway receives routing information from all customer gateways and calculates the set of preferred paths using the BGP best path selection algorithm. The rules of that algorithm, as it applies to VPC, are:

  1. The most specific IP prefix is preferred (for example, 10.0.0.0/24 is preferable to 10.0.0.0/16)

  2. When the prefixes are the same, statically configured VPN connections, if they exist, are preferred. For matching prefixes where each VPN connection uses BGP, the AS PATH is compared and the prefix with the shortest AS PATH is preferred. Alternatively, you can prepend AS_PATH, so that the path is less preferred.

  3. When the AS PATHs are the same length, the path origin is compared. Prefixes with an Interior Gateway Protocol (IGP) origin are preferred to Exterior Gateway Protocol (EGP) origins, which are preferred to unknown origins.

  4. When the origins are the same, the router IDs of the advertising routes are compared. The lowest router ID is preferred.

  5. When the router IDs are the same, the BGP peer IP addresses are compared. The lowest peer IP address is preferred.

The following diagram shows the configuration of multiple VPNs.

Multiple VPN layout

Customer Gateway Devices We've Tested

Your customer gateway can be a physical or software appliance.

For information about the specific routers that we've tested, see What customer gateway devices are known to work with Amazon VPC? in the Amazon VPC FAQ.

This guide presents information about how to configure the following devices:

  • Cisco ASA running Cisco ASA 8.2 (or later) software

  • Cisco IOS running Cisco IOS 12.4 (or later) software

  • Juniper J-Series 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 RT107e, RTX1200, RTX1500, RTX3000 and SRT100 routers

  • Microsoft Windows Server 2008 R2 (or later) software

If you have one of these devices, but configure it for IPsec in a different way than presented in this guide, feel free to alter our suggested configuration to match your particular needs.

Requirements for Your Customer Gateway

If you have a device that isn't in the preceding list of tested devices, this section describes the requirements the device must meet for you to use it with Amazon VPC. The following table lists the requirement the customer gateway must adhere to, the related RFC (for reference), and comments about the requirement. For an example of the configuration information if your device isn't one of the tested Cisco or Juniper devices, see Example: Generic Customer Gateway Using Border Gateway Protocol.

To provide context for the following requirements, think of each VPN connection as consisting of two separate tunnels. Each tunnel contains an IKE Security Association, an IPsec Security Association, and a BGP Peering. Note that you are limited to 2 Security Associations (SAs), one inbound and one outbound. Some devices use policy-based VPN and will create as many SAs as ACL entries. Therefore, you may need to consolidate your rules and then filter so you don't permit unwanted traffic.

The VPN tunnel comes up when traffic is generated from your side of the VPN connection. The AWS endpoint is not the initiator; your customer gateway must initiate the tunnels.

Requirement RFC Comments

Establish IKE Security Association using Pre-Shared Keys

RFC 2409

The IKE Security Association is established first between the virtual private gateway and customer gateway using the Pre-Shared Key as the authenticator. Upon establishment, IKE negotiates an ephemeral key to secure future IKE messages. Proper establishment of an IKE Security Association requires complete agreement among the parameters, including encryption and authentication parameters.

Establish IPsec Security Associations in Tunnel mode

RFC 4301

Using the IKE ephemeral key, keys are established between the virtual private gateway and customer gateway to form an IPsec Security Association (SA). Traffic between gateways is encrypted and decrypted using this SA. The ephemeral keys used to encrypt traffic within the IPsec SA are automatically rotated by IKE on a regular basis to ensure confidentiality of communications.

Utilize the AES 128-bit encryption function

RFC 3602

This encryption function is used to ensure privacy among both IKE and IPsec Security Associations.

Utilize the SHA-1 hashing function

RFC 2404

This hashing function is used to authenticate both IKE and IPsec Security Associations.

Utilize Diffie-Hellman Perfect Forward Secrecy in "Group 2" mode

RFC 2409

IKE uses Diffie-Hellman to establish ephemeral keys to secure all communication between customer gateways and VPN gateways.

Utilize IPsec Dead Peer Detection

RFC 3706

The use of Dead Peer Detection enables the VPN devices to rapidly identify when a network condition prevents delivery of packets across the Internet. When this occurs, the gateways delete the Security Associations and attempt to create new associations. During this process, the alternate IPsec tunnel is utilized if possible.

Bind tunnel to logical interface (route-based VPN)

None

Your gateway must support the ability to bind the IPsec tunnel to a logical interface. The logical interface contains an IP address used to establish BGP peering to the virtual private gateway. This logical interface should perform no additional encapsulation (for example, GRE, IP in IP). Your interface should be set to a 1436 byte Maximum Transmission Unit (MTU). An MTU up to 1500 bytes is supported.

Fragment IP packets before encryption

RFC 4459

When packets are too large to be transmitted, they must be fragmented. We will not reassemble fragmented encrypted packets. Therefore, your VPN device must fragment packets before encapsulating with the VPN headers. The fragments are individually transmitted to the remote host, which reassembles them. For more information about fragmentation, see the Wikipedia article on IP fragmentation.

(Optional) Establish BGP peerings

RFC 4271

BGP is used to exchange routes between the customer gateway and virtual private gateway for devices that use BGP. All BGP traffic is encrypted and transmitted via the IPsec Security Association. BGP is required for both gateways to exchange the IP prefixes reachable through the IPsec SA.

We recommend you use the techniques listed in the following table to minimize problems related to the amount of data that can be transmitted through the IPsec tunnel. Because the connection encapsulates packets with additional network headers (including IPsec), the amount of data that can be transmitted in a single packet is reduced.

Technique RFC Comments

Adjust the maximum segment size of TCP packets entering the VPN tunnel

RFC 4459

TCP packets are often the most prevalent type of packet across IPsec tunnels. Some gateways have the ability to change the TCP Maximum Segment Size parameter. This causes the TCP endpoints (clients, servers) to reduce the amount of data sent with each packet. This is an ideal approach, as the packets arriving at the VPN devices are small enough to be encapsulated and transmitted.

Reset the "Don't Fragment" flag on packets

RFC 791

Some packets carry a flag, known as the Don't Fragment (DF) flag, that indicates that the packet should not be fragmented. If the packets carry the flag, the gateways generate an ICMP Path MTU Exceeded message. In some cases, applications do not contain adequate mechanisms for processing these ICMP messages and reducing the amount of data transmitted in each packet. Some VPN devices have the ability to override the DF flag and fragment packets unconditionally as required. If your customer gateway has this ability, we recommend that you use it as appropriate.

If You Have a Firewall Between the Internet and Your Customer Gateway

To use this service, you must have an Internet-routable IP address to use as the endpoint for the IPsec tunnels connecting your customer gateway to the virtual private gateway. If a firewall is in place between the Internet and your gateway, the rules in the following tables must be in place to establish the IPsec tunnels. The virtual private gateway addresses are in the configuration information that you'll get from the integration team.

Inbound (from the Internet)

Input Rule I1

Source IP

Virtual Private Gateway 1

Dest IP

Customer Gateway

Protocol

UDP

Source Port

500

Destination

500

Input Rule I2

Source IP

Virtual Private Gateway 2

Dest IP

Customer Gateway

Protocol

UDP

Source Port

500

Destination Port

500

Input Rule I3

Source IP

Virtual Private Gateway 1

Dest IP

Customer Gateway

Protocol

IP 50 (ESP)

Input Rule I4

Source IP

Virtual Private Gateway 2

Dest IP

Customer Gateway

Protocol

IP 50 (ESP)


Outbound (to the Internet)

Output Rule O1

Source IP

Customer Gateway

Dest IP

Virtual Private Gateway 1

Protocol

UDP

Source Port

500

Destination Port

500

Output Rule O2

Source IP

Customer Gateway

Dest IP

Virtual Private Gateway 2

Protocol

UDP

Source Port

500

Destination Port

500

Output Rule O3

Source IP

Customer Gateway

Dest IP

Virtual Private Gateway 1

Protocol

IP 50 (ESP)

Output Rule O4

Source IP

Customer Gateway

Dest IP

Virtual Private Gateway 2

Protocol

IP 50 (ESP)


Rules I1, I2, O1, and O2 enable the transmission of IKE packets. Rules I3, I4, O3, and O4 enable the transmission of IPsec packets containing the encrypted network traffic.