Re: IPv4 flag day

[Arie Vayner via NANOG <nanog () lists nanog org>]

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 <nanog () lists nanog org>
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 <bill () herrin us>
> Sent: Thursday, June 18, 2026 2:37 PM
> To: Gary Sparkes <gary () kisaracorporation com>
> Cc: North American Network Operators Group <nanog () lists nanog org>
> Subject: Re: IPv4 flag day
>
> On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary () kisaracorporation com>
> 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/nanog () lists nanog org/message/TYNHRRA4OHL5CRXN2C2FZ7KMC4EWJIUS/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/LYNHL7WXW7NRKI7TSJBDGBRPVJFGSSYU/