Network Address Translation (NAT)

Network Address Translation (NAT) is a technique routers use to map an entire private network onto a single public IP address by rewriting the address information in packet headers as traffic passes through. It emerged largely to conserve scarce IPv4 addresses and is now nearly universal on home routers. For anyone self-hosting — a Bitcoin node, a miner dashboard, a Nostr relay — NAT is also the single most common reason a service that works perfectly on your local network is unreachable from the wider internet.

How it works

Devices behind your router use private, non-routable addresses from reserved ranges such as 192.168.x.x, 10.x.x.x, and 172.16–31.x.x. When one of them opens an outbound connection, the router substitutes its own public address for the private source address and records the mapping in a translation table so return traffic can be forwarded back to the right device. The variant running on virtually every home router is Port Address Translation (PAT, also called NAT overload or IP masquerading): it additionally rewrites the source port, giving each connection a unique public-side port so that dozens of devices can share one public address simultaneously. From the outside, your entire home network looks like a single busy host.

Why inbound connections break

NAT only creates a table entry when a connection originates from inside. An unsolicited packet arriving from the internet matches nothing in the table, so the router has no idea which internal device should receive it and silently drops it. That asymmetry is why your Bitcoin Core node can make its outbound peer connections just fine but never accepts inbound peers, why a miner's web UI is invisible from outside the house, and why every self-hosting guide eventually arrives at the same chapter. The standard remedy is port forwarding: a manual rule telling the router that traffic arriving on a specific public port always goes to a specific internal device. Automatic alternatives such as UPnP exist but trade convenience for a wider attack surface, since any device on the LAN can then open holes in your perimeter.

Carrier-grade NAT

Some ISPs add a second NAT layer of their own — carrier-grade NAT (CGNAT) — sharing one public address among many customers. Behind CGNAT you cannot open inbound ports at all, because the outermost router belongs to the ISP, not to you. This is a common and frustrating obstacle for home node operators: everything is configured correctly on your side and inbound still fails. Options include requesting a real public address from the ISP (sometimes a paid add-on), tunnelling out to a VPS or VPN endpoint that has one, or sidestepping the problem entirely with an onion service, which builds connectivity from outbound connections only.

NAT and the sovereignty question

NAT is often described, half-jokingly, as the accidental firewall — and it does block unsolicited inbound traffic as a side effect. But it should not be mistaken for security architecture; a real firewall policy is still essential. More fundamentally, NAT made the internet asymmetric: networks full of clients that can consume but not serve. Running reachable infrastructure from home — a node that accepts inbound peers, a relay others can use — is a small act of restoring the peer-to-peer shape the network was designed with. Understanding your router's translation table is the first step; deciding what you deliberately expose, and through which layer of forwarding, tunnel, or reverse proxy, is the second.

One last habit worth building: know your own NAT situation cold. Check whether your public address matches what your router reports (a mismatch means CGNAT), keep a note of which forwarding rules exist and why, and re-verify them after firmware updates — routers have a talent for quietly resetting the table. Ten minutes of documentation here saves hours of "it worked last month" debugging later.