I'm hitting an SMTP egress problem that I've narrowed down to the NAT Gateway path specifically, and I'd appreciate help understanding why.
ENVIRONMENT (region eu-west-1)
- EKS workloads (pods + nodes) in private subnets that egress to the internet through a NAT Gateway.
- Several EC2 instances in public subnets that egress directly via the Internet Gateway using their own Elastic IPs.
SYMPTOM
Outbound TCP to SMTP submission ports 25, 465, and 587 is SILENTLY DROPPED from anything egressing via the NAT Gateway:
- SYN is sent, no SYN-ACK and no RST come back, the connection just hangs and times out.
- This happens to every external mail server I test (Gmail SMTP, Office 365 SMTP, and the regional Amazon SES SMTP endpoint).
- On the IDENTICAL path/host, port 2587 (SES alternate submission port) connects in well under a second, and general egress (HTTPS/443 to non-mail hosts) works fine.
- So only ports 25/465/587, only via the NAT Gateway, are blackholed.
WHAT WORKS vs WHAT DOESN'T
- From the EC2 instances (direct IGW egress, instance Elastic IPs): SMTP 587 connects fine.
- From the EKS pods/nodes (NAT Gateway egress): SMTP 587 times out.
Same region, same account, same destinations — the only difference is whether the traffic leaves via an instance's own EIP (works) or via the NAT Gateway (blocked on 25/465/587).
STEPS I'VE ALREADY TAKEN TO RULE OUT MY OWN CONFIG
- EC2 email-sending limits ("remove email sending limitations") were already lifted for the account/region — confirmed because all the direct-IGW instances send on 587 successfully.
- Ruled out IP reputation: I replaced the NAT Gateway's Elastic IP with a brand-new allocation. A fresh, never-used IP is STILL blocked on 25/465/587 via the NAT.
- Ruled out a Kubernetes/CNI/pod issue: tested from the EKS node host itself (not a pod) — same block. So it's the node→NAT→internet path, not anything in the pod network.
- Security Groups on the node/ENI: egress is all-protocols to 0.0.0.0/0 (no port restriction).
- Network ACLs on the subnet: egress allows all to 0.0.0.0/0; ingress allows the TCP ephemeral return range (1024-65535). No port-specific deny.
- Route table: private subnets route 0.0.0.0/0 to the NAT Gateway (active). NAT Gateway is "available", connectivity type public.
- No Traffic Mirroring, no Gateway Load Balancer, no egress-only Internet Gateway, and no interface VPC endpoints that could intercept SMTP (only an S3 Gateway endpoint, which is unrelated).
QUESTION
Is outbound SMTP (25/465/587) throttled or blocked for NAT Gateway egress separately from EC2 instance/IGW egress — i.e., does the standard "remove email sending limitations" only cover traffic egressing from EC2 instance Elastic IPs and NOT traffic egressing via a NAT Gateway? If so, how do I get the SMTP egress restriction lifted for the NAT Gateway path, given the instance-EIP removal doesn't appear to cover it?
I've confirmed there is no Security Group, NACL, route table, or VPC-level interception on my side; the silent drop (timeout, no RST) is consistent with an upstream throttle that's specific to the NAT Gateway egress path.