Skip to content

Terraform GWLB NAT Gateway - Outbound Traffic from Private Subnet Fails/Hangs Despite Healthy Targets

0

Hello everyone,

I'm building a custom, highly-available NAT solution in AWS using a Gateway Load Balancer (GWLB) and an EC2 Auto Scaling Group for the NAT appliances. My goal is to provide outbound internet access for instances located in a private subnet.

The Problem: Everything appears to be configured correctly, yet outbound traffic from the private instance fails. Commands like curl google.com or ping 8.8.8.8 hang indefinitely and eventually time out.

Architecture Overview: The traffic flow is designed as follows: Private Instance (in Private Subnet) → Private Route Table → GWLB Endpoint → GWLB → NAT Instance (in Public Subnet) → Public Route Table → IGW → Internet

What I've Verified and Debugged:

  1. GWLB Target Group: The target group is correctly associated with the GWLB. All registered NAT instances are passing health checks and are in a Healthy state. I have at least one healthy target in each Availability Zone where my workload instance resides.
  2. NAT Instance Itself: I can SSH directly into the NAT appliance instances. From within the NAT instance, I can successfully run curl google.com. This confirms the instance itself has proper internet connectivity.
  3. NAT Instance Configuration: The user_data script runs successfully on boot. I have verified on the NAT instances that:
    • net.ipv4.ip_forward is set to 1.
    • The geneve0 virtual interface is created and is UP.
    • An iptables -t nat -A POSTROUTING -o <primary_interface> -j MASQUERADE rule exists and is active.
  4. Routing Tables: I believe my routing is configured correctly to handle both ingress and egress traffic symmetrically (Edge Routing).
    • Private Route Table (private-rt): Has a default route 0.0.0.0/0 pointing to the GWLB VPC Endpoint (vpce-...). This is associated with the private subnet.
    • Public Route Table (public-rt): Has two routes:
      1. 0.0.0.0/0 pointing to the Internet Gateway (igw-...).
      2. [private_subnet_cidr] (e.g., 10.20.0.0/24) pointing back to the GWLB VPC Endpoint (vpce-...) to handle the return traffic. This route table is associated with the subnets for the NAT appliances and the GWLB Endpoint.
  5. Security Groups & NACLs: Security Groups on the NAT appliance allow all traffic from within the VPC. I am using the default NACLs which allow all traffic.

Despite all of the above, the traffic from the private instance does not complete its round trip.

My Question: Given that the targets are healthy, the NAT instances themselves are functional, and the routing appears to be correct, what subtle configuration might I be missing? Is there a known issue or a specific way to further debug where the return traffic is being dropped?

the link of repo https://github.com/taha2samy/try

asked a year ago237 views

1 Answer
0

Based on your description, there are several potential issues that could be causing your outbound traffic failure from the private subnet:

  1. NAT Gateway Configuration: While your NAT instances appear to be properly configured with IP forwarding enabled and the appropriate iptables rules, there might be issues with how traffic is being processed through the GWLB. The NAT instances need to properly handle the GENEVE encapsulated traffic from the GWLB.

  2. Route Table Configuration: Although you've set up routes that appear correct, there might be subtle issues with the return traffic path. For symmetric routing with a GWLB, you need to ensure that:

  • The private subnet route table correctly sends traffic to the GWLB endpoint
  • The public subnet route table has both the default route to the IGW and a specific route for your private subnet CIDR back to the GWLB endpoint
  1. Security Group and NACL Configuration: Even though you're using default NACLs that allow all traffic, verify that:
  • Security groups for the NAT instances allow both inbound and outbound traffic
  • Security groups for the private instances allow outbound traffic
  • The GWLB endpoint security group allows traffic from your private subnet
  1. GWLB Endpoint Configuration: Ensure the GWLB endpoint is properly configured in the correct subnet and is in an "Available" state.

  2. TCP Connection Handling: If you're specifically having issues with TCP connections, check if there are any TCP connection handling issues on your NAT instances, such as fragmented TCP packets.

Troubleshooting steps:

  1. Enable VPC Flow Logs: This will help you see where traffic might be getting dropped or if it's reaching the intended destinations.

  2. Test with Different Protocols: Try both ICMP (ping) and TCP (curl) to see if the behavior differs, which might indicate protocol-specific issues.

  3. Check GWLB Health Checks: Verify that the health checks are properly configured to test the actual NAT functionality, not just instance reachability.

  4. Verify Source/Destination Check: Ensure that source/destination check is disabled on your NAT instances.

  5. Test Direct Routing: As a diagnostic step, try setting up a direct route from your private subnet to one of your NAT instances (bypassing the GWLB) to see if that works, which would help isolate whether the issue is with the NAT instances themselves or with the GWLB configuration.

  6. Check for MTU Issues: GWLB uses GENEVE encapsulation which can cause MTU issues. Ensure your NAT instances are properly handling the MTU for encapsulated traffic.

If all these checks pass, consider reviewing your Terraform code for any subtle configuration issues in how the GWLB, endpoints, and route tables are being created and associated.
Sources
Instances within the private subnet are unable to access the internet using NAT gateway. | AWS re:Post
Troubleshoot NAT gateways - Amazon Virtual Private Cloud
NLB Timeout Despite Healthy Targets & Verified Network Path (No VPC Flow Logs for NLB Traffic) | AWS re:Post
Troubleshoot EC2 instance internet access with a NAT gateway | AWS re:Post

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.