The ICMP echo request scenario is how we do the endpoint discovery so that the server knows the client's address.
After that, you start falling into more "standard" NAT traversal techniques between the two endpoints. That's what gets you the established NAT state/session. -----Original Message----- From: William Herrin <[email protected]> Sent: Thursday, June 18, 2026 3:22 PM To: Gary Sparkes <[email protected]> Cc: North American Network Operators Group <[email protected]> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 11:52 AM Gary Sparkes <[email protected]> wrote: > Correct, I specified both firewalls have an inbound default deny, accept only > related/established. > > The standard CPE configuration for any NAT scenario, and the usual standard > for any non-NAT scenario as well. > > NAT allows me to *bypass* this. Hi Gary, You still have not demonstrated that the non-NAT version rejects the packets. You've claimed it but offered no explanation. In your example, you sent ICMP echo-request packets to some random address. This would allow several types of ICMP packets to return to you from arbitrary IP addresses so long as they contained the same ICMP ID. After all, you have to be able to receive destination unreachable messages from intermediate routers. It would not allow UDP or TCP packets to reach you, at least not in the NAT case. Those use different translation tables which are not populated by outbound ICMP packets. The ICMP return packets are allowed in both the NAT case and the non-NAT case: both have state established to accept returns (including error returns) to the ICMP echo-request. Neither one has state established for TCP or UDP. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/SNCOEMQPN44XX2CYPAHSGN44AZ6J66SU/
