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

S600-E V200R012C00 Configuration Guide - VPN

This document describes the configurations of VPN, including IPSec, MCE.
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 the Remote Device

Configuring the Remote Device

Defining Data Flows to Be Protected

Context

IPSec can protect one or more data flows, and the ACL specifies data flows to be protected by IPSec. Therefore, you need to create an ACL and apply the ACL to an IPSec policy.

ACL Keyword Usage

Each ACL rule is a deny or permit clause. In IPSec applications, a permit clause identifies a data flow protected by IPSec, and a deny clause identifies a data flow that is not protected by IPSec. An ACL can contain multiple rules. A packet is processed according to the first rule that it matches.

  • In the outbound direction of an SA

    If a packet matches a permit clause, IPSec encapsulates and sends the packet. If a packet matches a deny clause or does not match a permit clause, IPSec directly forwards the packet. A matched permit clause indicates that a data flow needs to be protected and a pair of SAs is created.

  • In the inbound direction of an SA

    The packet protected by IPSec is decrypted and the packet not protected by IPSec is forwarded.

Precautions

  • The protocols defined in the ACLs on both ends of the IPSec tunnel must be the same. For example, if the protocol on one end is IP, the protocol must also be IP on the other end.

  • When ACL rules at both ends of an IPSec tunnel mirror each other, SAs can be set up successfully no matter which party initiates negotiation. If ACL rules at both ends of an IPSec tunnel do not mirror each other, SAs can be set up successfully only when the range specified by ACL rules on the initiator is included in the range specified by ACL rules on the responder. It is recommended that ACL rules at both ends of an IPSec tunnel mirror each other. That is, the source and destination addresses of an ACL rule at one end are the destination and source addresses of an ACL rule at the other end. The IKEv1 and IKEv2 configurations are as follows:

    If IPSec policies in ISAKMP mode are configured at both ends, ACL rules at both ends of an IPSec tunnel must mirror each other. If an IPSec policy in ISAKMP mode is configured at one end and an IPSec policy using an IPSec policy template is configured at the other end, the range specified by ACL rules in the IPSec policy in ISAKMP mode can be included in the range specified by ACL rules in the IPSec policy using an IPSec policy template. The devices use overlapping ACL rules as the negotiation result.

  • Avoid overlapped address segments in ACL rules. Rules with overlapped address segments may affect each other, causing data flow mismatch.

  • The ACL referenced in an IPSec policy group cannot contain rules of the same ID.

  • ACL rules referenced in all IPSec policies of an IPSec policy group cannot overlap. In the following example, ACL 3001 and ACL 3002 overlap.

    acl number 3001
     rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
    
    acl number 3002
     rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255
    
  • When the responder uses an IPSec policy template, note the following points:

    If data flows to be protected are not specified, the responder accepts the range of data flows to be protected on the initiator. If data flows to be protected are specified, the ACL on the responder must mirror the ACL on the initiator or the range specified by the ACL on the responder must cover the range specified by the ACL on the initiator.

  • If NAT is configured on an interface to which an Efficient VPN policy is applied, IPSec may not take effect because NAT is performed first. You can use the following methods:

    • Configure the destination IP address that matches the deny clause in an ACL referenced by NAT as the destination IP address in an ACL rule referenced by IPSec. In this case, data flows protected by IPSec are not translated by NAT.

    • Configure the ACL rule referenced by NAT to match the IP address translated by NAT.

Procedure

  1. Run system-view

    The system view is displayed.

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

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

  3. Run the following commands as required.

    • Run the rule [ rule-id ] { deny | permit } ip [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | dscp dscp ] * 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 ] * 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 ] * 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 ] * 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 ] * command to configure a rule to match the GRE protocol.

Configuration Guidelines

The configurations of rules vary in different scenarios. For details, see the following examples:

Site-to-Site IPSec VPN

A site-to-site IPSec tunnel is set up between gateway A and gateway B. Gateway A protects subnet 10.1.1.0/24 and gateway B protects subnet 192.168.196.0/24.

Configurations on gateway A:

[HUAWEI] acl 3001       
[HUAWEI-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255          

Configurations on gateway B:

[HUAWEI] acl 3001       
[HUAWEI-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.1.0 0.0.0.255

Ensure that the subnets on both ends use the same wildcard.

IPSec Gateway with NAT Configured

  • If endpoint A uses NAT only for the Internet access, not for IPSec traffic, you must reject the IPSec traffic from NAT.

    Endpoint A protects network 10.1.1.0/24 and endpoint B protects network 192.168.196.0/24. The ACL and NAT configurations on endpoint A are as follows:

    # Define the data flow to be protected.

    [HUAWEI] acl 3001       
    [HUAWEI-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255          
    [HUAWEI-acl-adv-3001] quit
    
    # Exclude the networks connected by the IPSec tunnel from the ACL referenced in the NAT policy.
    [HUAWEI] acl 3005       
    [HUAWEI-acl-adv-3005] rule deny ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255          
    [HUAWEI-acl-adv-3005] quit
    

    Configurations on gateway B:

    [HUAWEI] acl 3001 
    [HUAWEI-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
    
  • If the two networks overlap, endpoint A performs NAT for all traffic and then performs IPSec.

    If the networks protected by endpoints A and B are both network 10.1.1.0/24, the private addresses are translated to 10.1.2.1, the configurations on endpoints A and B are as follows:

    On endpoint A:

    [HUAWEI] acl 3001       
    [HUAWEI-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
    [HUAWEI-acl-adv-3001] quit
    

    On endpoint B:

    [HUAWEI] acl 3001       
    [HUAWEI-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
    [HUAWEI-acl-adv-3001] quit
    

Establishing an IPSec Tunnel Based on Efficient VPN Policies

Context

Only mandatory parameters, such as the Efficient VPN server IP address and pre-shared key, need to be configured on a remote device. Other parameters, such as authentication and encryption algorithms used in IKE negotiation, and the IPSec proposal, are preconfigured on the Efficient VPN server.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec efficient-vpn efficient-vpn-name [ mode { client | network | network-plus } ]

    An Efficient VPN policy in client mode is created and the Efficient VPN policy view is displayed.

    By default, no Efficient VPN policy is created in the system.

    NOTE:

    When IKEv2 is used, the device does not support the network-plus parameter.

  3. Run security acl acl-number

    An ACL is referenced in the IPSec Efficient VPN policy.

    By default, no ACL is referenced.

    acl-number is an advanced ACL that has been created.

    If an ACL is referenced, the rule can only match IP packets, that is, permit ip.

    The remote device in client mode applies to the headquarters for an IP address to establish an IPSec tunnel with the Efficient VPN server. The source address in packets sent from the branch to the headquarters is the requested IP address, so ACLs are not required.

  4. Run remote-address { ip-address | host-name host-name } { v1 | v2 }

    A peer address or a domain name in IKE negotiation is configured.

    By default, no IP address or domain name is configured for the remote IKE peer during IKE negotiation.

    To improve network reliability, two devices can be deployed at the headquarters to connect to the branch gateway. In an IPSec policy, two IP addresses or domain names of the remote IKE peer can be configured on the branch gateway. The branch gateway first attempts to use the first configured IP address or domain name to establish an IKE connection with the headquarters gateway. If establishing an IKE connection fails, the branch gateway uses the second IP address or domain name to establish an IKE connection.

  5. Run pre-shared-key { simple | cipher } key

    A pre-shared key is configured.

    By default, no pre-shared key is configured on IKE peers.

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

    If simple is used, passwords are saved in the configuration file in plain text, resulting in security risks. Therefore, cipher is recommended to save passwords in cipher text.

  6. Run dh { group1 | group2 | group5 | group14 }

    A Diffie-Hellman group used in IKE negotiation is configured.

    By default, group14 is used in IKE negotiation.

    The security levels of the following Diffie-Hellman groups are in descending order of priority: group14 > group5 > group2 > group1.

    You are advised not to use group1, group2, or group5; otherwise, security defense requirements may be not met.

  7. (Optional) Run local-id-type { fqdn | ip | key-id | 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.

    • ip: The IP address is configured by running the tunnel local command.
    • key-id: When the device functions as the remote end to communicate with a Cisco device in the Efficient VPN policy, you need to specify the key-id parameter in the command. Meanwhile, you also need to run the service-scheme command to specify the service scheme that the Cisco device uses.
    • fqdn or user-fqdn: The FQDN or User-FQDN is configured by running the ike local-name local-name command in the system view.

  8. (Optional) Run remote-id id

    The remote ID for IKE negotiation is configured.

    By default, the remote ID for IKE negotiation is not configured.

  9. (Optional) Run service-scheme service-scheme-name

    A server-end service scheme is configured in an Efficient VPN policy.

    By default, no server-end service scheme is configured in an Efficient VPN policy.

    If an AAA service scheme is configured in the Efficient VPN policy, you need to specify AAA the service scheme configured on the server before the server can authorize the remote device. Meanwhile, you also need to specify the key-id parameter in the local-id-type command. If the key-id parameter is not specified, the configuration does not take effect. If authorization is performed using the service scheme used on the server, this step is not required.

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

    A local IP address is configured.

    By default, the local IP address is not configured.

    Generally, you do not need to configure a local IP address for an IPSec policy established in IKE negotiation mode. During SA negotiation, the device selects the local IP address according to a route.
    • If the IP address of an interface bound to an IPSec policy is variable or unknown, run the tunnel local ip-address command to specify the IP address of another interface such as a loopback interface as the local IP address or run the tunnel local applied-interface command to specify an interface IP address 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 tunnel local ip-address command to specify one IP address as the local IP address or run the tunnel local applied-interface command to specify the primary IP address of the interface as the local IP address.
    • If the local and remote ends have equal-cost routes, run the tunnel local { ip-address | applied-interface } command to specify the local IP address so that IPSec packets can be sent out from the specified interface.

  11. (Optional) Run pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 }

    The device is configured to use Perfect Forward Secrecy (PFS) in IPSec negotiation.

    By default, PFS is not used in IPSec negotiation.

    To improve the security of communication, you can configure the PFS to perform an additional DH exchange in the IKEv1 phase 2 or IKEv2 CREATE_CHILD_SA exchange. The additional DH exchange ensures security of the IPSec SA key.

  12. (Optional) Run re-authentication interval interval

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

(Optional) Setting the IPSec SA Lifetime

Context

NOTE:

The configured IPSec SA lifetime is only valid for the new IPSec SAs established in IKE negotiation mode.

For a dynamic SA, configure the SA hard lifetime so that the SA can be updated in real time, reducing the crash risk and improving security.

There are two methods to measure the lifetime:
  • Time-based lifetime

    The period from when an SA is set up to when the SA is expired.

  • Traffic-based lifetime

    The maximum volume of traffic that this SA can process.

The lifetime is classified as follows:
  • Hard lifetime: specifies the lifetime of an IPSec SA.

    When two devices negotiate an IPSec SA, the actual hard lifetime is the smaller of the two values configured on the two devices.

  • Soft lifetime: specifies the time after which a new IPSec SA is negotiated so that the new IPSec SA will be ready before the hard lifetime of the original IPSec SA expires.

    Table 2-8 lists the default soft lifetime values.
    Table 2-8  Soft lifetime values
    Soft Lifetime Type Description
    Time-based soft lifetime (soft timeout period)

    The value is 7/10 of the actual hard lifetime (hard timeout period).

    Traffic-based soft lifetime (soft timeout traffic)

    The value is 7/10 of the actual hard lifetime (hard timeout traffic).

Before an IPSec SA becomes invalid, IKE negotiates a new IPSec SA for the remote end. The remote end uses the new IPSec SA to protect IPSec communication immediately after the new IPSec SA is negotiated. If service traffic is transmitted, the original IPSec SA is deleted immediately. If no service traffic is transmitted, the original IPSec SA will be deleted after 10s or the hard lifetime expires.

If the time-based lifetime and traffic-based lifetime are both set for an IPSec SA, the IPSec SA becomes invalid when either lifetime expires.

Procedure
  1. Run system-view

    The system view is displayed.

  2. Run ipsec sa global-duration { time-based interval | traffic-based size }

    The global IPSec SA hard lifetime is set.

    By default, the global time-based SA hard lifetime is 3600 seconds and the global traffic-based SA hard lifetime is 1843200 Kbytes.

(Optional) Enabling the Anti-replay Function

Context

NOTE:

To ensure non-stop service forwarding, the configured IPSec anti-replay window size takes effect only for new or re-negotiated IPSec policies but not for existing ones.

Replayed packets are packets that have been processed. IPSec uses the sliding window (anti-replay window) mechanism to check replayed packets. Each AH or ESP packet has a 32-bit sequence number. In an SA, sequence numbers of packets increase. If the sequence number of a received authenticated packet is the same as that of a decapsulated packet or if the sequence number is out of the sliding window, the device considers the packet as a replayed packet.

Decapsulating replayed packets consumes many resources and makes system performance deteriorate, resulting in a Denial Of Service (DoS) attack. After the anti-replay function is enabled, the system discards replayed packets and does not encapsulate them, saving system resources.

In some situations, for example, when network congestion occurs or QoS is performed for packets, the sequence numbers of some service data packets may be different from those in common data packets. The device that has IPSec anti-replay enabled considers the packets as replayed packets and discards them. You can disable global IPSec anti-replay to prevent packets from being discarded incorrectly or adjust the IPSec anti-replay window size to meet service requirements.

The anti-replay function can be configured globally or in an IPSec policy or profile:
  • Configuring the anti-replay function globally

    The global anti-replay function is valid for all existing IPSec policies. When the same anti-replay window parameters need to be set for many IPSec policies, you do not need to run commands one by one. You only need to set global parameters. The configuration efficiency is therefore improved.

  • Configuring the anti-replay function in an Efficient VPN policy

    The anti-replay function can be configured separately for an Efficient VPN policy. In this case, the anti-replay function for the IPSec policy is not affected by the global configuration.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Enable the anti-replay function. Run the following commands as required.

    • Enable the anti-replay function globally.

      1. Run ipsec anti-replay enable

        The anti-replay function is enabled globally.

      2. Run ipsec anti-replay window window-size

        The global IPSec anti-replay window size is configured.

        By default, the global IPSec anti-replay window size is 1024 bits.

    • Enable the anti-replay function in an Efficient VPN policy.

      1. Run ipsec efficient-vpn efficient-vpn-name [ mode { client | network | network-plus } ]

        An Efficient VPN policy is created and the Efficient VPN policy view is displayed.

      2. Run anti-replay window window-size

        The IPSec anti-replay window size is configured in the IPSec policy.

        By default, the anti-replay window size of a single IPSec tunnel is not set. The global value is used.

(Optional) Configuring DSCP Priority for IKE Packets

Context

IKE packets are used to negotiate IKE SAs and IPSec SAs or used for Deal Peer Detection (DPD). If IKE packets are lost during transmission, problems such as failures to negotiate IKE SAs and IPSec SAs may occur. As a result, packets cannot be protected by IPSec SAs. To solve these problems, ensure that network devices process IKE packets before service packets.

You can increase IKE packet priority by specifying the DSCP priority for IKE packets. This configuration ensures that IKE packets are processed in time on a busy network, improving transmission reliability of IKE packets.

Procedure
  1. Run system-view

    The system view is displayed.

  2. Run ike dscp dscp-value

    The DSCP priority of IKE packets is configured globally.

    By default, the global DSCP priority of IKE packets is 0.

(Optional) Configuring NAT Traversal

Context

During IPSec VPN deployment, the initiator on a private network may need to establish an IPSec tunnel with the responder on a public network. To ensure that an IPSec tunnel can be established when a network address translation (NAT) device exists, NAT traversal is required, as shown in Figure 2-19.

Figure 2-19  NAT traversal in IPSec

During Encapsulating Security Payload (ESP) integrity check, an outer IP header is not checked. If only address translation is performed, ESP can work properly. ESP is a Layer 3 protocol and does not support port setting, so there is also a problem in ESP when NAT port translation is used. To address this issue, NAT traversal encapsulates ESP packets with a UDP header. In transport mode, a standard UDP header is inserted between the original IP header and an ESP header during NAT traversal. In tunnel mode, a standard UDP header is inserted between the new IP header and an ESP header during NAT traversal. When ESP packets pass through a NAT device, the NAT device translates the IP address and port number of the outer IP header and inserted UDP header. After the translated packets reach the remote end of the IPSec tunnel, the remote end processes these packets in the same manner as IPSec packets.

If no IPSec packets are transmitted on an IPSec tunnel in a period of time, NAT session entries may be aged out and deleted because the NAT session entries have the keepalive time. As a result, the IPSec tunnel cannot transmit IPSec packets between the NAT device and the IKE peer connected to the public network. To prevent NAT session entries from being aged, an IKE SA on the private network side of the NAT device sends NAT Keepalive packets to its remote end at an interval to maintain the NAT session.

NOTE:

By default, NAT traversal is enabled.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ike nat-keepalive-timer interval interval

    The interval for sending Keepalive packets is set.

    By default, the interval for sending NAT Keepalive packets is 20 seconds.

(Optional) Enabling Dependency Between IPSec SA and IKE SA During IKEv1 Negotiation

Context

By default, no dependency exists between IPSec SA and IKE SA, that is, the two SAs can be deleted separately. If the IKE SA is deleted but the corresponding IPSec SA still exists, traffic forwarding will be effected. You can enable dependency between IPSec SA and IKE SA to ensure that an IPSec SA is deleted when its corresponding IKE SA is deleted.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ikev1 phase1-phase2 sa dependent

    Dependency between IPSec SA and IKE SA during IKEv1 negotiation is enabled.

    By default, no dependency exists between IPSec SA and IKE SA during IKEv1 negotiation.

(Optional) Configuring IPSec VPN Multi-instance

Context

When multiple branches connected to the headquarters network across the Internet using IPSec, you can configure IPSec VPN Multi-instance, thereby isolating traffic of different branches.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec efficient-vpn efficient-vpn-name [ mode { client | network | network-plus } ]

    An Efficient VPN policy is created and the Efficient VPN policy view is displayed.

  3. Run sa binding vpn-instance vpn-instance-name

    A VPN instance is bound to an IPSec tunnel.

    By default, no VPN instance is bound to an IPSec tunnel.

    The VPN instance specified by vpn-instance-name must have been created using the ip vpn-instance command, and must be the same as the VPN instance bound to the ACL that is referenced by an IPSec policy.

(Optional) Configuring Heartbeat Detection to Detect the IKE Peer Status

Context

Heartbeat detection enables the local end to periodically send heartbeat packets to the remote end. If the local end does not receive heartbeat packets within the timeout interval, the local end considers the remote end as unreachable and deletes the IKE SA or IPSec SA between IKE peers.

There are limitations on heartbeat detection:
  • Enabling heartbeat detection will consume CPU resources used to process IKE keepalive messages, so the number of established IPSec sessions is limited.
  • There are no uniform standards, so devices from different vendors may fail to interwork.

The interval at which heartbeat packets are sent at the local end must be used with the timeout interval of heartbeat packets at the remote end. If the remote end does not receive any heartbeat packet within the timeout interval and the IKE SA carries a timeout tag, the IKE SA and its corresponding IPSec SA are deleted. If the IKE SA does not carry a timeout tag, it is marked as timeout.

NOTE:

If IKE peers use IKEv1 during negotiation, the device supports heartbeat detection. If IKE peers use IKEv2 during negotiation, the device does not support heartbeat detection.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ike heartbeat { seq-num { new | old } | spi-list }

    Parameters of heartbeat packets are set.

    By default, a heartbeat packet uses old type sequence number mechanism and does not carry the SPI list.

  3. Run ike heartbeat-timer interval interval

    The interval at which heartbeat packets are sent by an IKE SA is set.

    By default, an IKE SA does not send heartbeat packets.

  4. Run ike heartbeat-timer timeout seconds

    The timeout interval of heartbeat packets is set.

    By default, the timeout interval during which an IKE SA waits for a heartbeat packet is not configured.

    When ike heartbeat-timer interval is configured at one end, the ike heartbeat-timer timeout command must be used at the other end.

    The timeout interval of heartbeat packets must be longer than the interval at which heartbeat packets are sent. Generally, packet loss does not occur for more than three consecutive times on a network. Therefore, it is recommended that the timeout interval of heartbeat packets be three times the interval at which heartbeat packets are sent.

(Optional) Configuring DPD to Detect the IKE Peer Status

Context

In IPSec communication, heartbeat detection technology detects faults at the remote end and prevents packet loss. However, periodically sending heartbeat messages consumes CPU resources at both ends and limits the number of established IPSec sessions.

Dead Peer Detection (DPD) technology sends DPD packets based on IPSec packets between IKE peers, and does not periodically send heartbeat packets. When the local end can receive IPSec traffic from the remote end, the local end considers the remote end as active. The local end sends DPD packets to detect the status of the remote end when the local end does not receive IPSec traffic from the remote end within a given period of time. If the local end does not receive response packets after sending DPD packets several times, the local end considers the remote end as unreachable and deletes the IKE SA or IPSec SA between IKE peers.

If heartbeat detection is used, the two ends periodically send heartbeat packets and settings at the two ends must match. If DPD is used, settings except the payload sequence in DPD packets at the two ends do not need to match. When IPSec packets are exchanged between IKE peers, DPD packets are not sent. DPD packets are sent only when one end does not receive IPSec packets from the other end in a period of time. This saves resources.

NOTE:

When both heartbeat detection and DPD are used, DPD takes effect.

If the local end does not receive a DPD response packet from the remote end within the DPD packet retransmission interval, the local end retransmits the DPD request packet. If the local end still does not receive a DPD response packet after the DPD packet retransmission count is reached, the local end considers that the remote end goes offline, and deletes the IKE SA and IPSec SA.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ipsec efficient-vpn efficient-vpn-name [ mode { client | network | network-plus } ]

    An Efficient VPN policy is created and the Efficient VPN policy view is displayed.

  3. Run dpd msg { seq-hash-notify | seq-notify-hash }

    The payload sequence of DPD packets on an IKE peer is configured.

    By default, the payload sequence of DPD packets on an IKE peer is seq-notify-hash.

    The two ends must use the same sequence of the payload in DPD packets; otherwise, DPD does not take effect.

Applying an Efficient VPN Policy to an Interface

Context

To use IPSec to protect data flows on an interface, apply an Efficient VPN policy to the interface. After an Efficient VPN policy is unbound from an interface, the interface does not provide IPSec protection.

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 efficient-vpn efficient-vpn-name

    The Efficient VPN policy is applied to the interface.

    By default, no Efficient VPN policy is applied to an interface.

Translation
Download
Updated: 2018-09-01

Document ID: EDOC1100037956

Views: 2527

Downloads: 7

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