CGNAT & VRF Steering

IPv4 address conservation via VRF-based handoff to a dedicated CGNAT appliance — clean separation, carrier-grade performance.

Overview

With IPv4 exhaustion a reality for Australian ISPs, CGNAT lets you serve more subscribers than you have public IP addresses. AthenaBNG provides CGNAT VRF steering — automatically identifying subscribers that require NAT and routing their traffic through a dedicated VRF to an external CGNAT appliance. This gives you the flexibility to use purpose-built NAT translation hardware or software while keeping your BNG focused on subscriber management.

Built-in Deterministic CGNAT — Coming Soon

A future release of AthenaBNG will include built-in nftables-based deterministic CGNAT with per-subscriber public IP and port range allocation — no external appliance required. The VRF steering architecture described below will remain supported for operators who prefer a dedicated CGNAT device.

How It Works

AthenaBNG steers CGNAT traffic using Linux VRF (Virtual Routing and Forwarding) and nftables packet marking:

1. Subscriber classification — When a subscriber session comes up, AthenaBNG checks whether their assigned IP falls within the CGNAT source range (default: 100.64.0.0/10 per RFC 6598)
2. Packet marking — nftables marks matching traffic with a configurable firewall mark (fwmark)
3. Policy routing — An ip rule steers marked packets into the CGNAT VRF routing table
4. VRF handoff — The CGNAT VRF has a default route via a dedicated handoff interface to your CGNAT appliance
5. Return path — The CGNAT appliance translates the source IP and forwards to upstream; return traffic follows the normal routing path

Architecture

Subscriber (100.64.x.x)
    │
    ▼
AthenaBNG ──── nftables (fwmark) ──── ip rule ──── CGNAT VRF (table 100)
    │                                                    │
    │                                              ┌─────▼─────┐
    │                                              │  CGNAT     │
    │                                              │  Appliance │
    │                                              │ (NFware /  │
    │                                              │  nftables) │
    │                                              └─────┬─────┘
    │                                                    │
    └────────────── Upstream / Internet ◄────────────────┘

Subscribers with public IPs bypass the CGNAT VRF entirely.

What AthenaBNG Manages

Component	Detail
VRF device	Creates and manages the Linux VRF (ip link add type vrf)
Handoff interface	Moves the dedicated interface into the CGNAT VRF
Policy routing	Adds ip rule add fwmark <mark> table <N>
Default route	Installs a default route in the VRF table via your CGNAT gateway
nftables rules	Manages the inet abng_cgnat table for packet marking
Subscriber detection	Automatically identifies CGNAT subscribers by IP range

Recommended: NFware vCGNAT

For production CGNAT deployments, we recommend NFware vCGNAT as the external translation appliance. NFware vCGNAT provides:

• Deterministic NAT — Predictable public IP + port mapping for lawful intercept compliance (required by Australian telecommunications regulations)
• High performance — Handles millions of concurrent NAT sessions with DPDK acceleration
• Logging — Full NAT translation logging for regulatory compliance
• Hairpinning — Subscriber-to-subscriber traffic within the CGNAT pool
• ALG support — Application Layer Gateways for SIP, FTP, and other protocols
• REST API — Programmatic pool and mapping management

NFware vCGNAT runs on the same commodity x86 hardware as AthenaBNG — deploy it on a second server or as a VM alongside the BNG.

Other CGNAT Options

Any CGNAT appliance or software that accepts routed traffic on a handoff interface will work. Alternatives include Linux nftables on a dedicated server, Juniper MX with MS-MPC, or A10 Thunder CGN.

Configuration

cgnat:
  enabled: true
  vrf_name: "cgnat"
  vrf_table: 100
  handoff_interface: "eth3"
  handoff_gateway: "10.99.0.1"
  source_range: "100.64.0.0/10"
  fwmark: "0x64"

Parameter	Default	Description
enabled	false	Enable CGNAT VRF steering
vrf_name	"cgnat"	Linux VRF device name
vrf_table	100	Routing table ID for the CGNAT VRF
handoff_interface	—	Dedicated interface to the CGNAT appliance
handoff_gateway	—	Next-hop IP on the CGNAT appliance
source_range	"100.64.0.0/10"	RFC 6598 CGNAT address range
fwmark	"0x64"	nftables firewall mark for policy routing

Typical Deployment

                  ┌─────────────┐
                  │  RADIUS     │
                  │  Server     │
                  └──────┬──────┘
                         │
 NBN NNI ────► AthenaBNG ────► Core Router ────► Internet
                  │                   ▲
                  │ (CGNAT VRF)       │ (translated traffic)
                  ▼                   │
            ┌──────────┐             │
            │  NFware  │─────────────┘
            │  vCGNAT  │
            └──────────┘

Subscribers with public IPs are routed directly to the core. Subscribers on RFC 6598 addresses are steered through the CGNAT VRF to the NFware appliance, which performs the translation and forwards upstream.

IPv6 Transition

CGNAT is a bridge technology. AthenaBNG's architecture supports a smooth transition:

• Run CGNAT for IPv4 alongside native IPv6
• Dual-stack subscribers get IPv6 natively, IPv4 through CGNAT
• Gradually reduce CGNAT pool size as IPv6 adoption grows
• When ready, simply disable the CGNAT VRF — no BNG reconfiguration needed