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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat
맨 위로 이동