Why Port Forwarding Fails: Diagnose Double NAT, CGNAT, and IPv6 Before Buying Gear
Tech GuruA port-forward rule is only one part of the connection path. The service must listen on the intended interface, host and router firewalls must allow the traffic, and any upstream NAT must also deliver it. A private router WAN address can mean your own second router or the ISP's network; those require different fixes.
Quick Answer
First prove the service works from another LAN device. Then compare the router's WAN IPv4 address with the public IPv4 observed through that same connection, without a VPN or proxy. Identify who controls any upstream NAT before changing rules or buying hardware. Double NAT under your control can be configured; ISP-controlled CGNAT usually needs a provider option or a different access path. Test native IPv6 separately with explicit firewall rules.
Baseline
Identify the service address and protocol, each router, and the WAN IPv4 on the actual outbound path.
Change
Fix the failed local check or the specific NAT/firewall hop; do not open every port.
Validate
Test from outside the LAN with the real application and check both allowed and denied access.
Operate
Remove temporary rules, maintain DNS/address mappings, and monitor the exposed service.
Start at the Service, Not the Internet
Write down the application, destination device, internal port, and protocol. TCP and UDP are different; a TCP-only port checker cannot establish that a UDP game server or VPN works. Give the server a stable LAN address through the router's supported reservation mechanism, and check that the forward still points to that address.
- On the server, confirm the application is running and listening on the intended LAN interface, not only 127.0.0.1 or ::1. Use the application's status/logs and your OS's socket-inspection tool.
- Connect from a second device on the same LAN using the server's LAN address and real application protocol. A working browser on the server itself does not prove other hosts can reach it.
- If that fails, inspect the host firewall, VLAN/client isolation, container port publication, and the server's route back to the client. Fix this local path before adding internet exposure.
- Keep authentication and transport encryption in place. Do not expose NAS administration, database administration, or a container-management API merely to test a forwarding rule.
Unperformed HTTP example: for an application you deliberately run at 192.168.50.20:8080, test from another LAN device with the following. The address and port are illustrative. This reads the application's root URL; do not use it against a service where that request has unintended side effects.
curl --ipv4 --connect-timeout 5 --max-time 15 http://192.168.50.20:8080/A response, including an expected authentication error, establishes more than a timeout, but it is not proof of application health. A connection refusal suggests that the target or an intervening device actively rejected the connection. A timeout can mean filtering, routing failure, or no response; it does not locate the fault by itself. The flags are documented in the curl manual.
Identify the Address on the Router's WAN
Read the WAN or internet-interface address in the router, not the address on your laptop. On a device using that router, check the internet-visible IPv4 address at the same time. Disable or account for VPNs, browser proxies, multi-WAN policies, and other alternate paths before comparing. Comparing a router's IPv4 to a website's IPv6 result is not a useful NAT test.
| WAN address or observation | Interpretation | Next check |
|---|---|---|
| 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16 | RFC 1918 private address. Another routing/NAT layer may be upstream. | Find the modem/router in front of yours and establish who administers it. |
| 100.64.0.0 through 100.127.255.255 | RFC 6598 shared space, commonly used between ISP CGNAT and subscribers. | Ask the ISP whether unsolicited inbound IPv4 and a public-address option are available. |
| Public WAN IPv4 matches observed public IPv4 | No mismatch was found on this test path. | Check exact forward, host firewall, protocol, and provider filtering. Matching addresses do not prove inbound access. |
| WAN IPv4 differs from observed public IPv4 | An upstream translation or a different outbound path needs explanation. | Eliminate VPN/proxy/multi-WAN effects; inspect the upstream device or ask the provider. |
RFC 1918 defines private space; RFC 6598 defines the separate shared block. Not every address starting with 172 is private, and not every address starting with 100 is shared space. These ranges are clues about reachability, not a complete diagnosis of your ISP.
If You Control Both Routers
Double NAT commonly means an ISP gateway routes a network and a second home router creates another network behind it. Choose one supported design: place the upstream gateway in bridge or passthrough mode and let your router own routing; put your downstream unit in access-point mode and let the gateway route; or deliberately forward through both. Save configurations and confirm how you will regain management access before changing modes. ISP voice, television, authentication, or VLAN requirements may constrain bridge mode.
Illustrative two-router path, not a tested deployment: the upstream gateway owns the public IPv4; your router's WAN is 192.168.1.2; the server behind it is 192.168.50.20. For a service on TCP 8443, the upstream rule targets 192.168.1.2:8443, and the downstream rule targets 192.168.50.20:8443. Both private addresses must remain stable. The upstream rule does not target the downstream server directly because that server is behind the second router in this design.
Do not use a broad DMZ-host rule or disable either firewall as the first diagnostic step. A narrow forward makes the intended exposure easier to verify and remove. Ubiquiti's port-forwarding troubleshooting covers upstream NAT and local-service checks; apply the concepts using your own router's supported configuration.
If the ISP Controls the Missing Hop
With carrier-grade NAT, or CGNAT, a local forwarding rule cannot by itself create the needed mapping on the provider's translator. Ask the ISP whether your connection supports unsolicited inbound IPv4, whether a public address or provider-managed mapping is available, and whether relevant ports are filtered. A static address is not always necessary for forwarding; a reachable dynamic public address can work with an appropriate DNS update plan.
For access by your own users and devices, consider an authenticated overlay network. A Tailscale subnet router can provide authorized access to devices that cannot run the client, but advertise only the required routes and apply access policy. Do not treat joining the overlay as permission for every device to reach every subnet.
For a suitable hosted application, an outbound connector such as Cloudflare Tunnel avoids depending on a home-router inbound mapping. Confirm protocol support, authentication, provider trust, and usage limits first. A public hostname without an access policy is still public exposure. A conventional VPN server at home may face the same CGNAT obstacle; an outbound tunnel to a reachable peer is a different topology.
Test From Outside, Then Test IPv6 Separately
Use an authorized remote client, such as a phone with Wi-Fi disabled, to test the actual application. An inside-LAN test of the public address may fail because NAT loopback, also called hairpin NAT, is unavailable, even when external access works. Conversely, a successful local test might use a different DNS answer and bypass the public path. Record which address and protocol the remote client actually used.
Native IPv6 generally routes to the server's globally routable IPv6 address rather than translating an IPv4 port forward. It still needs an appropriate router firewall rule and host firewall permission. A link-local address beginning fe80: is not an internet destination. Check service binding, the current delegated prefix, and the AAAA DNS record. A stale AAAA record can make an apparently correct IPv4 service fail for clients choosing IPv6.
RFC 6092 describes residential IPv6 filtering expectations. Do not disable IPv6 filtering wholesale. Allow only the necessary destination and service, and test from an IPv6-capable remote network; an IPv4-only client cannot directly reach an IPv6-only endpoint. Address or prefix changes also need to be reflected in DNS and any address-specific policy.
Use Failure Evidence to Choose the Next Action
- LAN fails: return to the listener, local route, and host/VLAN firewall. Changing WAN rules cannot repair this path.
- LAN works but external IPv4 fails: verify upstream NAT ownership, the public address, the exact TCP/UDP mapping, and available router rule counters or logs.
- External IPv4 works but the hostname fails: inspect A/AAAA answers, reverse-proxy routing, and TLS certificate names. Do not remove TLS verification to disguise a name mismatch.
- Remote access works but the application disconnects: examine application logs, return routing, session timeouts, and upstream connectivity; an open TCP port is not an end-to-end quality test.
- The approved path works: confirm an unrelated port or management interface remains denied, remove temporary forwards, and retain the saved configuration for rollback.
Evidence and Next Action
No ISP path or router was measured for this article. The examples explain how to locate a failure, not promise that a particular connection allows hosting. Before buying equipment, establish whether the first failed check is local service access, a router you control, an ISP policy, or IPv6 filtering. Keep diagnostics private, test only systems you are authorized to administer, and use a protected management path for subsequent changes.
Useful Gear And Buyer Notes
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
| Need | What to Evaluate | Buying Reference |
|---|---|---|
| Ethernet patch cables | Remove bad cabling from the troubleshooting path. | Amazon reference |
| VPN-capable router or firewall | Choose only after deciding whether you need an inbound VPN server or an outbound connection to a reachable peer; hardware alone does not remove CGNAT. | Amazon reference |
| MoCA backhaul kit | A wired backhaul can make the service stable after remote access is solved. | Amazon reference |
