Comment by sedawkgrep

> Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective?

Actually it doesn't. Well, not really.

With NAT you're generally talking about either 1:1 or 1:many (Masquerading).

In all cases the device doing the NAT maintains a table which is referenced for every matching packet that arrives or leaves.

In 1:1 NAT, the IP in the packet header (Layer-3) is simply rewritten from one address to the other whenever a packet matching both addresses in the NAT table leaves or arrives.

In 1:many NAT, the source port is randomized because you can run into collisions when multiple clients are connecting to the same server:port. So in that case the NAT table contains IP addresses as well as ports. When a return packet arrives, it checks the NAT table and rewrites both the L3 and L4 (port) info before passing it along.

Often times firewalls will randomize the source port when doing 1:1 NAT as a security measure, but after all these years I don't really remember why that's helpful. :-\

But that's really the extent of tracking connections with NAT.

Now when you're talking about firewalling, there's a lot more to track, such as connection start/stop/timeouts/lifetimes, total throughput, TCP state (handshakes, sequence numbers, etc.), closing open sessions when seeing things like TCP RSTs or FINs or ICMP unreachables. The amount of data and CPU is dramatically higher, and tailored to the software doing the firewalling. I believe in many cases simple L3/L4 rewrites can happen in hardware.

I haven't talked about any of this in several years so I hope I'm making sense.