Port forwarding not working? Test every link in the chain

You added the rule. External port 25565, internal 192.168.1.40, TCP, enabled. You saved it, you rebooted the router twice, and your friend still cannot connect. Port checking websites say the port is closed. Everything looks right and nothing works.

Port forwarding fails for about seven distinct reasons, and they produce nearly identical symptoms. The only way through is to test each link in the chain separately, from the inside out, and stop at the first one that fails. Here is that chain.

The chain a connection has to survive

For someone on the internet to reach a service in your house, every one of these has to be true:

1. The service is running and listening on the port you think it is.
2. The host's own firewall allows inbound connections on that port.
3. The device has the internal IP address the forwarding rule points at, and that address has not changed.
4. The router's rule is correct: right protocol, right internal address, right port, enabled.
5. Your router holds a real public IP address, not a private one handed to it by another device or by your ISP.
6. Your ISP is not blocking that port.
7. There is only one NAT layer between the internet and the device.

Seven conditions. Most guides check number four and stop, which is why so many people end up convinced their router is broken.

Test it in this order

1. Is the service even listening?

   From another device on the same network, connect to the internal address and port directly. The TCP/UDP Connect tool does exactly this: give it 192.168.1.40 and port 25565 and see whether the connection opens. If this fails, nothing else matters. The application is not running, it is bound to localhost only, or the host firewall is blocking it. Stop here and fix that first.

2. Confirm the internal IP has not moved

   DHCP leases expire. A device that was 192.168.1.40 in January can be 192.168.1.57 in March, and your forwarding rule still points at the old address, which may now be someone's tablet. Run a LAN Scan to see what is actually where, then set a DHCP reservation so it stops moving.

3. Check what your public IP really is

   Open Public IP and Geo/ASN and note the address. Then log into your router and look at its WAN address. If these two do not match, port forwarding on that router cannot work, because your router is not the device the internet is talking to. This one check explains a huge share of failures and takes ten seconds.

4. Ask the outside world to connect back

   This is the test that actually matters, and it cannot be done from inside your own network. External Port Check asks a server on the internet to open a connection to a port on your public IP and reports what happened. Open means the whole chain works. Closed means something refused. Filtered or timed out means something silently dropped it, which usually points at a firewall or at CGNAT.

5. Ask the router what it thinks it is doing

   UPnP and NAT-PMP discovery queries the gateway and, when supported, reports the external IP address the gateway believes it has. If the gateway reports a private address there, you have confirmed double NAT or carrier grade NAT without logging into anything.

# 1. Does the service answer on the LAN?
https://netdebug.app/open/portconnect?target=192.168.1.40&port=25565&protocol=tcp

# 2. What does the internet see when it connects back to me?
https://netdebug.app/open/reachme?port=25565

# 3. What does my gateway think its external address is?
https://netdebug.app/open/upnp

CGNAT: the reason it may be impossible

Carrier grade NAT is the most common reason a perfectly configured forwarding rule does nothing, and most people have never heard of it.

IPv4 addresses ran out. Rather than give every customer a public address, many providers now put thousands of customers behind one shared public IP. Your router gets an address from a private range, your traffic gets translated again at the provider's equipment, and inbound connections have nowhere to be delivered. Outbound works perfectly, so nothing feels wrong until you try to host something.

How to spot it: compare your router's WAN address against your actual public IP. If the router's WAN address falls in one of these ranges, you are behind another NAT:

Range	Meaning
100.64.0.0 to 100.127.255.255	Carrier grade NAT. Reserved specifically for this. A very strong signal.
10.x.x.x	Private. Either CGNAT or another router in front of yours.
192.168.x.x	Private. Almost always a second router or an ISP modem in router mode.
172.16.x.x to 172.31.x.x	Private. Same story.

If you are behind CGNAT, no router setting will fix it. Your options are to ask your ISP for a public IP address (often available, sometimes for a small fee, sometimes called a static or business IP), to use IPv6 if both ends support it, or to use a relay service such as a tunnel or a mesh VPN that establishes connections outbound from both sides.

Double NAT

The domestic version of the same problem. Your ISP supplied a combined modem and router, and you plugged your own router into it. Now there are two devices doing NAT, and forwarding a port on the inner one gets you nowhere because the outer one never sends the traffic along.

The fix is one of three things: put the ISP device into bridge or modem mode so your router receives the public address directly, set up a matching forwarding rule on both devices, or configure the ISP device to send all unsolicited inbound traffic to your router's address. Bridge mode is the cleanest, and most ISP devices support it even if the option is buried.

The other usual suspects

The host firewall

Windows Defender Firewall blocks inbound connections by default, and it has separate rule sets for private and public network profiles. A machine that decided it was on a "public" network will refuse connections it would otherwise allow. On Linux, check iptables or nftables. On a Mac, check the application firewall.

The service is bound to localhost

Many applications listen on 127.0.0.1 by default, which means they accept connections only from the machine itself. It works when you test locally and fails from everywhere else. The configuration usually needs to be 0.0.0.0 or the machine's LAN address.

TCP forwarded, UDP needed

Game servers, voice servers, VPN endpoints and DNS often need UDP, sometimes as well as TCP. A rule that only covers TCP will half work in a way that is genuinely confusing: the connection establishes and then nothing happens. Check what your service needs, and test with the right protocol.

The ISP blocks the port

Port 25 is blocked almost universally to limit spam. Ports 80 and 443 are frequently blocked on residential plans. Some providers block 445 and 137 through 139 for security reasons. If a high, unusual port works and a well known one does not, that is the signature. Moving the service to a non standard port is usually the fastest workaround.

Your public IP changed

Most residential connections have dynamic addresses. The rule still works, but whoever is connecting is using an address that now belongs to someone else. Dynamic DNS solves this permanently.

Why testing from inside your own network lies to you

If you connect to your own public IP from inside your own network, you are asking the router to send a packet out and immediately bring it back in. This is called NAT loopback or hairpinning, and plenty of routers do not support it. The test fails even though everything is configured correctly, and you spend an hour fixing something that was never broken.

The reverse trap is worse: some routers handle loopback fine, so the test succeeds from inside while the outside world still cannot reach you. Either way, an inside test tells you nothing reliable.

The only meaningful test comes from outside. That means a port checking service, a friend on a different network, your phone on cellular data with Wi-Fi turned off, or a tool like External Port Check that has a server on the internet do the connecting for you.

The short version

Work outward, not inward. Confirm the service answers on the LAN, confirm the internal IP has not drifted, then compare your router's WAN address with your real public IP. If those two differ, stop configuring and start dealing with double NAT or CGNAT, because nothing else you do will help. And never trust a test run from inside your own network.