High-Performance XDP BNG · CGNAT · QoS · Low-Latency · Lawful-Intercept Compliance

Broadband Gateway · Regulatory Compliance

Trace Any Public IP:Port Back to a Subscriber — Without Drowning in NAT Logs

Data-retention and lawful-intercept mandates require that every CGNAT translation be traceable: which subscriber held which public IP and port at what time. BNGSOFT answers that mandate directly from the XDP data plane — with block-based logging that cuts compliance storage by orders of magnitude, a deterministic NAT mode that needs no logs at all, and export to any standard IPFIX collector or syslog SIEM. No tap, no probe, no proprietary collector.

A subpoena or abuse complaint names a public IP, a port and a timestamp. You have minutes, not days, to answer "who was that?" — and the wrong design buries that answer under a billion per-connection log lines.

1 record

per port-BLOCK, not per
connection — orders-of-magnitude
less log volume

0 logs

deterministic NAT: reverse
lookup is computed, no stored
records needed

2 exports

syslog SIEM and IPFIX
collectors — simultaneously,
from the same events

tap, probe or proprietary
collector hardware — the data
plane is the probe

CGNAT events are generated where the translation happens: inside the XDP program, at line rate. The data plane writes each event to a BPF ring buffer; the bngxdpd daemon consumes it and fans it out to syslog (any facility/level, e.g. local4, into your SIEM) and to IPFIX via the dedicated, crash-hardened bngipfixd exporter — to one or more standard collectors. No separate tap span, no mirrored port, no probe appliance: the forwarding path is the measurement path.

1 · The mandate, and the trap most designs fall into

THE LEGAL REQUIREMENT

"Identify the subscriber behind a public IP:port at time T."

Data-retention and lawful-intercept regimes (e.g. India DoT directions, EU frameworks) require CGNAT translations be traceable to an individual subscriber.
An abuse complaint or court order arrives with a public IP, a port, and a timestamp — nothing else.
You must map that back to a private IP / session identity, fast and defensibly.
Without it, the operator — not the subscriber — carries the liability.

THE NAÏVE TRAP

Per-flow NAT logging: one record per connection.

A busy subscriber opens thousands of connections an hour — every one a log line.
Across a full BNG that is a firehose: terabytes of retention storage, saturated collectors, slow forensic search.
The exporter itself becomes a bottleneck and a reliability risk at peak.
You pay enormous storage cost to retain data you will almost never query.

BNGSOFT sidesteps the trap two ways. Block-based logging records one row per port-block allocation — covering thousands of connections per row — instead of one row per connection. And deterministic NAT makes the public allocation a pure function of the private IP, so the reverse lookup is computed on demand with no stored logs at all. You still satisfy "trace any IP:port at time T," at a fraction of the storage.

2 · Where the events come from — the data plane is the probe

Most compliance architectures bolt a separate capture probe or tap onto the network and reconstruct NAT state from mirrored packets. BNGSOFT has no such seam: the XDP program that performs the translation also emits the compliance event, in the same pass, at line rate.

DATA PLANE · XDP

Translation and logging happen together

cgnat_log_rb

BPF ring buffer written by the XDP program

The XDP CGNAT path allocates a port-block / creates a flow, then pushes a structured event onto the ring buffer.
No copy out to userspace per packet; no mirrored traffic; no probe NIC.
Runs at forwarding speed on the same cores that do the NAT.

CONTROL PLANE · bngxdpd

One consumer, two simultaneous exports

syslog + IPFIX

SIEM and flow-collector, from the same event stream

bngxdpd drains the ring buffer and formats each event once.
(a) syslog — configurable facility/level (e.g. local4) into any SIEM.
(b) IPFIX — via bngipfixd to one or more standard collectors.

The event types the data plane emits

PORT-BLOCK ALLOCATION

The compliance anchor.

Subscriber identity → public IP + port-range + timestamp.
One row covers the whole block — thousands of connections.
This single record type satisfies the core traceability mandate.

PORT-BLOCK RELEASE

Closes the time window.

Marks when the public IP:port-range stopped belonging to that subscriber.
Allocation + release together bound the exact interval for time-T queries.

FLOW TRANSLATION

Per-flow create / destroy.

Optional finer granularity carrying the destination 5-tuple.
For deployments that require per-session detail on top of block records.

IPv4-PUBLIC FLOWS

Non-CGNAT visibility.

Flow events for directly-routed public-IPv4 subscribers (no NAT).
Same pipeline, same collectors.

IPv6 FLOWS

Dual-stack coverage.

IPv6 flow events alongside the IPv4/CGNAT records.
Compliance visibility for the v6 side of a dual-stack subscriber base.

RECORD CONTENTS

What every row carries.

Private IP / session identity, public IP, port range/block, protocol.
Allocation + release timestamps; flows add the destination 5-tuple.

Why "no probe" matters: a separate NAT-logging probe or tap is extra hardware to buy, rack, power, and keep in sync with the forwarding state — and it reconstructs translations after the fact from copied packets, which can drift from ground truth. Here the record is emitted by the exact code that did the translation, so it is authoritative by construction.

3 · Block-based logging — orders of magnitude less storage ILLUSTRATIVE FORMAT

Each subscriber is assigned blocks of public ports — for example 128 ports per block, up to 16 blocks per user. You log once per block allocation, not once per connection. That one record — subscriber identity → public IP + port-range + timestamp — already answers "who held this port at time T" for every one of the thousands of connections that block carries.

Compliance log volume — per-flow NAT logging vs block-based (relative, illustrative)

A single active subscriber, one busy hour. The shape — not the exact figure — is the point: block records scale with port-block churn, not with connection count.

Per-flow NAT logging

~thousands of records / subscriber / hour

baseline

Block-based (this product)

a handful

orders of magnitude fewer

Dimension	Per-flow NAT logging	Block-based logging (BNGSOFT)
Records generated	One per connection — scales with traffic; a busy host emits thousands/hour.	One per port-block allocation — scales with block churn, typically a handful per subscriber.
Retention storage	Terabytes; grows with subscriber activity, not just count.	Orders of magnitude smaller for the same retention window.
Forensic query speed	Search a firehose of per-connection rows.	Search a compact set of block rows; the matching row directly names the subscriber and interval.
Answers "who held IP:port at T?"	Yes — at high cost.	Yes — the block's IP + port-range + alloc/release window contains the answer.
Exporter / collector load at peak	High; the exporter can become the bottleneck.	Low; far fewer records to format, ship and index.

A block-allocation compliance record, as exported ILLUSTRATIVE FORMAT

root@bng-edge-07:~# tail -f /var/log/cgnat-compliance.log  # syslog local4, SIEM feed

<164>1 2026-06-12T14:02:11Z bng-edge-07 bngxdpd - cgnat -
  event=block-alloc  sub=100.71.18.43  session=ppp0  public=203.0.113.50
  ports=18432-18559  block=144  proto=tcp  alloc_ts=2026-06-12T14:02:11Z

<164>1 2026-06-12T14:48:55Z bng-edge-07 bngxdpd - cgnat -
  event=block-release  sub=100.71.18.43  public=203.0.113.50
  ports=18432-18559  block=144  release_ts=2026-06-12T14:48:55Z

Illustrative record format (field layout shown for clarity; not a verbatim production capture). One alloc + one release row bound the exact window 14:02:11–14:48:55Z during which subscriber 100.71.18.43 (session ppp0) held public 203.0.113.50:18432-18559 — covering every connection that block carried. The same event is exported in parallel as an IPFIX record to your flow collector.

The compliance math: you do not need a log per connection to answer a per-connection question. You need to know which subscriber owned which public ports during which interval — and a port-block allocation record captures exactly that, for thousands of connections at once.

4 · Deterministic NAT — zero-log compliance

Block-based logging slashes volume. Deterministic NAT eliminates it. In deterministic mode the public IP:port allocation is a pure mathematical function of the subscriber's private IP — the mapping is fixed and reproducible, not dynamically assigned. So the reverse lookup, given a public IP:port at time T, is computed rather than looked up in a log. You satisfy lawful-intercept traceability with no stored records at all.

HOW IT WORKS

The mapping is the algorithm.

Public IP:port is derived deterministically from the private IP.
Given a public IP:port, the daemon runs the inverse function to recover the private IP / subscriber.
Nothing to write, ship, index or retain for the deterministic case.
The answer is exact and instantaneous — no log search, no retention gap.

THE COMMAND

One line, no logs queried.

bngxdpctl cgnat deterministic <ip:port>
Returns the subscriber/private IP that maps to that public IP:port.
Works even with logging disabled entirely — there is nothing to look up.
Removes the storage line item from the compliance budget.

Zero-log reverse lookup — answer an abuse complaint in one command ILLUSTRATIVE FORMAT

root@bng-edge-07:~# bngxdpctl cgnat deterministic 203.0.113.50:18510
=== deterministic reverse-lookup ===
  public     : 203.0.113.50:18510
  subscriber : 100.71.18.43  (private)
  block      : 144    ports 18432-18559
  method     : computed  (deterministic mapping — no log records consulted)

Illustrative output format. The mapping is reproduced by inverting the deterministic allocation function — no compliance log is read, because none is required in deterministic mode. The lookup is exact regardless of retention window.

"Zero-log compliance" is not zero capability — it is zero storage. The traceability requirement is met by the determinism of the mapping itself. For operators in retention regimes, deterministic mode reframes the cost question entirely: the cheapest log to store, secure and audit is the one you never had to write.

Honest framing: deterministic mode trades some public-IP packing efficiency for the zero-log property, and not every deployment can run it. Where dynamic allocation is required, block-based logging is the answer — still orders of magnitude lighter than per-flow NAT logging. The two modes are complementary; the right choice depends on pool sizing and jurisdiction.

5 · bngipfixd — a hardened exporter built for flow volume

The IPFIX side of the export is handled by bngipfixd, a dedicated exporter daemon (v1.12.x) that runs alongside bngxdpd. It is engineered for the high record rates a CGNAT BNG produces and was crash-hardened with a dedicated crash handler after a field incident — because a compliance exporter that silently dies is worse than no exporter at all.

FLOW AGGREGATION

Built for volume.

Aggregates flows before export to keep collector load sane.
Sized for the record rates a busy CGNAT box generates.

MULTIPLE COLLECTORS

Fan-out, no single point.

Export to one or more IPFIX/NetFlow collectors in parallel.
Configurable template-refresh interval for collector compatibility.

CRASH-HARDENED

Stays up under load.

Dedicated crash handler added after a real field incident.
Plus a series of robustness fixes through the 1.12.x line.

STANDARD WIRE FORMAT

No proprietary lock-in.

Standard IPFIX / NetFlow — works with collectors you already own.
No vendor-specific collector appliance required.

SYSLOG IN PARALLEL

SIEM and flow-store both.

bngxdpd emits syslog (e.g. local4) at the same time as IPFIX.
One event stream, two retention systems — SIEM search and flow forensics.

SEPARATE DAEMON

Isolated by design.

Runs as its own process beside bngxdpd, so export load never touches the forwarding path.
Restart/upgrade the exporter without disturbing the data plane.

Compliance requirement	How BNGSOFT satisfies it
Trace public IP:port → subscriber at time T	Block-allocation records (subscriber → public IP + port-range + alloc/release timestamps), or computed via `cgnat deterministic` with no logs.
Feed an existing SIEM	syslog export, operator-chosen facility/level (e.g. `local4`).
Feed an existing flow collector	IPFIX via bngipfixd to one or more standard collectors; no proprietary collector.
Per-session detail when required	Per-flow translation records carrying the destination 5-tuple, on top of block records.
Dual-stack coverage	IPv6 flow events and public-IPv4 (non-CGNAT) flow events in the same pipeline.
No new capture hardware	The XDP data plane is the probe; events emitted at line rate, no tap/span/probe appliance.

6 · Operating it — the commands you actually run

Compliance is not just the export pipeline; it is the day-to-day operator view of the CGNAT pool. Three commands cover monitoring, forensic lookup, and pool health.

cgnat

CGNAT stats at a glance.

Active sessions, active users, blocks in use.
Created / destroyed counters, protocol breakdown.
The "is the NAT healthy" dashboard line.

cgnat public

Public-pool / block usage.

Per public IP: how many blocks are in use.
Spot pool exhaustion and hot public IPs before they bite.

cgnat deterministic <ip:port>

No-log reverse lookup.

Public IP:port → subscriber, computed.
The one-command answer to an abuse complaint.

Pool and CGNAT health snapshot ILLUSTRATIVE FORMAT

root@bng-edge-07:~# bngxdpctl cgnat
=== CGNAT ===
  active users     : 7,940
  active sessions  : 1,284,506
  blocks in use    : 31,612
  created / destroyed : 9,204,113 / 9,172,501
  proto           : tcp 71%  udp 27%  icmp 2%

root@bng-edge-07:~# bngxdpctl cgnat public
=== public pool ===
  public IP      blocks-used   use%  status
  --------------------------------------------
  203.0.113.50       418      82%  BUSY
  203.0.113.51       233      46%  OK
  203.0.113.52        91      18%  OK

Illustrative output format (field layout for clarity; numbers are not a verbatim production capture). cgnat public surfaces per-public-IP block usage so operators see pool pressure before exhaustion; cgnat gives the rolling CGNAT health line for dashboards and NOC alerts.

One toolchain, the whole compliance loop: watch the pool (cgnat / cgnat public), export the records (syslog + IPFIX via bngipfixd), and answer the legal request (cgnat deterministic or a block-record search). No separate compliance product to license and integrate.

7 · What it means for the business

Regulatory Compliance · operator value

Meet the mandate, defensiblyEvery CGNAT translation is traceable to a subscriber and time window — the core data-retention / lawful-intercept requirement — emitted by the code that does the translation.

↓

Slash compliance storage costBlock-based logging records one row per port-block instead of one per connection; deterministic mode stores nothing at all. Orders of magnitude less retention storage vs per-flow NAT logging.

⚡

Abuse-to-subscriber in one commandA complaint names a public IP:port and time; cgnat deterministic or a compact block-record search returns the subscriber fast — no firehose to grep.

∞

Use the collectors you ownStandard IPFIX/NetFlow and standard syslog SIEM — both simultaneously. No proprietary collector, no vendor lock-in on the retention side.

No probe hardwareThe XDP data plane is the probe, at line rate. No tap, span port, or capture appliance to buy, rack, power and keep in sync.

★

Hardened, isolated exporterbngipfixd runs as its own crash-hardened daemon beside the forwarder, built for high flow volume — so compliance export never threatens the data plane.

The bottom line

Lawful-intercept and data-retention rules demand that you can name the subscriber behind any public IP:port at any time. BNGSOFT answers that directly from the XDP data plane — with block-based logging that records one row per port-block instead of one per connection, and a deterministic mode that computes the answer with no stored logs at all.

Export to the SIEM and the flow collector you already run, simultaneously, through a hardened dedicated exporter. Meet the mandate, cut the storage bill by orders of magnitude, and answer the next subpoena in one command — with no tap, no probe, and no proprietary collector.

Methodology and honest framing: This document describes the CGNAT logging and lawful-intercept traceability capabilities of the BNGSOFT XDP BNG. The grounded capabilities are: CGNAT events are generated inside the XDP data plane and written to a BPF ring buffer (cgnat_log_rb); the bngxdpd daemon consumes that ring buffer and exports each event two ways simultaneously — (a) syslog at an operator-configurable facility/level (e.g. local4) for SIEM ingestion, and (b) IPFIX, via the dedicated bngipfixd exporter daemon, to one or more standard collectors. Logged event types are port-block allocation, port-block release, per-flow translation create/destroy, public-IPv4 (non-CGNAT) flow events, and IPv6 flow events. Records carry subscriber private IP / session identity, assigned public IP, port range/block, protocol, and allocation/release timestamps; flow records additionally carry the destination 5-tuple. Block-based logging records one row per port-block allocation (e.g. 128 ports per block, up to 16 blocks per user), which covers many connections per row and reduces compliance log volume substantially compared with per-flow NAT logging while still satisfying "trace any public IP:port at time T to a subscriber." Deterministic NAT mode makes the public IP:port a pure function of the subscriber's private IP, so the reverse lookup is computed via bngxdpctl cgnat deterministic <ip:port> with no stored logs. Operational commands shown — bngxdpctl cgnat, bngxdpctl cgnat public, and bngxdpctl cgnat deterministic — exist as described. bngipfixd is a separate daemon (v1.12.x) that runs alongside bngxdpd; it provides flow aggregation, a configurable template-refresh interval, multiple-collector support and syslog, and was hardened with a dedicated crash handler after a field incident. Illustrative material: every terminal block, the log-record layout, the per-IP pool table, and the volume-comparison chart in this document are marked ILLUSTRATIVE FORMAT — they show the shape of the real output and record fields, with example node names (NodeA, bng-edge-07), example addresses from the documentation ranges (RFC 5737 / RFC 6598), and example counts; they are not verbatim production captures, and no real customer names or precise benchmark figures are claimed. The "orders of magnitude" storage reduction describes the structural difference between per-block and per-connection record generation; the exact factor depends on per-subscriber connection-to-block-churn ratios in a given deployment. Implementation status: port-block allocation, port-block release, and per-flow CGNAT translation logging are the fully-implemented core; the public-IPv4 per-flow event path exists in the pipeline. Not legal advice: exact regulatory obligations (which event types, what fields, what retention period, what intercept interface) vary by jurisdiction and change over time. BNGSOFT provides the traceability data and flexible standard export; mapping that to a specific legal regime (e.g. India DoT directions, EU frameworks) is the operator's responsibility in consultation with counsel. Prepared as a management and compliance-architecture overview for large-scale operators. Lawful-Intercept Compliance features are part of the BNGSOFT XDP BNG product.