My main point boils down to NAT extending and providing additional vectors and complexity above and beyond just a firewall. Heck, as a component alone it's a DoS vector as well. See: https://arxiv.org/html/2410.21984v1
This ONE technique we've been discussing - note that we've only been discussing one that I have experience with using for legitimate purposes - is neat in expanding the scope of attackability and flexibility. Not needing to control any aspect of network on any end at all. But it's not the only way. As for the beachhead, it could be as simple as a web page loading something in the background. Doesn't have to be fancy like a dedicated VPN appliance plugged into a person's desk. For ICMP, we really only need timeout exceeded and echo request/reply, packet too large isn't required (and that's what breaks PMTU) nor is dest unreach. With some kind of C&C infra, of course, it provides far more options. Game development libraries are especially useful as starting points here. Ancient Skype was my favorite example of easily getting around corporate firewalls in the past. If we want to get fancier, we can go this route if ALGs are in play - https://github.com/samyk/slipstream, for example. (mitigations and detections have since become available, this was in 2020, but it's still useful in some aspects) - article about this one: https://www.securityweek.com/nat-slipstreaming-visiting-malicious-site-can-expose-local-network-services-remote-attacks/ Or this - https://samy.pl/natpin/ - (no idea if it still works, it's from 2010, but it was just a web page that'd port forward any arbitrary port back to the machine it ran on, written in just javascript) There are, of course, many ways to tighten and mitigate a portion of potential vectors, and not all apply to every situation (like the ALG route above). But, that's again, throwing more and more complexity and management on top of what a simple firewall would otherwise handle in a much cleaner, clearer, and safer way. And not all NAT implementations are created equal.... https://ieeexplore.ieee.org/document/11076087 Tl;dr https://weberblog.net/why-nat-has-nothing-to-do-with-security/ (I probably should note that all this only applies to PAT type NAT) All that being said, all types of NAT are useful and have advantages in plenty of scenarios and shouldn't be avoided, just approached and managed carefully as deployed. But removing NAT removes operational complexity and additional vectors. -----Original Message----- From: William Herrin via NANOG <[email protected]> Sent: Thursday, June 18, 2026 10:29 PM To: Arie Vayner <[email protected]> Cc: North American Network Operators Group <[email protected]>; William Herrin <[email protected]> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 12:55 PM Arie Vayner <[email protected]> wrote: > Unless I'm missing something, the pwnat mechanism will actually work > through any stateful packet inspection (be it NAT or just a firewall) > that allows Traceroute to work. Hi Arie, You're not missing anything. It's a novel mechanism for escalating a beachhead, but Gary hasn't explained why it wouldn't work just as well with any other firewall that allows internal machines to initiate outbound connections by default. Everybody needs ICMP destination unreachable messages from arbitrary sources to reach back to the origin. Path MTU discovery fails if they do not. With any kind of firewall. ICMP Time exceeded is not as crucial but traceroute breaks without it so most firewalls propagate it inward too. Interesting as it is, the thought experiment fails to support Gary's claim that NAT specifically makes a network vulnerable. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/4RW6QTMWCWBJWKQHGSIWXQERC7OUQZDL/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/2R4V523OAVCK6XB77A2LLQSGQL6G5AT3/
