The router has a rule for TCP port 443. The server opens normally from a laptop in the office. From a phone on mobile data, the connection times out.
Port forwarding can fail because the service is not listening on the intended interface, a firewall blocks it, upstream address translation prevents the request reaching your router, or the reply takes an incompatible path. First test the service on its local address, then compare the router’s internet-facing address with its observed public address and test from a separate connection. A rule covers one hop, not the whole exchange.
Prove the service works beyond localhost
Start inside the local area network (LAN). Connect to the server’s actual LAN address from another machine using the intended protocol and port. A page that opens at localhost on the server proves less than it seems: the application may be listening only on the loopback interface.
Confirm the listener, host firewall rule and target address. If the router forwards to 192.168.20.15, verify that this is still the intended server. A Dynamic Host Configuration Protocol (DHCP) address change can silently send the rule to a different device. A reservation or an appropriately managed static address gives the mapping a target you can maintain.
Keep the test narrow. Allow the required service and test source where possible. Disabling the firewall or forwarding every port makes the exposure larger while throwing away the evidence that tells you which rule was needed.
Check the WAN address for upstream NAT or CGNAT
Read the wide area network (WAN), or internet-facing, address shown by the router. Then compare it with the IPv4 source reported by an external service from that connection. Make sure you are comparing IPv4 with IPv4; a browser may prefer IPv6.
A WAN address in 100.64.0.0/10 suggests carrier-grade network address translation (CGNAT). This is shared provider address space, separate from the familiar private ranges. RFC 6598 defines its use on service-provider networks. A private WAN address such as 10.0.0.8 can indicate another upstream router or provider translation.
If the WAN address and the observed public IPv4 differ, investigate the upstream hop. You might control a second router and need an approved rule there. You might be behind an ISP’s NAT, where your router cannot create the required public mapping. An address comparison is a useful clue, not a substitute for confirming the connection arrangement with the provider.
Even a globally routable-looking WAN address is not proof that unsolicited inbound traffic is delivered. Ask whether the service permits hosting, whether ports are restricted, and whether the address is actually routed to this connection.
Test externally and trace the request and reply
Use a separate internet connection. Testing the public address from inside the same LAN may depend on a router’s NAT loopback behavior. A successful local test and a failed external test are different observations.
Check the hostname’s current address too. A stale DNS record can send the request elsewhere. For HTTPS, keep the hostname in the test so certificate and application routing behavior remain meaningful.
With authorization to inspect the systems, look for the test connection at successive boundaries: router, forwarding gateway and target. Record the time, source, destination and port. Capture only the headers and traffic necessary for diagnosis; avoid collecting credentials or unrelated application data.
If the request reaches the target and a reply leaves it, inspect the return path. Translation is stateful in common gateway designs. The nftables reference documents destination and source NAT as distinct operations. A saved mapping alone does not demonstrate a complete application exchange.
Choose a remedy that matches the audience
For a team-only resource, private access may remove the need for a public listener. For a public service, an ISP-provided address with supported inbound routing can be perfectly suitable. A service-specific publishing arrangement can also fit an HTTP application, subject to its supported scope.
Fibmesh Public IPs provides another delivery model: a public address reaches supported infrastructure over WireGuard, either directly on a supported device or through a gateway arrangement. The access ISP’s NAT for the tunnel is a separate boundary from the public address delivered inside it. Confirm the platform, address family, inbound rules and reply routing for the deployment.
The useful result of troubleshooting is a precise statement: the application is listening, the public path reaches the intended boundary, the permitted request arrives, and the response completes. Once you know which statement fails, the next configuration change has a purpose.
Prepare and verify a Public IPs deployment →
