RE: IPv4 flag day

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

I mean, it's precisely why technology like STUN/TURN/ICE exist. To do exactly this. Establish direct connections 
between hosts over NAT that wouldn't be otherwise possible. 

But even then, other techniques exist as well. Not every technique works in every NAT setup, but a lot work in most out 
of application availability necessity. Utilizing NAT to bypass firewalls isn't exactly a new or novel technique. 

This might be of interest - https://sa.my/pwnat/ - that's one of the 'other techniques' not involving external 
infrastructure like STUN/TURN/ICE do. 

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. 

-----Original Message-----
From: William Herrin <bill () herrin us> 
Sent: Thursday, June 18, 2026 12:18 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 9:03 AM Gary Sparkes <gary () kisaracorporation com> wrote:
> Code running in a browser isn't a concern? That foothold can be extremely minimal, non-persistent, and enable far 
> greater attack/leveraging than otherwise available.
>
> But yes, this technique of allowing inbound traffic flows to bypass NAT is something that's somewhat common (STUN 
> servers anyone?) to support NAT legitimately, so it's hard to keep out of the mix.
>
> As I've noted in previous parts of this discussion, this is an example of the kind of NAT support network code I've 
> ripped out of applications I maintain. So in 1:many NAT scenarios, it's no longer plug-and-play. But it's far simpler 
> and easier to maintain.


Hi Gary,

Configure two firewalls identically. Changing nothing else, configure the second to implement 1:many NAT. Now, 
demonstrate a use of the technology you describe here where the NAT version of that firewall is more vulnerable than 
with the one without it.

Your claim was that NAT _enables_ the sort of attack you describe.
That it is vulnerable when the alternative is not. Show me.

No one in this discussion has posited that NAT is a cure-all against every attack vector. I think you're probably 
arguing against a straw man.

Regards,
Bill Herrin


--
For hire. https://bill.herrin.us/resume/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/X6LS5CYNRAQBMIVTA2GDDPPHUAW7SYFB/