RE: IPv4 flag day

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

The missing part is that we’re *effectively* performing an unsolicited inbound connection.

The ICMP part is used to discover the client IP. Then you perform the NAT traversal techniques now that you have that 
information.

The ICMP portion could be leveraged to trigger something behind a non-NAT firewall to connect *out* to something you 
control (listening server, network you can open inbound ports on, etc).

But not unsolicited inbound UDP tunneling from an arbitrary address and network architecture.

From: Arie Vayner <ariev () vayner net>
Sent: Thursday, June 18, 2026 3:55 PM
To: North American Network Operators Group <nanog () lists nanog org>
Cc: William Herrin <bill () herrin us>; Gary Sparkes <gary () kisaracorporation com>
Subject: Re: IPv4 flag day

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/3LQ3JWZXC3QOEFZJQKOYZKUG53457EGO/