===== IPsec ===== .. sidebar:: Contents .. contents:: :depth: 2 :local: IPsec is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication. It can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host). IPsec relies on different protocols to perform various functions: * **Authentication Header (AH)**: provides connectionless data integrity and data origin authentication for IP datagrams. * **Encapsulating Security Payload (ESP)**: provides confidentiality, connectionless data integrity, data origin authentication and traffic-flow confidentiality. * **Internet Key Exchange (IKE and IKEv2)**: its purpose is to generate the security associations (SA) with the bundle of algorithms and parameters necessary for AH and/or ESP operations. OSDx supports both transport and tunnel modes, IKE and IKEv2, many encryption and hashing algorithms and multiple ways to perform authentication. Configuration ============= IPsec can be configured with the following command :osdx:cfg:`vpn ipsec`. There are two different ways to setup VPN IPsec tunnels: * Using :doc:`Site-to-Site ` configuration. * Using Dynamic Multipoint VPN (DMVP) configuration. DMVPN and Site-to-Site instances need three different configuration profiles or groups: * **IKE profile** (or :osdx:cfg:`vpn ipsec ike-group *`). * **Authentication profile** (or :osdx:cfg:`vpn ipsec auth-profile *`). * **Encapsulating profile** (or :osdx:cfg:`vpn ipsec esp-group *`). .. raw:: html
----------- IKE profile ----------- As previously mentioned, IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for ESP, AH and a set of cryptographic algorithms to be used by the SAs to protect the traffic. In OSDx, IKE attributes are specified through ``ike-groups`` and multiple proposals can be specified in a single group. IKE version can be configured with the command :osdx:cfg:`vpn ipsec ike-group * key-exchange *`. If not specified, ``ikev1`` is used by default. The ``dead-peer-detection`` (DPD) mechanism can be enabled and customized with the command :osdx:cfg:`vpn ipsec ike-group * dead-peer-detection`. This allows the device to send periodic notification messages ir order to check the liveliness of the IPsec connection. **Configuration examples:** .. note:: Example using IKEv2, DPD enabled with a 1-minute interval and lifetime of 1 day. A single proposal was defined and it uses ``aes256gcm128`` for encryption, ``sha256`` for hashing and Diffie-Hellman group 19 (``ecp256``). .. code-block:: none set vpn ipsec ike-group IKE_SPOKE dead-peer-detection interval 60 set vpn ipsec ike-group IKE_SPOKE key-exchange ikev2 set vpn ipsec ike-group IKE_SPOKE lifetime 86400 set vpn ipsec ike-group IKE_SPOKE proposal 1 dh-group 19 set vpn ipsec ike-group IKE_SPOKE proposal 1 encryption aes256gcm128 set vpn ipsec ike-group IKE_SPOKE proposal 1 hash sha256 .. dropdown:: Click here to see the available configuration commands: .. osdx:cmdtree:: cfg :maxdepth: 3 vpn ipsec ike-group ---------------------- Authentication profile ---------------------- In order to configure an authentication profile, both network sides (i.e., ``remote`` and ``local``) can be specified. If the parameters are the same, the command :osdx:cfg:`vpn ipsec auth-profile * mirror-config *` can be used. Currently, OSDx supports the following authentication mechanisms: * Pre-Shared Key (PSK). * Certificate-based authentication (X.509). * Extensible Authentication Protocol (EAP). * Remote Authentication Dial-In User Service (RADIUS). **Configuration examples:** .. note:: Example using IKE IDs and Pre-Shared Key: .. code-block:: none set vpn ipsec auth-profile PSK_AUTH local auth pre-shared-secret mypassword set vpn ipsec auth-profile PSK_AUTH local id branch_office set vpn ipsec auth-profile PSK_AUTH remote id data_center .. note:: Example using SCEP to automatically retrieve X.509 credentials: .. code-block:: none set vpn ipsec auth-profile SCEP_AUTH mode x509 set vpn ipsec auth-profile SCEP_AUTH x509 csr SCEP_CSR .. dropdown:: Click here to see the available configuration commands: .. osdx:cmdtree:: cfg :maxdepth: 3 vpn ipsec auth-profile --------------------- Encapsulating profile --------------------- Finally, the ``esp-group`` must be defined in order to allow the encryption of IP packets on the network layer. Two modes are supported: * **Tunnel mode**: the complete IP packet is encapsulated by ESP and an outer IP header is prepended. If not specified, this mode is used by default. * **Transport mode**: original IP header is retained and just the Layer 4 payload carried by the IP packet is encrypted. The ESP header is inserted between the original IP header and the encrypted payload. On the one hand, tunnel mode is most commonly used for configurations that need a secure connection between two different networks, separated by an intermediate untrusted network. On the other hand, transport mode is commonly used when fast and secure end-to-end communications are required, such as client-server communications. In OSDx, the mode can be configured with the command :osdx:cfg:`vpn ipsec esp-group * mode *`. **Configuration examples:** .. note:: Example using transport mode, a child lifetime of 12 hours and disabled IPsec replay protection. A single proposal was defined and it uses ``aes256gcm128`` for encryption and Diffie-Hellman group 19 (``ecp256``). .. code-block:: none set vpn ipsec esp-group ESP_SPOKE lifetime 43200 set vpn ipsec esp-group ESP_SPOKE mode transport set vpn ipsec esp-group ESP_SPOKE replay-window 0 set vpn ipsec esp-group ESP_SPOKE proposal 1 encryption aes256gcm128 set vpn ipsec esp-group ESP_SPOKE proposal 1 pfs dh-group19 .. dropdown:: Click here to see the available configuration commands: .. osdx:cmdtree:: cfg :maxdepth: 3 vpn ipsec esp-group Administration ============== There are multiple operational commands available to manage, administrate and debug VPN IPsec connections. The operational command :osdx:op:`vpn ipsec show sa` can be used to list currently active SAs: .. code-block:: none vpn-peer-PEER_SA: #4, ESTABLISHED, IKEv2, 20f196be4f2a0858_i 9356cffbef06683f_r* local 'M2' @ 10.0.0.2[500] remote 'RS' @ 10.0.0.1[500] AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256 established 1s ago, rekeying in 18861s peer-PEER_SA-tunnel-1: #6, reqid 4, INSTALLED, TUNNEL, ESP:AES_GCM_16-256 installed 1s ago, rekeying in 3263s, expires in 3959s in cb6ac9cb, 0 bytes, 0 packets out caf347c3, 0 bytes, 0 packets local 192.168.100.0/24 remote 192.168.200.0/24 admin@M2$ :osdx:op:`vpn ipsec clear sa` can be used to close previously established SAs: .. code-block:: none admin@M2$ vpn ipsec clear sa Deleting IPSec SAs... 100% Closed tunnels: 1 admin@M2$ Additionally, we can manually initiate SAs by using the following command: :osdx:op:`vpn ipsec initiate peer *` .. code-block:: none admin@RS420$ vpn ipsec initiate peer PEER_SA Initiating IPSec SAs... 0% Initiated tunnels: 1 admin@RS420$ The operational command :osdx:op:`vpn ipsec show policy` can be also very useful since it displays the content of the security policy database. Additionally, it is possible to enable logging information with the following configuration command: :osdx:cfg:`vpn ipsec logging`. Command summary =============== .. osdx:cmdtree:: cfg :maxdepth: 3 vpn ipsec .. osdx:cmdtree:: op vpn ipsec See also ======== You can find more information about how to configure VPN IPsec instances in the articles below: .. toctree:: :titlesonly: :glob: */index