offers a method to natively assign
address and DNS information to roaming VPN clients as the connection is established by using the XAUTH
extension. 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
). 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
to 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
.htpasswd file and the Apache
htpasswd command 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
IPsec connection used, for example when using a
conn remoteusers to offer VPN to remote users, a password file entry should look as follows:
NOTE: when using the
htpasswd command, 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:
modecfgbanner="Authorized access is allowed"
# for walled-garden on xauth failure
xauthfail is 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
modecfgdomain value 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.
modecfgdns options 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
leftsubnet is not
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/8 through 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.