CGNAT Abuser Isolation · penalty IP · pool reputation · auto-restore · audited moves

CGNAT Security Brief · Abuser Auto-Isolation

One abuser shouldn't get your shared IP blocklisted for everyone else

On a shared CGNAT pool, every subscriber behind a public IP shares its reputation. One compromised device — a botnet node, a scanner, a spam relay — starts sending abuse. The shared address gets blocklisted. And every innocent subscriber on that address suddenly hits CAPTCHAs on Google, gets banned from gaming networks, or finds streaming services refusing connections. They didn't do anything wrong. BNGSOFT automatically moves the abuser off the pool the moment the abuse is detected — onto a dedicated penalty public IP — so their behaviour affects only them, not the subscribers they share with.

Automatic

no operator action

detected abuser moves to penalty IP the moment abuse triggers

Pool stays clean

innocent subs protected

abuse traffic never touches the shared pool address while isolated

Auto-restore

on hold expiry

subscriber returns to the shared pool when the hold period ends

Default-off

operator-controlled

observe mode first; penalty move requires explicit operator enable

CGNAT shares public IPs across dozens of subscribers. One botnet infection on one CPE can blocklist that address — and take every innocent neighbour down with it. Isolation cuts the damage at the source.

The shared-IP reputation problem

This is the CGNAT problem that most operators only notice after it has already caused damage. The abuse scenario plays out the same way every time:

Without abuser isolation

Sub B's abuse gets the shared IP blocklisted. Subs A, C, D did nothing wrong — but they pay the price.

With abuser isolation

Sub B is isolated on a dedicated penalty IP. The shared pool stays clean. Subs A, C, D are unaffected.

How it works

The isolation mechanism wires two systems that already exist inside bngxdpd: the outbound-abuse detector and the CGNAT assignment layer. No separate appliance, no manual ticket, no latency.

Step 1 — Detect

Outbound abuse flagged in the data plane

Volumetric flood: pps rate exceeds the per-subscriber threshold
Fan-out scanner: high distinct-destination-IP rate (port-scan / botnet C2 pattern)
Both signals operate per-subscriber, at line rate, in XDP

Step 2 — Isolate

CGNAT assignment redirected to penalty IP

Flagged subscriber's outbound traffic is remapped to the dedicated penalty public IP
All other subscribers on the shared pool IP are unaffected — no rebinding, no disruption
The move itself is clean: port-blocks on the old IP are released, sessions are evicted, and a single audit line records exactly what happened
Happens automatically when scanner_enforce is enabled — but only after operators have watched candidates in observe mode

Step 3 — Restore

Returns to shared pool when hold expires

After the hold period, the subscriber is automatically moved back to the shared pool
If abuse resumes, the cycle repeats
Operator can release manually at any time

Operator commands

View current penalty assignments and move a subscriber manually

# Show current CGNAT penalty assignments bngxdpctl cgnat penalty show subscriber public IP (penalty) reason hold 100.72.18.44 203.0.113.99 scanner 14m remaining 100.72.22.110 203.0.113.99 volumetric 3m remaining # Manually move a known-bad subscriber to penalty IP bngxdpctl cgnat penalty move 100.72.18.201 # Release a subscriber back to the shared pool immediately bngxdpctl cgnat penalty release 100.72.18.44

Operators retain full control: view who is isolated and why, manually move a known-bad subscriber, or release a false-positive immediately.

Nothing moves until you've watched it happenObservability

Automatically relocating a subscriber's public IP is not a decision to make on faith. Isolation ships with three observability primitives so an operator can see exactly what the detector would do, see who is held right now, and see exactly what changed when a move actually happens.

1 — Candidate logging

Observe mode shows you every move before any move happens

In observe mode, the daemon evaluates the same detection logic used by enforcement — but only logs, never moves
Each candidate is logged as it would fire, with the triggering signal named
Run it for a week. Confirm the flagged subscribers are actually abusive before flipping scanner_enforce on

2 — Quarantine list

A live, read-only view of who is isolated right now

bngxdpctl quarantine list shows interface, mode, and abuse score for every held subscriber
No black box: isolation state is always queryable, not just inferable from logs
Safe to run at any time — read-only, does not affect enforcement

3 — Audited moves

Every real move is a single, correlated, accountable log line

When a subscriber is actually moved, bngxdpd releases their port-blocks on the old IP, evicts their sessions, and re-homes them onto the penalty IP with fresh port-blocks on next packet
All three actions are recorded together in one audit line — nothing silently leaks or lingers
Answers the question "what happened to their open sessions?" with a log line, not a guess

Observe mode: candidate logging before any subscriber is touched

# tail of bngxdpd.log with cgnat.abuser_isolation=observe CANDIDATE: would move sub 100.72.18.201 (source: scanner) → penalty 203.0.113.99 CANDIDATE: would move sub 100.72.19.87 (source: volumetric) → penalty 203.0.113.99 CANDIDATE: would move sub 100.72.18.201 (source: scanner) → penalty 203.0.113.99 # Operator reviews the candidate log for days before enabling enforcement. # 100.72.18.201 repeats — consistent with real scanning, not a one-off spike.

Observe mode runs the real detection logic and logs every move it would make — with zero subscriber impact — so operators can validate accuracy before enforcement is ever enabled.

Live quarantine visibility and a real, audited move

# Who is held right now? bngxdpctl quarantine list subscriber interface mode score 100.72.18.201 eth0.312 enforce 87 100.72.22.110 eth0.318 enforce 64 # bngxdpd.log — a real move, fully accounted for in one line F3: sub 100.72.18.201 moved 49.238.60.114 → 203.0.113.99 · released 6 blocks · evicted 11 sessions · re-home pending

One command shows every subscriber currently held. One log line shows every effect of a real move — port-blocks released back to the pool, sessions evicted, re-home pending on next packet. Nothing leaks, nothing is silent.

What the abuse detectors catch

The outbound-abuse detection that drives isolation operates on two independent signals, both measured per-subscriber at line rate in the XDP data path:

Signal	What it detects	Typical source
Volumetric flood	Per-subscriber pps rate exceeds threshold — a CPE generating a large outbound packet flood	IoT botnet (Mirai-class, Aisuru-class), DDoS amplifier, compromised NVR/DVR
Fan-out scanner	High rate of distinct destination IPs — a CPE probing many hosts in sequence	Port scanner, worm spreading, botnet C2 check-in sweep, credential-stuffing tool

Detection already existed. bngxdpd's outbound-abuse detection (volumetric + fan-out scanner) shipped as part of the Edge DDoS Protection feature. Abuser isolation adds the CGNAT redirect step — wiring the detector's output to the CGNAT assignment layer so a flagged subscriber's traffic leaves via a dedicated penalty IP rather than the shared pool address. The underlying detection mechanism is not new; the CGNAT consequence is.

Default-off. Observe before enforce.

Observe mode (default)

Detection runs, move candidates are logged via CANDIDATE: lines and abuse events are visible via bngxdpctl cgnat penalty show, but no CGNAT reassignment happens. Use this to calibrate thresholds and confirm the detector isn't flagging innocent subscribers before enabling enforcement.

Enforce mode (opt-in)

Detected abusers are automatically redirected to the penalty IP with a clean, audited move. Enable per-operator decision, only after observe mode has been reviewed. Manual override — move or release — remains available at all times regardless of mode.

Honest boundary: The penalty IP must be a dedicated, reserved pool address — not the operator's WAN or control-plane IP, which would dirty its own reputation if used as a penalty target. What happens to the penalty address's reputation with third parties (spam blocklists, CDN blocklists, gaming networks) depends on those third parties' policies, not on the BNG. The goal of isolation is to protect the shared pool IP from being affected by the abuser's traffic — not to guarantee the penalty IP remains clean. The mechanism is validated; on our own production boxes it currently runs in observe mode — penalty IP configured, enforcement not yet enabled — while we watch the candidate log.

No hardware upgrade required. Abuser isolation runs entirely inside the existing bngxdpd daemon and XDP data plane. The penalty IP is configured as a reserved address in the CGNAT pool. No new appliance, no additional licence, no backhaul to a scrubbing centre — the containment happens at the subscriber port, in the BNG that is already there.

The problem with shared IPs is collective punishment. Isolation ends it.

CGNAT is an address-sharing architecture. That sharing creates an inherent dependency: one subscriber's behaviour affects the reputation of an address that others rely on. Most operators accept this as a cost of CGNAT and deal with complaints one by one — CAPTCHAs, gaming bans, streaming refusals — without a tool to contain the source.

Abuser isolation removes the dependency. A flagged subscriber's abuse traffic never touches the shared pool address. The pool stays clean. Innocent subscribers are not affected. And when the hold expires, the subscriber returns automatically — no manual intervention required.

And it is never a black box: observe mode lets you watch move candidates for as long as you like before enforcement is on, bngxdpctl quarantine list shows exactly who is held right now, and every real move is logged as one audited line — port-blocks released, sessions evicted, re-home pending. You can always answer "who, why, and what happened to their sessions."

Want to see the detection thresholds and the penalty pool configuration? We'll walk through a live demo: trigger a fan-out scan on a test subscriber, watch the candidate log fire in observe mode, then enable enforcement and watch the audited move happen in real time.

Honest framing: This is an operations brief; no throughput or price figures are claimed. Abuser isolation is an extension of bngxdpd's existing outbound-abuse detection (volumetric pps threshold + fan-out distinct-destination-IP rate, both measured per-subscriber in the XDP data path). In observe mode, the daemon evaluates the same detection logic and logs every move it would make (CANDIDATE: would move sub <ip> (source: volumetric|scanner) → penalty <ip>) without touching any subscriber — this is the intended validation path before enabling enforcement. When a subscriber is flagged and isolation enforcement is enabled (scanner_enforce on), that subscriber's CGNAT assignment is redirected to a designated penalty public IP address separate from the shared pool; the move releases the subscriber's port-blocks on the old IP, evicts their sessions, and re-homes them on the penalty IP on next packet, all recorded in one correlated audit log line. bngxdpctl quarantine list gives a read-only, real-time view of every subscriber currently held (interface, mode, score). The shared pool IP is unaffected by an isolated subscriber's traffic. The subscriber is automatically returned to the shared pool when the configured hold period expires. The penalty IP must be a dedicated, reserved pool address, not the operator's WAN or control-plane IP. Isolation does not guarantee the penalty IP remains clean with third-party blocklists. Manual operator override (move / release) is available at all times. The feature is default-off; enforcement requires explicit operator configuration, and observe mode (candidate logging only) is the recommended and default first step. On our own production boxes, the mechanism currently runs in observe mode — penalty IP configured, enforcement not yet enabled. Related briefs: Edge DDoS Protection, Per-Subscriber CGNAT X-Ray, Self-Healing CGNAT, Full CGNAT.