WireGuard & VRFs

Encrypted tunnels and routing isolation, built into the BNG and configured from the same CLI as everything else.

Why it's here

RADIUS is the BNG's most sensitive conversation. It carries subscriber identities, credentials, session state and the authority to disconnect or re-rate a customer. Plenty of networks end up sending it across a transit link because the AAA platform lives somewhere else.

AthenaBNG can put that entire conversation — authentication, accounting and Change-of-Authorization — inside a WireGuard tunnel that terminates in its own VRF, so the RADIUS server never needs a public address and BNG↔AAA traffic never shares a routing table with subscriber traffic.

VRFs

A VRF declared in the configuration is created and owned by the BNG. abngd builds the master device and its routing table on commit, and rebuilds it at startup — a VRF is runtime state that does not survive a reboot on its own.

abng# set vrfs vrf-radius table 300

Two VRFs sharing a routing table silently merge their routes, so a duplicate table id is refused at commit rather than accepted and left to cause a mystery later.

WireGuard tunnels

In-kernel WireGuard — the module ships with the Linux kernel the BNG runs on, so there is no userspace data path to slow things down.

abng# set wireguard wg-radius private_key <base64>
abng# set wireguard wg-radius addresses 10.255.10.2/30
abng# set wireguard wg-radius vrf vrf-radius
abng# set wireguard wg-radius peers <peer-key> endpoint radius.example.net:51820
abng# set wireguard wg-radius peers <peer-key> allowed_ips 10.255.10.1/32
abng# set wireguard wg-radius peers <peer-key> persistent_keepalive 25
abng# commit

A tunnel is reconciled to exactly what the configuration declares: peers removed from the config are removed from the running tunnel, withdrawing a prefix from allowed_ips actually withdraws it, and deleting or disabling a tunnel tears the interface down. Keys are validated at commit rather than failing halfway through being applied, and are never passed to the kernel tooling on a command line where they would be visible in the process list.

The vrf setting enslaves the tunnel interface, so traffic inside the tunnel lives in that routing domain. The encrypted packets still leave by the global table, which is what you want when the far end is reached over your transit.

Putting RADIUS in the tunnel

abng# set radius servers 10.255.10.1 secret <shared-secret>
abng# set radius vrf vrf-radius
abng# set radius source_address 10.255.10.2
abng# set radius coa_bind_address 10.255.10.2
abng# set radius coa_vrf vrf-radius
abng# commit

That covers the whole AAA path in one place:

	Direction	Now travels via
Authentication	BNG → server	tunnel, in vrf-radius
Accounting	BNG → server	tunnel, in vrf-radius
CoA / Disconnect	server → BNG	tunnel, listener bound in vrf-radius

source_address fixes the address the server's client list is keyed on, so the BNG's RADIUS identity no longer depends on which interface a packet happened to leave by.

Operationally

• Survives reboot. The VRF, the tunnel, its addresses, its VRF membership and its peers are all rebuilt from the configuration at startup.
• No restart needed. Changing tunnel or CoA settings takes effect on commit; the CoA listener is rebound in place rather than requiring a daemon restart that would drop live subscriber sessions.
• Fails safe. A tunnel that cannot be applied warns and leaves the rest of the commit intact, and a CoA listener that cannot bind never prevents the BNG from starting.

See the WireGuard configuration reference for the full option list and verification commands.