Inbound connections, port forwarding, and carrier grade NAT

Why nothing can call you

The translation table is built by outbound packets. A row exists because you sent something first. Now consider a packet arriving from the internet with no matching row.

src 198.51.100.9:33445  ->  dst 203.0.113.77:8080

The router looks for port 8080 in its table, finds nothing, and has no way to guess which of your devices was meant. It drops the packet. Not out of malice, out of genuine ignorance.

This is the defining property of NAT, and it has two faces:

- It is an accidental firewall. Unsolicited inbound traffic cannot reach your devices, which is a real security benefit and the reason home networks survive as well as they do. It is accidental, though, so do not treat NAT as a security control. It filters nothing on connections your own devices initiate, which is how most compromises actually happen. - It breaks the peer to peer model of the internet. A host behind NAT is a client only. It cannot be a server unless somebody adds an explicit rule.

That asymmetry, clients everywhere and servers only in data centers, was created by NAT rather than by any protocol design.

Port forwarding, the manual exception

Port forwarding is a static translation row entered by hand, so an inbound packet on a chosen public port has a defined destination.

Two constraints fall straight out of the design. One public port maps to one internal host, so two devices cannot both take public port 443 on the same public address. And the rule is permanent, so whatever is listening there is now exposed to the whole internet and had better be patched.

Three related mechanisms you will meet:

- UPnP and NAT-PMP let an application ask the router to create a forwarding rule automatically. Convenient for game consoles, and a real risk, because any program on your network can open a hole without asking you. - NAT hairpinning, also called NAT loopback, is a router's ability to let an inside device reach the public address of its own network and be looped back inside. Routers that do not support it produce the confusing situation where a service works from outside the house but not from the sofa. - STUN, TURN, and ICE are how video calls work anyway. A STUN server tells each peer what its public address and port look like from outside, both peers then send outbound packets to each other simultaneously so both NATs create rows, and the flows meet in the middle. That trick is called UDP hole punching. When it fails, TURN relays the media through a public server, which always works and costs bandwidth. ICE is the logic that tries the candidates in order.

Carrier grade NAT, and double NAT

When an ISP runs out of public addresses, it stops giving each customer one and puts many customers behind a shared public address. That is CGNAT (carrier grade NAT), and your router's outside address then comes from 100.64.0.0/10, the range reserved for exactly this in RFC 6598.

Now there are two translation layers between your laptop and the internet, which is double NAT.

192.168.1.42     your laptop, private
192.168.1.1      your router, inside
100.64.12.9      your router, outside, still not public
100.64.0.1       the ISP's CGNAT device, inside
203.0.113.77     the ISP's public address, shared with hundreds of customers

The consequences are concrete and worth recognizing on sight:

The genuine fixes are all workarounds. Request a public address from the ISP, often available on business plans. Use IPv6, which CGNAT does not apply to, because there is no shortage to work around. Or rent a small public server and have your inside host open an outbound tunnel to it, which is what remote access services do. All three sidestep the problem rather than solving it, and that is the honest state of IPv4 in 2026.