The missing part is that we’re *effectively* performing an unsolicited inbound connection.
The ICMP part is used to discover the client IP. Then you perform the NAT traversal techniques now that you have that information. The ICMP portion could be leveraged to trigger something behind a non-NAT firewall to connect *out* to something you control (listening server, network you can open inbound ports on, etc). But not unsolicited inbound UDP tunneling from an arbitrary address and network architecture. From: Arie Vayner <[email protected]> Sent: Thursday, June 18, 2026 3:55 PM To: North American Network Operators Group <[email protected]> Cc: William Herrin <[email protected]>; Gary Sparkes <[email protected]> Subject: Re: IPv4 flag day Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work. They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism... So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole... Interesting technique for sure. On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG <[email protected]<mailto:[email protected]>> wrote: Simply, the inbound firewall rules prevent it from working. There's no NAT to bypass the firewall to allow the ingress. You'd instead have to open the ingress port on the firewall to allow the traffic. (It does work, as I noted, I've used it for a legitimate customer before) In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control. Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address. -----Original Message----- From: William Herrin <[email protected]<mailto:[email protected]>> Sent: Thursday, June 18, 2026 2:37 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 11:18 AM Gary Sparkes <[email protected]<mailto:[email protected]>> wrote: > I never said the Pi wouldn't send outbound packets. > > 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. Hi Gary, That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall? The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/TYNHRRA4OHL5CRXN2C2FZ7KMC4EWJIUS/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/3LQ3JWZXC3QOEFZJQKOYZKUG53457EGO/
