NAT

When 192.168.1.42:51000 opens a connection to 203.0.113.5:443, the NAT device rewrites the source to its public 198.51.100.1 and a chosen port, say 40001, and records a translation entry: (192.168.1.42, 51000, 203.0.113.5, 443) ↔ (198.51.100.1, 40001). Return packets to 198.51.100.1:40001 are matched against the table and rewritten back. Ports are what make sharing possible: one public address has ~64k ports, so it can multiplex tens of thousands of simultaneous flows from many private hosts. The IPv4 checksum and TCP/UDP checksums are recomputed on every rewrite.

Entries are created by outbound traffic and expire by timeout — a few minutes for idle TCP on many devices, tens of seconds for UDP. That produces the classic failures. Inbound connections have no entry, so unsolicited packets are dropped unless a static mapping (port forwarding) exists; peer-to-peer and WebRTC need STUN/TURN and hole-punching to work around it. Idle connections whose entry expires die silently: the next packet matches nothing, and the client sees a reset or a hang — the reason long-lived connections need keep-alives shorter than the NAT timeout.

Table exhaustion under high connection churn (many short-lived connections, each holding an entry through TIME_WAIT) drops new flows with a timeout to perfectly healthy destinations. And protocols that embed IP addresses in their payload (classic FTP, SIP) break unless the NAT understands them, because the address in the payload is not rewritten.