Cisco Systems CL-28826-01 Security Camera User Manual


  Open as PDF
of 2616
 
28-9
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Understanding the GET VPN Registration Process
The reason deny works this way in fail-close mode is because fail-close includes an implicit
ACL statement that gets added at the bottom of the list of crypto map ACLs. This statement is
permit ip any any, which matches all traffic. Because there is no IPsec security association due
to the fact that registration has yet to occur, there is no way to encrypt the remaining traffic and
it is dropped.
Note that because of this final permit ip any any statement, you might be able to limit yourself
to deny statements in your fail-close ACL.
The fail-close ACL is processed sequentially after the optional group member security policy ACL.
However, all statements in the group member security policy ACL must be deny statements, which
indicate that matching traffic should be sent in clear text. Because the security policy is processed
according to normal crypto map rules, traffic that matches deny statements is subsequently
compared to the fail-close ACL. If the fail-close ACL does not have matching deny statements, the
traffic will subsequently be dropped by the implicit final fail-close permit ip any any statement.
Therefore, if you use a group member security policy ACL, and you want the identified traffic to be
sent in clear text regardless of the registration status of the group member, your fail-close ACL
should contain all of the same statements contained in the security policy ACL at the least. It might
even be possible to use the same ACL object for both ACLs.
For more information about group member security policies, see Understanding the GET VPN
Security Policy and Security Associations, page 28-10.
The fail-close ACL is inserted as the final crypto map ACL. Thus, if you configure other features on
the GET VPN interface that use crypto maps, any traffic identified on deny statements in those other
ACLs will also get trapped (and dropped) by the fail-close ACL and the implicit final permit ip any
any statement. Thus, configuring fail-close mode for GET VPN can influence the non-GET VPN
services you configure on the interface.
Upon successful registration, the fail-close ACL and the implicit final permit ip any any statement
are removed from the crypto maps. These policies are not persistent.
You should consider including the following rules in the fail-close ACL policy object. Remember
that these rules are from the perspective of the group member:
SSH, SSL (HTTPS) traffic—You, and Security Manager, need to be able to access the device to
configure it. To ensure that you do not lock down the device, include deny statements for SSH
and SSL. For SSH, deny tcp any eq 22 <host or network address>. For SSL, deny tcp any
eq 443 <host or network address>. If you specify host addresses, ensure that the Security
Manager server is one of the hosts.
Routing traffic—To enable routing, allow the traffic for your routing process. For example, if
you are using OSPF, deny ospf any any.
GDOI traffic—Regardless of the contents of the fail-close ACL, the device looks for GDOI
registration messages, so you do not need to explicitly allow them to enable successful
registration. However, if a group member (1) is in the path between the key server and another
group member (2), a registration failure by group member (1) will prevent successful
registration by the blocked group member (2). For registration on group member (2) to succeed,
the fail-close ACL on group member (1) would have to allow GDOI traffic to pass. Thus, you
might want to make it a general practice to allow GDOI traffic in the fail-close ACL: deny udp
any eq 848 any eq 848.
Related Topics
Configuring GET VPN, page 28-12
Creating Access Control List Objects, page 6-49
Creating Extended Access Control List Objects, page 6-50