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

NE20E-S2 V800R010C10SPC500 Configuration Guide - Security 01

This is NE20E-S2 V800R010C10SPC500 Configuration Guide - Security

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).
Defining Data Flows to Be Protected

Defining Data Flows to Be Protected

IPsec can protect different data flows. In practice, you need to define data flows through ACL and quote the ACL in the security policy. Therefore, data flows are protected.

Context

Data flows to be protected are defined through advanced ACLs. For data flows that require different security levels, different advanced ACLs must be created.

According to ACL rules, IPSec identifies which packets need or do not need security protection. Data flows matching advanced ACLs (permit) are protected and sent after being processed by IPSec. Data flows that do not match advanced ACLs are dropped directly. Data flows that need to be encrypted but actually not are considered as attack data flows and discarded.

Procedure

  1. Run system-view

    The system view is displayed.

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

    The advanced ACL view is displayed.

  3. Run rule

    Configure a rule for the advanced ACL.

    Pay attention to the following items:
    • It is recommended that you configure symmetrical ACL rules at two ends. Symmetrical ACL rules at two ends are not essential but are easier and not prone to errors in actual applications.

    • An IPSec policy can only quote one ACL. The original configuration must be deleted when a new ACL is quoted.
    • An ACL cannot include rules containing the deny keyword.
    • ACLs configured in the same security policy group cannot include the same rules.
    • Rules in an ACL can match data flows according to the source or destination IP address, source or destination port, and protocol number only.
    NOTE:

    When multiple initiators negotiate with the same responder, the ACL rules of each initiator cannot overlap those of any other initiator.

    When the IKEv1 negotiation is started, the source/destination IP address and source/destination port defined in the ACL rule for the initiator must fall into the range specified in the ACL rule for the responder. Otherwise, the IKEv1 negotiation fails.

    During the IKEv2 negotiation, intersection ACL rules are adopted. If multiple rules are defined in an ACL, the rule that is defined first is used preferentially.

    IPSec processes the data stream to be protected as follows:

    • If packets match the ACL rule with the permit action, the packets are encrypted and sent to the peer end through tunnels.

    • If packets match no ACL rule, the packets are dropped.

    • If an ACL that does not really exist or an ACL in which no rule is defined applies to a security policy, the packets are dropped.

    • To configure the source and destination port numbers in the ACL of the protected data flow, you must use the eq parameter, rather than the lt, gt, range, and neq parameters.

  4. Run commit

    The configuration is committed.

Translation
Download
Updated: 2019-01-02

Document ID: EDOC1100055397

Views: 25966

Downloads: 52

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next