RE: IPv4 flag day

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

So, obviously it doesn’t work in ALL NAT configurations, obviously, but it works in most.

If you look down here at the how does it work section –

https://sa.my/pwnat/

You’re effectively abusing ICMP echo handling.

So in their example, the device behind the NAT is sending ICMP’s to 3.3.3.3, which of course, is not replying.

“    Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
    ...
    Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
    ...
    Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
    ... every 30 seconds ...

              At this stage, a client wishes to connect
    Client (6.7.8.9): ICMP Time Exceeded (includes ICMP Echo Request to 3.3.3.3) -> 1.2.3.4
    Server's NAT: Sees server's Echo Request in client's Time Exceeded packet,
              sends entire packet to server because it matches server's outgoing packet

    Unsure if this works? Just traceroute any host while behind your NAT. You'll
    notice incoming packets coming in from random IP addresses your router knows
    nothing about. Your router knows to send those back to you, rather than another
    client on your network, based off of the data inside the ICMP time exceeded packet.
“


From: Dorn Hetzel <dorn () hetzel org>
Sent: Thursday, June 18, 2026 2:23 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

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<mailto: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<mailto:bill () herrin us>>
Sent: Thursday, June 18, 2026 1:45 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 10:02 AM Gary Sparkes <gary () kisaracorporation com<mailto: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/ZU4SYL65Z7HH4AO6OQWQPZLTDEHHKXTV/