Configuring ProL2TP as a PPPoE Access Concentrator

ProL2TP and kacd (the Katalix Access Concentrator Daemon) can be configured to operate as a PPPoE Access Concentrator using RADIUS to authenticate and route incoming sessions. This article is a guide to configuring such a setup.

Operation

The kacd daemon runs on the LAC machine, and accepts incoming PPPoE connections from client machines. The daemon extracts PPP traffic from the PPPoE container before interfacing with the ProL2TP daemon (prol2tpd) to route the PPP frames to the LNS over an L2TP PPP pseudowire.

Setting up this connection consists of a number of stages. When a new PPPoE connection is made, kacd performs LCP negotiation with the client to gather the client's PPP authentication parameters. It then contacts one or more configured RADIUS servers to attempt to authenticate the session. Once the session is successfully authenticated, the RADIUS server returns details of an L2TP tunnel which the incoming PPPoE session should be switched into. The kacd daemon then provides this information to prol2tpd to create a tunnel and session for transmission of the PPP traffic to the LNS. Finally, kacd connects the incoming PPPoE and outgoing L2TP sessions within the kernel.

Prerequisites

Install the l2tp-drivers, prol2tp and kacd packages on the machine which will be used as the LAC using your distribution's package management tools. These packages are available for download from the ProL2TP support portal. Contact your sales representative if you have not already received your support portal account details.

Ensure that the l2tp_ac_pppoe kernel driver is loaded. This driver is distributed in the l2tp-drivers package which you should have received with your software distribution. It will be loaded by the kacd init script for your distribution.

Configuration

Configuring kacd

The following kacd configuration instructs kacd to listen for incoming PPPoE connections on eth0, perform authentication with the connecting client, and then use the authentication details to authenticate the client with the radius server at 'myradiusserver.mydomain'. Once authenticated, the RADIUS server will return attributes which are used by kacd to select the destination LNS and local ProL2TP tunnel profile.

route "test" {

	source pppoe {
		interface "eth0"
		service_name any
	}

	destination radius {
		ppp_auth_protocols "pap"

		server "myradiusserver.mydomain" {
			secret "testing123"
		}
	}

}

This should be placed in the file '/etc/kacd/kacd.conf' on the LAC, and the kacd service restarted. Further details about the configuration of kacd can be found in the kacd.conf manual page.

Configuring ProL2TP on the LAC

Typically the ProL2TP LAC configuration will be very simple:

systemContains attributes that may be used to control the system behavior of ProL2TP, i.e. tunnel instance limits, UDP port number, debug logging options etc. There is always one instance of this object and it has no name. {
       # Don't let this system be used as a LNS
       deny_remote_tunnel_createsDeny the creation of new tunnels by remote peers. yes
       operational_mode lac
}

tunnel profileProvides a named set of L2TP tunnel parameters which may be used when creating tunnels locally (by specifying the tunnel profile name when the tunnel is created) or when tunnels are created by remote request. "test" {
       # Use L2TPv2
       proto_versionThe protocol version of a tunnel. 2 means L2TPv2. 3 means L2TPv3. Default is 0, which means either L2TPv2 or L2TPv3 is acceptable. For clients, the value 0 causes ProL2TP to send its tunnel setup request in a form that will work with both L2TPv2 and L2TPv3 peers. 2
}

The tunnel profile should contain any parameters needed for the to LAC establish a tunnel to the LNS.

LNS Configuration

The LNS need not be running ProL2TP, but it should be configured so that it can:

  • accept incoming tunnels and PPP sessions from the LAC
  • authenticate incoming PPP sessions and provide IP addresses via IPC

The ProL2TP configuration for the LNS would look something like this:

systemContains attributes that may be used to control the system behavior of ProL2TP, i.e. tunnel instance limits, UDP port number, debug logging options etc. There is always one instance of this object and it has no name. {
    # Don't let this system be used as a LAC
    deny_local_tunnel_createsDeny the creation of new tunnels by local request. yes
    operational_mode lns
}

ppp profileProvides a named set of PPP parameters which are to be used when creating PPP sessions in L2TP tunnels. "default" {
    ip_pool_nameThe name of an IP pool from which to allocate local and remote IP addresses if not otherwise assigned.  This value may be passed to RADIUS if RADIUS is configured, or used to locate a local IP pool defined using an ip pool block. "default"
    auth_papAllow PPP PAP authentication. Default=YES. Deprecated. Use auth_refuse_pap instead. yes
    auth_chapAllow PPP CHAP authentication. Default=YES. Deprecated. Use auth_refuse_chap instead. no
    auth_mschapv1Allow PPP MSCHAP authentication. Default=YES. Deprecated. Use auth_refuse_mschapv1 instead. no
    auth_mschapv2Allow PPP MSCHAPV2 authentication. Default=YES. Deprecated. Use auth_refuse_mschapv2 instead. no
    auth_eapAllow PPP EAP authentication. Default=YES. Deprecated. Use auth_refuse_eap instead. no
    auth_noneAllow unauthenticated PPP users. Default=NO for network-created sessions, and YES for locally created sessions. no
}

ip poolDefines a named IP address pool. The prol2tpd daemon assigns IP addresses from a named pool when configured to do so using the ip_pool_name parameter in ppp or ethernet profiles. "default" {
    ip_rangeA range of IP addresses assigned to the pool. The range is defined as the first and last IP address (inclusive). Multiple first/last address pairs may be specified. {
    	10.1.1.1 10.1.1.254
    	10.2.1.1 10.2.1.100
    }
}

If using ProL2TP on the LNS, the PAP authentication parameters for the client should be configured in /etc/ppp/pap-secrets, e.g.:

testuser	*	"testpassword"	*

Alternatively you can configure ProL2TP on the LNS to use RADIUS for authentication and IP addresses using the 'use_radius' keyword See the proltpd.conf manual page for details.

RADIUS Server Configuration

The RADIUS server should be configured to authenticate the PPPoE client (kacd is able to support PAP, CHAP and EAP authentication methods), and to return the following RADIUS attributes to authenticated clients:

  • Tunnel-Type: L2TP

    • This attribute must be set to L2TP to indicate that the incoming session should be tunneled out via L2TP.

  • Tunnel-Medium-Type: IPv4

    • This attribute should be set to IPv4.

  • Tunnel-Server-Endpoint: mylns.mydomain

    • This attribute should be set to the FQDN or IP address of your LNS.

  • Tunnel-Private-Group-Id: test

    • This attribute sets the ProL2TP tunnel profile name which kacd will use to create the tunnel and session to the LNS.

To configure the popular freeradius RADIUS server, the shared RADIUS secret for the client must be set with something similar to the following in /etc/freeradius/clients.conf:

client 192.168.0.0/16 {
    	secret = testing123
}

(Note that the secret 'testing123' matches the secret configured in the radius block of the kacd configuration). The client IP address range should be configured to match the range which the LAC appears in.

The RADIUS attributes for freeradius are configured in /etc/freeradius/users:

testuser Cleartext-Password := "testpassword"
    	Tunnel-Type:0 == L2TP,
    	Tunnel-Medium-Type:0 == IPv4,
    	Tunnel-Server-Endpoint:0 == mylns.mydomain,
    	Tunnel-Private-Group-ID:0 == test

Static PAP authentication must be configured at RADIUS server in /etc/ppp/pap-secrets, e.g.:

testuser	*	"testpassword"	*

Troubleshooting

The appropriate troubleshooting strategy is to follow the connection through from source to destination:

  • Is the PPPoE client sending PPPoE requests to eth0 on the LAC?
  • Has kacd seen and acknowledged the PPPoE requests?
  • Has kacd authenticated the client?
  • Has kacd authenticated the client with the RADIUS server?
  • Has kacd successfully opened the tunnel and session to the LNS?
  • Has the PPPoE client re-authenticated with the LNS?

To enable trace debugging output from kacd, you can use the 'kac_trace' command to enable tracing on a particular interface, for example, to enable tracing on eth0:

# sudo kac_trace on -s pppoe -i eth0

After enabling tracing, the kacd log for a successful PPPoE session will look similar to the following:

eth0: Received PADI from client 08:00:27:68:B1:96
eth0: Sending PADO to client 08:00:27:68:B1:96
eth0: Received PADR from client 08:00:27:68:B1:96
Selected route 'test' for PPPoE source eth0 49872, route ID 4533
eth0: Created PPPoE session 49872 for client 08:00:27:68:B1:96
eth0: Sending PADS (49872) to client 08:00:27:68:B1:96
Sending request to RADIUS server 'myradiusserver.mydomain'
Received RADIUS Access-Accept
Rerouting existing route ID 4533, new route ID 12706
Opening tunnel to L2TP peer 'mylns.mydomain'
Opened L2TP tunnel 32113
Created L2TP session 32113/44768
Received peer session for 32113/44768 from prol2tpd
Opened L2TP destination for route 12706
Completed route 'test' 12706 (PPPoE eth0 49872 -> L2TP 32113/44768)

To enable even more debug output, you can start kacd with debugging turned on. On Debian or Ubuntu, this is configured in /etc/default/kacd by setting KACD_OPTIONS:

KACD_OPTIONS="-D -droute,pppoe,l2tp,radius,ppp,pppfsm"

On Fedora 16 or later, this configuration lives in /etc/sysconfig/kacd and should be set as:

KACDARGS=-D -droute,pppoe,l2tp,radius,ppp,pppfsm

Note the lack of quotation marks - on earlier Fedora versions (before systemd was adopted) quotation marks are required.