No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CLI-based Configuration Guide - VPN

AR650, AR1600, and AR6100 V300R003

This document describes VPN features on the device and provides configuration procedures and configuration examples.
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Configuring an IKE Peer

Configuring an IKE Peer

Context

When an IPSec tunnel is established in IKE negotiation mode, you need to reference an IKE peer and configure attributes between IKE peers during IKE negotiation. When configuring attributes between IKE peers, note the following points:
  • The IKE peers must use the same IKE version.
  • The IKE peers that use IKEv1 must use the same negotiation mode.
  • Identity authentication parameters of the IKE peers must match.

IKE has two versions: IKEv1 and IKEv2. The differences between IKEv1 and IKEv2 are as follows:

  • IKEv1 requires the phase 1 negotiation mode, whereas IKEv2 does not.
  • IKEv1 does not support the Online Certificate Status Protocol (OCSP) for an IKE peer, whereas IKEv2 supports.
  • IKEv2 supports the re-authentication interval to enhance security, whereas IKEv1 does not support the re-authentication interval.

Pre-configuration Tasks

Before configuring an IKE peer, complete the following tasks:
  • Import the local certificate and CA root certificate on the authenticated end and import the CA root certificate on the authenticating end if RSA signature authentication is used.
  • Generate the RSA key pair on the authenticated end if RSA key authentication is used.

    In IKEv1 certificate negotiation, if the authentication algorithm sha2-512 is configured, the RSA key length must be greater than 1024.

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 local-address ipv4-address

    The local IP address in IKE negotiation is configured.

    By default, the system selects an outbound interface according to a route and uses the IP address of the outbound interface as the local IP address.

    Generally, you do not need to configure the local IP address.

    • If the IP address of an interface bound to an IPSec policy is variable or unknown, run the local-address ipv4-address command to specify the IP address of another interface such as a loopback interface as the local IP address.
    • If an interface bound to an IPSec policy is configured with one primary IP address and multiple secondary IP addresses, run the local-address ipv4-address command to specify one IP address as the local IP address.
    • If the local and remote ends have equal-cost routes, run the local-address ipv4-address command to specify the local IP address so that IPSec packets can be sent out from the specified interface.

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

    The remote IP address 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.

    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.

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

  8. 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. 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 { simple | cipher } 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.

          NOTE:
          • 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 | fqdn remote-fqdn | ip ipv4-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 interface-assign interface-type interface-number

            An interface associated with the IKE user is assigned.

            By default, no interface on the device is associated with the IKE user.

            Currently, the interface can only be a tunnel interface.

            The IKE user table in the headquarters contains multiple IKE users for managing parameters for interconnection between the headquarters and branches. If one IPSec profile in the headquarters is applied to multiple tunnel interfaces, IPSec negotiation may fail because the IKE peer in the headquarters fails to match the tunnel interface of each branch. In this case, you can perform this step to assign an interface associated with an IKE user.

          7. (Optional) Run description description

            The description of an IKE user is configured.

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

          8. Run quit

            Return to the IKE user table view.

          9. Run quit

            Return to the system view.

          10. Run ike peer peer-name

            The IKE peer view is displayed.

          11. Run user-table user-table-id

            An IKE user table is reference in the IKE peer.

      2. 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 4-9.

        Table 4-9  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

        1. Run local-id-type { fqdn | ip | 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 FQDN or User-FQDN.

          NOTE:
          • 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.
          • 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 | 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.

          When the remote ID type is IP, the value configured by the remote-address command is used as the remote ID by default, regardless of whether the remote-id command is configured.

    • 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 4-10.

        Table 4-10  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 SHA1.

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

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

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

          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, 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 does not preferentially obtain 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 | 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 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 remote ID type is IP, you do not need to configure the remote-id command. In this case, the device uses the value specified by the remote-address command as the remote ID by default.

          NOTE:

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

        13. (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 Router 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 Router. Based on the certificate information about branch offices, the Router 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.

  9. (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.

  10. (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.

Download
Updated: 2019-04-12

Document ID: EDOC1100041799

Views: 31208

Downloads: 43

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next