Understanding Network Infrastructure · Part 3 · How does traffic reach other networks and the Internet?

How do PCs behind one router share a public IP for Internet access?

Private addresses, PAT mappings, return traffic, state, and port forwarding troubleshooting

A private IP identifies the PC internally. Internet-bound packets use a translated public address and port so replies can return. The border device records the original and translated values in a NAT/PAT mapping, then uses it to find the internal PC when a response arrives. We follow one round trip to explain address and port changes and distinguish NAT, connection tracking, and stateful firewall processing.

How can a device with a private address reach an Internet server?↑

RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private IPv4 use. Many organizations reuse these addresses, so 10.0.0.25 alone cannot identify one host across the Internet.

For traditional IPv4 Internet access, a border device maps the private source to the organization's public address. A private address is not a security feature. Nonoverlapping private addresses can be routed within a private network or VPN without NAT.

Two companies can both use 10.0.0.25 in separate internal routing contexts. But Internet routers have no global way to associate 10.0.0.25 with one company's route. An Internet-bound packet needs a reachable public source at the border so the server can reply. NAT is one way to map between these address domains.

Not all private-network traffic needs NAT. If headquarters and a branch connect nonoverlapping RFC 1918 prefixes through a VPN with valid routes, they can retain the private addresses. Conversely, policy can apply NAT to public addresses. Address type, translation, and firewall permission are separate decisions. Keeping them separate avoids claims that a private IP is inherently safe or that without NAT a route cannot work.

NAT changes header values and maintains the mapping needed to reverse those changes. It does not, by itself, authenticate users or detect malicious traffic. Hiding a private address from direct external view and a firewall deciding whether traffic is allowed may produce similar-looking results, but they are different functions. Record them separately in design and troubleshooting.

Sources for this section IETF RFC 1918

Sharing one public IP: PAT distinguishes ports too↑

NAT is the broad term for mapping an IP address to another address. Basic NAT maps addresses; NAPT, also called PAT, additionally uses TCP/UDP ports or ICMP identifiers. These transport identifiers let multiple connections share a public address.

Products may use names such as SNAT, hide NAT, or masquerading. Look beyond the name: which fields change, in which direction, and what information is retained?

Suppose two internal PCs connect to the same server, 203.0.113.20:443, at once. One flow starts at 10.0.0.25:51514; the other at 10.0.0.26:51514. Sharing one public IP as the source requires another way to distinguish them externally. A PAT device might map them to 198.51.100.8:40001 and 198.51.100.8:40002, so each response's destination port identifies its flow.

TCP and UDP port spaces are distinguished by protocol, so the same port number can belong to different mappings. ICMP Echo has no TCP/UDP ports; implementations may use its Identifier field instead. Endpoint-independent mapping, address and port-dependent mapping, and filtering behavior can affect P2P and VoIP reachability. Do not stop at “PAT changes ports.” Determine which protocol fields form the mapping and how the device restricts external peers.

A device may preserve the internal source port if no conflict exists, or choose another port when one is in use or policy requires it. PAT therefore does not always change the port number. Whether the external address forms part of the mapping key, and whether one internal tuple reuses a mapping across destinations, depends on NAT behavior and configuration.

Sources for this section IETF RFC 3022 · IETF RFC 4787

The first outbound packet creates an internal-to-public mapping↑

Assume internal endpoint 10.0.0.25:51514 opens a connection to server 203.0.113.20:443 using TCP. The border device can choose public address 198.51.100.8 and external port 40001.

Before TCP 10.0.0.25:51514      → 203.0.113.20:443
After TCP 198.51.100.8:40001   → 203.0.113.20:443

The device records a NAT translation entry, changes the IP/TCP headers, and adjusts the required checksums. Even with PAT, however, the external port number can be the same as the internal port number.

When a new SYN matches NAT policy and has a valid route, the device finds an available public tuple and creates a translation entry. It may record the inside source, externally visible source, destination, protocol, creation time, and last-use time. Implementations differ in whether the destination is a lookup key or additional state. Operators still need to correlate the inside and outside tuples in one entry.

With port preservation, internal port 51514 can remain unchanged externally. If the public tuple is already in use or policy selects another pool, the device may choose 40001 instead. After changing packet headers, it must consistently adjust the IPv4 header checksum and any affected TCP/UDP pseudo-header-based checksum. For IPv4 UDP, a zero checksum must remain zero. Compare pre- and post-translation packets using not only addresses and ports, but also TCP sequence numbers and flags to identify the same packet.

This entry is live state used for reverse translation, not just a log. Depending on implementation, it includes creation and last-use times, protocol state, and a timeout. Different addresses in inside and outside captures are not necessarily an error. Correlate flags, sequence numbers, timestamps, and translation values to identify the same flow.

Sources for this section IETF RFC 3022 · IETF RFC 7857

How do a reply's public IP address and port identify the internal PC?↑

The server's response targets 198.51.100.8:40001. The border device uses this value, the protocol, and implementation-specific keys such as the remote peer to find the existing NAT mapping. A matching entry lets it restore the destination IP and port to 10.0.0.25:51514 and forward the reply inward.

If the mapping expires or is lost during a restart, the device may no longer know which internal flow should receive a late reply. Check both standards and product behavior for UDP/TCP entry lifetimes, endpoint mapping, filtering, and timeouts.

The reply SYN-ACK's destination, 198.51.100.8:40001, is not the router's own service port. It is the public-side tuple for an existing internal flow. After finding the mapping, the device changes the destination to 10.0.0.25:51514 and uses the internal route and neighbor information to reach the PC. Other devices sharing that public IP—another PC, for example—have different external ports and do not receive this reply. That lookup is how one public IP distinguishes multiple PCs.

An unsolicited external packet cannot identify an original internal destination without a mapping. Unless it targets a device service, static DNAT, or a port forwarding rule, the packet is usually dropped. This is not the same as a NAT security policy. Late UDP replies after timeout, flows losing state during failover, and incomplete Layer 4 information across IP fragments expose implementation differences. Compare entry creation, last-use, and expiration times with packet timestamps.

If a timeout removes the entry or failover does not copy it to the new device, the same response no longer has a mapping to restore. An internal prefix in the routing table and a permissive firewall policy may not keep the session alive. Check return failures in order: did the public interface receive the packet, did translation lookup succeed, and does the restored packet have a valid internal route?

Sources for this section IETF RFC 3022 · IETF RFC 7857

Why do inbound connections and double NAT need extra setup?↑

An internally initiated PAT entry handles replies to that flow. For an external user to initiate a connection to an internal server, a public address and port must map to the inside destination through DNAT or port forwarding, with separate firewall permission.

• Hairpin NAT: When an internal user reaches an internal server through the same border's public address, translation and return routing must work in both directions.
• CGNAT: Multiple subscribers share public addresses again within the ISP network. If the home router's WAN address is in 100.64.0.0/10, subscriber-side port forwarding alone generally cannot establish external access.
• Resource limits: Beyond port space, entry limits, destination concentration, protocol, and timeouts affect the number of concurrent connections.

A DNAT rule mapping public 198.51.100.8:8443 to internal 10.0.0.50:443 changes the incoming SYN's destination at the border. The firewall policy, internal route, and server's LISTEN port must also be correct. The server's response must cross the same border and use the existing mapping so the external client sees a response from 198.51.100.8:8443. One DNAT rule is only part of making a service reachable end to end.

With hairpin NAT, an internal client connects to a public address. Both source and destination may need translation to make the return path cross the NAT device again. With CGNAT, another ISP translation layer sits outside the home router, and configuring the home router alone cannot create mappings in that upstream layer. Check support for Port Control Protocol, a public IPv4 option, IPv6, or alternatives such as a reverse proxy or VPN. For clues about upstream NAT, compare the WAN address with the externally observed address. This comparison alone cannot determine the number of NAT layers.

Home NAT behind ISP CGNAT creates two translation layers. Configuring home-router port forwarding does not create an inbound mapping for the ISP's public address. VPN, SIP, and some P2P services rely on endpoint information or inbound access and can be affected by double NAT and short timeouts. Check each border's public address, translations, and administrative control separately.

Sources for this section IETF RFC 6598 · IETF RFC 6888

Glossary↑