Configuring an ACL

IPsec uses ACLs to identify the traffic to be protected.

An ACL is a collection of ACL rules. Each ACL rule is a deny or permit statement. A permit statement identifies a data flow protected by IPsec, and a deny statement identifies a data flow that is not protected by IPsec. IPsec compares a packet against the ACL rules and processes the packet according to the first rule it matches.

• Each ACL rule matches both the outbound traffic and the returned inbound traffic. Suppose there is a rule rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255. This rule matches both traffic from 1.1.1.0 to 2.2.2.0 and traffic from 2.2.2.0 to 1.1.1.0.

• In the outbound direction, if a permit statement is matched, IPsec considers that the packet requires protection and continues to process it. If a deny statement is matched or no match is found, IPsec considers that the packet does not require protection and delivers it to the next module.

• In the inbound direction:

  • Non-IPsec packets that match a permit statement are dropped.

  • IPsec packets destined for the device itself are de-encapsulated. By default, the de-encapsulated packets are compared against the ACL rules. Only those that match a permit statement are processed. Other packets are dropped. If ACL checking for de-encapsulated IPsec packets is disabled, the de-encapsulated packets are not compared against the ACL rules and are directly processed by other modules.

When defining ACL rules for IPsec, follow these guidelines:

• Permit only data flows that need to be protected and use the any keyword with caution. With the any keyword specified in a permit statement, all outbound traffic matching the permit statement will be protected by IPsec. All inbound IPsec packets matching the permit statement will be received and processed, but all inbound non-IPsec packets will be dropped. This will cause all the inbound traffic that does not need IPsec protection to be dropped.

• Avoid statement conflicts in the scope of IPsec policy entries. When creating a deny statement, be careful with its match scope and match order relative to permit statements. The policy entries in an IPsec policy have different match priorities. ACL rule conflicts between them are prone to cause mistreatment of packets. For example, when configuring a permit statement for an IPsec policy entry to protect an outbound traffic flow, you must avoid the situation that the traffic flow matches a deny statement in a higher priority IPsec policy entry. Otherwise, the packets will be sent out as normal packets. If they match a permit statement at the receiving end, they will be dropped by IPsec.

The following example shows how an improper statement causes unexpected packet dropping. Only the ACL-related configuration is presented.

Assume Router A is connected to subnet 1.1.2.0/24 and Router B is connected to subnet 3.3.3.0/24, and the IPsec policy configuration on Router A and Router B is as follows:

• IPsec configuration on Router A:

  acl advanced 3000
   rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255
   rule 1 deny ip
  acl advanced 3001
   rule 0 permit ip source 1.1.2.0 0.0.0.255 destination 3.3.3.0 0.0.0.255
   rule 1 deny ip
  #
  ipsec policy testa 1 isakmp <---IPsec policy entry with a higher priority
   security acl 3000
   ike-profile aa
   transform-set 1
  #
  ipsec policy testa 2 isakmp <---IPsec policy entry with a lower priority
   security acl 3001
   ike-profile bb
   transform-set 1
  

• IPsec configuration on Router B:

  acl advanced 3001
   rule 0 permit ip source 3.3.3.0 0.0.0.255 destination 1.1.2.0 0.0.0.255
   rule 1 deny ip
  #
  ipsec policy testb 1 isakmp
   security acl 3001
   ike-profile aa
   transform-set 1
  

On Router A, apply the IPsec policy testa to the outbound interface of Router A. The IPsec policy contains two policy entries, testa 1 and testa 2. The ACLs used by the two policy entries each contain a rule that matches traffic from 1.1.2.0/24 to 3.3.3.0/24. The one used in the policy entry testa 1 is a deny statement and the one used in the policy entry testa 2 is a permit statement. Because testa 1 is matched prior to testa 2, traffic from 1.1.2.0/24 to 3.3.3.0/24 will match the deny statement and be sent as normal traffic. When the traffic arrives at Router B, the traffic matches rule 0 (a permit statement) in ACL 3001 used in the applied IPsec policy testb. Because non-IPsec traffic that matches a permit statement must be dropped on the inbound interface, Router B drops the traffic.

To make sure subnet 1.1.2.0/24 can access subnet 3.3.3.0/24, you can delete the deny rule in ACL 3000 on Router A.

To make sure SAs can be set up and the traffic protected by IPsec can be processed correctly between two IPsec peers, create mirror image ACLs on the IPsec peers. As shown in Figure 114, ACL rules on Router B are mirror images of the rules on Router A. In this way, SAs can be created successfully for the traffic between Host A and Host C and for the traffic between Network 1 and Network 2.

If the ACL rules on IPsec peers do not form mirror images of each other, SAs can be set up only when both of the following requirements are met:

• The range specified by an ACL rule on one peer is covered by its counterpart ACL rule on the other peer. As shown in Figure 115, the range specified by the ACL rule configured on Router A is covered by its counterpart on Router B.

• The peer with the narrower rule initiates SA negotiation. If a wider ACL rule is used by the SA initiator, the negotiation request might be rejected because the matching traffic is beyond the scope of the responder. As shown in Figure 115, the SA negotiation initiated by Host A to Host C is accepted but the SA negotiations from Host C to Host A, from Host C to Host B, and from Host D to Host A are rejected.

To use IPsec to protect the data of an MPLS L3VPN, you must specify the VPN instance for the protected data in the ACL.

As shown in Figure 116, to protect traffic of VPN1 by using IPsec, you must configure the ACL on Device A as follows:

#
acl advanced 3400
 rule 0 permit ip vpn-instance vpn1 source 1.1.1.0 0.0.0.255 destination 3.3.3.0 0.0.0.255
#

In addition, you must specify VPN1 as the inside VPN instance in the IKE profile.

#
ike profile vpn1
 keychain vpn1
 match remote identity address 8.8.8.1 255.255.255.255
 inside-vpn vpn-instance vpn1
#