Home networks # Troubleshoot port forwarding without a scanner Check the service, local firewall, forwarding rule, and upstream NAT before trying an external connection. 4 minute read · Published October 11, 2026 ## Start with the service inside your network A forwarding rule cannot make a stopped service reachable. Confirm that the application is running and listening on the expected port and interface. A service bound only to 127.0.0.1 accepts local connections but is not reachable from another device through the LAN address. Then try the application from another device on the same LAN using the server’s private address. Check the server firewall for that application and port. Keep the test specific; opening every port or disabling the whole firewall makes the diagnosis harder and exposes unrelated services. ``` # On the Linux machine hosting your service: # inspect listening TCP sockets; this sends no network probes ss -ltn ``` ## Worked example: external 8443 to internal 443 Imagine an HTTPS service on 192.168.1.50:443, with the router forwarding external TCP 8443 to internal TCP 443. An outside client must use port 8443, not 443. The forwarding destination must remain 192.168.1.50; a DHCP reservation prevents a later address change from sending connections to the wrong device. First verify that the service responds locally. Then confirm the router rule says TCP, targets the correct LAN address, and maps the two ports in the intended direction. The HTTPS certificate must also match the hostname you actually use; a TLS warning is a different problem from an unreachable port. ## Check the path beyond your own router The connection page includes a local WAN-address comparison: copy the router’s WAN/Internet IPv4 and compare it with the public IPv4 from the same network and time. The input stays in the browser and no connection is made to the entered address. Private or shared space is a useful clue; a mismatch alone is not proof of CGNAT. - A private WAN address may indicate a second router that also needs a forwarding rule, or an ISP gateway you need to reconfigure with its administrator. - A WAN address in 100.64.0.0/10 suggests provider shared address space. Ordinary port forwarding on your router cannot create an inbound mapping at the ISP’s NAT. - Check whether your ISP restricts incoming connections or offers a public address option. - For IPv6, inspect the destination’s IPv6 address and the router and host firewall rules. An IPv4 forwarding rule does not configure IPv6 access. - When you control the destination and intend to expose the service, test the actual application from a separate network. A test from inside the same LAN can depend on NAT loopback support. ## What a port result would leave unanswered An accepted TCP connection would only show reachability from one source at one time. It would not establish that the application works correctly, its certificate is valid, or the service is secure. A timeout cannot distinguish a stopped host, filtering, routing trouble, and a missing forwarding rule. myip.dk does not initiate port probes toward your address. This checklist helps you gather the configuration evidence first and avoids treating an ambiguous “closed” result as a diagnosis. ## Further reading & sources - [RFC 6598: shared address space and carrier-grade NAT ↗](https://www.rfc-editor.org/rfc/rfc6598) - [RFC 4787: NAT behavior and hairpinning ↗](https://www.rfc-editor.org/rfc/rfc4787) - [Linux kernel: IP networking behavior ↗](https://docs.kernel.org/networking/ip-sysctl.html) [← Browse all guides](https://myip.dk/guides)[Check your connection →](https://myip.dk/) ---