I'm seeing inbound traffic in the VPC flow logs for my public NAT gateway. Is my public NAT gateway accepting inbound traffic from the internet?
Last updated: 2022-10-31
My Virtual Private Cloud (VPC) flow logs show Action = ACCEPT for inbound traffic coming from public IP addresses. However, my understanding of network address translation (NAT) gateways was that they don't accept traffic from the internet. Is my NAT gateway accepting inbound traffic from the internet?
NAT gateways managed by AWS don't accept traffic initiated from the internet. However, there are two reasons why information in your VPC flow logs might appear to indicate that inbound traffic is being accepted from the internet.
Reason #1: Inbound internet traffic is permitted by your security group or network access control lists (ACL)
VPC flow logs show inbound internet traffic as accepted if the traffic is permitted by your security group or network ACLs. If network ACLs attached to a NAT gateway don’t explicitly deny traffic from the internet, then the traffic to the NAT gateway appears accepted. However, the traffic isn't actually accepted by the NAT gateway and is dropped.
To confirm this, do the following:
- Open the Amazon CloudWatch console.
- In the navigation pane, choose Insights.
- From the dropdown, select the log group that contains the NAT gateway's elastic network interface and the private instance's elastic network interface.
- Run the query below.
filter (dstAddr like 'xxx.xxx' and srcAddr like 'public IP') | stats sum(bytes) as bytesTransferred by srcAddr, dstAddr | limit 10
Note: You can use just the first two octets in the search filter to analyze all network interfaces in the VPC. In the example above, replace xxx.xxx with the first two octets of your VPC classless inter-domain routing (CIDR). Also, replace public IP with the public IP that you're seeing in the VPC flow log entry.
Query results show traffic on the NAT gateway private IP from the public IP, but not traffic on other private IPs in the VPC. These results confirm that the incoming traffic was unsolicited. However, if you do see traffic on the private instance's IP, then follow the steps under Reason #2.
Reason #2: Traffic to the public IP was initiated from a private instance
If there are private instances using NAT gateway for internet access, then your VPC flow log includes the response traffic from the public IP address. To confirm that traffic to the public IP was initiated from your private instance, run the query below:
Note: Before running the query, do the following:
- Select the time frame that corresponds with the time frame when you observed traffic in the VPC flow logs.
- If you have multiple log groups in your VPC, then select the appropriate one.
filter (dstAddr like 'public IP' and srcAddr like 'xxx.xxx') or (srcAddr like 'public IP' and dstAddr like 'xxx.xxx') | limit 10
Be sure to replace xxx.xxx with the first two octets of your VPC CIDR. Replace public IP with the public IP you're seeing in the VPC flow log entry. Increase the limit if more than 10 resources in your VPC have initiated traffic to the public IP.
The query results show bi-directional traffic between the private instance and public IP addresses. To determine whether the private instance or external public IP address is the initiator, see the following example:
2022-09-28T12:05:18.000+10:00 eni-023466675b6xxxxxx 10.0.101.222 220.127.116.11 53218 53 6(17) 4 221 1664330718 1664330746 ACCEPT OK 2022-09-28T12:05:18.000+10:00 eni-023466675b6xxxxxx 18.104.22.168 10.0.101.222 53 53218 6(17) 4 216 1664330718 1664330746 ACCEPT OK
Note: It's a best practice to turn on the TCP flag field for your VPC flow log.
For example, the following entries have TCP flag field in the last column:
2022-09-28T12:05:52.000+10:00 eni-023466675b6xxxxxx 10.0.1.231 22.214.171.124 50691 53 6(17) 3 4 221 1664330752 1664330776 ACCEPT OK 2 2022-09-28T12:05:21.000+10:00 eni-023466675b6xxxxxx 126.96.36.199 10.0.1.231 53 50691 6(17) 19 4 216 1664330721 1664330742 ACCEPT OK 18
The private IP address 10.0.101.222 is the initiator with TCP flag 2, which represents a TCP SYN packet.
In the following ICMP protocol example, there isn't enough information to determine which side is the initiator because there is no port information or TCP flag:
2022-09-27T17:57:39.000+10:00 eni-023466675b6xxxxxx 10.0.1.231 188.8.131.52 0 0 1 17 1428 1664265459 1664265483 ACCEPT OK 2022-09-27T17:57:39.000+10:00 eni-023466675b6xxxxxx 184.108.40.206 10.0.1.231 0 0 1 0 17 1428 1664265459 1664265483 ACCEPT OK