I never said the Pi wouldn't send outbound packets. This is precisely why I linked pwnat. Because it's what cleanly enables that vector. It's worth a look at, and I've used it (legitimately) to set up a VPN on a network where the ability to configure some network layers was .... limited (terrible CPE).
> I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT > _without_ the Pi initiating outbound packets and establsihing connection > state in the 1:many NAT firewall first? I don't think so. 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. -----Original Message----- From: William Herrin <[email protected]> Sent: Thursday, June 18, 2026 1:45 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 10:02 AM Gary Sparkes <[email protected]> wrote: > I mean, it's precisely why technology like STUN/TURN/ICE exist. >As to your ask, with two firewalls, inbound default deny, accept >related/established only (So, standard SMB/residential CPE setup), and one >having NAT and the other not having NAT, I can..... > > Drop a box (raspberry pi, for example) inside the network and VPN into it > without having to establish a reverse tunnel first. I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server. And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack. Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/IUBECNWCL3TG7IBRQZPR64GMLWZCH547/
