Glossary

PPPoE Server

What is a PPPoE Server

A PPPoE server is the network-side endpoint of a PPPoE (Point-to-Point Protocol over Ethernet) connection. Subscriber devices such as routers, ONTs, and PCs dial in as PPPoE clients; the PPPoE server is the device that answers those dial-ins, verifies who is connecting, assigns each subscriber an address, and keeps track of every active session.

In broadband networks, this role is performed by a Broadband Network Gateway (BNG), also known as a BRAS. When the same functionality runs in software on a standard gateway platform rather than on dedicated carrier hardware, it is often called a vBNG (virtual BNG). A vBNG turns an ordinary Layer 3 gateway into a subscriber-aware access node: it handles client dial-ups, supports centralized authentication, authorization, and accounting (AAA) for billing, and provides Internet access through NAT. That makes it a practical fit for ISPs, enterprise campuses, hotels, and other environments where each user needs to log in individually.

How a PPPoE Server Works

A PPPoE server brings several functions together on one device.

Answering dial-in requests. The server listens on a designated Layer 2 interface for clients searching for a PPPoE service. It identifies itself with an AC name (Access Concentrator name) and advertises a service name, which clients can use to select which service they want. How strictly the server matches service names is configurable. With a setting that accepts any service, no service name needs to be configured on either the server or the client. With a setting that accepts blank service names, the server must have a service name configured, and the client must leave its own service name blank.

Authenticating subscribers. The server can verify credentials in two ways. In an enterprise or carrier deployment, it acts as a NAS (Network Access Server) toward an external RADIUS server, forwarding each subscriber's credentials — typically using CHAP — for verification, and identifying itself to the RADIUS server by a NAS IP address. The RADIUS server then returns an accept or reject decision, and the same server can provide accounting for billing. In a small standalone deployment, the server can instead check credentials against its own local user database.

Assigning IP addresses. Once a subscriber is authenticated, the server must give it an address, and there are two models. In the first, the gateway keeps a local IP pool — a defined range of addresses — and hands them out itself, while authentication still happens on the RADIUS server. In the second, fully centralized model, the RADIUS server manages the IP pool as well, so authentication, address allocation, and billing all live in one place and the gateway simply applies what RADIUS returns. The server itself presents a virtual gateway IP (a local address and mask) to dial-in clients, and it can hand them parameters such as a DNS server address.

Connecting subscribers to the Internet. PPPoE clients typically receive private addresses. To reach the public Internet, either the upstream core network must provide NAT, or the gateway itself can perform source NAT (SNAT), translating subscribers' private addresses to the WAN uplink address.

Tracking sessions. For every connected subscriber, the server maintains a session record — including its session ID, the client's MAC address, the assigned remote IP and local IP, the logical interface, the server instance, and how long the session has been up — which operators use to confirm that a client has connected successfully.

One operational point deserves attention: if a RADIUS server is configured but becomes unreachable, the server does not automatically fall back to its local user database. The RADIUS binding must be removed manually before local credentials take effect, so deployments should plan for RADIUS availability accordingly.

Why a PPPoE Server is Beneficial

  • Per-subscriber control on an Ethernet network: Every user authenticates individually and receives a dedicated session, which enables per-user policies, accounting, and billing on infrastructure that would otherwise treat all users alike.

  • Centralized AAA: Integrating with a RADIUS server consolidates user management and billing in a single system instead of spreading credentials across individual access devices.

  • Flexible address management: A local pool is simple to deploy, while RADIUS-managed pools suit larger deployments that want authentication, allocation, and billing in one place — and operators can move from the first to the second without redesigning the network.

  • Deployable in stages: A common approach is to start with RADIUS authentication and a local IP pool, verify that sessions establish correctly, and then migrate IP allocation to RADIUS.

  • A standalone option for small or isolated networks: Local authentication with SNAT lets a single gateway serve dial-in users with no external AAA infrastructure, which also makes it suitable as an emergency fallback configuration.

  • Software-based and cost-effective: Running the server function on a general-purpose gateway platform avoids the cost of dedicated BNG hardware.

At Asteraix

What We Can Do at Asteraix

AsterNOS-VPP turns the Asterfusion Open Intelligent Gateway into a high-performance vBNG, with documented configurations for both enterprise RADIUS integration and standalone operation.

  • Enterprise RADIUS integration: radius server <ip> mode pppoe (which must be configured first), followed by auth-type chap and passkey, defines the RADIUS server, and ppp chap radius-server <ip> plus nas-ip <ip> inside the PPPoE server instance bind it for authentication and accounting. The documented reference setup uses FreeRADIUS as the AAA server.

  • Global enablement and instance configuration: pppoe-server enable turns the function on, and interface pppoe-server <id> defines an instance with service-name, ac-name, a virtual gateway (local-ip <ip> <mask>), and dns-server. The instance is then attached to a physical LAN port with pppoe-server <id> under that interface.

  • Flexible service-name matching: accept-any-service enable and accept-blank-service enable let operators choose how strictly the server matches the client's requested service.

  • Two IP allocation models: A local pool (ip-pool <name> with ip-range <start> <end>, bound with remote-ip-pool <name>) works with RADIUS authentication in the baseline setup, and no remote-ip-pool <name> shifts allocation to RADIUS for a fully centralized architecture — with the documented FreeRADIUS configuration showing how the RADIUS-side pool is defined and assigned to a user.

  • Standalone mode with local authentication and NAT: ppp chap username <user> <password> defines a local user, and nat enable, nat pool, nat binding, and nat-zone on the WAN interface provide source NAT so locally authenticated subscribers can reach the Internet through the uplink address.

  • Clear verification: show pppoe-session lists each active session with its session ID, remote MAC, remote and local IPs, logical interface, PPPoE server instance, and uptime.