To fix NAT configuration issues, first confirm whether your router holds a real public WAN address, then check for double NAT, verify the NAT type reported by your device, and correct port forwarding rules. If the WAN IP is private, your ISP is using CGNAT and inbound services will need a workaround.
Symptoms
- Online games report Strict or Type 3 NAT and party chat, matchmaking, or voice fails intermittently.
- Port forwarding rules are saved in the router but external port checks still show the port as closed.
- Remote desktop, VPN, or self-hosted services are unreachable from outside the LAN despite correct firewall rules.
- VoIP calls connect but audio is one-way, drops after 30 seconds, or registration flaps.
- Traceroute to a public IP shows two or more private-range hops before reaching the ISP.
Common Causes
Double NAT from stacked routers
A modem-router combo in front of your own router translates traffic twice. Inbound sessions die at the outer device because it has no forwarding rule for the inner LAN.
Carrier-Grade NAT (CGNAT) on the WAN
The ISP hands out a private WAN address (100.64.0.0/10 or 10.x) and shares one public IP across many customers. You cannot open inbound ports without an ISP-side change or a tunnel.
Incorrect or stale port forwarding rules
Rules point to the wrong internal IP, use the wrong protocol (TCP vs UDP), or target a host whose DHCP lease changed. The router forwards packets into a black hole.
Overlapping private subnets
When the LAN and a VPN or upstream network use the same range (often 192.168.1.0/24), the router cannot decide where to send return traffic and NAT sessions break.
Firewall or ALG interference
SIP ALG, SPI firewalls, or aggressive connection-tracking timeouts rewrite or drop translated packets. This is a common cause of one-way VoIP audio and dropped game sessions.
Step-by-Step Fix
- Confirm the WAN address is actually public
Log into the router and read the WAN IP on the status page. Compare it to the address shown by an external site like ifconfig.me. If they differ, or the WAN IP falls in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 100.64.0.0/10, you are behind CGNAT or an upstream router. - Detect double NAT with a traceroute
From a client on the LAN, run tracert 8.8.8.8 on Windows or traceroute 8.8.8.8 on macOS and Linux. A healthy path shows one private hop (your router) then public hops. Two private hops before the first public address confirms a second NAT device upstream. - Collapse double NAT to a single device
Put the ISP modem-router into bridge or pass-through mode so your own router receives the public IP directly. If bridging is not available, enable DMZ on the outer device pointing to the inner router's WAN, or disable NAT on one of the two units and let the other handle it. - Fix port forwarding with a reserved internal IP
In the router's DHCP settings, create a static reservation for the target host by MAC address. Then add the forwarding rule using that reserved IP, the exact port, and the correct protocol. Many services (game servers, WireGuard, SIP) need UDP, not TCP. - Verify the rule from outside the network
Never test port forwarding from inside the LAN, since NAT loopback often masks failures. Use a mobile hotspot or an external port scanner against the WAN IP. If the port still shows closed, the rule, the host firewall, or CGNAT is blocking it. - Disable SIP ALG and similar helpers for VoIP
For one-way audio or dropping calls, turn off SIP ALG, SIP transformations, and any application-layer gateway on the router. These features rewrite SIP headers and RTP ports and usually break modern VoIP more than they help. - Resolve overlapping subnets
If your LAN uses 192.168.1.0/24 and a remote VPN uses the same range, renumber the LAN to something uncommon such as 192.168.37.0/24 or 10.42.7.0/24. Update DHCP scope, static reservations, and any hard-coded references before reconnecting the VPN. - Work around CGNAT when inbound access is required
If the ISP uses CGNAT, request a public IPv4 address (some ISPs offer it on request or as a paid option), enable IPv6 and expose the service over IPv6, or use an outbound tunnel such as a reverse proxy, WireGuard to a VPS, or a Zero Trust connector.
Common NAT symptoms mapped to likely cause and first fix
| Symptom | Likely cause | First action |
|---|---|---|
| Strict NAT in game console | Double NAT or UPnP disabled | Bridge outer router or enable UPnP on inner router |
| Port forwarded but shows closed externally | Wrong internal IP or protocol | Reserve host IP; verify TCP vs UDP; retest from outside LAN |
| One-way VoIP audio | SIP ALG rewriting RTP | Disable SIP ALG and SIP transformations on the router |
| WAN IP starts with 100.64 | Carrier-Grade NAT | Request public IP, use IPv6, or deploy an outbound tunnel |
| VPN clients cannot reach LAN hosts | Overlapping subnets | Renumber LAN to a less common private range |
| Sessions drop after idle period | Short NAT translation timeout | Increase UDP/TCP session timeouts or enable keepalives |
Prevention
- Document every port forwarding rule with service name, host, and protocol so stale entries are easy to spot.
- Use static DHCP reservations for any host that receives forwarded ports or hosts a service.
- Prefer a single router in routed mode; put ISP gear in bridge mode wherever possible.
- Test external reachability from outside the LAN after any firmware update or ISP change.
FAQ
How do I know if I am behind CGNAT?
Compare the WAN IP shown in your router to the public IP reported by an external site. If your router's WAN address falls inside 100.64.0.0/10, or you see two private hops before reaching a public address in traceroute, you are behind Carrier-Grade NAT. In that case inbound port forwarding on your router alone cannot make services reachable from the internet.
Is UPnP safe to enable to fix strict NAT?
UPnP resolves most strict NAT complaints for games and VoIP by letting applications open their own ports on demand. The trade-off is that any device on the LAN can request a mapping, so a compromised host could expose itself. Enable it on trusted home networks, but prefer explicit port forwarding on business or lab networks.
Why does port forwarding work from my phone on mobile data but not from a browser on the LAN?
That is NAT loopback (hairpinning) behaviour. Many consumer routers do not translate a request from an internal client to the WAN IP back to the internal server. Test forwarding from an external connection, and use the internal IP or split DNS when accessing the service from inside the LAN.
Need help auditing your NAT and firewall configuration? Contact our network team for a structured review.