Port Forwarding and NAT Type

Find out which of three problems you have before configuring anything. Compare the address your router shows on its internet side against your actual public address — that one comparison separates a five-minute fix from something you cannot fix at all.

Same warning, three causes: your router is not forwarding, there are two routers in the way, or your provider is sharing one address among many customers.

A note on this guide: this rests on how address translation works rather than on routers tested here. See how we test.

The problem, as it appears

A game reports a strict or moderate NAT type. Hosting does not work, voice chat is unreliable, and matchmaking puts you with fewer people.

Everything else is fine — pages load, downloads are quick — which makes it look like a game problem.

Why the guides disappoint

Because nearly all of them assume the first cause and skip straight to configuration.

NAT type is a description of one thing: how easily another machine can open a connection to you. Outbound works in every case, which is why nothing else on the connection seems wrong.

But three quite different situations produce that same result:

1. Your router is not forwarding. Ordinary, and entirely yours to fix.
2. Two routers in series. A provider's combined box with your own router behind it, each doing its own translation — so a forward configured on the inner one never sees the traffic arrive.
3. Carrier-grade NAT. Your provider is sharing a single public address among many customers. There is no port on that address that belongs to you, and nothing you configure at home changes it.

Following a port-forwarding guide while in situation two or three produces a correct configuration that does nothing, and hours spent doubting the steps.

What actually matters

The comparison that identifies which one

Two numbers, five minutes, and it settles the question.

Look at the address your router reports on its internet-facing side — usually labelled WAN or Internet on its status page. Then look up your public address with any external service.

• They match. Situation one. Forwarding on your router is the whole job.
• The router shows a private address — beginning 10., or 192.168., or in the 172.16 to 172.31 range. Situation two: something else is in front of it.
• The router shows an address in the 100.64 to 100.127 range. Situation three. That range is reserved for exactly this purpose, and it is your provider telling you plainly.

That third result is the useful one, because it stops the work before it starts.

Double NAT: bridge, do not layer

If a provider's box sits in front of your router, the clean fix is to put it into bridge or modem-only mode so it stops translating and your router holds the public address.

The alternative — forwarding the same ports on both devices — works and leaves you maintaining two configurations that must agree. It is worth doing only when the outer device cannot be bridged, which some provider hardware genuinely cannot.

Carrier-grade NAT is not yours to solve

Worth accepting quickly rather than fighting.

Your options are asking the provider for a public address, which some supply on request and some treat as a paid extra, or using a relay or tunnel service that gives you a reachable address somewhere else and connects it back to you.

Both are real answers. Neither is a router setting, and no amount of reconfiguring will substitute.

The forward needs a target that stops moving

The most common reason a working forward stops working.

Forwards point at an address, not at a device. When your machine's lease expires and it comes back with a different one, the router keeps sending traffic to the old address — which now belongs to something else, or to nothing.

Fix it with a reservation in the router's DHCP settings so it always hands that machine the same address. Setting a static address on the machine itself works until the router hands the same address to something else, because it was never told.

UPnP is a convenience with a posture cost

It does work. It lets a game or a console ask the router to open what it needs, without you knowing what those are.

Which is the cost: anything on your network can open a port, including things you did not install deliberately. For a household of trusted devices that is a reasonable trade; as a permanent default it means you no longer know what is reachable from outside.

Explicit forwards for the two or three things that need them are more work and more predictable.

Wire the machine first

A forward pointing at a device on marginal wi-fi produces a service that answers unreliably, and that gets blamed on the forwarding rather than on the path.

Hosting anything is the case where a wired connection stops being a preference, because it removes both the variability and the address instability that come with roaming between bands.

This page contains affiliate links. If you buy through them, Ugly Fixes may earn a commission at no extra cost to you. Products are selected independently.

Where a cable genuinely cannot go, the alternatives are not equivalent, which is the argument in powerline vs mesh vs ethernet.

Rule out the boring physical faults

A marginal cable produces errors and retransmissions rather than an obvious failure, and an intermittent service looks exactly like a configuration problem.

Finding a cable that is failing quietly rather than completely is covered in finding the bad ethernet cable.

IPv6 sidesteps the whole model

There is no address translation in IPv6, so there is nothing to forward. Each device has its own address, and the question becomes whether the router's firewall allows inbound traffic to it.

Where a service supports it, that can route around a carrier-grade NAT problem completely — which makes "does this work over IPv6" a worthwhile question before pursuing a paid public address.

It does not make anything faster

Worth stating because it gets bundled into performance advice. Forwarding changes what can reach you; it does not change how long anything takes to arrive.

Latency is a separate subject with separate causes, and the things people reach for there are mostly aimed at the wrong end of the problem — the argument in what a VPN does to game latency.

The order to work in

1. Compare the router's WAN address with your public address.
2. If they differ, identify which of the two reasons it is from the range.
3. Double NAT — bridge the outer device.
4. Carrier-grade NAT — stop, and talk to the provider.
5. If they match, reserve the machine's internal address first.
6. Wire the machine before forwarding to it.
7. Forward explicitly, or accept the trade UPnP makes.
8. Test from outside your own network — from inside, it may appear to work either way.

The mistake to avoid

Configuring before identifying. Port-forwarding guides begin at step one of three possible problems, so following one while behind carrier-grade NAT means executing every step correctly and achieving nothing — and the natural conclusion is that a step was wrong, which sends you round again. Two addresses compared before you start tells you whether the rest of the page even applies to you.

The second mistake is testing from inside your own network. Many routers do not send traffic back in on their own public address, so a service can appear unreachable when it is fine, or appear fine when it is not. The only honest test is from somewhere else entirely — a phone with wi-fi turned off is enough, and it takes a minute.