Why can't I connect to my VPC when using an AWS Site-to-Site VPN that terminates on a transit gateway?

Resolution

• Confirm that the tunnels for the AWS Site-to-Site VPN connection are up on both the AWS end and on your customer gateway device. If the connection is DOWN, then follow the troubleshooting steps for IKE/phase 1 and IKE/phase 2 failures to establish the tunnel.

• Check that the encryption domain that's configured on the customer gateway device is broad enough to cover the local (on-premises) and remote (AWS) network CIDRs. Site-to-Site VPN is a route-based solution. This means that the local and remote network CIDRs are set to any/any (0.0.0.0/0 <==> 0.0.0.0/0) on the AWS side, by default. But if you're using a policy-based Site-to-Site VPN on the customer gateway side, then use a specific encryption domain to cover the intended traffic.

  Note: AWS limits the number of security associations (SAs) to a single pair for both inbound and outbound SAs. If you're using policy-based Site-to-Site VPN and have multiple networks that are accessed through the Site-to-Site VPN tunnel, then the encryption domain must be summarized. If the encryption domain isn't summarized, then the customer gateway proposes multiple SAs, which can result in connectivity failure.

• Confirm if your customer gateway is behind a NAT device. If not, then make sure that ESP - IP protocol 50 is allowed to and from the Site-to-Site VPN endpoint to the customer gateway. If the customer gateway is behind a NAT device, then check if NAT-T is turned on. If NAT-T is turned on, then make sure that UDP port 4500 is allowed on the NAT device and the customer gateway device. This is a requirement for ESP traffic to flow.

• If you're using accelerated Site-to-Site VPN, then make sure that NAT-T is turned on on the customer gateway side.

• Check if the firewall policy on the customer gateway device allows outbound traffic from the on-premises network to AWS. Then check that the policy allows inbound traffic from AWS to the on-premises network.

• For static Site-to-Site VPN, define a static route for the on-premises network CIDRs on the transit gateway route table that's associated with the source VPC attachment.

• For dynamic Site-to-Site VPN, make sure that the customer gateway device is advertising the on-premises routes to the Site-to-Site VPN endpoints. Then, make sure that the customer gateway device is receiving the routes for the VPC CIDRs from the Site-to-Site VPN endpoints. Check that the device's route table has a route for the VPC CIDR that points to the virtual tunnel interface for the AWS peer.



• On the TGW route table that's associated with the source VPC attachment, you can turn on propagation from the Site-to-Site VPN attachment. The on-premises routes are then added automatically to the TGW route table associated with the source VPC attachment.

• For static Site-to-Site VPN, you might be using a route based VPN implementation. For this setup, check that the customer gateway device has a static route for the AWS network that points to the virtual tunnel interface. Or, if you're using policy-based VPN implementation, then make sure that you have a policy in place that matches the on-premises network and AWS network.

• For static Site-to-Site VPN, verify that the 2 tunnels on AWS have an active/active setup, meaning that both tunnels are up. Make sure that asymmetric routing is supported on your customer gateway device. If asymmetric routing isn't supported, then AWS randomly selects the egress tunnel.

• For dynamic Site-to-Site VPN, check if VPN ECMP Support is activated on the transit gateway. Then check if you have an active/active setup, where the customer gateway advertises the same prefixes and BGP attributes. If you have an active/active setup and VPN ECMP Support is activated, then AWS load balances traffic across both tunnels. For this reason, asymmetric routing must be supported and activated on the customer gateway device. If VPN ECMP Support is turned off, then AWS randomly chooses an egress tunnel, resulting in asymmetric routing.

• Check the routing on the VPC route tables. Virtual private gateways allow you to turn route propagation on to automatically propagate the Site-to-Site VPN routes to the VPC route tables. But when using a transit gateway, you must define a static route for the on-premises CIDRs that point to your transit gateway.

• Verify that the transit gateway VPC attachment has a subnet associated with it. This subnet must cover the Availability Zone (AZ) that your destination resource resides in within the VPC.

• Verify that traffic is allowed on the security group that's associated with the target instance or resource.

• Verify that the network access control list (network ACL) allows inbound and outbound traffic.

  Note: Network ACL rules are applied in different ways. This depends on whether the instances and transit gateway VPC attachment elastic network interface reside in the same subnet or in different subnets.

• Check if the target host's OS level firewall allows both inbound and outbound traffic.

• Check if the application that's running on the target server is listening on the specified port and protocol. Run the following commands:

  Windows PowerShell or Command prompt:

  netstat -a

  Linux terminal:

  netstat -plantu

Related information

Configure a Site-to-Site VPN connection to prefer tunnel A over tunnel B

Monitoring VPN tunnels using Amazon CloudWatch