6.6. Manually configuring an IPsec mesh VPN with certificate-based authentication

Procedure

1. If Libreswan is not yet installed, perform the following steps:

   1. Install the libreswan package:

      # dnf install libreswan

   2. Initialize the Network Security Services (NSS) database:

      # ipsec initnss

      The command creates the database in the /var/lib/ipsec/nss/ directory.

   3. Enable and start the ipsec service:

      # systemctl enable --now ipsec

   4. Open the IPsec ports and protocols in the firewall:

      # firewall-cmd --permanent --add-service="ipsec"
      # firewall-cmd --reload

2. Import the PKCS #12 file into the NSS database:

   # ipsec import <file>.p12
   Enter password for PKCS12 file: <password>
   pk12util: PKCS12 IMPORT SUCCESSFUL
   correcting trust bits for Example-CA

3. Display the nicknames of the server and CA certificates:

   # certutil -L -d /var/lib/ipsec/nss/
   Certificate Nickname     Trust Attributes
                            SSL,S/MIME,JAR/XPI
   
   server1                  u,u,u
   Example-CA               CT,,
   ...

   You need this information for the configuration file.

4. Create a .conf file for the connection in the /etc/ipsec.d/ directory. For example, create the /etc/ipsec.d/mesh.conf file with the following settings:

   1. Add a config setup section to enable CRL checks:

      config setup
          crl-strict=yes
          crlcheckinterval=1h

      The settings specified in the example include the following:

      crl-strict=yes

      Enables CRL checks. Authenticating peers are rejected if no CRL is available in the NSS database.

      crlcheckinterval=1h

      Re-fetches the CRL from the URL specified in the server’s certificate after the specified period.

   2. Add a section that enforces traffic among members in the mesh:

      conn <connection_name>
          # General setup and authentication type
          auto=ondemand
          authby=rsasig
      
          # Local settings settings
          left=%defaultroute
          leftid=%fromcert
          leftcert="<server_certificate_nickname>"
          leftrsasigkey=%cert
          leftsendcert=always
          failureshunt=drop
          type=transport
      
          # Settings related to other peers in the mesh
          right=%opportunisticgroup
          rightid=%fromcert

      The settings specified in the example include the following:

      left=%defaultroute

      Dynamically sets the IP address of the default route interface when the ipsec service starts. Alternatively, you can set the left parameter to the IP address or the FQDN of the host.

      leftid=%fromcert and rightid=%fromcert

      Configures Libreswan to retrieve the identity from the distinguished name (DN) field of the certificate.

      leftcert="<server_certificate_nickname>"

      Sets the nickname of the server’s certificate used in the NSS database.

      leftrsasigkey=%cert

      Configures Libreswan to use the RSA public key embedded in the certificate.

      leftsendcert=always

      Instructs the peer to always send the certificate, so that peers can validate it against the CA certificate.

      failureshunt=drop

      Enforces encryption and drops traffic if IPsec negotiation fails. This is critical for a secure mesh.

      right=%opportunisticgroup

      Specifies that the connection should apply to a dynamic group of remote peers defined in a policy file. This enables Libreswan to instantiate IPsec tunnels opportunistically for each listed IP or subnet in that group.

   For details about all parameters used in the example, see the ipsec.conf(5) man page on your system.

5. Create the /etc/ipsec.d/policies/server-mesh policy file that specifies the peers or subnets in classless inter-domain routing (CIDR) format:

   192.0.2.0/24
   198.51.100.0/24

   With these settings, the ipsec service encrypts traffic between hosts in these subnets. If a host is not configured as a member of the IPsec mesh, communication between this host and the mesh members fails.

6. Restart the ipsec service:

   # systemctl restart ipsec

7. Repeat the procedure on every host in the subnets you specified in the policy file.

Verification

1. Send traffic to a host in the mesh to establish the tunnel. For example, ping the host:

   # ping -c3 <peer_in_mesh>

2. Display the IPsec status:

   # ipsec status

   If the connection is successfully established, the output contains lines as follows for the peer:

   • Phase 1 of an Internet Key Exchange version 2 (IKEv2) negotiation has been successfully completed:

     #1: "<connection_name>#192.0.2.0/24"[1] ...192.0.2.2:500 ESTABLISHED_IKE_SA (established IKE SA); REKEY in 12822s; REPLACE in 13875s; newest; idle;

     The Security Association (SA) is now ready to negotiate the actual data encryption tunnels, known as child SAs or Phase 2 SAs.

   • A child SA has been established:

     #2: "<connection_name>#192.0.2.0/24"[1] ...192.0.2.2:500 ESTABLISHED_CHILD_SA (established Child SA); REKEY in 13071s; REPLACE in 13875s; newest; eroute owner; IKE SA #1; idle;

     This is the actual tunnel that your data traffic flows through.

3. Check if the service loaded the CRL and added the entries to the NSS database:

   # ipsec listcrls
   
   List of CRLs:
   
   issuer: CN=Example-CA
   revoked certs: 1
   updates: this Tue Jul 15 10:22:36 2025
            next Sun Jan 11 10:22:36 2026
   
   List of CRL fetch requests:
   
   Jul 15 15:13:56 2025, trials: 1
          issuer:  'CN=Example-CA'
          distPts: 'https://ca.example.com/crl.pem'