- Newest
- Most votes
- Most comments
The large numeric values in the log entries are the "start" and "end" timestamps of each flow:
- 1747979769 = 2025-05-23 05:56:09.000Z
- 1747979789 = 2025-05-23 05:56:29.000Z
- 1747979790 = 2025-05-23 05:56:30.000Z
The field description on the documentation page https://docs.aws.amazon.com/vpc/latest/userguide/flow-log-records.html#flow-logs-fields says that both values may be 0-60 seconds later than the actual moment to which the field refers. Based on the client's ephemeral port number 38168 and the timestamps fitting into the 60-second window, it seems very likely that those flows are indeed the one and the same TCP connection.
How did you limit access to CloudFront in the security group? Are you using the AWS-provided managed prefix list for the origin-facing servers for CloudFront? If so, it would seem most likely that the way security groups are implemented for NLBs as a function of the AWS hyperplane might cause TCP-level processing to get logged in VPC flow logs despite the security group set not to permit the initial TCP SYN segment in and quite likely no actual response getting sent to the internet.
You could consider testing it yourself: simply try connecting to port 80 on the NLB from any public internet connection. Check with tcpdump, Wireshark, or other packet capture tool if any response was returned. Once the VPC flow logs are delivered, check if similar VPC flow log entries are logged for your test and if they match what is shown in the packet capture. My guess would be that no packets are actually returned to the blocked client, even if VPC flow logs for the NLB show a response being generated to a request that should never have reached the NLB, which would probably be an unintended side effect of some implementation detail of the AWS hyperplane.
To make VPC flow logs more useful, you might also want to consider logging some of the other available fields. Particularly the tcp-flags field can be helpful in distinguishing between things like TCP SYN, RST, and other types of segments.
Based on the information provided, it's unlikely that the Network Load Balancer (NLB) initiated the traffic. The behavior you're observing in the VPC flow logs is likely due to how NLBs handle connections and how VPC flow logs record traffic.
NLBs are designed to drop unintended traffic without forwarding it to any targets. This means that for ports not configured with a listener (in this case, any port other than 80), the NLB will reject the connection attempts.
The flow log entries you're seeing are probably part of the same connection attempt, but they're recorded separately for the inbound and outbound traffic. Here's a likely interpretation of what's happening:
-
The first entry (REJECT) shows an incoming connection attempt from 64.62.197.131 to port 80 on the NLB (172.31.37.126). This was rejected, possibly because the source IP is not in the allowed CloudFront IP range in the security group.
-
The second entry (ACCEPT) shows the NLB's response to this connection attempt. Even though the initial connection was rejected, the NLB still sends a response packet back to the source to close the connection properly.
The timestamps in VPC flow logs can sometimes appear out of order due to how the logs are collected and aggregated. The actual sequence of events is likely:
- Incoming connection attempt (recorded as REJECT)
- NLB's response (recorded as ACCEPT)
The ACCEPT status on the outbound traffic doesn't necessarily mean a successful connection was established. It just indicates that the outbound packet from the NLB was allowed by the security group and NACL rules.
To further investigate, you might want to:
- Check if the source IP (64.62.197.131) is indeed a CloudFront IP.
- Verify your security group rules to ensure they're correctly configured to allow only CloudFront IPs.
- Consider using more detailed logging or packet capture tools for a more comprehensive view of the traffic patterns.
Remember that VPC flow logs provide a high-level overview of network traffic and may not capture all the nuances of connection handling by services like NLB.
Sources
Network Load Balancers without Security Groups. | AWS re:Post
Monitor your Network Load Balancers - Elastic Load Balancing
Resolve Network Load Balancer's TCP connectivity errors | AWS re:Post
Relevant content
- asked 2 years ago
I've tried multiple connection's to NLB's listener but flow logs registered "REJECT" only. I guess I will treat that as another example of flow logs weird reporting (e.g. NAT gateways show "ACCEPT" for traffic that is dropped)