RE: IPv4 flag day

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

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/