ISP Modem Configuration Modes Guide

Identify whether the ISP modem is delivering CGNAT, bridged, or routed/static service, and the consequences for VPN, port forwarding, and remote access.

ISP-side configuration drives a lot of what’s actually possible behind an Uplevel Gateway — whether VPNs stay up, whether you can host anything, whether port forwards work. This article covers the three modes you’ll typically encounter, how to identify which one you’ve got, and the practical implications.

Mode 1 — 2× NAT (CGNAT) via DHCP

The ISP hands the modem a private IP rather than a public one, then NATs the whole customer base through a smaller pool of public IPs behind their network.

Example

  • Local adapter IP: 10.45.123.78 (via DHCP)
  • Subnet mask: 255.255.255.0 (typically /24)
  • Gateway: 10.45.123.1 (ISP’s internal router)
  • Public WAN IP: 96.78.88.70 (shared with other customers)

Characteristics

  • One public IP serves many customers simultaneously.
  • Traffic traverses two NAT layers — the customer modem and the ISP’s CGN devices.
  • Cannot host publicly accessible services without ISP cooperation.
  • Most common on residential cable and fibre.
  • Inbound port forwarding from the public Internet is impossible at the customer level.

Private IP ranges used

RFC 1918 ranges:

  • 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
  • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
  • 192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

RFC 6598 shared address space (CGNAT-specific):

  • 100.64.0.0/10 (100.64.0.0 – 100.127.255.255)

Understanding RFC 6598 (the 100.64.0.0/10 range)

RFC 6598 reserves 100.64.0.0/10 specifically for carrier-grade NAT. The range exists because ISPs ran out of RFC 1918 space for their own infrastructure as they scaled CGNAT, and a dedicated range avoids collisions with the customer’s own networks.

Why ISPs use 100.x rather than 10.x:

  • Avoids collisions with home networks already using 192.168.x.x or 10.x.x.x internally.
  • Gives ISPs over 4 million addresses for their CGN infrastructure.
  • Clearly identifies carrier-side NAT addresses vs. customer private IPs.

If your adapter is showing an IP like 100.64.5.123, 100.100.200.45, or 100.127.255.254, you are definitely behind CGNAT. The 100.x range is not for customer use — it’s exclusively ISP carrier infrastructure.

CGNAT multi-exit-point problem

Many ISPs run CGNAT across multiple exit points for load balancing and redundancy. Stateful protocols hate this.

The flow that breaks:

  1. Your device gets 100.64.45.123 (a CGNAT internal IP).
  2. You start a VPN to vpn.company.com.
    • First packet exits via ISP Gateway A (public IP: 203.0.113.50).
    • VPN server sees a connection from 203.0.113.50.
    • VPN handshake begins.
  3. Your next packet takes a different path.
    • Second packet exits via ISP Gateway B (public IP: 203.0.113.88).
    • VPN server sees a new connection from 203.0.113.88.
    • VPN server thinks this is a different client (or an attack).
  4. The VPN session fails or churns endlessly.

Why multiple exit points exist: load balancing across multiple CGN devices, geographic distribution, redundancy, traffic engineering.

Symptoms of multi-exit CGNAT:

  • VPN connects then immediately drops.
  • Frequent Session expired or Connection reset errors.
  • VPN runs for 30–60 seconds, then dies, repeatedly.
  • Some destinations work, others fail, inconsistently.
  • curl ifconfig.me repeated several times shows different IPs.
  • Gaming servers kick you for “connection instability”.

Why it breaks at the protocol level: VPN protocols track state by source IP + source port. When exit IPs flip mid-stream, the VPN server sees what look like two different clients trying to share the same session keys — security checks fire, the session is dropped.

Affected protocols: IPsec (IKEv2, L2TP/IPsec), OpenVPN (UDP especially), VoIP/SIP, online gaming over UDP.

Workarounds (limited):

  • Switch the VPN from UDP to TCP — slower but more stable.
  • Enable short-interval VPN keepalives (5–10 s).
  • Prefer protocols designed for NAT traversal (WireGuard handles this better).
  • Ask the ISP for a business-grade product without CGNAT.
  • Use a VPS as a “bounce box” with a persistent tunnel.
  • Add a cellular backup connection (often has stable CGNAT or none at all).

Permanent solutions:

  • Request a static IP allocation (see Mode 3).
  • Switch the modem to bridge mode if available (see Mode 2).

Mode 2 — Bridged mode (DHCP)

The modem behaves as a transparent bridge — no NAT — and the gateway receives the public IP directly.

Example

  • Local adapter IP: 96.78.88.65 (via DHCP)
  • Subnet mask: 255.255.255.0
  • Gateway: 96.78.88.1 (ISP’s gateway)
  • Public WAN IP: 96.78.88.65 (matches the local IP)

Characteristics

  • Modem is a transparent bridge — zero NAT layers.
  • Gateway gets a genuine public IP from the ISP’s DHCP server.
  • Can host services (web, game, RDP, etc.).
  • The IP may change when the DHCP lease renews (every 24–72 hours, typically).
  • Single dynamically-assigned public IP.
  • Local adapter IP and public IP are identical.
  • Port forwards through the gateway to LAN hosts are possible.

Advantages over CGNAT

  • VPNs work reliably.
  • Gaming and VoIP have lower latency.
  • LAN services can be exposed via port forwards.
  • No double-NAT performance penalty.

Disadvantages

  • The public IP changes periodically — work around it with dynamic DNS.

Mode 3 — Routed mode (static block)

The ISP provides a routed block of public IPs assigned to the customer’s connection.

Example (manual configuration)

  • Static IP: 96.78.88.65 (chosen from the assigned range)
  • Subnet mask: 255.255.255.248 (/29 — 6 usable IPs)
  • Gateway: 96.78.88.70 (ISP’s router)
  • DNS: 8.8.8.8, 1.1.1.1 (your choice or ISP’s)
  • Public WAN IP: 96.78.88.65

A /29 block laid out

  • Network address: 96.78.88.64 (not usable)
  • Usable range: 96.78.88.65 – 96.78.88.70
  • Gateway: 96.78.88.70 (typically the last usable address)
  • Customer-assignable: 96.78.88.65 – 96.78.88.69
  • Broadcast: 96.78.88.71 (not usable)

Characteristics

  • No NAT at all — direct public Internet connectivity.
  • IPs never change (persistent configuration).
  • Multiple public IPs can be assigned to different devices and services.
  • Requires manual network configuration on the gateway side.
  • Common for business connections and advanced residential.
  • Best fit for sites running multiple servers, mail, DNS, etc.

Typical static block sizes

Block Usable IPs
/29 6
/28 14
/27 30
/26 62

Identifying which mode you have

Step 1 — check the local adapter IP

  • Linux / macOS: ip addr show
  • Windows: ipconfig /all

Step 2 — read the IP

Adapter IP Mode
10.0.0.0 – 10.255.255.255 2× NAT / CGNAT (RFC 1918)
172.16.0.0 – 172.31.255.255 2× NAT / CGNAT (RFC 1918)
192.168.0.0 – 192.168.255.255 2× NAT / CGNAT (RFC 1918)
100.64.0.0 – 100.127.255.255 2× NAT / CGNAT (RFC 6598 — CGNAT)
Anything else Bridged or routed mode

Step 3 — check the public IP

In a browser:

Or from a terminal:

curl ifconfig.me
curl ipinfo.io/ip
dig +short myip.opendns.com @resolver1.opendns.com

Quick local+public IP check (Windows PowerShell):

"Local IPs:"; (ipconfig | Select-String "IPv4").Line -replace '.*:\s+',''; "`nPublic IP:"; curl icanhazip.com

To make it a permanent shortcut, edit your profile:

notepad $PROFILE

Add:

function myips {
    "Local IPs:"
    (ipconfig | Select-String "IPv4").Line -replace '.*:\s+',''
    "`nPublic IP:"
    curl icanhazip.com
}

Save and restart PowerShell (or . $PROFILE). Then use myips.

If $PROFILE doesn’t exist yet:

New-Item -Path $PROFILE -ItemType File -Force

Step 4 — compare local vs. public

  • Local IP matches public IP → bridged or routed (Mode 2 or 3).
  • Local IP is private (10.x, 172.x, 192.168.x, or 100.64.x) but public IP differs → CGNAT (Mode 1).

Step 5 — bridged vs. routed

  • DHCP-assigned: bridged (Mode 2).
  • Manually / statically configured: routed (Mode 3).
  • Windows: check DHCP Enabled: Yes in ipconfig /all.
  • Linux: check /etc/network/interfaces or NetworkManager settings.

Testing for CGNAT multi-exit issues

Run this from the workstation to see whether the public IP is stable over time.

Bash (Linux / macOS):

for i in {1..10}; do
  echo "Check $i: $(curl -s ifconfig.me/ip)"
  sleep 5
done

PowerShell (Windows):

1..10 | % {
    "Check $_ `: $(curl -s ifconfig.me/ip)"
    sleep 5
}

Interpreting the results

All 10 IPs the same → single exit point or stable public IP. VPNs should work fine.

Check 1 : 187.190.4.181
Check 2 : 187.190.4.181
Check 3 : 187.190.4.181

Multiple different IPs → multi-exit CGNAT. VPNs will be problematic.

Check 1 : 203.0.113.50
Check 2 : 203.0.113.88
Check 3 : 203.0.113.50
Check 4 : 203.0.113.102

Summary comparison

Feature Mode 1: CGNAT Mode 2: Bridge Mode 3: Static
NAT layers 2 (double) 0 (none) 0 (none)
Public IP assignment Shared Dynamic Static
Can host services No Yes Yes
Port forwarding No Yes Yes
IP changes n/a Yes (periodic) Never
VPN reliability Poor–Fair Good Excellent
Configuration complexity Automatic Automatic Manual
Typical use case Residential Residential + Business
Monthly cost Lowest Low–medium Highest
Multiple public IPs No No Yes

Troubleshooting tips for MSPs

Common issues by mode

Mode 1 (CGNAT):

  • VPN randomly disconnects — test for multi-exit CGNAT (above).
  • Cannot reach the client remotely — no inbound port forwarding is possible.
  • Security-camera remote viewing fails — same reason.
  • VoIP quality issues — inconsistent NAT traversal.

Mode 2 (Bridged):

  • The DHCP public IP keeps changing — implement dynamic DNS at the gateway.

Quick diagnostic commands

Windows:

ipconfig /all          # check local IP and DHCP status
tracert 8.8.8.8        # trace route to verify gateway
nslookup google.com    # test DNS resolution

Linux:

ip addr show           # IP configuration
ip route               # routing table
traceroute 8.8.8.8     # trace route to the Internet
dig @8.8.8.8 google.com  # test DNS

Test for any NAT:

curl ifconfig.me/ip

If the result differs from the local adapter IP, NAT is in the path somewhere.

Related articles