Port forwarding usually fails for one of five reasons: wrong internal IP, mismatched protocol (TCP vs UDP), a blocking firewall on the target device, carrier-grade NAT on the WAN side, or double NAT from a second router. Fix it by assigning a static internal IP, rewriting the rule, and testing the port from outside your network.
Symptoms
- External clients cannot reach the service, but it works fine on the LAN.
- Online port checkers report the port as closed or filtered.
- Game or app shows Strict/Type 3 NAT despite a forwarding rule being set.
- Rule appears saved in the router, yet no traffic reaches the host.
- Connection worked previously and stopped after a router reboot or firmware update.
Common Causes
Wrong or changing internal IP
The rule points to an IP the host no longer holds. DHCP handed the device a new address after reboot, so the forwarded traffic lands on nothing.
Protocol mismatch (TCP vs UDP)
Many services need UDP (game servers, WireGuard, SIP) but the rule forwards TCP only. Choose the exact protocol the application uses, or forward both.
Local firewall blocking the port
Windows Defender Firewall, ufw, or a security suite drops inbound packets before the app sees them. The router forwards correctly, the host refuses the connection.
CGNAT on the ISP side
On mobile and many fibre plans your WAN IP is private (100.64.0.0/10). No inbound port forwarding is possible without a public IP or a relay like Tailscale Funnel or Cloudflare Tunnel.
Double NAT from stacked routers
An ISP modem-router runs NAT, and your own router runs NAT again. The rule on the inner router is invisible to the outside world.
Step-by-Step Fix
- Confirm the host's LAN IP and lock it with a DHCP reservation
Run ipconfig on Windows or ip a on Linux/macOS to read the current IPv4. Then open the router's DHCP settings and bind that IP to the device's MAC address. This stops the address from changing after reboot and breaking your rule. - Verify the service is actually listening on the expected port
On the host, run netstat -ano (Windows) or ss -tulpn (Linux) and confirm the application is bound to 0.0.0.0 or the LAN IP, not 127.0.0.1. A service listening on localhost only will never accept forwarded traffic. - Create the router rule with the correct protocol
In the router admin UI, open Port Forwarding or Virtual Server. Set external port, internal port, internal IP, and protocol. If unsure whether the app uses TCP or UDP, check the vendor docs. Save and, if the router requires it, reboot. - Allow the port through the host firewall
On Windows, open Windows Defender Firewall with Advanced Security and add an inbound rule for the port and protocol. On Linux, use sudo ufw allow 25565/tcp or the equivalent firewalld command. Test again after applying. - Rule out CGNAT before troubleshooting further
Compare your router's WAN IP with the public IP shown at a site like ifconfig.me. If they differ, or your WAN IP starts with 100.64–100.127, you are behind CGNAT. Ask the ISP for a public IPv4, use IPv6, or route the service through a tunnel provider. - Eliminate double NAT
Log into the upstream device (usually the ISP modem-router). Put it into bridge or modem-only mode so your router receives the public IP directly. If bridging is unavailable, add a matching forwarding rule on both devices and place your router in the modem's DMZ. - Test the port from an external network
Use a phone on mobile data or an external port checker to probe your WAN IP on the forwarded port. Testing from inside the LAN via the public IP fails on many routers due to NAT loopback limits and produces false negatives. - Disable UPnP if manual rules conflict
If UPnP is enabled, applications may map the same external port dynamically and override your static rule. Turn UPnP off in the router, delete stale mappings, then re-add your manual rule.
Common port forwarding symptoms mapped to cause and fix
| Symptom | Likely cause | Action |
|---|---|---|
| Port shows closed from outside, open on LAN | Wrong internal IP or DHCP reassigned it | Set a DHCP reservation and update the rule |
| Works on TCP tools, fails for game clients | Protocol mismatch | Change rule to UDP or forward both protocols |
| Public IP starts with 100.64–100.127 | Carrier-grade NAT | Request public IPv4 or use a relay/tunnel |
| Two routers in the path | Double NAT | Bridge the upstream device or use DMZ |
| Rule saved but overwritten | UPnP auto-mapping | Disable UPnP, clear mappings, reapply rule |
| Connection reaches host then drops | Host firewall blocking inbound | Add inbound firewall rule for the port |
Prevention
- Always use a DHCP reservation or static IP for any host you forward ports to.
- Document every rule with a clear label so old entries do not collide.
- Prefer application-layer tunnels (WireGuard, Tailscale) over open inbound ports where possible.
- Review forwarded ports quarterly and remove rules for services no longer in use.
FAQ
How do I know if my ISP is blocking the port?
Test the same port from a device connected directly to the modem, bypassing your router. If it still fails and your setup is otherwise correct, contact the ISP. Common blocks include TCP 25 (SMTP), 80, 443, and 445 on residential plans. Ask specifically whether the port is filtered or whether you are on CGNAT.
Should I forward TCP, UDP, or both?
Match the protocol the application actually uses. HTTP, SSH, and RDP are TCP. Most real-time games, DNS, WireGuard, and VoIP are UDP. Some services use both, for example Minecraft Bedrock. When the vendor documentation is silent, forward both and narrow it down once the connection works.
Is port forwarding safe to leave enabled long-term?
Any open inbound port increases exposure, so keep the surface minimal. Forward only the exact ports needed, run current software on the target host, use strong authentication, and restrict source IPs in the router firewall when possible. For remote access, a VPN or zero-trust tunnel is generally preferable to permanent port exposure.
Need help auditing your router, NAT topology, or firewall rules? Contact our IT support team for a configuration review.