Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

6.13. Configuring IPsec VPN connections by using nmstatectl

Configure IPsec VPN connections to establish encrypted tunnels over untrusted networks and ensure the integrity of data in transit. By using Nmstate, you can create IPsec VPN connections by using a declarative API.

You can use the nmstatectl utility to configure Libreswan IPsec VPN connections through the Nmstate API. The nmstatectl utility is a command-line tool to manage host networking through the declarative Nmstate API. Instead of running multiple imperative commands to configure an interface, you define the expected state in a YAML file. Nmstate then takes this definition and applies it to the system. A key advantage of this approach is an atomic result. Nmstate ensures that the resulting configuration precisely matches your YAML definition. If any part of the configuration fails to apply, it automatically rolls back all changes and prevents the system from entering an incorrect or broken network state.

참고

Due to the design of the NetworkManager-libreswan plugin, you can use nmstatectl only on one peer and must manually configure Libreswan on the other peer.

You can use the declarative Nmstate API to configure a host-to-host VPN between two devices to communicate safely over an insecure network. Nmstate ensures that the result matches the configuration file or rolls back the changes.

For authentication, RSA keys are more secure than pre-shared keys (PSKs) because their asymmetric encryption eliminates the risk of a shared secret. Using RSA keys also simplifies deployment by avoiding the need for a certificate authority (CA), while still providing strong peer-to-peer authentication.

참고

In general, the choice of which host is named left and right is arbitrary. However, NetworkManager always uses the term left for the local host and right for the remote host.

Prerequisites

  • The remote peer runs Libreswan IPsec and is prepared for a host-to-host connection.

    Due to the design of the NetworkManager-libreswan plugin, Nmstate cannot communicate with other peers that also use this plugin for the same connection.

Procedure

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

    1. Install the required packages: 

      # dnf install nmstate libreswan NetworkManager-libreswan

    2. Restart the NetworkManager service: 

      # systemctl restart NetworkManager

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

      # ipsec initnss

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

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

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

  2. Create an RSA key pair: 

    # ipsec newhostkey

    The ipsec utility stores the key pair in the NSS database.

  3. Display the Certificate Key Attribute ID (CKAID) on both the left and right peers: 

    # ipsec showhostkey --list
< 1> RSA keyid: <key_id> ckaid: <ckaid>

    You require the CKAIDs of both peers in the next steps.

  4. Display the public keys:

    1. On the left peer, enter: 

      # ipsec showhostkey --left --ckaid <ckaid_of_left_peer>
        # rsakey AwEAAdKCx
        leftrsasigkey=0sAwEAAdKCxpc9db48cehzQiQD...

    2. On the right peer, enter: 

      # ipsec showhostkey --right --ckaid <ckaid_of_right_peer>
        # rsakey AwEAAcNWC
        rightrsasigkey=0sAwEAAcNWCzZO+PR1j8WbO8X...

    The commands display the public keys with the corresponding parameters that you must use in the configuration file.

  5. Create a YAML file, for example ~/ipsec-host-to-host-rsa-auth.yml, with the following content: 

    ---
interfaces:
- name: '<connection_name>'
  type: ipsec
  libreswan:
    ikev2: insist

    left: <ip_address_or_fqdn_of_left_peer>
    leftid: peer_b
    leftrsasigkey: <public_key_of_left_peer>
    leftmodecfgclient: false

    right: <ip_address_or_fqdn_of_right_peer>
    rightid: peer_a
    rightrsasigkey: <public_key_of_right_peer>
    rightsubnet: <ip_address_of_right_peer>/32

    The settings specified in the example include the following:

    ikev2: insist
    Defines the modern IKEv2 protocol as the only allowed protocol without fallback to IKEv1. This setting is mandatory in a host-to-host configuration with Nmstate.
    left=<ip_address_or_fqdn_of_left_peer> and right=<ip_address_or_fqdn_of_right_peer>
    Defines the IP address or DNS name of the peers.
    leftid=<id> and rightid=<id>
    Defines how each peer is identified during the Internet Key Exchange (IKE) negotiation process. This can be an IP address or a literal string. Note that NetworkManager interprets all values other than IP addresses as a literal string and internally adds a leading @ sign. This requires that the Libreswan peer also uses literal strings as IDs or authentication fails.
    leftrsasigkey=<public_key> and rightrsasigkey=<public_key>
    Specifies the public key of the peers. Use the values displayed by the ipsec showhostkey command in a previous step.
    leftmodecfgclient: false
    Disables dynamic configuration on this host. This setting is mandatory in a host-to-host configuration with Nmstate.
    rightsubnet: <ip_address_of_right_peer>/32
    Defines that the host can only access this peer. This setting is mandatory in a host-to-host configuration with Nmstate.

  6. Apply the settings to the system: 

    # nmstatectl apply ~/ipsec-host-to-host-rsa-auth.yml

Verification

  • Display the IPsec status: 

    # ipsec status

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

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

      000 #1: "<connection_name>":500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 27935s; REPLACE in 28610s; 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: 

      000 #2: "<connection_name>":500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 27671s; REPLACE in 28610s; IKE SA #1; idle;

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

Troubleshooting

  • To display the actual configuration NetworkManager passes to Libreswan, enter: 

    # nmcli connection export <connection_name>

    The output can help to identify deviating settings, such as IDs and keys, when you compare them with the Libreswan configuration on the remote host.

Next steps

You can use the declarative Nmstate API to configure a site-to-site VPN between two distinct networks, seamlessly linking them across an insecure network. Nmstate ensures that the result matches the configuration file or rolls back the changes.

For authenticating the gateway devices, RSA keys are more secure than pre-shared keys (PSKs) because their asymmetric encryption eliminates the risk of a shared secret. Using RSA keys also simplifies deployment by avoiding the need for a certificate authority (CA), while still providing strong peer-to-peer authentication.

참고

In general, the choice which host is named left and right is arbitrary. However, NetworkManager always uses the term left for the local host and right for the remote host.

Prerequisites

  • The remote gateway runs Libreswan IPsec and is prepared for a site-to-site connection.

    Due to the design of the NetworkManager-libreswan plugin, Nmstate cannot communicate with other peers that also use this plugin for the same connection.

Procedure

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

    1. Install the required packages: 

      # dnf install nmstate libreswan NetworkManager-libreswan

    2. Restart the NetworkManager service: 

      # systemctl restart NetworkManager

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

      # ipsec initnss

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

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

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

  2. Create an RSA key pair: 

    # ipsec newhostkey

    The ipsec utility stores the key pair in the NSS database.

  3. Display the Certificate Key Attribute ID (CKAID) on both the left and right peer: 

    # ipsec showhostkey --list
< 1> RSA keyid: <key_id> ckaid: <ckaid>

    You require the CKAIDs of both peers in the following steps.

  4. Display the public keys:

    1. On the left peer, enter: 

      # ipsec showhostkey --left --ckaid <ckaid_of_left_peer>
        # rsakey AwEAAdKCx
        leftrsasigkey=0sAwEAAdKCxpc9db48cehzQiQD...

    2. On the right peer, enter: 

      # ipsec showhostkey --right --ckaid <ckaid_of_right_peer>
        # rsakey AwEAAcNWC
        rightrsasigkey=0sAwEAAcNWCzZO+PR1j8WbO8X...

    The commands display the public keys with the corresponding parameters that you must use in the configuration file.

  5. Create a YAML file, for example ~/ipsec-site-to-site-rsa-auth.yml, with the following content: 

    ---
interfaces:
- name: '<connection_name>'
  type: ipsec
  libreswan:
    ikev2: insist

    left: <ip_address_or_fqdn_of_left_peer>
    leftid: peer_b
    leftrsasigkey: <public_key_of_left_peer>
    leftmodecfgclient: false
    leftsubnet: 198.51.100.0/24

    right: <ip_address_or_fqdn_of_right_peer>
    rightid: peer_a
    rightrsasigkey: <public_key_of_right_peer>
    rightsubnet: 192.0.2.0/24

    The settings specified in the example include the following:

    ikev2: insist
    Defines the modern IKEv2 protocol as the only allowed protocol without fallback to IKEv1. This setting is mandatory in a site-to-site configuration with Nmstate.
    left=<ip_address_or_fqdn_of_left_peer> and right=<ip_address_or_fqdn_of_right_peer>
    Defines the IP address or DNS name of the peers.
    leftid=<id> and rightid=<id>
    Defines how each peer is identified during the Internet Key Exchange (IKE) negotiation process. This can be an IP address or a literal string. Note that NetworkManager interprets all values other than IP addresses as a literal string and internally adds a leading @ sign. This requires that the Libreswan peer also uses literal strings as IDs or authentication fails.
    leftrsasigkey=<public_key> and rightrsasigkey=<public_key>
    Specifies the public key of the peers. Use the values displayed by the ipsec showhostkey command in a previous step.
    leftmodecfgclient: false
    Disables dynamic configuration on this host. This setting is mandatory in a site-to-site configuration with Nmstate.
    leftsubnet=<subnet> and rightsubnet=<subnet>
    Defines subnets in classless inter-domain routing (CIDR) format that are connected through the tunnel.

  6. Enable packet forwarding: 

    # echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/95-IPv4-forwarding.conf
# sysctl -p /etc/sysctl.d/95-IPv4-forwarding.conf

  7. Apply the settings to the system: 

    # nmstatectl apply ~/ipsec-site-to-site-rsa-auth.yml

Verification

  1. Display the IPsec status: 

    # ipsec status

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

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

      000 #1: "<connection_name>":500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 27935s; REPLACE in 28610s; 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: 

      000 #2: "<connection_name>":500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 27671s; REPLACE in 28610s; IKE SA #1; idle;

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

  2. From a client in the local subnet, ping a client in the remote subnet.

Troubleshooting

  • To display the actual configuration NetworkManager passes to Libreswan, enter: 

    # nmcli connection export <connection_name>

    The output can help to identify deviating settings, such as IDs and keys, when you compare them with the Libreswan configuration on the remote host.

Next steps

6.13.3. Configuring a client to connect to an IPsec VPN gateway by using nmstatectl
링크 복사

To access resources on a remote private network, users must first configure an IPsec VPN connection. By using Nmstate, you can create the connection with an existing Libreswan IPsec gateway by using a declarative API.

참고

In general, the choice of which host is named left and right is arbitrary. However, NetworkManager always uses the term left for the local host and right for the remote host.

Prerequisites

  • The remote gateway runs Libreswan IPsec and is prepared for a host-to-site connection with certificate-based authentication.

    Due to the design of the NetworkManager-libreswan plugin, Nmstate cannot communicate with other peers that also use this plugin for the same connection.

  • The PKCS#12 file ~/file.p12 exists on the client with the following contents:

    • The private key of the user
    • The user certificate
    • The CA certificate
    • If required, intermediate certificates

    For details about creating a private key and certificate signing request (CSR), as well as about requesting a certificate from a CA, see your CA’s documentation.

  • The Extended Key Usage (EKU) in the certificate is set to TLS Web Client Authentication.

Procedure

  1. If Libreswan is not yet installed:

    1. Install the required packages: 

      # dnf install nmstate libreswan NetworkManager-libreswan

    2. Restart the NetworkManager service: 

      # systemctl restart NetworkManager

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

      # ipsec initnss

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

    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 user and CA certificates: 

    # certutil -L -d /var/lib/ipsec/nss/
Certificate Nickname     Trust Attributes
                         SSL,S/MIME,JAR/XPI

user                     u,u,u
Example-CA               CT,,
...

    You require this information in the Nmstate YAML file.

  4. Create a YAML file, for example, ~/ipsec-host-to-site-cert-auth.yml, with the following content: 

    ---
interfaces:
- name: '<connection_name>'
  type: ipsec
  libreswan:
    ikev2: insist

    left: <ip_address_or_fqdn_of_left_peer>
    leftid: '%fromcert'
    leftcert: <user_certificate_nickname>

    right: <ip_address_or_fqdn_of_right_peer>
    rightid: '%fromcert'
    rightsubnet: 192.0.2.0/24

    The settings specified in the example include the following:

    ikev2: insist
    Defines the modern IKEv2 protocol as the only allowed protocol without fallback to IKEv1. This setting is mandatory in a host-to-site configuration with Nmstate.
    left=<ip_address_or_fqdn_of_left_peer> and right=<ip_address_or_fqdn_of_right_peer>
    Defines the IP address or DNS name of the peers.
    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.
    rightsubnet: <subnet>
    Defines the subnet in classless inter-domain routing (CIDR) format that is connected to the gateway.

  5. Apply the settings to the system: 

    # nmstatectl apply ~/ipsec-host-to-site-cert-auth.yml

Verification

  • Establish a connection to a host in the remote network or ping it.

Troubleshooting

  • To display the actual configuration NetworkManager passes to Libreswan, enter: 

    # nmcli connection export <connection_name>

    The output can help to identify deviating settings, such as IDs and keys, when you compare them with the Libreswan configuration on the remote host.

Next steps

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat맨 위로 이동