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]> 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]> > Sent: Thursday, June 18, 2026 2:37 PM > To: Gary Sparkes <[email protected]> > Cc: North American Network Operators Group <[email protected]> > Subject: Re: IPv4 flag day > > On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <[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/
