CGNAT for ISPs: Configuration, Logging & Subscriber Tracking on MikroTik

When You Actually Need CGNAT

• You've burned through your /22 and the next block costs more than a router.
• Your subscriber-to-public-IP ratio is approaching 1:1 and growing.
• You've already deployed IPv6 (or are planning to alongside) — see our IPv6 deployment guide — and CGNAT is the IPv4 fall-back, not the only plan.

CGNAT is not a substitute for IPv6. Run dual-stack: IPv6 first, CGNAT for the legacy IPv4 Internet. The amount of traffic that bypasses your CGNAT will surprise you within a year.

The 100.64.0.0/10 Address Space

RFC 6598 reserves 100.64.0.0/10 (~4 million addresses) as shared address space — specifically for CGNAT. Use it for the inside leg. Never use RFC1918 (10/8, 172.16/12, 192.168/16) for CGNAT — it collides with subscriber LANs and confuses every CPE on Earth.

Pick a Port-Block Size First

A modern subscriber opens 200–800 simultaneous TCP/UDP flows. Picking the right port-block size per subscriber decides your subscriber:public ratio:

Most ISPs settle at 1,024 ports per subscriber — a balance between user experience (no broken video conferencing) and IPv4 conservation.

MikroTik Configuration

Below is a minimal CGNAT setup on RouterOS 7+ for one /24 of public IPs and the 100.64.0.0/16 CGNAT pool. Adjust for your scale.

# Address pool of public outside addresses
/ip pool
add name=cgnat-public ranges=203.0.113.0-203.0.113.255

# CGNAT inside pool fed to subscribers via PPPoE/IPoE
/ip pool
add name=cgnat-inside ranges=100.64.0.2-100.64.255.254

# PPPoE profile pulling from the inside pool
/ppp profile
add name=residential local-address=100.64.0.1 remote-address=cgnat-inside \
    dns-server=1.1.1.1,1.0.0.1

# Source NAT — single rule, RouterOS 7 will allocate per-flow
/ip firewall nat
add chain=srcnat src-address=100.64.0.0/10 action=src-nat \
    to-address=203.0.113.0-203.0.113.255 \
    comment="CGNAT outbound"

# Limit ports per inside address (port-block) — RouterOS 7
/ip firewall nat
add chain=srcnat src-address=100.64.0.0/10 protocol=tcp action=src-nat \
    to-address=203.0.113.0-203.0.113.255 \
    to-ports=1024-65535 same-ports-for-source=yes

On a CCR2216 you can sustain ~70 Gbps of CGNAT traffic. For larger deployments, look at multiple routers with ECMP or dedicated NAT appliances.

Deterministic vs Stateful CGNAT

There are two log-volume schools:

• Stateful CGNAT — log every translation (5-tuple in, 5-tuple out, timestamp). Most accurate. Generates 50–500 GB of logs per Gbps per day. Expensive to store.
• Deterministic CGNAT — pre-allocate a fixed port-block per subscriber (e.g. inside 100.64.5.42 always uses outside 203.0.113.7:10000–10999). One static mapping table replaces gigabytes of logs. Recommended for any ISP serving more than a few hundred CGNAT subs.

Deterministic CGNAT also makes incident response trivial: you don't have to grep a billion log lines, you do a single integer-divide on the source port to recover the subscriber.

What to Log (and What Not To)

Local laws differ — in most South Asian jurisdictions ISPs are required to retain enough data to identify which subscriber was using a given public IP + port + timestamp at any point for a defined retention window (commonly 90–180 days). The minimal log set:

• Subscriber username (PPPoE / IPoE) ↔ inside address ↔ outside address ↔ port-block ↔ start/end timestamp
• Session start & stop accounting (RADIUS Acct-Start / Acct-Stop)
• Optional: per-flow netflow records (for traffic engineering, not law-enforcement)

Do not log destination IPs or URLs unless you are legally compelled — it explodes storage and creates a sensitive data liability.

Answering a Subscriber-Identification Request

A typical request from law enforcement looks like “who was using 203.0.113.7:10523 at 2026-04-15 14:32:01 UTC?” With deterministic CGNAT and a port-block size of 1,000:

# Compute the per-public-IP block index
block_index = floor( (10523 - 1024) / 1000 ) = 9

# Look up which inside address was assigned block 9 of 203.0.113.7
# from your CGNAT mapping table → 100.64.5.42

# Look up which subscriber held 100.64.5.42 at that timestamp
# from your RADIUS accounting logs → username 'john.doe'

Two table lookups, no log scan. ISPbills stores RADIUS accounting natively and can join it against your CGNAT mapping table from the same UI.

CGNAT Pitfalls

• Hairpin NAT — subscribers behind the same outside IP cannot reach each other's open ports. Educate support.
• P2P / online gaming — strict NAT type. Whitelist heavy gamers to a public IP if necessary.
• Geo-IP confusion — many subscribers will look like they're in your NOC city. Tell GeoIP providers your CGNAT ranges.
• Reputation poisoning — one abusive subscriber gets the public IP blacklisted; everybody behind it suffers. Have a fast subscriber-quarantine workflow.
• Port exhaustion alarms — monitor utilization per outside IP; if any single IP gets above 70% port utilization, redistribute.

How ISPbills Helps

• RADIUS accounting capture — every PPPoE session start/stop is logged with timestamps so you can prove subscriber-IP mapping at any moment.
• Public-IP add-on plans — sell a public IP as a paid add-on; the platform handles billing and pool assignment.
• CGNAT-aware subscriber lookup — your support panel shows the public IP and port-block of every CGNAT user.
• Reputation-event workflows — quarantine an abusive subscriber to a separate public IP in one click.