Gary, Does this depend on cone-NAT or what in the NAT device to create the wider-than-single-IP inbound mapping?
Regards, Dorn On Thu, Jun 18, 2026 at 12:19 PM Gary Sparkes via NANOG < [email protected]> wrote: > 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/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/3E4OK7OX5O3W7GQBT6JLX2B32UXRGDNG/
