NAT Type Tester: Public vs. Private Subnets Explained

Posted on by

A nat type tester is most useful when the network path is mapped from the device outward: local IP, gateway, public IP, and whether another NAT layer sits in between. That sequence reveals why one connection looks open while another appears restricted.

With the subnet explained in practical terms, the key distinction is simple: a public subnet contains addresses that route on the internet, a private subnet uses local ranges that do not route globally, and a shared carrier-grade range sits in the middle as ISP-managed translation space. NAT status changes when those boundaries change, not because a tester invents a new rule.

Public subnet boundaries and private address ranges

What public addresses route to the internet

A public address is globally routable and unique. Routers on the internet know where to send traffic for that address because it appears in public routing tables. In a true public subnet, devices or edge interfaces can be reached from outside if firewalls and security policies allow it.

That does not mean every device on a public subnet is automatically reachable. Firewalls, access control lists, and service bindings can still block inbound traffic. The important difference is that the address itself is not hidden behind private translation. If a NAT tester reports an open or reachable path, the device or edge router is usually presenting a public egress address directly or through only one translation layer.

What private address blocks stay inside the LAN

Private subnets use address ranges reserved for local networks:

  • 10.0.0.0/8
  • 172.16.0.0/12 through 172.31.255.255
  • 192.168.0.0/16

These ranges are not routed across the public internet. A device on one of these addresses needs a gateway that performs NAT or another form of translation before traffic can leave the LAN. That is why a home laptop can browse the web even though its local IP is 192.168.x.x: the router rewrites the source address and usually the source port before sending packets upstream.

For troubleshooting, this matters because the local address tells only part of the story. A private subnet can be perfectly normal for a home or office LAN, but it also means inbound connections from the internet will not reach that device unless the translation path is explicitly created.

Where shared carrier-grade NAT fits

Carrier-grade NAT, often shortened to CGNAT, uses the shared address block 100.64.0.0/10. This range is not a public subnet, and it is not a normal private LAN range either. It is reserved for service-provider translation between subscriber networks and the internet.

When an ISP uses CGNAT, many customers can share one public IP at the edge while each customer receives a shared address internally. The routing implication is important: outbound traffic works because the ISP translates it, but inbound traffic is much harder because the ISP controls the shared translation table. A NAT type tester often flags this as restricted, symmetric, or otherwise limited for unsolicited inbound access.

How NAT changes address and port visibility

Your local IP, gateway, and the public IP

On a normal LAN, the device has a local IP, a subnet mask, and a default gateway. The gateway is the next hop, usually the router or firewall that handles traffic leaving the subnet. If the local IP is private, the gateway is almost always translating it before the traffic reaches the internet.

The public IP is the address seen by websites, cloud services, and NAT test tools. It may belong to the router, to an upstream ISP device, or to a provider-level translation system. Comparing those three values is the fastest way to understand the network shape:

  • Local IP shows the device’s LAN position.
  • Gateway shows the first routing boundary.
  • Public IP shows what the outside world sees.

If the local address is private and the public address is different, NAT is happening somewhere. If the gateway itself is in 100.64.0.0/10 or another private range, there is likely an additional upstream translation layer.

What changes for outbound and inbound traffic

NAT rewrites the source address, and often the source port, for outbound connections. The router or ISP keeps a translation table so return traffic can be mapped back to the correct device. That is why browsing, streaming, and downloading usually work even when the local address is private.

Inbound traffic behaves differently. An unsolicited packet from the internet has no existing mapping, so the edge device normally drops it. Port forwarding, static NAT, and firewall rules can create a path back in, but only when the upstream network actually owns the public address and allows that mapping to exist.

Layered NAT makes this more complicated. A device may sit behind:

  • a home router doing NAT,
  • a second router or modem-router doing NAT again, or
  • an ISP carrier-grade NAT system plus a home router.

In each case, the visible NAT status depends on both address assignment and the ability to preserve inbound mappings across every layer.

How a NAT type tester works and what it measures

Check local addressing and gateway status

The first step is to inspect the device itself. A practical test sequence looks like this:

  1. Find the device’s local IP address, subnet mask, and default gateway.
  2. Classify the local IP as public, private, or shared carrier-grade.
  3. Confirm whether the gateway address sits in the same subnet.
  4. Check whether the gateway is a standalone router, a modem-router, or a bridge device.

If the device has a private address and the gateway is also private or shared carrier-grade, there is translation upstream. If the device has a public IP directly and the gateway is only a pure bridge, NAT may be absent on the local side. A mismatch between the expected gateway role and the visible address range often explains why a tester reports stricter behavior than expected.

Compare the public IP view

Next, compare the public IP shown by the NAT test with the WAN IP on the router and the IP shown by an external lookup site. Matching values usually indicate that the router or firewall is the main edge device. Different values often indicate a second translation layer upstream.

Use this quick interpretation:

  • Router WAN IP matches the internet site: one translation layer, or a direct public connection.
  • Router WAN IP is private or 100.64.0.0/10, but the site shows a different public IP: upstream NAT or CGNAT.
  • Device IP, router WAN IP, and site IP all differ: layered NAT or a double-router setup is likely.

That comparison is more reliable than any single label in an app. A NAT type tester measures how packets behave through the current path; it does not redefine the network’s routing model.

Match the result to application behavior

To validate the result, check how a real application behaves. Peer-to-peer games, voice chat, remote desktop tools, and hosted services expose different limits. A tester may say one thing while a specific app fails because that app needs a particular port, protocol, or keepalive pattern.

Useful signals include:

  • Open behavior: direct inbound or peer connections succeed without special work.
  • Moderate or partial behavior: some peers connect, but others cannot reach the device.
  • Strict or restricted behavior: unsolicited inbound connections fail, and only outbound-initiated sessions work reliably.

Those labels are application-specific rather than universal protocol standards. The practical question is whether the tested service can accept inbound traffic through the current address path.

Diagnose double NAT and restricted inbound access

When a second router is translating traffic

Double NAT usually appears when two separate devices both act as routers. A modem-router from the ISP may already perform NAT, and then a personal router behind it performs NAT again. The result is a private or shared WAN address on the downstream router and another translation step before the internet.

Common signs include:

  • The router’s WAN address is 192.168.x.x, 172.16-31.x.x, or 100.64.x.x.
  • The gateway appears to be another consumer router or ISP gateway.
  • Port forwarding works inconsistently or only after being configured twice.
  • Inbound tests fail even though the local firewall is open.

The corrective options are straightforward: place the upstream modem-router into bridge mode, switch the downstream device to access point mode if routing is not needed, or configure forwarding on both routers if both must remain active. For a server, camera, or game host, a single public edge router is the cleanest design.

When the ISP uses carrier-grade NAT

CGNAT creates a different problem. The local router may be configured correctly, but the ISP keeps the actual public IP and translation table. In that case, port forwarding on the home router may still fail because the inbound packet never reaches the home router in the first place.

Typical clues are a WAN address in 100.64.0.0/10, a router status page that never shows a true public IP, and outside port checks that stay closed even after local rules are in place. Outbound browsing continues to work, which can make the issue look like a firewall problem when it is really an ISP translation boundary.

When CGNAT is the cause, the practical fixes are usually ISP-related: request a public IPv4 address, upgrade to a static or public-address plan, or use IPv6 if the application supports it. Relay services, tunneling tools, and VPN-based remote access can also bypass the inbound limitation when direct port exposure is not available.

Choose the right fix: bridge mode, port mapping, or an ISP change

The right correction depends on where the translation occurs:

  • Double NAT from your own hardware: use bridge mode or remove one router from routing duty.
  • One router with a true public WAN IP: use port mapping, firewall rules, and service-specific listening ports.
  • CGNAT from the ISP: port mapping alone will not fix inbound access; an ISP change or relay method is needed.

After the change, rerun the local IP check, gateway check, and public-IP comparison. If the NAT tester and the real application both show improved inbound reachability, the path has been corrected.