How do I avoid asymmetry in route-based VPN with static routing?

Short description

AWS Site-to-Site VPN provides two endpoints per VPN connection to reach the same destination network. AWS uses either one of the active tunnels to route traffic to the same destination.

VPN tunnels are usually hosted on "stateful" firewalls. The firewall devices expect a packet to use the same tunnel interface to send and receive traffic. Asymmetric routing occurs when the packet enters Amazon Virtual Private Cloud (Amazon VPC) through one tunnel and exits through the other tunnel on the same Site-to-Site VPN. When the packet returns through another tunnel interface, it doesn't match the "stateful" session and therefore gets dropped.

Resolution

You don’t need to create a new VPN with dynamic routing to address the problem of asymmetric routing. Instead, continue to use static routing after you’ve made changes to reflect the dynamic routing logic, as shown below.

Prerequisite

Confirm that you have asymmetric routing by checking the Amazon CloudWatch metrics:

View metrics for each tunnel

If you have only one VPN connection with Active/Active configuration:

1. Open the CloudWatch console.
2. In the navigation pane, choose Metrics.
3. Under All metrics, choose the VPN metric namespace.
4. Select VPN Tunnel Metrics.
5. Select the CloudWatch metrics TunnelDataIn and TunnelDataOut. If there's asymmetric routing, one tunnel has data points for the metric TunnelDataIn. The second tunnel has data points for the metric TunnelDataOut.

View metrics for the whole VPN connection (aggregate metrics)

If you have multiple VPN connections:

1. Open the CloudWatch console.
2. In the navigation pane, choose Metrics.
3. Under All metrics, choose the VPN metric namespace.
4. Select VPN Connection Metrics.
5. Select the CloudWatch metrics TunnelDataIn and TunnelDataOut. If there's asymmetric routing, one connection has data points for the metric TunnelDataIn. The other connection has data points for the metric TunnelDataOut.

For more information on tunnel metrics, see Monitoring VPN tunnels using CloudWatch.

Asymmetric routing scenarios

Review the following options to avoid asymmetric routing in these scenarios:

A single VPN connection configured as Active/Active

To avoid asymmetric routing:

• Use the IPsec aggregate feature if the customer gateway supports it. For more information, see IPsec aggregate for redundancy and tunnel load-balancing on the Fortinet website.
• If the customer gateway supports asymmetric routing, then make sure that asymmetric routing is turned on, on the virtual tunnel interfaces.
• If customer gateway doesn't support asymmetric routing, then make sure that the VPN setting is Active/Passive. This configuration identifies one tunnel as UP and the second tunnel as DOWN. In this setting, traffic from AWS to the on-premises network traverses only through the tunnel in the UP state. For more information, see How do I configure my Site-to-Site VPN to prefer tunnel A over tunnel B?

Two VPN connections (VPN-Pry and VPN-Sec) connect to the same VPC

In this scenario, VPN connections connect to the same Amazon VPC, using the same virtual private gateway.

Note: This scenario applies only to VPN connections with the virtual private gateway.

Both connections:

• Use static routing
• Advertise the same on-premises prefixes. For example, 10.170.0.0/20 and 10.167.0.0/20
• Connect to the same VPC through the virtual private gateway
• Have different customer gateway public IPs

Implement the following to avoid asymmetric routing:

Static routes for VPN-Pry (primary connection):

10.170.0.0/21

10.170.8.0/21

10.167.0.0/21

10.167.8.0/21

Static routes for VPN-Sec (secondary connection):

10.170.0.0/20

10.167.0.0/20

In these settings, AWS chooses VPN-Pry as the preferred connection over VPN-Sec. AWS uses the longest prefix match in your route table that matches the traffic to determine how to route the traffic.

Note: If your customer gateway doesn’t have asymmetric routing in this scenario, then configure each VPN setting as Active/Passive. Doing so identifies one tunnel as active per VPN connection. Traffic fails over to the active tunnel of the secondary connection if both tunnels of the active connection are down.

For more information on VPN route priority, see Route tables and VPN route priority.