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:
- Your device gets
100.64.45.123(a CGNAT internal IP). - 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.
- First packet exits via ISP Gateway A
(public IP:
- 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).
- Second packet exits via ISP Gateway B
(public IP:
- 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.merepeated 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/interfacesor 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.