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