AWS Site-to-Site VPN routes troubleshooting

In order for TGW to advertise a route via BPG, it needs to either receive that route via "Propagation" or by having a static route in the TGW Route Table. I suggest confirming if a "Route Propagation" exists on the Transit gateway route table.

Separately, while VWG is less expensive than TGW, keep in mind that a single VPN tunnel supports upto 1-1.25Gbps max. With VGW, only one tunnel is active on a VPN Connection at a time. With TGW, both tunnels are active and you can enable Equal Cost Multi-Pathing (ECMP). This doubles the throughput to 2-2.5GBps per VPN Connection. You could also add additional VPN Connections, in the future, if/when more bandwidth is needed. Since this is Cloud-to-Cloud connectivity, I suggest the flexibility to enable as much bandwidth as needed.

Does this help?

The VGW will only propagate routes to the VPN if they are contained within the CIDR ranges of the attached VPC. The static route to the WireGuard subnet references an external (outside the VPC CIDR) network and will not be propagated.

However, you can use the following procedure to advertise the WireGuard route across the tunnel. This is configuration is adapted from a middlebox routing scenario and modified to fit your use case.

First, define a new CIDR range on the VPC which includes the Wireguard subnet. For example, if the WireGuard subnet is 10.0.0.0/24, add a CIDR of 10.0.0.0/23. Note that there are some restrictions on what CIDRs can be added to a VPC depending on what the base CIDR is. Once you've added the new CIDR, it will be advertised across the VPN to GCP. Now, traffic from GCP destined for WireGuard will be forwarded across the VPN to AWS.

Next, we need a gateway route table to route inbound traffic from the VGW to the WireGuard instance. There are two requirements to accomplish this.

1. Create a new subnet in the VPC and configure it with the same addressing as the WireGuard subnet. Nothing will be deployed here, but the next step will fail if this subnet does not exist.

2. Create a new route table in the VPC. By default, this route table will contain local routes for all of the VPC CIDRs. Add a static route in this table for the WireGuard subnet with the next hop set to the ENI of the WireGuard instance. Then, in the route table configuration dialogue, go to the "edge associations" tab. Click "edit edge associations" and add an association for the VGW where the GCP tunnel is terminated.

Now traffic inbound from the VPN toward the WireGuard subnet will be routed to the WireGuard instance.

The last component of routing we need to add is a return route back to GCP. For this, edit the route table which is associated with the subnet where the WireGuard instance is deployed. Go to the "route propagation" tab. Click "edit route propagation" and check the box to enable propagation from the VGW. The GCP routes which were learned over the VPN will now propagate to the subnet route table completing the routing path.

I hope this helps.