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

Run system-view
The system view is displayed.
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.
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

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