How can I resolve asymmetric routing issues when I create a VPN as a backup to Direct Connect in a transit gateway?

Last updated: 2021-12-02

Using a VPN connection as a backup to Direct Connect can result in asymmetric routing issues. Asymmetric routing occurs when network traffic enters through one connection and exits through another connection. Some network devices such as firewalls drop packets if the traffic received isn't logged in your stateful table.

Follow these best practices for configuring outbound and inbound network traffic.

• Configure the VPN with dynamic routing using Border Gateway Protocol (BGP).
• Make sure your devices advertise the same prefixes from on-premises to AWS with the VPN and Direct Connect, or less specific VPN prefixes. For example, 10.0.0.0/16 is less specific compared to 10.0.0.0/24.
• AWS sets a higher preference value for Direct Connect over the VPN connection when sending on-premises traffic to your network if the prefix length received is the same value.
• For the AWS Transit Gateway, a static route pointing to a VPN attachment is more preferred to a dynamically propagated Direct Connect gateway route if the prefix length is the same value.
• For Direct Connect deployed with dynamic VPN as backup, AS PATH prepending isn't recommended. This is because if the prefixes are the same, Direct Connect routes are preferred regardless of the AS PATH prepend length.

For more information, see Route tables and VPN priority.

• Make sure that your network device is configured to prefer sending return traffic through the Direct Connect connection.
• If the prefixes advertised from AWS to your network device are the same for Direct Connect and VPN, then the BGP local preference attribute can be used to force your device to send outbound traffic through the Direct Connect connection towards AWS. Set the Direct Connect path with a higher local preference value and a lower preference for VPN. For example, Local preference 200 for Direct Connect and 100 for VPN.

Important:

If the Direct Connect allowed prefix is summarized and routes advertised through VPN are more specific, then your network devices prefer the routes received through VPN.

For example:

• The transit gateway propagated routes are VPC-A CIDR 10.0.0.0/16, VPC-B CIDR 10.1.0.0/16, and VPC-C 10.2.0.0/16.
• The summarized prefix on the Direct Connect gateway allowed prefixes is 10.0.0.0/14 in order to accommodate the 20 prefixes limit.

Direct Connect advertises the Direct Connect gateway prefix 10.0.0.0/14, and the VPN transit gateway advertises the /16 CIDRs for each VPC over VPN.

To resolve this issue, insert the summarized Direct Connect gateway route into the transit gateway route table. For example, add a static route 10.0.0.0/14 pointing to a VPC attachment. This makes sure that the transit gateway advertises the summarized network over VPN. Your network devices receive the same prefix from Direct Connect and VPN. Then, configure your gateway to filter out the specific prefixes received to make sure that only the summarized prefix is installed in the routing table from the VPN peer. There are different options available to filter out routes depending on the vendor specifications. For example, route-maps, prefix-lists, router-filter-lists, and so on.

Traffic from your network to AWS reaches the transit gateway route table and the gateway does a lookup to select the most specific routes from each VPC attachment. For example:

Attachment A pointing to VPC-A CIDR is 10.0.0.0/16.

Attachment B pointing to VPC-B CIDR is 10.1.0.0/16.

Attachment C pointing to VPC-C CIDR is 10.2.0.0/16.