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

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R010

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 a KS

Configuring a KS

Pre-configuration Tasks

Before configuring a KS, complete the following tasks:
  • Configure reachable routes between the GMs and KS.
  • Determine the data flows to be protected by A2A VPN.
  • Determine the encryption algorithm for IKE negotiation, that is, configure parameters for an IKE proposal.
  • Determine the encryption algorithm for data flow protection, that is, configure parameters for a security proposal.

Defining the Data Flows to Be Protected by A2A VPN

Context

After a GM registers with the KS, the GM obtains security policies from the KS, including the ACL rules configured on the KS. The ACL rules configured on the KS determine the data flows to be encrypted and those to be forwarded in plain text. The GM matches received data flows with the ACL rules obtained from the KS. If a data flow matches an ACL rule that defines the permit action, the GM encrypts and forwards the data flow; if a data flow matches an ACL rule that defines the deny action, the GM forwards the data flow in plain text.

NOTE:

The GM supports a maximum of 100 ACL rules, and excess ACL rules pushed by the KS do not take effect.

When configuring an ACL on the KS, you must deploy ACL rules based on the encrypted data flows to prevent some unencrypted packets from being discarded by IPSec verification, for example, rekey packets and IKE packets. When the ACL range is large, you must configure "deny" ACL rules for the packets that are not encrypted and should not be discarded. This ensures that such packets will not be dropped by IPSec verification.

Procedure

  1. Run the system-view command to enter the system view.
  2. Run the acl [ number ] acl-number [ match-order { config | auto } ] command to create an advanced ACL and enter the advanced ACL view. (The value of acl-number ranges from 3000 to 3999.)
  3. Perform any of the following operations as required:

    • Run the rule [ rule-id ] { deny | permit } ip [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | dscp dscp | vpn-instance vpn-instance-name ] * command to configure a rule to match the IP protocol.
    • Run the rule [ rule-id ] { deny | permit } tcp [ destination { destination-address destination-wildcard | any } | destination-port eq port | source { source-address source-wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] * command to configure a rule to match the TCP protocol.
    • Run the rule [ rule-id ] { deny | permit } udp [ destination { destination-address destination-wildcard | any } | destination-port eq port | source { source-address source-wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] * command to configure a rule to match the UDP protocol.
    • Run the rule [ rule-id ] { deny | permit } gre [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | dscp dscp | precedence precedence | tos tos | time-range time-name | logging | vpn-instance vpn-instance-name ] * command to configure a rule to match the GRE protocol.
    • Run the rule [ rule-id ] { deny | permit } gre [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | [ dscp dscp | [ tos tos | precedence precedence ] * ] | time-range time-name | logging | vpn-instance vpn-instance-name ] * command to configure a rule to match the GRE protocol.

Configuration Tips

Deploy data flows to be protected between GMs on the KS. Assume that the network segment 10.1.1.0/24 needs to be protected on GM_1 and 10.2.1.0/24 needs to be protected on GM_2.

The following shows a sample configuration on the KS:

[Huawei] acl 3001
[Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
[Huawei-acl-adv-3001] rule permit ip source 10.2.1.0 0.0.0.255 destination 10.1.1.0 0.0.0.255

Configuring IKE

Context

Configure IKE to perform IKE phase 1 negotiation with a GM and establish an IKE SA to protect the GDOI negotiation between the GM and the KS.

NOTE:

The KS does not support the IKEv2 protocol or RSA signature authentication.

Procedure

In A2A VPN, the detailed IKE configuration procedure is as follows:

  1. Configure an IKE proposal. For details, see "Configuring an IKE Proposal" in "IPSec Configuration".

  2. (Optional) Configure the lifetime of the IKE SA. See "(Optional) Setting the IKE SA Lifetime" in "IPSec Configuration" for more information.

Configuring an IPSec Proposal

Context

After registering with the KS, a GM obtains security policies from the KS, including the IPSec proposal configured on the KS. The GM uses the IPSec proposal to set up a TEK SA with another GM.

For details on how to configure an IPSec proposal, see "Configuring an IPSec Proposal" in "IPSec Configuration".

NOTE:

The KS supports only the Encapsulating Security Payload (ESP) protocol and the tunnel encapsulation mode.

Configuring a GDOI Group

Context

After a GM registers with the KS, the KS identifies the GDOI group to which the GM belongs based on the group ID submitted by the GM, and then pushes the security policies in the GDOI group to the GM. These security policies are used by GMs to generate TEK SA and KEK SA..

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run gdoi ks group group-name

    A GDOI group is created for the KS, and the GDOI group view is displayed.

    By default, no GDOI group is created for a KS.

  3. Run group identity number { group-number | ip-address }

    An identifier is configured for the GDOI group.

    By default, a GDOI group has no identifier.

    The group identifier is also called group ID. A GDOI group can only use its group number or IP address as the group ID and can only have one group ID configured.

  4. Run source address ip-address

    The IP address of the KS is configured.

    By default, no IP address is configured for a KS.

  5. Configure a pre-shared key.
    1. Run quit

      Return to the system view.

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

      An IKE user table is created and the IKE user table view is displayed.

      By default, no IKE user table is configured.

    3. Run user user-name

      An IKE user is created in the IKE user table and the IKE user view is displayed.

      By default, no IKE user is created in an IKE user table.

    4. Run id-type { any any-id | fqdn remote-fqdn | ip ipv4-address | user-fqdn remote-user-fqdn }

      The user ID type and ID are configured for the IKE user.

      By default, no user ID type or ID is configured for an IKE user.

      The value of id-type is the remote ID type.

    5. Run pre-shared-key key

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

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

    6. Run quit

      Return to the IKE user table view.

    7. Run quit

      Return to the system view.

    8. Run gdoi ks group group-name

      The GDOI group view is displayed.

    9. Run user-table user-table-id

      The IKE user table is referenced in the GDOI group.

      By default, no IKE user table is referenced in a GDOI group.

  6. Run rekey transport-type { multicast | unicast }

    The transmission mode of rekey messages is configured.

    The default transmission mode of rekey messages is multicast.

  7. (Optional) Run rekey destination address ip-address

    The destination IP address used by multicast rekey messages is configured.

    By default, no destination IP address is configured for multicast rekey messages.

    Perform this step when the transmission mode of rekey messages is multicast.

  8. Run rekey encryption-algorithm { des | 3des | aes-128 | aes-192 | aes-256 }

    The encryption algorithm used by rekey messages is configured.

    The default encryption algorithm used by rekey messages is AES-256.

    The DES and 3DES algorithms are not secure and therefore not recommended.

  9. Run rekey sig-hash-algorithm { sha1 | sha2-256 | sha2-384 | sha2-512 }

    The signature hash algorithm for rekey messages is configured.

    The default signature hash algorithm for rekey messages is SHA2-256.

    The SHA1 algorithm is not secure and therefore not recommended.

  10. Run rekey authentication public-key rsa key-pair-name

    The RSA key pair used by rekey messages is configured.

    By default, no RSA key pair is configured for rekey messages.

    key-pair-name is the RSA key pair created using the pki rsa local-key-pair create command or imported to the device memory using the pki import rsa-key-pair command.

  11. (Optional) Run rekey retry limit limit interval interval

    The number of retransmissions and retransmission interval of rekey messages are configured.

    By default, the number of retransmissions of rekey messages is 3 and the retransmission interval is 10 seconds.

  12. (Optional) Run local-id-type { fqdn | ip | user-fqdn }

    The local ID type of the GDOI group is configured.

    The default local ID type of a GDOI group is in the IP address format.

  13. (Optional) Run local-id id

    The local ID of the GDOI group is configured.

    By default, no local ID is specified for a GDOI group.

    Perform this step when the local ID type is set to FQDN or user-FQDN.

  14. Run ipsec policy-num

    A GDOI group IPSec policy is created and the GDOI group IPSec policy view is displayed.

    By default, no GDOI group IPSec policy is created.

  15. Run proposal proposal-name

    An IPSec proposal is referenced in the GDOI group IPSec policy.

    By default, no IPSec proposal is referenced in a GDOI group IPSec policy.

    proposal-name specifies the name of an IPSec proposal that has been created.

  16. Run security acl acl-number

    An ACL is referenced in the GDOI group IPSec policy.

    By default, no ACL is referenced in a GDOI group IPSec policy.

    acl-number specifies a created advanced ACL that defines the data flows to be protected by the A2A VPN.

Follow-up Procedure

After modifying the configuration in the GDOI group, you can run the gdoi ks rekey group group-name command to manually trigger the KS to send rekey messages, without waiting for the aging of the KEK SA.

(Optional) Configuring the SA Mode

Context

If SA modes cannot be configured in stages when you deploy the A2A VPN on an existing network (such as the MPLS VPN), services will be interrupted because a GM that joins a group can send and receive only ciphertext packets but the GM that has not joined the group can send and receive only plaintext packets. To prevent this problem, set the SA mode to Receive_Only or Normal on the KS and enable the KS to cooperate with GMs for phased deployment of the A2A VPN.

The procedure is as follows:

  1. Deploy the KS and set the SA mode to Receive_Only on the KS. The KS will deliver this SA mode to the GMs.

  2. Deploy GMs on the A2A VPN network one by one. The registered GMs work in Receive_Only mode, so they can communicate with the newly deployed GMs before they register with the KS.

  3. After all the GMs are deployed, set the SA mode to Receive_Option on the GMs. A GM in Receive_Option mode can still communicate with a GM in Receive_Only mode.

  4. After all the GMs are switched to Receive_Option mode, set the SA mode to Normal on the KS.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run gdoi ks group group-name

    The GDOI group view is displayed.

  3. Run sa receive-only

    The SA mode is set to Receive_Only. In this mode, the GM can send only plaintext packets but can receive both plaintext and ciphertext packets.

    By default, the SA mode is Normal. In this mode, the GM sends and receives only ciphertext packets.

(Optional) Configuring the Group SA Lifetime

Context

The SA lifetime is used for periodic SA updates and can reduce the risk of SA cracking and improve security.

The SA lifetime falls into the following types:
  • Hard lifetime (hard timeout period): defines the number of seconds until the SA expires.

  • Soft lifetime (soft timeout period): defines the number of seconds until the IKE process is informed that the SA is about to expire. This is to provide enough time for the creation of a new SA before the hard lifetime is reached.

There are two types of group SAs:
  • Key Encryption Key (KEK) SA

    When the soft lifetime expires, the KS generates a new KEK SA and sends it to GMs through rekey messages. After receiving the rekey messages, GMs delete the old KEK SA and use the new one when the hard lifetime expires.

  • Traffic Encryption Key (TEK) SA

    When the soft lifetime expires, the KS generates a new TEK SA and sends it to GMs through rekey messages. After receiving the rekey messages, GMs use the new TEK SA 30 seconds prior to hard lifetime expiry. When the hard lifetime expires, the old TEK SA is deleted.

The value of the soft lifetime is related to the transmission mode, number of retransmissions, and retransmission interval of rekey messages. Table 6-2 shows the detailed calculation methods.
Table 6-2  Soft lifetime values
Soft Lifetime Type Value

KEK SA

  • Unicast rekey

    Soft lifetime = Hard lifetime - (30 + (Number of retransmissions + 1) x Retransmission interval + 5 x Number of GMs in the group/50)

  • Multicast rekey

    Soft lifetime = Hard lifetime - (30 + (Number of retransmissions + 1) x Retransmission interval)

TEK SA

  • Unicast rekey

    Soft lifetime = Hard lifetime - (90 + (Number of retransmissions + 1) x Retransmission interval + 5 x Number of GMs in the group/50)

  • Multicast rekey

    Soft lifetime = Hard lifetime - (90 + (Number of retransmissions + 1) x Retransmission interval)

Procedure

  • Configure the KEK SA hard lifetime.
    1. Run system-view

      The system view is displayed.

    2. Run gdoi ks group group-name

      The GDOI group view is displayed.

    3. Run rekey sa duration time-based seconds

      The KEK SA hard lifetime is configured.

      The default KEK SA hard lifetime is 86,400 seconds.

  • Configure the TEK SA hard lifetime.
    1. Run system-view

      The system view is displayed.

    2. Run gdoi ks group group-name

      The GDOI group view is displayed.

    3. Run ipsec policy-num

      The GDOI group IPSec policy view is displayed.

    4. Run sa duration time-based seconds

      The TEK SA hard lifetime is configured.

      The default TEK SA hard lifetime is 3600 seconds.

(Optional) Configuring the Time-based Anti-Replay Function

Context

To prevent unauthorized users from stealing A2A VPN packets for DoS attacks, the A2A VPN provides the time-based anti-replay function to detect replayed packets (processed packets) according to the time mechanism.

After this function is enabled for the A2A VPN, the KS generates a pseudo timestamp (PTs) based on the GM and sends the pseudo timestamp and time-based anti-replay window (Tw) to GMs. During communication between GMs, the pseudo timestamp and time-based anti-replay window are used to prevent replayed packets. The detailed process is as follows:
  1. When sending a packet, GM_1 adds the encryption time t1 to the encrypted packet. The formula for calculating t1 is as follows: t1 = Pseudo timestamp (PTs1) + Packet sending time (ts) - GM_1 registration time (tr1).
  2. After receiving the packet, GM_2 generates the time t2, extracts the encryption time t1 from the packet, and compares t1 and t2. The formula for calculating t2 is as follows: t2 = Pseudo timestamp (PTs2) + Time when the packet is received (tsr) - GM_2 registration time (tr2). If the difference between t1 and t2 is within the range (-Tw to +Tw), the packet is accepted; otherwise, the packet is dropped.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run gdoi ks group group-name

    The GDOI group view is displayed.

  3. Run ipsec policy-num

    The GDOI group IPSec policy view is displayed.

  4. Run anti-replay time-based enable

    The time-based anti-replay function is enabled for the A2A VPN.

    By default, the time-based anti-replay function is disabled for the A2A VPN.

  5. Run anti-replay time-based window seconds

    The time-based anti-replay window size is configured for the A2A VPN.

    The default size of the A2A VPN time-based anti-replay window is 5 seconds.

Verifying the KS Configuration

Prerequisites

All A2A VPN configurations are complete.

Procedure

  • Run the display ike proposal [ number proposal-number ] command to check the parameters of the IKE proposal.
  • Run the display ipsec proposal [ brief | name proposal-name ] command to view information about the IPSec proposal.
  • Run the display gdoi ks group [ brief | name group-name ] command to check the GDOI group configuration of the KS.
  • Run the display gdoi ks members [ group group-name ] command to view information about GDOI group members of the KS.
  • Run the display ike sa [ remote ipv4-address ] command to check brief information about IKE SAs.
  • Run the display ike sa [ remote-id-type remote-id-type ] remote-id remote-id command to check brief information about IKE SAs based on the remote ID.
  • Run the display ike sa verbose { remote ipv4-address | connection-id connection-id | [ remote-id-type remote-id-type ] remote-id remote-id } command to check detailed information about IKE SAs.
  • Run the display gdoi ks sa [ group group-name ] command to check the SA information about a GDOI group of the KS.
Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100033725

Views: 152905

Downloads: 369

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