This episode builds high availability for L2TP/IPsec: HA patterns with multiple LNSes, floating IP failover via VRRP, dead peer detection with DPD and failureshunt, and load balancing with DNS round-robin, ECMP, and multi-instance xl2tpd.

A VPN is the lifeline of remote-working teams — when the VPN server dies, productivity dies with it. Episode 19 discusses high availability and redundancy: how to keep the L2TP/IPsec service running even when one server or one connection fails.
We will dissect three levels of availability: failover between servers with a floating IP, dead peer detection with DPD, and load balancing to spread many users' load. The three complement each other to build a resilient deployment.
The most common pattern is a pair of LNS servers — one active, one standby — sharing a virtual floating IP. keepalived with VRRP moves the floating IP to the backup server when the primary dies. Because clients contact the floating IP, the failure of the primary server goes unnoticed by users.
The keepalived configuration on the primary server:
vrrp_instance VPN_HA {
state MASTER
interface eth0
virtual_router_id 51
priority 100
virtual_ipaddress {
203.0.113.10/32 dev eth0
}
}The standby server uses the same configuration with state BACKUP and priority 90. When the MASTER dies, the BACKUP takes over 203.0.113.10.
DPD (Dead Peer Detection) ensures a dead peer is detected quickly, while failureshunt installs a diversion rule when the tunnel fails — for example dropping traffic so it does not leak, or passing it to another path:
conn vpn-ha
dpddelay=5
dpdtimeout=30
dpdaction=clear
failureshunt=dropThe failureshunt=drop value drops VPN traffic that has no tunnel — preventing data from leaking over the public path when HA fails.
To spread the load, register several server addresses under one DNS name. Clients will connect to the addresses in rotation. This approach is simple but does not account for each server's capacity — a saturated server still receives new connections.
A smarter alternative is ECMP (Equal-Cost Multi-Path) on the router: several equal-cost routes to several LNS gateways, with the router splitting packets. ECMP requires a supporting router and stateful treatment for VPN connections.
When a single xl2tpd process becomes a bottleneck, run multiple instances on different servers with separate configurations. Each instance listens on its own floating IP:
sudo xl2tpd -D -c /etc/xl2tpd/xl2tpd-1.conf -p /var/run/xl2tpd-1.pid
sudo xl2tpd -D -c /etc/xl2tpd/xl2tpd-2.conf -p /var/run/xl2tpd-2.pidEach configuration file uses a different local ip and ip range so no address conflicts occur.
For full availability, combine all layers: two servers with a floating IP via VRRP, DPD for fast detection, automatic failover that brings the service up on the standby server, and a load balancer in front if needed.
Design checklist:
ipsec and xl2tpd must move to the standby server too.dpddelay and dpdtimeout to your network conditions.Test the HA scheme periodically by force-killing the primary server and measuring recovery time. This drill reveals weak points invisible while everything runs normally.
An HA scheme is only useful if failures are actually detected. Add HA-specific monitoring:
ip addr show | grep 203.0.113.10
sudo ipsec statusall | grep -c "up "
sudo systemctl status keepalivedCheck three things: the floating IP is still attached, the number of active SAs, and keepalived is alive. Combine this with the alerting in episode 21 so a failover failure is immediately known to the team.
Warning
Two LNS servers must not share the same ip range, because two clients could receive the same address. Split the address pools between servers, or combine them with a centralized allocation server such as RADIUS.
Episode 19 built high availability: the VRRP pattern with a floating IP for failover between LNSes, DPD and failureshunt for handling peer failure, and DNS round-robin, ECMP, and multi-instance xl2tpd for spreading load.
Key takeaways:
failureshunt decides traffic direction on failure.ip range between servers.In the next episode, episode 20, we will discuss automation and Infrastructure as Code — Ansible roles for Libreswan, strongSwan, and xl2tpd, automated configuration generation, and integration with RADIUS, LDAP, and ACME.