# AWS Site-to-Site VPN customer gateway devices A *customer gateway device* is a physical or software appliance that you own or manage in your on-premises network (on your side of a Site-to-Site VPN connection). You or your network administrator must configure the device to work with the Site-to-Site VPN connection. The following diagram shows your network, the customer gateway device, and the VPN connection that goes to the virtual private gateway that is attached to your VPC. The two lines between the customer gateway and virtual private gateway represent the tunnels for the VPN connection. 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. From time to time, AWS also performs routine maintenance on the VPN connection, which might briefly disable one of the two tunnels of your VPN connection. For more information, see [AWS Site-to-Site VPN tunnel endpoint replacements](endpoint-replacements.md). When you configure your customer gateway device, it's therefore important that you configure it to use both tunnels. ![\[High-level customer gateway overview\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/cgw-high-level.png) For the steps to set up a VPN connection, see [Get started with AWS Site-to-Site VPN](SetUpVPNConnections.md). During this process, you create a customer gateway resource in AWS, which provides information to AWS about your device, for example, its public-facing IP address. For more information, see [Customer gateway options for your AWS Site-to-Site VPN connection](cgw-options.md). The customer gateway resource in AWS does not configure or create the customer gateway device. You must configure the device yourself. You can also find software VPN appliances on the [AWS Marketplace](https://aws.amazon.com/marketplace/search/results/ref=brs_navgno_search_box?searchTerms=vpn). # Requirements for an AWS Site-to-Site VPN customer gateway device AWS supports a number of Site-to-Site VPN customer gateway devices, which we provide downloadable configuration files for. For a list of supported devices, and the steps to download the configuration files, see [Static and dynamic routing configuration files](example-configuration-files.md). If you have a device that isn't in the list of supported devices, the following section describes the requirements that the device must meet in order to establish a Site-to-Site VPN connection. There are four main parts to the configuration of your customer gateway device. The following symbols represent each part of the configuration. | | | | --- |--- | | ![\[Internet key exchange symbol\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/IKE.png) | Internet key exchange (IKE) security association. This is required to exchange keys used to establish the IPsec security association. | | ![\[Internet Protocol security\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/IPsec.png) | IPsec security association. This handles the tunnel's encryption, authentication, and so on. | | ![\[Tunnel interface symbol\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/Tunnel.png) | Tunnel interface. This receives traffic going to and from the tunnel. | | ![\[Border Gateway Protocol\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/BGP.png) | (Optional) Border Gateway Protocol (BGP) peering. For devices that use BGP, this exchanges routes between the customer gateway device and the virtual private gateway. | The following table lists the requirements for the customer gateway device, the related RFC (for reference), and comments about the requirements. Each VPN connection consists of two separate tunnels. Each tunnel contains an IKE security association, an IPsec security association, and a BGP peering. You are limited to one unique security association (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 a policy-based VPN and create as many SAs as ACL entries. Therefore, you might need to consolidate your rules and then filter so that you don't permit unwanted traffic. By default, the VPN tunnel comes up when traffic is generated and the IKE negotiation is initiated from your side of the VPN connection. You can configure the VPN connection to initiate the IKE negotiation from the AWS side of the connection instead. For more information, see [AWS Site-to-Site VPN tunnel initiation options](initiate-vpn-tunnels.md). VPN endpoints support rekey and can start renegotiations when phase 1 is about to expire if the customer gateway device hasn't sent any renegotiation traffic. | Requirement | RFC | Comments | | --- | --- | --- | | Establish IKE security association ![\[IKE\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/IKE.png) | [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2409) [RFC 7296](https://datatracker.ietf.org/doc/html/rfc7296) | The IKE security association is established first between the virtual private gateway and the customer gateway device using a pre-shared key or a private certificate that uses AWS Private Certificate Authority as the authenticator. When established, IKE negotiates an ephemeral key to secure future IKE messages. There must be complete agreement among the parameters, including encryption and authentication parameters. When you create a VPN connection in AWS, you can specify your own pre-shared key for each tunnel, or you can let AWS generate one for you. Alternatively, you can specify the private certificate using AWS Private Certificate Authority to use for your customer gateway device. For more information, about configuring VPN tunnels see [Tunnel options for your AWS Site-to-Site VPN connection](VPNTunnels.md). The following versions are supported: IKEv1 and IKEv2. We support Main mode only with IKEv1. The Site-to-Site VPN service is a route-based solution. If you are using a policy-based configuration, you must limit your configuration to a single security association (SA). | | Establish IPsec security associations in Tunnel mode ![\[IPsec\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/IPsec.png) | [RFC 4301](https://datatracker.ietf.org/doc/html/rfc4301) | Using the IKE ephemeral key, keys are established between the virtual private gateway and the customer gateway device 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. | | Use the AES 128-bit encryption or AES 256-bit encryption function | [RFC 3602](https://datatracker.ietf.org/doc/html/rfc3602) | The encryption function is used to ensure privacy for both IKE and IPsec security associations. | | Use the SHA-1 or SHA-2 (256) hashing function | [RFC 2404](https://datatracker.ietf.org/doc/html/rfc2404) | This hashing function is used to authenticate both IKE and IPsec security associations. | | Use Diffie-Hellman Perfect Forward Secrecy. | [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2409) | IKE uses Diffie-Hellman to establish ephemeral keys to secure all communication between customer gateway devices and virtual private gateways. The following groups are supported: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/CGRequirements.html) | | (Dynamically-routed VPN connections) Use IPsec Dead Peer Detection | [RFC 3706](https://datatracker.ietf.org/doc/html/rfc3706) | 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 used if possible. | | (Dynamically-routed VPN connections) Bind tunnel to logical interface (route-based VPN) ![\[Tunnel\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/Tunnel.png) | None | Your device must be able to bind the IPsec tunnel to a logical interface. The logical interface contains an IP address that is used to establish BGP peering to the virtual private gateway. This logical interface should perform no additional encapsulation (for example, GRE or IP in IP). Your interface should be set to a 1399 byte Maximum Transmission Unit (MTU). | | (Dynamically-routed VPN connections) Establish BGP peerings ![\[BGP\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/BGP.png) | [RFC 4271](https://datatracker.ietf.org/doc/html/rfc4271) | BGP is used to exchange routes between the customer gateway device and the 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 that are reachable through the IPsec SA. | An AWS VPN connection does not support Path MTU Discovery ([RFC 1191](https://datatracker.ietf.org/doc/html/rfc1191)). If you have a firewall between your customer gateway device and the internet, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md). # Best practices for an AWS Site-to-Site VPN customer gateway device **Use IKEv2** We strongly recommend using IKEv2 for your Site-to-Site VPN connection. IKEv2 is a simpler, more robust, and more secure protocol than IKEv1. You should only use IKEv1 if your customer gateway device does not support IKEv2. For more details on the differences between IKEv1 and IKEv2, see [Appendix A of RFC7296](https://www.rfc-editor.org/rfc/rfc7296#appendix-A). **Reset the "Don't Fragment (DF)" flag on packets** Some packets carry a flag, known as the Don't Fragment (DF) flag, which 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 for reducing the amount of data transmitted in each packet. Some VPN devices can override the DF flag and fragment packets unconditionally as required. If your customer gateway device has this ability, we recommend that you use it as appropriate. See [RFC 791](https://datatracker.ietf.org/doc/html/rfc791) for more details. **Fragment IP packets before encryption** If packets being sent to over your Site-to-Site VPN connection exceed the MTU size, they must be fragmented. To avoid decreased performance, we recommend that you configure your customer gateway device to fragment the packets *before* they are encrypted. Site-to-Site VPN will then reassemble any fragmented packets before forwarding them to the next destination, in order to achieve higher packet-per-second flows through the AWS network. See [RFC 4459](https://datatracker.ietf.org/doc/html/rfc4459) for more details. **Ensure packet size does not exceed MTU for destination networks** Since Site-to-Site VPN will reassemble any fragmented packets received from your customer gateway device before forwarding to the next destination, keep in mind, there may be packet size/MTU considerations for destination networks where these packets get forwarded next, such as over Direct Connect, or with certain protocols, such as Radius. **Adjust MTU and MSS sizes according to the algorithms in use** TCP packets are often the most common type of packet across IPsec tunnels. Site-to-Site VPN supports a maximum transmission unit (MTU) of 1446 bytes and a corresponding maximum segment size (MSS) of 1406 bytes. However, encryption algorithms have varying header sizes and can prevent the ability to achieve these maximum values. To obtain optimal performance by avoiding fragmentation, we recommend that you set the MTU and MSS based specifically on the algorithms being used. Use the following table to set your MTU/MSS to avoid fragmentation and achieve optimal performance: | Encryption Algorithm | Hashing Algorithm | NAT-Traversal | MTU | MSS (IPv4) | MSS (IPv6-in-IPv4) | | --- | --- | --- | --- | --- | --- | | AES-GCM-16 | N/A | disabled | 1446 | 1406 | 1386 | | AES-GCM-16 | N/A | enabled | 1438 | 1398 | 1378 | | AES-CBC | SHA1/SHA2-256 | disabled | 1438 | 1398 | 1378 | | AES-CBC | SHA1/SHA2-256 | enabled | 1422 | 1382 | 1362 | | AES-CBC | SHA2-384 | disabled | 1422 | 1382 | 1362 | | AES-CBC | SHA2-384 | enabled | 1422 | 1382 | 1362 | | AES-CBC | SHA2-512 | disabled | 1422 | 1382 | 1362 | | AES-CBC | SHA2-512 | enabled | 1406 | 1366 | 1346 | **Note** The AES-GCM algorithms cover both encryption and authentication, so there is no distinct authentication algorithm choice which would affect MTU. **Disable IKE unique IDs** Some customer gateway devices support a setting which ensures that at most, one Phase 1 security association exists per tunnel configuration. This setting can result in inconsistent Phase 2 states between VPN peers. If your customer gateway device supports this setting, we recommend disabling it. # Firewall rules for an AWS Site-to-Site VPN customer gateway device You must have a static IP address to use as the endpoint for the IPsec tunnels that connect your customer gateway device to AWS Site-to-Site VPN endpoints. If a firewall is in place between AWS and your customer gateway device, the rules in the following tables must be in place to establish the IPsec tunnels. The IP addresses for the AWS-side will be in the configuration file. **Inbound (from the internet)** | | | Input rule I1 | | --- | | Source IP | Tunnel1 Outside IP | | Dest IP | Customer Gateway | | Protocol | UDP | | Source port | 500 | | Destination | 500 | | Input rule I2 | | --- | | Source IP | Tunnel2 Outside IP | | Dest IP | Customer Gateway | | Protocol | UDP | | Source port | 500 | | Destination port | 500 | | Input rule I3 | | --- | | Source IP | Tunnel1 Outside IP | | Dest IP | Customer Gateway | | Protocol | IP 50 (ESP) | | Input rule I4 | | --- | | Source IP | Tunnel2 Outside IP | | Dest IP | Customer Gateway | | Protocol | IP 50 (ESP) | **Outbound (to the internet)** | | | Output rule O1 | | --- | | Source IP | Customer Gateway | | Dest IP | Tunnel1 Outside IP | | Protocol | UDP | | Source port | 500 | | Destination port | 500 | | Output rule O2 | | --- | | Source IP | Customer Gateway | | Dest IP | Tunnel2 Outside IP | | Protocol | UDP | | Source port | 500 | | Destination port | 500 | | Output rule O3 | | --- | | Source IP | Customer Gateway | | Dest IP | Tunnel1 Outside IP | | Protocol | IP 50 (ESP) | | Output rule O4 | | --- | | Source IP | Customer Gateway | | Dest IP | Tunnel2 Outside IP | | 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 that contain the encrypted network traffic. **Note** If you are using NAT traversal (NAT-T) on your device, ensure that UDP traffic on port 4500 is also allowed to pass between your network and the AWS Site-to-Site VPN endpoints. Check if your device is advertising NAT-T. # Static and dynamic configuration files for an AWS Site-to-Site VPN customer gateway device After you create the VPN connection, you additionally have the option to download an AWS-provided sample configuration file from the Amazon VPC console, or by using the EC2 API. See [Step 6: Download the configuration file](SetUpVPNConnections.md#vpn-download-config) for more information. You can also download .zip files of sample configurations specifically for static vs. dynamic routing from those respective pages. The AWS-provided sample configuration file contains information specific to your VPN connection which you can use to configure your customer gateway device. These device-specific configuration files are only available for devices that AWS has tested. If your specific customer gateway device is not listed, you can download a generic configuration file to begin with. **Important** The configuration file is an example only and might not match your intended Site-to-Site VPN connection settings entirely. It specifies the minimum requirements for a Site-to-Site VPN connection of AES128, SHA1, and Diffie-Hellman group 2 in most AWS Regions, and AES128, SHA2, and Diffie-Hellman group 14 in the AWS GovCloud Regions. It also specifies pre-shared keys for authentication. You must modify the example configuration file to take advantage of additional security algorithms, Diffie-Hellman groups, private certificates, and IPv6 traffic. **Note** These device-specific configuration files are provided by AWS on a best-effort basis. While they have been tested by AWS, this testing is limited. If you are experiencing an issue with the configuration files, you might need to contact the specific vendor for additional support. The following table contains a list of devices which have an example configuration file available for download that has been updated to support IKEv2. We have introduced IKEv2 support in the configuration files for many popular customer gateway devices and will continue to add additional files over time. This list will be updated as more example configuration files are added. | Vendor | Platform | Software | | --- | --- | --- | | AXGATE | NF | AOS 3.2\$1 | | AXGATE | UTM | AOS 2.1\$1 | | Checkpoint | Gaia | R80.10\$1 | | Cisco Meraki | MX Series | 15.12\$1 (WebUI) | | Cisco Systems, Inc. | ASA 5500 Series | ASA 9.7\$1 VTI | | Cisco Systems, Inc. | CSRv AMI | IOS 12.4\$1 | | Fortinet | Fortigate 40\$1 Series | FortiOS 6.4.4\$1 (GUI) | | Juniper Networks, Inc. | J-Series Routers | JunOS 9.5\$1 | | Juniper Networks, Inc. | SRX Routers | JunOS 11.0\$1 | | Mikrotik | RouterOS | 6.44.3 | | Palo Alto Networks | PA Series | PANOS 7.0\$1 | | SonicWall | NSA, TZ | OS 6.5 | | Sophos | Sophos Firewall | v19\$1 | | Strongswan | Ubuntu 16.04 | Strongswan 5.5.1\$1 | | Yamaha | RTX Routers | Rev.10.01.16\$1 | # Downloadable static routing configuration files for an AWS Site-to-Site VPN customer gateway device To download a sample configuration file with values specific to your Site-to-Site VPN connection configuration, use the Amazon VPC console, the AWS command line or the Amazon EC2 API. For more information, see [Step 6: Download the configuration file](SetUpVPNConnections.md#vpn-download-config). You can also download generic example configuration files for static routing that do not include values specific to your Site-to-Site VPN connection configuration: [static-routing-examples.zip](samples/static-routing-examples.zip) The files use placeholder values for some components. For example, they use: + Example values for the VPN connection ID, customer gateway ID and virtual private gateway ID + Placeholders for the remote (outside) IP address AWS endpoints (*AWS\$1ENDPOINT\$11* and *AWS\$1ENDPOINT\$12*) + A placeholder for the IP address for the internet-routable external interface on the customer gateway device (*your-cgw-ip-address*) + A placeholder for the pre-shared key value (pre-shared-key) + Example values for the tunnel inside IP addresses. + Example values for MTU setting. **Note** MTU settings provided in the sample configuration files are examples only. Please refer to [Best practices for an AWS Site-to-Site VPN customer gateway device](cgw-best-practice.md) for information on setting the optimal MTU value for your situation. In addition to providing placeholder values, the files specify the minimum requirements for a Site-to-Site VPN connection of AES128, SHA1, and Diffie-Hellman group 2 in most AWS Regions, and AES128, SHA2, and Diffie-Hellman group 14 in the AWS GovCloud Regions. They also specify pre-shared keys for [authentication](vpn-tunnel-authentication-options.md). You must modify the example configuration file to take advantage of additional security algorithms, Diffie-Hellman groups, private certificates, and IPv6 traffic. The following diagram provides an overview of the different components that are configured on the customer gateway device. It includes example values for the tunnel interface IP addresses. ![\[Customer gateway device with static routing\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/cgw-static-routing.png) # Configure static routing for an AWS Site-to-Site VPN customer gateway device The following are some example procedures for configuring a customer gateway device using its user interface (if available). ------ #### [ Check Point ] The following are steps for configuring your customer gateway device if your device is a Check Point Security Gateway device running R77.10 or above, using the Gaia operating system and Check Point SmartDashboard. You can also refer to the [Check Point Security Gateway IPsec VPN to Amazon Web Services VPC](https://support.checkpoint.com/results/sk/sk100726) article on the Check Point Support Center. **To configure the tunnel interface** The first step is to create the VPN tunnels and provide the private (inside) IP addresses of the customer gateway and virtual private gateway for each tunnel. To create the first tunnel, use the information provided under the `IPSec Tunnel #1` section of the configuration file. To create the second tunnel, use the values provided in the `IPSec Tunnel #2` section of the configuration file. 1. Open the Gaia portal of your Check Point Security Gateway device. 1. Choose **Network Interfaces**, **Add**, **VPN tunnel**. 1. In the dialog box, configure the settings as follows, and choose **OK** when you are done: + For **VPN Tunnel ID**, enter any unique value, such as 1. + For **Peer**, enter a unique name for your tunnel, such as `AWS_VPC_Tunnel_1` or `AWS_VPC_Tunnel_2`. + Ensure that **Numbered** is selected, and for **Local Address**, enter the IP address specified for `CGW Tunnel IP` in the configuration file, for example, `169.254.44.234`. + For **Remote Address**, enter the IP address specified for `VGW Tunnel IP` in the configuration file, for example, `169.254.44.233`. ![\[Check Point Add VPN Tunnel dialog box\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-create-tunnel.png) 1. Connect to your security gateway over SSH. If you're using the non-default shell, change to clish by running the following command: `clish` 1. For tunnel 1, run the following command. ``` set interface vpnt1 mtu 1436 ``` For tunnel 2, run the following command. ``` set interface vpnt2 mtu 1436 ``` 1. Repeat these steps to create a second tunnel, using the information under the `IPSec Tunnel #2` section of the configuration file. **To configure the static routes** In this step, specify the static route to the subnet in the VPC for each tunnel to enable you to send traffic over the tunnel interfaces. The second tunnel enables failover in case there is an issue with the first tunnel. If an issue is detected, the policy-based static route is removed from the routing table, and the second route is activated. You must also enable the Check Point gateway to ping the other end of the tunnel to check if the tunnel is up. 1. In the Gaia portal, choose **IPv4 Static Routes**, **Add**. 1. Specify the CIDR of your subnet, for example, `10.28.13.0/24`. 1. Choose **Add Gateway**, **IP Address**. 1. Enter the IP address specified for `VGW Tunnel IP` in the configuration file (for example, `169.254.44.233`), and specify a priority of 1. 1. Select **Ping**. 1. Repeat steps 3 and 4 for the second tunnel, using the `VGW Tunnel IP` value under the `IPSec Tunnel #2` section of the configuration file. Specify a priority of 2. ![\[Check Point Edit Destination Route dialog box\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-static-routes.png) 1. Choose **Save**. If you're using a cluster, repeat the preceding steps for the other members of the cluster. **To define a new network object** In this step, you create a network object for each VPN tunnel, specifying the public (outside) IP addresses for the virtual private gateway. You later add these network objects as satellite gateways for your VPN community. You also need to create an empty group to act as a placeholder for the VPN domain. 1. Open the Check Point SmartDashboard. 1. For **Groups**, open the context menu and choose **Groups**, **Simple Group**. You can use the same group for each network object. 1. For **Network Objects**, open the context (right-click) menu and choose **New**, **Interoperable Device**. 1. For **Name**, enter the name that you provided for your tunnel, for example, `AWS_VPC_Tunnel_1` or `AWS_VPC_Tunnel_2`. 1. For **IPv4 Address**, enter the outside IP address of the virtual private gateway provided in the configuration file, for example, `54.84.169.196`. Save your settings and close the dialog box. ![\[Check Point Interoperable Device dialog box\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-network-device.png) 1. In the SmartDashboard, open your gateway properties and in the category pane, choose **Topology**. 1. To retrieve the interface configuration, choose **Get Topology**. 1. In the **VPN Domain** section, choose **Manually defined**, and then browse to and select the empty simple group that you created in step 2. Choose **OK**. **Note** You can keep any existing VPN domain that you've configured. However, ensure that the hosts and networks that are used or served by the new VPN connection are not declared in that VPN domain, especially if the VPN domain is automatically derived. 1. Repeat these steps to create a second network object, using the information under the `IPSec Tunnel #2` section of the configuration file. **Note** If you're using clusters, edit the topology and define the interfaces as cluster interfaces. Use the IP addresses that are specified in the configuration file. **To create and configure the VPN community, IKE, and IPsec settings** In this step, you create a VPN community on your Check Point gateway, to which you add the network objects (interoperable devices) for each tunnel. You also configure the Internet Key Exchange (IKE) and IPsec settings. 1. From your gateway properties, choose **IPSec VPN** in the category pane. 1. Choose **Communities**, **New**, **Star Community**. 1. Provide a name for your community (for example, `AWS_VPN_Star`), and then choose **Center Gateways** in the category pane. 1. Choose **Add**, and add your gateway or cluster to the list of participant gateways. 1. In the category pane, choose **Satellite Gateways**, **Add**, and then add the interoperable devices that you created earlier (`AWS_VPC_Tunnel_1` and `AWS_VPC_Tunnel_2`) to the list of participant gateways. 1. In the category pane, choose **Encryption**. In the **Encryption Method** section, choose **IKEv1 only**. In the **Encryption Suite** section, choose **Custom**, **Custom Encryption**. 1. In the dialog box, configure the encryption properties as follows, and choose **OK** when you're done: + IKE Security Association (Phase 1) Properties: + **Perform key exchange encryption with**: AES-128 + **Perform data integrity with**: SHA-1 + IPsec Security Association (Phase 2) Properties: + **Perform IPsec data encryption with**: AES-128 + **Perform data integrity with**: SHA-1 1. In the category pane, choose **Tunnel Management**. Choose **Set Permanent Tunnels**, **On all tunnels in the community**. In the **VPN Tunnel Sharing** section, choose **One VPN tunnel per Gateway pair**. 1. In the category pane, expand **Advanced Settings**, and choose **Shared Secret**. 1. Select the peer name for the first tunnel, choose **Edit**, and then enter the pre-shared key as specified in the configuration file in the `IPSec Tunnel #1` section. 1. Select the peer name for the second tunnel, choose **Edit**, and then enter the pre-shared key as specified in the configuration file in the `IPSec Tunnel #2` section. ![\[Check Point Interoperable Shared Secret dialog box\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-shared-secret.png) 1. Still in the **Advanced Settings** category, choose **Advanced VPN Properties**, configure the properties as follows, and then choose **OK** when you're done: + IKE (Phase 1): + **Use Diffie-Hellman group**: `Group 2` + **Renegotiate IKE security associations every** `480` **minutes** + IPsec (Phase 2): + Choose **Use Perfect Forward Secrecy** + **Use Diffie-Hellman group**: `Group 2` + **Renegotiate IPsec security associations every** `3600` **seconds** **To create firewall rules** In this step, you configure a policy with firewall rules and directional match rules that allow communication between the VPC and the local network. You then install the policy on your gateway. 1. In the SmartDashboard, choose **Global Properties** for your gateway. In the category pane, expand **VPN**, and choose **Advanced**. 1. Choose **Enable VPN Directional Match in VPN Column**, and save your changes. 1. In the SmartDashboard, choose **Firewall**, and create a policy with the following rules: + Allow the VPC subnet to communicate with the local network over the required protocols. + Allow the local network to communicate with the VPC subnet over the required protocols. 1. Open the context menu for the cell in the VPN column, and choose **Edit Cell**. 1. In the **VPN Match Conditions** dialog box, choose **Match traffic in this direction only**. Create the following directional match rules by choosing **Add** for each, and choose **OK** when you're done: + `internal_clear` > VPN community (The VPN star community that you created earlier, for example, `AWS_VPN_Star`) + VPN community > VPN community + VPN community > `internal_clear` 1. In the SmartDashboard, choose **Policy**, **Install**. 1. In the dialog box, choose your gateway and choose **OK** to install the policy. **To modify the tunnel\$1keepalive\$1method property** Your Check Point gateway can use Dead Peer Detection (DPD) to identify when an IKE association is down. To configure DPD for a permanent tunnel, the permanent tunnel must be configured in the AWS VPN community (refer to Step 8). By default, the `tunnel_keepalive_method` property for a VPN gateway is set to `tunnel_test`. You must change the value to `dpd`. Each VPN gateway in the VPN community that requires DPD monitoring must be configured with the `tunnel_keepalive_method` property, including any 3rd party VPN gateway. You cannot configure different monitoring mechanisms for the same gateway. You can update the `tunnel_keepalive_method` property using the GuiDBedit tool. 1. Open the Check Point SmartDashboard, and choose **Security Management Server**, **Domain Management Server**. 1. Choose **File**, **Database Revision Control...** and create a revision snapshot. 1. Close all SmartConsole windows, such as the SmartDashboard, SmartView Tracker, and SmartView Monitor. 1. Start the GuiBDedit tool. For more information, see the [Check Point Database Tool](https://support.checkpoint.com/results/sk/sk13009) article on the Check Point Support Center. 1. Choose **Security Management Server**, **Domain Management Server**. 1. In the upper left pane, choose **Table**, **Network Objects**, **network\$1objects**. 1. In the upper right pane, select the relevant **Security Gateway**, **Cluster** object. 1. Press CTRL\$1F, or use the **Search** menu to search for the following: `tunnel_keepalive_method`. 1. In the lower pane, open the context menu for `tunnel_keepalive_method`, and choose **Edit...**. Choose **dpd** and then choose **OK**. 1. Repeat steps 7 through 9 for each gateway that's part of the AWS VPN Community. 1. Choose **File**, **Save All**. 1. Close the GuiDBedit tool. 1. Open the Check Point SmartDashboard, and choose **Security Management Server**, **Domain Management Server**. 1. Install the policy on the relevant **Security Gateway**, **Cluster** object. For more information, see the [New VPN features in R77.10](https://support.checkpoint.com/results/sk/sk97746) article on the Check Point Support Center. **To enable TCP MSS clamping** TCP MSS clamping reduces the maximum segment size of TCP packets to prevent packet fragmentation. 1. Navigate to the following directory: `C:\Program Files (x86)\CheckPoint\SmartConsole\R77.10\PROGRAM\`. 1. Open the Check Point Database Tool by running the `GuiDBEdit.exe` file. 1. Choose **Table**, **Global Properties**, **properties**. 1. For `fw_clamp_tcp_mss`, choose **Edit**. Change the value to `true` and choose **OK**. **To verify the tunnel status** You can verify the tunnel status by running the following command from the command line tool in expert mode. ``` vpn tunnelutil ``` In the options that display, choose **1** to verify the IKE associations and **2** to verify the IPsec associations. You can also use the Check Point Smart Tracker Log to verify that packets over the connection are being encrypted. For example, the following log indicates that a packet to the VPC was sent over tunnel 1 and was encrypted. ![\[Check Point log file\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-log.png) ------ #### [ SonicWALL ] The following procedure demonstrates how to configure the VPN tunnels on the SonicWALL device using the SonicOS management interface. **To configure the tunnels** 1. Open the SonicWALL SonicOS management interface. 1. In the left pane, choose **VPN**, **Settings**. Under **VPN Policies**, choose **Add...**. 1. In the VPN policy window on the **General ** tab, complete the following information: + **Policy Type**: Choose **Tunnel Interface**. + **Authentication Method**: Choose **IKE using Preshared Secret**. + **Name**: Enter a name for the VPN policy. We recommend that you use the name of the VPN ID, as provided in the configuration file. + **IPsec Primary Gateway Name or Address**: Enter the IP address of the virtual private gateway as provided in the configuration file (for example, `72.21.209.193`). + **IPsec Secondary Gateway Name or Address**: Leave the default value. + **Shared Secret**: Enter the pre-shared key as provided in the configuration file, and enter it again in **Confirm Shared Secret**. + **Local IKE ID**: Enter the IPv4 address of the customer gateway (the SonicWALL device). + **Peer IKE ID**: Enter the IPv4 address of the virtual private gateway. 1. On the **Network** tab, complete the following information: + Under **Local Networks**, choose **Any address**. We recommend this option to prevent connectivity issues from your local network. + Under **Remote Networks**, choose **Choose a destination network from list**. Create an address object with the CIDR of your VPC in AWS. 1. On the **Proposals** tab, complete the following information: + Under **IKE (Phase 1) Proposal**, do the following: + **Exchange**: Choose **Main Mode**. + **DH Group**: Enter a value for the Diffie-Hellman group (for example, `2`). + **Encryption**: Choose **AES-128** or **AES-256**. + **Authentication**: Choose **SHA1** or **SHA256**. + **Life Time**: Enter `28800`. + Under **IKE (Phase 2) Proposal**, do the following: + **Protocol**: Choose **ESP**. + **Encryption**: Choose **AES-128** or **AES-256**. + **Authentication**: Choose **SHA1** or **SHA256**. + Select the **Enable Perfect Forward Secrecy** check box, and choose the Diffie-Hellman group. + **Life Time**: Enter `3600`. **Important** If you created your virtual private gateway before October 2015, you must specify Diffie-Hellman group 2, AES-128, and SHA1 for both phases. 1. On the **Advanced** tab, complete the following information: + Select **Enable Keep Alive**. + Select **Enable Phase2 Dead Peer Detection** and enter the following: + For **Dead Peer Detection Interval**, enter `60` (this is the minimum that the SonicWALL device accepts). + For **Failure Trigger Level**, enter `3`. + For **VPN Policy bound to**, select **Interface X1**. This is the interface that's typically designated for public IP addresses. 1. Choose **OK**. On the **Settings** page, the **Enable** check box for the tunnel should be selected by default. A green dot indicates that the tunnel is up. ------ ## Cisco devices: additional information Some Cisco ASAs only support Active/Standby mode. When you use these Cisco ASAs, you can have only one active tunnel at a time. The other standby tunnel becomes active if the first tunnel becomes unavailable. With this redundancy, you should always have connectivity to your VPC through one of the tunnels. Cisco ASAs from version 9.7.1 and later support Active/Active mode. When you use these Cisco ASAs, you can have both tunnels active at the same time. With this redundancy, you should always have connectivity to your VPC through one of the tunnels. For Cisco devices, you must do the following: + Configure the outside interface. + Ensure that the Crypto ISAKMP Policy Sequence number is unique. + Ensure that the Crypto List Policy Sequence number is unique. + Ensure that the Crypto IPsec Transform Set and the Crypto ISAKMP Policy Sequence are harmonious with any other IPsec tunnels that are configured on the device. + Ensure that the SLA monitoring number is unique. + Configure all internal routing that moves traffic between the customer gateway device and your local network. # Downloadable dynamic routing configuration files for AWS Site-to-Site VPN customer gateway device To download a sample configuration file with values specific to your Site-to-Site VPN connection configuration, use the Amazon VPC console, the AWS command line or the Amazon EC2 API. For more information, see [Step 6: Download the configuration file](SetUpVPNConnections.md#vpn-download-config). You can also download generic example configuration files for dynamic routing that do not include values specific to your Site-to-Site VPN connection configuration: [dynamic-routing-examples.zip](samples/dynamic-routing-examples.zip) The files use placeholder values for some components. For example, they use: + Example values for the VPN connection ID, customer gateway ID and virtual private gateway ID + Placeholders for the remote (outside) IP address AWS endpoints (*AWS\$1ENDPOINT\$11* and *AWS\$1ENDPOINT\$12*) + A placeholder for the IP address for the internet-routable external interface on the customer gateway device (*your-cgw-ip-address*) + A placeholder for the pre-shared key value (pre-shared-key) + Example values for the tunnel inside IP addresses. + Example values for MTU setting. **Note** MTU settings provided in the sample configuration files are examples only. Please refer to [Best practices for an AWS Site-to-Site VPN customer gateway device](cgw-best-practice.md) for information on setting the optimal MTU value for your situation. In addition to providing placeholder values, the files specify the minimum requirements for a Site-to-Site VPN connection of AES128, SHA1, and Diffie-Hellman group 2 in most AWS Regions, and AES128, SHA2, and Diffie-Hellman group 14 in the AWS GovCloud Regions. They also specify pre-shared keys for [authentication](vpn-tunnel-authentication-options.md). You must modify the example configuration file to take advantage of additional security algorithms, Diffie-Hellman groups, private certificates, and IPv6 traffic. The following diagram provides an overview of the different components that are configured on the customer gateway device. It includes example values for the tunnel interface IP addresses. ![\[Customer gateway device with dynamic routing\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/cgw-bgp.png) # Configure dynamic routing for an AWS Virtual Private Network customer gateway device The following are some example procedures for configuring a customer gateway device using its user interface (if available). ------ #### [ Check Point ] The following are steps for configuring a Check Point Security Gateway device running R77.10 or above, using the Gaia web portal and Check Point SmartDashboard. You can also refer to the [Amazon Web Services (AWS) VPN BGP](https://support.checkpoint.com/results/sk/sk108958) article on the Check Point Support Center. **To configure the tunnel interface** The first step is to create the VPN tunnels and provide the private (inside) IP addresses of the customer gateway and virtual private gateway for each tunnel. To create the first tunnel, use the information provided under the `IPSec Tunnel #1` section of the configuration file. To create the second tunnel, use the values provided in the `IPSec Tunnel #2` section of the configuration file. 1. Connect to your security gateway over SSH. If you're using the non-default shell, change to clish by running the following command: `clish` 1. Set the customer gateway ASN (the ASN that was provided when the customer gateway was created in AWS) by running the following command. ``` set as 65000 ``` 1. Create the tunnel interface for the first tunnel, using the information provided under the `IPSec Tunnel #1` section of the configuration file. Provide a unique name for your tunnel, such as `AWS_VPC_Tunnel_1`. ``` add vpn tunnel 1 type numbered local 169.254.44.234 remote 169.254.44.233 peer AWS_VPC_Tunnel_1 set interface vpnt1 state on set interface vpnt1 mtu 1436 ``` 1. Repeat these commands to create the second tunnel, using the information provided under the `IPSec Tunnel #2` section of the configuration file. Provide a unique name for your tunnel, such as `AWS_VPC_Tunnel_2`. ``` add vpn tunnel 1 type numbered local 169.254.44.38 remote 169.254.44.37 peer AWS_VPC_Tunnel_2 set interface vpnt2 state on set interface vpnt2 mtu 1436 ``` 1. Set the virtual private gateway ASN. ``` set bgp external remote-as 7224 on ``` 1. Configure the BGP for the first tunnel, using the information provided `IPSec Tunnel #1` section of the configuration file. ``` set bgp external remote-as 7224 peer 169.254.44.233 on set bgp external remote-as 7224 peer 169.254.44.233 holdtime 30 set bgp external remote-as 7224 peer 169.254.44.233 keepalive 10 ``` 1. Configure the BGP for the second tunnel, using the information provided `IPSec Tunnel #2` section of the configuration file. ``` set bgp external remote-as 7224 peer 169.254.44.37 on set bgp external remote-as 7224 peer 169.254.44.37 holdtime 30 set bgp external remote-as 7224 peer 169.254.44.37 keepalive 10 ``` 1. Save the configuration. ``` save config ``` **To create a BGP policy** Next, create a BGP policy that allows the import of routes that are advertised by AWS. Then, configure your customer gateway to advertise its local routes to AWS. 1. In the Gaia WebUI, choose **Advanced Routing**, **Inbound Route Filters**. Choose **Add**, and select **Add BGP Policy (Based on AS)**. 1. For **Add BGP Policy**, select a value between 512 and 1024 in the first field, and enter the virtual private gateway ASN in the second field (for example, `7224`). 1. Choose **Save**. **To advertise local routes** The following steps are for distributing local interface routes. You can also redistribute routes from different sources (for example, static routes, or routes obtained through dynamic routing protocols). For more information, see the [Gaia Advanced Routing R77 Versions Administration Guide](https://sc1.checkpoint.com/documents/R77/CP_R77_Gaia_Advanced_Routing_WebAdminGuide/html_frameset.htm). 1. In the Gaia WebUI, choose **Advanced Routing**,** Routing Redistribution**. Choose **Add Redistribution From** and then select **Interface**. 1. For **To Protocol**, select the virtual private gateway ASN (for example, `7224`). 1. For **Interface**, select an internal interface. Choose **Save**. **To define a new network object** Next, create a network object for each VPN tunnel, specifying the public (outside) IP addresses for the virtual private gateway. You later add these network objects as satellite gateways for your VPN community. You also need to create an empty group to act as a placeholder for the VPN domain. 1. Open the Check Point SmartDashboard. 1. For **Groups**, open the context menu and choose **Groups**, **Simple Group**. You can use the same group for each network object. 1. For **Network Objects**, open the context (right-click) menu and choose **New**, **Interoperable Device**. 1. For **Name**, enter the name that you provided for your tunnel in step 1, for example, `AWS_VPC_Tunnel_1` or `AWS_VPC_Tunnel_2`. 1. For **IPv4 Address**, enter the outside IP address of the virtual private gateway provided in the configuration file, for example, `54.84.169.196`. Save your settings and close the dialog box. ![\[Check Point Interoperable Device dialog box\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-network-device.png) 1. In the left category pane, choose **Topology**. 1. In the **VPN Domain** section, choose **Manually defined**, and then browse to and select the empty simple group that you created in step 2. Choose **OK**. 1. Repeat these steps to create a second network object, using the information under the `IPSec Tunnel #2` section of the configuration file. 1. Go to your gateway network object, open your gateway or cluster object, and choose **Topology**. 1. In the **VPN Domain** section, choose **Manually defined**, and then browse to and select the empty simple group that you created in step 2. Choose **OK**. **Note** You can keep any existing VPN domain that you've configured. However, ensure that the hosts and networks that are used or served by the new VPN connection are not declared in that VPN domain, especially if the VPN domain is automatically derived. **Note** If you're using clusters, edit the topology and define the interfaces as cluster interfaces. Use the IP addresses that are specified in the configuration file. **To create and configure the VPN community, IKE, and IPsec settings** Next, create a VPN community on your Check Point gateway, to which you add the network objects (interoperable devices) for each tunnel. You also configure the Internet Key Exchange (IKE) and IPsec settings. 1. From your gateway properties, choose **IPSec VPN** in the category pane. 1. Choose **Communities**, **New**, **Star Community**. 1. Provide a name for your community (for example, `AWS_VPN_Star`), and then choose **Center Gateways** in the category pane. 1. Choose **Add**, and add your gateway or cluster to the list of participant gateways. 1. In the category pane, choose **Satellite Gateways**, **Add**, and add the interoperable devices that you created earlier (`AWS_VPC_Tunnel_1` and `AWS_VPC_Tunnel_2`) to the list of participant gateways. 1. In the category pane, choose **Encryption**. In the **Encryption Method** section, choose **IKEv1 for IPv4 and IKEv2 for IPv6**. In the **Encryption Suite** section, choose **Custom**, **Custom Encryption**. **Note** You must select the **IKEv1 for IPv4 and IKEv2 for IPv6** option for IKEv1 functionality. 1. In the dialog box, configure the encryption properties as follows, and then choose **OK** when you're done: + IKE Security Association (Phase 1) Properties: + **Perform key exchange encryption with**: AES-128 + **Perform data integrity with**: SHA-1 + IPsec Security Association (Phase 2) Properties: + **Perform IPsec data encryption with**: AES-128 + **Perform data integrity with**: SHA-1 1. In the category pane, choose **Tunnel Management**. Choose **Set Permanent Tunnels**, **On all tunnels in the community**. In the **VPN Tunnel Sharing** section, choose **One VPN tunnel per Gateway pair**. 1. In the category pane, expand **Advanced Settings**, and choose **Shared Secret**. 1. Select the peer name for the first tunnel, choose **Edit**, and then enter the pre-shared key as specified in the configuration file in the `IPSec Tunnel #1` section. 1. Select the peer name for the second tunnel, choose **Edit**, and then enter the pre-shared key as specified in the configuration file in the `IPSec Tunnel #2` section. ![\[Check Point Interoperable Shared Secret dialog box\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-shared-secret.png) 1. Still in the **Advanced Settings** category, choose **Advanced VPN Properties**, configure the properties as follows, and then choose **OK** when you're done: + IKE (Phase 1): + **Use Diffie-Hellman group**: `Group 2 (1024 bit)` + **Renegotiate IKE security associations every** `480` **minutes** + IPsec (Phase 2): + Choose **Use Perfect Forward Secrecy** + **Use Diffie-Hellman group**: `Group 2 (1024 bit)` + **Renegotiate IPsec security associations every** `3600` **seconds** **To create firewall rules** Next, configure a policy with firewall rules and directional match rules that allow communication between the VPC and the local network. You then install the policy on your gateway. 1. In the SmartDashboard, choose **Global Properties** for your gateway. In the category pane, expand **VPN**, and choose **Advanced**. 1. Choose **Enable VPN Directional Match in VPN Column**, and choose **OK**. 1. In the SmartDashboard, choose **Firewall**, and create a policy with the following rules: + Allow the VPC subnet to communicate with the local network over the required protocols. + Allow the local network to communicate with the VPC subnet over the required protocols. 1. Open the context menu for the cell in the VPN column, and choose **Edit Cell**. 1. In the **VPN Match Conditions** dialog box, choose **Match traffic in this direction only**. Create the following directional match rules by choosing **Add** for each, and then choose **OK** when you're done: + `internal_clear` > VPN community (The VPN star community that you created earlier, for example, `AWS_VPN_Star`) + VPN community > VPN community + VPN community > `internal_clear` 1. In the SmartDashboard, choose **Policy**, **Install**. 1. In the dialog box, choose your gateway and choose **OK** to install the policy. **To modify the tunnel\$1keepalive\$1method property** Your Check Point gateway can use Dead Peer Detection (DPD) to identify when an IKE association is down. To configure DPD for a permanent tunnel, the permanent tunnel must be configured in the AWS VPN community. By default, the `tunnel_keepalive_method` property for a VPN gateway is set to `tunnel_test`. You must change the value to `dpd`. Each VPN gateway in the VPN community that requires DPD monitoring must be configured with the `tunnel_keepalive_method` property, including any 3rd party VPN gateway. You cannot configure different monitoring mechanisms for the same gateway. You can update the `tunnel_keepalive_method` property using the GuiDBedit tool. 1. Open the Check Point SmartDashboard, and choose **Security Management Server**, **Domain Management Server**. 1. Choose **File**, **Database Revision Control...** and create a revision snapshot. 1. Close all SmartConsole windows, such as the SmartDashboard, SmartView Tracker, and SmartView Monitor. 1. Start the GuiBDedit tool. For more information, see the [Check Point Database Tool](https://support.checkpoint.com/results/sk/sk13009) article on the Check Point Support Center. 1. Choose **Security Management Server**, **Domain Management Server**. 1. In the upper left pane, choose **Table**, **Network Objects**, **network\$1objects**. 1. In the upper right pane, select the relevant **Security Gateway**, **Cluster** object. 1. Press CTRL\$1F, or use the **Search** menu to search for the following: `tunnel_keepalive_method`. 1. In the lower pane, open the context menu for `tunnel_keepalive_method`, and select **Edit...**. Choose **dpd**, **OK**. 1. Repeat steps 7 through 9 for each gateway that's part of the AWS VPN Community. 1. Choose **File**, **Save All**. 1. Close the GuiDBedit tool. 1. Open the Check Point SmartDashboard, and choose **Security Management Server**, **Domain Management Server**. 1. Install the policy on the relevant **Security Gateway**, **Cluster** object. For more information, see the [New VPN features in R77.10](https://support.checkpoint.com/results/sk/sk97746) article on the Check Point Support Center. **To enable TCP MSS clamping** TCP MSS clamping reduces the maximum segment size of TCP packets to prevent packet fragmentation. 1. Navigate to the following directory: `C:\Program Files (x86)\CheckPoint\SmartConsole\R77.10\PROGRAM\`. 1. Open the Check Point Database Tool by running the `GuiDBEdit.exe` file. 1. Choose **Table**, **Global Properties**, **properties**. 1. For `fw_clamp_tcp_mss`, choose **Edit**. Change the value to `true` and then choose **OK**. **To verify the tunnel status** You can verify the tunnel status by running the following command from the command line tool in expert mode. ``` vpn tunnelutil ``` In the options that display, choose **1** to verify the IKE associations and **2** to verify the IPsec associations. You can also use the Check Point Smart Tracker Log to verify that packets over the connection are being encrypted. For example, the following log indicates that a packet to the VPC was sent over tunnel 1 and was encrypted. ![\[Check Point log file\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/check-point-log.png) ------ #### [ SonicWALL ] You can configure a SonicWALL device using the SonicOS management interface. For more information about configuring the tunnels, see [Configure static routing for an AWS Site-to-Site VPN customer gateway device](cgw-static-routing-example-interface.md). You cannot configure BGP for the device using the management interface. Instead, use the command line instructions provided in the example configuration file, under the section named **BGP**. ------ ## Cisco devices: additional information Some Cisco ASAs only support Active/Standby mode. When you use these Cisco ASAs, you can have only one active tunnel at a time. The other standby tunnel becomes active if the first tunnel becomes unavailable. With this redundancy, you should always have connectivity to your VPC through one of the tunnels. Cisco ASAs from version 9.7.1 and later support Active/Active mode. When you use these Cisco ASAs, you can have both tunnels active at the same time. With this redundancy, you should always have connectivity to your VPC through one of the tunnels. For Cisco devices, you must do the following: + Configure the outside interface. + Ensure that the Crypto ISAKMP Policy Sequence number is unique. + Ensure that the Crypto List Policy Sequence number is unique. + Ensure that the Crypto IPsec Transform Set and the Crypto ISAKMP Policy Sequence are harmonious with any other IPsec tunnels that are configured on the device. + Ensure that the SLA monitoring number is unique. + Configure all internal routing that moves traffic between the customer gateway device and your local network. ## Juniper devices: additional information The following information applies to the example configuration files for Juniper J-Series and SRX customer gateway devices. + The outside interface is referred to as *ge-0/0/0.0*. + The tunnel interface IDs are referred to as *st0.1* and *st0.2*. + Ensure that you identify the security zone for the uplink interface (the configuration information uses the default 'untrust' zone). + Ensure that you identify the security zone for the inside interface (the configuration information uses the default 'trust' zone). # Configure Windows Server as an AWS Site-to-Site VPN customer gateway device You can configure a server running Windows Server as a customer gateway device for your VPC. Use the following process whether you are running Windows Server on an EC2 instance in a VPC, or on your own server. The following procedures apply to Windows Server 2012 R2 and later. **Topics** + [ ## Configuring your Windows instance ](#cgw-device-windows-server-configure-instance) + [ ## Step 1: Create a VPN connection and configure your VPC ](#cgw-device-windows-server-vpn) + [ ## Step 2: Download the configuration file for the VPN connection ](#cgw-device-windows-server-config) + [ ## Step 3: Configure the Windows Server ](#cgw-device-windows-server-configure) + [ ## Step 4: Set up the VPN tunnel ](#cgw-device-windows-server-setup-tunnel) + [ ## Step 5: Enable dead gateway detection ](#cgw-device-windows-server-gateway-detection) + [ ## Step 6: Test the VPN connection ](#cgw-device-windows-server-test-connection) ## Configuring your Windows instance If you are configuring Windows Server on an EC2 instance that you launched from a Windows AMI, do the following: + Disable source/destination checking for the instance: 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Select your Windows instance, and choose **Actions**, **Networking**, **Change source/destination check**. Choose **Stop**, and then choose **Save**. + Update your adapter settings so that you can route traffic from other instances: 1. Connect to your Windows instance. For more information, see [Connecting to your Windows instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html). 1. Open the Control Panel, and start the Device Manager. 1. Expand the **Network adapters** node. 1. Select the network adapter (depending on the instance type, this might be Amazon Elastic Network Adapter or Intel 82599 Virtual Function), and choose **Action**, **Properties**. 1. On the **Advanced** tab, disable the **IPv4 Checksum Offload**, **TCP Checksum Offload (IPv4)**, and **UDP Checksum Offload (IPv4)** properties, and then choose **OK**. + Allocate an Elastic IP address to your account and associate it with the instance. For more information, see [Elastic IP addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) in the *Amazon EC2 User Guide*. Take note of this address — you need it when you create the customer gateway. + Ensure that the instance's security group rules allow outbound IPsec traffic. By default, a security group allows all outbound traffic. However, if the security group's outbound rules have been modified from their original state, you must create the following outbound custom protocol rules for IPsec traffic: IP protocol 50, IP protocol 51, and UDP 500. Take note of the CIDR range of the network in which your Windows instance is located, for example, `172.31.0.0/16`. ## Step 1: Create a VPN connection and configure your VPC To create a VPN connection from your VPC, do the following: 1. Create a virtual private gateway and attach it to your VPC. For more information, see [Create a virtual private gateway](SetUpVPNConnections.md#vpn-create-vpg). 1. Create a VPN connection and new customer gateway. For the customer gateway, specify the public IP address of your Windows Server. For the VPN connection, choose static routing, and then enter the CIDR range for your network in which the Windows Server is located, for example, `172.31.0.0/16`. For more information, see [Step 5: Create a VPN connection](SetUpVPNConnections.md#vpn-create-vpn-connection). After you create the VPN connection, configure the VPC to enable communication over the VPN connection. **To configure your VPC** + Create a private subnet in your VPC (if you don't have one already) for launching instances to communicate with the Windows Server. For more information, see [Creating a subnet in your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#AddaSubnet). **Note** A private subnet is a subnet that does not have a route to an internet gateway. The routing for this subnet is described in the next item. + Update your route tables for the VPN connection: + Add a route to your private subnet's route table with the virtual private gateway as the target, and the Windows Server's network (CIDR range) as the destination. For more information, see [Adding and removing routes from a route table](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) in the *Amazon VPC User Guide*. + Enable route propagation for the virtual private gateway. For more information, see [(Virtual private gateway) Enable route propagation in your route table](SetUpVPNConnections.md#vpn-configure-routing). + Create a security group for your instances that allows communication between your VPC and network: + Add rules that allow inbound RDP or SSH access from your network. This enables you to connect to instances in your VPC from your network. For example, to allow computers in your network to access Linux instances in your VPC, create an inbound rule with a type of SSH, and the source set to the CIDR range of your network (for example, `172.31.0.0/16`). For more information, see [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon VPC User Guide*. + Add a rule that allows inbound ICMP access from your network. This enables you to test your VPN connection by pinging an instance in your VPC from your Windows Server. ## Step 2: Download the configuration file for the VPN connection You can use the Amazon VPC console to download a Windows Server configuration file for your VPN connection. **To download the configuration file** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Site-to-Site VPN Connections**. 1. Select your VPN connection and choose **Download Configuration**. 1. Select **Microsoft** as the vendor, **Windows Server** as the platform, and **2012 R2** as the software. Choose **Download**. You can open the file or save it. The configuration file contains a section of information similar to the following example. You see this information presented twice, one time for each tunnel. ``` vgw-1a2b3c4d Tunnel1 -------------------------------------------------------------------- Local Tunnel Endpoint:       203.0.113.1 Remote Tunnel Endpoint:      203.83.222.237 Endpoint 1:                  [Your_Static_Route_IP_Prefix] Endpoint 2:                  [Your_VPC_CIDR_Block] Preshared key:               xCjNLsLoCmKsakwcdoR9yX6GsEXAMPLE ``` `Local Tunnel Endpoint` The IP address that you specified for the customer gateway when you created the VPN connection. `Remote Tunnel Endpoint` One of two IP addresses for the virtual private gateway that terminates the VPN connection on the AWS side of the connection. `Endpoint 1` The IP prefix that you specified as a static route when you created the VPN connection. These are the IP addresses in your network that are allowed to use the VPN connection to access your VPC. `Endpoint 2` The IP address range (CIDR block) of the VPC that is attached to the virtual private gateway (for example 10.0.0.0/16). `Preshared key` The pre-shared key that is used to establish the IPsec VPN connection between `Local Tunnel Endpoint` and `Remote Tunnel Endpoint`. We suggest that you configure both tunnels as part of the VPN connection. Each tunnel connects to a separate Site-to-Site VPN Concentrator on the Amazon side of the VPN connection. Although only one tunnel at a time is up, the second tunnel automatically establishes itself if the first tunnel goes down. Having redundant tunnels ensure continuous availability in the case of a device failure. Because only one tunnel is available at a time, the Amazon VPC console indicates that one tunnel is down. This is expected behavior, so there's no action required from you. With two tunnels configured, if a device failure occurs within AWS, your VPN connection automatically fails over to the second tunnel of the virtual private gateway within a matter of minutes. When you configure your customer gateway device, it's important that you configure both tunnels. **Note** From time to time, AWS performs routine maintenance on the virtual private gateway. This maintenance might 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 we perform this maintenance. Additional information regarding the Internet Key Exchange (IKE) and IPsec Security Associations (SA) is presented in the downloaded configuration file. ``` MainModeSecMethods: DHGroup2-AES128-SHA1 MainModeKeyLifetime: 480min,0sess QuickModeSecMethods: ESP:SHA1-AES128+60min+100000kb QuickModePFS: DHGroup2 ``` `MainModeSecMethods` The encryption and authentication algorithms for the IKE SA. These are the suggested settings for the VPN connection, and are the default settings for Windows Server IPsec VPN connections. `MainModeKeyLifetime` The IKE SA key lifetime.  This is the suggested setting for the VPN connection, and is the default setting for Windows Server IPsec VPN connections. `QuickModeSecMethods` The encryption and authentication algorithms for the IPsec SA. These are the suggested settings for the VPN connection, and are the default settings for Windows Server IPsec VPN connections. `QuickModePFS` We suggest that you use master key perfect forward secrecy (PFS) for your IPsec sessions. ## Step 3: Configure the Windows Server Before you set up the VPN tunnel, you must install and configure Routing and Remote Access Services on Windows Server. That allows remote users to access resources on your network. **To install Routing and Remote Access Services** 1. Log on to your Windows Server. 1. Go to the **Start** menu, and choose **Server Manager**. 1. Install Routing and Remote Access Services: 1. From the **Manage** menu, choose **Add Roles and Features**. 1. On the **Before You Begin** page, verify that your server meets the prerequisites, and then choose **Next**. 1. Choose **Role-based or feature-based installation**, and then choose **Next**. 1. Choose **Select a server from the server pool**, select your Windows Server, and then choose **Next**. 1. Select **Network Policy and Access Services** in the list. In the dialog box that displays, choose **Add Features** to confirm the features that are required for this role. 1. In the same list, choose **Remote Access**, **Next**. 1. On the **Select features** page, choose **Next**. 1. On the **Network Policy and Access Services** page, choose **Next**. 1. On the **Remote Access** page, choose **Next**. On the next page, select **DirectAccess and VPN (RAS)**. In the dialog box that displays, choose **Add Features** to confirm the features that are required for this role service. In the same list, select **Routing**, and then choose **Next**. 1. On the **Web Server Role (IIS)** page, choose **Next**. Leave the default selection, and choose **Next**. 1. Choose **Install**. When the installation completes, choose **Close**. **To configure and enable Routing and Remote Access Server** 1. On the dashboard, choose **Notifications** (the flag icon). There should be a task to complete the post-deployment configuration. Choose the **Open the Getting Started Wizard** link. 1. Choose **Deploy VPN only**. 1. In the **Routing and Remote Access** dialog box, choose the server name, choose **Action**, and then select **Configure and Enable Routing and Remote Access**. 1. In the **Routing and Remote Access Server Setup Wizard**, on the first page, choose **Next**. 1. On the **Configuration** page, choose **Custom Configuration**, **Next**. 1. Choose **LAN routing**, **Next**, **Finish**. 1. When prompted by the **Routing and Remote Access** dialog box, choose **Start service**. ## Step 4: Set up the VPN tunnel You can configure the VPN tunnel by running the netsh scripts included in the downloaded configuration file, or by using the Windows Server user interface. **Important** We suggest that you use master key perfect forward secrecy (PFS) for your IPsec sessions. If you choose to run the netsh script, it includes a parameter to enable PFS (`qmpfs=dhgroup2`). You cannot enable PFS using the Windows user interface — you must enable it using the command line. **Topics** + [ ### Option 1: Run the netsh script ](#cgw-device-windows-server-run-netsh) + [ ### Option 2: Use the Windows Server user interface ](#cgw-device-windows-server-ui) ### Option 1: Run the netsh script Copy the netsh script from the downloaded configuration file and replace the variables. The following is an example script. ``` netsh advfirewall consec add rule Name="vgw-1a2b3c4d Tunnel 1" ^ Enable=Yes Profile=any Type=Static Mode=Tunnel ^ LocalTunnelEndpoint=Windows_Server_Private_IP_address ^ RemoteTunnelEndpoint=203.83.222.236 Endpoint1=Your_Static_Route_IP_Prefix ^ Endpoint2=Your_VPC_CIDR_Block Protocol=Any Action=RequireInClearOut ^ Auth1=ComputerPSK Auth1PSK=xCjNLsLoCmKsakwcdoR9yX6GsEXAMPLE ^ QMSecMethods=ESP:SHA1-AES128+60min+100000kb ^ ExemptIPsecProtectedConnections=No ApplyAuthz=No QMPFS=dhgroup2 ``` **Name**: You can replace the suggested name (`vgw-1a2b3c4d Tunnel 1)` with a name of your choice. **LocalTunnelEndpoint**: Enter the private IP address of the Windows Server on your network. **Endpoint1**: The CIDR block of your network on which the Windows Server resides, for example, `172.31.0.0/16`. Surround this value with double quotes ("). **Endpoint2**: The CIDR block of your VPC or a subnet in your VPC, for example, `10.0.0.0/16`. Surround this value with double quotes ("). Run the updated script in a command prompt window on your Windows Server. (The ^ enables you to cut and paste wrapped text at the command line.) To set up the second VPN tunnel for this VPN connection, repeat the process using the second netsh script in the configuration file. When you are done, go to [Configure the Windows firewall](#cgw-device-windows-server-firewall). For more information about the netsh parameters, see [Netsh AdvFirewall Consec Commands](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd736198(v=ws.10)?redirectedfrom=MSDN#BKMK_2_set) in the *Microsoft TechNet Library*. ### Option 2: Use the Windows Server user interface You can also use the Windows Server user interface to set up the VPN tunnel. **Important** You can't enable master key perfect forward secrecy (PFS) using the Windows Server user interface. You must enable PFS using the command line, as described in [Enable master key perfect forward secrecy](#cgw-device-windows-server-enable-pfs). **Topics** + [ #### Configure a security rule for a VPN tunnel ](#cgw-device-windows-server-security-rule) + [ #### Confirm the tunnel configuration ](#cgw-device-windows-server-confirm-tunnel) + [ #### Enable master key perfect forward secrecy ](#cgw-device-windows-server-enable-pfs) + [ #### Configure the Windows firewall ](#cgw-device-windows-server-firewall) #### Configure a security rule for a VPN tunnel In this section, you configure a security rule on your Windows Server to create a VPN tunnel. **To configure a security rule for a VPN tunnel** 1. Open Server Manager, choose **Tools**, and then select **Windows Defender Firewall with Advanced Security**. 1. Select **Connection Security Rules**, choose **Action**, and then **New Rule**. 1. In the **New Connection Security Rule** wizard, on the **Rule Type** page, choose **Tunnel**, and then choose **Next**. 1. On the **Tunnel Type** page, under **What type of tunnel would you like to create**, choose **Custom configuration**. Under **Would you like to exempt IPsec-protected connections from this tunnel**, leave the default value checked (**No. Send all network traffic that matches this connection security rule through the tunnel**), and then choose **Next**. 1. On the **Requirements** page, choose **Require authentication for inbound connections. Do not establish tunnels for outbound connections**, and then choose **Next**. 1. On the **Tunnel Endpoints** page, under **Which computers are in Endpoint 1**, choose **Add**. Enter the CIDR range of your network (behind your Windows Server customer gateway device; for example, `172.31.0.0/16`), and then choose **OK**. The range can include the IP address of your customer gateway device. 1. Under **What is the local tunnel endpoint (closest to computer in Endpoint 1)**, choose **Edit**. In the **IPv4 address** field, enter the private IP address of your Windows Server, and then choose **OK**. 1. Under **What is the remote tunnel endpoint (closest to computers in Endpoint 2)**, choose **Edit**. In the **IPv4 address** field, enter the IP address of the virtual private gateway for Tunnel 1 from the configuration file (see `Remote Tunnel Endpoint`), and then choose **OK**. **Important** If you are repeating this procedure for Tunnel 2, be sure to select the endpoint for Tunnel 2. 1. Under **Which computers are in Endpoint 2**, choose **Add**. In the **This IP address or subnet field**, enter the CIDR block of your VPC, and then choose **OK**. **Important** You must scroll in the dialog box until you locate **Which computers are in Endpoint 2**. Do not choose **Next** until you have completed this step, or you won't be able to connect to your server. ![\[New Connection Security Rule Wizard: Tunnel Endpoints\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/tunnelendpoints_complete_win2012.png) 1. Confirm that all of the settings you've specified are correct and then choose **Next**. 1. On the **Authentication Method** page, select **Advanced** and choose **Customize**. 1. Under **First authentication methods**, choose **Add**. 1. Select **Preshared key**, enter the pre-shared key value from the configuration file and then choose **OK**. **Important** If you are repeating this procedure for Tunnel 2, be sure to select the pre-shared key for Tunnel 2. 1. Ensure that **First authentication is optional** is not selected, and choose **OK**. 1. Choose **Next**. 1. On the **Profile** page, select all three check boxes: **Domain**, **Private**, and **Public**. Choose **Next**. 1. On the **Name** page, enter a name for your connection rule; for example, `VPN to Tunnel 1`, and then choose **Finish**. Repeat the preceding procedure, specifying the data for Tunnel 2 from your configuration file. After you've finished, you’ll have two tunnels configured for your VPN connection. #### Confirm the tunnel configuration **To confirm the tunnel configuration** 1. Open Server Manager, choose **Tools**, select **Windows Firewall with Advanced Security**, and then select **Connection Security Rules**. 1. Verify the following for both tunnels: + **Enabled** is `Yes` + **Endpoint 1** is the CIDR block for your network + **Endpoint 2** is the CIDR block of your VPC + **Authentication mode** is `Require inbound and clear outbound` + **Authentication method** is `Custom` + **Endpoint 1 port** is `Any` + **Endpoint 2 port** is `Any` + **Protocol** is `Any` 1. Select the first rule and choose **Properties**. 1. On the **Authentication** tab, under **Method**, choose **Customize**. Verify that **First authentication methods** contains the correct pre-shared key from your configuration file for the tunnel, and then choose **OK**. 1. On the **Advanced** tab, verify that **Domain**, **Private**, and **Public** are all selected. 1. Under **IPsec tunneling**, choose **Customize**. Verify the following IPsec tunneling settings, and then choose **OK** and **OK** again to close the dialog box. + **Use IPsec tunneling** is selected. + **Local tunnel endpoint (closest to Endpoint 1)** contains the IP address of your Windows Server. If your customer gateway device is an EC2 instance, this is the instance's private IP address. + **Remote tunnel endpoint (closest to Endpoint 2)** contains the IP address of the virtual private gateway for this tunnel. 1. Open the properties for your second tunnel. Repeat steps 4 to 7 for this tunnel. #### Enable master key perfect forward secrecy You can enable master key perfect forward secrecy by using the command line. You cannot enable this feature using the user interface. **To enable master key perfect forward secrecy** 1. In your Windows Server, open a new command prompt window. 1. Enter the following command, replacing `rule_name` with the name that you gave the first connection rule. ``` netsh advfirewall consec set rule name="rule_name" new QMPFS=dhgroup2 QMSecMethods=ESP:SHA1-AES128+60min+100000kb ``` 1. Repeat step 2 for the second tunnel, this time replacing `rule_name` with the name that you gave the second connection rule. #### Configure the Windows firewall After setting up your security rules on your server, configure some basic IPsec settings to work with the virtual private gateway. **To configure the Windows firewall** 1. Open Server Manager, choose **Tools**, select **Windows Defender Firewall with Advanced Security**, and then choose **Properties**. 1. On the **IPsec Settings** tab, under **IPsec exemptions**, verify that **Exempt ICMP from IPsec** is **No (default)**. Verify that **IPsec tunnel authorization** is **None**. 1. Under **IPsec defaults**, choose **Customize**. 1. Under **Key exchange (Main Mode)**, select **Advanced** and then choose **Customize**. 1. In **Customize Advanced Key Exchange Settings**, under **Security methods**, verify that the following default values are used for the first entry: + Integrity: SHA-1 + Encryption: AES-CBC 128 + Key exchange algorithm: Diffie-Hellman Group 2 + Under **Key lifetimes**, verify that **Minutes** is `480` and **Sessions** is `0`. These settings correspond to these entries in the configuration file. ``` MainModeSecMethods: DHGroup2-AES128-SHA1,DHGroup2-3DES-SHA1 MainModeKeyLifetime: 480min,0sec ``` 1. Under **Key exchange options**, select **Use Diffie-Hellman for enhanced security**, and then choose **OK**. 1. Under **Data protection (Quick Mode)**, select **Advanced**, and then choose **Customize**. 1. Select **Require encryption for all connection security rules that use these settings**. 1. Under **Data integrity and encryption**, leave the default values: + Protocol: ESP + Integrity: SHA-1 + Encryption: AES-CBC 128 + Lifetime: 60 minutes These values correspond to the following entry from the configuration file. ``` QuickModeSecMethods: ESP:SHA1-AES128+60min+100000kb ``` 1. Choose **OK** to return to the **Customize IPsec Settings** dialog box and choose **OK** again to save the configuration. ## Step 5: Enable dead gateway detection Next, configure TCP to detect when a gateway becomes unavailable. You can do this by modifying this registry key: `HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters`. Do not perform this step until you’ve completed the preceding sections. After you change the registry key, you must reboot the server. **To enable dead gateway detection** 1. From your Windows Server, launch the command prompt or a PowerShell session, and enter **regedit** to start Registry Editor. 1. Expand **HKEY\$1LOCAL\$1MACHINE**, expand **SYSTEM**, expand **CurrentControlSet**, expand **Services**, expand **Tcpip**, and then expand **Parameters**. 1. From the **Edit** menu, select **New** and select **DWORD (32-bit) Value**. 1. Enter the name **EnableDeadGWDetect**. 1. Select **EnableDeadGWDetect** and choose **Edit**, **Modify**. 1. In **Value data**, enter **1**, and then choose **OK**. 1. Close the Registry Editor and reboot the server. For more information, see [EnableDeadGWDetect](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc960464(v=technet.10)?redirectedfrom=MSDN) in the *Microsoft TechNet Library*. ## Step 6: Test the VPN connection To test that the VPN connection is working correctly, launch an instance into your VPC, and ensure that it does not have an internet connection. After you've launched the instance, ping its private IP address from your Windows Server. The VPN tunnel comes up when traffic is generated from the customer gateway device. Therefore, the ping command also initiates the VPN connection. For steps to test the VPN connection, see [Test an AWS Site-to-Site VPN connection](HowToTestEndToEnd_Linux.md). If the `ping` command fails, check the following information: + Ensure that you have configured your security group rules to allow ICMP to the instance in your VPC. If your Windows Server is an EC2 instance, ensure that its security group's outbound rules allow IPsec traffic. For more information, see [Configuring your Windows instance](#cgw-device-windows-server-configure-instance). + Ensure that the operating system on the instance you are pinging is configured to respond to ICMP. We recommend that you use one of the Amazon Linux AMIs. + If the instance you are pinging is a Windows instance, connect to the instance and enable inbound ICMPv4 on the Windows firewall. + Ensure that you have configured the route tables correctly for your VPC or your subnet. For more information, see [Step 1: Create a VPN connection and configure your VPC](#cgw-device-windows-server-vpn). + If your customer gateway device is an EC2 instance, ensure that you've disabled source/destination checking for the instance. For more information, see [Configuring your Windows instance](#cgw-device-windows-server-configure-instance). In the Amazon VPC console, on the **VPN Connections** page, select your VPN connection. The first tunnel is in the UP state. The second tunnel should be configured, but it isn't used unless the first tunnel goes down. It may take a few moments to establish the encrypted tunnels. # Troubleshooting AWS Site-to-Site VPN customer gateway device When troubleshooting issues with your customer gateway device, it's important to have a structured approach. The first two topics in this section provide generalized flowcharts for troubleshooting issues when using a device configured for dynamic routing (BGP enabled), and a device configured for static routing (without BGP enabled), respectively. Following those topics are device-specific troubleshooting guides for Cisco, Juniper, and Yamaha customer gateway devices. In addition to the topics in this section, enabling [AWS Site-to-Site VPN logs](monitoring-logs.md) can be very helpful for troubleshooting and resolving VPN connectivity issues. For general testing instructions, also see [Test an AWS Site-to-Site VPN connection](HowToTestEndToEnd_Linux.md). **Topics** + [Device with BGP](Generic_Troubleshooting.md) + [Device without BGP](Generic_Troubleshooting_noBGP.md) + [Cisco ASA](Cisco_ASA_Troubleshooting.md) + [Cisco IOS](Cisco_Troubleshooting.md) + [Cisco IOS without BGP](Cisco_Troubleshooting_NoBGP.md) + [Juniper JunOS](Juniper_Troubleshooting.md) + [Juniper ScreenOS](Juniper_ScreenOs_Troubleshooting.md) + [Yamaha](Yamaha_Troubleshooting.md) **Additional resources** + [Amazon VPC forum](https://repost.aws/tags/TATGuEiYydTVCPMhSnXFN6gA/amazon-vpc) # Troubleshoot AWS Site-to-Site VPN connectivity when using Border Gateway Protocol The following diagram and table provide general instructions for troubleshooting a customer gateway device that uses Border Gateway Protocol (BGP). We also recommend that you enable the debug features of your device. Consult your gateway device vendor for details. ![\[Flow chart for troubleshooting a generic customer gateway device\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-diagram.png) | | | | --- |--- | | IKE | Determine if an IKE security association exists. An IKE security association is required to exchange keys that are used to establish the IPsec security association. If no IKE security association exists, review your IKE configuration settings. You must configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If an IKE security association exists, move on to 'IPsec'. | | IPsec | Determine if an IPsec security association (SA) exists. An IPsec SA is the tunnel itself. Query your customer gateway device to determine if an IPsec SA is active. Ensure that you configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If no IPsec SA exists, review your IPsec configuration. If an IPsec SA exists, move on to 'Tunnel'. | | Tunnel | Confirm that the required firewall rules are set up (for a list of the rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md)). If they are, move forward. Determine if there is IP connectivity through the tunnel. Each side of the tunnel has an IP address as specified in the configuration file. The virtual private gateway address is the address used as the BGP neighbor address. From your customer gateway device, ping this address to determine if IP traffic is being properly encrypted and decrypted. If the ping isn't successful, review your tunnel interface configuration to make sure that the proper IP address is configured. If the ping is successful, move on to 'BGP'. | | BGP | Determine if the BGP peering session is active. For each tunnel, do the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/Generic_Troubleshooting.html) If the tunnels are not in this state, review your BGP configuration. If the BGP peering is established, you are receiving a prefix, and you are advertising a prefix, your tunnel is configured correctly. Make sure that both tunnels are in this state. | # Troubleshoot AWS Site-to-Site VPN connectivity without Border Gateway Protocol The following diagram and table provide general instructions for troubleshooting a customer gateway device that does not use Border Gateway Protocol (BGP). We also recommend that you enable the debug features of your device. Consult your gateway device vendor for details. ![\[Flow chart for troubleshooting generic customer gateway device\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-nobgp-diagram.png) | | | | --- |--- | | IKE | Determine if an IKE security association exists. An IKE security association is required to exchange keys that are used to establish the IPsec security association. If no IKE security association exists, review your IKE configuration settings. You must configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If an IKE security association exists, move on to 'IPsec'. | | IPsec | Determine if an IPsec security association (SA) exists. An IPsec SA is the tunnel itself. Query your customer gateway device to determine if an IPsec SA is active. Ensure that you configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If no IPsec SA exists, review your IPsec configuration. If an IPsec SA exists, move on to 'Tunnel'. | | Tunnel | Confirm that the required firewall rules are set up (for a list of the rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md)). If they are, move forward. Determine if there is IP connectivity through the tunnel. Each side of the tunnel has an IP address as specified in the configuration file. The virtual private gateway address is the address used as the BGP neighbor address. From your customer gateway device, ping this address to determine if IP traffic is being properly encrypted and decrypted. If the ping isn't successful, review your tunnel interface configuration to make sure that the proper IP address is configured. If the ping is successful, move on to 'Static routes'. | | Static routes | For each tunnel, do the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/Generic_Troubleshooting_noBGP.html) If the tunnels are not in this state, review your device configuration. Make sure that both tunnels are in this state, and you're done. | # Troubleshoot AWS Site-to-Site VPN connectivity with a Cisco ASA customer gateway device When you troubleshoot the connectivity of a Cisco customer gateway device, consider IKE, IPsec, and routing. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up. **Important** Some Cisco ASAs only support Active/Standby mode. When you use these Cisco ASAs, you can have only one active tunnel at a time. The other standby tunnel becomes active only if the first tunnel becomes unavailable. The standby tunnel might produce the following error in your log files, which can be ignored: `Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside` . ## IKE Use the following command. The response shows a customer gateway device with IKE configured correctly. ``` ciscoasa# show crypto isakmp sa ``` ``` Active SA: 2 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 2 1 IKE Peer: AWS_ENDPOINT_1 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE ``` You should see one or more lines containing an `src` value for the remote gateway that is specified in the tunnels. The `state` value should be `MM_ACTIVE` and `status` should be `ACTIVE`. The absence of an entry, or any entry in another state, indicates that IKE is not configured properly. For further troubleshooting, run the following commands to enable log messages that provide diagnostic information. ``` router# term mon router# debug crypto isakmp ``` To disable debugging, use the following command. ``` router# no debug crypto isakmp ``` ## IPsec Use the following command. The response shows a customer gateway device with IPsec configured correctly. ``` ciscoasa# show crypto ipsec sa ``` ``` interface: outside Crypto map tag: VPN_crypto_map_name, seq num: 2, local addr: 172.25.50.101 access-list integ-ppe-loopback extended permit ip any vpc_subnet subnet_mask local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (vpc_subnet/subnet_mask/0/0) current_peer: integ-ppe1 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 172.25.50.101, remote crypto endpt.: AWS_ENDPOINT_1 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 6D9F8D3B current inbound spi : 48B456A6 inbound esp sas: spi: 0x48B456A6 (1219778214) transform: esp-aes esp-sha-hmac no compression in use settings ={L2L, Tunnel, PFS Group 2, } slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1 sa timing: remaining key lifetime (kB/sec): (4374000/3593) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001 outbound esp sas: spi: 0x6D9F8D3B (1839172923) transform: esp-aes esp-sha-hmac no compression in use settings ={L2L, Tunnel, PFS Group 2, } slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1 sa timing: remaining key lifetime (kB/sec): (4374000/3593) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001 ``` For each tunnel interface, you should see both `inbound esp sas` and `outbound esp sas`. This assumes that an SA is listed (for example, `spi: 0x48B456A6`), and that IPsec is configured correctly. In Cisco ASA, the IPsec only comes up after interesting traffic (traffic that should be encrypted) is sent. To always keep the IPsec active, we recommend configuring an SLA monitor. The SLA monitor continues to send interesting traffic, keeping the IPsec active. You can also use the following ping command to force your IPsec to start negotiation and go up. ``` ping ec2_instance_ip_address ``` ``` Pinging ec2_instance_ip_address with 32 bytes of data: Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128 Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128 Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128 Ping statistics for 10.0.0.4: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss), Approximate round trip times in milliseconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ``` For further troubleshooting, use the following command to enable debugging. ``` router# debug crypto ipsec ``` To disable debugging, use the following command. ``` router# no debug crypto ipsec ``` ## Routing Ping the other end of the tunnel. If this is working, then your IPsec should be established. If this is not working, check your access lists, and refer to the previous IPsec section. If you are not able to reach your instances, check the following information. 1. Verify that the access list is configured to allow traffic that is associated with the crypto map. You can do this using the following command. ``` ciscoasa# show run crypto ``` ``` crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac crypto map VPN_crypto_map_name 1 match address access-list-name crypto map VPN_crypto_map_name 1 set pfs crypto map VPN_crypto_map_name 1 set peer AWS_ENDPOINT_1 AWS_ENDPOINT_2 crypto map VPN_crypto_map_name 1 set transform-set transform-amzn crypto map VPN_crypto_map_name 1 set security-association lifetime seconds 3600 ``` 1. Check the access list using the following command. ``` ciscoasa# show run access-list access-list-name ``` ``` access-list access-list-name extended permit ip any vpc_subnet subnet_mask ``` 1. Verify that the access list is correct. The following example access list allows all internal traffic to the VPC subnet 10.0.0.0/16. ``` access-list access-list-name extended permit ip any 10.0.0.0 255.255.0.0 ``` 1. Run a traceroute from the Cisco ASA device, to see if it reaches the Amazon routers (for example, *AWS\$1ENDPOINT\$11*/*AWS\$1ENDPOINT\$12*). If this reaches the Amazon router, then check the static routes that you added in the Amazon VPC console, and also the security groups for the particular instances. 1. For further troubleshooting, review the configuration. ## Bounce the tunnel interface If the tunnel appears to be up but traffic isn't flowing properly, bouncing (disabling and re-enabling) the tunnel interface can often resolve connectivity issues. To bounce the tunnel interface on a Cisco ASA: 1. Run the following: ``` ciscoasa# conf t ciscoasa(config)# interface tunnel X (where X is your tunnel ID) ciscoasa(config-if)# shutdown ciscoasa(config-if)# no shutdown ciscoasa(config-if)# end ``` Alternately you can use a single-line command: ``` ciscoasa# conf t ; interface tunnel X ; shutdown ; no shutdown ; end ``` 1. After bouncing the interface, check if the VPN connection has been re-established and if traffic is now flowing correctly.. # Troubleshoot AWS Site-to-Site VPN connectivity with a Cisco IOS customer gateway device When you troubleshoot the connectivity of a Cisco customer gateway device, consider four things: IKE, IPsec, the tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up. ## IKE Use the following command. The response shows a customer gateway device with IKE configured correctly. ``` router# show crypto isakmp sa ``` ``` IPv4 Crypto ISAKMP SA dst src state conn-id slot status 192.168.37.160 72.21.209.193 QM_IDLE 2001 0 ACTIVE 192.168.37.160 72.21.209.225 QM_IDLE 2002 0 ACTIVE ``` You should see one or more lines containing an `src` value for the remote gateway that is specified in the tunnels. The `state` should be `QM_IDLE` and `status` should be `ACTIVE`. The absence of an entry, or any entry in another state, indicate that IKE is not configured properly. For further troubleshooting, run the following commands to enable log messages that provide diagnostic information. ``` router# term mon router# debug crypto isakmp ``` To disable debugging, use the following command. ``` router# no debug crypto isakmp ``` ## IPsec Use the following command. The response shows a customer gateway device with IPsec configured correctly. ``` router# show crypto ipsec sa ``` ``` interface: Tunnel1 Crypto map tag: Tunnel1-head-0, local addr 192.168.37.160 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.225 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149 #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.225 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xB8357C22(3090512930) inbound esp sas: spi: 0x6ADB173(112046451) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xB8357C22(3090512930) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: interface: Tunnel2 Crypto map tag: Tunnel2-head-0, local addr 174.78.144.73 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.193 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26 #pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.193 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xF59A3FF6(4120526838) inbound esp sas: spi: 0xB6720137(3060924727) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xF59A3FF6(4120526838) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: ``` For each tunnel interface, you should see both `inbound esp sas` and `outbound esp sas`. Assuming an SA is listed (`spi: 0xF95D2F3C`, for example) and the `Status` is `ACTIVE`, IPsec is configured correctly. For further troubleshooting, use the following command to enable debugging. ``` router# debug crypto ipsec ``` Use the following command to disable debugging. ``` router# no debug crypto ipsec ``` ## Tunnel First, check that you have the necessary firewall rules in place. For more information, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md). If your firewall rules are set up correctly, then continue troubleshooting with the following command. ``` router# show interfaces tun1 ``` ``` Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 169.254.255.2/30 MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 2/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 174.78.144.73, destination 72.21.209.225 Tunnel protocol/transport IPSEC/IP Tunnel TTL 255 Tunnel transport MTU 1427 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0") Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 407 packets input, 30010 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles ``` Make sure that the `line protocol` is up. Check that the tunnel source IP address, source interface, and destination respectively match the tunnel configuration for the customer gateway device outside IP address, interface, and virtual private gateway outside IP address. Make sure that `Tunnel protection via IPSec` is present. Run the command on both tunnel interfaces. To resolve any problems, review the configuration and check the physical connections to your customer gateway device. Also use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. ``` router# ping 169.254.255.1 df-bit size 1410 ``` ``` Type escape sequence to abort. Sending 5, 1410-byte ICMP Echos to 169.254.255.1, timeout is 2 seconds: Packet sent with the DF bit set !!!!! ``` You should see five exclamation points. For further troubleshooting, review the configuration. ## BGP Use the following command. ``` router# show ip bgp summary ``` ``` BGP router identifier 192.168.37.160, local AS number 65000 BGP table version is 8, main routing table version 8 2 network entries using 312 bytes of memory 2 path entries using 136 bytes of memory 3/1 BGP path/bestpath attribute entries using 444 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory BGP using 948 total bytes of memory BGP activity 4/1 prefixes, 4/1 paths, scan interval 15 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 169.254.255.1 4 7224 363 323 8 0 0 00:54:21 1 169.254.255.5 4 7224 364 323 8 0 0 00:00:24 1 ``` Both neighbors should be listed. For each, you should see a `State/PfxRcd` value of `1`. If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC. ``` router# show bgp all neighbors 169.254.255.1 advertised-routes ``` ``` For address family: IPv4 Unicast BGP table version is 3, local router ID is 174.78.144.73 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path *> 10.120.0.0/16 169.254.255.1 100 0 7224 i Total number of prefixes 1 ``` Additionally, ensure that you're receiving the prefix corresponding to your VPC from the virtual private gateway. ``` router# show ip route bgp ``` ``` 10.0.0.0/16 is subnetted, 1 subnets B 10.255.0.0 [20/0] via 169.254.255.1, 00:00:20 ``` For further troubleshooting, review the configuration. # Troubleshoot AWS Site-to-Site VPN connectivity with a Cisco IOS customer gateway device without Border Gateway Protocol When you troubleshoot the connectivity of a Cisco customer gateway device, consider three things: IKE, IPsec, and tunnel. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up. ## IKE Use the following command. The response shows a customer gateway device with IKE configured correctly. ``` router# show crypto isakmp sa ``` ``` IPv4 Crypto ISAKMP SA dst src state conn-id slot status 174.78.144.73 205.251.233.121 QM_IDLE 2001 0 ACTIVE 174.78.144.73 205.251.233.122 QM_IDLE 2002 0 ACTIVE ``` You should see one or more lines containing an `src` value for the remote gateway that is specified in the tunnels. The `state` should be `QM_IDLE` and `status` should be `ACTIVE`. The absence of an entry, or any entry in another state, indicates that IKE is not configured properly. For further troubleshooting, run the following commands to enable log messages that provide diagnostic information. ``` router# term mon router# debug crypto isakmp ``` To disable debugging, use the following command. ``` router# no debug crypto isakmp ``` ## IPsec Use the following command. The response shows a customer gateway device with IPsec configured correctly. ``` router# show crypto ipsec sa ``` ``` interface: Tunnel1 Crypto map tag: Tunnel1-head-0, local addr 174.78.144.73 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.225 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149 #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.121 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xB8357C22(3090512930) inbound esp sas: spi: 0x6ADB173(112046451) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xB8357C22(3090512930) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0 sa timing: remaining key lifetime (k/sec): (4467148/3189) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: interface: Tunnel2 Crypto map tag: Tunnel2-head-0, local addr 205.251.233.122 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 72.21.209.193 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26 #pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.122 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0 current outbound spi: 0xF59A3FF6(4120526838) inbound esp sas: spi: 0xB6720137(3060924727) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xF59A3FF6(4120526838) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0 sa timing: remaining key lifetime (k/sec): (4387273/3492) IV size: 16 bytes replay detection support: Y replay window size: 128 Status: ACTIVE outbound ah sas: outbound pcp sas: ``` For each tunnel interface, you should see both an inbound `esp sas` and outbound `esp sas`. This assumes that an SA is listed (for example, `spi: 0x48B456A6`), that the status is `ACTIVE`, and that IPsec is configured correctly. For further troubleshooting, use the following command to enable debugging. ``` router# debug crypto ipsec ``` To disable debugging, use the following command. ``` router# no debug crypto ipsec ``` ## Tunnel First, check that you have the necessary firewall rules in place. For more information, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md). If your firewall rules are set up correctly, then continue troubleshooting with the following command. ``` router# show interfaces tun1 ``` ``` Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 169.254.249.18/30 MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 2/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 174.78.144.73, destination 205.251.233.121 Tunnel protocol/transport IPSEC/IP Tunnel TTL 255 Tunnel transport MTU 1427 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0") Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 407 packets input, 30010 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles ``` Make sure that the line protocol is up. Check that the tunnel source IP address, source interface, and destination respectively match the tunnel configuration for the customer gateway device outside IP address, interface, and virtual private gateway outside IP address. Make sure that `Tunnel protection through IPSec` is present. Run the command on both tunnel interfaces. To resolve any problems, review the configuration and check the physical connections to your customer gateway device. You can also use the following command, replacing `169.254.249.18` with the inside IP address of your virtual private gateway. ``` router# ping 169.254.249.18 df-bit size 1410 ``` ``` Type escape sequence to abort. Sending 5, 1410-byte ICMP Echos to 169.254.249.18, timeout is 2 seconds: Packet sent with the DF bit set !!!!! ``` You should see five exclamation points. ### Routing To see your static route table, use the following command. ``` router# sh ip route static ``` ``` 1.0.0.0/8 is variably subnetted S 10.0.0.0/16 is directly connected, Tunnel1 is directly connected, Tunnel2 ``` You should see that the static route for the VPC CIDR through both tunnels exists. If it does not exist, add the static routes as follows. ``` router# ip route 10.0.0.0 255.255.0.0 Tunnel1 track 100 router# ip route 10.0.0.0 255.255.0.0 Tunnel2 track 200 ``` ### Checking the SLA monitor ``` router# show ip sla statistics 100 ``` ``` IPSLAs Latest Operation Statistics IPSLA operation id: 100 Latest RTT: 128 milliseconds Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012 Latest operation return code: OK Number of successes: 3 Number of failures: 0 Operation time to live: Forever ``` ``` router# show ip sla statistics 200 ``` ``` IPSLAs Latest Operation Statistics IPSLA operation id: 200 Latest RTT: 128 milliseconds Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012 Latest operation return code: OK Number of successes: 3 Number of failures: 0 Operation time to live: Forever ``` The value for `Number of successes` indicates whether the SLA monitor has been set up successfully. For further troubleshooting, review the configuration. # Troubleshoot AWS Site-to-Site VPN connectivity with a Juniper JunOS customer gateway device When you troubleshoot the connectivity of a Juniper customer gateway device, consider four things: IKE, IPsec, tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up. ## IKE Use the following command. The response shows a customer gateway device with IKE configured correctly. ``` user@router> show security ike security-associations ``` ``` Index Remote Address State Initiator cookie Responder cookie Mode 4 72.21.209.225 UP c4cd953602568b74 0d6d194993328b02 Main 3 72.21.209.193 UP b8c8fb7dc68d9173 ca7cb0abaedeb4bb Main ``` You should see one or more lines containing a remote address of the remote gateway specified in the tunnels. The `State` should be `UP`. The absence of an entry, or any entry in another state (such as `DOWN`), is an indication that IKE is not configured properly. For further troubleshooting, enable the IKE trace options as recommended in the example configuration file. Then run the following command to print a variety of debugging messages to the screen. ``` user@router> monitor start kmd ``` From an external host, you can retrieve the entire log file with the following command. ``` scp username@router.hostname:/var/log/kmd ``` ## IPsec Use the following command. The response shows a customer gateway device with IPsec configured correctly. ``` user@router> show security ipsec security-associations ``` ``` Total active tunnels: 2 ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys <131073 72.21.209.225 500 ESP:aes-128/sha1 df27aae4 326/ unlim - 0 >131073 72.21.209.225 500 ESP:aes-128/sha1 5de29aa1 326/ unlim - 0 <131074 72.21.209.193 500 ESP:aes-128/sha1 dd16c453 300/ unlim - 0 >131074 72.21.209.193 500 ESP:aes-128/sha1 c1e0eb29 300/ unlim - 0 ``` Specifically, you should see at least two lines per gateway address (corresponding to the remote gateway). The carets at the beginning of each line (< >) indicate the direction of traffic for the particular entry. The output has separate lines for inbound traffic ("<", traffic from the virtual private gateway to this customer gateway device) and outbound traffic (">"). For further troubleshooting, enable the IKE traceoptions (for more information, see the preceding section about IKE). ## Tunnel First, double-check that you have the necessary firewall rules in place. For a list of rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md). If your firewall rules are set up correctly, then continue troubleshooting with the following command. ``` user@router> show interfaces st0.1 ``` ``` Logical interface st0.1 (Index 70) (SNMP ifIndex 126) Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel Input packets : 8719 Output packets: 41841 Security: Zone: Trust Allowed host-inbound traffic : bgp ping ssh traceroute Protocol inet, MTU: 9192 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 169.254.255.0/30, Local: 169.254.255.2 ``` Make sure that the `Security: Zone` is correct, and that the `Local` address matches the customer gateway device tunnel inside address. Next, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. Your results should look like the response shown here. ``` user@router> ping 169.254.255.1 size 1382 do-not-fragment ``` ``` PING 169.254.255.1 (169.254.255.1): 1410 data bytes 64 bytes from 169.254.255.1: icmp_seq=0 ttl=64 time=71.080 ms 64 bytes from 169.254.255.1: icmp_seq=1 ttl=64 time=70.585 ms ``` For further troubleshooting, review the configuration. ## BGP Run the following command. ``` user@router> show bgp summary ``` ``` Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 169.254.255.1 7224 9 10 0 0 1:00 1/1/1/0 0/0/0/0 169.254.255.5 7224 8 9 0 0 56 0/1/1/0 0/0/0/0 ``` For further troubleshooting, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. ``` user@router> show bgp neighbor 169.254.255.1 ``` ``` Peer: 169.254.255.1+179 AS 7224 Local: 169.254.255.2+57175 AS 65000 Type: External State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ EXPORT-DEFAULT ] Options: Holdtime: 30 Preference: 170 Local AS: 65000 Local System AS: 0 Number of flaps: 0 Peer ID: 169.254.255.1 Local ID: 10.50.0.10 Active Holdtime: 30 Keepalive Interval: 10 Peer index: 0 BFD: disabled, down Local Interface: st0.1 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 7224) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 1 Last traffic (seconds): Received 4 Sent 8 Checked 4 Input messages: Total 24 Updates 2 Refreshes 0 Octets 505 Output messages: Total 26 Updates 1 Refreshes 0 Octets 582 Output Queue[0]: 0 ``` Here you should see `Received prefixes` and `Advertised prefixes` listed at 1 each. This should be within the `Table inet.0` section. If the `State` is not `Established`, check the `Last State` and `Last Error` for details of what is required to correct the problem. If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC. ``` user@router> show route advertising-protocol bgp 169.254.255.1 ``` ``` inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 Self I ``` Additionally, make sure that you're receiving the prefix that corresponds to your VPC from the virtual private gateway. ``` user@router> show route receive-protocol bgp 169.254.255.1 ``` ``` inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.110.0.0/16 169.254.255.1 100 7224 I ``` # Troubleshoot AWS Site-to-Site VPN connectivity with a Juniper ScreenOS customer gateway device When you troubleshoot the connectivity of a Juniper ScreenOS-based customer gateway device, consider four things: IKE, IPsec, tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up. ## IKE and IPsec Use the following command. The response shows a customer gateway device with IKE configured correctly. ``` ssg5-serial-> get sa ``` ``` total configured sa: 2 HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys 00000002< 72.21.209.225 500 esp:a128/sha1 80041ca4 3385 unlim A/- -1 0 00000002> 72.21.209.225 500 esp:a128/sha1 8cdd274a 3385 unlim A/- -1 0 00000001< 72.21.209.193 500 esp:a128/sha1 ecf0bec7 3580 unlim A/- -1 0 00000001> 72.21.209.193 500 esp:a128/sha1 14bf7894 3580 unlim A/- -1 0 ``` You should see one or more lines containing a remote address of the remote gateway that is specified in the tunnels. The `Sta` value should be `A/-` and `SPI` should be a hexadecimal number other than `00000000`. Entries in other states indicate that IKE is not configured properly. For further troubleshooting, enable the IKE trace options (as recommended in the example configuration file). ## Tunnel First, double-check that you have the necessary firewall rules in place. For a list of rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md). If your firewall rules are set up correctly, then continue troubleshooting with the following command. ``` ssg5-serial-> get interface tunnel.1 ``` ``` Interface tunnel.1: description tunnel.1 number 20, if_info 1768, if_index 1, mode route link ready vsys Root, zone Trust, vr trust-vr admin mtu 1500, operating mtu 1500, default mtu 1500 *ip 169.254.255.2/30 *manage ip 169.254.255.2 route-deny disable bound vpn: IPSEC-1 Next-Hop Tunnel Binding table Flag Status Next-Hop(IP) tunnel-id VPN pmtu-v4 disabled ping disabled, telnet disabled, SSH disabled, SNMP disabled web disabled, ident-reset disabled, SSL disabled OSPF disabled BGP enabled RIP disabled RIPng disabled mtrace disabled PIM: not configured IGMP not configured NHRP disabled bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps] configured ingress mbw 0kbps, current bw 0kbps total allocated gbw 0kbps ``` Make sure that you see `link:ready`, and that the `IP` address matches the customer gateway device tunnel inside address. Next, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. Your results should look like the response shown here. ``` ssg5-serial-> ping 169.254.255.1 ``` ``` Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 169.254.255.1, timeout is 1 seconds !!!!! Success Rate is 100 percent (5/5), round-trip time min/avg/max=32/32/33 ms ``` For further troubleshooting, review the configuration. ## BGP Run the following command. ``` ssg5-serial-> get vrouter trust-vr protocol bgp neighbor ``` ``` Peer AS Remote IP Local IP Wt Status State ConnID Up/Down -------------------------------------------------------------------------------- 7224 169.254.255.1 169.254.255.2 100 Enabled ESTABLISH 10 00:01:01 7224 169.254.255.5 169.254.255.6 100 Enabled ESTABLISH 11 00:00:59 ``` The state of both BGP peers should be `ESTABLISH`, which means that the BGP connection to the virtual private gateway is active. For further troubleshooting, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. ``` ssg5-serial-> get vr trust-vr prot bgp neigh 169.254.255.1 ``` ``` peer: 169.254.255.1, remote AS: 7224, admin status: enable type: EBGP, multihop: 0(disable), MED: node default(0) connection state: ESTABLISH, connection id: 18 retry interval: node default(120s), cur retry time 15s configured hold time: node default(90s), configured keepalive: node default(30s) configured adv-interval: default(30s) designated local IP: n/a local IP address/port: 169.254.255.2/13946, remote IP address/port: 169.254.255.1/179 router ID of peer: 169.254.255.1, remote AS: 7224 negotiated hold time: 30s, negotiated keepalive interval: 10s route map in name: , route map out name: weight: 100 (default) self as next hop: disable send default route to peer: disable ignore default route from peer: disable send community path attribute: no reflector client: no Neighbor Capabilities: Route refresh: advertised and received Address family IPv4 Unicast: advertised and received force reconnect is disable total messages to peer: 106, from peer: 106 update messages to peer: 6, from peer: 4 Tx queue length 0, Tx queue HWM: 1 route-refresh messages to peer: 0, from peer: 0 last reset 00:05:33 ago, due to BGP send Notification(Hold Timer Expired)(code 4 : subcode 0) number of total successful connections: 4 connected: 2 minutes 6 seconds Elapsed time since last update: 2 minutes 6 seconds ``` If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC. This command applies to ScreenOS version 6.2.0 and higher. ``` ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 advertised ``` ``` i: IBGP route, e: EBGP route, >: best route, *: valid route Prefix Nexthop Wt Pref Med Orig AS-Path -------------------------------------------------------------------------------------- >i 0.0.0.0/0 0.0.0.0 32768 100 0 IGP Total IPv4 routes advertised: 1 ``` Additionally, ensure that you're receiving the prefix that corresponds to your VPC from the virtual private gateway. This command applies to ScreenOS version 6.2.0 and higher. ``` ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 received ``` ``` i: IBGP route, e: EBGP route, >: best route, *: valid route Prefix Nexthop Wt Pref Med Orig AS-Path -------------------------------------------------------------------------------------- >e* 10.0.0.0/16 169.254.255.1 100 100 100 IGP 7224 Total IPv4 routes received: 1 ``` # Troubleshoot AWS Site-to-Site VPN connectivity with a Yamaha customer gateway device When you troubleshoot the connectivity of a Yamaha customer gateway device, consider four things: IKE, IPsec, tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up. **Note** The `proxy ID` setting used in phase 2 of IKE is disabled by default on the Yamaha router. This can cause problems connecting to Site-to-Site VPN. If the `proxy ID` is not configured on your router, please see the AWS-provided example configuration file for Yamaha to set properly. ## IKE Run the following command. The response shows a customer gateway device with IKE configured correctly. ``` # show ipsec sa gateway 1 ``` ``` sgw flags local-id remote-id # of sa -------------------------------------------------------------------------- 1 U K YOUR_LOCAL_NETWORK_ADDRESS 72.21.209.225 i:2 s:1 r:1 ``` You should see a line containing a `remote-id` value for the remote gateway that is specified in the tunnels. You can list all of the security associations (SAs) by omitting the tunnel number. For further troubleshooting, run the following commands to enable DEBUG level log messages that provide diagnostic information. ``` # syslog debug on # ipsec ike log message-info payload-info key-info ``` To cancel the logged items, run the following command. ``` # no ipsec ike log # no syslog debug on ``` ## IPsec Run the following command. The response shows a customer gateway device with IPsec configured correctly. ``` # show ipsec sa gateway 1 detail ``` ``` SA[1] Duration: 10675s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Protocol: IKE Algorithm: AES-CBC, SHA-1, MODP 1024bit SPI: 6b ce fd 8a d5 30 9b 02 0c f3 87 52 4a 87 6e 77 Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- SA[2] Duration: 1719s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Direction: send Protocol: ESP (Mode: tunnel) Algorithm: AES-CBC (for Auth.: HMAC-SHA) SPI: a6 67 47 47 Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- SA[3] Duration: 1719s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Direction: receive Protocol: ESP (Mode: tunnel) Algorithm: AES-CBC (for Auth.: HMAC-SHA) SPI: 6b 98 69 2b Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- SA[4] Duration: 10681s Local ID: YOUR_LOCAL_NETWORK_ADDRESS Remote ID: 72.21.209.225 Protocol: IKE Algorithm: AES-CBC, SHA-1, MODP 1024bit SPI: e8 45 55 38 90 45 3f 67 a8 74 ca 71 ba bb 75 ee Key: ** ** ** ** ** (confidential) ** ** ** ** ** ---------------------------------------------------- ``` For each tunnel interface, you should see both `receive sas` and `send sas`. For further troubleshooting, use the following command to enable debugging. ``` # syslog debug on # ipsec ike log message-info payload-info key-info ``` Run the following command to disable debugging. ``` # no ipsec ike log # no syslog debug on ``` ## Tunnel First, check that you have the necessary firewall rules in place. For a list of rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md). If your firewall rules are set up correctly, then continue troubleshooting with the following command. ``` # show status tunnel 1 ``` ``` TUNNEL[1]: Description: Interface type: IPsec Current status is Online. from 2011/08/15 18:19:45. 5 hours 7 minutes 58 seconds connection. Received: (IPv4) 3933 packets [244941 octets] (IPv6) 0 packet [0 octet] Transmitted: (IPv4) 3933 packets [241407 octets] (IPv6) 0 packet [0 octet] ``` Make sure that the `current status` value is online and that `Interface type` is IPsec. Make sure to run the command on both tunnel interfaces. To resolve any problems here, review the configuration. ## BGP Run the following command. ``` # show status bgp neighbor ``` ``` BGP neighbor is 169.254.255.1, remote AS 7224, local AS 65000, external link BGP version 0, remote router ID 0.0.0.0 BGP state = Active Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds Received 0 messages, 0 notifications, 0 in queue Sent 0 messages, 0 notifications, 0 in queue Connection established 0; dropped 0 Last reset never Local host: unspecified Foreign host: 169.254.255.1, Foreign port: 0 BGP neighbor is 169.254.255.5, remote AS 7224, local AS 65000, external link BGP version 0, remote router ID 0.0.0.0 BGP state = Active Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds Received 0 messages, 0 notifications, 0 in queue Sent 0 messages, 0 notifications, 0 in queue Connection established 0; dropped 0 Last reset never Local host: unspecified Foreign host: 169.254.255.5, Foreign port: ``` Both neighbors should be listed. For each, you should see a `BGP state` value of `Active`. If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC. ``` # show status bgp neighbor 169.254.255.1 advertised-routes ``` ``` Total routes: 1 *: valid route Network Next Hop Metric LocPrf Path * default 0.0.0.0 0 IGP ``` Additionally, ensure that you're receiving the prefix that corresponds to your VPC from the virtual private gateway. ``` # show ip route ``` ``` Destination Gateway Interface Kind Additional Info. default ***.***.***.*** LAN3(DHCP) static 10.0.0.0/16 169.254.255.1 TUNNEL[1] BGP path=10124 ``` # AWS Site-to-Site VPN and eero Integration AWS Site-to-Site VPN has collaborated with [eero](http://eero.com) to make it simple and convenient for organizations to establish secure connectivity between their remote sites and AWS in just a few clicks. This solution leverages eero’s WiFi access points and network gateways to provide local connectivity. Using eero’s gateway appliances and Site-to-Site VPN, customers can automatically establish VPN connectivity to access their applications hosted in AWS such as payment gateways for point of sales systems in just a few clicks. This makes it simple and faster for customers to scale their remote site connectivity across hundreds of sites and eliminates the need for an onsite technician with networking expertise to set-up the connectivity. This solution is suitable for distributed enterprises with up to 500 remote offices, with each office having up to 100 users. To learn more about this integration, including detailed set-up guide, check the [eero documentation](https://support.eero.com/hc/en-us/articles/42827838351899-AWS-Account-and-VPN-Configuration). **Note** There are no changes to the functionality of AWS Site-to-Site VPN as part of this integration. **Considerations:** + Available only for VPN connections attached to a Transit Gateway or to Cloud WAN. Not supported for Virtual Private Gateway attachments. + 5 Gbps tunnels are not supported. + Site-to-Site VPN Concentrator is not supported. + Site-to-Site VPN [quotas](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html) do not change with this integration.