6.4. Manually configuring an IPsec site-to-site VPN with raw RSA key authentication


A site-to-site VPN establishes a secure, encrypted tunnel between two distinct networks, seamlessly linking them across an insecure public network such as the internet.

For example, a site-to-site VPN enables devices in a branch office to access resources at a corporate headquarters just as if they were all part of the same local network.

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.

Perform the steps on both gateway devices.

Prerequisites

  • Routes in both networks ensure that the traffic to the remote networks is sent through the local VPN gateway devices.

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. Create an RSA key pair:

    # ipsec newhostkey

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

  3. Designate your peers. In an IPsec tunnel, you must designate one host as left and the other as right. This is an arbitrary choice. A common practice is to call your local host left and the remote host right.
  4. 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 next steps.

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

  6. Create a .conf file for the connection in the /etc/ipsec.d/ directory. For example, create the /etc/ipsec.d/site-to-site.conf file with the following settings:

    conn <connection_name>
        # General setup and authentication type
        auto=start
        authby=rsasig
    
        # Site A
        left=<ip_address_or_fqdn_of_left_peer>
        leftid=@site_a
        leftrsasigkey=<public_key_of_left_peer>
        leftsubnet=192.0.2.0/24
    
        # Site B
        right=<ip_address_or_fqdn_of_right_peer>
        rightid=@site_b
        rightrsasigkey=<public_key_of_right_peer>
        rightsubnet={198.51.100.0/24, 203.0.113.0/24}
    注意

    You can use the same configuration file on both gateway devices, and Libreswan identifies whether it is operating on the left or right host by using internal information. However, it is important that all values in left* parameters belong to one peer and the values in right* parameters belong to the other.

    The settings specified in the example include the following:

    conn <connection_name>
    Defines the connection name. The name is arbitrary, and Libreswan uses it to identify the connection. You must indent parameters in this connection by at least one space or tab.
    auto=<type>
    Controls how the connection is initiated. If you set the value to start, Libreswan activates the connection automatically when the service starts.
    authby=rsasig
    Enables RSA signature authentication for this connection.
    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 a fully-qualified domain name (FQDN), an IP address, or a literal string. In the latter case, precede the string with an @ sign.
    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.
    leftsubnet=<subnet> and rightsubnet=<subnet>
    Defines subnets in classless inter-domain routing (CIDR) format that are connected through the tunnel. If you want to tunnel multiple subnets on one side, specify them in curly brackets and separate them with a comma.
  7. 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
  8. Restart the ipsec service:

    # systemctl restart ipsec

    If you use auto=start in the configuration file, the connection is automatically activated. With other methods, additional steps are required to activate the connection. For details, see the ipsec.conf(5) man page on your system.

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:

      #2: "<connection_name>":500 ESTABLISHED_IKE_SA (established IKE SA); REKEY in 28523s; REPLACE in 28793s; 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:

      #3: "<connection_name>":500 ESTABLISHED_CHILD_SA (established Child SA); REKEY in 28523s; REPLACE in 28793s; newest; eroute owner; IKE SA #2; 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.

Next steps

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部