Configure a Router with IPSec Using Pre-shared Keys
Step 3 – Create crypto ACLs

Crypto access lists are used to define which IP traffic will be protected by IPSec and which traffic will not be protected by IPSec . These access lists are not the same as regular access lists, which determine what traffic to forward or block at an interface. For example, A crypto access list can be created to protect all IP traffic between two subnets or Telnet traffic between two individual hosts.

The access lists themselves are not specific to IPSec. It is the crypto map entry referencing the specific access list that defines whether IPSec processing is applied to the traffic matching a permit statement in the access list.

If certain traffic is to receive one combination of IPSec protection, such as authentication only, and other traffic is to receive a different combination of IPSec protection, such as both authentication and encryption, two different crypto access lists must be created to define the two different types of traffic. These different access lists are then used in different crypto map entries which specify different IPSec policies.

To create crypto access lists, use the access-list command in global configuration mode . Although the ACL syntax is unchanged, the meanings are slightly different for crypto ACLs. The permit keyword specifies that matching packets must be encrypted. deny specifies that matching packets need not be encrypted. Any unprotected inbound traffic that matches a permit entry in the crypto ACL for a crypto map entry flagged as IPSec will be dropped, because this traffic was expected to be protected by IPSec.

Cisco recommends that the any keyword be avoided. The permit any any statement is strongly discouraged, as this will cause all outbound traffic to be protected, and will require protection for all inbound traffic. All inbound packets that lack IPSec protection will be silently dropped, including packets for routing protocols, NTP, echo, echo response, and so on.

Try to be as restrictive as possible when defining the traffic to protect in a crypto ACL. If the any keyword must be used in a permit statement, that statement must be prefaced with a series of deny statements to filter out any traffic that should not be protected that would otherwise fall within that permit statement.

In a later step, the crypto ACL will be applied to a crypto map, which in turn is assigned to a specific interface.

Defining Mirror Image Crypto Access Lists at Each IPSec Peer
Cisco recommends that for every crypto access list specified for a static crypto map entry that is defined at the local peer, a symmetrical, or mirror image, crypto access list is configured at the remote peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. The crypto map entries themselves must also support common transforms and must refer to the other system as a peer.

Both inbound and outbound traffic is evaluated against the same outbound IPSec ACL. The criteria of the ACL are applied in the forward direction to traffic when exiting a router, and the reverse direction to traffic when entering a router. When a router receives encrypted packets back from an IPSec peer, it uses the same ACL to determine which inbound packets to decrypt by viewing the source and destination addresses in the ACL in reverse order.

The example shown in Figure illustrates why symmetrical ACLs are recommended. For site 1, IPSec protection is applied to traffic between hosts on the 10.0.1.0 network as the data exits the s0 interface of Router A when the destination is one of the site 2 hosts on the 10.0.2.0 network. For traffic from site 1 hosts on the 10.0.1.0 network to site 2 hosts on the 10.0.2.0 network, the ACL entry on Router A is evaluated as follows:

  • source = hosts on 10.0.1.0 network
  • destination = hosts on 10.0.2.0 network

For incoming traffic from site 2 hosts on the 10.0.2.0 network to site 1 hosts on the 10.0.1.0 network, that same ACL entry on Router A is evaluated as follows:

  • source = hosts on 10.0.2.0 network
  • destination = hosts on 10.0.1.0 network