Port Forwarding: The Four Things That Must All Be True

By LK Wood IV · 2026-09-18 · ~11 min read · St. Louis County, MO

A port forward is one line in a translation table. Traffic arrives at your router on a public port, the router rewrites the destination, and the packet goes to one machine inside your network.

That is the whole mechanism. The reason this page runs long is that the mechanism is almost never what fails. Four separate conditions have to hold at once, they fail independently, and every one of them fails silently. A port checker reports “closed” for all four.

One quick disambiguation before anything else, because two different things share this name. This page is about the rule in your router. If you came looking for ssh -L, ssh -R and -D, that is a different tool with different failure modes, and it lives in SSH port forwarding.

What the router is doing

Your home network runs on private addresses. Mine sits on 192.168.1.0/24, and addresses in that range are not routable on the internet by design. When my desktop opens a connection outward, the router replaces the private source address with the one public address it owns and remembers the swap, so the reply finds its way back.

That works because your machine started the conversation. The router has a table entry waiting for the reply.

An unsolicited packet from outside has no such entry. The router receives it, finds nothing that explains where it should go, and drops it — no security feature was switched on to make that happen. The address translation simply has no answer to the question.

A port forward supplies the missing answer in advance. You tell the router that anything arriving on TCP 32400 belongs to 192.168.1.40, permanently, whether or not that machine asked for it.

So the rule you write has four parts: the external port, the internal address, the internal port, and the protocol. Get any of them wrong and nothing tells you.

The four conditions

Every one of these has to be true. Check them in this order, because each one makes the next one worth testing.

1. Your line has a real public IPv4 address

This is the condition that ends the conversation for a growing number of people, and it is the first thing to check because you cannot fix it yourself.

Read the WAN address on your router’s status page. Then compare it with what a what-is-my-IP site reports.

If the two match, you have a real public address and this condition passes. If they differ, something upstream is translating your traffic, and the WAN address tells you which problem you have.

An address inside 100.64.0.0/10 means carrier-grade NAT. RFC 6598 reserves that range as Shared Address Space, assigned for service provider use to number the link between a CGN device and customer equipment. You share one public address with other subscribers. There is no port on it that belongs to you, so there is nothing to forward, and no setting in your router changes that.

Whether your provider will move you off it varies. On Spectrum’s own community forum, a verified employee answering one customer who asked to opt out of CG-NAT said there is no way to opt out, naming a static IP on a business account or a VPN as the two alternatives. That is one provider’s answer to one customer, so ask yours before planning around it. Hold on to the second half of that answer, because a tunnel out to somewhere with a public address is where this page ends up too.

An address in 192.168.x.x, 10.x.x.x or 172.16.x.x through 172.31.x.x, the three private ranges RFC 1918 sets aside, means double NAT instead: a second router upstream of yours, usually the ISP’s own gateway running in router mode with your equipment behind it. That one you can fix. Either put the ISP gateway into bridge or passthrough mode so your router holds the public address, or write the same forward twice, once on each device. Bridging is the better repair, because the second rule is a thing you will forget in a year. If you want to check whether a given address falls inside a private range, the subnet and CIDR calculator will tell you.

2. Exactly one device is doing the translating

Condition 1 finds the common version of this. The uncommon version is a router you forgot about: a mesh node in router mode rather than access-point mode, or a travel router still plugged in behind the main one.

The symptom is a forward that is configured correctly on the device you are looking at and lands on a device that is not the one holding the public address. Count the boxes between your machine and the wall.

3. The rule points at an address that does not move

Your router hands out LAN addresses by DHCP, and a lease expires. If the machine you forwarded to comes back on a different address after a reboot, your rule now points at whatever took its old one.

Fix it in the router rather than on the host. Assign a DHCP reservation that ties the machine’s MAC address to one LAN address permanently. A static address configured on the host itself works too, as long as it sits outside the DHCP pool, which is a detail people skip and then spend an evening on an address conflict.

4. The destination machine’s own firewall allows it

This is the one that catches experienced people, because the router configuration is visibly correct and the port still reads closed.

The router forwards the packet. The host receives it and drops it.

Microsoft documents the -DefaultInboundAction values for Set-NetFirewallProfile plainly: Block “blocks inbound network traffic that does not match an inbound rule”, and “the default setting when managing a computer is Block”. On my own Windows 11 desktop, reading the effective policy rather than the configured one, all three profiles agree:

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction

Domain    True   Block
Private   True   Block
Public    True   Block

Measured 2026-09-18 on Windows 11 Home build 26200. The ActiveStore part matters. Querying the default store on the same machine returns NotConfigured for all three, which reads like permissiveness and is not. The effective policy is Block.

So a forward into a Windows host needs an inbound rule on that host as well. Most server software adds one at install time. Anything you unzipped and ran by hand did not.

The automatic version, and why it keeps not working

Routers can open these rules on request, without you touching the admin page. Three protocols do it: UPnP IGD, NAT-PMP, and PCP, the last of which RFC 6887 defines as a way for a host to control how incoming packets are translated and forwarded by a NAT or a simple firewall.

When it works it is genuinely better than a hand-written rule, because the application asks for exactly the port it needs and gives it back afterwards.

It frequently does not work. Tailscale’s David Anderson, writing about NAT traversal in 2020, put the problem in one line: these protocols “might not be implemented on your devices. They might be disabled by default and nobody knew to turn them on.” He adds a detail worth knowing before you go looking for three separate settings, which is that “many devices come with a single ‘UPnP’ checkbox that actually toggles UPnP, NAT-PMP and PCP all at once.”

That single checkbox is also why the advice to disable UPnP for security is coarser than it sounds. Turning it off removes all three, including the two that never carried UPnP’s vulnerabilities.

My position: leave it off, and write the rule by hand. A permanent rule you wrote is one you can find again. A rule some application opened for itself is one nobody will ever audit, and the reason UPnP has the reputation it has is that malware on a LAN machine can ask for a forward exactly as politely as your game does.

IPv6 does not have port forwarding at all

On IPv6 there is no address translation, so there is nothing to translate. Every device on your network already holds a globally routable address. What stands between the internet and that device is your router’s firewall policy, and nothing else.

So the IPv6 equivalent of a port forward is a firewall rule, usually labelled a pinhole. You specify one address and one port, and you allow inbound traffic to it.

The default behaviour is genuinely vendor-dependent. RFC 6092, the recommendations document for residential IPv6 gateways, requires in REC-49 that a gateway “MUST provide an easily selected configuration option that permits a ’transparent mode’ of operation that forwards all unsolicited flows regardless of forwarding direction”, and then adds that “the transparent mode of operation MAY be the default configuration”. A conforming router can ship wide open or closed. Check yours rather than assuming.

Which address to open, and the one your port checker will hand you

Here is the part that costs people an evening, and it is measurable rather than theoretical.

A Windows machine does not hold one IPv6 address. It holds several at once, for different jobs. On my wired desktop, on a Charter line, I read the interface on 2026-09-18:

Get-NetIPAddress -InterfaceAlias 'Ethernet 2' -AddressFamily IPv6 |
  Select-Object IPAddress, PrefixOrigin, SuffixOrigin, AddressState, PreferredLifetime

That returned eight addresses. Four were link-local and unique-local, which never reach the internet and are not what a pinhole targets. The other four were globally routable under the ISP’s delegated prefix, and those are the rows below. They appear as truncated SHA-256 hashes, because the addresses themselves identify the line:

On this machine the two marked Random are the two that ipconfig /all labels Temporary IPv6 Address, and I am reading the mapping off that correlation rather than off the property name. Random does not by itself mean temporary: a stable SLAAC address also reports a randomized suffix on a host configured for it. The Link row above is what tells me this box is not doing that. Check the ipconfig labels on your own machine instead of trusting the mapping.

Temporary addresses exist so that the address a remote server sees cannot be used to follow your machine around. RFC 8981 describes them as “typically employed for initiating outgoing sessions” and used “for a short period of time (typically hours to days)” before being deprecated, with a default preferred lifetime of one day. My desktop’s own setting agrees: netsh interface ipv6 show privacy reports a maximum preferred lifetime of 1d.

Now the two measurements that make this concrete.

Windows sends outbound traffic from the temporary address. Asking the routing stack which source it would pick for a remote IPv6 host, without sending anything:

Find-NetRoute -RemoteIPAddress 2001:4860:4860::8888

It returned 8c54b72251e1, the Preferred Random one. That is the documented default, not a quirk: RFC 6724 Rule 7 says “if SA is a temporary address and SB is a public address, then prefer SA.”

The temporary addresses really do go away, and the stable ones really do not. I read the same interface four days earlier, on 2026-09-14. The temporary address that was Preferred then, and that Windows was using as its source, is now not on the interface at all. Meanwhile 51d7bac62b7c and 3e69fab27a83, the stable SLAAC address and the DHCPv6 address, are the same two addresses they were four days ago, across a reboot in between.

That is the rule, measured on one line rather than quoted from a standard: the addresses ipconfig labels Temporary are the ones that disappear, and the plain IPv6 Address and DHCPv6 lines are the ones a firewall rule should name.

Which brings me to the part that makes this a trap rather than a curiosity. The obvious way to find out your own IPv6 address is to ask a website, and port-checking tools offer exactly that: yougetsignal’s open-ports page has a “Use Current IP” control, and it was in Bing’s top ten for “port forwarding” when I searched on 2026-09-18. Loaded from this desktop, that control pre-filled an IPv6 address. On 2026-09-14 it offered the temporary address current that day. On 2026-09-18 it offered 8c54b72251e1: the new temporary address, the same one Find-NetRoute had just picked and the same Preferred Random row from the table above.

On both days I checked, it offered the temporary address and neither of the two stable ones. That is not a flaw in one tool. Any site that reports “your IP” can only report the address your connection arrived from, and Rule 7 above is what makes that the temporary one. So the entire category of what-is-my-IP controls will hand you the wrong address for this particular job, and the better the tool is at its actual job the more reliably it does so. Ask your own machine instead.

Copy that into a router firewall rule and the rule works. It works for hours — long enough to close the admin page and call the job done. Then the address behind it is retired, the rule points at nothing, and the thing you are running stops answering with no configuration having changed.

When to stop forwarding entirely

There is a decent case that most people reading this should not write the rule at all.

A forward is still the right tool in a few places. A self-hosted WireGuard endpoint needs exactly one forwarded UDP port and gives you an encrypted path to everything behind it, which is one rule instead of one per service. A game server for friends is a reasonable use. So is anything already designed to face the internet.

Everywhere else, an overlay network has quietly become the better answer, because it satisfies condition 1 by refusing to depend on it. Both ends dial outward, so CGNAT stops being a problem instead of being an obstacle, and nothing on your router is open. That is the decision covered in Tailscale vs WireGuard, and neither Tailscale nor a Cloudflare Tunnel needs an inbound port. The cost is client software on whatever is connecting, which is the one thing a forwarded port never demands, and it is why the answer is not unanimous.

If your ISP gateway turns out to have no usable forwarding table or no IPv6 firewall controls at all, which is common on carrier-supplied hardware, the fix is your own router behind it in bridge mode. The Wi-Fi 7 router picks cover that purchase with current pricing.

And if what you wanted was to reach one media server from outside, the service-specific version of this decision is worked through end to end in Jellyfin remote access, including why forwarding its plain HTTP port is the one setup nobody should copy.

What I measured and what I did not

The Windows figures here are first-hand, from read-only commands on my own wired desktop: Windows 11 Home build 26200, Charter line, captured 2026-09-14 and again 2026-09-18. The IPv6 addresses appear only as truncated hashes because the addresses identify the connection. The prefix owner comes from ARIN’s registry, which returns Charter Communications LLC for that block.

Three things are outside what I tested, and they change what you should trust.

I did not read the router. That means I cannot tell you whether this line is behind CGNAT, and I cannot tell you what this router does with unsolicited inbound IPv6. Both are exactly the things the sections above tell you to go and check yourself, and I am following my own instruction rather than guessing.

I did not press the port checker’s test button. Watching which address it pre-fills is reading the page; running its scan submits a probe against the operator’s own address to a third party. So the address it offers is measured, and whether its test runs over IPv6 is not something I checked.

The disappearance of that temporary address has two possible causes I cannot separate, since the four-day window contained both a reboot and several preferred lifetimes. Either retires a temporary address and neither touches the stable pair, so the advice is the same, but I am not going to claim a mechanism I did not isolate.

Sources

• https://www.rfc-editor.org/rfc/rfc1918.html
• https://www.rfc-editor.org/rfc/rfc6598.html
• https://www.rfc-editor.org/rfc/rfc6092.html
• https://www.rfc-editor.org/rfc/rfc6724.html
• https://www.rfc-editor.org/rfc/rfc6887.html
• https://www.rfc-editor.org/rfc/rfc8981.html
• https://learn.microsoft.com/en-us/powershell/module/netsecurity/set-netfirewallprofile
• https://learn.microsoft.com/en-us/windows/win32/fwp/wmi/nettcpipprov/msft-netipaddress
• https://learn.microsoft.com/en-us/powershell/module/nettcpip/find-netroute
• https://tailscale.com/blog/how-nat-traversal-works
• https://community.spectrum.net/discussion/172901/opt-out-of-carrier-grade-nat-cg-nat