When the internet was first designed, every device connected to it was supposed to have a unique public-facing IP address, and they did, for a time. But the explosion of internet-connected devices meant a solution was necessary, and Network Address Translation or NAT was born. This essentially translates your router's external IP into your devices' internal IP, fixing the IP address limitations but introducing a few new problems. The thing is, those problems are easily fixable with NAT rules to forward ports into and out of your network, and it would be that simple if your ISP wasn't involved.

Single NAT is straightforward in dealing with port forwarding, but the problem is that many ISPs use another form of NAT called CGNAT (Carrier Grade-NAT), which puts you in a double NAT situation. This isn't a problem for regular internet use, but makes port forwarding and the peer-to-peer networking used in many multiplayer games a tricky thing.

The problem with CGNAT

Gamers and home labbers know the pain of this all-too-familiar situation

So, NAT is usually 1:1, where one router gets one IP address, and then the devices behind that router get NAT applied to them for routing packets. This is fine, it works, it's not a perfect solution but what is. CGNAT, however, breaks the 1:1 ratio, and puts multiple routers on the same public IP. This makes trying to port forward a nightmare, because you're not in charge of the external IP and you don't know the second hop to forward through that as well.

Because you don't know the second set of NAT rules, you can't set up port forwards because any rules only pass the first NAT (the one between your private network and the public IP), and go nowhere when they hit the second ISP-imposed NAT. So, if you're behind CGNAT (like most residential ISP customers in the US are), what can you do? Paying for a static public IP address is one option, but usually requires a business connection and those are twice the price of residential ones. But there are a few other things that could happen, and it's worth checking those first.

But it's a (mostly) solved problem now

Port Control Protocol (PCP) outlined in RFC 6887, provides a way for your ISP to scan for incoming ports on their CGNAT host and decide how to route them through to the internet. It also reduces the number of keepalive packets needed to keep that connection going. Many ISPs will see your forwarded port and apply their own forward rule, so it behaves as if you were connected to the internet, but not all, and definitely not for all ports.

Want to self-host an email server? Well, you can't without some workarounds because Port 25 will be blocked on the CGNAT side as spammers love to use self-hosted email servers to send phishing emails and other unwanted mail. And many low-number ports will also be blocked from use, like port 443 or port 80. If you use ports above 1024 (remember there are over 65,000 ports to use), you have a better chance of the automated forwarding rules working. But what if that doesn't work?

Time to learn about NAT traversal

Who needs ports opening or forwarding when you can sidestep everything

There are a few ways to side-step port forwarding blocks, including using a VPS either as a relay or as the self-hosted server for your email (assuming your VPS provider won't also block the necessary ports). That's one route, but it's even neater to avoid having to port forward at all. I don't like having ports permanently open through my firewall; it makes it too easy for the automated scanners used by hackers to flag your IP as one to investigate further.

The solution is to use a that performs NAT traversal, which takes advantage of the inherent properties of NAT and stateful firewalls to punch through the NAT solution and set up an encrypted point-to-point VPN for the connection to go through. Most firewall rules stop packets from coming in, so solutions like NetBird, ZeroTier, Tailscale, and Pangolin send packets out from your private network. The firewall sees the packet go out, and if it gets an incoming packet that matches that one, it lets the connection go through.

Some firewalls or NAT solutions are pickier, and need a third server to initiate the connection, using a process known as STUN, that works as a relay to tell the packets where to go. In practice, many CGNAT traversal techniques use all of these tricks, with STUN servers, port mapping protocols, and tests for NAT64, because IPv6 is much easier to deal with (it drops the need for NAT completely). And a few fallback relays, just for good measure if nothing else works.

Modern remote access tools have all but wiped the annoyance of CGNAT away

CGNAT has been a pain for many years, and is still an annoyance but one that you can work around. In an ideal world, everything would be running on IPv6 now and NAT and CGNAT would no longer be necessary, but we live in a dual-stack world, so we use tools to mitigate the effects.