VPC inbound traffic rules do not apply for UDP? Kind of BUG?

0

My configuration is simple:

  • VPC
  • IGW
  • Public subnet: 1 NAT GW with a route pointing to the IGW
  • Private subnet => Other stuff
  • Management subnet: 1 Bastion host running wireguard with a public ip address attached. The subnet has 1 route that points to the NAT Gateway with destination 0.0.0.0/0

THE PROBLEM: TCP Traffic do not reach the bastion host as expected. BUT! UDP traffic CAN reach the bastion host. I can actually ssh to the bastion through wireguard that is the VPN software we are using and runs over UDP... so traffic is bidirectional.

Isn't that wrong? based on the documentation in order for a public ip address on a subnet to work, it has to have a route to the IGW.

if I change that route to point to the IGW, the TCP AND UDP works.

  • Hi, can you edit your question and publish the sec group protecting the management subnet?

asked 12 days ago110 views
4 Answers
1

You have asymmetric route that causes this problem:

Client -> IGW -> Bastion -> NAT GW -> IGW -> Client

Your Bastion receives traffic (TCP SYN) to it's public IP, but when it responds (TCP SYN-ACK) it get routed from the Bastion's private IP to the NAT GW which drops it because it is a stateful device and expects TCP traffic to begin with SYN.

With UDP there there is no indication for start of a session like SYN with TCP, so the response from the Bastion is not dropped by the NAT GW and is being forwarded back to the client.

If your bastion has a public IP, why are you routing it through a NAT GW and not directly to the IGW?

profile pictureAWS
EXPERT
answered 11 days ago
profile picture
EXPERT
reviewed 10 days ago
  • Completely agree

  • Thanks for the comment. I understand your reasoning there is only one thing that doesn't match with this theory and correct me if I'm wrong. Based on the documentation, for a public IP to receive traffic within a VPC, it has to have a route to the IGW. That is at least my understanding. The subnet where I placed the bastion has a route to the NAT GW ONLY. Unless the previous statement is ONLY valid for outbound traffic?

  • @JuanBrein can you provide a link to the documentation so I can see the exact wording?

    In any case, as long as the VPC has an Internet Gateway associated with it and the EC2 instance has a public IP it will be able to receive inbound traffic from the internet.

    The outbound traffic from the EC2 instance is determined by the route table associated with the subnet where the EC2 instance resides.

    (If I answered your question I will appreciate if you can accept it)

0

There’s an issue with your configuration description.

Your bastion host has a public IP. Therefore it must be in a public subnet with a route to an IGW. But you say there’s a route of 0.0.0.0/0 to the NAT gateway. Please confirm as that configuration is invalid.

The route in the public subnet of 0.0.0.0/0 MUST route to the IGw.

The route in the private subnet of 0.0.0.0/0 MUST route to the NAT gateway that’s sat on the Public subnet.

profile picture
EXPERT
answered 12 days ago
0

There is no issue in the configuration.

Both management and private subnets have NAT GW routes with destination 0.0.0.0/0 . The public net has IGW route with destination 0.0.0.0/0

Now if I assign a public IP to an instance in the management subnet I still can receive UDP traffic. That should not be possible as per the VPC/NAT/IGW documentation. Is that expected?

answered 12 days ago
0

Didier_Durand Security Groups do not protect subnets but EC2 Instnaces. Now if that is the case, I can tell you the instance has ALL UDP/TCP Ingress allowed and UDP/TCP ougbound allowed.

Although I don't think this is relevant to my problem. Even with a fully open ACL/SG and a public IP address attached to the instance, it shouldn't be possible for any internet box to send UDP traffic successfully since there is no route to the IGW.

answered 12 days 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.

Guidelines for Answering Questions