Subscriber Authentication

This page explains how our platform authenticates subscribers, the methods available, how they are inherited across Virtual Servers, Clients and Service Profiles, and the optional Calling-Station-ID fallback used to migrate or onboard MAC-based (IPoE) subscribers.

It is aimed at operators configuring the platform for the first time. If you are new to RADIUS, it helps to know that every login produces an access-request from your NAS/BNG, and our platform replies with an access-accept (allow) or access-reject (deny).

Overview

The platform supports the access models used by broadband and wireless ISPs:

PPPoE — the subscriber logs in with a username and password. This is the traditional broadband model.
IPoE / MAC-Based Authentication — the subscriber's device is identified by its MAC address (presented as the RADIUS Calling-Station-Id), with no password. This is common on fibre (IPoE), fixed-wireless and hotspot networks.
Hotspot — the subscriber is authenticated either with a username and password (captive-portal login) or by their device MAC address (MAC-based auto-login after the first sign-in). This is common on public Wi-Fi and guest networks.
Mobile APN Authentication — the mobile device is authenticated when it attaches to an APN. The username presented for the APN session identifies the subscriber, with or without a password depending on the APN configuration.
MS-ISDN Authentication — the subscriber is identified by their mobile number (MSISDN), with no password. This is used on mobile and LTE/5G networks where the MSISDN is the subscriber identity.

When a password is required, the platform accepts it in any of the standard RADIUS password protocols and detects the correct one automatically from the access-request:

PAP — Password Authentication Protocol (RFC 2865).
CHAP — Challenge-Handshake Authentication Protocol (RFC 2865).
MS-CHAPv1 — Microsoft CHAP version 1 (RFC 2433).
MS-CHAPv2 — Microsoft CHAP version 2 (RFC 2759), including MS-MPPE keying (RFC 3079).

You do not choose the password protocol on the platform — the NAS/BNG decides which one to send, and the platform responds appropriately. Your only choice is the authentication method (below), which decides what must match.

Authentication Methods

An authentication method decides which parts of the access-request must match a subscriber account before access is granted.

Method	What must match
username	Only the username. No password is checked. Suitable for IPoE / MAC-based access where the username carries the MAC.
username+password	The username and password. The standard PPPoE model.
username+calling-station-id	The username and the device Calling-Station-Id (MAC). No password is checked. Suitable for MAC-based (IPoE) access identified by device rather than username.
username+password+calling-station-id	The username, password and the device Calling-Station-Id (MAC). Binds the account to a specific line/device. See Locking an account to a device.

Locking an account to a device

The username+password+calling-station-id method (and, more generally, a Calling-Station-Id stored on the account) ties a subscriber to a specific device or line. If the MAC presented by the NAS does not match the value on the account, the login is rejected with "Username + Calling-Station-ID mismatch". Use this to stop credential sharing or to pin a service to a known ONT/CPE.

This lock — often called a station lock — is applied whenever a Calling-Station-Id is stored on the account, regardless of the authentication method. The only time it is not applied is when the Calling-Station-ID fallback is enabled on the Virtual Server or Client: because the fallback is a migration tool that expects devices to move between lines, enabling it relaxes the station lock on that path so a changed MAC is not rejected while you migrate.

Where Authentication Is Configured (Inheritance)

Authentication can be set at three levels. The most specific level that is set wins, and any level left blank simply inherits from the level above it:

Level	Purpose	Options
Virtual Server	The base method for the whole Virtual Server. Always set (defaults to username+password).	username, username+password, username+password+calling-station-id username+calling-station-id
Client (NAS)	Optional override for a specific NAS/Client. Leave blank to inherit the Virtual Server.	(blank = inherit), username, username+password, username+password+calling-station-id username+calling-station-id
Service Profile	Optional override for subscribers on a Service Profile. Leave blank to inherit. A Service Profile cannot use the calling-station-id method.	(blank = inherit), username, username+password

How the effective method is decided

The login lookup (how we find the account, and whether the device MAC is part of that lookup) follows the Client, otherwise the Virtual Server.
The final decision (whether a password is required) follows the Service Profile if set, otherwise the Client, otherwise the Virtual Server.

In short: set a sensible default on the Virtual Server, override per NAS on the Client when a particular BNG behaves differently, and relax or tighten the password requirement per plan on the Service Profile.

Calling-Station-ID Fallback

The Calling-Station-ID fallback is a separate, optional feature that helps you migrate PPPoE subscribers to IPoE / MAC-based access without a flag day, or run both models side by side during a transition.

What it does

Normally, if the username in a request does not match any subscriber, the login is rejected. With the fallback enabled, the platform does one extra thing before giving up: it takes the request's Calling-Station-Id (the device MAC) and looks for a subscriber carrying that MAC, trying two places in order:

a subscriber whose Calling-Station-Id matches the MAC; then
if none is found, a subscriber whose username matches the MAC.

If either lookup finds an account, the device is admitted with no password. Each lookup must resolve to a single subscriber — if the MAC matches more than one account the request is rejected as ambiguous rather than guessing.

Both lookups reuse ordinary indexed columns (the subscriber's calling_station_id, then its username), so there is no separate table.

Migration example: PPPoE to IPoE / MAC-Based

Suppose you have a base of PPPoE subscribers and you want to move them to IPoE (MAC-based) as CPE is swapped out, without disrupting anyone still on PPPoE.

Enable the fallback on the Virtual Server (or just the Client/BNG you are migrating). Enabling it at either level turns it on for that path.
Provision the MAC identity. For each device being migrated, create (or update) a subscriber that carries the device MAC — stored either in the subscriber's Calling-Station-Id or as its username — exactly as the NAS presents it in the request's Calling-Station-Id.
Cut the device over to IPoE. When the NAS now sends an access-request for that device:
- If it still presents the PPPoE username + password, that account is found and authenticated as before — nothing changes.
- If it presents an unknown username (or the MAC) with no usable password, the normal lookup misses and the fallback matches the request's Calling-Station-Id against the subscriber's Calling-Station-Id first, then its username, admitting the device with no password.
Retire PPPoE for that subscriber whenever you are ready. Both models work throughout the transition, so you migrate device by device at your own pace.

Enabling it

Turn the fallback on in Subscriber (AAA) > Virtual Servers > {server} > Overview, or per Client in the Client form, using the Calling-Station-ID fallback toggle. Enabling it on either the Virtual Server or the Client turns it on for that path.

Safety

With the fallback left off (the default), authentication is unchanged and any Calling-Station-Id stored on an account is strictly enforced as a station lock. Turning the fallback on is a deliberate migration step: as well as admitting unknown devices by MAC, it relaxes the station lock on that Virtual Server or Client so devices can move between lines. Leave it off on any path where you want the Calling-Station-Id lock strictly enforced.