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?
"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?"
"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?ResolutionNAT 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 10Note: 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 instanceIf 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 10Be 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 8.8.8.8 53218 53 6(17) 4 221 1664330718 1664330746 ACCEPT OK2022-09-28T12:05:18.000+10:00 eni-023466675b6xxxxxx 8.8.8.8 10.0.101.222 53 53218 6(17) 4 216 1664330718 1664330746 ACCEPT OKIn this TCP/UDP traffic (protocol ID = 6 or 17) example, the private IP address10.0.101.222 with the source port53218 (ephemeral port) is the initiator. The IP address8.8.8.8 with destination port53 is the receiver and responder.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 8.8.8.8 50691 53 6(17) 3 4 221 1664330752 1664330776 ACCEPT OK 22022-09-28T12:05:21.000+10:00 eni-023466675b6xxxxxx 8.8.8.8 10.0.1.231 53 50691 6(17) 19 4 216 1664330721 1664330742 ACCEPT OK 18The 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 8.8.8.8 0 0 1 17 1428 1664265459 1664265483 ACCEPT OK2022-09-27T17:57:39.000+10:00 eni-023466675b6xxxxxx 8.8.8.8 10.0.1.231 0 0 1 0 17 1428 1664265459 1664265483 ACCEPT OKThe format of your flow log entry depends on how it was created. For more information on log line formats, see View flog logs.Related informationLogging IP traffic using VPC Flow LogsSample queriesFollow"