So, obviously it doesn’t work in ALL NAT configurations, obviously, but it works in most.
If you look down here at the how does it work section – https://sa.my/pwnat/ You’re effectively abusing ICMP echo handling. So in their example, the device behind the NAT is sending ICMP’s to 3.3.3.3, which of course, is not replying. “ Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3 ... Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3 ... Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3 ... every 30 seconds ... At this stage, a client wishes to connect Client (6.7.8.9): ICMP Time Exceeded (includes ICMP Echo Request to 3.3.3.3) -> 1.2.3.4 Server's NAT: Sees server's Echo Request in client's Time Exceeded packet, sends entire packet to server because it matches server's outgoing packet Unsure if this works? Just traceroute any host while behind your NAT. You'll notice incoming packets coming in from random IP addresses your router knows nothing about. Your router knows to send those back to you, rather than another client on your network, based off of the data inside the ICMP time exceeded packet. “ From: Dorn Hetzel <[email protected]> Sent: Thursday, June 18, 2026 2:23 PM To: North American Network Operators Group <[email protected]> Cc: William Herrin <[email protected]>; Gary Sparkes <[email protected]> Subject: Re: IPv4 flag day Gary, Does this depend on cone-NAT or what in the NAT device to create the wider-than-single-IP inbound mapping? Regards, Dorn On Thu, Jun 18, 2026 at 12:19 PM Gary Sparkes via NANOG <[email protected]<mailto:[email protected]>> wrote: I never said the Pi wouldn't send outbound packets. This is precisely why I linked pwnat. Because it's what cleanly enables that vector. It's worth a look at, and I've used it (legitimately) to set up a VPN on a network where the ability to configure some network layers was .... limited (terrible CPE). > I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT > _without_ the Pi initiating outbound packets and establsihing connection > state in the 1:many NAT firewall first? I don't think so. It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX. Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4 Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before. -----Original Message----- From: William Herrin <[email protected]<mailto:[email protected]>> Sent: Thursday, June 18, 2026 1:45 PM To: Gary Sparkes <[email protected]<mailto:[email protected]>> Cc: North American Network Operators Group <[email protected]<mailto:[email protected]>> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 10:02 AM Gary Sparkes <[email protected]<mailto:[email protected]>> wrote: > I mean, it's precisely why technology like STUN/TURN/ICE exist. >As to your ask, with two firewalls, inbound default deny, accept >related/established only (So, standard SMB/residential CPE setup), and one >having NAT and the other not having NAT, I can..... > > Drop a box (raspberry pi, for example) inside the network and VPN into it > without having to establish a reverse tunnel first. I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server. And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack. Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/IUBECNWCL3TG7IBRQZPR64GMLWZCH547/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/ZU4SYL65Z7HH4AO6OQWQPZLTDEHHKXTV/
