Configuring an IKE Peer

Procedure

1. Run system-view

   The system view is displayed.

2. Run ike peer peer-name

   An IKE peer is created and the IKE peer view is displayed.

   By default, no IKE peer is created in the system.

3. Run version { 1 | 2 }

   The IKE protocol version used by IKE peers is configured.

   By default, IKE peers support IKEv1 and IKEv2.

4. (Optional) Run exchange-mode { main | aggressive | auto }

   IKEv1 phase 1 negotiation mode is set.

   By default, the main mode is used in IKEv1 phase 1.

   • Main mode: protects identities.

   • Aggressive mode: provides faster negotiation speed, but cannot protect identities.

   • Auto-sensing mode: The main mode is used if the device serves as the initiator. If the device serves as the responder, both the main mode and aggressive mode can be used.

5. (Optional) Run ike negotiate compatible

   The responder is configured to receive the IKE proposal and IPSec proposal of IKE peer.

   By default, the responder does not receive the IKE proposal and IPSec proposal of IKE peer.

   During IPSec negotiation between IKE peers, if the responder of IPSec negotiation does not learn initiator's IPSec parameters (IKEv1 negotiation mode, algorithm in the IKE proposal or security protocol, algorithm, and encapsulation mode in the IPSec proposal), perform this step to enable the responder to use the IPSec proposal of the initiator for negotiation. This ensures successful IPSec negotiation.

   After the ike negotiate compatible command is configured, the default duration and traffic for IPSec SA aging are 604800 seconds and 0 (indicating that the traffic timeout function is disabled on the responder), respectively. As a result, the responder cannot proactively initiate IPSec SA re-negotiation.

6. (Optional) Run remote-address { [ vpn-instance vpn-instance-name ] { start-ipv4-address [ end-ipv4-address ] | start-ipv6-address [ end-ipv6-address ] | host-name host-name } | ip-pool pool-number | authentication-address start-ipv4-address [ end-ipv4-address ] }

   The remote IP address/IP address segment or domain name used in IKE negotiation is configured.

   By default, an IKE peer has no domain name, remote IP address, or remote IP address range configured.

   IPv4 and IPv6 addresses cannot be configured on the device simultaneously. If remote-address specifies a domain name and IPSec does not obtain an IP address based on the domain name, you can configure an address or domain name of a different IP version. However, the specified domain name and configured address or domain name cannot take effect simultaneously, and only the IP address that IPSec obtains first takes effect.

   When an IPSec policy is applied to a tunnel interface to establish an IPSec 6 tunnel, the IP address of the remote tunnel interface needs to be specified using remote-address.

   If both tunnel local and remote-address are configured, IP addresses of the same version must be specified.

   If a VPN instance has been configured on the interface applied with an IPSec policy, the vpn-instance-name parameter needs to be configured. After this parameter is configured, the device searches for a route to the remote IP address in the specified VPN during IPSec tunnel negotiation. If more than one remote IP address or domain name is configured, the specified vpn-instance-name must be the same.

   If the remote device has a variable IP address and a fixed domain name, you must specify host-name to configure the remote domain name. In this situation, the remote end must have Dynamic Domain Name System (DDNS) configured to bind domain names to dynamic IP addresses, and the local end must have DNS configured for domain name resolution.

   To enable the local end to allocate an IP address to the remote end, you can specify pool-number on the local end to configure an IP address pool.

   You can specify authentication-address to configure the pre-NAT IP address as the remote authentication address when the following conditions are met:

   • Two devices use IKEv2.
   • The remote device uses the internal IP address.
   • Packets traverse the NAT device.
   • The IP address is used for authentication.

   The post-NAT IP address needs to be used as the remote address in this situation.

7. (Optional) Run ipsec sm4 version { draft-standard | standard }

   Set the SM4 algorithm version used for IKE negotiation.

   By default, the SM4 algorithm version draft-standard is used.

   For IKE negotiation during interconnection with non-Huawei devices, if the SM4 algorithm versions used by devices of different vendors differ from each other, the IKE negotiation fails. In this case, run this command to set the SM4 algorithm version consistent with that on non-Huawei devices.

8. Run ike-proposal proposal-number

   An IKE proposal is referenced.

   The IKE proposal must have been created.

   By default, an IKE peer does not reference an IKE proposal

9. Configure identity authentication parameters.

   Identity authentication parameters are different in different authentication modes. Configure identity authentication parameters based on the authentication mode defined in an IKE proposal.

   • Pre-shared key authentication

     1. Run pre-shared-key key

        The pre-shared key used by IKE peers to perform pre-shared key authentication is configured.

        The pre-shared key at the two ends must be the same.

     2. Configure a pre-shared key for pre-shared key authentication.

        You can use the following methods to configure the pre-shared key. When both of the two methods are used, the pre-shared key configured in the IKE user table is preferred.

        • A single IKE peer or multiple IKE peers use the same ID and pre-shared key.

          Run the pre-shared-key key command to configure a pre-shared key.

          The pre-shared key at the two ends must be the same.

        • Multiple IKE peers use different IDs and pre-shared keys.

          

          • In a point-to-multipoint scenario, the device functions as the VPN gateway of the headquarters, an IPSec policy is created using an IPSec policy template, and the VPN gateway receives IPSec connection setup requests of different branches. When the pre-shared key is used for identity authentication and all branches use the same ID and pre-shared key, there are security risks. That is, if the ID and pre-shared key of one branch leak, the ID and pre-shared key of all branches leak. The IKE user table can prevent this problem.

          • When the IKE user table is used, you do not need to use the remote-id-type command subsequently.

          1. Run quit

             Return to the system view.

          2. Run ike user-table user-table-id

             An IKE user table is created and its view is displayed, or the view of an existing IKE user table is displayed directly.

          3. Run user user-name

             An IKE user is created and its view is displayed, or the view of an existing IKE user is displayed directly.

          4. Run pre-shared-key key

             The pre-shared key used by IKE peers is configured when IKE peers use pre-shared key authentication during IKE negotiation.

             By default, the pre-shared key used by IKE peers is not configured when IKE peers use pre-shared key authentication during IKE negotiation.

          5. Run id-type { any any-id | esn esn-number | fqdn remote-fqdn | ip { ipv4-address | ipv6-address } | user-fqdn remote-user-fqdn }

             The IKE user ID type and ID are configured.

             By default, the IKE user ID type and ID are not configured.

             The value of id-type is the remote ID.

             When IKEv1 in main mode is used, the value of id-type must be set to ip. In NAT traversal scenarios, ipv4-address should be set to the IP address that is translated using NAT.

          6. (Optional) Run description description

             The description of an IKE user is configured.

             By default, the description of an IKE user is not configured.

          7. Run quit

             Return to the IKE user table view.

          8. Run quit

             Return to the system view.

          9. Run ike peer peer-name

             The IKE peer view is displayed.

          10. Run user-table user-table-id

              An IKE user table is reference in the IKE peer.

     3. Configure the ID type and ID value.

        For pre-shared key authentication, the local ID type or local ID on the local end must be the same as the remote ID type or remote ID on the remote end. Configure the ID type and ID value according to Table 1.

        Table 1 Relationship between the local ID type, local ID, remote ID type, and remote ID

        Local ID Type	Local ID	Remote ID Type	Remote ID
        FQDN	Local name: local-id device	FQDN	remote-id device
        IP	Local IP address: 10.1.1.3	IP	remote-address 10.1.1.3
        User-FQDN	Local user domain name: local-id devicea@example.com	User-FQDN	remote-id devicea@example.com
        ESN	You do not need to configure this parameter. The ESN of the device is used by default.	ESN	You do not need to configure this parameter. The ESN of the device is used by default.

        1. Run local-id-type { esn | fqdn | ip [ ip-configurable ] | user-fqdn }

           The local ID type used in IKE negotiation is set.

           By default, the IP address of the local end is used as the local ID.

        2. (Optional) Run local-id id

           The local ID used in IKE negotiation is set.

           You need to configure the local ID when the ID type of an IKE peer is IP, FQDN, or User-FQDN.

           

           • When the local ID type is IP, you do not need to perform this step. In this case, the device uses the IP address of the interface for establishing an IPSec tunnel as the local ID by default. If the interface has multiple IP addresses, for example, primary and secondary IP addresses are configured, the device uses the IP address configured by the tunnel local command as the local ID.

           • If the ID type is FQDN or User-FQDN, you can also run the ike local-name local-name command in the system view to configure the local ID during IKE negotiation. Then all IKE peers of the device use this local ID for identity authentication.

           • The local ID configured by the local-id command takes precedence over the local ID configured by the ike local-name command.

        3. Run remote-id-type { any | esn | fqdn | ip | user-fqdn | none }

           The remote ID type used in IKE negotiation is set.

           By default, no remote ID type is set.

        4. (Optional) Run remote-id id

           The remote ID used in IKE negotiation is set.

   • RSA signature authentication

     1. Configure the ID type and ID value.

        For RSA signature authentication, the remote ID type or remote ID on the local end must be consistent with corresponding fields in the local certificate on the remote end. Configure the ID type and ID value according to Table 2.

        Table 2 Relationship between the local ID type, local ID, remote ID type, and remote ID

        Local ID Type	Local ID	Remote ID Type	Remote ID
        DN	Subject: CN=devicea	DN	remote-id /CN=devicea
        FQDN	DNS:devicea.example.com	FQDN	remote-id devicea.example.com
        IP	Local IP address: 10.1.1.3	IP	remote-address 10.1.1.3
        User-FQDN	email: devicea@example.com	User-FQDN	remote-id devicea@example.com

        1. (Optional) Run ikev2 authentication sign-hash { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }

           The certificate signature algorithm used by IKEv2 is configured.

           By default, IKEv2 uses the certificate signature algorithm SHA2-256.

        2. Run rsa signature-padding { pkcs1 | pss }

           A padding mode is configured for the RSA signature.

           By default, the padding mode of the RSA signature is PSS.

        3. Run certificate local-filename filename

           The local digital certificate is specified offline.

           Or run pki realm realm-name

           The PKI domain that the digital certificate of the IKE peer belongs to is specified. The local digital certificate is obtained based on the configuration of the PKI domain.

           If the authentication mode is RSA signature, the local certificate contains the IP address, DN, name, and User-FQDN information about the local end.

           

           In IKEv1 scenarios, when RSA signature authentication is used for identity authentication, certificates generated using SM2 key pairs can be used.

        4. (Optional) Run local-id-reflect enable

           During IKEv2 negotiation, the local ID of the responder is used as the remote ID carried in the IKE packets sent by the initiator.

           By default, this function is enabled.

           During IKEv2 negotiation, if the user does not know the remote ID configured for the initiator, you can perform this step on the responder. When the responder receives an IKE packet from the initiator, the responder uses the IDr payload (remote ID) in the received packet as its local ID. If the responder does not obtain the IDr payload, it obtains its local ID based on the local configuration.

           Currently, the ID type can only be IP address, ESN, FQDN, or User-FQDN.

           When both the local-id-reflect enable and local-id-preference certificate enable commands are configured, the local-id-reflect enable command takes effect.

        5. (Optional) Run local-id-preference certificate enable

           The device is enabled to preferentially obtain the local ID from a field in a certificate when IKE uses certificate negotiation.

           By default, the device preferentially obtains the local ID from a field in a certificate when IKE uses certificate negotiation.

           When IKE uses certificate negotiation, the device can obtain its local ID from a field (IP address, FQDN, or email address) in the certificate, removing the need to configure the local ID.

           After this command is configured, the device preferentially obtains its local ID from a field in the certificate. If this method fails, it obtains its local ID based on the local configuration. If this method also fails, IKE negotiation fails.

        6. Run local-id-type { dn | fqdn | ip [ ip-configurable ] | user-fqdn }

           The ID type is configured.

           By default, the IP address of the local end is used as the local ID.

           The specified ID type must be the same as that displayed in the display pki certificate command output.

        7. (Optional) Run local-id id

           The local ID used in IKE negotiation is set.

           You need to configure the local ID when the ID type of an IKE peer is IP, FQDN, or User-FQDN.

        8. Run remote-id-type { any | dn | fqdn | ip | user-fqdn | none }

           The remote ID type used in IKE negotiation is set.

           By default, no remote ID type is set.

           The local and remote ID types of an IKE peer must be the same.

        9. (Optional) Run remote-id id

           The remote ID used in IKE negotiation is set.

           

           If the local ID type is FQDN or User-FQDN, the remote end uses the remote-id specified in the IKE peer as the remote ID for IKEv1 negotiation. However, for IKEv2 negotiation, the remote end preferentially uses the value of the DNS (corresponding to FQDN) or email (corresponding to User-FQDN) field in the certificate. If the fields are unavailable, the remote end uses the remote-id specified in the IKE peer for negotiation.

        10. (Optional) Run inband ocsp

            The device is configured to validate the remote certificate based on the OCSP validation result sent from the remote device when IKEv2 uses RSA signature authentication.

            By default, the device does not validate the remote certificate based on the OCSP validation result sent from the remote device when IKEv2 uses RSA signature authentication.

        11. (Optional) Run inband crl

            The device is configured to validate the remote certificate based on the CRL sent from the remote device when IKEv2 uses RSA signature authentication.

            By default, the device does not validate the remote certificate based on the CRL sent from the remote device when IKEv2 uses RSA signature authentication.

            If both the inband ocsp and inband crl commands are run, the certificate is considered valid only when the certificate verifications in OCSP and CRL modes are passed.

        12. (Optional) Run certificate-access-policy policy-name

            A certificate access policy is referenced to the IKE peer.

            By default, the IKE peer does not reference a certificate access policy.

            The value of policy-name is the name of the certificate access policy created using the pki certificate access-control-policy name command.

            Perform this step if you want to control IPSec tunnel establishment using the certificate filtering function.

        13. (Optional) Run ikev2 id-match-certificate enable

            The device is enabled to check certificate identity information of the remote device during IKEv2 certificate negotiation.

            By default, the device does not check certificate identity information of the remote device during IKEv2 certificate negotiation.

            After this command is configured, the local device only checks the Subject field, IP address, FQDN, or email of the remote device. If the information differs from the ID (DN, IP address, FQDN, or User-FQDN) of the remote device, IKEv2 negotiation fails.

        14. (Optional) Run certificate-request empty-payload enable

            The certificate request payload is empty.

            By default, certificate request payloads carry CA information.

            When a template-based IPSec policy is configured for the FW in headquarters and certificate-based authentication is used, you can run the certificate-request empty-payload enable command to empty certificate request payloads so that users who use different CA certificates in branch offices can access the FW. Based on the certificate information about branch offices, the FW obtains certificates from associated certificate domains for authentication.

            If the access devices cannot process certificate request packets with an empty authentication and authorization field, do not configure this command. Otherwise, tunnel negotiation fails.

        15. (Optional) Run pki validate-certificate whitelist enable

            PKI certificate whitelist check is enabled.

            By default, PKI certificate whitelist check is disabled.

            In an LTE scenario, the device establishes IPSec tunnels with multiple base stations using certificate negotiation. To facilitate unified management of base station certificates, you can run this command. After PKI certificate whitelist check is enabled, the local device checks whether the CN in the certificate subject of the remote device carried in the received certificate authentication packet matches that in the local certificate whitelist. If they are different, authentication fails and an IPSec tunnel cannot be established between the two devices.

            Ensure that the certificate whitelist file has been imported to the device memory by using the pki import whitelist command. Otherwise, PKI certificate whitelist check does not take effect.

        16. (Optional) Run pki whitelist-fuzzy-match enable

            Fuzzy match for the PKI certificate whitelist is enabled.

            By default, the PKI certificate whitelist supports exact match.

            In some scenarios, however, the CN in a certificate subject contains dots (.), such as 123.huawei.com, but that in the certificate whitelist does not, such as 123. In this case, the CN in the certificate subject of the remote device does not exactly match that in the local certificate whitelist, leading to an authentication failure. To prevent this problem, run the pki whitelist-fuzzy-match enable command to enable fuzzy match for the PKI certificate whitelist. After this function is enabled, the local device matches the content before the first dot in the received CN with that in the local certificate whitelist. If they match, authentication succeeds.

            Ensure that PKI certificate whitelist check has been enabled by using the pki validate-certificate whitelist enable command. Otherwise, fuzzy match for the PKI certificate whitelist does not take effect.

            Ensure that the CN in the certificate whitelist does not contain dots. Otherwise, fuzzy match fails for the PKI certificate whitelist.

   • RSA authentication for digital envelope

     

     Only the IKEv1 main mode supports RSA authentication for digital envelope.

     In an IKE negotiation, the local and remote IDs can only use the fixed format DN.

     When RSA authentication for digital envelope is configured, the ike-proposal command must be run on the IKE peer to reference an IKE proposal; otherwise, IKE negotiation will fail.

     1. Run rsa signature-padding { pkcs1 | pss }

        A padding mode is configured for the RSA signature.

        By default, the padding mode of the RSA signature is PSS.

     2. Run rsa encryption-padding { oaep | pkcs1 }

        The padding mode for RSA encryption is set.

        The default padding mode is OAEP.

     3. Run certificate local-filename filename

        The digital certificate is specified for the local end offline.

        Or run pki realm realm-name

        The PKI domain is specified for the digital certificate. The local digital certificate is obtained based on the configuration of the PKI domain.

        realm-name specifies a PKI domain that has been created using the pki realm command.

     4. Run certificate peer-filename filename

        The certificate file name of the peer is specified.

        Or run certificate peer-name peer-name

        The IKEv1 digital envelope negotiation is configured to use the peer certificate imported by PKI.

        

        If the local digital certificate is specified using the preceding two methods and the CA certificate has been imported to the PKI domain, the device uses the digital certificate specified offline during certificate negotiation but uses the CA certificate in the PKI domain during certificate verification. You are advised to select only one method to specify the digital certificate used by the local end.

     5. (Optional) Run remote-id id

        The peer ID is set.

        The id parameter does not need to be set. By default, the Subject field ID in the peer certificate is used. If you specify the id parameter, ensure that the value is the same as the Subject field ID; otherwise, IKE negotiation will fail.

     6. (Optional) Run certificate-access-policy policy-name

        A certificate access policy is referenced to the IKE peer.

        By default, the IKE peer does not reference a certificate access policy.

        The value of policy-name is the name of the certificate access policy created using the pki certificate access-control-policy name command.

        Perform this step if you want to control IPSec tunnel establishment using the certificate filtering function.

     7. (Optional) Run certificate-request empty-payload enable

        The certificate request payload is empty.

        By default, certificate request payloads carry CA information.

        When a template-based IPSec policy is configured for the FW in headquarters and certificate-based authentication is used, you can run the certificate-request empty-payload enable command to empty certificate request payloads so that users who use different CA certificates in branch offices can access the FW. Based on the certificate information about branch offices, the FW obtains certificates from associated certificate domains for authentication.

        If the access devices cannot process certificate request packets with an empty authentication and authorization field, do not configure this command. Otherwise, tunnel negotiation fails.

     8. (Optional) Run pki validate-certificate whitelist enable

        PKI certificate whitelist check is enabled.

        By default, PKI certificate whitelist check is disabled.

        In an LTE scenario, the device establishes IPSec tunnels with multiple base stations using certificate negotiation. To facilitate unified management of base station certificates, you can run this command. After PKI certificate whitelist check is enabled, the local device checks whether the CN in the certificate subject of the remote device carried in the received certificate authentication packet matches that in the local certificate whitelist. If they are different, authentication fails and an IPSec tunnel cannot be established between the two devices.

        Ensure that the certificate whitelist file has been imported to the device memory by using the pki import whitelist command. Otherwise, PKI certificate whitelist check does not take effect.

     9. (Optional) Run pki whitelist-fuzzy-match enable

        Fuzzy match for the PKI certificate whitelist is enabled.

        By default, the PKI certificate whitelist supports exact match.

        In some scenarios, however, the CN in a certificate subject contains dots (.), such as 123.huawei.com, but that in the certificate whitelist does not, such as 123. In this case, the CN in the certificate subject of the remote device does not exactly match that in the local certificate whitelist, leading to an authentication failure. To prevent this problem, run the pki whitelist-fuzzy-match enable command to enable fuzzy match for the PKI certificate whitelist. After this function is enabled, the local device matches the content before the first dot in the received CN with that in the local certificate whitelist. If they match, authentication succeeds.

        Ensure that PKI certificate whitelist check has been enabled by using the pki validate-certificate whitelist enable command. Otherwise, fuzzy match for the PKI certificate whitelist does not take effect.

        Ensure that the CN in the certificate whitelist does not contain dots. Otherwise, fuzzy match fails for the PKI certificate whitelist.

     10. (Optional) Enable IKE negotiation packets to carry the SM encryption key length.

         1. Run quit

            Return to the system view.

         2. Run ike sm-encryption-key-length enable

            The device is enabled to carry the SM encryption key length in IKE negotiation packets.

            By default, IKE negotiation packets do not carry the SM encryption key length.

            If the IKE responder cannot process the SM encryption key length, run the undo ike sm-encryption-key-length enable command on the IKE initiator to disable IKE negotiation packets from carrying the SM encryption key length. Otherwise, IKE negotiation fails.

         3. Run ike peer peer-name

            The IKE peer view is displayed.

   • SM2 digital envelope authentication (digital-envelope version 2.0)
     1. Run the encryption-certificate pki realm realm-name

        Configure a PKI encryption realm for an IKE peer.

        The encryption certificate used for SM digital envelope authentication must be imported to the device using the pki import-certificate local realm realm-name { der | pkcs12 | pem } filename filename no-check-same-name command. The no-check-same-name parameter allows the device to import the encryption certificate and signature certificate with the same issuer and subject names.

     2. Run the signature-certificate pki realm realm-name

        Configure a PKI signature realm for an IKE peer.

        The signature certificate used for SM digital envelope authentication must be imported to the device using the pki import-certificate local realm realm-name { der | pkcs12 | pem } filename filename no-check-same-name command. The no-check-same-name parameter allows the device to import the encryption certificate and signature certificate with the same issuer and subject names.

10. (Optional) Run lifetime-notification-message enable

    The device is enabled to send IKE SA lifetime notification messages.

    By default, the device does not send IKE SA lifetime notification messages.

    IKEv1 peers negotiate the lifetime, and a smaller SA lifetime at the two ends is used. When a Huawei device and a non-Huawei device establish an IPSec tunnel and they use different IKE SA lifetimes, run this command to enable the device to send IKE SA lifetime notification messages. By doing this, two ends can successfully perform IKE negotiation.

11. (Optional) Run lifetime-notify-payload hash-disable

    Configure the device not to calculate the notification payload of the aging configuration during IKEv1 phase-2 HASH2 calculation.

    By default, the device calculates the notification payload of the aging configuration during IKEv1 phase-2 HASH2 calculation.

    This command is used for compatibility with the hash calculation difference between the local device and the peer non-Huawei device during IKEv1 phase-2 negotiation. If the peer device of the tunnel is a Huawei device, do not run this command.

12. (Optional) Run re-authentication interval interval

    The IKEv2 re-authentication interval is set.

    By default, IKEv2 does not perform re-authentication.

    In remote access, IPSec peers periodically send re-authentication packets, which reduces potential risks of attacks and improves IPSec network security.