At the point notification (the “server” receives the time exceeded packet) it then starts slinging UDP packets in a fashion just like the client does to establish the holepunch. At least, for this specific example. Removes any kind of external resource or network control requirement.
From: Dorn Hetzel <[email protected]> Sent: Thursday, June 18, 2026 10:59 PM To: Gary Sparkes <[email protected]> Cc: North American Network Operators Group <[email protected]>; Arie Vayner <[email protected]> Subject: Re: IPv4 flag day Does this assume that the firewall creating a mapping for ICMP also causes it to create a full mapping for any IP protocol (TCP, UDP, etc) ? On Thu, Jun 18, 2026 at 4:05 PM Gary Sparkes <[email protected]<mailto:[email protected]>> wrote: ICMP Time Exceeded, not unreachable. In this case we’re abusing that ICMP Time Exceeded packet to communicate to the host behind the NAT the client-side IP. Then all the magic can light up between the two endpoints. From: Dorn Hetzel <[email protected]<mailto:[email protected]>> Sent: Thursday, June 18, 2026 5:46 PM To: North American Network Operators Group <[email protected]<mailto:[email protected]>> Cc: Gary Sparkes <[email protected]<mailto:[email protected]>>; Arie Vayner <[email protected]<mailto:[email protected]>> Subject: Re: IPv4 flag day Do I misunderstand, or does it only allow inbound traffic from random hosts *as long as it meets the format of ICMP unreachable* and has the correct contents? On Thu, Jun 18, 2026 at 3:34 PM Arie Vayner via NANOG <[email protected]<mailto:[email protected]>> wrote: 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/LYNHL7WXW7NRKI7TSJBDGBRPVJFGSSYU/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/FUN6PUKR3A4PY323QX5X5IPPATXYAXK3/
