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]> 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]> > *Sent:* Thursday, June 18, 2026 5:46 PM > *To:* North American Network Operators Group <[email protected]> > *Cc:* Gary Sparkes <[email protected]>; Arie Vayner < > [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]> 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]> > 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/ > > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/473JXSWZRGV76ZQR3KMP32WMPSUFS2J3/
