4.6. Securing Virtual Private Networks (VPNs) Using Libreswan
In Red Hat Enterprise Linux 7, a Virtual Private Network (VPN) can be configured using the
IPsec
protocol which is supported by the Libreswan application. Libreswan is a continuation of the Openswan application and many examples from the Openswan documentation are interchangeable with Libreswan. The NetworkManager IPsec
plug-in is called NetworkManager-libreswan. Users of GNOME Shell should install the NetworkManager-libreswan-gnome package, which has NetworkManager-libreswan as a dependency. Note that the NetworkManager-libreswan-gnome package is only available from the Optional channel. See Enabling Supplementary and Optional Repositories.
The
IPsec
protocol for VPN is itself configured using the Internet Key Exchange (IKE) protocol. The terms IPsec and IKE are used interchangeably. An IPsec VPN is also called an IKE VPN, IKEv2 VPN, XAUTH VPN, Cisco VPN or IKE/IPsec VPN. A variant of an IPsec VPN that also uses the Level 2 Tunneling Protocol (L2TP) is usually called an L2TP/IPsec VPN, which requires the Optional channel xl2tpd application.
Libreswan is an open-source, user-space
IKE
implementation available in Red Hat Enterprise Linux 7. IKE
version 1 and 2 are implemented as a user-level daemon. The IKE protocol itself is also encrypted. The IPsec
protocol is implemented by the Linux kernel and Libreswan configures the kernel to add and remove VPN tunnel configurations.
The
IKE
protocol uses UDP port 500 and 4500. The IPsec
protocol consists of two different protocols, Encapsulated Security Payload (ESP) which has protocol number 50, and Authenticated Header (AH) which as protocol number 51. The AH
protocol is not recommended for use. Users of AH
are recommended to migrate to ESP
with null encryption.
The
IPsec
protocol has two different modes of operation, Tunnel Mode
(the default) and Transport Mode
. It is possible to configure the kernel with IPsec without IKE. This is called Manual Keying
. It is possible to configure manual keying using the ip xfrm
commands, however, this is strongly discouraged for security reasons. Libreswan interfaces with the Linux kernel using netlink. Packet encryption and decryption happen in the Linux kernel.
Libreswan uses the Network Security Services (NSS) cryptographic library. Both libreswan and NSS are certified for use with the Federal Information Processing Standard (FIPS) Publication 140-2.
Important
IKE
/IPsec
VPNs, implemented by Libreswan and the Linux kernel, is the only VPN technology recommended for use in Red Hat Enterprise Linux 7. Do not use any other VPN technology without understanding the risks of doing so.
4.6.1. Installing Libreswan
To install Libreswan, enter the following command as
root
:
~]# yum install libreswan
To check that Libreswan is installed:
~]$ yum info libreswan
After a new installation of Libreswan, the NSS database should be initialized as part of the installation process. Before you start a new database, remove the old database as follows:
~]#systemctl stop ipsec
~]#rm /etc/ipsec.d/*db
Then, to initialize a new NSS database, enter the following command as
root
:
~]# ipsec initnss
Initializing NSS database
Only when operating in FIPS mode, it is necessary to protect the NSS database with a password. To initialize the database for FIPS mode, instead of the previous command, use:
~]# certutil -N -d sql:/etc/ipsec.d
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
To start the
ipsec
daemon provided by Libreswan, issue the following command as root
:
~]# systemctl start ipsec
To confirm that the daemon is now running:
~]$ systemctl status ipsec
* ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled; vendor preset: disabled)
Active: active (running) since Sun 2018-03-18 18:44:43 EDT; 3s ago
Docs: man:ipsec(8)
man:pluto(8)
man:ipsec.conf(5)
Process: 20358 ExecStopPost=/usr/sbin/ipsec --stopnflog (code=exited, status=0/SUCCESS)
Process: 20355 ExecStopPost=/sbin/ip xfrm state flush (code=exited, status=0/SUCCESS)
Process: 20352 ExecStopPost=/sbin/ip xfrm policy flush (code=exited, status=0/SUCCESS)
Process: 20347 ExecStop=/usr/libexec/ipsec/whack --shutdown (code=exited, status=0/SUCCESS)
Process: 20634 ExecStartPre=/usr/sbin/ipsec --checknflog (code=exited, status=0/SUCCESS)
Process: 20631 ExecStartPre=/usr/sbin/ipsec --checknss (code=exited, status=0/SUCCESS)
Process: 20369 ExecStartPre=/usr/libexec/ipsec/_stackmanager start (code=exited, status=0/SUCCESS)
Process: 20366 ExecStartPre=/usr/libexec/ipsec/addconn --config /etc/ipsec.conf --checkconfig (code=exited, status=0/SUCCESS)
Main PID: 20646 (pluto)
Status: "Startup completed."
CGroup: /system.slice/ipsec.service
└─20646 /usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork
To ensure that Libreswan will start when the system starts, issue the following command as
root
:
~]# systemctl enable ipsec
Configure any intermediate as well as host-based firewalls to permit the
ipsec
service. See Chapter 5, Using Firewalls for information on firewalls and allowing specific services to pass through. Libreswan requires the firewall to allow the following packets:
UDP
port 500 and 4500 for theInternet Key Exchange
(IKE) protocol- Protocol 50 for
Encapsulated Security Payload
(ESP)IPsec
packets - Protocol 51 for
Authenticated Header
(AH)IPsec
packets (uncommon)
We present three examples of using Libreswan to set up an
IPsec
VPN. The first example is for connecting two hosts together so that they may communicate securely. The second example is connecting two sites together to form one network. The third example is supporting remote users, known as road warriors in this context.
4.6.2. Creating VPN Configurations Using Libreswan
Libreswan does not use the terms “source” and “destination” or “server” and “client” since IKE/IPsec are peer to peer protocols. Instead, it uses the terms “left” and “right” to refer to end points (the hosts). This also allows the same configuration to be used on both end points in most cases, although a lot of administrators choose to always use “left” for the local host and “right” for the remote host.
There are four commonly used methods for authentication of endpoints:
- Pre-Shared Keys (PSK) is the simplest authentication method. PSKs should consist of random characters and have a length of at least 20 characters. In FIPS mode, PSKs need to comply to a minimum strength requirement depending on the integrity algorithm used. It is recommended not to use PSKs shorter than 64 random characters.
- Raw RSA keys are commonly used for static host-to-host or subnet-to-subnet
IPsec
configurations. The hosts are manually configured with each other's public RSA key. This method does not scale well when dozens or more hosts all need to setupIPsec
tunnels to each other. - X.509 certificates are commonly used for large-scale deployments where there are many hosts that need to connect to a common
IPsec
gateway. A central certificate authority (CA) is used to sign RSA certificates for hosts or users. This central CA is responsible for relaying trust, including the revocations of individual hosts or users. - NULL Authentication is used to gain mesh encryption without authentication. It protects against passive attacks but does not protect against active attacks. However, since
IKEv2
allows asymmetrical authentication methods, NULL Authentication can also be used for internet scale Opportunistic IPsec, where clients authenticate the server, but servers do not authenticate the client. This model is similar to secure websites usingTLS
(also known as https:// websites).
In addition to these authentication methods, an additional authentication can be added to protect against possible attacks by quantum computers. This additional authentication method is called Postquantum Preshared Keys (PPK. Individual clients or groups of clients can use their own PPK by specifying a (PPKID that corresponds to an out-of-band configured PreShared Key. See Section 4.6.9, “Using the Protection against Quantum Computers”.
4.6.3. Creating Host-To-Host VPN Using Libreswan
To configure Libreswan to create a host-to-host
IPsec
VPN, between two hosts referred to as “left” and “right”, enter the following commands as root
on both of the hosts (“left” and “right”) to create new raw RSA key pairs:
~]# ipsec newhostkey --output /etc/ipsec.d/hostkey.secrets
Generated RSA key pair with CKAID 14936e48e756eb107fa1438e25a345b46d80433f was stored in the NSS database
This generates an RSA key pair for the host. The process of generating RSA keys can take many minutes, especially on virtual machines with low entropy.
To view the host public key so it can be specified in a configuration as the “left” side, issue the following command as
root
on the host where the new hostkey was added, using the CKAID returned by the “newhostkey” command:
~]# ipsec showhostkey --left --ckaid 14936e48e756eb107fa1438e25a345b46d80433f
# rsakey AQPFKElpV
leftrsasigkey=0sAQPFKElpV2GdCF0Ux9Kqhcap53Kaa+uCgduoT2I3x6LkRK8N+GiVGkRH4Xg+WMrzRb94kDDD8m/BO/Md+A30u0NjDk724jWuUU215rnpwvbdAob8pxYc4ReSgjQ/DkqQvsemoeF4kimMU1OBPNU7lBw4hTBFzu+iVUYMELwQSXpremLXHBNIamUbe5R1+ibgxO19l/PAbZwxyGX/ueBMBvSQ+H0UqdGKbq7UgSEQTFa4/gqdYZDDzx55tpZk2Z3es+EWdURwJOgGiiiIFuBagasHFpeu9Teb1VzRyytnyNiJCBVhWVqsB4h6eaQ9RpAMmqBdBeNHfXwb6/hg+JIKJgjidXvGtgWBYNDpG40fEFh9USaFlSdiHO+dmGyZQ74Rg9sWLtiVdlH1YEBUtQb8f8FVry9wSn6AZqPlpGgUdtkTYUCaaifsYH4hoIA0nku4Fy/Ugej89ZdrSN7Lt+igns4FysMmBOl9Wi9+LWnfl+dm4Nc6UNgLE8kZc+8vMJGkLi4SYjk2/MFYgqGX/COxSCPBFUZFiNK7Wda0kWea/FqE1heem7rvKAPIiqMymjSmytZI9hhkCD16pCdgrO3fJXsfAUChYYSPyPQClkavvBL/wNK9zlaOwssTaKTj4Xn90SrZaxTEjpqUeQ==
You will need this key to add to the configuration file on both hosts as explained below. If you forgot the CKAID, you can obtain a list of all host keys on a machine using:
~]# ipsec showhostkey --list
< 1 > RSA keyid: AQPFKElpV ckaid: 14936e48e756eb107fa1438e25a345b46d80433f
The secret part of the keypair is stored inside the “NSS database” which resides in
/etc/ipsec.d/*.db
.
To make a configuration file for this host-to-host tunnel, the lines
leftrsasigkey=
and rightrsasigkey=
from above are added to a custom configuration file placed in the /etc/ipsec.d/
directory.
Using an editor running as
root
, create a file with a suitable name in the following format:
/etc/ipsec.d/my_host-to-host.conf
Edit the file as follows:
conn mytunnel leftid=@west.example.com left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east.example.com right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig # load and initiate automatically auto=start
Public keys can also be configured by their CKAID instead of by their RSAID. In that case use “leftckaid=” instead of “leftrsasigkey=”
You can use the identical configuration file on both left and right hosts. Libreswan automatically detects if it is “left” or “right” based on the specified IP addresses or hostnames. If one of the hosts is a mobile host, which implies the
IP
address is not known in advance, then on the mobile client use %defaultroute
as its IP
address. This will pick up the dynamic IP
address automatically. On the static server host that accepts connections from incoming mobile hosts, specify the mobile host using %any
for its IP
address.
Ensure the
leftrsasigkey
value is obtained from the “left” host and the rightrsasigkey
value is obtained from the “right” host. The same applies when using leftckaid
and rightckaid
.
Restart
ipsec
to ensure it reads the new configuration and if configured to start on boot, to confirm that the tunnels establish:
~]# systemctl restart ipsec
When using the
auto=start
option, the IPsec
tunnel should be established within a few seconds. You can manually load and start the tunnel by entering the following commands as root
:
~]#ipsec auto --add mytunnel
~]#ipsec auto --up mytunnel
4.6.3.1. Verifying Host-To-Host VPN Using Libreswan
The
IKE
negotiation takes place on UDP
ports 500 and 4500. IPsec
packets show up as Encapsulated Security Payload
(ESP) packets. The ESP
protocol has no ports. When the VPN connection needs to pass through a NAT router, the ESP
packets are encapsulated in UDP
packets on port 4500.
To verify that packets are being sent through the VPN tunnel, issue a command as
root
in the following format:
~]# tcpdump -n -i interface esp or udp port 500 or udp port 4500
00:32:32.632165 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1a), length 132
00:32:32.632592 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1a), length 132
00:32:32.632592 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 7, length 64
00:32:33.632221 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1b), length 132
00:32:33.632731 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1b), length 132
00:32:33.632731 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 8, length 64
00:32:34.632183 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1c), length 132
00:32:34.632607 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1c), length 132
00:32:34.632607 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 9, length 64
00:32:35.632233 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1d), length 132
00:32:35.632685 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1d), length 132
00:32:35.632685 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 10, length 64
Where interface is the interface known to carry the traffic. To end the capture with tcpdump, press Ctrl+C.
Note
The tcpdump command interacts a little unexpectedly with
IPsec
. It only sees the outgoing encrypted packet, not the outgoing plaintext packet. It does see the encrypted incoming packet, as well as the decrypted incoming packet. If possible, run tcpdump on a router between the two machines and not on one of the endpoints itself. When using the Virtual Tunnel Interface (VTI), tcpdump on the physical interface shows ESP
packets, while tcpdump on the VTI interface shows the cleartext traffic.
To check the tunnel is succesfully established, and additionally see how much traffic has gone through the tunnel, enter the following command as
root
:
~]# ipsec whack --trafficstatus
006 #2: "mytunnel", type=ESP, add_time=1234567890, inBytes=336, outBytes=336, id='@east'
4.6.4. Configuring Site-to-Site VPN Using Libreswan
In order for Libreswan to create a site-to-site
IPsec
VPN, joining together two networks, an IPsec
tunnel is created between two hosts, endpoints, which are configured to permit traffic from one or more subnets to pass through. They can therefore be thought of as gateways to the remote portion of the network. The configuration of the site-to-site VPN only differs from the host-to-host VPN in that one or more networks or subnets must be specified in the configuration file.
To configure Libreswan to create a site-to-site
IPsec
VPN, first configure a host-to-host IPsec
VPN as described in Section 4.6.3, “Creating Host-To-Host VPN Using Libreswan” and then copy or move the file to a file with a suitable name, such as /etc/ipsec.d/my_site-to-site.conf
. Using an editor running as root
, edit the custom configuration file /etc/ipsec.d/my_site-to-site.conf
as follows:
conn mysubnet also=mytunnel leftsubnet=192.0.1.0/24 rightsubnet=192.0.2.0/24 auto=start conn mysubnet6 also=mytunnel connaddrfamily=ipv6 leftsubnet=2001:db8:0:1::/64 rightsubnet=2001:db8:0:2::/64 auto=start conn mytunnel leftid=@west.example.com left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east.example.com right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig
To bring the tunnels up, restart Libreswan or manually load and initiate all the connections using the following commands as
root
:
~]# ipsec auto --add mysubnet
~]# ipsec auto --add mysubnet6
~]# ipsec auto --up mysubnet
104 "mysubnet" #1: STATE_MAIN_I1: initiate
003 "mysubnet" #1: received Vendor ID payload [Dead Peer Detection]
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
106 "mysubnet" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mysubnet" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mysubnet" #1: received Vendor ID payload [CAN-IKEv2]
004 "mysubnet" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x9414a615 <0x1a8eb4ef xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
~]# ipsec auto --up mysubnet6
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x06fe2099 <0x75eaa862 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
4.6.4.1. Verifying Site-to-Site VPN Using Libreswan
Verifying that packets are being sent through the VPN tunnel is the same procedure as explained in Section 4.6.3.1, “Verifying Host-To-Host VPN Using Libreswan”.
4.6.5. Configuring Site-to-Site Single Tunnel VPN Using Libreswan
Often, when a site-to-site tunnel is built, the gateways need to communicate with each other using their internal
IP
addresses instead of their public IP
addresses. This can be accomplished using a single tunnel. If the left host, with host name west
, has internal IP
address 192.0.1.254
and the right host, with host name east
, has internal IP
address 192.0.2.254
, store the following configuration using a single tunnel to the /etc/ipsec.d/myvpn.conf
file on both servers:
conn mysubnet leftid=@west.example.com leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== left=192.1.2.23 leftsourceip=192.0.1.254 leftsubnet=192.0.1.0/24 rightid=@east.example.com rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== right=192.1.2.45 rightsourceip=192.0.2.254 rightsubnet=192.0.2.0/24 auto=start authby=rsasig
4.6.6. Configuring Subnet Extrusion Using Libreswan
IPsec
is often deployed in a hub-and-spoke architecture. Each leaf node has an IP
range that is part of a larger range. Leaves communicate with each other through the hub. This is called subnet extrusion.
Example 4.2. Configuring Simple Subnet Extrusion Setup
In the following example, we configure the head office with
10.0.0.0/8
and two branches that use a smaller /24
subnet.
At the head office:
conn branch1 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=5.6.7.8 rightid=@branch1 rightsubnet=10.0.1.0/24 rightrsasigkey=0sAXXXX[...] # auto=start authby=rsasig conn branch2 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=10.11.12.13 rightid=@branch2 rightsubnet=10.0.2.0/24 rightrsasigkey=0sAYYYY[...] # auto=start authby=rsasig
At the “branch1” office, we use the same connection. Additionally, we use a pass-through connection to exclude our local LAN traffic from being sent through the tunnel:
conn branch1 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=10.11.12.13 rightid=@branch2 rightsubnet=10.0.1.0/24 rightrsasigkey=0sAYYYY[...] # auto=start authby=rsasig conn passthrough left=1.2.3.4 right=0.0.0.0 leftsubnet=10.0.1.0/24 rightsubnet=10.0.1.0/24 authby=never type=passthrough auto=route
4.6.7. Configuring IKEv2 Remote Access VPN Libreswan
Road warriors are traveling users with mobile clients with a dynamically assigned
IP
address, such as laptops. These are authenticated using certificates. To avoid needing to use the old IKEv1 XAUTH protocol, IKEv2 is used in the following example:
On the server:
conn roadwarriors ikev2=insist # Support (roaming) MOBIKE clients (RFC 4555) mobike=yes fragmentation=yes left=1.2.3.4 # if access to the LAN is given, enable this, otherwise use 0.0.0.0/0 # leftsubnet=10.10.0.0/16 leftsubnet=0.0.0.0/0 leftcert=vpn-server.example.com leftid=%fromcert leftxauthserver=yes leftmodecfgserver=yes right=%any # trust our own Certificate Agency rightca=%same # pick an IP address pool to assign to remote users # 100.64.0.0/16 prevents RFC1918 clashes when remote users are behind NAT rightaddresspool=100.64.13.100-100.64.13.254 # if you want remote clients to use some local DNS zones and servers modecfgdns="1.2.3.4, 5.6.7.8" modecfgdomains="internal.company.com, corp" rightxauthclient=yes rightmodecfgclient=yes authby=rsasig # optionally, run the client X.509 ID through pam to allow/deny client # pam-authorize=yes # load connection, don't initiate auto=add # kill vanished roadwarriors dpddelay=1m dpdtimeout=5m dpdaction=%clear
Where:
left=1.2.3.4
- The 1.2.3.4 value specifies the actual IP address or host name of your server.
leftcert=vpn-server.example.com
- This option specifies a certificate referring to its friendly name or nickname that has been used to import the certificate. Usually, the name is generated as a part of a PKCS #12 certificate bundle in the form of a
.p12
file. See thepkcs12(1)
andpk12util(1)
man pages for more information.
On the mobile client, the road warrior's device, use a slight variation of the previous configuration:
conn to-vpn-server ikev2=insist # pick up our dynamic IP left=%defaultroute leftsubnet=0.0.0.0/0 leftcert=myname.example.com leftid=%fromcert leftmodecfgclient=yes # right can also be a DNS hostname right=1.2.3.4 # if access to the remote LAN is required, enable this, otherwise use 0.0.0.0/0 # rightsubnet=10.10.0.0/16 rightsubnet=0.0.0.0/0 # trust our own Certificate Agency rightca=%same authby=rsasig # allow narrowing to the server’s suggested assigned IP and remote subnet narrowing=yes # Support (roaming) MOBIKE clients (RFC 4555) mobike=yes # Initiate connection auto=start
Where:
auto=start
- This option enables the user to connect to the VPN whenever the
ipsec
system service is started. Replace it with theauto=add
if you want to establish the connection later.
4.6.8. Configuring IKEv1 Remote Access VPN Libreswan and XAUTH with X.509
Libreswan offers a method to natively assign
IP
address and DNS information to roaming VPN clients as the connection is established by using the XAUTH IPsec
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 (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 back ends for XAUTH:
xauthby=pam
- This uses the configuration in
/etc/pam.d/pluto
to authenticate the user. Pluggable Authentication Modules (PAM) can be configured to use various back ends 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. xauthby=file
- This uses the
/etc/ipsec.d/passwd
configuration file (it should not be confused with the/etc/ipsec.d/nsspassword
file). The format of this file is similar to the Apache.htpasswd
file and the Apachehtpasswd
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 theIPsec
connection used, for example when using aconn remoteusers
to offer VPN to remove users, a password file entry should look as follows:user1:$apr1$MIwQ3DHb$1I69LzTnZhnCT2DPQmAOK.:remoteusers
Note
When using thehtpasswd
command, the connection name has to be manually added after the user:password part on each line. xauthby=alwaysok
- The server always pretends the XAUTH user and password combination is 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 back end.
An example server configuration with X.509 certificates:
conn xauth-rsa ikev2=never 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 modecfgdns="1.2.3.4,8.8.8.8" modecfgdomains=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
When
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. Note while IKEv2 supports a comma-separated list of domain names and nameserver IP addresses using modecfgdomains
and modecfgdns
, the IKEv1 protocol only supports one domain name, and libreswan only supports up to two nameserver IP addresses. Optionally, to send a banner text to VPN cliens, use the modecfgbanner
option.
If
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:
xauthby=file
- The administrator generated the password and stored it in the
/etc/ipsec.d/passwd
file. xauthby=pam
- The password is obtained at the location specified in the PAM configuration in the
/etc/pam.d/pluto
file. xauthby=alwaysok
- 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.
Additional Resources
For more information about XAUTH, see the Extended Authentication within ISAKMP/Oakley (XAUTH) Internet-Draft document.
4.6.9. Using the Protection against Quantum Computers
Using IKEv1 with PreShared Keys provided protection against quantum attackers. The redesign of IKEv2 does not offer this protection natively. Libreswan offers the use of Postquantum Preshared Keys (PPK) to protect IKEv2 connections against quantum attacks.
To enable optional PPK support, add
ppk=yes
to the connection definition. To require PPK, add ppk=insist
. Then, each client can be given a PPK ID with a secret value that is communicated out-of-band (and preferably quantum safe). The PPK's should be very strong in randomness and not be based on dictionary words. The PPK ID and PPK data itself are stored in ipsec.secrets
, for example:
@west @east : PPKS "user1" "thestringismeanttobearandomstr"
The
PPKS
option refers to static PPKs. There is an experimental function to use one-time-pad based Dynamic PPKs. Upon each connection, a new part of a onetime pad is used as the PPK. When used, that part of the dynamic PPK inside the file is overwritten with zeroes to prevent re-use. If there is no more one time pad material left, the connection fails. See the ipsec.secrets(5)
man page for more information.
Warning
The implementation of dynamic PPKs is provided as a Technology Preview and this functionality should be used with caution. See the 7.5 Release Notes for more information.
4.6.10. Additional Resources
The following sources of information provide additional resources regarding Libreswan and the
ipsec
daemon.
4.6.10.1. Installed Documentation
ipsec(8)
man page — Describes command options foripsec
.ipsec.conf(5)
man page — Contains information on configuringipsec
.ipsec.secrets(5)
man page — Describes the format of theipsec.secrets
file.ipsec_auto(8)
man page — Describes the use of the auto command line client for manipulating LibreswanIPsec
connections established using automatic exchanges of keys.ipsec_rsasigkey(8)
man page — Describes the tool used to generate RSA signature keys./usr/share/doc/libreswan-version/
4.6.10.2. Online Documentation
- https://libreswan.org
- The website of the upstream project.
- https://libreswan.org/wiki
- The Libreswan Project Wiki.
- https://libreswan.org/man/
- All Libreswan man pages.
- NIST Special Publication 800-77: Guide to IPsec VPNs
- Practical guidance to organizations on implementing security services based on IPsec.