IPv4 Class Guide: How to Check NAT Status and Type

Posted on by

An IPv4 class label does not determine a connection’s NAT status. Class A, B, and C describe a historical addressing system, while CIDR prefix length defines modern subnets. NAT status is determined by comparing the device address, default gateway, router WAN address, and public IPv4 address, then confirming whether inbound application ports are reachable.

A private device address with a public router WAN address usually indicates single NAT. A private WAN address indicates another translation layer, such as a second home router or carrier-grade NAT (CGNAT). Application labels such as Open, Moderate, or Strict describe reachability and may not use identical definitions across platforms.

IPv4 Class Labels vs. CIDR: What They Actually Tell You

Historical IPv4 classes and their ranges

The original classful IPv4 system divided addresses according to the first octet. The historical ranges were:

  • Class A: 1.0.0.0 through 126.255.255.255, with a default /8 mask.
  • Class B: 128.0.0.0 through 191.255.255.255, with a default /16 mask.
  • Class C: 192.0.0.0 through 223.255.255.255, with a default /24 mask.
  • Class D: 224.0.0.0 through 239.255.255.255, used for multicast rather than ordinary host addressing.
  • Class E: 240.0.0.0 through 255.255.255.255, reserved for experimental or special purposes.

The 0.0.0.0/8 range is reserved for special purposes, and 127.0.0.0/8 is reserved for loopback traffic. These exceptions are why the commonly cited Class A range begins at 1 and ends at 126.

Class labels remain useful for recognizing older documentation, but they do not describe how a current network is actually divided. For example, 10.20.30.40 falls within the old Class A range, yet it is normally a private address. Likewise, 192.168.1.25 falls within the old Class C range, but the entire 192.168.0.0/16 block is private.

Why CIDR—not class labels—defines the subnet

Classless Inter-Domain Routing (CIDR) uses a prefix length, written after a slash, to identify the network portion of an address. The prefix can be any length from /0 through /32, subject to the network’s design. It replaces the rigid /8, /16, and /24 boundaries of the classful system.

A network written as 192.168.1.0/24 contains 256 total addresses, while 192.168.1.0/25 divides that space into a smaller 128-address subnet. A network such as 10.40.0.0/20 also does not follow the old Class A default mask. The prefix length and subnet mask determine whether two devices are local, which address is the gateway, and where routing is required.

Consequently, an IPv4 class can describe an address’s historical first-octet category, but it cannot identify the subnet size, the routing boundary, or the presence of NAT.

Private and Public IPv4 Ranges to Recognize

The three private IPv4 ranges reserved for internal networks are defined by RFC 1918:

  • 10.0.0.0/8: 10.0.0.0 through 10.255.255.255.
  • 172.16.0.0/12: 172.16.0.0 through 172.31.255.255.
  • 192.168.0.0/16: 192.168.0.0 through 192.168.255.255.

Routers do not normally route these addresses across the public internet. They are common on home, office, and data-center networks, and NAT often translates them into a public IPv4 address for internet access.

Some other ranges are not ordinary public addresses:

  • 100.64.0.0/10: shared address space commonly used by internet providers for carrier-grade NAT.
  • 127.0.0.0/8: loopback addresses that refer back to the local device.
  • 169.254.0.0/16: link-local addresses commonly assigned when automatic local configuration fails.
  • 224.0.0.0/4: multicast addresses.

A public IPv4 address is generally globally routable and is not part of these private or special-purpose ranges. However, a public-looking address alone does not guarantee that unsolicited inbound traffic will pass. A firewall, provider policy, VPN, or application-level restriction can still block it.

What NAT Status Describes—and What It Does Not

NAT status describes how an endpoint’s address and port are translated between a local network and an upstream network. A home router may translate a device such as 192.168.1.20:5000 into the router’s public address and a different external port. The router records that mapping so response traffic can return to the correct device.

NAT status therefore concerns address translation and reachability. It does not come from the IPv4 class of the device address. A Class A private address, a Class B private address, and a Class C private address can all experience the same NAT arrangement.

Direct, single, double, and carrier-grade NAT

  • Direct or no home NAT: The endpoint or router has a globally routable IPv4 address. Inbound access may be possible if the device firewall and service permit it.
  • Single NAT: The device has a private address, the home router has a public WAN address, and the router performs one translation between them.
  • Double NAT: The device connects through a home router whose WAN address is itself private, usually because another router is upstream. Traffic crosses two translation devices.
  • Carrier-grade NAT: The provider assigns the customer router a shared address, commonly in 100.64.0.0/10, and translates it again at the provider network. The customer does not control the provider-side translation.

CGNAT can exist alongside home NAT. In that case, the local device is translated by the home router and then translated again by the provider, so it behaves like a form of double NAT from the application’s perspective.

Games and peer-to-peer applications may report NAT types as Open, Moderate, or Strict. These labels generally summarize whether the application can accept direct incoming sessions, maintain predictable port mappings, or must use a relay. The exact tests vary by platform. A Strict result does not identify the cause by itself; double NAT, CGNAT, a firewall, an inactive port, or an application-specific limitation can produce it.

How to Check Your NAT Type Step by Step

Compare your device IP, gateway, router WAN IP, and public IP

  1. Record the device IPv4 address and subnet mask. On the device’s network settings, note the IPv4 address, such as 192.168.1.20, and its prefix or mask. An address in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 is private.
  2. Record the default gateway. The gateway is normally the local router address, such as 192.168.1.1. It shows which device the endpoint uses to reach other networks, but it does not by itself prove that NAT is present.
  3. Open the router’s internet or WAN status page. Record the IPv4 address assigned to the router by its upstream network. This address is more important for NAT diagnosis than the router’s LAN address.
  4. Check the public IPv4 address. Use a trusted external IP-checking service or the provider’s account portal and record the IPv4 address seen from outside. Disable a VPN or proxy first, because it can make the external address belong to the tunnel or proxy rather than the internet connection being tested.
  5. Compare the WAN and public addresses. Interpret the result using the following patterns:
  • Private device IP, public WAN IP, and matching public IP: usually single NAT.
  • Private device IP and private WAN IP: another NAT router is upstream, indicating double NAT or a similar layered setup.
  • WAN IP in 100.64.0.0/10, with a different public IP: carrier-grade NAT is highly likely.
  • WAN IP in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16: the router is behind another private network, commonly a second router or managed gateway.
  • Device and WAN addresses are public: the device may be directly addressed, although a firewall or another upstream policy can still restrict inbound traffic.

If the router WAN address is public but does not match the external public address, check for a VPN, proxy, tunnel, special provider architecture, or a second upstream translation layer. Some provider equipment may also expose an administrative WAN address that is not the final internet-facing address.

Use application port behavior to confirm reachability

Address comparison identifies likely translation layers; an inbound port test checks what the application can actually reach. First, run the application or service so that it is actively listening on a known TCP or UDP port. Then configure a port-forwarding rule on the home router from the external port to the device’s local address. Test from a separate internet connection, such as a mobile network, rather than from the same LAN.

  • Inbound traffic reaches the service: the connection has usable inbound reachability for that protocol and port.
  • The port fails while the service is inactive: the result is inconclusive because no process is listening.
  • The service is listening but the port remains unreachable: check the device firewall, router firewall, port-forwarding address, protocol, and upstream NAT.
  • Port forwarding works only through one router: a second router may require a corresponding rule, or the first router may need bridge or access-point operation.
  • Port forwarding cannot work through the provider’s shared address: CGNAT is likely unless the provider supplies a public IPv4 address or an alternative inbound service.

Outbound browsing or a successful speed test does not prove that unsolicited inbound traffic can reach the device. TCP and UDP also behave differently, and some applications use relays, hole punching, or UPnP rather than a manually forwarded port. The most reliable NAT diagnosis combines the four address checks with the application’s actual inbound connection behavior.