Hacker News Reader

Comment by Beinglis23 | Hacker News Reader

When a ping is sent from a device on a local network to a device on the internet, the router performing NAT rewrites the source address of the ping to its public IP address and rewrites the ID field of the ICMP packet to a unique value. When the response is received, the router uses the unique ID value to forward the response to the correct device on the local network.

View on HN

Or thinking about the proper way: how an operating system distinguish between two different ICMP 'talks' to the same destination.

Bam, you only need one computer and wireshark/tcpdump.

Sure, the article is nice and probably is enlightening for someone who never even thought about and doesn't have any networking understanding... honestly it's more about how to make a proper network lab and dig the sources but without thinking.

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

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.

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).

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.

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

Ping needs that bit if state itself anyway to match replies to requests.

Why not use the source private IP instead of the “unique value”?

One reason would be to not expose details about your private network to every hop the ICMP packet traverses. Even if knowing you have some 192.168.1.x host is not on its own very useful to an attacker, it'd be preferable to not expose that.

It's another reason WebRTC/STUN was a big issue when it first became widely available, it made it easy to leak details about your LAN to outside servers.

Besides “security” which is a byproduct of NAT and not a goal, there’s the fact that an ip address can change. The routing tables usually go to MAC addresses, not ip addresses. So it is easier to store a unique id that fits in that field, that then points to a MAC address, that then points to a ip address.

But the ID is on the ICMP header or it belongs to the IP part?

Reply on news.ycombinator.com