RE: IPv4 flag day

[Gary Sparkes via NANOG <nanog () lists nanog org>]

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 <dorn () hetzel org>
Sent: Thursday, June 18, 2026 10:59 PM
To: Gary Sparkes <gary () kisaracorporation com>
Cc: North American Network Operators Group <nanog () lists nanog org>; Arie Vayner <ariev () vayner net>
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 <gary () kisaracorporation com<mailto:gary () kisaracorporation com>> 
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 <dorn () hetzel org<mailto:dorn () hetzel org>>
Sent: Thursday, June 18, 2026 5:46 PM
To: North American Network Operators Group <nanog () lists nanog org<mailto:nanog () lists nanog org>>
Cc: Gary Sparkes <gary () kisaracorporation com<mailto:gary () kisaracorporation com>>; Arie Vayner <ariev () vayner 
net<mailto:ariev () vayner net>>
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 <nanog () lists nanog org<mailto:nanog () lists nanog org>> 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 <nanog () lists nanog org<mailto: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<mailto:bill () herrin us>>
> Sent: Thursday, June 18, 2026 2:37 PM
> To: Gary Sparkes <gary () kisaracorporation com<mailto:gary () kisaracorporation com>>
> Cc: North American Network Operators Group <nanog () lists nanog org<mailto:nanog () lists nanog org>>
> Subject: Re: IPv4 flag day
>
> On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary () kisaracorporation com<mailto: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/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FUN6PUKR3A4PY323QX5X5IPPATXYAXK3/