Re: IPv4 flag day

[Dorn Hetzel via NANOG <nanog () lists nanog org>]

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 <
nanog () lists nanog org> 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 <bill () herrin us>
> Sent: Thursday, June 18, 2026 1:45 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 10:02 AM Gary Sparkes <gary () kisaracorporation com>
> 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/nanog () lists nanog org/message/IUBECNWCL3TG7IBRQZPR64GMLWZCH547/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/3E4OK7OX5O3W7GQBT6JLX2B32UXRGDNG/