Learn L2TP IPsec - strongSwan: Configuration & Features

#Introduction

If Libreswan is the trusted veteran, strongSwan is the IPsec implementation most diligent about following modern standards. Episode 10 dissects it: two configuration styles — the legacy ipsec.conf and the modern swanctl — plus flagship features such as full IKEv2, EAP, MOBIKE, and complete certificate chain handling.

strongSwan is highly relevant for L2TP/IPsec because charon handles IPsec with high precision, while xl2tpd remains the L2TP daemon on top of it. After this episode, you can choose the IPsec daemon that best fits your deployment.

#Two Configuration Styles

#ipsec.conf and strongswan.conf (Legacy Style)

Historically, strongSwan used ipsec.conf in a style similar to Libreswan, with global parameters in strongswan.conf:

conn L2TP-IKEv1
    type=transport
    left=%any
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    authby=secret
    ikev1=always
    esp=aes128-sha1
    auto=add

Note the ikev1=always — this is the equivalent of Libreswan's ikev2=never and forces IKEv1 negotiation, which classic L2TP clients need.

#swanctl: The Modern Approach

Since version 5, strongSwan recommends swanctl with the more explicit swanctl.conf file. Its structure is based on named sections, similar to YAML:

connections {
    L2TP-IKEv1 {
        version = 1
        proposals = aes256-sha256-modp2048
        local-1 {
            auth = psk
        }
        remote-1 {
            auth = psk
        }
        children {
            L2TP {
                type = transport
                local_ts = udp/1701
                remote_ts = dynamic[udp]
                esp_proposals = aes128-sha1
            }
        }
    }
}

In the children block, local_ts = udp/1701 restricts the protected traffic to UDP 1701 only — exactly the role of leftprotoport in the legacy style.

#strongSwan Flagship Features

#IKEv2 and EAP

Charon fully implements IKEv2 (RFC 7296) and supports EAP for user authentication. With EAP, credentials do not need to be wrapped by old mechanisms like XAUTH — EAP can wrap EAP-MSCHAPv2, EAP-TLS, or EAP-TTLS for clean RADIUS integration.

#MOBIKE and Certificate Chain

MOBIKE keeps a connection alive when a device changes networks, and complete certificate chain handling ensures full validation from leaf to root CA. Logging and control are done through swanctl as in episode 8:

sudo swanctl --load-all
sudo swanctl --initiate --child L2TP
sudo swanctl --list-sas

The swanctl --list-sas command displays SAs after initiation and must show state ESTABLISHED.

#Loading Configuration and Verification

#Load and Check Process

Apply the configuration and check the result:

sudo systemctl restart strongswan
sudo swanctl --load-all
sudo swanctl --list-conns

The charon logs show every step of the IKE negotiation:

sudo journalctl -u strongswan -f

If the log ends with IKE_SA ... established, the IPsec layer succeeded. A common problem: proposal mismatch — match the proposals and esp_proposals blocks with the suites your clients support.

#Closing

Episode 10 completed the IPsec implementation picture: strongSwan with its two configuration styles, the IKEv2, EAP, MOBIKE, and certificate chain features, and how to apply and verify an L2TP configuration using swanctl.

Key takeaways:

• strongSwan uses either the legacy ipsec.conf style or the modern swanctl.conf.
• ikev1=always forces IKEv1 for classic L2TP clients.
• swanctl is the modern control interface replacing ipsec auto.
• EAP replaces XAUTH for user authentication in IKEv2.
• MOBIKE keeps connections alive when a device switches networks.
• Use strongSwan and Libreswan on different machines.

In the next episode, episode 11, we will discuss xl2tpd and PPP setup — the [lns default] configuration, integration with options.xl2tpd, enforcing MS-CHAPv2, and IP address assignment for clients.