Why is my AWS Site-to-Site VPN connection in the DOWN IPSEC UP status when the customer gateway is UP?
4 minute read
The customer gateway that's configured for my AWS Site-to-Site VPN is UP but the Site-to-Site VPN console shows that my connection is DOWN.
The Site-to-Site VPN console might show that the status of your connection is IPSEC UP but the tunnel status is DOWN. This means that Internet Protocol security (IPsec) been is established, but Border Gateway Protocol (BGP) isn't established. For a dynamic Site-to-Site VPN connection to show as UP on the AWS side, both IPSEC and BGP must be successfully established.
Confirm that the customer gateway supports BGP
Confirm that your customer gateway supports and is configured with BGP.
Confirm if the on-premises side of your connection uses dynamic (BGP) or static (policy-based Site-to-Site VPN or static route-based Site-to-Site VPN). If the on-premises side is using static routing, then you must re-create the Site-to-Site VPN on the AWS end.
When you create a Site-to-Site VPN connection using AWS, the dynamic routing option is selected, by default. If you create a Site-to-Site VPN connection without choosing static routing, then a dynamic Site-to-Site VPN is created. You can't modify the routing option for an existing Site-to-Site VPN connection, so you must create a new Site-to-Site VPN to use static routing.
When you delete a Site-to-Site VPN connection and create a new connection, then a new pair of public IP addresses is assigned to the tunnels. You must reconfigure the customer gateway device and update the public peer IPs, accordingly. But when you create a new connection, you can use the tunnel inside IPs and pre-shared secret key from your previous Site-to-Site VPN connection. You don't need to use the details that AWS auto-generates.
Verify the encryption domain and proxy IDs
Confirm if the encryption domain or proxy ID that's configured on both AWS and on your customer gateway device is 0.0.0.0/0 = 0.0.0.0/0.
On the AWS end, check the local IPV4 network CIDR (on-premises CIDR) and remote IPv4 network CIDR (AWS CIDR).
On the customer gateway, follow the guidelines provided by the vendor to check the encryption domain and proxy ID.
If you have turned on Site-to-Site VPN logs for your connection, then review the Amazon CloudWatch log group that contains your Site-to-Site VPN logs. Choose the log stream for the associated Site-to-Site VPN endpoint. Then, choose AWS tunnel Phase 2 SA is established with SPI** to filter the log streams. You can now view the traffic selector negotiated by the customer gateway, assuming the AWS side is the default of 0.0.0.0/0 = 0.0.0.0/0.
The log steam is in a format similar to vpn-id-VPN_Peer_IP-IKE.log. See the following example output:
"details": "AWS tunnel Phase 2 SA is established with
inbound SPI: 0xcbf7f2e3: outbound SPI: 0xc9be76cd: traffic selectors:
(AWS-side) 172.31.0.0/16 <=> (CGW-side) 10.0.0.0/16",
Note: If you're using a dynamic Site-to-Site VPN connection, then the traffic selector must be broad enough to cover all traffic. This includes APIPA IP addresses that are used for BGP peers. In the previous example, you update the encryption domain on your customer gateway device to 0.0.0.0/0 (AWS) <==> **0.0.0.0/**0 (on-premises).
You might have a Site-to-Site VPN that terminates on a transit gateway, with acceleration turned on. With this setup, make sure that NAT-T is activated on the customer gateway device.
Note: NAT-T must be turned on for accelerated Site-to-Site VPN. If NAT-T isn't activated on the customer gateway device, then IPsec is established but no traffic flows over the Site-to-Site VPN connection. This includes BGP traffic. For more information, see the Rules and restrictions for accelerated Site-to-Site VPN.