4.6. Securing Virtual Private Networks (VPNs) Using Libreswan
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 : To check that Libreswan is installed: 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: Then, to initialize a new NSS database, enter the following command as root : 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 command, use: To start the ipsec daemon provided by Libreswan , issue the following command as root : To confirm that the daemon is now running: To ensure that Libreswan will start when the system starts, issue the following command as root : 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 the Internet 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 setup IPsec 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 using TLS (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: 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: 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: 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: 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: 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 : 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: 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 : 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: To bring the tunnels up, restart Libreswan or manually load and initiate all the connections using the following commands as root : 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: 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: 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: 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: 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 the pkcs12(1) and pk12util(1) man pages for more information. On the mobile client, the road warrior's device, use a slight variation of the configuration: Where: auto=start This option enables the user to connect to the VPN whenever the ipsec system service is started. Replace it with the auto=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 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 remove users, a password file entry should look as follows: user1:USDapr1USDMIwQ3DHbUSD1I69LzTnZhnCT2DPQmAOK.:remoteusers Note When using the htpasswd 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: 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: 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 for ipsec . ipsec.conf(5) man page - Contains information on configuring ipsec . ipsec.secrets(5) man page - Describes the format of the ipsec.secrets file. ipsec_auto(8) man page - Describes the use of the auto command line client for manipulating Libreswan IPsec 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.
~]# yum install libreswan ~]USD yum info libreswan ~]# systemctl stop ipsec ~]# rm /etc/ipsec.d/*db ~]# ipsec initnss Initializing NSS database ~]# 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: ~]# systemctl start ipsec ~]USD 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 ~]# systemctl enable ipsec ~]# ipsec newhostkey --output /etc/ipsec.d/hostkey.secrets Generated RSA key pair with CKAID 14936e48e756eb107fa1438e25a345b46d80433f was stored in the NSS database ~]# 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== ~]# ipsec showhostkey --list < 1 > RSA keyid: AQPFKElpV ckaid: 14936e48e756eb107fa1438e25a345b46d80433f 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 ~]# systemctl restart ipsec ~]# ipsec auto --add mytunnel ~]# ipsec auto --up mytunnel ~]# 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 ~]# ipsec whack --trafficstatus 006 #2: "mytunnel", type=ESP, add_time=1234567890, inBytes=336, outBytes=336, id='@east' 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 ~]# 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} 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 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 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 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 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 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 @west @east : PPKS "user1" "thestringismeanttobearandomstr"