Don't Port-Forward: NAT, Exposure, and Overlay Networks
TL;DR
To reach something at home from the outside (a NAS, a camera, a game server, a home lab), the old advice was to “port-forward” it on your router. That quietly puts the device on the public internet, where automated bots find and attack it within minutes. There is a far safer modern way: an overlay network (like Tailscale or WireGuard) that connects your devices privately, with nothing exposed to the internet at all.
- Your router’s NAT normally hides your home devices from the internet by accident. Port-forwarding removes that protection for whatever you forward.
- Anything you expose is constantly scanned and attacked. Exposed remote desktop, cameras, and NAS boxes are a top cause of ransomware and account takeover.
- The better approach is an overlay (mesh) network: your devices build encrypted tunnels to each other, reachable only by you, with no inbound ports opened.
- Tailscale is the easy option (WireGuard under the hood, almost no setup). Plain WireGuard is the do-it-yourself version. Either beats port-forwarding for remote access.
Now for the more technical explanation
What NAT is, and why it accidentally protects you
Home routers use NAT (Network Address Translation). Your devices have private addresses (like 192.168.x.x) that are not routable on the public internet; the router shares one public address for everyone behind it. When a device inside makes an outbound connection, the router remembers it and lets the reply back in.
The side effect is important: unsolicited inbound connections have nowhere to go. Someone on the internet cannot reach your laptop or NAS, because the router has no rule sending that traffic anywhere. It is not a firewall by design, but in practice NAT hides your devices. That accidental protection is what port-forwarding throws away.
What port-forwarding actually does
A port-forward tells the router: “any connection from the internet arriving on port X, send it to this internal device.” You are deliberately opening a hole from the entire internet straight to that device and service.
That means the service is now:
- Discoverable. The whole internet is scanned continuously. Search engines for exposed devices (Shodan, Censys, and similar) index anything reachable, usually within hours.
- Attackable. Once found, it faces automated brute-force, credential stuffing, and exploitation of any unpatched vulnerability, around the clock, forever.
Why this goes wrong so often
The classic disasters are all exposed services:
- Remote Desktop (RDP) on port 3389: a perennial favourite for ransomware crews. Exposed RDP is brute-forced and, once in, the whole network follows.
- IP cameras and DVRs: shipped with default or weak credentials and rarely patched, so they end up in botnets or streaming to strangers.
- NAS boxes: exposed management interfaces have been hit by waves of ransomware that encrypt every file on the device.
- Anything unpatched: a single known vulnerability in an exposed service is enough.
The pattern is always the same: exposure plus a weak credential or an unpatched flaw equals compromise. And you often will not know until it is too late.
How do you reach your home network without port-forwarding?
An overlay network (also called a mesh VPN) flips the model. Instead of opening your network to the world and hoping to defend it, your devices join a private encrypted network that only you can access. Nothing is exposed to the public internet.
How it works, in plain terms:
- Each device runs a small client and makes an outbound connection to a coordination service, so no inbound port is opened (NAT stays intact).
- The coordination service helps your devices find each other and then get out of the way; the actual traffic flows directly and encrypted between your devices (peer-to-peer where possible).
- Only devices you have authorised can join, so the network is private by default.
The result: you can reach your NAS or home lab from anywhere as if you were on your home network, but an attacker on the internet sees nothing to attack.
The options
- Tailscale (recommended for most people). Built on WireGuard, but it handles the hard parts (key exchange, NAT traversal, device authorisation) for you. Install it on each device, sign in, and they can reach each other. Minimal setup, strong security, generous free tier for personal use. There is also Headscale, an open-source coordination server you can self-host if you want no third party in the loop.
- Plain WireGuard. A fast, modern, lean VPN protocol. You run it yourself: generate keys, write configs, and (usually) run one endpoint you can reach. More manual than Tailscale, and you still need one reachable endpoint, but it is excellent and fully under your control.
- ZeroTier. Another mesh option with a slightly different model (virtual layer-2 networks). Also solid; pick based on preference.
For nearly everyone, Tailscale is the shortest path from “I want to reach my stuff remotely” to “done, and nothing is exposed.”
When you genuinely must expose a service
Sometimes something has to be reachable by the public (a website, a service others use). If so, do it properly, not with a raw port-forward:
- Put it behind a reverse proxy that terminates TLS and adds authentication, and keep everything patched.
- Use a tunnel that avoids opening inbound ports, such as Cloudflare Tunnel, which connects out from your side and publishes the service without exposing your IP or router.
- Host it on a cloud VM or managed service instead of your home connection, so your home network is never the attack surface.
- Never expose management interfaces (RDP, SSH with passwords, NAS admin panels, camera portals) directly. Those go behind the overlay network, always.
The short version
Port-forwarding was fine when the internet was smaller and quieter. Today, anything you expose is found and attacked almost immediately. For remote access to your own things, use an overlay network (Tailscale is the easy win, WireGuard the hands-on one) and keep your inbound ports closed. Reserve genuine public exposure for the rare case that truly needs it, and even then, put it behind TLS, authentication, and ideally a tunnel.
Related
Written by Tom Langston, IT Infrastructure and Cybersecurity.