This guide walks you through configuring an L2TP/IPsec VPN that authenticates users via RADIUS. It targets system administrators, developers, and IT managers who need a scalable, centralized authentication system for VPN access. You will find clear, practical steps, configuration examples, and troubleshooting tips for common environments such as Linux (strongSwan + xl2tpd) and FreeRADIUS, along with notes on Windows NPS and security best practices.

Why combine L2TP/IPsec with RADIUS?

L2TP over IPsec is a common VPN choice because it pairs a secure transport (IPsec) with a tunneling protocol (L2TP) that supports user authentication and per-user session parameters. RADIUS centralizes authentication, authorization, and accounting (AAA), making it ideal for organizations with many users, multi-server deployments, or integration with directory services (LDAP/AD).

High-level architecture and prerequisites

At a high level, the setup involves three components:

  • The VPN gateway (L2TP/IPsec server) that terminates IPsec and L2TP sessions.
  • The RADIUS server (e.g., FreeRADIUS or Windows NPS) that validates user credentials and returns attributes like framed-IP-address, MS-CHAPv2 settings, and session time limits.
  • The client devices (Windows, macOS, Linux, iOS, Android) configured to use L2TP/IPsec and connect with either PSK or certificate-based IPsec.

Prerequisites

  • A Linux server (Debian/Ubuntu/CentOS) with public IP or firewall rules allowing UDP ports 500 and 4500 (IPsec) and UDP 1701 (L2TP if NAT traversal is used).
  • Root or sudo access to install packages and modify system networking.
  • A RADIUS server reachable from the VPN gateway.
  • Basic familiarity with IPsec concepts, NAT, and firewall rules.

Design decisions: PSK vs Certificates

There are two common ways to authenticate the IPsec layer:

  • Pre-Shared Key (PSK): simple to deploy but less secure in large deployments. Use when you control all clients and can protect the key.
  • Certificates: stronger, scalable, and recommended for production. Requires a PKI to issue client and server certificates.

For this guide, examples will assume PSK for ease of demonstration, but the RADIUS-based user authentication is handled at the L2TP/PPP layer (typically MS-CHAPv2), so certificates can be swapped in for the IPsec phase without changing RADIUS configuration.

Step 1 — Prepare and harden the server

Install required packages on Linux (example for Debian/Ubuntu):

Install strongSwan, xl2tpd, and PPP: apt-get update && apt-get install -y strongswan xl2tpd ppp

Adjust kernel parameters to allow IP forwarding and reduce ICMP redirects:

Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward (persist in /etc/sysctl.conf: net.ipv4.ip_forward=1)

Harden the server by blocking unnecessary services, applying system updates, and configuring fail2ban or similar for additional protection.

Step 2 — Configure the RADIUS server (FreeRADIUS example)

FreeRADIUS is a common, flexible RADIUS implementation. Basic steps:

  • Install: apt-get install -y freeradius
  • Edit clients.conf to add the VPN gateway as a client with a shared secret:

Example entry in /etc/freeradius/3.0/clients.conf:

client vpn-gw { ipaddr = 203.0.113.10 secret = myradiussecret shortname = vpn-gw }

  • Configure users in /etc/freeradius/3.0/users or connect to LDAP/AD for authentication.
  • Ensure response attributes are set: FreeRADIUS will return attributes like Framed-IP-Address, MS-MPPE-Keys (for MS-CHAPv2), Session-Timeout, and Framed-Compression if needed.

Test the RADIUS server locally using radtest or radclient:

Example test: radtest alice password 127.0.0.1 0 myradiussecret

Step 3 — Configure strongSwan (IPsec)

Edit /etc/ipsec.conf (simplified example for PSK + L2TP):

config setup

charondebug=”cfg 2, knl 2, enc 2″

conn %default

keyexchange=ikev1

authby=secret

ike=aes256-sha1-modp1024

esp=aes256-sha1

conn L2TP-PSK

keyexchange=ikev1

left=%any

leftauth=psk

leftsubnet=0.0.0.0/0

right=%any

rightauth=psk

rightprotoport=17/1701

auto=add

Place PSK in /etc/ipsec.secrets:

%any %any : PSK “your_strong_pre_shared_key”

Note: if using certificates, configure leftcert and appropriate x509 settings instead of PSK.

Step 4 — Configure xl2tpd and PPP

Edit /etc/xl2tpd/xl2tpd.conf:

[global]

ipsec saref = yes

[lns default]

ip range = 192.168.100.10-192.168.100.200

local ip = 192.168.100.1

require chap = yes

refuse pap = yes

require authentication = yes

name = L2TPVPN

ppp debug = yes

pppoptfile = /etc/ppp/options.xl2tpd

In /etc/ppp/options.xl2tpd include PPP options and RADIUS plugin support (pppd radius plugin or rlm_radius with xl2tpd):

name l2tpd

require-mschap-v2

ms-dns 8.8.8.8

ms-dns 8.8.4.4

proxyarp

lock

nobsdcomp

nodefaultroute

plugin radius.so

radius-config-file /etc/radiusclient/radiusclient.conf

Note: The exact plugin path and configuration differ by distribution. On some systems ppp-radius package is used and you configure /etc/radiusclient/.

Step 5 — Configure RADIUS client on the VPN gateway

Configure the RADIUS client library to point to your FreeRADIUS server (example file /etc/radiusclient/radiusclient.conf):

auth_order radius,local

servers /etc/radiusclient/servers

dictionary /etc/radiusclient/dictionary

In /etc/radiusclient/servers add:

203.0.113.20 myradiussecret 1812

Adjust file paths for your distro. Ensure pppd is built with RADIUS support or use rlm_passwd/rlm_ldap modules with FreeRADIUS to integrate with backend stores.

Step 6 — Firewall and NAT considerations

Open firewall ports on the VPN gateway:

  • UDP 500 (IKE)
  • UDP 4500 (NAT-T)
  • UDP 1701 (L2TP) — often encapsulated in IPsec; may still need allowance if IPsec passthrough is enabled.

On Linux with iptables, example NAT for client traffic to reach the internet:

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE

Also ensure forwarding rules allow established connections:

iptables -A FORWARD -s 192.168.100.0/24 -j ACCEPT

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

Step 7 — Start services and test

Restart services:

  • systemctl restart strongswan
  • systemctl restart xl2tpd
  • systemctl restart freeradius (if local)

From a client, create an L2TP/IPsec connection configured to use the PSK (or server certificate) and username/password that exist on RADIUS. For Windows clients, set the security to use L2TP with pre-shared key, and authentication via MS-CHAPv2.

Monitor logs on the gateway:

  • strongSwan logs at /var/log/syslog or /var/log/auth.log depending on distro.
  • xl2tpd logs as configured; pppd debug output will show RADIUS communication and MS-CHAPv2 negotiation.
  • FreeRADIUS logs typically in /var/log/freeradius/radius.log or journalctl -u freeradius.

Troubleshooting checklist

If connections fail, check these common issues:

  • IPsec phase 1 fails: Verify PSK/certificate settings and UDP 500/4500 reachability. Check for NAT devices modifying packets.
  • RADIUS authentication fails: Ensure the VPN gateway is listed as a RADIUS client and the shared secret matches. Use radtest from the gateway to the RADIUS server.
  • PPP/MS-CHAPv2 errors: Verify pppd is configured to require MS-CHAPv2 and FreeRADIUS is set to return MS-MPPE-Keys if encryption is required.
  • IP forwarding/NAT issues: Confirm sysctl net.ipv4.ip_forward=1 and iptables rules are correct.
  • DNS problems: Ensure PPP options provide DNS servers (ms-dns) or push routed DNS via DHCP-like settings.

Security and scalability considerations

For production environments, follow these best practices:

  • Prefer certificates: Use an internal PKI to issue certificates to gateways and clients. This supports revocation and per-client control.
  • Harden RADIUS: Use Secure TLS::TLS inside FreeRADIUS for backends (e.g., EAP-TLS to AD) and enforce strong password policies.
  • Enable accounting: Configure RADIUS accounting to track session durations, data usage, and perform billing or auditing.
  • Implement rate limiting and intrusion prevention to reduce brute-force risk. Consider integrating MFA by using RADIUS to proxy to an MFA provider.
  • Segment network access: Use RADIUS attributes (e.g., Framed-Filter-Id or Class) to place users into VLANs or enforce role-based access controls.

Scaling tips

When scaling beyond a single gateway:

  • Deploy multiple VPN gateways behind a load balancer that supports UDP and IPsec (often requires special handling).
  • Use a centralized RADIUS cluster or a virtualized FreeRADIUS setup with a shared SQL/LDAP backend to maintain state and user databases.
  • Cache RADIUS responses where possible and tune FreeRADIUS worker settings for high concurrency.

Wrap-up and further reading

This guide covered the essential steps to configure an L2TP/IPsec VPN authenticated via RADIUS, from server preparation to RADIUS integration, IPsec and L2TP configuration, firewall rules, testing, and troubleshooting. While the examples focused on strongSwan, xl2tpd, and FreeRADIUS on Linux, the same principles apply to other stacks such as Windows RRAS and pfSense with their corresponding RADIUS configurations. For production, favor certificate-based IPsec, secure your RADIUS infrastructure, and enable accounting and monitoring.

For more in-depth tutorials and downloadable configuration examples, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.