Explainer · self-hosting

Port forwarding, explained

The rule that lets the outside world reach a service inside your home network — and the workflow most likely to silently fail in 2026. Here is what it does, why it breaks, and the modern alternatives that mostly replace it.

The problem port forwarding solves

When you visit a website, your machine opens a connection outward to the site. Your home router does Network Address Translation (NAT) on the way out — it remembers your private IP and rewrites the source to look like the router's public IP. When the website responds, the router matches the response to its NAT table and sends the packet back to the right device inside your network.

That mechanism works perfectly for outbound connections. It fails entirely forinbound connections: if someone on the public internet wants to reach a service inside your home — a game server, a self-hosted website, a remote-access tool — they arrive at your router's public IP with no way to know which internal device should receive the traffic, and the router (by default) drops the connection on the floor.

A port forwarding rule is the override: "when traffic arrives on TCP port 25565, send it to 192.168.1.42 on the same port." It's a permanent NAT-table entry telling the router how to handle inbound flows to a specific port. The protocol itself — TCP or UDP — and both the external and internal port can be specified independently.

Why you might need it

How the rule actually works

Your router maintains a NAT table that maps internal flows to external translations. For each outbound connection, it remembers the four-tuple: 192.168.1.42:54321 ↔ <your-public-IP>:31234. When the response arrives at the router's public IP on port 31234, it knows where to send it.

A port forward is a static entry in this table — created at the moment you configure the rule, not on demand. It says: any inbound connection to public-IP:25565 should land on 192.168.1.42:25565, regardless of whether there was a preceding outbound flow. The router rewrites the destination IP and port, then forwards the packet onto the LAN.

Different router UIs use different names for the same concept: "Port Forwarding," "Virtual Server," "Application Filter," and (badly) "DMZ" all refer to similar mechanisms. The badly-named "DMZ" mode is usually the worst option — it forwardsall inbound ports to one device, which is almost never what you want.

Automatic configuration: UPnP and PCP

The two automated standards let an app request a port forward without you opening the router UI:

On a fully-trusted home LAN, leaving UPnP on is fine. On any network where you don't fully trust every device — visitor devices, smart-home gear of dubious provenance, kids' devices — turn UPnP off and add rules by hand.

Why your port forward silently fails

You added the rule, the router shows it as active, and nothing on the outside can reach the service. The diagnostic checklist, in order of frequency:

  1. You're behind CGNAT. Your ISP is doing a second layer of NATabove your router. The forward rule stops at your router; the ISP's NAT layer has no idea anyone wanted to reach you. This is the #1 cause on mobile carriers, T-Mobile Home Internet, Starlink (in some configurations), Verizon LTE Home, and an increasing share of FTTH offerings. Compare your router's WAN page IP with what IPFerret shows. If they differ — or if your WAN address is in 100.64.0.0/10 — you're CGNAT'd. Read the full CGNAT explainer for what to do about it.
  2. Your router doesn't actually have a public IP. Variant of the above. Cable modems sometimes run a "router mode" you can't disable, putting their own NAT in front of yours. The fix is to ask the ISP to put your modem in bridge mode.
  3. The target device's local firewall. A correctly-forwarded port arrives at the device but is rejected by Windows Defender, macOS's pf, ufw, or a personal firewall. Easy to miss because the router shows the rule as active and the failure is one layer deeper.
  4. The service isn't actually listening. The forward routes to the device, the device's firewall allows the connection, but no service is bound to the port. Confirm with ss -tlnp | grep :25565 on Linux, netstat -an | findstr 25565 on Windows.
  5. You're testing from inside the LAN. "NAT hairpinning" — the ability to reach your own public IP from inside — works on some routers and not others. Always test from a genuinely external network: tether to your phone (with mobile data, not Wi-Fi from home), or use a service like canyouseeme.org or ifconfig.co.

Quick probe commands

From outside your LAN:

The modern alternatives that mostly replace port forwarding

Port forwarding is from a 1990s mental model where every device wanted its own public IP. In 2026, most of the reasons people reach for it are better solved with something that doesn't need a forward at all.

Reverse tunnels (Cloudflare Tunnel, Tailscale Funnel, ngrok)

Your home device opens an outbound connection to a public relay. The relay holds the connection open and forwards inbound traffic from the internet back down it. No inbound port on your network needed; works perfectly behind CGNAT; only exposes the ports you explicitly map. Cloudflare Tunnel is free, has a polished interface, and handles TLS for you. Tailscale Funnel is great when you already use Tailscale for the rest of your network. ngrok is the dev-focused option.

Mesh VPNs (Tailscale, Nebula, ZeroTier)

Every device on the mesh gets a stable private IP. To reach your home machine from your phone, you don't expose anything to the public internet — you join both devices to the same mesh, and they speak directly (peer-to-peer with hole-punching where possible, relayed otherwise). This is the right answer for "I want to remote-access my own machines from anywhere" — port forwarding was always a workaround for that use case.

IPv6 end-to-end

If both endpoints have native IPv6, every device on your home network has a globally-routable address — no NAT at all, no port forwarding required, just firewall rules. The catch is that the consumer-internet IPv6 deployment is uneven and many ISPs still don't offer it. Verify with the IPv6 reachability test; if your connection has working v6, every device in your house already has a public address waiting.

Hole punching (WebRTC, STUN, Tailscale)

For peer-to-peer use cases — video calls, file transfers, multiplayer games — modern tools use STUN servers to discover each side's NAT mapping, then synchronize outbound packets so the NAT mappings line up. This works for peer-to-peer traffic. It doesn't help if you want random internet strangers to reach a service you host — they have nothing to synchronize with.

When you genuinely want a real forward

Sometimes the answer is just "open the port." If reverse tunnels feel like cheating and you have a real public IP, here's the recipe:

  1. Confirm you have a public IP, not CGNAT. The router's WAN page is the source of truth — if it shows a 100.64.x.x address, you're CGNAT'd and no router rule will fix it.
  2. Give the target device a stable internal address — either a DHCP reservation (keyed on MAC) or a static IP outside the DHCP pool. DHCP reservation is usually less work. See our DHCP guide.
  3. Open the router's "Port Forwarding" or "Virtual Server" panel. Add: external port (what the internet connects to), internal IP (the target device), internal port (what the service is actually listening on, may differ from external), protocol (TCP, UDP, or both).
  4. Open the matching port in the device's local firewall: sudo ufw allow 25565/tcp on Linux, Windows Defender Firewall on Windows, System Preferences → Security & Privacy on macOS.
  5. Confirm the service is actually listening on the right port with ss -tlnp or netstat -an.
  6. Test from outside the LAN — phone on mobile data, not Wi-Fi from home.

Security checklist before opening a port

Related reading