Port forwarding sends selected incoming traffic from a router’s public side to a service on your LAN. It needs a working service, a stable LAN address, matching protocol, and permitted traffic at every firewall and NAT boundary.
Start with the service, not the router
Confirm that the application is running and listening on the intended interface and port. A listener bound only to 127.0.0.1 is local to that computer. First test from another device on the LAN using the server's LAN address. Then inspect the host firewall for a narrowly scoped rule that permits the intended service.
Assign a DHCP reservation or a documented static LAN address so the router rule does not later point at another device. Keep the service updated and enable its authentication before making it Internet-reachable.
Write one explicit forwarding rule
For an illustrative TCP service, the rule could map WAN TCP port 8443 to 192.168.1.50 TCP port 443. The external and internal ports can differ when the router supports it. Confirm that the application actually expects that arrangement and that remote clients use the external port.
- Select TCP, UDP, or the specific combination the application requires.
- Enter the reserved destination LAN address.
- Map only the required port or small range.
- Restrict source addresses if the router and use case support it.
Changing the external port does not replace authentication or patching. Avoid broad DMZ exposure and review automatically created UPnP mappings if your router permits them. A public administration interface or remote desktop service often deserves a private-access design instead of direct exposure.
Test from outside the LAN
A mobile connection with Wi-Fi disabled or another external network provides a useful comparison. Some routers do not support hairpin NAT, so testing your own public address from inside the LAN can fail even when external access works. Conversely, a successful local connection says nothing about the WAN rule.
This site's port checker tests TCP reachability on your observed public address. It does not test UDP services, authenticate to the application, or prove that the service is secure. An open result describes one connection attempt at that time.
If it still fails, follow the path
Compare the router WAN IPv4 with your public IPv4. Investigate double NAT or CGNAT if there is another upstream boundary. Check ISP restrictions, router logs, host firewall logs, and whether the application stopped listening.
For IPv6, configure the intended inbound firewall permission and reachable address rather than assuming an IPv4 NAT rule applies. Document every exposure you create and remove it when no longer needed. Retest after a router change, public-IP change, or server migration.
Put it into practice
References & further reading
Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.