Language and Page Formatting Options
2.7.8. Road Warrior Access VPN Using Libreswan and XAUTH with X.509
Libreswan offers a method to natively assign
IPaddress and DNS information to roaming VPN clients as the connection is established by using the XAUTH
IPsecextension. Extended authentication (XAUTH) can be deployed using PSK or X.509 certificates. Deploying using X.509 is more secure. Client certificates can be revoked by a certificate revocation list or by Online Certificate Status Protocol (OCSP). With X.509 certificates, individual clients cannot impersonate the server. With a PSK, also called Group Password, this is theoretically possible.
XAUTH requires the VPN client to additionally identify itself with a user name and password. For One time Passwords (OTP), such as Google Authenticator or RSA SecureID tokens, the one-time token is appended to the user password.
There are three possible backends for XAUTH:
- This uses the configuration in
/etc/pam.d/plutoto authenticate the user. Pluggable Authentication Modules (PAM) can be configured to use various backends by itself. It can use the system account user-password scheme, an LDAP directory, a RADIUS server or a custom password authentication module. See the Using Pluggable Authentication Modules (PAM) chapter for more information.
- This uses the configuration file
/etc/ipsec.d/passwd(not to be confused with
/etc/ipsec.d/nsspassword). The format of this file is similar to the Apache
.htpasswdfile and the Apache
htpasswdcommand can be used to create entries in this file. However, after the user name and password, a third column is required with the connection name of the
IPsecconnection used, for example when using a
conn remoteusersto offer VPN to remote users, a password file entry should look as follows:
user1:$apr1$MIwQ3DHb$1I69LzTnZhnCT2DPQmAOK.:remoteusersNOTE: when using the
htpasswdcommand, the connection name has to be manually added after the user:password part on each line.
- The server will always pretend the XAUTH user and password combination was correct. The client still has to specify a user name and a password, although the server ignores these. This should only be used when users are already identified by X.509 certificates, or when testing the VPN without needing an XAUTH backend.
An example server configuration with X.509 certificates:
conn xauth-rsa auto=add authby=rsasig pfs=no rekey=no left=ServerIP leftcert=vpn.example.com #leftid=%fromcert leftid=vpn.example.com leftsendcert=always leftsubnet=0.0.0.0/0 rightaddresspool=10.234.123.2-10.234.123.254 right=%any rightrsasigkey=%cert modecfgdns1=22.214.171.124 modecfgdns2=126.96.36.199 modecfgdomain=example.com modecfgbanner="Authorized access is allowed" leftxauthserver=yes rightxauthclient=yes leftmodecfgserver=yes rightmodecfgclient=yes modecfgpull=yes xauthby=pam dpddelay=30 dpdtimeout=120 dpdaction=clear ike_frag=yes # for walled-garden on xauth failure # xauthfail=soft #leftupdown=/custom/_updown
xauthfailis set to soft, instead of hard, authentication failures are ignored, and the VPN is setup as if the user authenticated properly. A custom updown script can be used to check for the environment variable
XAUTH_FAILED. Such users can then be redirected, for example, using iptables DNAT, to a “walled garden” where they can contact the administrator or renew a paid subscription to the service.
VPN clients use the
modecfgdomainvalue and the DNS entries to redirect queries for the specified domain to these specified nameservers. This allows roaming users to access internal-only resources using the internal DNS names.
modecfgdnsoptions contain a comma-separated list of internal DNS servers for the client to use for DNS resolution. Optionally, to send a banner text to VPN cliens, use the
0.0.0.0/0, split tunneling configuration requests are sent automatically to the client. For example, when using
leftsubnet=10.0.0.0/8, the VPN client would only send traffic for
10.0.0.0/8through the VPN.
On the client, the user has to input a user password, which depends on the backend used. For example:
- The administrator generated the password and stored it in the
- The password is obtained at the location specified in the PAM configuration in the
- The password is not checked and always accepted. Use this option for testing purposes or if you want to ensure compatibility for xauth-only clients.
For more information about XAUTH, see the Extended Authentication within ISAKMP/Oakley (XAUTH) Internet-Draft document.