Wi-Fi & Network

Port forwarding isn't working

Forwarded a port and still can't reach the service? Work the real causes in order — CGNAT, double-NAT, the hairpin test trap, ISP-blocked 80/443, wrong IP.

Problem summary

Most 'port forwarding doesn't work' cases are one of a few things: you're testing from inside the LAN (hairpin), you're behind CGNAT or a double-NAT so the rule can never be reached, the ISP blocks 80/443, or the forward points at the wrong internal IP. Prove the service listens locally first, then test from outside.

Operator snapshotEvidence first

First proof

Read your router's WAN IP and compare it to whatismyip.com.

Screen to open

ss -tlnp (or: netstat -an | find "LISTENING" on Windows)

Expected signal

The router's WAN IP is public and matches whatismyip.

Stop boundary

Confirm with traceroute showing a 100.64 carrier hop before investing in workarounds.

Layer path

1Port forwarding fails for a small number of distinct reasons, and the order you test in matters: most 'it doesn't work' reports are really a test-from-inside (hairpin) artifact or a path that can never be reached (CGNAT / double-NAT).

2A forward only matters if (a) inbound traffic actually reaches your router's WAN, (b) the rule points at the device's real current IP, (c) the host is listening and its own firewall allows the port, and (d) you're testing from outside.

3Two WAN-IP shapes decide a lot: a private WAN IP (192.168/10.x/172.16) means double-NAT you can fix; a 100.64.0.0/10 WAN IP means CGNAT you cannot port-forward through at all.

4Prove the service locally first, then test only from an external network — an external port checker or a phone on cellular.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Prove the service locally

Check: On the host, confirm it listens on the LAN interface (ss -tlnp), then reach it by internal IP from another LAN device.

Expected result: The service answers locally by its LAN IP.

If not: If it only listens on 127.0.0.1 or not at all, fix the bind/host firewall before touching the router.

Classify the WAN path

Check: Compare the router's WAN IP to whatismyip: public-and-matching, private (double-NAT), or 100.64.x (CGNAT).

Expected result: You know whether a forward can be reached at all.

If not: CGNAT → stop and use a tunnel/VPN; double-NAT → bridge/passthrough the upstream gateway first.

Point the forward at a reserved IP

Check: Create the forward to a DHCP-reserved/static internal IP and the correct port.

Expected result: The rule targets an IP the device actually holds.

If not: Without a reservation, a lease change silently breaks the forward later.

Test only from outside

Check: Use a phone on cellular or an external port checker to test the public IP and port.

Expected result: The port is reachable from outside.

If not: Never trust an in-LAN test of the public IP — hairpin limits make it lie.

Handle ISP port blocks

Check: If 80/443 fail but a high port works, switch to an alternate external port, a reverse proxy, or a tunnel/mesh VPN.

Expected result: The service is reachable on a port the ISP doesn't block, or via a no-inbound-port path.

If not: Don't keep retrying 80/443 against a residential block — change the approach.

Clear the quiet blockers

Check: Check the host firewall and the router's UPnP mappings; remove conflicts.

Expected result: No host firewall drop or stray UPnP mapping defeats the rule.

If not: If it still fails with a clean external path, re-confirm the service bind and the destination IP.

Decision tree

If: Router WAN IP is in 100.64.0.0/10 (or differs from whatismyip).

Then: You're behind CGNAT — a forward can never be reached.

Action: Stop trying to port-forward; use a Cloudflare Tunnel or mesh VPN. See /fix/cgnat-home-access-no-public-ip.

Safe stop: Confirm with traceroute showing a 100.64 carrier hop before investing in workarounds.

If: Router WAN IP is a private range (192.168/10.x/172.16).

Then: Double-NAT: your router sits behind another NAT.

Action: Put the ISP gateway in bridge mode / IP passthrough, or DMZ it to your router, so only one device does NAT.

If: It works from outside but not when tested from home.

Then: Hairpin/NAT-loopback limitation, not a broken forward.

Action: Enable NAT reflection/loopback on the router, or use split-horizon/local DNS; otherwise just test from outside.

If: A high port is reachable but 80/443 are not.

Then: The ISP blocks those inbound ports.

Action: Use an alternate external port, a reverse proxy, or a tunnel/mesh VPN.

If: Path is fine but the specific service still won't answer.

Then: Wrong internal IP, host firewall, service not listening, or a UPnP conflict.

Action: Reserve the IP, allow the port on the host, bind the service to all interfaces, and clear stray UPnP mappings.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Nothing reachable from outside; WAN IP looks odd.	Router WAN IP vs whatismyip; traceroute first hops.	CGNAT or double-NAT	Bridge the gateway (double-NAT) or move to a tunnel/VPN (CGNAT).
Fails from home, untested from outside.	Result from a phone on cellular or an external port checker.	Hairpin test artifact	Trust only the external test; enable NAT loopback if you need in-LAN access by public name.
High port works, 80/443 time out.	External port check on 8080 vs 80/443.	ISP inbound block	Alternate port, reverse proxy, or tunnel.
Path open but service silent.	ss -tlnp on host; forward destination IP; host firewall; UPnP mappings page.	Host/service/IP/UPnP	Reserve IP, bind to all interfaces, allow port, clear UPnP conflict.

Reference

Commands and settings paths

Is the service even listening?

ss -tlnp (or: netstat -an | find "LISTENING" on Windows)

Where: On the host running the service.

Expected: The service is listening on 0.0.0.0/the LAN IP and the intended port — not only 127.0.0.1.

Failure means: Loopback-only or absent means the forward has nothing to deliver to.

Safe next step: Bind the service to all interfaces, then reach it by internal IP from another LAN device.

What is the router's WAN IP really?

Router admin > WAN/Internet status vs whatismyip.com

Where: In the router admin UI and a browser.

Expected: WAN IP is public and matches whatismyip.

Failure means: Private WAN IP = double-NAT; 100.64.x = CGNAT.

Safe next step: Bridge the upstream gateway, or move to a tunnel/VPN for CGNAT.

Is the port open from OUTSIDE?

An external port checker, or: nc -vz <public-ip> <port> from a cellular hotspot

Where: From a network outside your home (phone on cellular, not your Wi-Fi).

Expected: The port shows open/reachable from outside.

Failure means: Closed from outside while fine locally points at CGNAT/double-NAT, an ISP block, or a host firewall.

Safe next step: Work the decision tree by which combination of internal/external tests passes.

Any conflicting UPnP mappings?

Router admin > UPnP / port-mapping status

Where: In the router admin UI.

Expected: No automatic UPnP mapping conflicts with your manual forward.

Failure means: A game console or app may have auto-created a mapping on the same port.

Safe next step: Remove the stray mapping or disable UPnP, then re-test.

Hardware boundary

Hardware and platform boundary

Change only when

If you're behind CGNAT or fighting ISP blocks, stop hardening port-forwarding and move to a tunnel (Cloudflare Tunnel) or mesh VPN (Tailscale/WireGuard) — see the safe-remote-access guide.

Evidence that matters

Whether your ISP gives a real public IPv4 (vs CGNAT), whether the router supports bridge mode and NAT loopback, and DHCP reservations.

Evidence that does not matter

Raw router throughput — port forwarding is a reachability/config problem, not a speed one.

Avoid

Exposing a sensitive service straight to the internet just to make a forward work, or DMZ'ing your whole LAN; prefer a reverse proxy or VPN.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Device setup troubleshooter

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 web research verified against router/firewall vendor docs (UI/Ubiquiti, MikroTik, OPNsense/pfSense NAT reflection, Netgate UPnP) and CGNAT detection guidance; complements rather than duplicates /fix/cgnat-home-access-no-public-ip. Leads with the hairpin test trap and the local-listen check, the two most common false failures.

Sources/assumptions

Assumes a consumer/prosumer router where you've already created a forward rule and the target service runs on a known LAN device.
Assumes you can test from a network outside your home (a phone on cellular) — testing from inside the LAN is the single most common false failure.
If you're behind CGNAT, port forwarding cannot work at all — a tunnel or mesh VPN is the answer; see the CGNAT page.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Apple Support: Wi-Fi and internet troubleshooting on MacUsed for safe first checks around Wi-Fi status, diagnostics, VPN/security software, and external network devices.Microsoft Support: Fix network connection issues in WindowsUsed for Windows network baseline checks before changing router-wide settings.T-Mobile: 5G Home Internet plans and CGNAT behaviorUsed for T-Mobile Home Internet 2026 reality: CGNAT default on all tiers, no port forwarding, no UPnP, 1.2 TB Heavy Data User threshold.Cloudflare: Cloudflare TunnelUsed for cloudflared install, Public Hostnames + Access policies, account limits (1000 tunnels, 100 MB upload cap on free/Pro), and SMB-over-Tunnel limitations.Tailscale: Pricing v4 (April 8, 2026)Used for the April 2026 Tailscale pricing change: free Personal plan = 6 users + unlimited user devices, 50 tagged resources, exit nodes free on all tiers.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

It works from my phone on Wi-Fi but not from my laptop — wait, why does testing from home lie to me?

Testing from inside your own LAN using the public IP/domain is the classic trap. Many routers can't 'hairpin' (NAT loopback) — loop a packet from the LAN out to their own WAN IP and back in — so the connection fails even when the forward is perfect for outside users. Always test from an external network: a phone with Wi-Fi off (on cellular), a friend's connection, or an external port checker. Only trust an outside result.

My router's WAN IP starts with 192.168 or 100.64 — what does that mean?

A private WAN IP (192.168.x, 10.x, 172.16–31.x) means your router sits behind another router/gateway — a double-NAT — so your forward never sees inbound traffic. Fix it by putting the ISP gateway in bridge mode / IP passthrough, or DMZ'ing it to your router. A WAN IP in 100.64.0.0/10 means CGNAT (the carrier is NAT'ing you) and you cannot port-forward at all — use a tunnel or mesh VPN instead. See CGNAT: no public IP.

Forwarding a high port works but 80 and 443 don't — is my router broken?

More likely your ISP blocks inbound 80/443 on residential plans (port 25 too). Confirm with an external port check: if 8080 is reachable but 80/443 time out, that's the signature. Work around it with an alternate external port, a reverse proxy, or a Cloudflare Tunnel / mesh VPN that needs no inbound port at all.

The forward looks right but still nothing — what's left?

Check the boring causes: the forward points at an IP the device no longer holds (set a DHCP reservation), the host's own firewall blocks the port, the service is bound to 127.0.0.1 instead of all interfaces (it isn't actually listening for LAN traffic), or a stray UPnP mapping conflicts with your manual rule. Confirm the service is reachable by its internal IP from another LAN device before blaming the router.