Chapter 5. Setting up an IPsec VPN A virtual private network (VPN) is a way of connecting to a local network over the internet. IPsec provided by Libreswan is the preferred method for creating a VPN. Libreswan is a user-space IPsec implementation for VPN. A VPN enables the communication between your LAN, and another, remote LAN by setting up a tunnel across an intermediate network such as the internet. For security reasons, a VPN tunnel always uses authentication and encryption. For cryptographic operations, Libreswan uses the NSS library. 5.1. Libreswan as an IPsec VPN implementation In RHEL, you can configure a Virtual Private Network (VPN) by 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 IPsec protocol for a VPN is 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 Layer 2 Tunneling Protocol (L2TP) is usually called an L2TP/IPsec VPN, which requires the xl2tpd package provided by the optional repository. Libreswan is an open-source, user-space IKE implementation. IKE v1 and v2 are implemented as a user-level daemon. The IKE protocol 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 protocols: Encapsulated Security Payload (ESP), which has protocol number 50. Authenticated Header (AH), which has 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 provides two modes of operation: Tunnel Mode (the default) Transport Mode You can configure the kernel with IPsec without IKE. This is called manual keying . You can also configure manual keying using the ip xfrm commands, however, this is strongly discouraged for security reasons. Libreswan communicates with the Linux kernel using the Netlink interface. The kernel performs packet encryption and decryption. Libreswan uses the Network Security Services (NSS) cryptographic library. NSS is 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 RHEL. Do not use any other VPN technology without understanding the risks of doing so. In RHEL, Libreswan follows system-wide cryptographic policies by default. This ensures that Libreswan uses secure settings for current threat models including IKEv2 as a default protocol. See Using system-wide crypto policies for more information. Libreswan does not use the terms "source" and "destination" or "server" and "client" because 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 you to use the same configuration on both end points in most cases. However, administrators usually choose to always use "left" for the local host and "right" for the remote host. The leftid and rightid options serve as identification of the respective hosts in the authentication process. See the ipsec.conf(5) man page for more information. 5.2. Authentication methods in Libreswan Libreswan supports several authentication methods, each of which fits a different scenario. Pre-Shared key (PSK) Pre-Shared Key (PSK) is the simplest authentication method. For security reasons, do not use PSKs shorter than 64 random characters. In FIPS mode, PSKs must comply with a minimum-strength requirement depending on the integrity algorithm used. You can set PSK by using the authby=secret connection. Raw RSA keys Raw RSA keys are commonly used for static host-to-host or subnet-to-subnet IPsec configurations. Each host is manually configured with the public RSA keys of all other hosts, and Libreswan sets up an IPsec tunnel between each pair of hosts. This method does not scale well for large numbers of hosts. You can generate a raw RSA key on a host using the ipsec newhostkey command. You can list generated keys by using the ipsec showhostkey command. The leftrsasigkey= line is required for connection configurations that use CKA ID keys. Use the authby=rsasig connection option for raw RSA keys. X.509 certificates X.509 certificates are commonly used for large-scale deployments with hosts that connect to a common IPsec gateway. A central certificate authority (CA) signs RSA certificates for hosts or users. This central CA is responsible for relaying trust, including the revocations of individual hosts or users. For example, you can generate X.509 certificates using the openssl command and the NSS certutil command. Because Libreswan reads user certificates from the NSS database using the certificates' nickname in the leftcert= configuration option, provide a nickname when you create a certificate. If you use a custom CA certificate, you must import it to the Network Security Services (NSS) database. You can import any certificate in the PKCS #12 format to the Libreswan NSS database by using the ipsec import command. Warning Libreswan requires an Internet Key Exchange (IKE) peer ID as a subject alternative name (SAN) for every peer certificate as described in section 3.1 of RFC 4945 . Disabling this check by changing the require-id-on-certificated= option can make the system vulnerable to man-in-the-middle attacks. Use the authby=rsasig connection option for authentication based on X.509 certificates using RSA with SHA-1 and SHA-2. You can further limit it for ECDSA digital signatures using SHA-2 by setting authby= to ecdsa and RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signatures based authentication with SHA-2 through authby=rsa-sha2 . The default value is authby=rsasig,ecdsa . The certificates and the authby= signature methods should match. This increases interoperability and preserves authentication in one digital signature system. NULL authentication NULL authentication is used to gain mesh encryption without authentication. It protects against passive attacks but not against active attacks. However, because IKEv2 allows asymmetric authentication methods, NULL authentication can also be used for internet-scale opportunistic IPsec. In this model, clients authenticate the server, but servers do not authenticate the client. This model is similar to secure websites using TLS. Use authby=null for NULL authentication. Protection against quantum computers In addition to the previously mentioned authentication methods, you can use the Post-quantum Pre-shared Key (PPK) method to protect against possible attacks by quantum computers. Individual clients or groups of clients can use their own PPK by specifying a PPK ID that corresponds to an out-of-band configured pre-shared key. Using IKEv1 with pre-shared keys protects against quantum attackers. The redesign of IKEv2 does not offer this protection natively. Libreswan offers the use of a Post-quantum Pre-shared Key (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 based on dictionary words. The PPK ID and PPK data are stored in the ipsec.secrets file, for example: The PPKS option refers to static PPKs. This experimental function uses one-time-pad-based Dynamic PPKs. Upon each connection, a new part of the one-time pad is used as the PPK. When used, that part of the dynamic PPK inside the file is overwritten with zeros 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 an unsupported Technology Preview. Use with caution. 5.3. Installing Libreswan Before you can set a VPN through the Libreswan IPsec/IKE implementation, you must install the corresponding packages, start the ipsec service, and allow the service in your firewall. Prerequisites The AppStream repository is enabled. Procedure Install the libreswan packages: If you are re-installing Libreswan, remove its old database files and create a new database: Start the ipsec service, and enable the service to be started automatically on boot: Configure the firewall to allow 500 and 4500/UDP ports for the IKE, ESP, and AH protocols by adding the ipsec service: 5.4. Creating a host-to-host VPN You can configure Libreswan to create a host-to-host IPsec VPN between two hosts referred to as left and right using authentication by raw RSA keys. Prerequisites Libreswan is installed and the ipsec service is started on each node. Procedure Generate a raw RSA key pair on each host: The step returned the generated key's ckaid . Use that ckaid with the following command on left , for example: The output of the command generated the leftrsasigkey= line required for the configuration. Do the same on the second host ( right ): In the /etc/ipsec.d/ directory, create a new my_host-to-host.conf file. Write the RSA host keys from the output of the ipsec showhostkey commands in the step to the new file. For example: After importing keys, restart the ipsec service: Load the connection: Establish the tunnel: To automatically start the tunnel when the ipsec service is started, add the following line to the connection definition: 5.5. Configuring a site-to-site VPN To create a site-to-site IPsec VPN, by joining two networks, an IPsec tunnel between the two hosts is created. The hosts thus act as the end points, which are configured to permit traffic from one or more subnets to pass through. Therefore you can think of the host 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. Prerequisites A host-to-host VPN is already configured. Procedure Copy the file with the configuration of your host-to-host VPN to a new file, for example: Add the subnet configuration to the file created in the step, for example: 5.6. Configuring a remote access VPN Road warriors are traveling users with mobile clients and a dynamically assigned IP address. The mobile clients authenticate using X.509 certificates. The following example shows configuration for IKEv2 , and it avoids using the IKEv1 XAUTH protocol. On the server: On the mobile client, the road warrior's device, use a slight variation of the configuration: 5.7. Configuring a mesh VPN A mesh VPN network, which is also known as an any-to-any VPN, is a network where all nodes communicate using IPsec. The configuration allows for exceptions for nodes that cannot use IPsec. The mesh VPN network can be configured in two ways: To require IPsec. To prefer IPsec but allow a fallback to clear-text communication. Authentication between the nodes can be based on X.509 certificates or on DNS Security Extensions (DNSSEC). You can use any regular IKEv2 authentication method for opportunistic IPsec , because these connections are regular Libreswan configurations, except for the opportunistic IPsec that is defined by right=%opportunisticgroup entry. A common authentication method is for hosts to authenticate each other based on X.509 certificates using a commonly shared certification authority (CA). Cloud deployments typically issue certificates for each node in the cloud as part of the standard procedure. Important Do not use PreSharedKey (PSK) authentication because one compromised host would result in the group PSK secret being compromised as well. You can use NULL authentication to deploy encryption between nodes without authentication, which protects only against passive attackers. The following procedure uses X.509 certificates. You can generate these certificates by using any kind of CA management system, such as the Dogtag Certificate System. Dogtag assumes that the certificates for each node are available in the PKCS #12 format ( .p12 files), which contain the private key, the node certificate, and the Root CA certificate used to validate other nodes' X.509 certificates. Each node has an identical configuration with the exception of its X.509 certificate. This allows for adding new nodes without reconfiguring any of the existing nodes in the network. The PKCS #12 files require a "friendly name", for which we use the name "node" so that the configuration files referencing the friendly name can be identical for all nodes. Prerequisites Libreswan is installed, and the ipsec service is started on each node. A new NSS database is initialized. If you already have an old NSS database, remove the old database files: You can initialize a new database with the following command: Procedure On each node, import PKCS #12 files. This step requires the password used to generate the PKCS #12 files: Create the following three connection definitions for the IPsec required (private), IPsec optional (private-or-clear), and No IPsec (clear) profiles: 1 The auto variable has several options: You can use the ondemand connection option with opportunistic IPsec to initiate the IPsec connection, or for explicitly configured connections that do not need to be active all the time. This option sets up a trap XFRM policy in the kernel, enabling the IPsec connection to begin when it receives the first packet that matches that policy. You can effectively configure and manage your IPsec connections, whether you use Opportunistic IPsec or explicitly configured connections, by using the following options: The add option Loads the connection configuration and prepares it for responding to remote initiations. However, the connection is not automatically initiated from the local side. You can manually start the IPsec connection by using the command ipsec auto --up . The start option Loads the connection configuration and prepares it for responding to remote initiations. Additionally, it immediately initiates a connection to the remote peer. You can use this option for permanent and always active connections. 2 The leftid and rightid variables identify the right and the left channel of the IPsec tunnel connection. You can use these variables to obtain the value of the local IP address or the subject DN of the local certificate, if you have configured one. 3 The leftcert variable defines the nickname of the NSS database that you want to use. Add the IP address of the network to the corresponding category. For example, if all nodes reside in the 10.15.0.0/16 network, and all nodes must use IPsec encryption: To allow certain nodes, for example, 10.15.34.0/24 , to work with and without IPsec, add those nodes to the private-or-clear group: To define a host, for example, 10.15.1.2 , which is not capable of IPsec into the clear group, use: You can create the files in the /etc/ipsec.d/policies directory from a template for each new node, or you can provision them by using Puppet or Ansible. Note that every node has the same list of exceptions or different traffic flow expectations. Two nodes, therefore, might not be able to communicate because one requires IPsec and the other cannot use IPsec. Restart the node to add it to the configured mesh: Verification Open an IPsec tunnel by using the ping command: Display the NSS database with the imported certification: See which tunnels are open on the node: Additional resources ipsec.conf(5) man page on your system For more information about the authby variable, see Authentication methods in Libreswan . 5.8. Deploying a FIPS-compliant IPsec VPN You can deploy a FIPS-compliant IPsec VPN solution with Libreswan. To do so, you can identify which cryptographic algorithms are available and which are disabled for Libreswan in FIPS mode. Prerequisites The AppStream repository is enabled. Procedure Install the libreswan packages: If you are re-installing Libreswan, remove its old NSS database: Start the ipsec service, and enable the service to be started automatically on boot: Configure the firewall to allow 500 and 4500 UDP ports for the IKE, ESP, and AH protocols by adding the ipsec service: Switch the system to FIPS mode: Restart your system to allow the kernel to switch to FIPS mode: Verification Confirm Libreswan is running in FIPS mode: Alternatively, check entries for the ipsec unit in the systemd journal: To see the available algorithms in FIPS mode: To query disabled algorithms in FIPS mode: To list all allowed algorithms and ciphers in FIPS mode: Additional resources Using system-wide cryptographic policies 5.9. Protecting the IPsec NSS database by a password By default, the IPsec service creates its Network Security Services (NSS) database with an empty password during the first start. To enhance security, you can add password protection. Note In the releases of RHEL up to version 6.6, you had to protect the IPsec NSS database with a password to meet the FIPS 140-2 requirements because the NSS cryptographic libraries were certified for the FIPS 140-2 Level 2 standard. In RHEL 8, NIST certified NSS to Level 1 of this standard, and this status does not require password protection for the database. Prerequisites The /etc/ipsec.d/ directory contains NSS database files. Procedure Enable password protection for the NSS database for Libreswan: Create the /etc/ipsec.d/nsspassword file that contains the password you have set in the step, for example: The nsspassword file use the following syntax: The default NSS software token is NSS Certificate DB . If your system is running in FIPS mode, the name of the token is NSS FIPS 140-2 Certificate DB . Depending on your scenario, either start or restart the ipsec service after you finish the nsspassword file: Verification Check that the ipsec service is running after you have added a non-empty password to its NSS database: Check that the Journal log contains entries that confirm a successful initialization: Additional resources certutil(1) man page on your system FIPS 140-2 and FIPS 140-3 in the Compliance Activities and Government Standards Knowledgebase article. 5.10. Configuring an IPsec VPN to use TCP Libreswan supports TCP encapsulation of IKE and IPsec packets as described in RFC 8229. With this feature, you can establish IPsec VPNs on networks that prevent traffic transmitted via UDP and Encapsulating Security Payload (ESP). You can configure VPN servers and clients to use TCP either as a fallback or as the main VPN transport protocol. Because TCP encapsulation has bigger performance costs, use TCP as the main VPN protocol only if UDP is permanently blocked in your scenario. Prerequisites A remote-access VPN is already configured. Procedure Add the following option to the /etc/ipsec.conf file in the config setup section: To use TCP encapsulation as a fallback option when the first attempt over UDP fails, add the following two options to the client's connection definition: Alternatively, if you know that UDP is permanently blocked, use the following options in the client's connection configuration: Additional resources IETF RFC 8229: TCP Encapsulation of IKE and IPsec Packets 5.11. Configuring automatic detection and usage of ESP hardware offload to accelerate an IPsec connection Offloading Encapsulating Security Payload (ESP) to the hardware accelerates IPsec connections over Ethernet. By default, Libreswan detects if hardware supports this feature and, as a result, enables ESP hardware offload. In case that the feature was disabled or explicitly enabled, you can switch back to automatic detection. Prerequisites The network card supports ESP hardware offload. The network driver supports ESP hardware offload. The IPsec connection is configured and works. Procedure Edit the Libreswan configuration file in the /etc/ipsec.d/ directory of the connection that should use automatic detection of ESP hardware offload support. Ensure the nic-offload parameter is not set in the connection's settings. If you removed nic-offload , restart the ipsec service: Verification Display the tx_ipsec and rx_ipsec counters of the Ethernet device the IPsec connection uses: Send traffic through the IPsec tunnel. For example, ping a remote IP address: Display the tx_ipsec and rx_ipsec counters of the Ethernet device again: If the counter values have increased, ESP hardware offload works. Additional resources Configuring a VPN with IPsec 5.12. Configuring ESP hardware offload on a bond to accelerate an IPsec connection Offloading Encapsulating Security Payload (ESP) to the hardware accelerates IPsec connections. If you use a network bond for fail-over reasons, the requirements and the procedure to configure ESP hardware offload are different from those using a regular Ethernet device. For example, in this scenario, you enable the offload support on the bond, and the kernel applies the settings to the ports of the bond. Prerequisites All network cards in the bond support ESP hardware offload. Use the ethtool -k <interface_name> | grep "esp-hw-offload" command to verify whether each bond port supports this feature. The bond is configured and works. The bond uses the active-backup mode. The bonding driver does not support any other modes for this feature. The IPsec connection is configured and works. Procedure Enable ESP hardware offload support on the network bond: This command enables ESP hardware offload support on the bond0 connection. Reactivate the bond0 connection: Edit the Libreswan configuration file in the /etc/ipsec.d/ directory of the connection that should use ESP hardware offload, and append the nic-offload=yes statement to the connection entry: Restart the ipsec service: Verification The verification methods depend on various aspects, such as the kernel version and driver. For example, certain drivers provide counters, but their names can vary. See the documentation of your network driver for details. The following verification steps work for the ixgbe driver on Red Hat Enterprise Linux 8: Display the active port of the bond: Display the tx_ipsec and rx_ipsec counters of the active port: Send traffic through the IPsec tunnel. For example, ping a remote IP address: Display the tx_ipsec and rx_ipsec counters of the active port again: If the counter values have increased, ESP hardware offload works. Additional resources Configuring a network bond Setting up an IPsec VPN 5.13. Configuring VPN connections with IPsec by using RHEL system roles With the vpn system role, you can configure VPN connections on RHEL systems by using Red Hat Ansible Automation Platform. You can use it to set up host-to-host, network-to-network, VPN Remote Access Server, and mesh configurations. For host-to-host connections, the role sets up a VPN tunnel between each pair of hosts in the list of vpn_connections using the default parameters, including generating keys as needed. Alternatively, you can configure it to create an opportunistic mesh configuration between all hosts listed. The role assumes that the names of the hosts under hosts are the same as the names of the hosts used in the Ansible inventory, and that you can use those names to configure the tunnels. Note The vpn RHEL system role currently supports only Libreswan, which is an IPsec implementation, as the VPN provider. 5.13.1. Creating a host-to-host VPN with IPsec by using the vpn RHEL system role You can use the vpn system role to configure host-to-host connections by running an Ansible playbook on the control node, which configures all managed nodes listed in an inventory file. Prerequisites You have prepared the control node and the managed nodes You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. Procedure Create a playbook file, for example ~/playbook.yml , with the following content: - name: Host to host VPN hosts: managed-node-01.example.com, managed-node-02.example.com roles: - rhel-system-roles.vpn vars: vpn_connections: - hosts: managed-node-01.example.com: managed-node-02.example.com: vpn_manage_firewall: true vpn_manage_selinux: true This playbook configures the connection managed-node-01.example.com-to-managed-node-02.example.com by using pre-shared key authentication with keys auto-generated by the system role. Because vpn_manage_firewall and vpn_manage_selinux are both set to true , the vpn role uses the firewall and selinux roles to manage the ports used by the vpn role. To configure connections from managed hosts to external hosts that are not listed in the inventory file, add the following section to the vpn_connections list of hosts: vpn_connections: - hosts: managed-node-01.example.com: <external_node> : hostname: <IP_address_or_hostname> This configures one additional connection: managed-node-01.example.com-to- <external_node> Note The connections are configured only on the managed nodes and not on the external node. Optional: You can specify multiple VPN connections for the managed nodes by using additional sections within vpn_connections , for example, a control plane and a data plane: - name: Multiple VPN hosts: managed-node-01.example.com, managed-node-02.example.com roles: - rhel-system-roles.vpn vars: vpn_connections: - name: control_plane_vpn hosts: managed-node-01.example.com: hostname: 192.0.2.0 # IP for the control plane managed-node-02.example.com: hostname: 192.0.2.1 - name: data_plane_vpn hosts: managed-node-01.example.com: hostname: 10.0.0.1 # IP for the data plane managed-node-02.example.com: hostname: 10.0.0.2 Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Verification On the managed nodes, confirm that the connection is successfully loaded: Replace <connection_name> with the name of the connection from this node, for example managed_node1-to-managed_node2 . Note By default, the role generates a descriptive name for each connection it creates from the perspective of each system. For example, when creating a connection between managed_node1 and managed_node2 , the descriptive name of this connection on managed_node1 is managed_node1-to-managed_node2 but on managed_node2 the connection is named managed_node2-to-managed_node1 . On the managed nodes, confirm that the connection is successfully started: Optional: If a connection does not successfully load, manually add the connection by entering the following command. This provides more specific information indicating why the connection failed to establish: Note Any errors that may occur during the process of loading and starting the connection are reported in the /var/log/pluto.log file. Because these logs are hard to parse, manually add the connection to obtain log messages from the standard output instead. Additional resources /usr/share/ansible/roles/rhel-system-roles.vpn/README.md file /usr/share/doc/rhel-system-roles/vpn/ directory 5.13.2. Creating an opportunistic mesh VPN connection with IPsec by using the vpn RHEL system role You can use the vpn system role to configure an opportunistic mesh VPN connection that uses certificates for authentication by running an Ansible playbook on the control node, which will configure all the managed nodes listed in an inventory file. Prerequisites You have prepared the control node and the managed nodes You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The IPsec Network Security Services (NSS) crypto library in the /etc/ipsec.d/ directory contains the necessary certificates. Procedure Create a playbook file, for example ~/playbook.yml , with the following content: - name: Mesh VPN hosts: managed-node-01.example.com, managed-node-02.example.com, managed-node-03.example.com roles: - rhel-system-roles.vpn vars: vpn_connections: - opportunistic: true auth_method: cert policies: - policy: private cidr: default - policy: private-or-clear cidr: 198.51.100.0/24 - policy: private cidr: 192.0.2.0/24 - policy: clear cidr: 192.0.2.7/32 vpn_manage_firewall: true vpn_manage_selinux: true Authentication with certificates is configured by defining the auth_method: cert parameter in the playbook. By default, the node name is used as the certificate nickname. In this example, this is managed-node-01.example.com . You can define different certificate names by using the cert_name attribute in your inventory. In this example procedure, the control node, which is the system from which you will run the Ansible playbook, shares the same classless inter-domain routing (CIDR) number as both of the managed nodes (192.0.2.0/24) and has the IP address 192.0.2.7. Therefore, the control node falls under the private policy which is automatically created for CIDR 192.0.2.0/24. To prevent SSH connection loss during the play, a clear policy for the control node is included in the list of policies. Note that there is also an item in the policies list where the CIDR is equal to default. This is because this playbook overrides the rule from the default policy to make it private instead of private-or-clear. Because vpn_manage_firewall and vpn_manage_selinux are both set to true , the vpn role uses the firewall and selinux roles to manage the ports used by the vpn role. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.vpn/README.md file /usr/share/doc/rhel-system-roles/vpn/ directory 5.14. Configuring IPsec connections that opt out of the system-wide crypto policies Overriding system-wide crypto-policies for a connection The RHEL system-wide cryptographic policies create a special connection called %default . This connection contains the default values for the ikev2 , esp , and ike options. However, you can override the default values by specifying the mentioned option in the connection configuration file. For example, the following configuration allows connections that use IKEv1 with AES and SHA-1 or SHA-2, and IPsec (ESP) with either AES-GCM or AES-CBC: Note that AES-GCM is available for IPsec (ESP) and for IKEv2, but not for IKEv1. Disabling system-wide crypto policies for all connections To disable system-wide crypto policies for all IPsec connections, comment out the following line in the /etc/ipsec.conf file: Then add the ikev2=never option to your connection configuration file. Additional resources Using system-wide cryptographic policies 5.15. Troubleshooting IPsec VPN configurations Problems related to IPsec VPN configurations most commonly occur due to several main reasons. If you are encountering such problems, you can check if the cause of the problem corresponds to any of the following scenarios, and apply the corresponding solution. Basic connection troubleshooting Most problems with VPN connections occur in new deployments, where administrators configured endpoints with mismatched configuration options. Also, a working configuration can suddenly stop working, often due to newly introduced incompatible values. This could be the result of an administrator changing the configuration. Alternatively, an administrator may have installed a firmware update or a package update with different default values for certain options, such as encryption algorithms. To confirm that an IPsec VPN connection is established: If the output is empty or does not show an entry with the connection name, the tunnel is broken. To check that the problem is in the connection: Reload the vpn.example.com connection: , initiate the VPN connection: Firewall-related problems The most common problem is that a firewall on one of the IPsec endpoints or on a router between the endpoints is dropping all Internet Key Exchange (IKE) packets. For IKEv2, an output similar to the following example indicates a problem with a firewall: For IKEv1, the output of the initiating command looks like: Because the IKE protocol, which is used to set up IPsec, is encrypted, you can troubleshoot only a limited subset of problems using the tcpdump tool. If a firewall is dropping IKE or IPsec packets, you can try to find the cause using the tcpdump utility. However, tcpdump cannot diagnose other problems with IPsec VPN connections. To capture the negotiation of the VPN and all encrypted data on the eth0 interface: Mismatched algorithms, protocols, and policies VPN connections require that the endpoints have matching IKE algorithms, IPsec algorithms, and IP address ranges. If a mismatch occurs, the connection fails. If you identify a mismatch by using one of the following methods, fix it by aligning algorithms, protocols, or policies. If the remote endpoint is not running IKE/IPsec, you can see an ICMP packet indicating it. For example: Example of mismatched IKE algorithms: Example of mismatched IPsec algorithms: A mismatched IKE version could also result in the remote endpoint dropping the request without a response. This looks identical to a firewall dropping all IKE packets. Example of mismatched IP address ranges for IKEv2 (called Traffic Selectors - TS): Example of mismatched IP address ranges for IKEv1: When using PreSharedKeys (PSK) in IKEv1, if both sides do not put in the same PSK, the entire IKE message becomes unreadable: In IKEv2, the mismatched-PSK error results in an AUTHENTICATION_FAILED message: Maximum transmission unit Other than firewalls blocking IKE or IPsec packets, the most common cause of networking problems relates to an increased packet size of encrypted packets. Network hardware fragments packets larger than the maximum transmission unit (MTU), for example, 1500 bytes. Often, the fragments are lost and the packets fail to re-assemble. This leads to intermittent failures, when a ping test, which uses small-sized packets, works but other traffic fails. In this case, you can establish an SSH session but the terminal freezes as soon as you use it, for example, by entering the 'ls -al /usr' command on the remote host. To work around the problem, reduce MTU size by adding the mtu=1400 option to the tunnel configuration file. Alternatively, for TCP connections, enable an iptables rule that changes the MSS value: If the command does not solve the problem in your scenario, directly specify a lower size in the set-mss parameter: Network address translation (NAT) When an IPsec host also serves as a NAT router, it could accidentally remap packets. The following example configuration demonstrates the problem: The system with address 172.16.0.1 have a NAT rule: If the system on address 10.0.2.33 sends a packet to 192.168.0.1, then the router translates the source 10.0.2.33 to 172.16.0.1 before it applies the IPsec encryption. Then, the packet with the source address 10.0.2.33 no longer matches the conn myvpn configuration, and IPsec does not encrypt this packet. To solve this problem, insert rules that exclude NAT for target IPsec subnet ranges on the router, in this example: Kernel IPsec subsystem bugs The kernel IPsec subsystem might fail, for example, when a bug causes a desynchronizing of the IKE user space and the IPsec kernel. To check for such problems: Any non-zero value in the output of the command indicates a problem. If you encounter this problem, open a new support case , and attach the output of the command along with the corresponding IKE logs. Libreswan logs Libreswan logs using the syslog protocol by default. You can use the journalctl command to find log entries related to IPsec. Because the corresponding entries to the log are sent by the pluto IKE daemon, search for the "pluto" keyword, for example: To show a live log for the ipsec service: If the default level of logging does not reveal your configuration problem, enable debug logs by adding the plutodebug=all option to the config setup section in the /etc/ipsec.conf file. Note that debug logging produces a lot of entries, and it is possible that either the journald or syslogd service rate-limits the syslog messages. To ensure you have complete logs, redirect the logging to a file. Edit the /etc/ipsec.conf , and add the logfile=/var/log/pluto.log in the config setup section. Additional resources Troubleshooting problems by using log files tcpdump(8) and ipsec.conf(5) man pages. Using and configuring firewalld 5.16. Configuring a VPN connection with control-center If you use Red Hat Enterprise Linux with a graphical interface, you can configure a VPN connection in the GNOME control-center . Prerequisites The NetworkManager-libreswan-gnome package is installed. Procedure Press the Super key, type Settings , and press Enter to open the control-center application. Select the Network entry on the left. Click the + icon. Select VPN . Select the Identity menu entry to see the basic configuration options: General Gateway - The name or IP address of the remote VPN gateway. Authentication Type IKEv2 (Certificate) - client is authenticated by certificate. It is more secure (default). IKEv1 (XAUTH) - client is authenticated by user name and password, or a pre-shared key (PSK). The following configuration settings are available under the Advanced section: Figure 5.1. Advanced options of a VPN connection Warning When configuring an IPsec-based VPN connection using the gnome-control-center application, the Advanced dialog displays the configuration, but it does not allow any changes. As a consequence, users cannot change any advanced IPsec options. Use the nm-connection-editor or nmcli tools instead to perform configuration of the advanced properties. Identification Domain - If required, enter the Domain Name. Security Phase1 Algorithms - corresponds to the ike Libreswan parameter - enter the algorithms to be used to authenticate and set up an encrypted channel. Phase2 Algorithms - corresponds to the esp Libreswan parameter - enter the algorithms to be used for the IPsec negotiations. Check the Disable PFS field to turn off Perfect Forward Secrecy (PFS) to ensure compatibility with old servers that do not support PFS. Phase1 Lifetime - corresponds to the ikelifetime Libreswan parameter - how long the key used to encrypt the traffic will be valid. Phase2 Lifetime - corresponds to the salifetime Libreswan parameter - how long a particular instance of a connection should last before expiring. Note that the encryption key should be changed from time to time for security reasons. Remote network - corresponds to the rightsubnet Libreswan parameter - the destination private remote network that should be reached through the VPN. Check the narrowing field to enable narrowing. Note that it is only effective in IKEv2 negotiation. Enable fragmentation - corresponds to the fragmentation Libreswan parameter - whether or not to allow IKE fragmentation. Valid values are yes (default) or no . Enable Mobike - corresponds to the mobike Libreswan parameter - whether or not to allow Mobility and Multihoming Protocol (MOBIKE, RFC 4555) to enable a connection to migrate its endpoint without needing to restart the connection from scratch. This is used on mobile devices that switch between wired, wireless, or mobile data connections. The values are no (default) or yes . Select the IPv4 menu entry: IPv4 Method Automatic (DHCP) - Choose this option if the network you are connecting to uses a DHCP server to assign dynamic IP addresses. Link-Local Only - Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be assigned as per RFC 3927 with prefix 169.254/16 . Manual - Choose this option if you want to assign IP addresses manually. Disable - IPv4 is disabled for this connection. DNS In the DNS section, when Automatic is ON , switch it to OFF to enter the IP address of a DNS server you want to use separating the IPs by comma. Routes Note that in the Routes section, when Automatic is ON , routes from DHCP are used, but you can also add additional static routes. When OFF , only static routes are used. Address - Enter the IP address of a remote network or host. Netmask - The netmask or prefix length of the IP address entered above. Gateway - The IP address of the gateway leading to the remote network or host entered above. Metric - A network cost, a preference value to give to this route. Lower values will be preferred over higher values. Use this connection only for resources on its network Select this check box to prevent the connection from becoming the default route. Selecting this option means that only traffic specifically destined for routes learned automatically over the connection or entered here manually is routed over the connection. To configure IPv6 settings in a VPN connection, select the IPv6 menu entry: IPv6 Method Automatic - Choose this option to use IPv6 Stateless Address AutoConfiguration (SLAAC) to create an automatic, stateless configuration based on the hardware address and Router Advertisements (RA). Automatic, DHCP only - Choose this option to not use RA, but request information from DHCPv6 directly to create a stateful configuration. Link-Local Only - Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be assigned as per RFC 4862 with prefix FE80::0 . Manual - Choose this option if you want to assign IP addresses manually. Disable - IPv6 is disabled for this connection. Note that DNS , Routes , Use this connection only for resources on its network are common to IPv4 settings. Once you have finished editing the VPN connection, click the Add button to customize the configuration or the Apply button to save it for the existing one. Switch the profile to ON to activate the VPN connection. Additional resources nm-settings-libreswan(5) 5.17. Configuring a VPN connection using nm-connection-editor If you use Red Hat Enterprise Linux with a graphical interface, you can configure a VPN connection in the nm-connection-editor application. Prerequisites The NetworkManager-libreswan-gnome package is installed. If you configure an Internet Key Exchange version 2 (IKEv2) connection: The certificate is imported into the IPsec network security services (NSS) database. The nickname of the certificate in the NSS database is known. Procedure Open a terminal, and enter: Click the + button to add a new connection. Select the IPsec based VPN connection type, and click Create . On the VPN tab: Enter the host name or IP address of the VPN gateway into the Gateway field, and select an authentication type. Based on the authentication type, you must enter different additional information: IKEv2 (Certifiate) authenticates the client by using a certificate, which is more secure. This setting requires the nickname of the certificate in the IPsec NSS database IKEv1 (XAUTH) authenticates the user by using a user name and password (pre-shared key). This setting requires that you enter the following values: User name Password Group name Secret If the remote server specifies a local identifier for the IKE exchange, enter the exact string in the Remote ID field. In the remote server runs Libreswan, this value is set in the server's leftid parameter. Optional: Configure additional settings by clicking the Advanced button. You can configure the following settings: Identification Domain - If required, enter the domain name. Security Phase1 Algorithms corresponds to the ike Libreswan parameter. Enter the algorithms to be used to authenticate and set up an encrypted channel. Phase2 Algorithms corresponds to the esp Libreswan parameter. Enter the algorithms to be used for the IPsec negotiations. Check the Disable PFS field to turn off Perfect Forward Secrecy (PFS) to ensure compatibility with old servers that do not support PFS. Phase1 Lifetime corresponds to the ikelifetime Libreswan parameter. This parameter defines how long the key used to encrypt the traffic is valid. Phase2 Lifetime corresponds to the salifetime Libreswan parameter. This parameter defines how long a security association is valid. Connectivity Remote network corresponds to the rightsubnet Libreswan parameter and defines the destination private remote network that should be reached through the VPN. Check the narrowing field to enable narrowing. Note that it is only effective in the IKEv2 negotiation. Enable fragmentation corresponds to the fragmentation Libreswan parameter and defines whether or not to allow IKE fragmentation. Valid values are yes (default) or no . Enable Mobike corresponds to the mobike Libreswan parameter. The parameter defines whether or not to allow Mobility and Multihoming Protocol (MOBIKE) (RFC 4555) to enable a connection to migrate its endpoint without needing to restart the connection from scratch. This is used on mobile devices that switch between wired, wireless or mobile data connections. The values are no (default) or yes . On the IPv4 Settings tab, select the IP assignment method and, optionally, set additional static addresses, DNS servers, search domains, and routes. Save the connection. Close nm-connection-editor . Note When you add a new connection by clicking the + button, NetworkManager creates a new configuration file for that connection and then opens the same dialog that is used for editing an existing connection. The difference between these dialogs is that an existing connection profile has a Details menu entry. Additional resources nm-settings-libreswan(5) man page on your system 5.18. Additional resources ipsec(8) , ipsec.conf(5) , ipsec.secrets(5) , ipsec_auto(8) , and ipsec_rsasigkey(8) man pages. /usr/share/doc/libreswan- version / directory. The Libreswan Project Wiki . All Libreswan man pages . NIST Special Publication 800-77: Guide to IPsec VPNs .

Commands:
@west @east : PPKS "user1" "thestringismeanttobearandomstr"
yum install libreswan
systemctl stop ipsec rm /etc/ipsec.d/*db ipsec initnss
systemctl enable ipsec --now
firewall-cmd --add-service="ipsec" firewall-cmd --runtime-to-permanent
ipsec newhostkey
ipsec showhostkey --left --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d
ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03
conn mytunnel leftid=@west left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig
systemctl restart ipsec
ipsec auto --add mytunnel
ipsec auto --up mytunnel
auto=start
cp /etc/ipsec.d/ my_host-to-host.conf /etc/ipsec.d/ my_site-to-site .conf
conn mysubnet also=mytunnel leftsubnet=192.0.1.0/24 rightsubnet=192.0.2.0/24 auto=start conn mysubnet6 also=mytunnel leftsubnet=2001:db8:0:1::/64 rightsubnet=2001:db8:0:2::/64 auto=start the following part of the configuration file is the same for both host-to-host and site-to-site connections: conn mytunnel leftid=@west left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig
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=gw.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 or deny client # pam-authorize=yes # load connection, do not 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 fragmentation=yes # 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
systemctl stop ipsec rm /etc/ipsec.d/*db
ipsec initnss
ipsec import nodeXXX.p12
cat /etc/ipsec.d/mesh.conf conn clear auto=ondemand 1 type=passthrough authby=never left=%defaultroute right=%group conn private auto=ondemand type=transport authby=rsasig failureshunt=drop negotiationshunt=drop ikev2=insist left=%defaultroute leftcert= nodeXXXX leftid=%fromcert 2 rightid=%fromcert right=%opportunisticgroup conn private-or-clear auto=ondemand type=transport authby=rsasig failureshunt=passthrough negotiationshunt=passthrough # left left=%defaultroute leftcert= nodeXXXX 3 leftid=%fromcert leftrsasigkey=%cert # right rightrsasigkey=%cert rightid=%fromcert right=%opportunisticgroup
echo "10.15.0.0/16" >> /etc/ipsec.d/policies/private
echo "10.15.34.0/24" >> /etc/ipsec.d/policies/private-or-clear
echo "10.15.1.2/32" >> /etc/ipsec.d/policies/clear
systemctl restart ipsec
ping <nodeYYY>
certutil -L -d sql:/etc/ipsec.d Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI west u,u,u ca CT,,
ipsec trafficstatus 006 #2: "private#10.15.0.0/16"[1] ... <nodeYYY> , type=ESP, add_time=1691399301, inBytes=512, outBytes=512, maxBytes=2^63B, id='C=US, ST=NC, O=Example Organization, CN=east'
yum install libreswan
systemctl stop ipsec rm /etc/ipsec.d/*db
systemctl enable ipsec --now
firewall-cmd --add-service="ipsec" firewall-cmd --runtime-to-permanent
fips-mode-setup --enable
reboot
ipsec whack --fipsstatus 000 FIPS mode enabled
journalctl -u ipsec Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Product: YES Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Kernel: YES Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Mode: YES
ipsec pluto --selftest 2>&1 | head -11 FIPS Product: YES FIPS Kernel: YES FIPS Mode: YES NSS DB directory: sql:/etc/ipsec.d Initializing NSS Opening NSS database "sql:/etc/ipsec.d" read-only NSS initialized NSS crypto library initialized FIPS HMAC integrity support [enabled] FIPS mode enabled for pluto daemon NSS library is running in FIPS mode FIPS HMAC integrity verification self-test passed
ipsec pluto --selftest 2>&1 | grep disabled Encryption algorithm CAMELLIA_CTR disabled; not FIPS compliant Encryption algorithm CAMELLIA_CBC disabled; not FIPS compliant Encryption algorithm SERPENT_CBC disabled; not FIPS compliant Encryption algorithm TWOFISH_CBC disabled; not FIPS compliant Encryption algorithm TWOFISH_SSH disabled; not FIPS compliant Encryption algorithm NULL disabled; not FIPS compliant Encryption algorithm CHACHA20_POLY1305 disabled; not FIPS compliant Hash algorithm MD5 disabled; not FIPS compliant PRF algorithm HMAC_MD5 disabled; not FIPS compliant PRF algorithm AES_XCBC disabled; not FIPS compliant Integrity algorithm HMAC_MD5_96 disabled; not FIPS compliant Integrity algorithm HMAC_SHA2_256_TRUNCBUG disabled; not FIPS compliant Integrity algorithm AES_XCBC_96 disabled; not FIPS compliant DH algorithm MODP1024 disabled; not FIPS compliant DH algorithm MODP1536 disabled; not FIPS compliant DH algorithm DH31 disabled; not FIPS compliant
ipsec pluto --selftest 2>&1 | grep ESP | grep FIPS | sed "s/^.*FIPS//" {256,192,*128} aes_ccm, aes_ccm_c {256,192,*128} aes_ccm_b {256,192,*128} aes_ccm_a [*192] 3des {256,192,*128} aes_gcm, aes_gcm_c {256,192,*128} aes_gcm_b {256,192,*128} aes_gcm_a {256,192,*128} aesctr {256,192,*128} aes {256,192,*128} aes_gmac sha, sha1, sha1_96, hmac_sha1 sha512, sha2_512, sha2_512_256, hmac_sha2_512 sha384, sha2_384, sha2_384_192, hmac_sha2_384 sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256 aes_cmac null null, dh0 dh14 dh15 dh16 dh17 dh18 ecp_256, ecp256 ecp_384, ecp384 ecp_521, ecp521
certutil -N -d sql:/etc/ipsec.d Enter Password or Pin for "NSS Certificate DB": 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:
cat /etc/ipsec.d/nsspassword NSS Certificate DB:_<password>_
<token_1> : <password1> <token_2> : <password2>
systemctl restart ipsec
systemctl status ipsec ● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; vendor preset: disable> Active: active (running)
journalctl -u ipsec pluto[6214]: Initializing NSS using read-write database "sql:/etc/ipsec.d" pluto[6214]: NSS Password from file "/etc/ipsec.d/nsspassword" for token "NSS Certificate DB" with length 20 passed to NSS pluto[6214]: NSS crypto library initialized
listen-tcp=yes
enable-tcp=fallback tcp-remoteport=4500
enable-tcp=yes tcp-remoteport=4500
systemctl restart ipsec
ethtool -S enp1s0 | grep -E "_ipsec" tx_ipsec: 10 rx_ipsec: 10
ping -c 5 remote_ip_address
ethtool -S enp1s0 | grep -E "_ipsec" tx_ipsec: 15 rx_ipsec: 15
nmcli connection modify bond0 ethtool.feature-esp-hw-offload on
nmcli connection up bond0
conn example nic-offload=yes
systemctl restart ipsec
grep "Currently Active Slave" /proc/net/bonding/ bond0 Currently Active Slave: enp1s0
ethtool -S enp1s0 | grep -E "_ipsec" tx_ipsec: 10 rx_ipsec: 10
ping -c 5 remote_ip_address
ethtool -S enp1s0 | grep -E "_ipsec" tx_ipsec: 15 rx_ipsec: 15
- name: Host to host VPN hosts: managed-node-01.example.com, managed-node-02.example.com roles: - rhel-system-roles.vpn vars: vpn_connections: - hosts: managed-node-01.example.com: managed-node-02.example.com: vpn_manage_firewall: true vpn_manage_selinux: true
vpn_connections: - hosts: managed-node-01.example.com: <external_node> : hostname: <IP_address_or_hostname>
- name: Multiple VPN hosts: managed-node-01.example.com, managed-node-02.example.com roles: - rhel-system-roles.vpn vars: vpn_connections: - name: control_plane_vpn hosts: managed-node-01.example.com: hostname: 192.0.2.0 # IP for the control plane managed-node-02.example.com: hostname: 192.0.2.1 - name: data_plane_vpn hosts: managed-node-01.example.com: hostname: 10.0.0.1 # IP for the data plane managed-node-02.example.com: hostname: 10.0.0.2
ansible-playbook --syntax-check ~/playbook.yml
ansible-playbook ~/playbook.yml
ipsec status | grep <connection_name>
ipsec trafficstatus | grep <connection_name>
ipsec auto --add <connection_name>
- name: Mesh VPN hosts: managed-node-01.example.com, managed-node-02.example.com, managed-node-03.example.com roles: - rhel-system-roles.vpn vars: vpn_connections: - opportunistic: true auth_method: cert policies: - policy: private cidr: default - policy: private-or-clear cidr: 198.51.100.0/24 - policy: private cidr: 192.0.2.0/24 - policy: clear cidr: 192.0.2.7/32 vpn_manage_firewall: true vpn_manage_selinux: true
ansible-playbook --syntax-check ~/playbook.yml
ansible-playbook ~/playbook.yml
conn MyExample ikev2=never ike=aes-sha2,aes-sha1;modp2048 esp=aes_gcm,aes-sha2,aes-sha1
include /etc/crypto-policies/back-ends/libreswan.config
ipsec trafficstatus 006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=100.64.13.5/32
ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"
ipsec auto --up vpn.example.com
ipsec auto --up vpn.example.com 181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA 181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for
ipsec auto --up vpn.example.com 002 "vpn.example.com" #9: initiating Main Mode 102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response
tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500
ipsec auto --up vpn.example.com 000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
ipsec auto --up vpn.example.com 003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
ipsec auto --up vpn.example.com 182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048} 002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSEN
ipsec auto --up vpn.example.com 1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLE
ipsec auto --up vpn.example.com 031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
ipsec auto --up vpn.example.com 003 "vpn.example.com" #1: received Hash Payload does not match computed value 223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500
ipsec auto --up vpn.example.com 002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
conn myvpn left=172.16.0.1 leftsubnet=10.0.2.0/24 right=172.16.0.2 rightsubnet=192.168.0.0/16 ...
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN
cat /proc/net/xfrm_stat XfrmInError 0 XfrmInBufferError 0
journalctl -b | grep pluto
journalctl -f -u ipsec
nm-connection-editor