Why can't I connect to VPC resources over a transit virtual interface using a Direct Connect connection?
Last updated: 2020-03-25
I'm unable to connect to Amazon Virtual Private Cloud (Amazon VPC) resources over a transit virtual interface using my AWS Direct Connect connection. How can I troubleshoot this connectivity issue?
Verify that you are advertising the correct on-premises network prefixes over the transit virtual interface
- Confirm that your on-premises Direct Connect border gateway protocol (BGP) router is advertising the correct on-premises prefixes towards the AWS Direct Connect BGP peer on the transit virtual interface.
- Review the advertised routes on your local BGP router. Your local BGP router must include the advertised route in the local routing information base (RIB). The commands for checking these routes vary based on the make/model of your on-premises BGP device. Refer to the documentation for your device for more details.
Note: You can advertise a maximum of 100 routes per BGP session on a transit virtual interface. This is a hard service quota that cannot be changed. Crossing this service quota causes the BGP session to go into an IDLE state.
Verify that you are advertising the correct Amazon VPC prefixes from the Direct Connect gateway to the on-premises network over the transit virtual interface
When associating a transit gateway with a Direct Connect gateway, use prefixes that can be advertised to the on-premises network through the Direct Connect gateway.
Note: You can specify any of the following, and AWS will advertise it back to the on-premises network:
- A subnet prefix of a virtual private computer (VPC), such as 10.1.0.0/24 in a 10.1.0.0/16 VPC
- An entire VPC prefix
- A supernet (for example, 10.0.0.0/8)
Review your transit gateway settings
- Transit virtual interfaces use Direct Connect gateway associations with transit gateways to facilitate communication. This communication goes from the on-premises network to multiple VPCs in all Regions and accounts over a single transit virtual interface. Be sure to follow the rules for transit gateway associations.
- Review your transit gateway routing configuration. You can configure route tables (custom or default) to propagate routes for any attached VPCs, virtual private networks (VPNs), or Direct Connect connections. You can also add static routes to the transit gateway route tables. When a packet comes from one attachment, it is routed to another attachment using the route table that matches the destination IP address.
Note: Each attachment (whether a VPC or a Direct Connect connection) can be associated with exactly one route table. However, an attachment can propagate its routes to one or more route tables.
- If you have a VPC attached to your transit gateway, confirm that you selected the appropriate amount of Availability Zones for the transit gateway to route traffic to resources in VPC subnets. The transit gateway creates a network interface in that subnet using one IP address from the subnet.
- For resources in different Availability Zones, confirm that the transit gateway elastic network interface (ENI) is present in that Availability Zone.
Important: Availability Zones that don't have a transit gateway attachment are unable to reach the transit gateway. If you can route traffic from one Availability Zone but are unable to do so in another, confirm that the transit gateway ENI is present in that zone. It's a best practice to enable transit gateway ENIs in multiple Availability Zones to ensure high availability.
Review your Amazon VPC settings
On your Amazon VPC, verify that:
- The security groups are whitelisted to allow inbound and outbound traffic to and from the advertised on-premises network prefixes.
- Network access control lists (ACLs) are correctly configured. You can create one network ACL and associate it with all of the subnets that are associated with the transit gateway. Keep the network ACL open in both the inbound and outbound directions.
- The subnet route table includes a route entry with Target set to the transit gateway ID and Destination set to the on-premises network prefix.
Verify that requests are sent and received over the desired Direct Connect connection
Note: These troubleshooting steps apply when you have:
- Redundant Direct Connect physical connections configured from the on-premises location
- One transit virtual interface configured per Direct Connect physical connection
- Similar on-premises prefixes advertised over both the transit virtual interfaces towards AWS
To confirm that the Active/Passive or Active/Active configuration for your redundant connections works as expected:
- Run a bidirectional traceroute. Review the Direct Connect BGP peer IP addresses to find which transit virtual interface is being used to send or receive traffic.
- Use local preference BGP community tags to achieve load balancing and/or route preference for incoming traffic to your network.
- If you’d rather use an Active/Passive configuration in the same Region, use local preference and AS-path prepending:
- Local preference: To influence outbound traffic from your on-premises data center over a certain Direct Connect link
- AS-path prepending: To influence inbound traffic back to your on-premises data center from AWS