Step 3-3 Configure Crypto ACLs
Access lists, specifically crypto ACLs, play a substantial
roll in how IPSec processes data flows. Crypto ACLs perform the following
functions:
-
Define the data flow to be protected by IPSec (permit
statements).
-
Define the data flow to pass unprotected by IPSec (deny
statements).
-
Check outbound traffic to see if it should be protected by
IPSec.
-
Check inbound traffic to discard traffic that should have
been protected by IPSec. The assumption is if it’s unprotected, it isn’t from
the source.
-
Determine whether to accept requests for IPSec SAs for
requested data flows when processing IKE negotiations.
Only extended IP ACLs can be used to create crypto ACLs. These
extended IP ACLs select the IP traffic to encrypt by protocol, IP address,
network, subnet, and port. While the basic ACL syntax is unchanged, the result
is slightly different for crypto ACLs. Crypto ACLs are only deciding which
traffic to protect and which to allow access through unprotected. A permit statement means the matching packet must be
protected, while a deny statement means the matching
packet needn’t be protected. Any actual packet filtering must be done with
another ACL. The crypto ACL determines only if the packet
is protected. The level and type of protection is determined by the IKE and
IPSec SAs.
Allowing one type of data traffic to receive one combination of
IPSec protection is possible—such as authentication only—and other traffic to
receive a different combination, such as both authentication and encryption. To
do this, you must create two different crypto ACLs to define each of the two
different types of traffic. The resulting ACLs are then used in different crypto
map entries defining the different IPSec policies.
Using the Any Keyword
Cisco strongly recommends avoiding the any
keyword for specifying source or destination addresses whenever possible. A
permit any any statement causes all outbound traffic to be protected and
discards any unprotected inbound traffic, including packets for routing
protocols, NTP, echo, echo response, and so forth.
If using the any keyword in a permit
statement is unavoidable, be sure to precede the statement with as many deny
statements as necessary to identify any traffic to be allowed through
unprotected.
Mirrored ACLs
The same outbound IPSec ACL that determines which outbound
traffic will be protected by IPSec is also used to “catch” noncompliant inbound
traffic. For example, if all TCP traffic is to be protected, then any
unprotected inbound TCP traffic must have been introduced at some point other
than the IPSec source. This is both an elegant and a simple system, but it
relies on having ACLs at each end, which are virtually mirror images of each
other. This means the source addresses/ports and destination addresses/ports are
literally reversed on the peer.
In the following example, using the chapter scenario, each peer
will protect outbound TCP traffic, discard any unprotected inbound TCP traffic,
and, because of the implicit deny any statement, each will allow all other
traffic to pass unprotected and unfiltered.
Rtr1(config)#access-list 125 permit tcp 192.168.0.0 0.0.127.255
192.168.130.0 0.0.0.255
Rtr2(config)#access-list 150 permit tcp 192.168.130.0 0.0.0.255
192.168.0.0 0.0.127.255
Compare that to the next example, where the Rtr1 Admin decided to
protect outbound UDP traffic without adding the same ACL statement to Rtr2. Now,
as requested, all outbound UDP traffic will be protected. But maybe what isn’t
expected is the inbound UDP traffic continues to be unprotected and, therefore,
mistaken as interlopers and discarded. While this is a somewhat glaring example
and would probably be noticed quite quickly, it’s an easy and troublesome
mistake to make when new protocols or services are added to a network.
Rtr1(config)#access-list 125 permit tcp 192.168.0.0 0.0.127.255
192.168.130.0 0.0.0.255
Rtr1(config)#access-list 125 permit udp 192.168.0.0 0.0.127.255
192.168.130.0 0.0.0.255
Rtr2(config)#access-list 150 permit tcp 192.168.130.0 0.0.0.255
192.168.0.0 0.0.127.255
In the next step, the crypto ACL is associated to a crypto
map assigned to a specific interface.
Sections
Comments (0 posted)
Syndication
