Carrier-Grade NAT is the operational reality for nearly every Pakistani ISP operating with a limited IPv4 allocation. The economics of acquiring public IPv4 addresses at current transfer market prices make CGNAT a practical necessity for any ISP serving more than a handful of subscribers from a modest address block. MikroTik RouterOS handles CGNAT natively through its src-nat and masquerade rules, but the difference between a CGNAT deployment that works and one that performs well at scale, logs correctly for regulatory purposes, and handles edge cases cleanly is in the implementation details.

Addressing Architecture Before Configuration

The addressing decisions made before touching RouterOS determine how well the CGNAT deployment scales. There are three address spaces to design: the subscriber-facing private address space, the CGNAT public pool, and the management address space. These must be completely non-overlapping and planned for the subscriber count you will have in two to three years, not just today.

For subscriber-facing addresses, the RFC 6598 100.64.0.0/10 range is specifically reserved for CGNAT use and is the correct choice for ISP subscriber addressing. Using RFC 1918 space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for subscriber addressing creates problems when subscribers themselves use RFC 1918 addressing internally: double-NAT with overlapping private ranges causes routing failures. The 100.64.0.0/10 block gives you 4 million addresses for subscriber use, which is enough for any deployment that will run on a MikroTik platform.

The public NAT pool size determines how many concurrent sessions you can support before port exhaustion. Standard CGNAT port allocation is 1,000 to 4,000 ports per subscriber depending on your subscriber profile. A /29 giving you 6 usable public addresses at 1,000 ports each supports approximately 384,000 concurrent sessions, which maps to roughly 200-400 concurrent subscribers depending on activity level. Size the pool against your expected concurrent subscriber count at peak rather than your total subscriber count.

Basic CGNAT Configuration

RouterOS CGNAT is implemented as a src-nat rule in the NAT firewall chain. The minimal configuration to enable CGNAT from a subscriber subnet to a public pool:

/ip firewall nat
add chain=srcnat src-address=100.64.0.0/10 action=src-nat \
    to-addresses=<your-public-pool-range> to-ports=1024-65535 \
    protocol=tcp
add chain=srcnat src-address=100.64.0.0/10 action=src-nat \
    to-addresses=<your-public-pool-range> to-ports=1024-65535 \
    protocol=udp
add chain=srcnat src-address=100.64.0.0/10 action=masquerade \
    protocol=icmp

The split between TCP, UDP, and ICMP rules is intentional: masquerade works correctly for ICMP (which doesn't use ports) while explicit src-nat with port range control is better for TCP and UDP because it gives you deterministic behavior and logging control.

Port Block Allocation for Logging

The most important CGNAT configuration decision for Pakistani ISPs is port block allocation, because it directly affects your ability to satisfy lawful intercept and logging requirements. Without port block allocation, mapping a specific public IP and port back to a specific subscriber at a specific time requires querying the connection tracking table, which only holds active connections. Once the connection ends, the mapping is lost.

Port block allocation assigns a defined block of ports to each subscriber for a defined period. With this approach, you can log at the allocation event rather than per-connection, which is both more efficient and more reliable for meeting retention requirements.

Configure port block allocation in RouterOS using pcp (port control protocol) or through script-based allocation management. A practical approach for subscriber counts under 10,000 assigns a fixed block of 1,000 ports per subscriber from the pool, logs the subscriber IP, assigned public IP, assigned port block, start time, and release time. This log entry is what satisfies the requirement to associate a public IP and port with a specific subscriber at a specific time.

Store these logs to your centralised log infrastructure, not just RouterOS's ring buffer. The ring buffer is volatile and insufficient for any regulatory retention requirement.

Hairpin NAT

Hairpin NAT, also called NAT reflection, handles the case where a subscriber is trying to reach a service hosted by another subscriber on the same CGNAT pool. Without hairpin configuration, the request goes out to the public IP, hits the router's WAN interface, and either fails or loops incorrectly.

RouterOS handles this with an additional NAT rule that matches traffic from the subscriber subnet destined for the public NAT pool and performs appropriate translation:

/ip firewall nat
add chain=srcnat src-address=100.64.0.0/10 \
    dst-address=<your-public-pool-range> \
    action=masquerade comment="Hairpin NAT"

Place this rule before the main CGNAT rules in the chain order.

Performance Tuning for Scale

RouterOS connection tracking is the component that limits CGNAT performance at high subscriber counts. Each active connection occupies an entry in the connection tracking table, which is memory-bounded. Default connection tracking timeouts are generous and designed for small networks, not ISP-scale deployments.

Reduce timeouts aggressively for a CGNAT router:

/ip firewall connection tracking
set tcp-established=1h tcp-close-wait=10s tcp-fin-wait=10s \
    tcp-last-ack=10s tcp-syn-received=5s tcp-syn-sent=5s \
    tcp-time-wait=10s udp-stream=120s udp-timeout=30s \
    icmp-timeout=10s

These values keep the connection tracking table lean at scale. Monitor connection tracking table size under load and adjust if you see table full errors in the log, which indicate that new connections are being dropped.

For routers handling more than 50,000 concurrent connections, consider moving CGNAT to dedicated hardware with FastTrack enabled for established connections to reduce CPU load, or distributing subscriber groups across multiple CGNAT routers with different public pool ranges.

Integration with Subscriber Management

A CGNAT deployment that does not integrate with your subscriber management system creates operational problems: you cannot easily identify which subscriber is causing abuse complaints by public IP alone, and generating the log entries required for lawful intercept requires manual cross-referencing. Integrating CGNAT logging with your RADIUS accounting data, so subscriber IP to public IP mappings are correlated with subscriber identity, is the operational and regulatory standard.

For automation of subscriber provisioning, pool management, and log correlation, Automation & Integrations covers the integration work between RouterOS, RADIUS, and your billing and log management systems. For operators designing CGNAT as part of a broader network architecture, Network Design & Optimization covers the addressing and routing design.