Hacker News Reader

Comment by baq | Hacker News Reader

Taking this thought just a tiny bit further, this is changing a stateless protocol to a stateful one.

NAT stands for Network Address Translation, which means a NAT device maintains a translation table of internal IPs to external, so that it can return response packets coming from Internet to a proper destination on the internal network.

By definition NAT will maintain state which is translation table. Now that table can be dynamic or static, but it doesn't change the fact that there will be some state to maintain.

> By definition NAT will maintain state which is translation table.

Stateless NAT is also possible, but then it has to be 1:1. Which has it's purpose, but is rarely used.

A practical example would be with IPv6 if your ISP doesn't allocate you a static prefix. Stateless NAT would allow you to use a /64 from the private range of fd00::/8 in your local network which the router would translate to your globally unique /64. No state needed, because there would be as many IPs available in your LAN prefix as in your GUA prefix. All it would do would be translating fdxx:xxxx:xxxx:xxxx:1234:1234:1234:1234 to 2yyy:yyyy:yyyy:yyyy:1234:1234:1234:1234 and vice versa.

I've also done stateless NAT on IPv4. When you request more IPs from some cloud providers, they assign you a bunch of /32s, not a proper subnet, virtually requiring you to run a cloud router.

Any NAT that is not statically mapping IP addresses or ports 1-to-1 will require connections to be tracked and hence makes it stateful on the side after the translation (usually outside).

Hence you do need state syncing between firewalls in order for NAT connections to failover correctly, unless it's a statically mapped, one-on-one, one range onto another range, for example.

This isn't really specific to NAT either, connection tracking is required for most firewalls as well even if NAT isn't in play just to implement the most basic ALLOW related,estabalished rule even, and especially, what would normally be connectionless protocols.

Yes, tracking the state of connections (e.g. TCP) is needed enforce rules on OSI layers 4 - 7. That's kinda the typically scenario when we think of connection tracking and stateful enforcement of rules.

I was just pointing out when NAT also requires connection tracking (i.e. when the NAT table needs to be built dynamically, as opposed to statically mapped).

You're confusing tracking the packets with protocol. It's not changing ICMP, it's tracking ICMP packets. That's a totally different thing.

Is or was a thing with NAT. Linux also comes with stateful modules (ip_conntrack*) to track and rewrite higher level protocols, such as FTP control connections.

Reply on news.ycombinator.com