On Thu, Jun 18, 2026 at 9:03 AM Gary Sparkes <[email protected]> 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/[email protected]/message/H6LVYI5EHCGJJ4M7FB2A3DWAH2WDKZZR/
