Designing a mikrotik cgnat solution that scales#

Matthew Enger — Leaptel

• Why: Solid operator content on cheap whitebox CGNAT — and the static-port-block logging pattern is a genuinely smart answer to a hard compliance problem.
• What: Leaptel (~70k subscribers, >300G national aggregate) built CGNAT on Mikrotik CCR2216 (~$5k AUD/box; 2×100G + 12×25G; 16 ARM cores; ~42G real-world "conditions apply"). Law-enforcement logging is solved by static port allocation — 250 (currently) / 200 (new design) ports mapped per CGNAT customer IP, so the only record needed is the RADIUS entry for the CGNAT IP plus a lookup table; no per-flow NAT logs. Redundancy: VRRP toward the BNGs, BGP toward an L3 switch with AS-prepend per box and address-list-partitioned pools, all NAT rules pre-staged on both boxes; tcp-established-timeout cut to 31 minutes to stretch conntrack (max 1,048,576 entries) across ~7,000+ services. Failover testing: VRRP takeover in ≤3s, but conntrack resets on cutover — impact minutes, and QUIC's path-validation may stretch recovery to ~30s. Honest limitations: ~75% CPU on some cores, no dynamic port allocation on Mikrotik, occasional spontaneous reboots (recovers quickly), and load distribution across appliances still unsolved.
• How: Full config walkthrough (VLANs/VRRP, ROS7 BGP templates/connections/filters, the Mikrotik wiki's CGNAT port-block script generating hundreds of chained NAT rules, fasttrack with HW offload), all validated on a spare-parts test rig (two Mikrotiks plus a mock BNG and an Arista L3 switch) before production.
• Where applicable: Leaptel-specific scale and traffic; best suited to small/mid ISPs — the largest east-coast sites are moving to a commercial CGNAT solution and the freed hardware bolsters other sites. The static-port-block logging pattern and the failover/conntrade-off lessons transfer broadly.