3

When reviewing Flowlogs for a host on a private subnet in an AWS VPC that routable IP addresses are being rejected. How is that possible? I expect IP addresses from the private subnet could be rejected but not routable IP's

This is an example of the flowlog:

12:24:40 2 redacted eni-obfuscated 149.28.xx.xx 10.55.27.62 53501 22 6 1 40 1539951880 1539951940 REJECT OK

13:22:41 2 redacted eni-obfuscated 60.51.xx.xx 10.55.27.62 60375 8081 6 1 40 1539955361 1539955421 REJECT OK

13:39:41 2 redacted eni-obfuscated 221.229.xx.xx 10.55.27.62 9090 22 6 1 40 1539956381 1539956441 REJECT OK

The VPC layout contains a public and private subnet. The private subnet routes outbound to the Internet through an AWS NAT Gateway. The public subnet contains a bastion host that is used to connect to the private host.

The bastion server has a security group that only allows in port 22 from specific IP addresses (a.b.c.d/32).
The host on the private subnet has a security group that allows only ssh in from the bastion host, and all traffic from the private subnet.

So where is this coming from? On the bright side no IP addresses I don't expect are being accepted.

Improve this question
3
  • Ok, so you're seeing traffic ostensibly from public IPs attempting to contact hosts in your private subnet, which has no direct internet access, other than through a bastion host that separates your public/private subnet, and filters traffic only allowing TCP Port 22 from a specific IP. Right?
    – Daisetsu
    Commented Oct 20, 2018 at 0:41
  • Looking at the flowlog documentation, it says "dstaddr:The destination IPv4 or IPv6 address. The IPv4 address of the network interface is always its private IPv4 address." This means the 10.X.X.X IP you're seeing in your flow log for the destaddr is the local IP for that host, but there could be a public IP also associated with that host. You may want to check if that's the case. If so, the flow log is showing that your security groups are correctly preventing traffic from those public IPs.
    – Daisetsu
    Commented Oct 20, 2018 at 0:50
  • @Daisetsu, correct on the first comment. Regarding the second comment, the host does not have a public IP associated to it. It is also in a subnet that routes through a NAT and is not connected directly to the Internet.
    – kenlukas
    Commented Oct 22, 2018 at 14:29

1 Answer 1

Reset to default
1

TL;DR - There was a Network Load Balancer (NLB) in the private subnet in front of the host in the private network. That NLB had a public IP.

When there is a Public IP associated to the network interface, traffic from the client public IP (source) will reach the ENI provided the security group and ACL allows the traffic to come in, regardless of whether there is IGW as default route or not.

Because an AWS NLB does not use security groups and no NACL was in place, routable traffic was able to reach the private subnet. The security group on the host rejected the traffic and that's what was showing up in the Flow Logs.

Response traffic would not make it out of the private subnet because the route tables are followed. Route tables aren't used to control inbound traffic but do control responses.

Can you clarify why an NLB in a private subnet even with a publicly routable IP address can receive traffic when it's subnet does not route through the Internet Gateway?

From a port scanners perspective they would have received no response from the NLB.

SYN from the client will reach the NLB, but no SYN-ACK would be sent to the client as now route table would be evaluated for response traffic and as there is no route to IGW the response traffic would be dropped.

To summarize, NLB or your backend target are not responding to internet traffic. Traffic would be accepted by Public IP on private subnet regardless of the route table default route.

Reference: AWS Support

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .