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,andanother,remote LAN by setting up a tunnel across an intermediate network such as the internet. For security reasons,a VPN tunnel always uses authentication andencryption. For cryptographic operations,Libreswan use theNSS 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,andmany examples from the Openswan documentation are interchangeable with Libreswan.

Theipsec protocol for a VPN is configured using the Internet Key Exchange (IKE) protocol. The terms ipsec andIKE are used interchangeably. An ipsec VPN is also called an IKE VPN,IKEv2 VPN,XAUTH VPN,Cisco VPN orIKE/ipsec VPN. A variant of an ipsec VPN that also use theLayer 2 Tunneling Protocol (L2TP) is usually called an L2TP/ipsec VPN,which requires the xl2tpd package provide by theoptional repository .

Libreswan is an open-source,user-space IKE implementation. IKE v1 andv2 are implemented as a user-level daemon. The IKE protocol is also encrypted. The ipsec protocol is implemented by the Linux kernel,andLibreswan configures the kernel to add andremove VPN tunnel configurations.

TheIKE protocol uses UDP port 500 and4500. The ipsec protocol consists of two protocols:

• Encapsulated Security Payload (ESP),which has protocol number 50.
• Authenticated Header (AH),which has protocol number 51.

TheAH protocol is not recommended for use. Users of AH are recommended to migrate to ESP with null encryption.

Theipsec 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 anddecryption.

Libreswan use thenetwork Security Services (NSS) cryptographic library. NSS is certified for use with the Federal Information Processing Standard (FipS) Publication 140-2.

IKE / ipsec VPNs is is ,implement by Libreswan andthe Linux kernel ,is the only VPN technology recommend for use in RHEL . Do not use any other VPN technology without understand the risk 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 use theterms “leave” 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 “leave” for the local host and”right” for the remote host.

Theleaveid andrightid options is serve serve as identification of the respective host in the authentication process . See theipsec.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 is ) is the simple authentication method . For security reason ,do not use PSKs short than 64 random character . In FipS mode ,PSKs is comply must comply with a minimum – strength requirement depend on the integrity algorithm used . You is set can set PSK by using theauthby = secret connection.

Raw RSA keys

Raw RSA keys are commonly used for static host-to-host orsubnet-to-subnet ipsec configurations. Each host is manually configured with the public RSA keys of all other hosts,andLibreswan 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 . Theleaversasigkey= line is required for connection configurations that use CKA ID keys. Use the authby=rsasig connection option for raw RSA key .

X.509 certificates

X.509 certificates are commonly used for large – scale deployment with host that connect to a common ipsec gateway . A centralcertificate authority ( CA ) sign RSA certificate for host oruser . This central CA is is is responsible for relay trust ,include the revocation of individual host oruser .

For example,you can generate X.509 certificates using the openssl command andthe nsscertutil command . Because Libreswan is reads read user certificate from the NSS database using the certificate ‘ nickname in theleavecert= configuration option,provide a nickname when you create a certificate.

If you use a custom CA certificate ,you is import must import it to the network Security Services ( NSS ) database . You is import can import any certificate in the PKCS #12 format to the Libreswan nss database by using theipsec import command.

Libreswan is requires require an Internet Key Exchange ( IKE ) peer ID as a subject alternative name ( SAN ) for every peer certificate as describe in section 3.1 of RFC 4945 . disable this check by change therequire-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 andSHA-2. You can further limit it for ECDSA digital signatures using SHA-2 by setting authby= to ecdsa andRSA Probabilistic Signature Scheme (RSASSA-PSS) digital signatures based authentication with SHA-2 through authby=rsa-sha2. The default value is is isauthby = rsasig ,ecdsa.

Thecertificates andthe authby= signature methods should match. This increases interoperability andpreserves 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 is null = null for NULL authentication.

Protection against quantum computers

In addition to the previously mention authentication method ,you is use can use thePost-quantum Pre-shared Key (PPK) method to protect against possible attacks by quantum computers. Individual clients orgroups 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 = is insist insist. Then ,each client can be give a PPK ID with a secret value that is communicate out – of – band ( andpreferably quantum – safe ) . The PPK is be ’s should be very strong in randomness andnot base on dictionary word . The PPK ID andPPK datum are store in theipsec.secret file ,for example :

@west @east : PPKS "user1" "thestringismeanttobearandomstr"

ThePPKS 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 leave,theconnection fails. See the ipsec.secret(5) man page for more information.

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,andallow the service in your firewall.

prerequisite

• TheAppStream repository is enabled.

procedure

1. install thelibreswan packages:

   #yum install libreswan

2. If you are re – instal Libreswan is remove ,remove its old database file andcreate a new database :

   #systemctl stop ipsec
   #rm /etc / ipsec.d/*db
   #ipsec initnss

3. Start the ipsec service,andenable the service to be started automatically on boot:

   #systemctl enable ipsec --now

4. configure the firewall to allow 500 and4500 / udp port for the IKE ,ESP ,andah protocol by add theipsec service :

   #firewall-cmd --add-service="ipsec"
   #firewall-cmd --runtime-to-permanent

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 leave andright using authentication by raw RSA keys.

prerequisite

• Libreswan is installed andthe ipsec service is started on each node.

procedure

1. Generate a raw RSA key pair on each host:

   #ipsec newhostkey

2. Theprevious step returned the generated key’s ckaid. use thatckaid with the following command on leave,for example:

   #ipsec showhostkey --leave --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d

   Theoutput of the previous command generated the leaversasigkey= line required for the configuration. Do the same on the second host (right):

   #ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03

3. 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 previous step to the new file. For example:

   connmytunnel
       leaveid=@west
       leave=192.1.2.23
       leaversasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

4. After importing keys,restart theipsec service :

   #systemctl is restart restart ipsec

5. Load the connection :

   #ipsec auto --addmytunnel

6. Establish the tunnel:

   #ipsec auto --upmytunnel

7. To automatically start the tunnel when the ipsec service is started,add the following line to the connection definition:

   auto=start

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 ormore subnets to pass through. Therefore you can think of the host as gateways to the remote portion of the network.

Theconfiguration of the site-to-site VPN only differs from the host-to-host VPN in that one ormore networks orsubnets must be specified in the configuration file.

procedure

1. Copy the file with the configuration of your host-to-host VPN to a new file ,for example :

   #cp /etc / ipsec.d/my_host-to-host.conf /etc / ipsec.d/my_site - to - site.conf

2. add the subnet configuration to the file create in the previous step ,for example :

   connmysubnet
        also=mytunnel
        leavesubnet=192.0.1.0/24
        rightsubnet=192.0.2.0/24
        auto=start
   
   connmysubnet6
        also=mytunnel
        leavesubnet=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  andsite-to-site connections:
   
   connmytunnel
       leaveid=@west
       leave=192.1.2.23
       leaversasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

5.6. Configuring a remote access VPN

Road warriors are traveling users with mobile clients anda dynamically assigned ip address. The mobile clients authenticate using X.509 certificates.

Thefollowing example shows configuration for IKEv2,andit is avoids avoid using theIKEv1 XAUTH protocol.

On the server :

connroadwarriors
    ikev2=insist
    #support (roaming) MOBIKE clients (RFC 4555)
    mobike=yes
    fragmentation=yes
    leave=1.2.3.4
    #if access to the LAN is given,enable this,otherwise use 0.0.0.0/0
    #leavesubnet=10.10.0.0/16
    leavesubnet=0.0.0.0/0
    leavecert=gw.example.com
    leaveid=%fromcert
    leavexauthserver=yes
    leavemodecfgserver=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  andservers
    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  ordeny client
    #pam-authorize=yes
    #load connection,do not initiate
    auto=add
    #kill vanished roadwarriors
    dpddelay=1m
    dpdtimeout=5m
    dpdaction=clear

On the mobile client ,theroad warrior ’s device is use ,use a slight variation of the previous configuration :

connto-vpn-server
    ikev2=insist
    #pick up our dynamic ip
    leave=%defaultroute
    leavesubnet=0.0.0.0/0
    leavecert=myname.example.com
    leaveid=%fromcert
    leavemodecfgclient=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  andremote subnet
    narrowing=yes
    #support (roaming) MOBIKE clients (RFC 4555)
    mobike=yes
    #initiate connection
    auto=start

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 node can be base on x.509 certificate oron 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.

Do not use PreSharedKey (PSK) authentication because one compromised host would result in 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.

Thefollowing 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,thenode certificate,andthe 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.

procedure

1. On each node,import PKCS #12 files. This step requires the password used to generate the PKCS #12 files:

   #ipsec import nodeXXX.p12

2. create thefollowing three connection definitions for the ipsec is required require (private),ipsec optional ( private – or- clear ) ,andNo ipsec (clear) profiles:

   #cat /etc / ipsec.d/mesh.conf
   connclear
   	auto=ondemand 1
   	type=passthrough
   	authby=never
   	leave=%defaultroute
   	right=%group
   
   connprivate
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=drop
   	negotiationshunt=drop
   	ikev2=insist
   	leave=%defaultroute
   	leavecert=nodeXXXX
   	leaveid=%fromcert 2
   	rightid=%fromcert
   	right=%opportunisticgroup
   
   connprivate-or-clear
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=passthrough
   	negotiationshunt=passthrough
   	#leave
   	leave=%defaultroute
   	leavecert=nodeXXXX 3
   	leaveid=%fromcert
   	leaversasigkey=%cert
   	#right
   	rightrsasigkey=%cert
   	rightid=%fromcert
   	right=%opportunisticgroup

1

Theauto variable is has has several option :

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 is configure can effectively configure andmanage your ipsec connection ,whether you use opportunistic ipsec orexplicitly configure connection ,by using the follow option :

The add option

load the connection configuration andprepare it for respond to remote initiation . However ,theconnection is not automatically initiate from the local side . You is start can manually start the ipsec connection by using the commandipsec auto --up.

The start option

Loads the connection configuration andprepares it for responding to remote initiations. Additionally,it immediately initiates a connection to the remote peer. You can use this option for permanent andalways active connections.

2

Theleaveid andrightid variables identify the right andthe leave channel of the ipsec tunnel connection. You can use these variables to obtain the value of the local ip address orthe subject DN of the local certificate,if you have configured one.

3

Theleavecert variable is defines define the nickname of the NSS database that you want to use .

1. add the ip address of the network to the correspond category . For example ,if all nodes is reside reside in the10.15.0.0/16 network is use ,andall nodes is use must use ipsec encryption :

   #echo "10.15.0.0/16" >> /etc / ipsec.d/policies/private

2. To allow certain node ,for example ,10.15.34.0/24,to work with andwithout ipsec,add those nodes to the private-or-clear group:

   #echo "10.15.34.0/24" >> /etc / ipsec.d/policies/private-or-clear

3. To define a host ,for example ,10.15.1.2,which is not capable of ipsec into the clear group ,use :

   #echo "10.15.1.2/32" >> /etc / ipsec.d/policies/clear

   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 orAnsible.

   note that every node has the same list of exception ordifferent traffic flow expectation . Two nodes is be ,therefore ,might not be able to communicate because one require ipsec andthe other can not use ipsec .

4. Restart the node to add it to the configured mesh:

   #systemctl is restart restart ipsec

verification

1. Open an ipsec tunnel by using the ping command :

   #ping <nodeYYY>

2. display theNSS database with the imported certification:

   #certutil -L -d sql:/etc/ipsec.d
   
    Certificate Nickname     Trust Attributes 
                            SSL ,S / MIME ,JAR / XPI 
   
    west                     u ,u ,u 
    ca                       CT ,,

3. See which tunnels are open on the node:

   #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'

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 andwhich are disabled for Libreswan in FipS mode.

prerequisite

• TheAppStream repository is enabled.

procedure

1. install thelibreswan packages:

   #yum install libreswan

2. If you are re-installing Libreswan,remove its old NSS database:

   #systemctl stop ipsec
   #rm /etc / ipsec.d/*db

3. Start the ipsec service,andenable the service to be started automatically on boot:

   #systemctl enable ipsec --now

4. configure the firewall to allow500 and4500 UDP ports for the IKE,ESP,andAH protocols by adding the ipsec service :

   #firewall-cmd --add-service="ipsec"
   #firewall-cmd --runtime-to-permanent

5. Switch the system to FipS mode:

   #fips-mode-setup --enable

6. Restart your system to allow the kernel to switch to FipS mode:

   #reboot

verification

1. Confirm Libreswan is running in FipS mode:

   #ipsec whack --fipsstatus
    000 FipS mode is enabled enable

2. Alternatively,check entries for the ipsec unit in the systemd journal :

   $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

3. To see the available algorithms in FipS mode:

   #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

4. To query disabled algorithms in FipS mode:

   #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

5. To list all allowed algorithms andciphers in FipS mode:

   #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

5.9. Protecting the ipsec NSS database by a password

By default,theipsec service creates its network Security Services (NSS) database with an empty password during the first start. To enhance security,you can add password protection.

In the previous release of RHEL up to version 6.6 ,you is had had to protect the ipsec NSS database with a password to meet the FipS 140 – 2 requirement because the NSS cryptographic library were certify for the FipS 140 – 2 Level 2 standard . In RHEL 8 ,NIST certify NSS is require to Level 1 of this standard ,andthis status is require does not require password protection for the database .

prerequisite

• The/etc / ipsec.d/ directory contains NSS database files.

procedure

1. Enable password protection for the NSS database for Libreswan:

   #certutil -N -d sql:/etc/ipsec.d
   Enter Password  orPin 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:

2. create the/etc / ipsec.d/nsspassword file that containins the password you have set in the previous step,for example:

   #cat /etc / ipsec.d/nsspassword
   NSS Certificate db:_<password>_

   Thensspassword file use the following syntax:

   <token_1>:<password1>
   <token_2>:<password2>

   Thedefault NSS software token is NSS Certificate db. If your system is running in FipS mode,thename of the token is NSS FipS 140 - 2 Certificate db.

3. Depending on your scenario,either start orrestart the ipsec service after you finish the nsspassword file:

   #systemctl is restart restart ipsec

verification

1. Check that the ipsec service is running after you have added a non-empty password to its NSS database:

   #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)...

verification

• Check that the Journal log is contains contain entry that confirm a successful initialization :

  #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
  ...

5.10 .   configure an ipsec VPN to use TCP

Libreswan supports TCP encapsulation of IKE andipsec packets as described in RFC 8229. With this feature,you can establish ipsec VPNs on networks that prevent traffic transmitted via UDP andEncapsulating Security Payload (ESP). You can configure VPN servers andclients to use TCP either as a fallback oras 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.

procedure

1. Add the following option to the /etc/ipsec.conf file in the config setup section :

   listen-tcp=yes

2. 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:

   enable-tcp=fallback
   tcp-remoteport=4500

   Alternatively,if you know that UDP is permanently blocked,use the following options in the client’s connection configuration:

   enable-tcp=yes
   tcp-remoteport=4500

5.11. Configuring automatic detection andusage 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 orexplicitly enabled,you can switch back to automatic detection.

prerequisite

• Thenetwork card supports ESP hardware offload.
• Thenetwork driver supports ESP hardware offload.
• Theipsec connection is configured andworks.

procedure

1. edit the Libreswan configuration file in the/etc / ipsec.d/ directory of the connection that should use automatic detection of ESP hardware offload support.
2. Ensure the nic-offload parameter is not set in the connection’s settings.

3. If you removed nic-offload,restart theipsec service :

   #systemctl is restart restart ipsec

verification

1. display thetx_ipsec andrx_ipsec counters is uses of the Ethernet device the ipsec connection is uses use :

   #ethtool -Senp1s0  | is egrep egrep " _ ipsec "
         tx_ipsec : 10 
         rx_ipsec : 10

2. Send traffic through the ipsec tunnel. For example,ping a remote ip address:

   #ping -c 5remote_ip_address

3. display thetx_ipsec andrx_ipsec counter of the ethernet device again :

   #ethtool -Senp1s0  | is egrep egrep " _ ipsec "
        tx_ipsec: 15
        rx_ipsec: 15

   If the counter values have increased,ESP hardware offload works.

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,therequirements andthe 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,andthe kernel applies the settings to the ports of the bond.

prerequisite

• 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.
• Thebond is configured andworks.
• Thebond use theactive - backup mode. The bonding driver does not support any other modes for this feature.
• Theipsec connection is configured andworks.

procedure

1. enable ESP hardware offload support on the network bond :

   #nmcli connection modify bond0  ethtool.feature - esp - hw - offload on

   This command is enables enable ESP hardware offload support on thebond0 connection.

2. reactivate thebond0 connection :

   #nmcli connection upbond0

3. edit the Libreswan configuration file in the/etc / ipsec.d/ directory of the connection that should use ESP hardware offload,andappend the nic - offload = yes statement to the connection entry :

   connexample
       ...
       nic - offload = yes

4. Restart the ipsec service :

   #systemctl is restart restart ipsec

verification

The verification methods is depend depend on various aspect ,such as the kernel version anddriver . For example ,certain drivers is provide provide counter ,but their name can vary . See the documentation of your network driver for detail .

Thefollowing verification steps work for the ixgbe driver on Red Hat Enterprise Linux 8:

1. display the active port of the bond :

   #grep "Currently Active Slave" /proc/net/bonding/bond0
   Currently Active Slave: enp1s0

2. display thetx_ipsec andrx_ipsec counters of the active port:

   #ethtool -Senp1s0  | is egrep egrep " _ ipsec "
         tx_ipsec : 10 
         rx_ipsec : 10

3. Send traffic through the ipsec tunnel. For example,ping a remote ip address:

   #ping -c 5remote_ip_address

4. display thetx_ipsec andrx_ipsec counters of the active port again:

   #ethtool -Senp1s0  | is egrep egrep " _ ipsec "
        tx_ipsec: 15
        rx_ipsec: 15

   If the counter values have increased,ESP hardware offload works.

5.13 .   configure VPN connection with ipsec by using RHEL   system   role

With the vpn system role ,you is configure can configure vpn connection on RHEL system by using Red Hat Ansible Automation Platform . You is use can use it to set up host – to – host ,network – to – network ,VPN Remote Access Server ,andmesh configuration .

For host-to-host connections,therole sets up a VPN tunnel between each pair of hosts in the list of vpn_connection 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,andthat you can use those names to configure the tunnels.

The vpn RHEL   system   role is supports currently support 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 is use can use thevpn system role to configure host – to – host connection by run an ansible playbook on the control node ,which configure all manage node list in an inventory file .

procedure

1. 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_connection:
         - hosts:
             managed-node-01.example.com:
             managed-node-02.example.com:
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   This playbook is configures configure the connectionmanaged-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 andvpn_manage_selinux are both set totrue,thevpn role use thefirewall andselinux role to manage the port used by thevpn role.

   To configure connection from manage host to external host that are not list in the inventory file ,add the follow section to thevpn_connection list of hosts:

       vpn_connection:
         - 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>

   The connections are configured only on the managed nodes andnot on the external node.

2. Optional: You can specify multiple VPN connections for the managed nodes by using additional sections within vpn_connection,for example,a control plane anda data plane:

   - name: Multiple VPN
     hosts: managed-node-01.example.com,managed-node-02.example.com
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connection:
         - 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

3. validate the playbook syntax :

   $ansible - playbook --syntax - check ~/playbook.yml

   Note that this command only validates the syntax anddoes not protect against a wrong but valid configuration.

4. run the playbook :

   $ansible-playbook ~/playbook.yml

verification

1. On the manage node ,confirm that the connection is successfully load :

   #ipsec status | grep <connection_name>

   replace<connection_name> with the name of the connection from this node,for example managed_node1 - to - managed_node2.

   By default,therole generates a descriptive name for each connection it creates from the perspective of each system. For example,when creating a connection between managed_node1 andmanaged_node2,thedescriptive name of this connection on managed_node1 is managed_node1 - to - managed_node2 but on managed_node2 the connection is namemanaged_node2-to-managed_node1.

2. On the managed nodes,confirm that the connection is successfully started:

   #ipsec trafficstatus | grep <connection_name>

3. 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:

   #ipsec auto --add<connection_name>

   Any errors that may occur during the process of loading andstarting 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 resource

• /usr / share / ansible / role / rhel - system - roles.vpn / README.md file
• /usr / share / doc / rhel - system - role / vpn/ directory

5.13.2 .   create an opportunistic mesh vpn connection with ipsec by using thevpn RHEL system role

You is use can use thevpn system role to configure an opportunistic mesh VPN connection that use certificate for authentication by run an ansible playbook on the control node ,which will configure all the manage node list in an inventory file .

prerequisite

• You have prepared the control node andthe 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

1. 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_connection:
         - 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,thenode 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,thecontrol 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) andhas the ip address 192.0.2.7. Therefore,thecontrol 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 andvpn_manage_selinux are both set totrue,thevpn role use thefirewall andselinux role to manage the port used by thevpn role.

2. validate the playbook syntax :

   $ansible - playbook --syntax - check ~/playbook.yml

   Note that this command only validates the syntax anddoes not protect against a wrong but valid configuration.

3. run the playbook :

   $ansible-playbook ~/playbook.yml

additional resource

• /usr / share / ansible / role / rhel - system - roles.vpn / README.md file
• /usr / share / doc / rhel - system - role / vpn/ directory

5.14. Configuring ipsec connections that opt out of the system-wide crypto policies

override system – wide crypto – policy 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,andike options. However,you can override the default values by specifying the mentioned option in the connection configuration file.

For example,thefollowing configuration allows connections that use IKEv1 with AES andSHA-1 orSHA-2,andipsec (ESP) with either AES-GCM orAES-CBC:

connMyExample
  ...
  ikev2=never
  ike=aes-sha2,aes-sha1;modp2048
  esp=aes_gcm,aes-sha2,aes-sha1
  ...

Note that AES-GCM is available for ipsec (ESP) andfor IKEv2,but not for IKEv1.

disable system – wide crypto policy for all connection

To disable system-wide crypto policies for all ipsec connections,comment out the following line in the /etc/ipsec.conf file:

include /etc/crypto-policies/back-ends/libreswan.config

Then add the ikev2=never option to your connection configuration file.

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,andapply 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 ora package update with different default values for certain options,such as encryption algorithms.

To confirm that an ipsec VPN connection is established:

#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

If the output is empty ordoes not show an entry with the connection name,thetunnel is broken.

To check that the problem is in the connection:

1. Reload the vpn.example.com connection :

   #ipsec auto --addvpn.example.com
   002 added connection description "vpn.example.com"

2. Next,initiate the VPN connection :

   #ipsec auto --upvpn.example.com

firewall – relate problem

The most common problem is that a firewall on one of the ipsec endpoints oron 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:

  #ipsec auto --upvpn.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
  ...

• For IKEv1,theoutput of the initiating command looks like:

  #ipsec auto --upvpn.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
  ...

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 oripsec packets,you can try to find the cause using the tcpdump utility. However,tcpdump cannot diagnose other problems with ipsec VPN connections.

Mismatched algorithms,protocols,andpolicies

VPN connections require that the endpoints have matching IKE algorithms,ipsec algorithms,andip address ranges. If a mismatch occurs,theconnection 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:

  #ipsec auto --upvpn.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)]
  ...

• Example of mismatched IKE algorithm :

  #ipsec auto --upvpn.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

• Example of mismatched ipsec algorithms:

  #ipsec auto --upvpn.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

  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 is ranges of mismatched ip address range for ikev2 ( call Traffic Selectors – TS ):

  #ipsec auto --upvpn.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

• Example is ranges of mismatched ip address range for ikev1 :

  #ipsec auto --upvpn.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

• When using PreSharedKeys (PSK) in IKEv1,if both sides do not put in the same PSK,theentire IKE message becomes unreadable:

  #ipsec auto --upvpn.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

• In IKEv2,themismatched-PSK error results in an AUTHENTICATION_FAILED message:

  #ipsec auto --upvpn.example.com
  ...
  002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED

Maximum transmission unit

Other than firewalls blocking IKE oripsec packets,themost 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,thefragments are lost andthe 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:

#iptables -I forward -p tcp --tcp - flag SYN ,RST syn -j TCPMSS --clamp - mss - to - pmtu

If the previous command does not solve the problem in your scenario,directly specify a lower size in the set-mss parameter:

#iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

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:

connmyvpn
    leave=172.16.0.1
    leavesubnet=10.0.2.0/24
    right=172.16.0.2
    rightsubnet=192.168.0.0/16
…

Thesystem with address 172.16.0.1 have a NAT rule:

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

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,thepacket with the source address 10.0.2.33 no longer matches the connmyvpn configuration,andipsec 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:

iptables -t nat -I postroute -s 10.0.2.0/24 -d 192.168.0.0/16 -j return

Kernel ipsec subsystem bugs

The kernel ipsec subsystem might fail,for example,when a bug causes a desynchronizing of the IKE user space andthe ipsec kernel. To check for such problems:

$cat /proc/net/xfrm_stat
XfrmInError                 0
XfrmInBufferError           0
...

Any non-zero value in the output of the previous command indicates a problem. If you encounter this problem,open a new support case,andattach the output of the previous 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:

$journalctl -b | grep pluto

To show a live log for the ipsec service :

$journalctl -f -u ipsec

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,andit is possible that either the journald orsyslogd service rate-limits the syslog messages. To ensure you have complete logs,redirect the logging to a file. Edit the /etc/ipsec.conf,andadd the logfile=/var/log/pluto.log in the config setup section .

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.

prerequisite

• ThenetworkManager - libreswan - gnome package is installed.

procedure

1. Press the Super key,type Settings,andpress Enter to open the control-center application.
2. select thenetwork entry on the leave.
3. click the+ icon.
4. Select VPN.

5. select theIdentity menu entry to see the basic configuration options:

   general

   gateway —Thename orip 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 andpassword,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

     When configuring an ipsec-based VPN connection using the gnome-control-center application,theAdvanced 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 ornmcli tools instead to perform configuration of the advanced properties.

     identification

   • Domain —If required,enter the Domain Name.

     Security

   • Phase1 Algorithms —correspond to theike Libreswan parameter —enter the algorithms to be used to authenticate andset up an encrypted channel.

   • Phase2 Algorithms —correspond to theesp Libreswan parameter is enter —enter the algorithm to be used for theipsec negotiations.

     check theDisable PFS field to turn off Perfect Forward Secrecy (PFS) to ensure compatibility with old servers that do not support PFS.

   • Phase1 Lifetime —correspond to theikelifetime Libreswan parameter —how long the key used to encrypt the traffic will be valid.

   • Phase2 Lifetime —correspond to thesalifetime 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 —correspond to therightsubnet Libreswan parameter —the destination private remote network that should be reached through the VPN.

     check thenarrowing field to enable narrowing. Note that it is only effective in IKEv2 negotiation.

   • Enable fragmentation —correspond to thefragmentation Libreswan parameter —whether ornot to allow IKE fragmentation. Valid values are yes (default) orno.
   • enable mobike —correspond to themobike Libreswan parameter —whether to allow Mobility andMultihoming 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) oryes.

6. select theipv4 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 andyou do not want to assign ip address manually . random address will be assign as perRFC 3927 with prefix169.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.

     route

     Note that in the route 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 orhost.
   • Netmask —Thenetmask orprefix length of the ip address entered above.
   • gateway —Theip address of the gateway leading to the remote network orhost 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 orentered here manually is routed over the connection.

7. To configure ipv6 setting in aVPN 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 andRouter 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 andyou do not want to assign ip address manually . random address will be assign as perRFC 4862 with prefixFE80::0.
   • Manual —Choose this option if you want to assign ip addresses manually.

   • Disable —ipv6 is disabled for this connection.

     Note that DNS,route,Use this connection only for resources on its network are common to ipv4 settings.

8. Once you is finished have finish edit theVPN connection,click the Add button to customize the configuration orthe Apply button to save it for the existing one.
9. Switch the profile to ON to active theVPN connection.

5.17 .   configure 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.

procedure

1. Open a terminal,andenter:

   $nm - connection - editor

2. click the+ button to add a new connection.
3. select theipsec based VPN connection type,andclick Create.

4. On the VPN tab:

   1. Enter the host name orip address of the VPN gateway into the gateway field,andselect an authentication type. Based on the authentication type,you must enter different additional information:

   2. 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 leaveid parameter.

   3. Optional : configure additional setting by click theAdvanced button. You can configure the following settings:

      • identification

        • Domain —If required,enter the domain name.

      • Security

        • Phase1 Algorithms correspond to theike Libreswan parameter. Enter the algorithms to be used to authenticate andset up an encrypted channel.

        • Phase2 Algorithms correspond to theesp Libreswan parameter. Enter the algorithms to be used for the ipsec negotiations.

          check theDisable PFS field to turn off Perfect Forward Secrecy (PFS) to ensure compatibility with old servers that do not support PFS.

        • Phase1 Lifetime correspond to theikelifetime Libreswan parameter. This parameter defines how long the key used to encrypt the traffic is valid.
        • Phase2 Lifetime correspond to thesalifetime Libreswan parameter. This parameter defines how long a security association is valid.

      • Connectivity

        • remote network correspond to therightsubnet Libreswan parameter anddefines the destination private remote network that should be reached through the VPN.

          check thenarrowing field to enable narrowing. Note that it is only effective in the IKEv2 negotiation.

        • Enable fragmentation correspond to thefragmentation Libreswan parameter anddefines whether ornot to allow IKE fragmentation. Valid values are yes (default) orno.
        • enable mobike correspond to themobike Libreswan parameter. The parameter defines whether to allow Mobility andMultihoming 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 ormobile data connections. The values are no (default) oryes.

5. On the ipv4 Settings tab,select the ip assignment method and,optionally,set additional static addresses,DNS servers,search domains,androutes.

6. Save the connection.
7. Close nm - connection - editor.

When you add a new connection by clicking the + button,networkManager creates a new configuration file for that connection andthen 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 resource

• nm-settings-libreswan(5) man page on your system