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 GM

Configuring a GM

Pre-configuration Tasks

Before configuring a GM, complete the following tasks:
  • Configure reachable routes between the GMs and between the GM 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.
  • Specify the PKI domain to which the peer belongs if digital certificate PKI authentication is used.
    NOTE:
    For details on the PKI configuration, see "PKI Configuration" in Huawei AR Series V200R010 Configuration Guide - Security.

Configuration Procedure

Perform the following operations in sequence to configure a GM. You can determine whether to perform optional operations based on site requirements.

Configuring IKE

Context

To configure IKE, you need to configure an IKE proposal and an IKE peer for the first-stage IKE negotiation between the GM and KS.

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 IKE SA Lifetime, see "(Optional) Setting the IKE SA Lifetime" in "IPSec Configuration".

  3. Configure an IKE peer. For details, see "Configuring an IKE Peer" in "IPSec Configuration".

  4. (Optional) Bind a VPN instance to A2A VPN. For details, see "(Optional) Configuring IPSec VPN Multi-instance" in "IPSec Configuration".

(Optional) Defining Data Flows Not to Be Protected

Context

After a GM registers with the KS, the GM obtains security policies including the ACL rules from the KS. The ACL rules configured on the KS determine data flows to be encrypted and data flows to be forwarded in plain text. The GM matches received data flows with the ACL rules obtained from the KS. If the matched ACL rule defines a permit action, the GM encrypts the data flows and forwards them; if the matched ACL rule defines a deny action, the GM forwards the data flows in plain text. If a data flow matches an ACL rule that defines a permit action, but the GM wants to forward the data flow in plain text, you can configure a local ACL rule to define data flows not to be protected. When a device forwards a data flow, it matches the data flow with the local ACL rule first. If the data flow matches the local ACL rule, the device forwards the data flow in plain text. If not, the device matches the data flow with the ACL rules obtained from the KS.

NOTE:

If the KS sends more than 100 ACL rules to a GM, only 100 ACL rules take effect. If more than 100 ACL rules are configured on a GM, only 100 ACL rules take effect.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run acl [ number ] acl-number [ match-order { config | auto } ]

    An advanced ACL with acl-number ranging from 3000 to 3999 is created and the advanced ACL view is displayed.

  3. Run rule [ rule-id ] deny ip [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | vpn-instance vpn-instance-name | dscp dscp ] *

    An ACL rule is configured in the ACL view.

    A2A VPN also support advanced ACLs that define various protocols such as ICMP, TCP, UDP, and IGMP.

Configuring a GDOI Policy

Context

The name and sequence number identify a GDOI policy.

A GDOI policy contains key information submitted by a GM when it registers with the KS. The information includes the group ID, referenced IKE peer, and the registration interface.

  • Group ID: identifies a GDOI group in A2A VPN. The KS determines the GDOI group to which a GM is to be added based on the group ID submitted by the GM.

  • Referenced IKE peer: used for the first stage IKE negotiation.

  • Registration interface: A GM registers with the KS through the registration interface.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec policy policy-name seq-number gdoi

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

    By default, no GDOI policy is configured in the system.

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

    An identifier is configured for a 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.

  4. Run ike-peer peer-name

    An IKE peer is applied to the GDOI policy.

    peer-name specifies the name of a created IKE peer.

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

  5. (Optional) Run security acl acl-number

    An ACL is referenced in a GDOI policy.

    acl-number specifies an advanced ACL that defines the data flows not to be protected.

    By default, no ACL is referenced.

    A GDOI policy can reference only one ACL.

    A local ACL (supporting the deny action only) has a higher priority than an ACL downloaded from the KS.

  6. (Optional) Run tunnel local { ip-address | applied-interface }

    The local address is configured for A2A VPN.

    By default, no local address is configured for A2A VPN.

    For a GDOI policy, you do not need to configure a local address for A2A VPN because the device will select an appropriate local address based on routing information during SA negotiation.
    • If the IP address of the interface to which a GDOI policy is applied varies or is unknown, run the tunnel local ip-address command to specify the IP address of another interface (such as the loopback interface) on the device as the local IP address for A2A VPN. Otherwise, run the tunnel local applied-interface command to specify the IP address of the interface as the local IP address for A2A VPN.
    • If the interface to which a GDOI policy is applied has multiple IP addresses (one primary IP address and several secondary IP addresses), run the tunnel local ip-address command to specify one of these IP addresses as the local IP address for A2A VPN. Otherwise, run the tunnel local applied-interface command to specify the primary IP address of the interface as the local IP address for A2A VPN.
    • If equal-cost routes exist between the local and remote ends, run the tunnel local { ip-address | applied-interface } command to specify a local IP address for A2A VPN.

Configuring an IP Address for Multicast Rekey Messages

Context

After an IP address for multicast Rekey messages is configured, GMs with this IP address and a UDP port number 848/4500 update TEK SAs or KEK SAs based on the multicast Rekey messages.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec gdoi multicast-rekey ip ip-address

    An IP address is configured for multicast Rekey messages.

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

    The IP address for multicast Rekey messages configured on the GM must be the same as that configured on the KS.

(Optional) Configuring the Receive_Option Mode

Context

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

The SA mode deployment of GMs and the KS are 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.

When configuring the SA mode on the KS, refer to the KS configuration of other vendors.

Procedure

  1. Run gdoi sa direction receive-option

    The SA mode is set to Receive_Option. In this mode, the device can receive both cipher text and plain text packets but can send only cipher text packets.

(Optional) Configuring the QoS Function for A2A VPN

Context

In network planning, the QoS function needs to be configured to improve network service capabilities and provide differentiated services to different types of traffic. QoS groups the packets sharing common features into one class and provides the same QoS level for traffic of the same type. In this manner, the class-based QoS technology provides differentiated services.

You can configure the QoS function to implement refined QoS management on A2A VPN packets. Choose either of the following method based on site requirements:
  • If you want to classify packets to be encapsulated based on quintuple information including the source address, destination address, protocol type, source port number, and destination port number, configure the pre-extract original packet function. If you want to classify packets based on the source address, destination address, or protocol type only, you do not need to configure the pre-extract original packet function because the new IP header added to A2A VPN packets is the same as the raw IP header.
  • Packet encapsulation and decapsulation may result in transmission delay and consume network bandwidth; therefore, A2A VPN requires differentiated services to shorten the transmission delay, reduce the packet loss ratio, and maximize bandwidth. Classify A2A VPN packets into a QoS group to provide differentiated services for A2A VPN packets in the QoS group.
Figure 6-8 shows the procedure for configuring QoS.
Figure 6-8  Procedure for configuring QoS

For details on QoS, see "MQC Configuration" in Huawei AR Series V200R010 Configuration Guide - QoS.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec policy policy-name seq-number gdoi

    The GDOI policy view is displayed.

  3. Configure the QoS function for A2A VPN.

    • Run qos pre-classify

      The device is configured to pre-extract original packet information.

      By default, the device does not pre-extract original packet information.

    • Run qos group qos-group-value

      A QoS group is configured for A2A VPN packets.

      By default, A2A VPN packets do not belong to a QoS group.

Follow-up Procedure

  • After configuring the pre-extract original packet function, you need to run the if-match acl { acl-number | acl-name } command in the traffic classifier view to create ACL-based matching rules.

  • After adding A2A VPN packets to a QoS group, you need to run the if-match qos-group qos-group-value command in the traffic classifier view to create QoS group-based matching rules.

(Optional) Configuring A2A VPN Multi-Link Sharing

Context

To improve network reliability, a GM is connected to a KS through multiple egress links for link backup or load balancing. When the same A2A VPN protection method is used on multiple outbound interfaces to ensure smooth service switchover, these outbound interfaces register with the KS independently and negotiate to generate their own KEK SA. If a large number of GMs need to be connected to the KS, the KS will become heavily loaded.

To reduce the load on the KS, configure a GDOI policy as a multi-link shared security policy. GMs then register with the KS through loopback interfaces and negotiate to generate one KEK SA. In this situation, multiple interfaces to which the GDOI policy is applied share one KEK SA. That is, multiple links share one KEK SA.

NOTE:

One loopback interface maps to only one multi-link shared security policy.

A GM can select an outbound interface according to a route to negotiate with the KS for a KEK SA as long as the loopback interface of the GM is routable to the KS.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec policy policy-name shared local-interface loopback interface-number

    A GDOI policy is configured as a multi-link shared security policy.

    By default, no GDOI policy is configured as a multi-link shared security policy.

(Optional) Configuring Fragmentation Before Encryption

Context

After packets are encapsulated in A2A VPN, the packet length may exceed the maximum transmission unit (MTU) allowed by the device outbound interface. In this case, you need to fragment the packets to prevent packet loss. Two methods are available to fragment packets:

  • Fragmentation before encryption: Before encapsulating A2A VPN packets, the encryption device calculates the predicted length of the encapsulated packets. If the predicted length of the encapsulated packets exceeds the MTU of the outbound interface, the device fragments the A2A VPN packets and then encapsulates the fragmented packets. In this case, the terminal host decrypts and assembles A2A VPN fragments. This reduces the CPU usage of the peer decryption device.

  • Fragmentation after encryption: If the size of the encapsulated A2A VPN packets exceeds the MTU of the outbound interface, the encryption device fragments the packets based on the MTU of the outbound interface. In this case, the peer decryption device assembles and decrypts A2A VPN fragments and then sends decrypted packets to the terminal host.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec df-bit { clear | set | copy }

    The Don't Fragment (DF) flag bit is configured for A2A VPN packets, indicating whether packets can be fragmented.

    By default, the DF flag bit in A2A VPN is the flag bit of original packets.

    Only after clear is specified to allow packet fragmentation, the following command takes effect.

  3. Run ipsec fragmentation before-encryption

    The fragmentation mode of packets is set to fragmentation before-encryption.

    By default, packets are fragmented after being encrypted.

Applying a GDOI Policy Group to an Interface

Context

A GDOI policy group is a collection of security policies with the same name but different sequence numbers. In a GDOI policy group, a GDOI policy with a smaller sequence number has a higher priority.

To protect data flows on an interface through A2A VPN, you need to apply a GDOI policy group to the interface. If the GDOI policy group is deleted from the interface, the interface no longer provides the A2A VPN protection function.

When sending a data flow, an interface matches the data flow with the GDOI policies in the GDOI policy group in ascending order of sequence numbers. If the data flow matches a local ACL referenced in a GDOI policy, the interface forwards the data flow in plain text; if the data flow does not match any local ACL, the interface matches the data flow with the ACLs downloaded from the KS; if the data flow does not match any ACL downloaded from the KS, the interface forwards the data flow in plain text by default.

NOTE:

Only one GDOI policy group can be applied on an interface. A GDOI policy group can be applied to only one interface.

In a GDOI policy group, if multiple policies are bound to different IKE peers, the remote addresses specified in the IKE peers cannot be the same. Otherwise, IKE negotiation of some GDOI policies fails.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-type interface-number

    The interface view is displayed.

  3. Run ipsec policy policy-name

    A GDOI policy group is applied to the interface.

    By default, no GDOI policy group is applied to an interface.

Verifying the GM Configuration

Prerequisites

All A2A VPN configurations are complete.

Procedure

  • Run the display ike peer [ brief | name peer-name ] command to check information about the IKE peer.
  • Run the display ike proposal [ number proposal-number ] command to check parameters in the IKE proposal.
  • 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 ipsec gdoi-sa [ policy-name [ seq-number ] ] command to check information about the GDOI SA.
  • Run the display ipsec gdoi-policy [ policy-name [ seq-number ] ] command to check information about GDOI policies.
Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100033725

Views: 143593

Downloads: 361

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