Cisco Ccnp Security Training

Table of Contents Chapter 1 Evaluating the Cisco ASA VPN Subsystem .......................................3 Chapter 2 Deploying Cisco ASA IPsec VPN Solutions ............................. 42 Chapter 3 Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions..............................109 Chapter 4 Deploying Clientless RemoteAccess SSL VPN Solutions ................148 Chapter 5 Deploying Advanced Cisco ASA VPN Solutions .............................184

CCNP Security VPN 642-648 Quick Reference

Cristian Matei

ciscopress.com

[2] CCNP Security VPN 642-648 Quick Reference

About the Author
Cristian Matei, CCIE No. 23684, is a senior security consultant for Datanet Systems, Cisco Gold Partner in Romania. He has designed, implemented, and maintained multiple large enterprise networks, covering the Cisco security, routing, switching, service provider, and wireless portfolios of products. Cristian started this journey back in 2005 with Microsoft technology and ﬁnished the MCSE Security and MCSE Messaging tracks. He then joined Datanet Systems, where he quickly obtained his Security and Routing & Switching CCIE, among other certiﬁcations and specializations, such as CCNP, CCSP, and CCDP. Cristian has been a Cisco Certiﬁed Systems Instructor (CCSI) since 2007, teaching CCNA, CCNP, and CCSP curriculum courses. In 2009, he received a Cisco Trusted Technical Advisor (TTA) award and became certiﬁed as a Cisco IronPort Certiﬁed Security Professional (CICSP) on E-mail and Web. That same year, he started his collaboration with Internetwork Expert as a technical editor on the CCIE Routing & Switching and Security Workbook series. In 2010, he received his ISACA Certiﬁed Information Security Manager (CISM) certiﬁcation. He is currently preparing for Service Provider CCIE and CCDE tracks and can be found as a regular and active member on Internetwork Expert and Cisco forums.

About the Technical Editor
Sean Wilkins is an accomplished networking consultant for SR-W Consulting (http://www.sr-wconsulting.com) and has been in the ﬁeld of IT since the mid 1990s, working with companies such as Cisco, Lucent, Verizon, and AT&T. Sean currently holds certiﬁcations with Cisco (CCNP/CCDP), Microsoft (MCSE), and CompTIA (A+ and Network+). He also has a master’s of science degree in Information Technology with a focus in Network Architecture and Design, a master’s of science degree in Organizational Management, a master’s certiﬁcate in Network Security, a bachelor’s of science degree in Computer Networking, and an associate’s degree of Applied Science in Computer Information systems. In addition to working as a consultant, Sean spends a lot of his time as a technical writer and editor for various companies.

Dedications
To Bianca Mihaela, a beautiful and lovely girl who actually became my wife in 2010. Thank you for loving and supporting me throughout all these years. Your morning smile makes my day. To Petr Lapukhov from Internetwork Expert. His technical mentoring and level of knowledge are purely outstanding. I am still waiting for a book release from him; it should break all frontiers.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[3] CCNP Security VPN 642-648 Quick Reference

Chapter 1

Evaluating the Cisco ASA VPN Subsystem
This Quick Reference serves as a quick review for the VPN 642-647 v2.0 exam and is a great refresher for the virtual private network (VPN) technologies supported on the Cisco Adaptive Security Appliance (ASA). This book covers ASA VPN technologies by using the latest available release of Cisco ASA, which is 8.4(3), the latest version of Adaptive Security Device Manager (ASDM), which is 6.4(7), and the latest versions of Cisco AnyConnect Secure Mobility Client (3.0.x) and Cisco Secure Desktop (3.6.x). This is important to consider because ASA suffered major changes from a command-line interface (CLI) and functionality perspective starting with Version 8.3.x and AnyConnect starting with Version 3.0.x. This chapter reviews the basic functionalities of the ASA, examines how these might interact with VPN technologies, and covers some common configuration concepts generally applicable to all VPN scenarios.

Evaluating Cisco ASA Software Architecture
Overview
Cisco ASA was designed as a product to combine Cisco PIX firewalls and Cisco VPN concentrator functions and to add extra security functions built in to the proprietary operating system or through the addition of separate modules, such as Intrusion Prevention and Content Security. The hardware architectures were also engineered with performance, reliability, and scalability in mind. Cisco ASA and PIX run the same proprietary Finesse operating system until software Version 7.x. Starting with Version 8.x, the operating system code used on ASA differs and is based on the Linux kernel.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[4] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Within the ASA family itself, Cisco developed different hardware architectures for multiple levels of performance and service:
■ ■ ■ ■

Cisco ASA 5505 is the low-end platform for small businesses. Cisco ASA 5510, 5520, 5540, and 5550 use the same physical chassis and architecture, but distinct CPU and RAM, leading to performance differences, and are targeted for medium to large enterprises. Cisco ASA 5580-20 and 5580-40 have a totally different hardware layout and are targeted for Internet service providers (ISP) and datacenters; these models are now EOL/EOS (end of life/support). Cisco ASA 5585-X series, the newest products, were designed for large datacenters and campus environments and embrace the latest hardware architecture.

All Cisco ASA VPN solutions are supported and configured in the same way, regardless of the model, thus making this writing generally applicable. To fully understand the VPN functions available on Cisco ASA, you first need a basic understanding of how this platform manages traffic flow. Cisco ASA is built around a stateful packet-filtering engine that supports deep packet inspection at OSI Layer 7 through Application Inspection and Control (AIC). While the stateful packet filtering is performing intelligent traffic manipulation at OSI Layers 3 and 4, the AIC functionality analyzes the application layer for conformity with protocol standards and adherence to an acceptable use policy as dictated by configured rules. Multiple options exist as to controlling what and how traffic is managed when traversing the appliance:
■ ■ ■ ■ ■ ■

Interface security levels Routing Interface access control lists (ACL) Service policies controlled through MPF Network Address Translation (NAT) Security service modules (SSM)

Traffic destined to the ASA is handled by the control plane and is subject to a different set of rules.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[5] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Interface Security Levels Refresher
Security level, a mandatory configurable attribute of an interface, is a numeric value ranging from 0 to 100 and defines the trustworthiness of networks reachable via that interface. A value of 0 means it is least trusted, whereas a value of 100 means it is most trusted. On Cisco ASA, for an interface to pass traffic, the following conditions need to be satisfied:
■ ■ ■ ■

IP address and mask are conﬁgured. Logical name is conﬁgured. Security level is assigned. Interface must be enabled, removed from administratively down state. ciscoasa ciscoasa ciscoasa ciscoasa (conﬁg)# interface Ethernet0/1 (conﬁg-if)# ip address 192.1681.1 255.255.255.0 (conﬁg-if)# nameif inside (conﬁg-if)# security-level 90

The logical name works, by default, hand in hand with the security level, in that after it has been configured, there is also a default security level assigned to the interface:
■ ■

If the logical name conﬁgured is inside, the default security level assigned is 100. If the logical name conﬁgured has any other value (for example, outside), the default security level assigned is 0.

Based on the security levels assigned to interfaces, the following rules for passing traffic apply:
■ ■ ■

By default, trafﬁc from higher security level interfaces to lower security level interfaces is allowed; this is called outbound trafﬁc. By default, trafﬁc from lower security level interfaces to higher security level interfaces is denied. To pass it needs to be allowed in an access list applied inbound on the lower security level interface; this is called inbound trafﬁc. Trafﬁc between interfaces with same security level is by default denied and can be allowed to pass by enabling samesecurity-trafﬁc permit inter-interface globally on the appliance.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[6] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■

Trafﬁc entering the appliance via one interface and exiting it via the same interface, what is called a U-turn, is by default denied and can be allowed to pass by enabling same-security-trafﬁc permit intra-interface globally on the appliance.

Interface ACL Refresher
Cisco ASA supports both IPv4 and IPv6 access lists. You can apply ACLs both in the inbound and outbound direction of an interface, thus restricting traffic entering or exiting that interface. After an access list has been applied inbound/outbound on an interface, all traffic entering/exiting that interface is subject to the ACL entries, and security-level rules defined previously are simply ignored. Only the first packet in the Transfer Control Protocol (TCP) or User Datagram Protocol (UDP) flow is matched against the ACL entries. Once the packet is allowed, the flow is created in the ASA connection table, and all further packets in the flow are permitted based on the connection entry, bypassing the ACL check. You can use the show conn command to view the connection table. It is not recommended to use both inbound and outbound ACLs on same interface because it adds unnecessary overload without any added security benefit. Generally, inbound filtering is implemented because you can filter traffic in one place regardless of the exit interface. Starting with ASA Version 8.3, global ACLs are introduced to ease the overall ACL management. There can be only one ACL applied globally, which applies only to traffic traversing the ASA regardless of the incoming or outgoing interface. When combined with interface-specific ACLs, global ACS rules are inspected after interface specific rules. Only one ACL per protocol (IPv4 or IPv6) can be applied in the inbound or outbound direction of an interface, and one per protocol (IPv4 or IPv6) at global level.

NAT Refresher
On Cisco ASA, when traffic passes from one interface to another and is subject to a NAT rule, we can say that
■

ASA is performing inside NAT when trafﬁc ﬂows from high security level to low security level and inside local is the original address reachable via the high security level interface; inside global is the translated address as seen over the low security level interface.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[7] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■

ASA is performing outside NAT when trafﬁc ﬂows from low security level to high security level and outside global is the original address reachable via the low security level interface; outside local is the translated address, as seen over the high security level interface.

Cisco ASA supports the following types of NAT starting with ASA software Version 8.3, where NAT has been completely redesigned and simplified:
■ ■ ■ ■ ■

Dynamic NAT dynamically translates a group of original addresses into a pool of mapped addresses by translating only source addresses. Dynamic Port Address Translation (PAT) dynamically translates a group of original addresses into a single mapped address by translating both source address and port. Static NAT is a ﬁxed one-to-one mapping between an original address and a mapped address. Static PAT is similar to static NAT except that the Layer 4 protocol, TCP or UDP, is speciﬁed and therefore the port can also be mapped. Identity NAT translates an original address to itself, bypassing NAT; useful to exempt from NAT certain trafﬁc which matches an existing NAT conﬁguration.

In Version 6 of the PIX OS, for a flow to traverse the appliance it was mandatory to match on a translation rule; otherwise, packets were dropped. This behavior was applicable regardless of the traffic direction, from low to high security level or from high to low security level. Since Version 7.x, translation of traffic is no longer mandatory. Traffic is allowed to pass as long as the default security level allows it, or when ACLs have been applied if traffic first matches a permit entry. To reenable the old behavior, we need to globally enable NAT control on the appliance with the global command nat-control. Starting with Version 8.3 of the ASA, NAT control is not available. If NAT control is enabled, the following rules apply:
■ ■

Trafﬁc ﬂowing from high- to low-security interfaces need to match on a NAT rule. Trafﬁc ﬂowing from low- to high-security interfaces does not need to match any NAT rule. (An exception applies when outside dynamic NAT or PAT is conﬁgured for any particular trafﬁc; then, all trafﬁc needs to match a NAT rule.)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[8] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■

Trafﬁc ﬂowing between interfaces at the same security level does not need any NAT rule. (An exception applies when dynamic NAT or PAT is conﬁgured on the same security level interface; then, all trafﬁc from that interface to the samesecurity or lower-security interface needs to match a NAT rule.) Static NAT or PAT does not trigger the need for trafﬁc to match on a NAT rule.

■

Because certain applications do not support NAT, or perhaps because we do not want to NAT particular traffic but NAT control is enabled, there are options to bypass NAT:
■ ■ ■

Identity NAT (nat 0 command) is a special use of dynamic NAT, where the address is actually dynamically translated to itself regardless of the exit interface. Static identity NAT (static command) or static identity policy NAT is a special use of static NAT, where the address is statically translated to itself for trafﬁc between chosen interfaces or between chosen source-destination pairs. NAT exemption (nat 0 access-list command) exempts trafﬁc matched in the ACL from NAT rules regardless of the exit interface; the ACL does not support Layer 4 information to be conﬁgured.

Cisco ASA also allows for same-interface NAT, meaning that traffic enters and exits the same interface but needs to be translated and is functional if the following conditions are satisfied:
■ ■

The same-security-trafﬁc permit intra-interface command is globally enabled on the appliance. The interface becomes both inside and outside from the NAT conﬁguration perspective (nat and global commands applied on the same interface for pre-8.3 ASA version or only nat command for post-8.3 version).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[9] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Routing
Cisco ASA supports IPv4 unicast routing, both static and dynamic methods, with the following protocols (see Table 1-1 for a detailed overview):
■ ■ ■

Routing Information Protocol (RIP) Open Shortest Path First (OSPF) Protocol Enhanced Interior Gateway Routing Protocol (EIGRP)

For IPv6 only, static unicast routing is supported. These protocols are supported when the appliance functions in routed mode. In transparent mode, only static routes are supported, and these are applicable for control-plane traffic only. In terms of static routing, the following rules apply:
■ ■ ■ ■ ■

The static route is active as long as the interface it is associated with is in the up state and has a nameif conﬁgured. ASA does not support equal-cost load balancing over multiple interfaces. Therefore, for any given unique destination preﬁx, you cannot route over multiple interfaces. ASA supports equal-cost load balancing over the same interface, with a maximum of three routes supported. Floating static routing is supported. Static routing redundancy is supported by tracking the availability of a primary route and installing a secondary one if the primary fails. This is achieved by associating the primary route with a deﬁned monitoring target with which connectivity is tested by means of Internet Control Message Protocol (ICMP) echo (Cisco service level agreement [SLA] technology). As long as the target responds with ICMP echo reply within a conﬁgured time interval, the primary route is kept in the routing table. Otherwise, the backup route with higher administrative distance is installed. This functionality is preemptive: When the monitoring target starts responding, the primary route is reinstalled and used for trafﬁc forwarding.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 10 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Cisco ASA uses not only the routing table to make packet-forwarding decisions but also the XLATE tables, and there is a two-step process for this: STEP 1. Select the egress interface. STEP 2. Select the next hop. The egress interface on the ASA is not based on route-recursion process like on routers because each IPv4 unicast route, be it static or dynamic, has an interface associated with. Instead, it uses the following algorithm:
■ ■ ■

If there is an existing IP destination translation in the XLATE table, the egress interface is chosen from the XLATE table. If there is no existing IP destination translation in the XLATE table, but it matches a conﬁgured static translation rule, the routing table is not checked, and the egress interface is selected from the static translation. If none of the preceding is true, ASA looks into the routing table to select the egress interface and IP source NAT is performed if necessary.

As soon as the packet is placed on the selected egress interface buffer, the next hop needs to be selected. Only the routing table is checked to find the longest prefix match for the destination IP of the packet, and from the selected route the next hop is found. Only routes pointing to the respective egress interface are inspected; if none are found, the packet is dropped. ASA supports a tunneled default static route for routing tunneled traffic. When the default tunnel route is configured and no specific routes for the destination of incoming VPN traffic exist, tunnel traffic is routed through the default tunnel route because it overrides any existing regular default routes. The following restrictions apply:
■ ■ ■

Only one default tunnel route can be conﬁgured. TCP intercept is not supported on the egress interface of the tunneled default route. Unicast reverse path forwarding (uRPF) on the egress interface of the tunneled route is not supported.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 11 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Table 1-1 Routing Protocols on Cisco ASA
RIP OSPF EIGRP

Distance-vector routing protocol Single RIP process N/A By default, sends V1 update and accepts both V1 and V2 updates Clear-text/MD5 authentication in V2. Automatic summarization Route information ﬁltering with access lists Default route origination

Link-state routing protocol Two concurrent OSPF processes (An interface cannot participate in both processes.) Stub and NSSA areas, virtual links Broadcast and point-to-point network types

Hybrid routing protocol Single EIGRP process EIGRP stub Dynamic (multicast) and static (unicast) neighbors MD5 authentication Automatic and manual summarization Route-information ﬁltering with access lists Clearing of the candidate default route bit on incoming and outgoing updates Routed single-context mode

Clear-text/MD5 authentication Manual summarization Interarea LSA Type 3 ﬁltering with preﬁx lists Normal and conditional default route origination Routed single-context mode

Routed single-context mode

In terms of multicast routing, ASA provides support for only the UDP transport layer, and the following options are available:
■ ■

Stub multicast routing. Protocol Independent Multicast (PIM) multicast routing.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 12 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Authentication, Authorization, and Accounting Refresher
The authentication, authorization, and accounting (AAA) services on ASA can be used for the following scopes:
■ ■ ■

VPN users/sessions Administrative management on the ASA Firewall sessions (cut-through proxy)

Cisco ASA supports the following user databases for AAA processes:
■ ■ ■ ■ ■ ■ ■

Local RADIUS and supports Internet Engineering Task Force (IETF), Cisco, and Microsoft vendor-speciﬁc attributes (VSA) TACACS+ Lightweight Directory Access Protocol (LDAP) RSA SecureID Kerberos Windows NT

Based on the required AAA services, only certain databases are supported, as listed in Tables 1-2 through 1-4. You can find a more updated AAA services matrix based on 8.x at www.cisco.com/en/US/partner/docs/security/asa/asa81/config/ guide/aaa.html#wp1039490.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 13 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Table 1-2 Firewall Authentication Services
Service Local RADIUS TACACS+ SDI Windows NT Kerberos

VPN users Administration Firewall sessions

Yes Yes Yes

Yes Yes Yes

Yes Yes Yes

Yes No No

Yes No No

Yes No No

Table 1-3 Firewall Authorization Services
Service Local RADIUS TACACS+ SDI Windows NT Kerberos LDAP

VPN users Administration Firewall sessions

Yes Yes No

Yes No No

No Yes Yes

No No No

No No No

No No No

Yes No No

Table 1-4 Firewall Accounting Services
Service Local RADIUS TACACS+ SDI Windows NT Kerberos LDAP

VPN users Administration Firewall sessions

No No No

Yes No Yes

Yes Yes Yes

No No No

No No No

No No No

No No No

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 14 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Modular Policy Framework
Modular Policy Framework (MPF) replaces fixup commands used in Version 6.x of the operating system and is similar in syntax to Modular QOS CLI (MQC) found on IOS routers. Apart from that, its role is to allow for advanced security features and application control. It consists of three major components:
■ ■ ■

Class maps to identify trafﬁc Policy maps to set actions on identiﬁed trafﬁc within class maps Service policies to activate the policies globally or at interface level

The following actions can be applied to an identified traffic flow:
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

TCP normalization TCP sequence number randomization TCP and UDP connection limits and timeouts TCP state bypass QoS input and output policing QoS interface-level standard priority queuing QoS trafﬁc shaping and hierarchical priority queuing Stateful application inspection at Layer 5–7 NetFlow Secure Event Logging (NSEL) export Forwarding trafﬁc to the Cisco Intrusion Prevention System Module (AIP-SSM) Forwarding trafﬁc to the Cisco Content Security and Control Module (CSC-SSM)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 15 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Compared with Cisco IOS MQC, MPF policies have no direction when applied (for example, in or out), but behave as shown in Table 1-5.

Table 1-5 MPF Behavior
Feature Interface Level Global Level

TCP normalization (IPv4 and IPv6) TCP sequence number randomization (IPv4 and IPv6) TCP and UDP connection limits and timeouts (IPv4 and IPv6) TCP state bypass (IPv4 and IPv6) QoS input and output policing (only IPv4) QoS standard priority queuing (only IPv4) QoS trafﬁc shaping, hierarchical priority queuing (only IPv4) Stateful application inspection at Layer 5–7 (for IPv6 only FTP, HTTP, ICMP, SIP, SMTP, IPsec) NSEL export (IPv4 and IPv6) Forwarding trafﬁc to AIP-SSM (IPv4 and IPv6) Forwarding trafﬁc to CSC-SSM (only IPv4)

Bidirectional Bidirectional Bidirectional Bidirectional Ingress/egress Egress Egress Bidirectional N/A Bidirectional Bidirectional

Ingress Ingress Ingress Ingress Ingress/egress Egress N/A Ingress Ingress Ingress Ingress

If a particular flow is matched against multiple sets of rules, the following applies:
■ ■

If a ﬂow matches multiple classes inside the same policy map, actions are combined if different. If a ﬂow matches multiple classes inside the same policy map and actions are conﬂicting, ﬂow matches on ﬁrst class based on the order it appears in the policy map.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 16 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■ ■

If a ﬂow matches the same policy on both the global and interface level, the interface-level policy takes precedence and is the ﬁnal action applied. If a ﬂow matches multiple but different policies on both the global and interface level, actions are combined.

Security Service Modules
Some models of Cisco ASA support the addition of a security module for advanced traffic inspection:
■ ■

AIP-SSC, AIP-SSM, and IPS-SSP are intrusion prevention/detection modules you can deploy in inline or promiscuous mode. CSC-SSM is the Content Security and Control Module, which can be deployed only inline and inspect HTTP, Simple Mail Transfer Protocol (SMTP), POP3, and FTP trafﬁc on standard ports only.

Public Key Infrastructure Overview
Within the scope of VPN, Public Key Infrastructure (PKI) provides a scalable and secure method for distributing, managing, and revoking identity information, also called identity certificates. PKI itself is composed of multiple pieces:
■ ■ ■ ■ ■

Entities that require secure communication Certiﬁcate authority (CA), which grants identity certiﬁcates Digital certiﬁcates that uniquely identify endpoints Optional registration authority (RA) to ofﬂoad the CA for the enrollment process Distribution mechanism for certiﬁcate revocation list (CRL)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 17 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Entities that require secure communication are VPN endpoints in this case, and these take a two-step process to be part of PKI infrastructure: 1. 2. Generate an RSA key pair, resulting in one private key and one public key. Enroll with the CA, providing a name and the previously generated public key. The public key is being signed by the CA’s private key, resulting in the identity certiﬁcate for the requester.

SCEP is a protocol initially developed by VeriSign for Cisco, its scope being to secure issuing of identity certificates in a scalable process. It can support the following operations:
■ ■ ■ ■ ■

CA and RA public key distribution Certiﬁcate enrollment Certiﬁcate revocation Certiﬁcate query CRL query

Cisco ASA can proxy SCEP requests between AnyConnect clients and certificate authorities, to ease the certificate enrollment process. It is supported for both AnyConnect SSL VPN and AnyConnect IKEv2 IPsec VPN. In asymmetric cryptography, public keys are used for encryption, and private keys are used for decryption. In digital signature algorithms, private keys are used for signing, and public keys are used for verifying the signature. Although public key exchange can be performed in the clear over an untrusted channel and verified manually over a secure out-of-band channel, in the context of any-toany or any-to-one VPNs this imposes the following drawbacks:
■ ■

The number of public key exchanges is not scalable. Out-of-band veriﬁcation is neither real time nor scalable.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 18 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

For these reasons, the concept of a trusted third party, the CA, which is trusted by all entities, has been introduced. Everyone needs to securely receive the public key of the CA (a certificate issued by the CA itself), a process called authenticating the CA, which is used to verify CA’s signature of received digital certificates from partner VPN peers. As long as the signature is authentic, VPN endpoints trust each other. A public key of entities or identity certificate is basically the certificate holder public key signed by the private key of the CA and presented in a standard format, such as X.509. For example, in an X.509v3 certificate, the following information is present: Note
PKI requires that time between VPN peers be synchronized to correctly identify certiﬁcate validity on both sides. ■ ■ ■ ■ ■ ■

Name of the identity certiﬁcate holder Public key of the holder Digital signature of the CA Certiﬁcate serial number Certiﬁcate expiration date Algorithms used to generate the signature

Either because a certificate is expired or the corresponding private key of a certificate has been exposed and the certificate was revoked (invalidated) by the CA, this needs to be signaled to everyone in the PKI infrastructure to no longer trust it. To check for revoked certificate, you have the following options:
■ ■

CRLs, a list where the CA publishes expired or revoked certiﬁcates; each PKI entity checks this list on a regular basis. Online Certiﬁcate Status Protocol (OCSP), which is more secure than CRLs because it provides real-time veriﬁcation of identity certiﬁcates against a database and does not need to download any list of revoked certiﬁcates as it is working on a query mechanism basis. AAA Based Certiﬁcate Authorization, a proprietary Cisco method relying on the RADIUS protocol to query AAA servers for revocation information in real time.

■

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 19 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

The PKI model is not limited to only VPN, but is also used in scenarios such as the following:
■ ■ ■ ■

Email encryption Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption within Hypertext Transport Protocol Secure (HTTPS) TLS-protected signaling within the Cisco Uniﬁed Communication Manager infrastructure Secure symmetric key encryption transport for Data Encryption Standard (DES), Triple DES (3DES), and Advanced Encryption Standard (AES)

Evaluating the Cisco ASA VPN Subsystem Architecture
Cisco ASA VPN Technologies
Cisco ASA supports remote-access VPNs and site-to-site VPNs. Although the term virtual private network itself does not imply any security measures, we focus on IP Security (IKev1/IKEv2 IPsec) VPNs and SSL VPNs, which add security measures such as endpoint authentication, traffic encryption, and integrity checks. Remote-access VPNs traditionally provide secure connectivity to enterprise resources for remote workers and can be briefly described as follows:
■ ■ ■ ■ ■

Connect mobile users to protected resources. Use client authentication, message integrity, and trafﬁc encryption. May require a variety of user focused security controls. Must support any connectivity method and transparently traverse any network. ASA supports clientless SSL VPN, client-based SSL VPN, and IKEv1/IKEv2 client-based IPsec VPN.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 20 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Site-to-site VPNs differ as follows:
■ ■ ■ ■ ■ ■ ■

Connect sites for added security over existing WAN. Use peer authentication, message integrity, and trafﬁc encryption. Transparent to the end user requiring access to network resources through the tunnel. Require basic network access controls. ASA supports IKEv1/IKEv2 IPsec VPN. Work as overlay VPN over existing VPN technologies, such as Multiprotocol Label Switching (MPLS), Frame Relay, generic routing encapsulation (GRE) tunnels, or directly over the Internet. Most of the time, require high-availability and performance guarantees (quality of service [QoS]).

IPsec Refresher
Note
IPsec SAs are unidirectional in nature because a different session/ encryption key is used in each direction, one inbound and one outbound. Because IKE SAs use the same session key for both inbound and outbound, it is called a bidirectional SA.

IPsec is a framework defined in RFC 4301, a suite of protocols designed to provide security functions for IP packets at the network layer, such as data integrity, origin authentication, confidentiality, and protection against replay attacks. It is built upon three protocols:
■

Internet Key Exchange (IKEv1 or IKEv2) for secure key management, mutual authentication of systems, and shared secret key establishment for building IPsec security associations (SA); ASA currently supports both IKEv1 and IKEv2, but IKEv1 is not backward compatible with IKEv2. Authentication Header (AH), deﬁned in RFC 2402, uses IP protocol number 51 and encapsulates user trafﬁc to offer data integrity, data-origin authentication, and protection against replay attacks. Encapsulation Security Payload (ESP), deﬁned in RFC 4303, uses IP protocol number 50 and encapsulates IPv4/IPv6 user trafﬁc to offer data integrity, data-origin authentication, conﬁdentiality, and protection against replay attacks.

■ ■

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 21 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Note
AH is no longer supported on Cisco security appliances starting with software Version 7.0. It was supported on PIX platforms on software Version 6.3 and earlier versions. IKEv2 is supported starting with ASA software Version 8.4.x.

An SA contains information about security parameters that have been negotiated between two endpoints to protect traffic (integrity/ encryption algorithms, negotiated keys), and there are two types of SAs if IKEv1 is being used:
■ ■

Internet Key Exchange (IKE) SAs resulting from IKE Phase 1 IPsec SAs resulting from IKE Phase 2

IKEv1 is defined in RFC 2408, runs over UDP port 500, and is a protocol used to automatically and securely establish shared security policies and authentication/encryption keys between two entities. It works in two phases, which are correlated with the two types of SAs:
■

The Phase 1 goal is to establish a secure and authenticated management channel (called the control channel) by using DifﬁeHellman (DH) exchange so that Phase 2 negotiations can occur securely. Phase 1 can operate in main mode or aggressive mode, and it results in one bidirectional IKE SA. The Phase 2 goal is to negotiate and establish IPsec SAs that will protect IP trafﬁc, this being the ﬁnal scope. It is done over the secure channel created in Phase 1, and session encryption keys are derived from the Phase 1 master key or by using a separate D-H exchange if Perfect Forward Secrecy (PFS) is enabled. Phase 2 can operate in quick mode or GDOI mode (used only by GETVPN on IOS routers), and it results in a minimum of two unidirectional SAs (one inbound and one outbound).

■

IKEv2 is defined in RFC 4306, runs over UDP port 500, and was developed to address multiple vulnerabilities present in IKEv1, enhance the protocol functionality, and create a standard protocol to better resolve current challenges. Differences worth mentioning when compared to IKEv1 include the following:
■ ■ ■ ■ ■

Negotiation is shorter; typically, four message exchanges need to take place, but it can be more. Message types used are IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, INFORMATIONAL. There is only one phase for the process, where the child SAs are also created. There are no more options for phases, like aggressive mode and main mode. Dead peer detection (DPD), NAT Traversal, and denial-of-service (DoS) protection through Photuris-style cookie mechanism are now built-in, standard.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 22 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■ ■ ■ ■ ■

Uses unidirectional authentication method, which allows for asymmetric authentication. Informational messages are acknowledged, to address synchronization issues seen in IKEv1. Provides better rekeying and collision handling. Provides a built-in conﬁguration payload and user authentication mode through EAP. (IKEv1 Phase 1.5 is now standard.) IKEv2 policies are agnostic to authentication method, and multiple algorithms can be speciﬁed in the same policy.

Generally speaking, regardless if AH or ESP is being used to provide IP datagram security, two IPsec functional modes exist:
■

Transport mode, where the IPsec header (AH or ESP) is inserted between the IP and the upper-layer protocol headers (see Figure 1-1)
TCP/UDP Data

Original IP Header

Original IP Header

AH Header Authenticated

TCP/UDP

Data

Original IP Header

ESP Header

TCP/UDP Authenticated

Data

ESP Trailer

ESP Auth

Encrypted

Figure 1-1 IPsec Transport Mode Encapsulation
■

Tunnel mode, where the original IP packet is encapsulated in a new IP datagram and the IPsec header is being inserted between the outer and inner IP headers (see Figure 1-2)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 23 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem
Original IP Header TCP/UDP Data

New IP Header

AH Header

Original IP Header Authenticated

TCP/UDP

Data

New IP Header

ESP Header

Original IP Header

TCP/UDP Authenticated Encrypted

Data

ESP Trailer

ESP Auth

Figure 1-2 IPsec Tunnel Mode Encapsulation

SSL/TLS Refresher
Note
Full tunneling is just a term meant to differentiate from the clientless VPN method. It does not mean that all trafﬁc between two VPN endpoints is forced through the tunnel. As discussed further, in the full-tunneling remote-access VPN, you have the option to tunnel all trafﬁc (full tunneling) or selected trafﬁc (split tunneling).

Secure Sockets Layer (SSL) was developed by Netscape in 1994 to secure web transactions, until Version 3.0, when the IETF adopted the protocol and called it Transport Layer Security (TLS), which is also known as SSL 3.1. TLS is not compatible with SSL because TLS uses DH and Digital Signature Standard (DSS) as algorithms, whereas SSL uses RSA. SSL was designed to protect web traffic passing via an unsecure medium, such as the Internet, in the following ways:
■ ■ ■ ■

Authenticates the server to the client by means of X.509 identity certiﬁcates Optionally authenticates client to server by means of X.509 identity certiﬁcates Negotiates encryption algorithms and generates shared keys Establishes a secure SSL/TLS tunnel to ensure conﬁdentiality and integrity for both TCP and UDP trafﬁc

Similar to IPsec, SSL works in two different planes, both occurring inside the SSL Record Protocol
■ ■

Control plane, where negotiation of parameters and peer authentication is performed Data-transfer plane, which provides the protected/secure path between client and server for data communication

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 24 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

SSL/TLS control-plane session establishment and key management take place as follows:
■ ■ ■ ■

Phase 1, initiated by the client, negotiates security capabilities, such as authentication and encryption algorithms. Phase 2, initiated by the server, negotiates one-way or two-way authentication and the server is authenticated by the client. Phase 3, initiated by the client, is optional and authenticates the client based on its identity certiﬁcate. Phase 4, data transfer starts after session keys are exchanged/negotiated.

Cisco ASA VPN Access Methods
Cisco ASA supports multiple VPN architectures, and each is discussed further:
■ ■ ■ ■

Full-tunneling (client based) remote-access SSL VPN Clientless remote-access SSL VPN Full-tunneling (client-based) remote-access IPsec (IKEv1/IKEv2) VPN Full-tunneling site-to-site IPsec (IKEv1/IKEv2) VPN

In full-tunneling SSL VPN, remote users make use of the Cisco AnyConnect VPN client to establish an SSL/TLS tunnel with the ASA box. Benefits of a full-tunneling remote-access SSL VPN include the following:
■ ■ ■ ■ ■ ■

It supports transparent access to any IP application. Just basic user training is required, only for creating and terminating the VPN tunnel. It supports low-latency forwarding of sensitive applications, such as IP voice, because of Datagram Transport Layer Security (DTLS) encapsulation. Because it uses regular HTTPS port 443, it traverses ﬁrewalls and NAT devices transparently. VPN termination on ASA is restricted to AnyConnect clients (thus adding a layer of security). Auto-updates for AnyConnect clients are pushed from the ASA.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 25 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Drawbacks of a full-tunneling remote-access SSL VPN include the following:
■ ■

It requires installation of AnyConnect software on client machines. It requires administrative privilege on the client machine for the initial install but not for updates.

In a clientless SSL VPN, remote endpoints do not require any software but use a compatible browser to establish an SSL/TLS tunnel with the ASA, after which they are presented with a web portal for application access such as the following:
■ ■ ■ ■ ■

URL and Common Internet File System (CIFS) ﬁle access Application plug-ins such as Remote Desktop Protocol (RDP), Telnet, Secure Shell (SSH), Virtual Network Computing (VNC), Citrix Port forwarding through a Java applet Smart tunnels for tunneling TCP applications in the SSL tunnel E-mail proxy

Benefits of a clientless SSL VPN include the following:
■ ■ ■

Because it uses regular HTTPS port 443, it traverses ﬁrewalls and NAT devices transparently. It does not require any software installation on client devices and is therefore compatible with any device for which AnyConnect is not available. It does not require any administrative privileges on client device.

Drawbacks of a clientless SSL VPN include the following:
■ ■

It does not support full native-application access (for example, only those supported by port forwarding and smart tunnel, with respective restrictions). It might require user training for optimum web portal usage.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 26 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■ ■

It does not support low-latency forwarding and real-time applications. The login portal on ASA could be accessed by anyone, and therefore additional security measures are needed.

In both SSL/TLS tunneling methods, Cisco Secure Desktop (CSD) offers additional security features:
■ ■ ■

Secure Vault encrypts data and ﬁles from the SSL session in a secure partition, which is deleted upon VPN termination. Host Scan checks for the presence of different software on clients (for example, antivirus and ﬁrewall). Keystroke logger detection and host-emulation detection deny VPN access when keystroke logging software or a host emulator is detected.

In a full-tunneling IPsec VPN, clients make use of the Cisco IPsec VPN Client (IKEv1) or Cisco AnyConnect Secure Mobility Client (IKEv2) to establish an IPsec tunnel with ASA. This method has the following benefits:
■ ■ ■ ■ ■

It supports transparent access to any IP application. Just basic user training is required (only creating and terminating the VPN tunnel). It supports low-latency forwarding of sensitive applications like IP voice, because IPsec is a connectionless protocol. VPN termination on ASA is restricted to only Cisco VPN clients. It does not require licensing for IKEv1IPsec sessions.

Drawbacks of a full-tunneling IPsec VPN include the following:
■ ■ ■ ■

It requires installation of Cisco VPN IPsec software on client machines for IKEv1 IPsec sessions. It requires installation of Cisco AnyConnect Secure Mobility Client on client machines for IKEv2 IPsec sessions. It requires administrative privilege on the client machine for both initial installment and updates; AnyConnect updates do not require administrative privileges. It can experience connectivity problems over ﬁrewalls and NAT devices because IPsec(ESP) and IKEv1/IKEv2 might be restricted along the path between clients and VPN gateway.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 27 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

A full-tunneling, site-to-site IPsec VPN is a VPN tunnel between Cisco ASA and any other IPsec-capable device, but lacks features supported on Cisco IOS routers, such as virtual tunnel interfaces (VTI), GRE-over-IPsec tunneling, Dynamic Multipoint VPN (DMVPN) or Group Encrypted Transport VPN (GETVPN). It has the following benefits:
■ ■ ■ ■

It supports transparent access to any IP application. It does not require any end-user training. It supports low-latency forwarding of sensitive applications like IP voice because IPsec is a connectionless protocol. Supports both IKEv1 and IKEv2 IPsec sessions.

One drawback of a full-tunneling, site-to-site IPsec VPN is as follows:
■

It can experience connectivity problems over ﬁrewalls and NAT devices because IPsec(ESP) and IKEv1/IKEv2 might be restricted along the path.

Note that the term full tunneling is being used here to mark the technology; it does not mean that all traffic is forced to go through the tunnel. As discussed the configuration section, you can select what traffic is forwarded through the tunnel, the rest being forwarded outside of the tunnel. VPN connections may be subject to NAT/PAT along the path, which imposes a problem only for IPsec VPNs, because both AH and ESP are Layer 3 connectionless protocols with no knowledge of port numbers. AH is not even compatible with NAT devices because AH authenticates not only the datagram but also the IP header, but ESP is because it authenticates only the IP datagram. For ESP to be passed across NAT/PAT devices, the following solutions exist on Cisco ASA: Note
Telnet is not allowed in clear text on the outside interface, but only through a VPN tunnel, so that trafﬁc reaches the appliance encrypted. ■ ■

Standard-based NAT Traversal or NAT Transparency (NAT-T), which encapsulates ESP into UDP port 4500 to traverse NAT gateways, but only if NAT is detected along the path; it is supported for all IPsec VPN types, both IKEv1 and IKEv2. Cisco proprietary UDP or TCP encapsulation is supported only for remote-access IPsec IKEv1 VPNs. With TCP encapsulation, IKEv1 and ESP are encapsulated into TCP, with TCP port 10000 being used by default. With UDP encapsulation, IKEv1 negotiation still uses the standard UDP port 500, but ESP is encapsulated into UDP, with UDP port 10000 being used by default. With this method, TCP or UDP encapsulation is always used regardless of NAT device existence in the path.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 28 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

In terms of VPN termination on ASA interfaces, the same restrictions as for usual control-plane traffic apply. If ICMP echo is allowed on the control-plane level of the ASA and is allowed by default, you can only ping the interface closest to you from a routing perspective. For example, if you reside on the inside network of the ASA, you can only ping the inside interface; you cannot traverse the firewall and ping the outside interface. To ping the outside interface, you need to reside on the outside networks from the ASA’s point of view. The same applies for VPN sessions, because you can only terminate VPN sessions on the interface facing the client. An exception applies to this control-plane rule for allowing management access through an IPsec VPN session on other interfaces than the VPN terminating one: Only one management access interface is allowed and configured with global command managementaccess. For example, if you terminate an IPSec VPN session on the outside interface but want to gain SSH access on the inside interface through the tunnel, you would configure management-access inside.

Cisco ASA IPv6 VPN Capabilities
Cisco ASA supports IPv6 for site-to-site IKEv1/IKEv2 IPsec VPNs, and IPv6 can be used both as transport and protected networks. For mixed IPv4 and IPv6 addressing, however, some restrictions apply for the current software version of 8.4:
■ ■ ■ ■

Both VPN gateways need to be ASA appliances. The VPN terminating interface is IPv6 enabled, and inside interfaces are IPv4 enabled. The VPN terminating interface is IPv4 enabled, and inside interfaces are IPv6 enabled. The VPN terminating interface is IPV6 enabled, and inside interfaces are IPv6 enabled.

Cisco ASA supports IPv6 for all remote-access VPNs except for IKEv1 IPsec sessions, but IPv6 can be used only to access protected IPv6 networks/resources; it cannot be used as a transport protocol between clients and VPN gateway with current software version of ASA (8.4) and AnyConnect (3.0).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 29 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Cisco AnyConnect 3.0 Components
AnyConnect 3.0 represents Cisco’s new vision on secure mobility segment and all related aspects, hence the name of AnyConnect Secure Mobility Client. It is completely different from earlier versions because it is a modular client, which allows Cisco to easily add future capabilities to it by new modules and faster address issues/bugs related to specific modules. It is customizable and translatable, and the current version contains the following modules:
■ ■ ■ ■ ■ ■ ■

AnyConnect VPN for IKEv2 and SSL remote-access VPNs Nework Access Manager for managing access and authentication process to wired and wireless networks (former SSC) Posture Assessment for gathering client information like OS, antivirus, ﬁrewall through Host Scan application Telemetry for sending information about origin of malicious web content to Cisco IronPort WSA Web Security for web proxy conﬁguration, cloud-based with Cisco ScanSafe or standalone with Cisco IronPort WSA Diagnostic and Reporting Tool (DART) for troubleshooting AnyConnect installation and connection problems Start Before Logon (SBL) for starting the AnyConnect VPN session before users logging on to Windows

Cisco ASA VPN Access Control Model
Cisco ASA has different control mechanisms available to restrict resource access, depending on the type of VPN tunnel. In all VPN models where the end user requiring access is identifiable by static or dynamic IPv4/IPv6 address (full-tunneling SSL VPN, IPsec remote-access VPN, and site-to-site VPN), some of the available options are as follows:
■ ■ ■ ■ ■

Interface ACLs Per-user or per-group ACLs called ﬁlters Dynamic access policy (DAP)-assigned ACLs MPF policies Redirection of trafﬁc to security modules

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 30 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

For clear-text traffic from tunnels terminated on the ASA to bypass interface ACLs, sysopt connection permit-vpn is globally enabled by default. For a clientless SSL VPN, where the ASA acts as a proxy when resources are accessed because the client is not assigned an IPv4/IPv6 address, limited control is available through the following:
■ ■ ■ ■ ■ ■ ■

Portal customization. Restricted applications available in the portal. URL entries. File server entries and browsing. Hidden-share access. Active relay applications. Port-forwarding, smart tunnels, and plug-in access can be controlled with webtype ACLs based on the destination IP and TCP port socket pair. (Webtype ACLs can also make restrictions based on URLs.)

Cisco ASA VPN Licensing Overview
The license is a 160-bit activation key that activates certain features or increases performance parameters on the ASA appliances. All ASAs are delivered with a license already installed, either the Base license or the Security Plus license (available as an add-on to the Base license only on ASA 5505 and ASA 5510). In addition, the following licenses can be installed:
■ ■ ■ ■

Security Contexts GTP/GPRS Inspection Botnet Trafﬁc Filter SSL VPN

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 31 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem ■ ■

Cisco Intercompany Media Engine (IME) Cisco ASA Uniﬁed Communication Proxy

IKEv1 remote-access/site-to-site IPsec VPNs and IKEv2 site-to-site VPNs do not require licenses, with the number of IPsec sessions being platform dependent. Remote-access IKEv2 and SSL VPNs require licensing. You have multiple VPN licensing models from which to choose, depending on what you want to accomplish:
■ ■

AnyConnect Essential license supports only SSL AnyConnect SSL and IKEv2 client connections. It does not support CSD or clientless SSL and is not compatible with the Premium license. A single license per device model is needed. AnyConnect Premium license supports both SSL/IKEv2 AnyConnect sessions and SSL clientless connections with CSD support. The license is based on the number of simultaneous users and is available for a standalone device or may be shared among multiple devices. It is not compatible with the Essential license. AnyConnect Mobile license enables AnyConnect sessions from mobile device operating systems such as iOS or Android. A single license per device model is needed in addition to an Essential or Premium license. AnyConnect for Cisco VPN Phone allows access from hardware IP phones that have built-in AnyConnect compatibility. Advanced Endpoint Assessment enables client auto-remediation through use of CSD. A single license per device model is needed in addition to a Premium license. Cisco Secure Mobility provides web proxy services automatic integration between AnyConnect and Cisco IronPort Web Security Appliance (WSA). This is enabled on the Ironport WSA. Cisco Secure Mobility for ScanSafe provides (in the cloud) ScanSafe web proxy services. This is enabled on the AnyConnect client side. FIPS 140-2 Level 1 allows for Federal Information Processing Standard (FIPS)-compliant AnyConnect versions, starting with AnyConnect 2.4.x. A single license per device model is needed.

■ ■ ■ ■ ■ ■

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 32 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

All Cisco ASA models are shipped by default with an AnyConnect Premium license for two simultaneous sessions, thus allowing you to test both client and clientless SSL VPN connection types. The ASA supports both temporary (time-based or evaluation) and permanent licenses, which interact as follows:
■ ■ ■ ■ ■

If a temporary license is activated, features from both the temporary and permanent license are merged to form the running license. For each licensed feature, only the highest value between temporary and permanent is used; values are not combined. Activation of a permanent license for a feature overwrites any temporary or permanent licenses for that feature and becomes the running license. If a permanent license is installed but is a downgrade from a temporary license, ASA needs a reload to disable the temporary license and restore the permanent. For a license upgrade, ASA does not need a reload. ASA can have multiple temporary licenses installed, but only one per feature can be active at any given time.

VPN high availability can be achieved by configuring two ASAs in a failover pair or by grouping multiple ASAs in a cluster. With failover, starting with ASA software Version 8.3, there is no longer a requirement to have identical licenses on both devices (except for Security Plus license needed to support failover on ASA 5510); licenses from both boxes are additive and form the running license on the active device. In the cluster, remote-access VPN sessions are load balanced across the members, a model that fits a shared licensing architecture:
■ ■ ■ ■ ■ ■ ■

Members can be different models and have differing licenses. The licensing server uses a dedicated shared license. One ASA can be designated as the backup licensing server, which needs a permanent regular license. Participants obtain licenses from the licensing server in 50-session batches. The number of licenses is ultimately limited by platform limit. A cluster master is not necessarily identical to the licensing server. Communication inside the cluster is protected by SSL.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 33 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Licenses can be installed using the global command activation-key and can be viewed in the system with command show activationkey or show version (see Example 1-1).

Example 1-1

ASA Licenses

ciscoasa# show activation-key Serial Number: JMX1025K29F Running Permanent Activation Key: 0x2c19c458 0x8ce4f79c 0x2c81c524 0x8e8844fc 0x4934219a Licensed features for this platform: Maximum Physical Interfaces : Unlimited Maximum VLANs : 150 Inside Hosts : Unlimited Failover : Active/Active VPN-DES : Enabled VPN-3DES-AES : Enabled Security Contexts : 2 GTP/GPRS : Disabled AnyConnect Premium Peers : 2 AnyConnect Essentials : Disabled Other VPN Peers : 750 Total VPN Peers : 750 Shared License : Disabled AnyConnect for Mobile : Disabled AnyConnect for Cisco VPN Phone : Disabled Advanced Endpoint Assessment : Disabled UC Phone Proxy Sessions : 2 Total UC Proxy Sessions : 2 Botnet Traﬀic Filter : Disabled Intercompany Media Engine : Disabled This platform has an ASA 5520 VPN Plus license.

perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual perpetual

Follow these steps to configure the shared licensing server: STEP 1. Globally conﬁgure the shared secret used between participants and the server with the command license-server secret secret. STEP 2. Globally conﬁgure the backup licensing server parameters with the command license-server backup address backup-id serial_number [ha-backup-id ha_serial_number].
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 34 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

STEP 3. Enable the licensing server with the global command license-server enable interface_name. Follow these steps to configure the backup licensing server: STEP 1. Globally conﬁgure the shared licensing server and optionally modify the default TCP port 50554 used for communication with the command license-server address address secret secret [port port]. STEP 2. Globally enable the backup licensing server with the command license-server backup enable interface_name. Follow these steps to configure a shared licensing participant: STEP 1. Globally conﬁgure the shared licensing server parameters with the command license-server address address secret secret [port port]. STEP 2. Globally conﬁgure the backup licensing server parameters with the command license-server backup address address. To configure any shared license role by using ASDM, navigate to Configuration > Device Management > Licensing > Shared SSL VPN Licenses.

Implementing Proﬁles, Group Policies, and User Policies
Overview
Cisco ASA uses a flexible and scalable configuration scheme to meet different requirements for all types of VPNs supported. There are two major components in the process of VPN configuration: 1. Connection proﬁles, also known as tunnel groups from the CLI, which deﬁne the prelogin requirements of a VPN session. A connection proﬁle separates all VPN sessions into groups based on requirements such as AAA method used or connection method/protocol used, to apply different security policies on each group or user. Group policies, which deﬁne the postlogin security policies applied, such as trafﬁc ﬁltering (authorization) or time restrictions.

2.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 35 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Because multiple options exist for enforcing the same or maybe conflicting policies for a remote-access VPN session, ASA uses a hierarchical policy inheritance model with the following priority philosophy, starting from the highest priority: 1. 2. 3. 4. 5. DAP rules User profiles (local or remotely pushed from the AAA server) Group policy attached to user profile Group policy attached to connection profile DﬂtGrpPolicy group policy settings

For example, if you assign a group policy at both user profile and connection profile levels for the respective user and VPN session, settings from both policies are combined to form a final set of rules. If two policies have conflicting settings, settings from the group policy applied at the user profile are preferred (in accordance with the priority chart).

Connection Proﬁles
Note
If a VPN session is assigned to an administrator conﬁgured connection proﬁle and the conﬁguration is correct, the session will succeed. It is not the case for the default connection proﬁles of DefaultRAGroup and DefaultWEBVPNGroup, where if the session is mapped the connection will most probably not be successful because of the preconﬁgured rules for these proﬁles.

Connection profiles, depending on the VPN type, can be selected by the end user at connection time or forced by the ASA and remote AnyConnect/IPsec VPN clients. In the absence of administrator-configured connection profiles on ASA, two default profiles are used for remote-access VPN type assignment: 1. DefaultRAGroup for IKEv1/IKEv2 and client-based SSL VPN remote-access sessions; it is conﬁgurable and can be viewed with the following command: ciscoasa# show running-conﬁg all tunnel-group DefaultRAGroup

2.

DefaultWEBVPNGroup for clientless SSL VPN sessions; it is configurable and can be viewed with the following command: ciscoasa# show running-conﬁg all tunnel-group DefaultWEBVPNGroup

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 36 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Note that you can use both of these for any remote-access connection type. However, their default intended purpose is the described one, and they act as a catchall entry for any remote-access VPN session that is not assigned to a manually configured connection profile. In remote-access SSL VPNs or IKEv2 IPsec with user password authentication, the connection profile mapping options are as follows:
■ ■ ■ ■

Users can choose the connection proﬁle from a drop-down menu in the browser or menu in AnyConnect Client, given that multiple conﬁgured proﬁles exist on the ASA. In a clientless SSL VPN, users can be forced to a speciﬁc connection proﬁle by accessing a speciﬁc URL at login time. In a full-tunneling SSL VPN, users can be forced to a speciﬁc connection proﬁle by Extensible Markup Language (XML) proﬁles, as discussed later. If a user does not choose a connection proﬁle, the session is mapped to DefaultRAGroup or DefaultWEBVPNGroup.

In a remote-access SSL VPN or IKEv2 IPsec with client identity certificate authentication (or combined certificate and password authentication), connection profile mapping options are as follows:
■ ■ ■

Based on attributes matching from the certiﬁcate, users can be automatically mapped to a connection proﬁle. As in password authentication only, clients can select the connection proﬁle or can be forced to one. If no identity certiﬁcate mapping rules are conﬁgured, users are mapped to DefaultRAGroup or DefaultWEBVPNGroup.

In a remote-access IKEv1 IPsec VPN with group pre-shared key authentication, the connection profile is selected as follows:
■ ■

Conﬁgured as the group name in the Cisco IPsec VPN client. DefaultRAGroup cannot be used as group name by default because it does not use pre-shared key authentication.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 37 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

In remote-access IKEv1 IPsec VPNs with identity certificate authentication (or combined certificate and password authentication), the connection profile is selected as follows:
■ ■ ■ ■

Cannot be speciﬁed as a group name in the Cisco IPsec VPN client. Based on information from the certiﬁcate, users can be automatically mapped to a conﬁgured connection proﬁle. If no identity certiﬁcate mapping rules are conﬁgured, ASA examines the organizational unit (OU) from the certiﬁcate and uses its value as the connection proﬁle. If no connection proﬁle has been identiﬁed by the OU, users are mapped to DefaultRAGroup.

In all these cases, users can be locked by their user profile configuration into a specific connection profile, with access to all other connection profiles being denied. To create connection profiles using the ASDM, complete the following steps: STEP 1. Navigate to Conﬁguration > Remote Access VPN and
■ ■ ■

For a full-tunneling SSL VPN, navigate to Network (Client) Access > AnyConnect Connection Proﬁles. For a clientless SSL VPN, navigate to Clientless SSL VPN Access > Connection Proﬁles. For an IPsec remote-access VPN, navigate to Network (Client) Access > IPsec(IKEv1) Connection Proﬁles.

STEP 2. Click Add to create a new connection proﬁle. STEP 3. Assign a name to the connection proﬁle. STEP 4. Conﬁgure the connection proﬁle settings. As a general rule, when ASDM examples are given throughout this book, notice that the following actions are not covered even though needed at each configuration step (see Figure 1-3):
■ ■ ■

OK button used to close a window as part of a new conﬁguration section. Apply button used to save the modiﬁcations from ASDM into running-conﬁguration of ASA. Save button used after Apply to save changes into the startup conﬁguration of ASA.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 38 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Figure 1-3 General ASDM Rules

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 39 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

To create connection profiles using the CLI, follow these steps: STEP 1. Create a connection proﬁle (tunnel-group) called TEST-CP, for example, of remote-access type. STEP 2. Enter conﬁguration mode for general proﬁle attributes like AAA, DHCP server: ciscoasa(conﬁg)# tunnel-group TEST-CP type remote-access ciscoasa(conﬁg)# tunnel-group TEST-CP general-attributes

The following are optional configuration steps: 1. 2. 3. 4. 5. Enter conﬁguration mode for SSL VPN- or IPsec VPN-speciﬁc attributes; conﬁgure group-alias for a clientless SSL VPN and a pre-shared key for a remote-access IKEv1 IPsec VPN. Create a certificate map called TEST-MAP, for example, and match on OU of identity certificate and CN of CA. For certificate-based authentication, bind users to specific profiles. Allow users to select the connection profile from the browser drop-down menu. Lock a user TEST-USER to a specific connection profile: ciscoasa(conﬁg)# tunnel-group TEST-CP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# group-alias "Financial Department" enable ciscoasa(conﬁg)# tunnel-group TEST-CP ipsec-attributes ciscoasa(conﬁg-tunnel-ipsec)# ikev1 pre-shared-key *datanetsystemskey* ciscoasa(conﬁg)# crypto ca certiﬁcate map TEST-MAP 10 ciscoasa(conﬁg-ca-cert-map)# subject-name attr ou eq FINANCIAL ciscoasa(conﬁg-ca-cert-map)# issuer-name attr cn eq TEST-CA ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# certiﬁcate-group-map TEST-MAP 10 TEST-CP ciscoasa(conﬁg-webvpn)# tunnel-group-list enable ciscoasa(conﬁg)# username TEST-USER password test-password ciscoasa(conﬁg)# username TEST-USER attributes ciscoasa(conﬁg-username)# group-lock value TEST-CP

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 40 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

Group Policies
Group policies are usually mapped either to specific users or to specific connection profiles so that users/groups receive different settings such as IP address pool, DNS servers, or access control enforcements such as DAPs and ACLs. Multiple users or connection profiles can share the same group policy, though. Cisco ASA includes a default group policy, called DfltGrpPolicy, which is applied to the default connection profiles of DefaultRAGroup and DefaultWEBVPNGroup. It is configurable and can be viewed with command: ciscoasa# show running-conﬁg all group-policy DﬂtGrpPolicy

To create group policies using the ASDM, follow these steps: STEP 1. Navigate to Conﬁguration > Remote Access VPN and
■ ■

For a full-tunneling SSL VPN and an IKEv1/IKEv2 IPsec remote-access VPN, navigate to Network (Client) Access > Group Policies. For a clientless SSL VPN, navigate to Clientless SSL VPN Access > Group Policies.

STEP 2. Click Add to create a new group policy. STEP 3. Assign a name to the group policy. STEP 4. Conﬁgure group policy settings. To create group policies using the CLI, follow these steps: STEP 1. Create a local internal (external type is downloaded from RADIUS or LDAP) policy called TEST-POLICY. STEP 2. Conﬁgure policy settings, such as DNS server: ciscoasa(conﬁg)# group-policy TEST-POLICY internal ciscoasa(conﬁg)# group-policy TEST-POLICY attributes ciscoasa(conﬁg-group-policy)# dns-server value 1.1.1.1

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 41 ] Chapter 1: Evaluating the Cisco ASA VPN Subsystem

The following are optional configuration steps: 1. 2. Assign the group policy to a speciﬁc connection proﬁle so that it does not inherit all the DﬂtGrpPolicy settings. Assign the group policy to a specific user profile so that it does not inherit the group policy settings from the connection profile: ciscoasa(conﬁg)# tunnel-group TEST-CP general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy TEST-POLICY ciscoasa(conﬁg)# username TEST-USER attributes ciscoasa(conﬁg-username)# vpn-group-policy TEST-POLICY

User Proﬁles
Because most of the time VPN sessions on ASA are authenticated on a username/password basis, ASA allows the creation of per-user profiles. User profiles offer a limited set of features found in group policies, such as connection profile lock and ACL filtering, while also allowing for additional features such as per-user static IP addresses.

External Policy Storage
You can configure VPN group policies locally on the ASA, called internal, or download them from an external database, called external. ASA supports the following external databases for this:
■ ■ ■

RADIUS Lightweight Directory Access Protocol (LDAP) TACACS+ (limited, only ACL assignments and session timeouts)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 42 ] CCNP Security VPN 642-648 Quick Reference

Chapter 2

Deploying Cisco ASA IPsec VPN Solutions
This chapter covers site-to-site IKEv1/IKEv2 IPsec virtual private network (VPN), remote-access IKEv2 IPsec VPN (AnyConnect) and remote-access IKEv1 IPsec VPN (Easy VPN) solutions on Cisco Adaptive Security Appliances (ASA). Although IP Security (IPsec) VPN termination on Cisco ASA does not require additional licensing, the number of supported concurrent IPsec sessions on each box is limited by platform model, ranging from 10 to 10,000. Because of its early implementation on Cisco ASA, expect interoperability issues if using AnyConnect with IKEv2 and IKEv2 site-to-site IPsec VPNs. Tunnels established between any two ASA IPsec peers are created on demand as follows: 1. 2. 3. 4. 5. When interesting trafﬁc (matched in the crypto ACL) is detected in the buffer of the interface where the crypto map is applied, the process is triggered. Internet Key Exchange (IKEv1) Phase 1 negotiation for the management tunnel starts, and one IKEv1 security association (SA) is created. IKEv1 Phase 2 negotiation for the data-plane tunnel starts, and at least two IPsec SAs are created. Data starts to flow through the tunnel using security parameters from IPsec SAs. The tunnel is terminated when the idle/session-timeout timer is reached or when one gateway disconnects.

For IKEv2, there is only one phase, so Steps 2 and 3 become one, where both parent SA (IKEv2 SA) and child SA (IPsec SA) are established. For remote-access IPsec VPNs, the process is user triggered by starting the AnyConnect (for IKEv2) or VPN client (for IKEv1), or you can configure these clients to automatically initiate the VPN session upon certain conditions. In site-to-site VPNs, VPN gateways (tunnel endpoints) must authenticate each other before the communication path can be considered secure. In basic, small deployments, pre-shared keys are used for authentication. In large deployments, digital certificates are typically used to scale and strengthen the security level.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 43 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Deploying Basic Site-to-Site VPNs
Site-to-site VPNs create a secure point-to-point connection between any two capable IPsec endpoints (see Figure 2-1). Basic site-tosite VPN deployment consists of three steps: STEP 1. Conﬁgure basic peer authentication: IKEv1 Phase 1 or IKEv2 parent SA. STEP 2. Conﬁgure transmission protection: IKEv1 Phase 2 or IKEv2 child SA. STEP 3. Verify communication over the encrypted tunnel.

Figure 2-1 Site-to-Site VPN

IKE v2

IKE v1 IP

v4

VP

N Tunn el

IKEv2 IPv4 VPN Tunnel

Tunnel PN 6V v IP

HQ VPN Gateway IPv4/IPv6 Transport Network

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 44 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

With the addition of IKEv2 support, smooth migration is supported from IKEv1 and the configuration process made easier as follows:
■ ■ ■ ■ ■ ■

IKEv1 and IKEv2 conﬁgurations can be on same crypto map, which allows the initiator to fall back from IKEv2 to IKEv1 if for any reason the IKEv2 negotiation fails. IKEv2 has feature parity with IKEv1 for VPN session mapping to tunnel-group rules, dynamic L2L, access control with VPN ﬁltering in group policies, and peer ID veriﬁcation. IKEv2 allows for asymmetric authentication methods, and therefore you can use different authentication schemes for the originator and responder. IKEv2 does not negotiate the peer authentication type in IKE policies. The authentication type is determined after tunnelgroup mappings. IKEv2 supports an optional pre-shared key conﬁguration in the crypto map, necessary when asymmetric authentication is used, to map the VPN session to a speciﬁc connection proﬁle. IKEv2 for site-to-site VPNs does not support multiple peers or IPsec transport mode (left only for L2TP).

Conﬁguring Basic Peer Authentication: IKEv1 Phase 1 or IKEv2 Parent SA
By default on Cisco ASA, IKEv1 runs in aggressive mode for only remote-access VPNs using pre-shared-key authentication, and because of the identity-matching mechanism, this is a requirement for the connection to be successful. You can disable aggressive mode with the global command crypto ikev1 am-disable. To configure basic peer authentication, follow this process: STEP 1. Enable IKEv1, IKEv2, or both on the interface the VPN tunnel will be terminated on; this needs to be the interface closest to the remote gateway.To enable IKEv2/IKEv2 on the interface using the Adaptive Security Device Manager (ASDM), navigate to Conﬁguration > Site-to-Site VPN > Connection Proﬁles, and under Access Interfaces select the interface and protocol (see Figure 2-2). Optionally, you can modify the IKE identity of the initiator from Conﬁguration > Site-to-Site VPN > Advanced > IKE Parameters, and you have the following options:

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 45 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■ ■ ■

Automatic (IP address for pre-shared key authentication and certiﬁcate distinguished name [DN] for identity certiﬁcate authentication) Address (IP address of the interface) Hostname (fully qualiﬁed domain name [FQDN]) Key ID (string used by remote peer to look for pre-shared key)

Figure 2-2 Enable IKEv1/IKEv2

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 46 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

To enable IKEv1/IKEv2 on the interface and select IKE identity using the command-line interface (CLI), use the following commands: ciscoasa(conﬁg)# crypto ikev1 enable outside ciscoasa(conﬁg)# crypto ikev2 enable outside ciscoasa(conﬁg)# crypto isakmp identity auto

STEP 2. Conﬁgure the IKE policy. If multiple policies are conﬁgured, the VPN session initiator presents it all to the remote device in the order of their priority values from low to high, which picks up the ﬁrst one with a perfect match on its own policies. To create IKE policies using the ASDM, navigate to Conﬁguration > Site-to-Site VPN > Advanced > IKE Policies and click the Add button. The following options are conﬁgurable for IKEv1 (see Figure 2-3):
■ ■ ■ ■ ■ ■

Priority (a number between 1 and 65,535, with a lower number meaning higher priority in policy negotiation between VPN gateways) Encryption algorithm (Data Encryption Standard [DES], Triple DES [3DES], Advanced Encryption Standard [AES-128], AES-192, and AES-256) Hash algorithm (message digest authentication 5 [MD5] or Secure Hash 1 [SHA-1]) Authentication mode (pre-share, rsa-sig, or crack) D-H Group (group1 [768 bit], group2 [1024 bit], or group5 [1536 bit]) Lifetime (in seconds, a number between 120 and 2,147,483,647 or unlimited) Priority (a number between 1 and 65,535, with a lower number meaning higher priority in policy negotiation between VPN gateways) Encryption algorithm (Data Encryption Standard [DES], Triple DES [3DES], Advanced Encryption Standard [AES-128], AES-192, and AES-256) Integrity Hash algorithm (message digest authentication 5 [MD5] or Secure Hash [SHA-160], SHA256, SHA384, SHA512)

The following options are conﬁgurable for IKEv2 (see Figure 2-3):
■ ■ ■

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 47 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■ ■

PRF Hash algorithm (message digest authentication 5 [MD5] or Secure Hash [SHA-160], SHA256, SHA384, SHA512) D-H Group (group1 [768 bit], group2 [1024 bit], group5 [1536 bit] or group14 [2048 bit]) Lifetime (in seconds, a number between 120 and 2,147,483,647 or unlimited)

A noticeable difference between IKEv1 and IKEv2 policies is that on same IKEv2 policy you can specify multiple integrity, D-H groups, and encryption algorithms and that IKEv2 no longer requires authentication parameters in IKE policies. So, you could specify all supported algorithms in one policy, and upon negotiation, peers will use the strongest commonly supported ones. IKEv2 adds a pseudo random function hash (PRF) that is dedicated to deriving the keying material.

Figure 2-3 Create IKEv1/IKEv2 Policies
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 48 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

For a successful negotiation, VPN gateways need to agree on one common policy, with attributes having the same values, except for priority, which is locally signiﬁcant, and lifetime, which does not need to match. (On IKEv1, the lifetime value is negotiated to the lowest conﬁgured value; in IKEv2, each peer can use its own local lifetime.) To create IKEv1/IKEv2 policies using the CLI, use the following commands: ciscoasa(conﬁg)# crypto ikev1 policy 10 ciscoasa(conﬁg-isakmp-policy)# authentication pre-share ciscoasa(conﬁg-isakmp-policy)# encryption aes-256 ciscoasa(conﬁg-isakmp-policy)# hash sha ciscoasa(conﬁg-isakmp-policy)# group 2 ciscoasa(conﬁg-isakmp-policy)# lifetime 7200 ciscoasa(conﬁg)# crypto ikev2 policy 10 ciscoasa(conﬁg-isakmp-policy)# prf sha512 sha md5 ciscoasa(conﬁg-isakmp-policy)# encryption aes-256 aes-192 3des ciscoasa(conﬁg-isakmp-policy)# integrity sha512 sha md5 ciscoasa(conﬁg-isakmp-policy)# group 5 2 ciscoasa(conﬁg-isakmp-policy)# lifetime 7200

STEP 3. Conﬁgure the connection proﬁle and pre-shared key. For site-to-site VPNs with pre-shared key authentication, the connection proﬁle name needs to actually be the IPv4/IPv6 address of remote VPN gateway, although there are mechanisms to bypass this limitation. To create the connection profile using the ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > Tunnel Groups and click Add. Notice that both IKEv1 and IKEv2 settings have been configured for an IPv4 tunnel (see Figure 2-4).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 49 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-4 Add Site-to-Site VPN
To create connection profiles with pre-shared key authentication for a site-to-site IKEv1 VPN with remote gateway 5.5.5.5 and enable IKEv1 dead peer detection (DPD) using the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group ciscoasa(conﬁg)# tunnel-group ciscoasa(conﬁg-tunnel-ipsec)# ciscoasa(conﬁg-tunnel-ipsec)# 5.5.5.5 type ipsec-l2l 5.5.5.5 ipsec-attributes ikev1 pre-shared-key *ciscotestkey* isakmp keepalive threshold 10 retry 2

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 50 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

To create connection profiles with symmetric pre-shared key authentication for a site-to-site IKEv2 VPN with remote gateway 5.5.5.5, use the following commands: ciscoasa(conﬁg)# tunnel-group ciscoasa(conﬁg)# tunnel-group ciscoasa(conﬁg-tunnel-ipsec)# ciscoasa(conﬁg-tunnel-ipsec)# 5.5.5.5 type ipsec-l2l 5.5.5.5 ipsec-attributes ikev2 local-authentication pre-shared-key *ciscotestkey* ikev2 remote-authentication pre-shared-key *ciscotestkey*

Conﬁguring Transmission Protection: IKEv1 Phase 2 or IKEv2 Child SA
IKEv1 Phase 2 has only one functional mode, called quick mode, which occurs only after Phase 1 is successfully established. The steps involved in this process are as follows: STEP 1. Conﬁgure an IPv4/IPv6 access control list (ACL) that deﬁnes trafﬁc to be protected by the VPN tunnel. One restriction for successful negotiation is that the crypto ACLs need to be conﬁgured as mirror images of each other on the two VPN gateways and describe exactly the same trafﬁc and have the exact same number of ACE entries. To create an ACL using the ASDM, navigate to Conﬁguration > Site-to-Site VPN > Advanced > ACL Manager and click the Add > Add ACL button followed by Add ACE (see Figure 2-5).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 51 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-5 IPv4 IPsec Access List
To create an IPv4 ACL using the CLI (for example, to protect traffic from local subnet 10.10.10.0/24 to remote subnet 10.10.11.0/24), use the following command: ciscoasa(conﬁg)# access-list IPSEC-ENCRYPT permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 52 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 2. Conﬁgure a crypto map that actually binds together all IKEv1 Phase 2 or IKEv2 child SA required attributes:
■ ■ ■ ■

ACL deﬁned in Step 1. Crypto peer IPv4/IPv6 address, which is a remote VPN gateway. IKEv1 transform set / IKEv2 IPsec proposals, to deﬁne the protocol and algorithms used to protect data trafﬁc. Optionally, enable Perfect Forward Secrecy (PFS) so that a new Difﬁe-Hellman (D-H) exchange takes place to derive IKEv1 Phase 2 / IKEv2 child SA keys, instead of deriving it from the IKEv1 Phase 1 / IKEv2 parent SA master key. The interface where crypto map is applied needs to be the interface where the VPN is terminated on the ASA, closest to the remote VPN gateway.

■

To create a transform set using the ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > IPsec Proposals (Transform Sets) and click Add (see Figure 2-6). To create a transform set for IKEv1 or IPsec proposal for IKEv2 with CLI, use the following commands: ciscoasa(conﬁg)# crypto ipsec ikev1 transform-set ESP-SHA-AES esp-aes-256 esp-sha-hmac ciscoasa(conﬁg)# crypto ipsec ikev2 ipsec-proposalESP-SHA-AES ciscoasa(conﬁg-ipsec-proposal)# protocol esp encryption aes-256 aes-192 3des ciscoasa(conﬁg-ipsec-proposal)# protocol esp integrity sha-1 md5

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 53 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-6 IPsec Proposals (Transform Sets)
To configure crypto maps using the ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > Crypto Maps and click Add. Note that both IKEv1 and IKEv2 have been configured. For IKEv2, even the crypto map pre-shared key has been configured in case asymmetric is authentication configured (see Figure 2-7).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 54 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-7 Static Crypto Map
To configure the crypto map and transform set using the CLI, use the following commands: ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# crypto crypto crypto crypto crypto crypto crypto map map map map map map map TEST-MAP TEST-MAP TEST-MAP TEST-MAP TEST-MAP TEST-MAP TEST-MAP 1 set peer 5.5.5.5 1 set pfs group2 1 set ikev1 transform-set ESP-SHA-AES 1 set ikev2 ipsec-proposal ESP-SHA-AES 1 set ikev2 pre-shared-key 0 *datanetsystems* 1 match address IPSEC-ENCRYPT interface outside

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 55 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

If you have a pre-deployed site-to-site IKEv1 IPsec VPN and want to migrate it to an IKEv2 IPsec VPN, you can instantly migrate the configuration with this command: ciscoasa(conﬁg)# migrate l2l

To configure a site-to-site IPsec VPN using the ASDM, you have three options:
■ ■ ■

Start the IPsec VPN Wizard from ASDM > Wizards > VPN Wizards > Site-to-site VPN Wizard. Go to Conﬁguration > Site-to-Site VPN > Advanced and Tunnel Groups, Crypto Maps, IKE Policies, ACL Manager. Go to Conﬁguration > Site-to-Site VPN > Connection Proﬁles.

Troubleshooting Cisco ASA Adaptive Security Appliance Siteto-Site VPNs
Two possible problems may appear on a VPN connection in general:
■ ■

A VPN tunnel does not get established. A tunnel is established, but trafﬁc does not ﬂow through it.

This needs further investigation, using a systematic approach, to identify the problem. If VPN tunnel does not get established, follow these steps: STEP 1. Make sure the VPN gateways have connectivity with each other and UDP port 500 for IKEv1/IKEv2 is allowed between the two VPN gateways; use ping and traceroute and verify routing tables. STEP 2. To trigger the IPsec session initiation, trafﬁc identiﬁed by the ACL mapped in the crypto map (called crypto ACL) needs to be routed out on the interface where the crypto map is applied. STEP 3. Verify IKEv1 Phase 1 or IKEv2 parent SA negotiation. If state is not MM_ACTIVE (see Example 2-1), verify the IKE policy conﬁguration on both ends. Use the debug crypto ikev1 or debug crypto ikev2 protocol commands to investigate the negotiation issues.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 56 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Example 2-1

IKE Phase 1

ciscoasa# show crypto ikev1 sa detail Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1 1 IKE Peer: 5.5.5.5 Type : L2L Rekey : no Encrypt : aes Auth : preshared Lifetime Remaining: 29763

Role : State : Hash : Lifetime:

initiator MM_ACTIVE SHA 86400

STEP 4. Verify IKEv1 Phase 2 or IKEv2 child SA negotiation. Check that bidirectional SAs exist (see Example 2-2). If SAs are not established, verify Phase 2 conﬁguration on both ends. Use the debug crypto ipsec command to investigate the negotiation issues.

Example 2-2

IKE Phase 2

ciscoasa# show crypto ipsec sa peer 5.5.5.5 peer address: 5.5.5.5 Crypto map tag: TEST-MAP, seq num: 1, local addr: 1.1.1.1 access-list IPSEC-ENCRYPT extended permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0 local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.10.11.0/255.255.255.0/0/0) current_peer: 5.5.5.5 #pkts encaps: 242227, #pkts encrypt: 242300, #pkts digest: 242300 #pkts decaps: 295661, #pkts decrypt: 295661, #pkts verify: 295661 local crypto endpt.: 1.1.1.1, remote crypto endpt.: 5.5.5.5 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 0773F60F current inbound spi : 604B711F

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 57 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

inbound esp sas: spi: 0x604B711F (1615556895) transform: esp-3des esp-sha-hmac no compression in use settings ={L2L, Tunnel, } slot: 0, conn_id: 8192, crypto-map: TEST-MAP sa timing: remaining key lifetime (kB/sec): (3914842/20940) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0xFFFFFFFF 0xFFFFFFFF outbound esp sas: spi: 0x0773F60F (125040143) transform: esp-3des esp-sha-hmac no compression in use settings ={L2L, Tunnel, } slot: 0, conn_id: 8192, crypto-map: TEST-MAP sa timing: remaining key lifetime (kB/sec): (3914823/20940) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001

If a VPN tunnel is established but traffic is not flowing through, follow these steps: STEP 1. Is sysopt-connection-permit-vpn enabled? If not, make sure that inbound ACL permits decrypted trafﬁc. STEP 2. Is Network Address Translation (NAT) enabled on the VPN gateways? If yes, verify that the VPN trafﬁc bypasses NAT rules (NAT exemption for pre-8.3 ASA software version or Identity NAT for post-8.3 version); or if NAT is desired for VPN trafﬁc, verify that the crypto ACL matches on the translated trafﬁc. STEP 3. Issue the show crypto ipsec sa command and verify whether there are both encrypted and decrypted packets. If not, verify whether devices in the path are dropping Encapsulation Security Protocol (ESP) or User Datagram Protocol (UDP) if ESP trafﬁc is UDP encapsulated. STEP 4. Verify that the connection is established with show conn.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 58 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Deploying Certiﬁcate Authentication in Site-to-Site IPsec VPNs
The methodology for site-to-site VPN configuration remains the same, except that digital certificate peer authentication is being used. Because validity of certificates is important, peers need to be Network Time Protocol (NTP) synchronized. Deployment tasks are as follows: STEP 1. Generate an RSA private/public key pair: ciscoasa(conﬁg)# hostname ciscoasa ciscoasa(conﬁg)# domain-name cisco.com ciscoasa(conﬁg)# crypto key generate rsa general-keys modulus 2048

STEP 2. Authenticate the certiﬁcate authority (CA). (That is, install the CA certiﬁcate.) To authenticate the CA using the ASDM, navigate to Conﬁguration > Site-to-Site VPN > Certiﬁcate Management > CA Certiﬁcates and click Add(see Figure 2-8). Options are via Simple Certiﬁcate Enrollment Protocol (SCEP) or importing it from a base64/PEM (privacy enhanced mail) format.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 59 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-8 CA Authentication
To authenticate CA via SCEP using the CLI, use the following code: ciscoasa(conﬁg)# crypto ca trustpoint TEST-CA ciscoasa(conﬁg-ca-trustpoint)# enrollment url http://1.1.1.1/certsrv/mscep/mscep.dll ciscoasa(conﬁg)# crypto ca authenticate TEST-CA

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 60 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 3. Enroll with the CA. (That is, install the identity certiﬁcate for the ASA.) To enroll with the CA, a certiﬁcate request must be sent and then the identity certiﬁcate installed. To perform a certiﬁcate request using the ASDM, navigate to Conﬁguration > Site-to-Site VPN > Certiﬁcate Management > Identity Certiﬁcates and click Add(see Figure 2-9). Enrollment options are via SCEP or manual (import from the CLI or GUI). Whereas SCEP allows for automatic enrollment (after certiﬁcate request is completed, the certiﬁcate can be automatically issued by the CA and installed by ASA), manual enrollment needs both the certiﬁcate request and install to be completed by the administrator.

Figure 2-9 Certiﬁcate Request
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 61 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

To install the digital certiﬁcate using the ASDM, navigate to Conﬁguration > Site-to-Site VPN > Certiﬁcate Management > Identity Certiﬁcates and click the Install button (see Figure 2-10).

Figure 2-10 Install Identity Certiﬁcate

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 62 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

To enroll with the CA manually using the CLI, use the following commands: ciscoasa(conﬁg)# crypto ca trustpoint TEST-CA ciscoasa(conﬁg-ca-trustpoint)# enrollment terminal ciscoasa(conﬁg-ca-trustpoint)# subject-name CN=TEST-ASA ciscoasa(conﬁg)# crypto ca enroll TEST-CA noconﬁrm ciscoasa(conﬁg)# crypto ca import TEST-CA certiﬁcate nointeractive

STEP 4. Conﬁgure IKEv1 Phase 1 for certiﬁcate authentication. IKEv2 policies do not specify authentication. STEP 5. Conﬁgure the connection proﬁle (tunnel group) for certiﬁcate authentication. STEP 6. Conﬁgure transmission protection: IKEv1 Phase 2 or IKEv2 child SA. STEP 7. Optionally, deﬁne certiﬁcate-to-connection proﬁle maps. STEP 8. Verify certiﬁcates and test tunnel functionality. Steps 4, 5, and 6 are all performed at the same time by using the connection profile method of configuring site-to-site VPNs. To perform the site-to-site VPN configuration using the ASDM, navigate to Configuration > Site-to-Site VPN > Connection Profiles and click Add (see Figures 2-11 and 2-12). In the Basic tab, you can specify the following:
■ ■ ■ ■ ■

Peer IP address, which can be IPv4 or IPv6 Connection name, important to map a VPN session to a connection proﬁle Interface on which the tunnel is terminated Protected networks where crypto ACL is conﬁgured; can be IPv4 or IPv6 ACLs IPsec enabling where you attach a group-policy to the VPN session and enable protocols: IKEv1, IKEv2, or both

In the IPsec Settings pane are two tabs, one for IKEv1 and one for IKEv2 settings, where you can configure the following:
■ ■

IKEv1 authentication settings, where either a pre-shared key or device certiﬁcate can be used. IKEv1 encryption algorithms, where Phase 1 and Phase 2 algorithms are conﬁgured.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 63 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■

IKEv2 authentication settings, where either a pre-shared key or device certiﬁcate can be used for the local device. For the remote device, both methods can be speciﬁed. IKEv2 encryption algorithms, where IKE policies and IPsec proposals are conﬁgured.

Figure 2-11 Connection Proﬁle

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 64 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-12 Connection Proﬁle (IKE v2 Settings)
Under Advanced > Crypto Map Entry(see Figure 2-13), you can specify the following:
■

Priority, a number between 1 and 65,535, which is signiﬁcant for the order of entry processing within the crypto map, entries being inspected from low to high priority values. Any incoming IKE VPN session is compared to crypto map entries conﬁgurations, starting from lower priority values until a match for the remote peer is found. Enable or disable PFS. Enable Network Address Translation – Traversal (NAT-T). Enable Reverse Route Injection (RRI). IPsec SA lifetime deﬁned as a time period or trafﬁc volume or both. Connection type (bidirectional, answer-only, or originate-only), bidirectional being selected so that each VPN gateway can initiate the VPN session. IKEv2 supports only bidirectional mode. Conﬁgure the crypto map pre-shared key, only for IKEv2 sessions. Select a CA certiﬁcate so that ASA can validate CA signatures from remote VPN gateways’ received identity certiﬁcates. Specify IKEv1 Phase 1 mode, main or aggressive. If aggressive is used, the D-H group can also be selected.

■ ■ ■ ■ ■ ■ ■ ■

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 65 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-13 Connection Proﬁle Crypto Map Entry
Under Advanced > Tunnel Group(see Figure 2-14), you can specify the following:
■ ■ ■

Enable sending of certiﬁcate chain to the remote VPN gateway IKE peer ID validation IKE DPD/keepalive settings

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 66 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-14 Connection Proﬁle Tunnel Group
To perform site-to-site IKEv1 and IKEv2 IPv4 VPN configuration using the CLI, use the following commands: ciscoasa(conﬁg) # access-list IPSEC-ENCRYPT extended permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0 ciscoasa(conﬁg)# tunnel-group 5.5.5.5 type ipsec-l2l ciscoasa(conﬁg)# tunnel-group 5.5.5.5 ipsec-attributes ciscoasa(conﬁg-tunnel-ipsec)# ikev1 trust-point TEST-CA

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 67 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ciscoasa(conﬁg-tunnel-ipsec)# ikev2 local-authentication certiﬁcate TEST-CA ciscoasa(conﬁg-tunnel-ipsec)# ikev2 remote-authentication certiﬁcate ciscoasa(conﬁg-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2 ciscoasa(conﬁg)# crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ciscoasa(conﬁg)# crypto ipsec ikev2 ipsec-proposalESP-SHA-AES ciscoasa(conﬁg-ipsec-proposal)# protocol esp encryption aes-256 aes-192 3des ciscoasa(conﬁg-ipsec-proposal)# protocol esp integrity sha-1 md5 ciscoasa(conﬁg)# crypto map TEST-MAP 10 set trustpoint TEST-CA ciscoasa(conﬁg)# crypto map TEST-MAP 10 match address IPSEC-ENCRYPT ciscoasa(conﬁg)# crypto map TEST-MAP 10 set pfs group2 ciscoasa(conﬁg)# crypto map TEST-MAP 10 set peer 5.5.5.5 ciscoasa(conﬁg)# crypto map TEST-MAP 10 set ikev1 transform-set ESP-3DES-SHA ciscoasa(conﬁg)# crypto map TEST-MAP 10 set ikev2 ipsec-proposal ESP-SHA-AES ciscoasa(conﬁg)# crypto map TEST-MAP interface outside ciscoasa(conﬁg)# crypto ikev1 policy 1 ciscoasa(conﬁg-isakmp-policy)# encryption 3des ciscoasa(conﬁg-isakmp-policy)# hash sha ciscoasa(conﬁg-isakmp-policy)# group 2 ciscoasa(conﬁg-isakmp-policy)# authentication rsa-sig ciscoasa(conﬁg-isakmp-policy)# lifetime 86400 ciscoasa(conﬁg)# crypto ikev2 policy 1 ciscoasa(conﬁg-isakmp-policy)# prf sha512 sha md5 ciscoasa(conﬁg-isakmp-policy)# encryption aes-256 aes-192 3des ciscoasa(conﬁg-isakmp-policy)# integrity sha512 sha md5 ciscoasa(conﬁg-isakmp-policy)# group 5 2 ciscoasa(conﬁg-isakmp-policy)# lifetime 7200 ciscoasa(conﬁg)# crypto ikev1 enable outside ciscoasa(conﬁg)# crypto ikev2 enable outside

Cisco ASA needs to map an IKEv1/IKEv2 VPN tunnel to a connection profile (tunnel group) to identify preestablishment settings of the tunnel. For this, ASA uses the following order of preference for connection requests with digital certificate authentication: 1. 2. 3. 4. Certiﬁcate map to connection proﬁle mapping. This option is disabled by default and allows to match on certain attributes from identity certiﬁcates and to map VPN sessions to connection proﬁles based on it. OU from the received identity certificate of the VPN peer. IKE identity presented. Peer IP address.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 68 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

You can view these policies with the show running-config all tunnel-group-map command. If it fails to match on any of these rules, the connection request lands on the default Defaultl2LGroup tunnel group. Deploying certificate map to connection profile mapping requires a three-step process: STEP 1. Enable this option. Using ASDM, navigate to Conﬁguration > Site-to-Site VPN > Advanced > Certiﬁcate to Connection Proﬁle Maps > Policy and check the Use the Conﬁgured Rules to Match a Certiﬁcate to Connection Proﬁle check box. STEP 2. Conﬁgure a certiﬁcate map and bind it to desired connection proﬁle. Using ASDM, navigate to Conﬁguration > Site-to-Site VPN > Advanced > Certiﬁcate to Connection Proﬁle Maps > Rules and click Add under Certiﬁcate to Connection Proﬁle Maps (see Figure 2-15).

Figure 2-15 Certiﬁcate to Connection Proﬁle Maps
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 69 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 3. Conﬁgure mapping criteria, by matching on one or multiple certiﬁcate attributes. If these conditions are satisﬁed, the VPN session is mapped to the connection proﬁle speciﬁed in the previous step. Using ASDM, navigate to Conﬁguration > Site-to-Site VPN > Advanced > Certiﬁcate to Connection Proﬁle Maps > Rules and click Add under Mapping Criteria (see Figure 2-16).

Figure 2-16 Certiﬁcate to Connection Proﬁle Mapping Criteria
To enable and configure certificate to connection profile mapping using the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group-map enable rules ciscoasa(conﬁg)# crypto ca certiﬁcate map TEST-MAP 10 ciscoasa(conﬁg-ca-cert-map)# subject-name attr cn eq cisco ciscoasa(conﬁg)#tunnel-group-map TEST-MAP 10 5.5.5.5

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 70 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Deploying Cisco Remote-Access IPsec VPN Clients
Cisco ASA supports IKEv1 remote-access IPsec VPN sessions through the use of Cisco IPsec VPN Client software and IKEv2 remote-access IPsec VPN sessions through the use of Cisco AnyConnect Secure Mobility Client (minimum Version 3.0).

Note
It seems that in the latest versions Help and Uninstall VPN Client are no longer available in the Programs menu. Help is available as a menu option in the GUI, though.

Evaluating Legacy Cisco IPsec VPN Client Features
Cisco IPsec VPN Client software allows for IKEv1 remote-access IPsec VPN termination on Cisco ASA or Cisco IOS platforms. Once installed, the following applications are available in the Programs menu:
■ ■ ■ ■

Help, online manual instructions. Set MTU, which enables you to change the maximum transmission unit (MTU) for VPN connections. Upon installation, IPsec VPN Client changes the system MTU to 1300 to accommodate for the overhead without the need for fragmentation. VPN Client, which allows for connection proﬁle conﬁguration, certiﬁcate enrollment, and session initiation. Uninstall VPN Client, which enables you to safely remove the software from the system, retaining connection proﬁles and certiﬁcate conﬁgurations.

Cisco IPsec VPN Client supports the following operating systems:
■ ■ ■ ■

Microsoft Windows 2000, XP, Vista, and 7 (32-bit and 64-bit versions) Linux (Intel) Solaris Ultra SPARC (32-bit and 64-bit versions) Mac OS X 10.4 and 10.5

Cisco IPsec VPN Client is compatible with the following Cisco products:
■ ■

Cisco IOS platforms Release 12.2(8)T and later Cisco ASA Release 7.0 and later

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 71 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■

Cisco PIX Release 6.0 and later Cisco 7600/6500 VPN SPA IOS Release 12.2SX and later

Cisco IPsec VPN Client supports multiple algorithms and configuration options, as described in Table 2-1.

Table 2-1 IPsec VPN Client Attributes
Note
VPN Client supports D-H group 5 only if “Certiﬁcate Authentication” or “Mutual Group Authentication” is being used along with digital certiﬁcates. IPsec Attribute Description

IKE Phase 1 main and aggressive modes Authentication algorithms Authentication modes

Negotiation for IKE Phase 1 HMAC with MD5 HMAC with SHA-1 Pre-shared keys Mutual group authentication X.509 identity certiﬁcates

D-H groups

Group1 – 768 bit Group2 – 1024 bit Group5 – 1536 bit

XAUTH (Extended Authentication) Mode conﬁguration Tunnel encapsulation modes

Capability of user authentication ISAKMP conﬁguration method IPsec over UDP IPsec over TCP IPsec over UDP NAT-T

IP compression using LZS

Data-compression algorithm

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 72 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Installing and Conﬁguring Legacy Cisco IPsec VPN Client Software
Once Cisco IPsec VPN Client is installed and the system is restarted, configuration tasks are as follows: STEP 1. Create a new connection entry, similar to a connection proﬁle on ASA. To create a new connection in Windows, navigate to Start > All Programs > Cisco Systems VPN Client > VPN Client and click Connection Entries > New (see Figure 2-16). STEP 2. Conﬁgure the basic connection properties:
■ ■ ■ ■

Enter the connection name in the Connection Entry ﬁeld. Optionally, enter a description in the Description ﬁeld. Enter the hostname or IP address of the VPN gateway in the Host ﬁeld. On the Authentication tab, choose the authentication method. For certiﬁcate authentication, select the identity certiﬁcate; for group authentication, complete the name and password, which are actually the connection proﬁle name and IKEv1 pre-shared key conﬁgured on the ASA.

Figure 2-16 IPsec VPN Client Connection Entry Conﬁguration

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 73 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 3. Optionally, conﬁgure transport properties by navigating to the Transport tab and
■ ■ ■

Enabling/disabling IPsec over UDP or IPsec over TCP encapsulation. Allowing local LAN access (to local network resources), if is permitted also by the VPN gateway. Conﬁguring the peer response timeout, which is actually the DPD timer.

STEP 4. Optionally, conﬁgure backup server properties by navigating to the Backup Servers tab and
■

Enabling/disabling the use of backup servers (that is back up [or not] the VPN gateways, in case the primary does not respond). If enabled, click Add for additional VPN gateways and specify the name or IP address.

STEP 5. Optionally, conﬁgure dial-up properties by navigating to the Dial-Up tab and
■ ■

Enabling/disabling the connection to the Internet via dial-up Choosing between Microsoft dial-up and a third-party application

Conﬁguring Advanced Proﬁle Settings
Each of the previously mentioned entries from the connection profile is saved in a PCF file in Program Files\Cisco Systems\VPN Client\Profiles\ on Windows and /etc/CiscoSystemsVPNClient/Profiles/ on Linux. You can configure additional settings by editing the PCF file, such as the following:
■ ■ ■

Username and password asked in IKEv1 Phase 1.5, called XAUTH Split DNS settings DN certiﬁcate veriﬁcation for the VPN peer

On Microsoft platforms, additional configurable parameters are available by editing the PCF file, such as the following:
■ ■ ■

Dial-up networking phonebook entry. Command string for connecting through an ISP. NT domain.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 74 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■ ■ ■

Logging credentials for Microsoft network. Default IKE ports of 500/4500 can be changed. Enable Force Network Login. Enable or disable browser proxy settings pushed from the VPN gateway. An IPsec session cannot be completed through a proxy because the client does not support it.

Once the VPN client is installed, a file called vpnclient.ini is created in Program Files\Cisco Systems\VPN Client\Profiles\ on Windows and /etc/CiscoSystemsVPNClient/Profiles/ on Linux. It contains systemwide settings applicable to all users, such as the following:
■ ■ ■ ■ ■ ■

Start before logon settings Automatic connection settings to a speciﬁc connection entry upon startup Automatic disconnect settings upon user logoff Certiﬁcate enrollment settings Automatic application launch upon successful VPN session connection Transparent tunneling settings

Deploying Basic IKEv1 Easy VPN Solutions
Overview
In IKEv1 IPsec remote-access VPNs, there are two types of clients:
■ ■

Software clients, namely IPsec VPN Client Hardware clients, like Cisco ASA 5505

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 75 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

In remote-access VPNs, only the VPN server needs to be fully configured. The VPN client is configured basically only, and all security policies are being pushed remotely from the VPN server upon VPN tunnel establishment. This is called Cisco Easy VPN, in that it eases management complexity in VPN deployments on remote locations. In basic, small deployments, pre-shared keys are used for authentication, whereas in large deployments digital certificates are being used to scale. To deploy a basic IKEv1 Easy VPN solution for software clients, complete the following steps: STEP 1. Conﬁgure basic ASA Easy VPN Server features. STEP 2. Conﬁgure group authentication. STEP 3. Optionally conﬁgure extended user authentication (XAUTH). STEP 4. Conﬁgure client network conﬁguration. STEP 5. Conﬁgure basic access control. STEP 6. Conﬁgure the Easy VPN software client, Cisco IPsec VPN Client. STEP 7. Troubleshoot Easy VPN operation.

Conﬁguring Basic Cisco ASA IKEv1 Easy VPN Server Features
The first step is to configure basic Easy VPN Server parameters: STEP 1. Enable IKEv1 and IPsec on desired interfaces.Using ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Proﬁles and select interfaces for IPsec processing. Doing so will also automatically
■ ■ ■ ■ ■

Enable IKEv1 on selected interfaces. Conﬁgure 15 IKEv1 policies Conﬁgure 10 transform sets Create dynamic crypto map rules that use these policies Attach the dynamic crypto map to a static crypto map and apply it on enabled interfacesIf conﬁguration is done via the CLI, you need to manually create IKEv1 policies, transform sets, and dynamic crypto maps: ciscoasa(conﬁg)# crypto ikev1 enable outside ciscoasa(conﬁg)# crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 76 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ciscoasa(conﬁg)# crypto ikev1 policy 1 ciscoasa(conﬁg-isakmp-policy)# authentication pre-share ciscoasa(conﬁg-isakmp-policy)# encryption 3des ciscoasa(conﬁg-isakmp-policy)# hash sha ciscoasa(conﬁg-isakmp-policy)# group 2 ciscoasa(conﬁg-isakmp-policy)# lifetime 86400 ciscoasa(conﬁg)# crypto dynamic-map DYNAMIC-TEST-MAP 65535 set transform-set ESP-3DES-SHA ciscoasa(conﬁg)# crypto map TEST-MAP 65535 ipsec-isakmp dynamic DYNAMIC-TEST-MAP ciscoasa(conﬁg)# crypto map TEST-MAP interface outside

STEP 2. Optionally, tune the IKEv1 policies. If Step 1 was done via the CLI, you already selected IKEv1 Phase 1 policy parameters. Otherwise, if it was done via ASDM, you might want to tune these parameters. To do so, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > IKE Policies, select the IKE policy, and click Edit to make changes or click Add for a new policy. If you modify the default created policies, make sure to match on one of the 14 built-in IKEv1 policies used by Cisco IPsec VPN Client that support pre-shared key authentication. Note that the Cisco IPsec VPN Client at its current version, which is 5.0.7, supports the following IKEv1 policies:
■ ■ ■ ■

7 IKEv1 policies for pre-shared key authentication without XAUTH and 7 for pre-shared key authentication with XAUTH 14 IKEv1 policies for certiﬁcate authentication with XAUTH 12 IKEv1 policies for mutual group authentication 13 IKEv1 policies for certiﬁcate authentication without XAUTH

STEP 3. Optionally, tune the IPsec policy.If Step 1 was done via the CLI, you already selected IPsec policy parameters. Otherwise, if it was done via ASDM, you might want to tune these parameters. To do so, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > Crypto Maps, select the dynamic crypto map entry with priority 65535, and click Edit. Here, you can
■ ■ ■

Add, delete, or modify IKEv1 transform sets and their priority. Enable Perfect Forward Secrecy (PFS). On the Advanced tab, you can manage security association (SA) lifetime by time or trafﬁc volume and enable NAT-T and RRI.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 77 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

In site-to-site VPNs, crypto maps were binding together traffic-protection policies. Because in Easy VPN the IP address of the Easy VPN client is unknown, as is the traffic to be protected (because IPv4 addresses are assigned dynamically to software VPN clients and authorization policies may differ from user to user), dynamic crypto maps are used. With these, the Easy VPN server creates crypto map entries on-the-fly and fills in parameters in the SAs based on the IKE negotiation.

Conﬁguring Group Pre-Shared Key Authentication
Basic Easy VPN authenticates the following:
■ ■

The remote peer through group passwords, called pre-shared keys. Optionally, the remote user based on static passwords or One Time Password (OTP), a process called extended authentication (XAUTH).

To configure group authentication, perform the following tasks: STEP 1. Conﬁgure a group policy.This is not mandatory for this step, but needed later. To create the group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and click Add (see Figure 2-17).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 78 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-17 Add a Group Policy
To create the group policy using the CLI, use the following commands. (The IPv4 address pool is also conﬁgured.) ciscoasa(conﬁg)# group-policy ciscoasa(conﬁg)# group-policy ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-policy)# TEST-GROUP internal TEST-GROUP attributes vpn-tunnel-protocol ikev1 address-pools value TEST-POOL

STEP 2. Conﬁgure a connection proﬁle with pre-shared key authentication and assign the previously created group policy to it. To create the connection proﬁle using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Proﬁles and click Add (see Figure 2-18).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 79 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-18 Add Connection Proﬁle
To create the connection proﬁle using the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-PROFILE type remote-access ciscoasa(conﬁg)# tunnel-group TEST-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy TEST-GROUP ciscoasa(conﬁg-tunnel-general)# address-pool TEST-POOL ciscoasa(conﬁg)# tunnel-group TEST-PROFILE ipsec-attributes ciscoasa(conﬁg-tunnel-ipsec)# ikev1 pre-shared-key 8chn4326cewfgeq

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 80 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Conﬁguring XAUTH
Because group passwords are shared by many users and are more vulnerable to compromise, an additional layer of security is achieved through XAUTH. This is done in IKEv1 Phase 1.5 because it runs after IKEv1 Phase 1 has successfully completed, but before IKEv1 Phase 2. It is enabled by default with each configured connection profile. To configure XAUTH, perform the following tasks: STEP 1. Ensure that XAUTH is enabled in the connection proﬁle.To verify using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Proﬁles, choose the proﬁle, and click Edit. Navigate to Advanced > IPsec > IKE Authentication Mode.To enable it using the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-PROFILE ipsec-attributes ciscoasa(conﬁg-tunnel-ipsec)#isakmp ikev1-user-authentication xauth

STEP 2. If using local user authentication, conﬁgure the user database and credentials.To create a local user and restrict it to only VPN access and no management access using the ASDM, navigate to Conﬁguration > Remote Access VPN > AAA/Local Users > Local Users and click Add (see Figure 2-19).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 81 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-19 User Proﬁle
To create the user using the CLI, use the following commands: ciscoasa(conﬁg)# username TEST-USER password TEST-PASS ciscoasa(conﬁg)# username TEST-USER attributes ciscoasa(conﬁg-username)# service-type remote-access

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 82 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Conﬁguring Client Network Conﬁguration
Additional parameters, such as IPv4 address and DNS servers, are also pushed to the remote IPsec client in Phase 1.5, and this is called mode config (push config). For this, the following parameters are configured on the Easy VPN server: STEP 1. Conﬁgure DNS, WINS servers, and domain name.To conﬁgure these using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies, edit the previously conﬁgured group policy or the default DﬂtGrpPolicy, and go to the Servers tab (see Figure 2-20).

Figure 2-20 Group Policy Settings
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 83 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

To conﬁgure these using the CLI, use the following commands: ciscoasa(conﬁg)# group-policy ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-policy)# TEST-POLICY attributes dns-server value 10.10.10.10 wins-server value 10.10.10.10 default-domain value cisco.com

STEP 2. Conﬁgure the IPv4 address assignment method. You can assign IP addresses to VPN clients in a number of ways, all of which are enabled by default. The order of processing is as follows:
■ ■ ■

Authentication server assigned (local or remote AAA) External DHCP server Internal address pools (speciﬁed in connection proﬁle or group policy)

To modify or view these settings using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Address Assignment > Assignment Policy. Example 2-3 lists the commands necessary to view these via the CLI.

Example 2-3

Address Assignment Methods

ciscoasa# show running-conﬁg all vpn-addr-assign vpn-addr-assign aaa vpn-addr-assign dhcp vpn-addr-assign local reuse-delay 0

STEP 3. Optionally, conﬁgure an IPv4 address pool and assign it to the group policy. To conﬁgure an IPv4 address pool using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Address Assignment > Address Pools and click Add. To assign it to the connection proﬁle, modify the Address Pools ﬁeld value from the group policy on the General tab. To conﬁgure it using the CLI, use the following command: ciscoasa(conﬁg)# ip local pool TEST-POOL 10.11.11.1-10.11.11.100 mask 255.255.255.255

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 84 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 4. Optionally, assign static IP addresses to users.To statically conﬁgure an IP address to users using the ASDM, navigate to Conﬁguration > Remote Access VPN > AAA/Local Users > Local Users, select the user, click Edit, and enter the IP address in the Dedicated IP Address section under the VPN Policy tab.To conﬁgure it using the CLI, use the following commands: ciscoasa(conﬁg)# username TEST-USER attributes ciscoasa(conﬁg-username)# vpn-framed-ip-address 10.11.11.5 255.255.255.255

Conﬁguring Basic Access Control
You can control and restrict IKEv1 IPsec VPN client remote resource access in multiple ways after the session has been established:
■

Conﬁgure interface bypass. This disables the checking of incoming decrypted VPN trafﬁc against inbound ACLs and is the default setting. You can view is using the ASDM by navigating to Conﬁguration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Proﬁles. To view it using the CLI, use the command show running-conﬁg all sysopt. To disable it via the CLI, thus forcing decrypted packets to be checked against inbound interface ACL or global ACL, use the following commands: ciscoasa(conﬁg)# no sysopt connection permit-vpn

■

■

Conﬁgure interface ACLs. If ACL bypass is disabled, decrypted trafﬁc needs to be speciﬁcally allowed in the inbound ACLs. This is not commonly used because attackers might spoof VPN clients’ IP addresses and get access to restricted resources. Another option is to apply the inbound ACL with the per-user-override option. If this is combined with downloadable ACLs from a AAA server for the VPN session, the dynamic ACLs from AAA override the inbound ACL on the interface and trafﬁc is allowed. To conﬁgure it using the CLI, use the following commands: ciscoasa(conﬁg)#access-group OUTSIDE_IN in interface outside per-user-override

■

Conﬁgure per-group policy ACLs. If this option is used, it applies to all VPN sessions that inherit this group policy. To conﬁgure this using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies, click Edit on the selected group policy, and modify the IPv4Filter section on the General tab.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 85 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

To conﬁgure it using the CLI, use the following commands: ciscoasa(conﬁg)# group-policy TEST-POLICY attributes ciscoasa(conﬁg-group-policy)# vpn-ﬁlter value FILTER-ACL

■

Conﬁgure per-user ACLs. This option has the advantage that the ﬁltering is applied only to the respective user. To conﬁgure this using the ASDM, navigate to Conﬁguration > Remote Access VPN > AAA/Local Users > Local Users, select the user, click Edit, and on the VPN Policy tab, modify the IPv4Filter section. To conﬁgure it using the CLI, use the following commands: ciscoasa(conﬁg)# username TEST-USER attributes ciscoasa(conﬁg-username)# vpn-ﬁlter value FILTER-ACL

■

Conﬁgure split tunneling. Split tunneling allows for speciﬁcally deﬁned trafﬁc to ﬂow through the tunnel, while the rest bypasses the tunnel. First of all, split tunneling needs to be enabled at the group policy level (by default, all trafﬁc is tunneled) and trafﬁc to be tunneled speciﬁed in an ACL (with only standard ACLs being supported). To conﬁgure a standard ACL using the ASDM, navigate to Conﬁguration > Firewall > Advanced > Standard ACL and click Add. To modify group policy settings, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and click Edit on the selected group policy. Navigate to Advanced > Split Tunneling, modify the Policy entry to Tunnel Network List Below and select the standard ACL in the Network List area (see Figure 2-21).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 86 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-21 Split Tunneling
To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy TEST-POLICY attributes ciscoasa(conﬁg-group-policy)# split-tunnel-policy tunnelspeciﬁed ciscoasa(conﬁg-group-policy)# split-tunnel-network-list value SPLIT-ACL

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 87 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Conﬁguring the Cisco VPN Client
To establish the IPsec session between Easy VPN client and server, the following are performed on the client side: STEP 1. Conﬁgure the VPN client for basic connection. For this, start the IPsec VPN client and
■ ■ ■ ■

Click New to create a connection entry. Give it a name and specify the Easy VPN server IP address or hostname. Choose group authentication and conﬁgure the group name (connection proﬁle from the Easy VPN server) and password (pre-shared key from the Easy VPN server). Conﬁgure, if needed, NAT-T, backup servers, or dial-up settings.

STEP 2. Initiate the session:
■

Choose the connection created in Step 1 and click Connect. Enter the username and password if XAUTH was conﬁgured on the ASA.

STEP 3. Verify whether the connection is successfully established. You can verify VPN sessions on both the client and server side:
■ ■

On the client side, right-click the VPN client tray icon and choose Statistics to check on parameters such as IP address assigned, encryption algorithms, and secured routes (see Figure 2-22). On the server side, use the command show vpn-sessiondb ra-ikev1-ipsec to see IKEv1 IPsec remote VPN sessions and verify tunnel parameters.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 88 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-22 IPsec VPN Client Statistics

Troubleshoot IKEv1 Easy VPN Operation
You can perform Easy VPN troubleshooting on both the server and client side. Most issues are logged by default on Cisco ASA and the VPN Client, with debugging being required to investigate IKEv1 Phase 1, Phase 1.5, and Phase 2 negotiation issues. As mentioned earlier with regard to site-to-site VPNs, troubleshooting can be categorized as follows: If a VPN session does not get established
■ ■ ■ ■ ■ ■

Make sure that basic IP connectivity exists between the Easy VPN server and client (ping, traceroute, nslookup, dig). Verify that IKEv1 Phase 1 and IKEv1 Phase 2 policies match between VPN endpoints. Use debug crypto ikev1 and debug crypto ipsec to investigate IKEv1 negotiation issues. Verify XAUTH and user credentials. Check on connection proﬁle and group policy conﬁguration. Verify correct IPv4 addressing assignment policy.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 89 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

If traffic does not flow through the tunnel
■ ■ ■ ■ ■ ■ ■

Make sure that no device along the path drops the ESP or UDP/TCP port used for ESP encapsulation. If there is a NAT device along the path, make sure NAT-T is conﬁgured and negotiated correctly. If split tunneling is enabled, verify client-protected routes. Verify encrypted and decrypted packets on both server and client to observe in which direction packets are dropped. Verify correct access control measures implemented on ASA. Verify that VPN client trafﬁc is not subject to NAT policies; or if NAT control is enabled, conﬁgure NAT exemptions. Check proper routing to VPN client addresses from behind the ASA.

Deploying Advanced Authentication in Cisco Easy VPN Solutions
In addition to the group authentication method, Easy VPN supports two additional advanced authentication methods for the VPN client:
■ ■

Identity certiﬁcate authentication Mutual group authentication or hybrid authentication

Deploying Cisco VPN Client Identity Certiﬁcate Authentication
Cisco IPsec VPN Clients support enrollment with a CA/RA from the GUI so that both an identity certificate and the CA root certificates are obtained. For certificate authentication to be configured, follow this procedure: STEP 1. Enroll the IPsec VPN Client in the PKI. STEP 2. Enroll the ASA in the PKI (just like in site-to-site VPN).
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 90 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 3. Create or modify the existing IPsec VPN Client connection entry to use certiﬁcate authentication. STEP 4. Create or modify the existing connection proﬁle on ASA to use certiﬁcate authentication (just as in site-to-site VPN). Cisco IPsec VPN Client supports two methods for CA enrollment:
■ ■

Online through SCEP Ofﬂine through a ﬁle-based certiﬁcate request

To enroll online, follow these steps: STEP 1. Open the client, navigate to the Certiﬁcates tab, and click Enroll. STEP 2. Choose the Online option and provide the CA domain and CA URL (in the form http//IP-ADDRESS/certsrv/ mscep/mscep.dll for the Microsoft CA) and the challenge password, if required by the CA (see Figure 2-23). STEP 3. Click the Next button and conﬁgure the certiﬁcate attributes: Common Name, Department, Company, State, Country, E-mail, IP Address, and Domain. Then, click Enroll to complete the process (see Figure 2-24). Depending on settings on the CA side, the certiﬁcate might be automatically approved or may need manual approval. STEP 4. Once the identity certiﬁcate is issued, navigate to the Connection Entries tab and modify the existing entry or add a new entry to use certiﬁcate authentication.

Figure 2-23 IPsec VPN Client CA Enrollment
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 91 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-24 IPsec VPN Client CA Enrollment

Conﬁguring Hybrid Authentication
Both previous authentication types were symmetrical, in that the client and server authenticated each other using the same method. Hybrid authentication is asymmetrical:
■ ■

The Easy VPN server authenticates the client by the group password, the same as in pre-shared key authentication. The Easy VPN client authenticates the server by the group password, except that the exchange is digitally signed by a credential that only the ASA holds (its RSA private key).

For the client to verify the signature, ASA sends to the client its identity certificate (containing the public key that corresponds to its private key). Self-signed identity certificates on ASA are not supported, so the VPN client needs to have the CA certificate installed to verify the ASA’s identity certificate. To configure hybrid authentication, perform the following tasks: STEP 1. Enroll the ASA in PKI (same as site-to-site VPN); the client does not need to be enrolled.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 92 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

STEP 2. Enable hybrid authentication in the connection proﬁle on the ASA. To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Proﬁles and edit the selected proﬁle. Navigate further to Advanced > IPsec > IKE Authentication Mode and choose Hybrid XAUTH. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP ipsec-attributes ciscoasa(conﬁg-tunnel-ipsec)#isakmp ikev1-user-authentication hybrid

STEP 3. Conﬁgure the VPN client connection entry. VPN client conﬁguration is similar to the group authentication method:
■ ■ ■ ■ ■

Create a new connection entry or modify an existing one. If a new entry, give it a name and provide the IP address or hostname of the VPN gateway. Choose Mutual Group Authentication, and the client prompts to import the CA certiﬁcate in the VPN Client Certiﬁcate Store. Conﬁgure the group name and password (just like in pre-shared key authentication). Conﬁgure, optionally, other settings such as NAT-T, backup server, and dial-up proﬁles.

Deploying Advanced PKI Integration
To minimize the risk of compromised or expired identity certificates, a solution needs to provide a method for revoking certificates and verifying certificate validity:
■ ■ ■

Certiﬁcate revocation lists (CRL) Online Certiﬁcate Status Protocol (OCSP) AAA user authorization via RADIUS based on identity certiﬁcate

To configure a revocation-checking policy using the ASDM, navigate to Configuration > Remote Access VPN > Certificate Management > CA Certificates, select the CA certificate used to verify client certificates, and click Edit:
■

On the Revocation Check tab, make sure that the Check Certiﬁcates for Revocation radio button is checked and select one or both methods: CRL/OCSP.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 93 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■ ■

On the CRL Retrieval Policy tab, you can use a static URL or distribution point from the certiﬁcate. For the CRL Retrieval Method, select one or more options (LDAP, HTTP, SCEP). In the OCSP Rules tab, conﬁgure OCSP rules, only if you’ve selected OCSP in previous step.

To configure revocation checking with CRL using HTTP via the CLI, use the following commands: ciscoasa(conﬁg)# crypto ca trustpoint TEST-CA ciscoasa(conﬁg-ca-trustpoint)# revocation-check crl none ciscoasa(conﬁg-ca-trustpoint)# crl conﬁgure ciscoasa(conﬁg-ca-crl)# no protocol ldap ciscoasa(conﬁg-ca-crl)# no protocol scep ciscoasa(conﬁg-ca-crl)# protocol http

To configure AAA certificate authorization using the ASDM, follow these steps: STEP 1. Conﬁgure the RADIUS server.Using ASDM, navigate to Conﬁguration > Remote Access VPN > AAA/Local Users > AAA Server Groups, add or edit an existing RADIUS server, and complete the Common Password ﬁeld with the password that will be sent to the RADIUS server along with the username extracted from the certiﬁcate. STEP 2. Conﬁgure certiﬁcate authorization in the connection proﬁle. Using ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles and edit the desired profile. Navigate further to Advanced > Authorization and select the previously configured RADIUS server group, check the Users Must Exist in the Authorization Database to Connectoption (see Figure 2-25), and specify one certificate attribute to be used as username. (CN is used most often.)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 94 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-25 AAA Certiﬁcate Authorization
To configure AAA certificate authorization via the CLI, use the following commands: ciscoasa(conﬁg)# aaa-server TEST-RADIUS protocol radius ciscoasa(conﬁg)# aaa-server TEST-RADIUS (inside) host 10.10.10.10

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 95 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ciscoasa(conﬁg-aaa-server-host)# radius-common-pw cisco ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authorization-required ciscoasa(conﬁg-tunnel-general)# username-from-certiﬁcate CN ciscoasa(conﬁg-tunnel-general)# authorization-server-group TEST-RADIUS

Troubleshooting PKI Integration
To troubleshoot remote-access client-connectivity issues, you use the same tools and methodologies discussed earlier. Complexity added by PKI integration can lead to the following additional problems that might inhibit successful IPsec connection:
■ ■ ■

The connection proﬁle is not correctly conﬁgured for PKI, so the session might land on the default remote-access group of DefaultRAGroup. Revocation-checking servers are not accessible, and fallback on the None revocation method is not conﬁgured. In this case, the ASA rejects the connection. The certiﬁcate is expired or revoked.

If AAA certificate authorization has been implemented, make sure that the RADIUS server is correctly configured and accessible and that the required username/passwords are created on it.

Deploying the Cisco ASA 5505 as an IKEv1 Easy VPN Hardware Client
Choosing Easy VPN Hardware Client Modes
The following Cisco equipment can serve the role of IKEv1 Easy VPN hardware clients. (IKEv2 is not supported.)
■ ■

ASA 5505 PIX 501 or 506E
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 96 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■ ■

800 series routers 1700, 1800, 1900 series routers 2800, 2900, 3800, 3900 series routers

The advantage of using hardware VPN clients rather than software VPN clients in a Cisco IKEv1 Easy VPN solution is that hardware clients can secure traffic from multiple users behind them by using only one IPsec session. The advantage of using Easy VPN with hardware clients rather than regular site-to-site VPN is the minimal configuration required on the hardware client to create the tunnel. When ASA performs the role of Easy VPN hardware client, also called Easy VPN Remote, it can function in two modes:
■ ■

Client mode, in which all users/devices behind the ASA use Network Address Translation (NAT) or Port Address Translation (PAT) when trafﬁc passes through the IPsec tunnel, so identity is hidden. This option supports split tunneling. Network extension mode, where NAT or PAT is not used and it does support split tunneling. Users/devices behind the ASA are fully visible over the IPsec tunnel and fully routable.

Deploying a Basic Easy VPN Hardware Client Proﬁle
The configuration steps for the hardware client are as follows: STEP 1. Enable Cisco Easy VPN Remote. STEP 2. Conﬁgure the functional mode. STEP 3. Conﬁgure authentication. STEP 4. Conﬁgure the primary and optionally backup servers. To configure these steps using the ASDM, navigate to Configuration > Remote Access VPN > Easy VPN Remote and
■ ■

Check the Enable Easy VPN Remote check box. Choose between client mode and network extension mode.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 97 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■

Choose between pre-shared key and X.509 certiﬁcate; the second option requires a previous enrollment with a CA. Conﬁgure one or more Easy VPN servers; connections are attempted based on the order on the list.

To configure it and use X.509 certificates via the CLI, use the following commands: ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# vpnclient vpnclient vpnclient vpnclient enable mode client-mode trustpoint TEST-CA server 10.10.10.10

Conﬁguring Advanced Easy VPN Hardware Client Features
The following advanced features are available:
■

User or unit authentication (XAUTH) The following authentication options are supported by the Easy VPN hardware client, which needs to be enabled and pushed from the VPN server:
■ No XAUTH. ■ Automatic Unit XAUTH, enabled by default. With this option, the username and password used for authentication

are stored locally on the hardware remote client in the conﬁguration ﬁle.
■ Secure Unit Authentication (SUA), not enabled by default. This option is more secure, does not allow for local

username and password storage, and it needs credentials to be manually entered by a remote user from a browser. Basically, a user behind the hardware remote client needs to open a web session to a VPN protected resource (to trigger the IKEv1 process), and it is then redirected to a login page on the remote client. ■ Individual User Authentication (IUA), not enabled by default. This can be added as an extra function to XAUTH or SUA, and it requires every user to authenticate itself following same procedure as for SUA. The remote hardware client keeps track of authenticated users based on their IP and MAC addresses.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 98 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

For automatic unit XAUTH, a username and password are also conﬁgured on the Easy VPN client in the User Settings section of easy VPN Remote pane. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# vpnclient username TEST-USER password TEST-PASS

SUA and IUA need to be enabled on the Easy VPN server, in the associated group policy for Easy VPN Remote, and it is pushed to the remote hardware client upon VPN establishment. To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and edit the appropriate policy. Navigate further to Advanced > IPsec Client > Hardware Client and enable the desired option. To conﬁgure it using the CLI on the Easy VPN server, use the following commands: ciscoasa(conﬁg)# group-policy TEST-POLICY attributes ciscoasa(conﬁg-group-policy)# secure-unit-authentication enable ciscoasa(conﬁg-group-policy)# user-authentication enable

■

Remote management Three methods of remote management are supported by ASA 5505 VPN Remote:
■ Tunneled, through the IPsec tunnel, method, which also triggers the tunnel establishment process ■ Clear, bypassing the IPsec tunnel, method, which relies on SSH and HTTPS for security of management access ■ Disabled, prohibited from the Easy VPN server unless speciﬁcally allowed on VPN Remote with regular manage-

ment access commands for SSH, HTTPS To conﬁgure it on Easy VPN Remote using the ASDM, click the Advanced button in the Easy VPN Remote pane and check either the Enable Tunneled Management or Clear Tunnel Management check box. To conﬁgure it on Easy VPN Remote via the CLI, use the following command: ciscoasa(conﬁg)# vpnclient management tunnel 10.10.10.0 255.255.255.0

■

NAT transparency By default, Easy VPN Server and Remote use IPsec over UDP encapsulation. If UDP is not allowed, the second option is to enable IPsec over TCP on both the server and client. To enable it on the client side using the ASDM, click the Advanced button in the Easy VPN Remote pane and check the IPsec over TCP check box along with desired port. To conﬁgure it on Easy VPN Remote via the CLI, use the following command: ciscoasa(conﬁg)# vpnclient ipsec-over-tcp port 10000
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 99 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■

Device pass-through When IUA is enabled, clients that cannot authenticate (for example, IP phones, printers, or access points) cannot pass trafﬁc through the tunnel. These devices can bypass authentication based on their MAC addresses. To conﬁgure it on Easy VPN Remote using the ASDM, navigate to the Advanced Easy VPN properties window, and add MAC addresses and MAC masks in the MAC Exemption section. A mask of FFFF.FFFF.FFFF matches a single device, and FFFF.FF00.0000 matches all devices by the same manufacturer. To conﬁgure it on Easy VPN Remote via the CLI, use the following command: ciscoasa(conﬁg)# vpnclient mac-exempt 0007.50d5.4d95 ﬀﬀ.ﬀﬀ.ﬀﬀ

In addition, IP phones and Lightweight Extensible Authentication Protocol (LEAP) packets can bypass IUA if enabled on the Easy VPN server. To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies and edit the appropriate policy. Navigate further to Advanced > IPsec Client > Hardware Client and enable LEAP Bypass and Cisco IP Phone Bypass (see Figure 2-26).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 100 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions
Easy VPN Hardware Client

IKE v1 Easy VPN Software Client

VP

N

Tu nn

el

IKEv1 VPN Tunnel

Easy VPN Software Client

Figure 2-26 Easy VPN Software and Hardware
To configure it on Easy VPN Server via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy TEST-GROUP attributes ciscoasa(conﬁg-group-policy)# leap-bypass enable ciscoasa(conﬁg-group-policy)# ip-phone-bypass enable

IKE v1

N VP

nel Tun

HQ VPN Gateway Transport Network

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 101 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

LEAP bypass works only for Cisco Aironet access points using LEAP for authentication, and IP phone bypass works only in if the hardware client functions in network extension mode (see Figure 2-27).

Figure 2-27 Easy VPN Server SUA, IUA, and Authentication Bypass

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 102 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Troubleshooting the Easy VPN Hardware Client
To troubleshoot Easy VPN Remote connectivity issues, you use the same tools and methodologies discussed previously. Some level of complexity is added by those features supported only by Easy VPN Remote. You must verify that these are correctly configured (on both sides, client and server).

Using IKEv2 for Remote Access IPsec VPN
Current IKEv2 implementation with AnyConnect uses a proprietary EAP authentication method and is the only authentication method supported for now, and therefore no third-party IKEv2 clients are supported with ASA. What in IKEv1 is achieved through Mode Config Phase 1.5, in IKEv2 is achieved through the Aggregation Authentication and Control Protocol. The following configuration guidelines need to be remembered for IKEv2:
■ ■ ■ ■

IKEv2 policies, crypto maps, and crypto IPsec proposals are used for both site-to-site and remote-access IKEv2 sessions. IKEv2 does not use IPsec attribute settings from tunnel group conﬁguration in remote-access sessions. IKEv2 uses WebVPN attribute settings from tunnel group conﬁguration in remote-access sessions. Because AnyConnect by default connects using SSL, to use AnyConnect with IKEv2, IPsec needs to be conﬁgured as primary protocol in AnyConnect XML client proﬁle.

To complete an IKEv2 remote-access configuration with AnyConnect, you can use ASDM VPN Wizard from Wizards > VPN Wizards > AnyConnect VPN Wizard or follow these steps: STEP 1. Enable IKEv2 on the interface and select a certiﬁcate for it.Using ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Proﬁles and check both Enable Cisco AnyConnect VPN Client Access on the Interfaces Selected in the Table Below and Allow Access under IPsec (IKEv2) Access. When prompted, select the certiﬁcate to be used for the interface. STEP 2. Enable Client Services. Using ASDM, navigate to same location as in previous step and check Enable Client Services under IPsec (IKEv2) Access (see Figure 2-28).
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 103 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-28 Enable IKEv2 and Client Services
During the AnyConnect IKEv2 session initiation, settings like XML client proﬁle download, automatic client version update, CSD, and SCEP enrollment are needed. These are functional only if Client Services is enabled, which uses a parallel SSL connection to exchange this data. On the Port Settings tab, you can modify the port used by the Client Services function. STEP 3. Conﬁgure an IKEv2 group policy. Using ASDM, conﬁgure a new group policy or edit an existing one to support IKEv2 protocol by navigating to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies (see Figure 2-29).
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 104 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-29 IKEv2 Group Policy
STEP 4. Create an IPsec AnyConnect connection proﬁle. Using ASDM, conﬁgure a new connection proﬁle or edit an existing one and specify the previously conﬁgured group policy by navigating to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Proﬁles. Also specify an IPv4/IPv6 address pool or both (see Figure 2-30).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 105 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-30 IKEv2 Connection Proﬁle
STEP 5. Conﬁgure an AnyConnect XML proﬁle. Using ASDM, conﬁgure a new XML proﬁle to support IKEv2 IPsec as primary method by navigating to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Client Proﬁle (see Figure 2-31).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 106 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions

Figure 2-31 AnyConnect Client Proﬁle
STEP 6. Establish an AnyConnect session to download the new client XML proﬁle. Reconnect the AnyConnect session, this time using IKEv2 IPsec.Instead of downloading the IKEv2 IPsec-enabled XML AnyConnect client proﬁle upon a new connection, the proﬁle can be manually copied on the remote system. Note that in the preceding steps, no configuration related to IKEv2 policies, IPsec proposals, or crypto maps has been specified. A complete CLI configuration for an IKEv2 session follows: ciscoasa(conﬁg)# crypto ikev2 policy 100 ciscoasa(conﬁg-ikev2-policy)# encryption aes-256 aes-192 3des ciscoasa(conﬁg-ikev2-policy)# integrity sha512 sha md5 ciscoasa(conﬁg-ikev2-policy)# prf sha512 sha md5 ciscoasa(conﬁg-ikev2-policy)# group 14 5 2 ciscoasa(conﬁg-ikev2-policy)# group 14 5 2 ciscoasa(conﬁg-ikev2-policy)# lifetime seconds 28800 ciscoasa(conﬁg)# crypto ikev2 enable outside client-services port 443 ciscoasa(conﬁg)# crypto ikev2 remote-access trustpoint TEST-CA ciscoasa(conﬁg)# crypto ipsec ikev2 ipsec-proposal IKEv2-ANYCONNECT-PROPOSAL ciscoasa(conﬁg-ipsec-proposal)# protocol esp encryption aes-256 aes-192 3des ciscoasa(conﬁg-ipsec-proposal)# protocol esp integrity sha-1 md5 ciscoasa(conﬁg)# crypto dynamic-map DYNAMIC-ANYCONNECT 65535 set ikev2 ipsec-proposal IKEv2-ANYCONNECT-PROPOSAL

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 107 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ciscoasa(conﬁg)# crypto map STATIC 65535 ipsec-isakmp dynamic DYNAMIC-ANYCONNECT ciscoasa(conﬁg)# crypto map STATIC interface outside ciscoasa(conﬁg)# group-policy IKEv2-ANYCONNECT-GROUP internal ciscoasa(conﬁg)# group-policy IKEv2-ANYCONNECT-GROUP attributes ciscoasa(conﬁg-group-policy)# vpn-tunnel-protocol ikev2 ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect proﬁles value IKEv2-ANYCONNECT type user ciscoasa(conﬁg-group-policy)# dns-server value 10.10.10.100 ciscoasa(conﬁg-group-policy)# wins-server value 10.10.10.100 ciscoasa(conﬁg-group-policy)# default-domain value cisco.com ciscoasa(conﬁg)# ip local pool IPv4 10.10.10.1-10.10.10.10 mask 255.255.255.0 ciscoasa(conﬁg)# tunnel-group IKEv2-ANYCONNECT-TUNNEL type remote-access ciscoasa(conﬁg)# tunnel-group IKEv2-ANYCONNECT-TUNNEL general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy IKEv2-ANYCONNECT-GROUP ciscoasa(conﬁg-tunnel-general)# address-pool IPv4 ciscoasa(conﬁg-tunnel-general)# tunnel-group IKEv2-ANYCONNECT-TUNNEL webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# group-alias IKEv2-ANYCONNECT-ALIAS enable ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# enable outside ciscoasa(conﬁg-webvpn)# tunnel-group-list enable ciscoasa(conﬁg-webvpn)# anyconnect enable ciscoasa(conﬁg-webvpn)# anyconnect proﬁles IKEv2-ANYCONNECT disk0:/IKEv2-ANYCONNECT.xml nat (outside,outside) 1 source static any any destination static NETWORK_OBJ_1.1.1.0_29 NETWORK_ OBJ_1.1.1.0_29 no-proxy-arp route-lookup

Troubleshoot IKEv2 AnyConnect Sessions
You can perform IKEv2 remote-access troubleshooting on both the server and client side. Most issues are logged by default on the Cisco ASA and AnyConnect Client, with debugging being required to investigate IKEv2 negotiation issues. If an IKEv2 remote-access VPN session does not get established
■ ■ ■

Make sure that basic IP connectivity exists between the ASA and AnyConnect Client (ping, traceroute, nslookup, dig). Verify IKEv2 policies, IPsec proposals, and Client Services conﬁguration on the ASA. Ensure that UDP port 500 for IKEv2 and TCP port used for Client Services is allowed between the ASA and AnyConnect Client.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 108 ] Chapter 2: Deploying Cisco ASA IPsec VPN Solutions ■ ■ ■ ■

Use the built-in DART tool on AnyConnect to gather information about session failure. Use debug crypto ikev2 protocol and debug crypto ipsec to investigate IKEv2 negotiation issues. Check on connection proﬁle and group policy conﬁguration. Verify correct IPv4/IPv6 addressing assignment policy.

If traffic does not flow through the tunnel
■ ■ ■ ■ ■ ■

Make sure no device along the path drops ESP or UDP port 4500 used for ESP encapsulation. If split tunneling is enabled, verify client-protected routes on AnyConnect. Verify encrypted and decrypted packets on both server and client to observe in which direction packets are dropped. Verify correct access control measures implemented on ASA. Verify that AnyConnect Client trafﬁc is not subject to NAT policies; conﬁgure Identity NAT for client trafﬁc if needed. Check proper routing to AnyConnect Client addresses from behind the ASA.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 109 ] CCNP Security VPN 642-648 Quick Reference

Chapter 3

Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions
In this chapter, you learn to deploy and manage client-based Secure Sockets Layer (SSL) virtual private networks (VPN) on Cisco Adaptive Security Appliance (ASA) as the VPN gateway using AnyConnect Secure Mobility Client software. As you’ll see, you can initiate a client-based SSL VPN session from a broad range of devices and operating systems that support the install of AnyConnect Client (desktops, laptops, mobile devices), as shown in Figure 3-1.
Desktop

SS
SSL VPN Tunnel Laptop

Tu nn el

PDA Smartphone

Figure 3-1 AnyConnect SSL VPN
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

SS

LV

PN

LV PN Tu nn el
Transport Network HQ VPN Gateway

[ 110 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Deploying a Basic Cisco AnyConnect Full-Tunnel SSL VPN Solution
Basic Cisco AnyConnect full-tunnel SSL VPN uses user authentication by username and password, provides IP address assignment to the client, and uses a basic access control policy. The client also authenticates the ASA with identity certificate-based authentication. Deployment tasks for this scenario are as follows: 1. 2. 3. 4. 5. Conﬁgure the basic ASA SSL VPN gateway features. Configure local user authentication. Configure IPv4/IPv6 address assignment. Configure basic access control. Install the Cisco AnyConnect Secure Mobility Client.

Initially, AnyConnect was an SSL-only VPN client. Starting with Version 3.0, AnyConnect became a modular client with additional features (including IPsec IKEv2 VPN terminations on Cisco ASA), but it requires a minimum of ASA 8.4(1) and ASDM 6.4(1).

Conﬁguring Basic Cisco ASA SSL VPN Gateway Features
Note
Starting with version 2.5, AnyConnect is called AnyConnect Secure Mobility Client.

To initially prepare the ASA for SSL VPN termination, complete the following steps: STEP 1. Provision the ASA with an identity certiﬁcate. Your options are as follows:
■ ■ ■

Use a self-signed certiﬁcate. Enroll ASA in Public Key Infrastructure (PKI) with Simple Certiﬁcate Enrollment Protocol (SCEP). Enroll ASA in PKI with manual cut-and-paste method enrollment.

To install a self-signed certiﬁcate using the ASDM, navigate to Conﬁguration > Remote Access VPN > Certiﬁcate Management > Identity Certiﬁcates and click Add. Give the PKI trustpoint a name, choose Add a New Identity Certiﬁcate, check Generate Self-Signed Certiﬁcate, and then click Add Certiﬁcate.To conﬁgure a self-signed certiﬁcate via the command-line interface (CLI), use the following commands:

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 111 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions ciscoasa(conﬁg)# crypto key generate rsa label SELF-SIGNED modulus 2048 ciscoasa(conﬁg)# crypto ca trustpoint TEST-CA ciscoasa(conﬁg-ca-trustpoint)# id-usage ssl-ipsec ciscoasa(conﬁg-ca-trustpoint)# subject-name CN=cisco.com ciscoasa(conﬁg-ca-trustpoint)# enrollment self ciscoasa(conﬁg-ca-trustpoint)# keypair SELF-SIGNED ciscoasa(conﬁg)# crypto ca enroll TEST-CA noconﬁrm

To enroll with SCEP by using the ASDM, navigate to same section as for self-signed certiﬁcates. Give the PKI trustpoint a name, choose Add a New Identity Certiﬁcate (do not check Generate Self-Signed Certiﬁcate), and click the Advanced button for enrollment options. From here, you have two options:
■

For SCEP enrollment, navigate to Enrollment Mode and choose the Request from a CA method and complete the URL (which is in the form http://IP_ADDRESS/certserv/mscep/mscep.dll). Navigate to SCEP Challenge Password and provide the challenge in case the certiﬁcate authority (CA) requires it. For manual enrollment, navigate to Enrollment Mode and choose Request by Manual Enrollment. This requires an additional step: After the certiﬁcate is issued, it needs to be imported onto the ASA from a ﬁle. For this, select the created trustpoint and click Install. In the new window, choose Install from a File and provide the full path to the base64encoded certiﬁcate.

■

To conﬁgure SCEP enrollment via the CLI, use the following commands: ciscoasa(conﬁg)# crypto key generate rsa label SELF-SIGNED modulus 2048 ciscoasa(conﬁg)# crypto ca trustpoint TEST-CA ciscoasa(conﬁg-ca-trustpoint)# id-usage ssl-ipsec ciscoasa(conﬁg-ca-trustpoint)# subject-name CN=cisco.com ciscoasa(conﬁg-ca-trustpoint)# enrollment url http://10.10.10.10/certsrv/mscep/mscep.dll ciscoasa(conﬁg-ca-trustpoint)# keypair SELF-SIGNED ciscoasa(conﬁg)# crypto ca authenticate TEST-CA nointeractive ciscoasa(conﬁg)# crypto ca enroll TEST-CA

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 112 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

STEP 2. Load the AnyConnect image onto the ASA. There are different AnyConnect web deployment packages (PKG ﬁles) for different client operating systems. Choose the one you need, download it from Cisco.com, and load it into ASA ﬂash memory. To make the transfer using the ASDM, navigate to Tools > File Management. STEP 3. Enable SSL VPN termination on desired interfaces. To enable SSL using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Proﬁles and check the Enable Cisco AnyConnect VPN Client Access on the Interfaces Selected in the Table Below check box. In the pop-up window, select the AnyConnect image. Choose Allow Access and, optionally, Enable DTLS for desired interfaces. To enable SSL via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# enable outside ciscoasa(conﬁg-webvpn)# anyconnect enable ciscoasa(conﬁg-webvpn)# anyconnect image disk0:/ anyconnect-win-3.0.1047-k9.pkg 1

STEP 4. Conﬁgure and optionally tune SSL Transport Layer Security (TLS) settings.Here, you can tune SSL VPN by allowing only certain SSL/TLS versions and algorithms and by specifying the identity certiﬁcate used (if many exist). To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Advanced > SSL Settings (see Figure 3-2).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 113 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Figure 3-2 SSL VPN Tuning
To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)#ssl trust-point TEST-CA outside ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)#ssl server-version tlsv1 ciscoasa(conﬁg-webvpn)#ssl encryption aes128-sha1 aes256-sha1 3des-sha1 des-sha1
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 114 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Conﬁguring Local Password-Based User Authentication
The simplest authentication method uses local usernames and passwords. We enabled SSL VPN access for AnyConnect clients earlier. Now we need to configure the access, including authentication: STEP 1. Conﬁgure a new group policy for AnyConnect connections or modify the default group policy (not recommended because this policy is inherited by all newly created policies, thus making it difﬁcult to differentiate users later). To create a group policy for AnyConnect connections using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and click Add. To create it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-ANYCONNECT-POLICY internal ciscoasa(conﬁg)# group-policy BASIC-ANYCONNECT-POLICY attributes ciscoasa (conﬁg-group-policy)# vpn-tunnel-protocol ssl-client

STEP 2. Conﬁgure a connection proﬁle for AnyConnect connections and assign it the new group policy. To create a connection proﬁle for AnyConnect connections using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Proﬁles and click Add. To create it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-ANYCONNECT-PROFILE type remote-access ciscoasa(conﬁg)# tunnel-group BASIC-ANYCONNECT-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy BASIC-ANYCONNECT-POLICY

STEP 3. Optionally, deﬁne an alias for the connection proﬁle. This option allows users to select the desired connection proﬁle when connecting to the SSL VPN. Navigate in the connection proﬁle conﬁguration to Advanced > Group Alias/Group URL and click Add under Connection Aliases (see Figure 3-3). To create it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-ANYCONNECT-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# group-alias "BASIC PROFILE" enable

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 115 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Figure 3-3 Connection Alias

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 116 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

STEP 4. Conﬁgure the local user database. To create a user account using the ASDM, navigate to Conﬁguration > Remote Access VPN > AAA/Local Users > Local Users and click Add. To create it via the CLI, use the following commands: ciscoasa(conﬁg)# username BASIC-ANYCONNECT-USER password CISCO ciscoasa(conﬁg)# username BASIC-ANYCONNECT-USER attributes ciscoasa(conﬁg-username)# service-type remote-access

Note
You learn the manual installation method in this module.

STEP 5. Optionally, conﬁgure the connection proﬁle lock. This option restricts users to a speciﬁc connection proﬁle with no other proﬁle being valid for them, even if it is selected. To conﬁgure restrictions using the ASDM, in the user-editing pane, navigate to VPN Policy and conﬁgure Connection Proﬁle (Tunnel Group) Lock.To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# username BASIC-ANYCONNECT-USER attributes ciscoasa(conﬁg-username)# group-lock value BASIC-ANYCONNECT-PROFILE

Conﬁguring Client IP Address Management, Basic Access Control, and Split Tunneling
IPv4/IPv6 address assignment methods are the same as in IKEv1 Easy VPN or IKEv2 AnyConnect VPN:
■ ■ ■ ■ ■

Using a default group policy pool Using a pool in a speciﬁc group policy Per-user assignment in the local AAA database (Only IPv4 addresses can be assigned.) Per-user or per-group assignment via remote authentication, authorization, and accounting (AAA) server Using a Dynamic Host Control Protocol (DHCP) server

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 117 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Address assignment and access control configuration steps are the same as in IKEv1 Easy VPN:
■ ■ ■ ■ ■ ■ ■ ■

Deﬁne the IP address assignment methods. Conﬁgure an IPv4/IPv6 address pool to use this method. Assign the address pools to the group policy. Assign per-user IP addresses if needed. Conﬁgure interface access control list (ACL) bypass if needed. Conﬁgure interface IPv4/IPv6 ACLs or global IPv4/IPv6 if bypass is disabled. Conﬁgure per-proﬁle or per-user IPv4/IPv6 ACLs. Conﬁgure split tunneling.

Installing and Conﬁguring Cisco AnyConnect Client
AnyConnect Client was introduced together with the ASA Version 8.0 operating system to replace the SSL VPN Client (SVC). You can install the AnyConnect Client on remote devices in two ways:
■ ■

Predeploy installation package, manual installation using an installer on client devices Web installation, automatic installation through an SSL VPN clientless session, using PKG ﬁles from ASA

Cisco AnyConnect 3.0 supported platforms are as follows:
■ ■ ■

Windows 7 (32-bit and 64-bit), Windows Vista (32-bit and 64-bit) SP2, Windows XP SP3 Linux Red Hat Enterprise 5 Desktop, Ubuntu 9.x and 10.x Mac OS X 10.5, 10.6.x (32-bit and 64-bit) and Lion OS X 10.7 (32-bit and 64-bit)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 118 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

For mobile devices the current available version is not 3.0 and there is no feature parity, due to mobile devices limitations:
■ ■ ■ ■

For iOS, the current AnyConnect version is 2.5.x. For Android, the current AnyConnect version is 2.4.x. For Symbian, the current version is 2.4.x. For Windows mobile devices, the current AnyConnect version is 2.5.x.

The manual deployment of AnyConnect Client requires the following steps: STEP 1. Install the AnyConnect Secure Mobility Client. STEP 2. Verify the VPN server certiﬁcate authentication chain. AnyConnect uses the certiﬁcate store. If an internal nonglobal CA is used, import the CA identity certiﬁcate on client devices so that the CA becomes trusted. STEP 3. Conﬁgure basic AnyConnect proﬁle settings. Start the AnyConnect Client and specify the VPN gateway fully qualiﬁed domain name (FQDN), which should match the common name (CN) from the identity certiﬁcate of the ASA; otherwise, you will receive certiﬁcate name mismatch warnings received. STEP 4. Establish the SSL VPN connection. To initiate the session, click the Select button. After the first successful connection, ASA pushes further configuration options to the client such as the list of connection profiles if aliases were configured and allowed to be selected. Verification of the connection can be done on both the client and server. On the client, use the AnyConnect tray icon and Statistics. On the server, navigate with ASDM to Monitoring > VPN > VPN Statistics > Sessions, or from the CLI issue the command show vpn-sessiondb anyconnect.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 119 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Troubleshooting Basic Full-Tunnel SSL VPN Operation
You can use the Diagnostic AnyConnect Reporting Tool (DART) to collect data useful for troubleshooting AnyConnect install and connection problems. It is separate from AnyConnect Client and assembles diagnostic information for Cisco Technical Assistance Center (TAC) analysis. To troubleshoot AnyConnect SSL VPN, follow this approach: 1. 2. 3. 4. Install DART (can be installed manually on remote devices or pushed from ASA as additional module). Collect diagnostic information by starting DART. Optionally examine gathered data. Perform troubleshooting.

If the VPN session does not get established, you may to do the following:
■ ■ ■ ■

Verify Secure Sockets Layer/Transport Layer Security (SSL/TLS) parameters match on the server and client. Verify user credentials are correct. Verify connection proﬁle, group policies, and any conﬁgured restrictions. Verify correct IPv4/IPv6 address assignment to AnyConnect Client.

Most common session establishment issues are logged by the ASA. If logging is enabled, there is no need for debugging. If advanced investigations are required on the ASA side, perform the following debug process: ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# ciscoasa(conﬁg)# logging logging logging logging logging logging logging enable timestamp buﬀered debugging class auth buﬀered debugging class webvpn buﬀered debugging class ssl buﬀered debugging class svc buﬀered debugging

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 120 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

If traffic does not flow through the AnyConnect SSL VPN session, do the following:
■ ■ ■ ■ ■

Check client routes and split tunneling. Check access control methods deployed on ASA. Check Network Address Translation (NAT) conﬁguration; perhaps Identity NAT is needed for AnyConnect trafﬁc. Check routing back to AnyConnect Client addresses from the internal network. Check fragmentation issues.

Deploying an Advanced Cisco AnyConnect Full-Tunnel SSL VPN Solution
Advanced AnyConnect deployment steps are as follows: STEP 1. Deploy Datagram Transport Layer Security (DTLS). STEP 2. Manage the AnyConnect software. STEP 3. Conﬁgure AnyConnect gateway deploy settings. STEP 4. Deploy advanced AnyConnect OS integration options. STEP 5. Customize the AnyConnect user interface.

Deploying DTLS
DTLS is an alternative VPN transport protocol to SSL/TLS. DTLS is a standard SSL protocol defined in RFC 4347 and provides a lowlatency data path for real-time applications by using User Datagram Protocol (UDP). It improves the application performance because
■ ■

UDP transport does not trigger packet retransmission at the VPN layer. The UDP header is simpler than TCP, creates less overhead, and consumes fewer resources
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 121 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

If DTLS is enabled
■ ■ ■

TLS/SSL is used as the control plane to negotiate and establish DTLS connection. Two simultaneous tunnels are established, TLS/SSL and DTLS. DTLS falls back to TLS/SSL in case of DTLS tunnel failure, determined by dead peer detection (DPD). This is triggered by the client and not the VPN gateway. DTLS tunnel recovery is attempted, and if it is successful, data starts ﬂowing again over the DTLS tunnel.

If DTLS is disabled, clients establish only an SSL/TLS tunnel. See Figure 3-4 to better understand headers in DTLS encapsulation.
IP Header UDP DTLS Header DTLS Payload IP Header IP Payload

Figure 3-4 DTLS Encapsulation
When SSL VPN is enabled on an interface, DTLS is automatically enabled, as well. DTLS takes precedence over SSL/TLS and by default uses UDP port 443. To enable DTLS using the ASDM, navigate to Configuration >Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles and enable DTLS on interfaces where SSL VPN is also enabled. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# enable outside INFO: WebVPN and DTLS are enabled on 'outside'. ciscoasa(conﬁg-webvpn)# dtls port 443

Once enabled globally, DTLS is active on DfltGrpPolicy and automatically on all newly created group policies. Therefore, you can enable/disable it at the group policy level. To disable it at the group policy level using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select the policy, and click Edit. Navigate further to Advanced > AnyConnect Client and disable Datagram TLS.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 122 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-ANYCONNECT-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect ssl dtls none

Starting with ASA Version 8.4(3), DTLS and SSL compression is supported with LZS and is enabled by default. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-webvpn)# ciscoasa(conﬁg-group-webvpn)# BASIC-ANYCONNECT-POLICY attributes webvpn anyconnect dtls compression lzs anyconnect ssl compression lzs

After a successful AnyConnect SSL/VPN session, DTLS can be verified on both the client and server. On the client side, it can be verified by choosing Statistics in the AnyConnnect GUI. On the server side, it can be viewed with the commands show conn and show vpn-sessiondb anyconnect.

Managing Cisco AnyConnect Software
AnyConnect software can be installed as follows:
■ ■ ■

Manually using an installer on the remote client Automatically using software management tools Automatically via the clientless portal

AnyConnect software can be uninstalled as follows:
■ ■ ■

Manually on the remote client Automatically using software management tools Automatically, triggered by the ASA after VPN logoff
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 123 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

There are two optional configuration steps on the ASA for AnyConnect management: 1. Conﬁgure client persistence so that after VPN logoff AnyConnect is not automatically uninstalled. You can conﬁgure this at the group policy level. To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select the policy, and click Edit. Navigate further to Advanced > AnyConnect Client and click Yes on Keep Installer on Client System, which is the default option (see Figure 3-5). To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-ANYCONNECT-POLICY attributes ciscoasa (conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect keep-installer installed

Figure 3-5 AnyConnect Client Persistence

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 124 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

2.

Conﬁgure the automatic client update, pushed by the ASA to the remote device. At the SSL VPN session initiation, ASA checks the AnyConnect version of the client and automatically updates it. To enable it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Settings and click Add on AnyConnect Client Images. To enable it using the CLI and upgrade the client to AnyConnect 3.0, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# anyconnect image disk0:/ anyconnect-win-3.0.1047-k9.pkg

Conﬁguring Cisco AnyConnect Client XML Proﬁles
Cisco AnyConnect Client configuration is fully controlled by the ASA through Extensible Markup Language (XML) profiles, but this is not a mandatory step unless you need additional controls that profiles give you as the administrator:
■ ■ ■ ■

XML proﬁles can be edited manually with a XML editor, directly within the ASA ASDM or by using Cisco Proﬁle Editor, a tool installed on a client PC. XML proﬁles are uploaded to ASA and attached to group policies. After the ﬁrst login, the XML proﬁle is pushed down to the client. Users can be allowed to control some settings of their connection experience.

Configuration steps are as follows: STEP 1. Create the XML proﬁle.Open Cisco AnyConnect Client Proﬁle Editor and choose File > New. Change all required parameters, and then choose File > Save As. STEP 2. Upload the XML proﬁle on ASA and validate it. To upload the XML proﬁle onto the ASA using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Client Proﬁle and click Add or Import followed by Validate if the proﬁle was imported, to ensure it is correctly written with the ofﬂine XML Proﬁle Editor.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 125 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# anyconnect proﬁles MY-XML-PROFILE disk0:/MY-PROFILE.XML

STEP 3. Assign the XML proﬁle to a group policy. To assign it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and edit the desired policy. Navigate further to Advanced > AnyConnect Client and edit the Client Proﬁles to Download ﬁeld. To assign it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-ANYCONNECT-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect proﬁles value MY-XML-PROFILE type user

After successful connection, the XML profile is pushed/uploaded to the remote client in the following path:
■ ■

Windows XP: C:\Documents and Settings \All Users\Application Data\Cisco AnyConnect VPN Client\Proﬁle Windows Vista/Windows 7: C:\Program Data\Cisco\Cisco AnyConnect VPN Client\Proﬁle

This can be either manually checked in the respective path or via Windows Event Viewer in the Cisco AnyConnect VPN Client section.

Deploying Advanced Cisco AnyConnect Operating System Integration Options
Cisco AnyConnect VPN Client offers advanced functionalities, including the following:
■ ■ ■

Trusted Network Detection (TND) Start Before Logon (SBL) Client scripting

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 126 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Trusted Network Detection
■ ■ ■ ■ ■ ■

Allows the AnyConnect VPN Client to automatically disconnect the SSL VPN session when the user is inside the corporate network (trusted network). Starts the SSL VPN session when the user is outside the corporate network (untrusted network). The trusted network is detected by the assigned domain name or Domain Name System (DNS) servers. TND does not interfere with the ability of the user to manually initiate the SSL VPN session. Is supported on Microsoft Windows XP and later and Mac OS X. Is conﬁgured in the AnyConnect XML client proﬁle, on the Preferences (cont) tab.

Start Before Logon
■ ■ ■ ■ ■

Windows-only feature allows AnyConnect SSL session to be established before Windows logon. Useful to log in to Active Directory over a VPN session. Required to establish a VPN session if Active Directory Group Policy Object (GPO) does not allow caching. Is conﬁgured in the AnyConnect XML client proﬁle, on the Preferences tab. Even with SBL, a user can still log on to the machine and bypass SBL; to enforce the use of SBL, use TND or always-on conﬁguration.

AnyConnect can run up to one script at login and one script at logout; these need to be defined in XML profile. Scripting is useful for
■ ■ ■

Refreshing Active Directory policies Mapping and unmapping of network drives Automatically starting applications

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 127 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Scripting is configured in the AnyConnect XML client profile, on the Preferences (cont) tab. The script is pushed from ASA, so it must first be uploaded to ASA. To upload a script to ASA using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Customization/Localization > Script and click Import. You can verify TND and scripting in the Cisco AnyConnect VPN Client section of the Windows Event Viewer.

Customizing the Cisco AnyConnect User Interface
You can fully customize the AnyConnect client GUI by adding graphic elements and language screens. Most customization tasks are easily performed using the ASDM. However, more extensive customization such as replacing the VPN GUI entirely and deploying a custom GUI are possible using the AnyConnect application programming interface (API). To make customizations using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Customization/Localization > Resources.

Deploying Advanced Authentication in AnyConnect Full-Tunnel SSL VPNs
Overview
In this section, we explore advanced password-based authentication options, meant to enhance manageability and increase strength of client authentication and overall SSL VPN process:
■ ■ ■

Centralized AAA authentication (possibly integrated backend databases) Identity certiﬁcate authentication Double or triple authentication starting with ASA 8.2

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 128 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Cisco ASA can validate username/password credentials against external authentication servers, such as the following:
■ ■ ■ ■ ■ ■

RADIUS authentication server TACACS+ authentication server Kerberos authentication server Windows authentication Lightweight Directory Access Protocol (LDAP) authentication server RSA Secure ID authentication server

RADIUS and TACACS servers can be configured to check user credentials in back-end authentication servers, such as the following:
■ ■ ■ ■ ■

Windows authentication LDAP External Open Database Connectivity (ODBC) RSA Secure ID Other RADIUS servers

When identity certificate authentication is being deployed, the ASA identity certificate can be one of the following:
■ ■

A self-signed certiﬁcate. ASA is a CA and issues identity certiﬁcates to clients. An external Public Key Infrastructure (PKI) certiﬁcate. Both ASA and clients enroll with an external CA.

When deploying advanced authentication for SSL VPNs, you have the following options:
■ ■

Deploy advanced password-based client authentication. Deploy certiﬁcate-based client authentication using the ASA local CA.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 129 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions ■ ■ ■ ■

Conﬁgure certiﬁcates to connection proﬁle mapping. Deploy certiﬁcate-based client authentication using external CAs. Deploy advanced PKI integration. Deploy double/triple client authentication.

Deploying External AAA Authentication
Configuring external AAA authentication is performed in two steps: STEP 1. Conﬁgure the remote authentication server.To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > AAA/Local Users > AAA Server Groups and click Add under AAA Server Groups. Give it a name and select the type of AAA server, based on protocol. To conﬁgure an external RADIUS server using the ASDM, do the following:
■ ■ ■

In AAA Server Groups, click Add and choose RADIUS as the protocol. Click the created RADIUS group and in the Servers in the Selected Group click Add. Select the interface to reach the RADIUS server, IP address of the RADIUS server, ports, and server secret key used to communicate with it.To conﬁgure an external RADIUS server via the CLI, use the following commands: ciscoasa(conﬁg)# aaa-server TEST-RADIUS-SRV protocol radius ciscoasa(conﬁg)# aaa-server TEST-RADIUS-SRV (inside) host 10.10.10.10 ciscoasa(conﬁg-aaa-server-host)# key TEST-RADIUS-KEY

To conﬁgure an LDAP server using the ASDM, do the following:
■ ■ ■

In AAA Server Groups, click Add and choose LDAP as the protocol (see Figure 3-6). Click the created LDAP group and in the Servers in the Selected Group click Add. Select the interface to reach the LDAP server, IP address of the LDAP server, LDAP server type, and optionally select LDAP over SSL, conﬁgure the base DN and Login DN, and select the authentication protocol (see Figure 3-7).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 130 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

To conﬁgure an LDAP server via the CLI, use the following commands: ciscoasa(conﬁg)# aaa-server TEST-LDAP-SRV protocol ldap ciscoasa(conﬁg)# aaa-server TEST-LDAP-SRV (inside) host 10.10.10.11 ciscoasa(conﬁg-aaa-server-host)# server-type Microsoft ciscoasa(conﬁg-aaa-server-host)# ldap-over-ssl enable ciscoasa(conﬁg-aaa-server-host)# server-port 636 ciscoasa(conﬁg-aaa-server-host)# sasl-mechanism digest-md5 ciscoasa(conﬁg-aaa-server-host)# ldap-scope subtree ciscoasa(conﬁg-aaa-server-host)# ldap-base-dn cn=users, dc=cisco, dc=com ciscoasa(conﬁg-aaa-server-host)# ldap-naming-attribute cn ciscoasa(conﬁg-aaa-server-host)# ldap-login-password TEST-LDAP-PASSWORD ciscoasa(conﬁg-aaa-server-host)# ldap-login-dn cn=ASAUSER, dc=cisco, dc=com

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 131 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Figure 3-6 LDAP Server Setup

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 132 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Figure 3-7 LDAP Server Setup

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 133 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

To conﬁgure an RSA server using the ASDM, do the following:
■ ■ ■

In AAA Server Groups, click Add and choose SDI as the protocol. Click the created SDI group, and in the Servers in the Selected Group click Add. Select the interface to reach the SDI server, the IP address of the SDI server, and the server port.

To conﬁgure an RSA server via the CLI, use the following commands: ciscoasa(conﬁg)# aaa-server TEST-RSA-SRV protocol sdi ciscoasa(conﬁg)# aaa-server TEST-RSA-SRV (inside) host 10.10.10.11

STEP 2. Enable remote AAA authentication in the connection proﬁle. To enable any of the previously created external authentication server on connection profiles using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles, select the desired profile, and click Edit. In the Basic pane, choose AAA as the authentication method and select one of the configured external servers. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-ANYCONNECT-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RSA-SRV

Consider the following implementation guidelines:
■ ■ ■

Implement a redundant AAA infrastructure. When using static passwords, be sure that user credentials are strong enough; consider using account lockout. Deploy one-time passwords if existing credentials are not adequately strong; also consider migrating to client certiﬁcates.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 134 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Deploying Certiﬁcate-Based Client Authentication Using the Cisco ASA Local CA
Note
If ASA is used as a CA server, failover functionality is disabled. You cannot have both CA and failover capabilities concurrently conﬁgured because these are mutually exclusive. Take this into account if you have a pair of ASAs deployed in a failover scenario and you want to conﬁgure local CA. You will not be allowed to do it.

When CA is configured on the ASA, it generates additional self-signed certificate used to sign the identity certificates issued to clients. To deploy identity certificate authentication using the ASA as the CA, the following steps are necessary: STEP 1. Conﬁgure the ASA local CA. To enable CA using the ASDM, navigate to Conﬁguration > Remote Access VPN > Certiﬁcate Management > Local Certiﬁcate Authority > CA Server, check the Enable Certiﬁcate Authority Server check box (see Figure 3-8), and
■ ■ ■ ■ ■ ■ ■

Check the Enable check box to activate the local CA server. Conﬁgure the passphrase used to protect the local CA certiﬁcate. Conﬁgure the issuer subject name (the default being the CN=FQDN of the ASA). Select the CA and client key sizes. Conﬁgure the CA and client certiﬁcate lifetime. Optionally, conﬁgure the Simple Mail Transfer Protocol (SMTP) server used to send instructions to users about how to obtain identity certiﬁcates. Optionally, click More Options to conﬁgure the certiﬁcate revocation list (CRL) and the database storage location.

To enable it via the CLI, use the following commands: ciscoasa(conﬁg)# smtp-server 10.10.10.20 ciscoasa(conﬁg)# crypto ca server ciscoasa(conﬁg-ca-server)# keysize 2048 ciscoasa(conﬁg-ca-server)# keysize server 2048 ciscoasa(conﬁg-ca-server)# lifetime ca-certiﬁcate 3650 ciscoasa(conﬁg-ca-server)# lifetime certiﬁcate 365 ciscoasa(conﬁg-ca-server)# smtp from-address vpn-ca@cisco.com ciscoasa(conﬁg-ca-server)# issuer-name CN=vpn-ca@cisco.com ciscoasa(conﬁg-ca-server)# cdp-url http://VPN-CA.cisco.com/+CSCOCA+/asa_ca.crl ciscoasa(conﬁg-ca-server)# no shutdown passphrase CISCO-VPN-CA INFO: Certiﬁcate server is being enabled

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 135 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Figure 3-8 ASA Local CA
STEP 2. Create CA user accounts. After the CA is enabled, you must create user accounts for all users eligible to obtain an identity certiﬁcate from ASA. To conﬁgure them using the ASDM, navigate to Conﬁguration > Remote Access VPN > Certiﬁcate Management > Local Certiﬁcate Authority > Manage User Database and click Add:
■ ■ ■

Conﬁgure the username. Conﬁgure the user e-mail address. Conﬁgure the distinguished name (DN) for the identity certiﬁcate.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 136 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions ■ ■

Check the Allow Enrollment check box. Click Add User.

To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# crypto ca server user-db add VPN-USER DN CN=vpn-user,OU=Financial,O=Cisco,C=RO, email vpn-user@cisco.com ciscoasa(conﬁg)# crypto ca server user-db allow VPN-USER

STEP 3. Provision the client identity certiﬁcates. Users can obtain their identity certiﬁcate using a web browser or AnyConnect. Either way, before downloading the certiﬁcate, the user has to authenticate to the ASA by the previously deﬁned username and a one-time password (OTP) generated by the ASA. The OTP can be sent to the user via e-mail (via the E-mail OTP button) or manually on an outof-band (OOB) medium. STEP 4. Install the client certiﬁcate on AnyConnect Client. Users can click the link received via e-mail to receive the identity certiﬁcate via a browser. Alternatively, they can initiate the AnyConnect session, and the AnyConnect client displays a Get Certiﬁcate button (if certiﬁcate authentication was conﬁgured in the connection proﬁle). STEP 5. Map certiﬁcates to connection proﬁles. Certiﬁcate to connection proﬁle maps are needed so that ASA can use appropriate connection proﬁles for users authenticating with identity certiﬁcates. To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Advanced > Certiﬁcate to AnyConnect and clientless SSL VPN Connection Proﬁle Maps and
■ ■ ■ ■

Click Add under Certiﬁcate to Connection Proﬁle Maps. Choose New, give it a name, and select the desired connection proﬁle from Mapped to Connection Proﬁle. Click OK to accept the certiﬁcate map. Click Add under Mapping Criteria and specify the DN matching criteria.

To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# crypto ca certiﬁcate map TEST-MAP 10 ciscoasa(conﬁg-ca-cert-map)# subject-name attr ou eq Financial ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# certiﬁcate-group-map TEST-MAP 10 BASIC-ANYCONNECT-PROFILE

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 137 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

STEP 6. Enable client certiﬁcate authentication for the connection proﬁles. To enable certificate-based authentication on a specific connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles, select the profile, click Edit, and enable the Certificate authentication method. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate

Verification can be done as follows:
■ ■

On the client side, navigate to Internet Explorer > Tools > Internet Options >Content > Certiﬁcates to view the identity certiﬁcates. On the server side, once the session is established, navigate to Monitoring > VPN > VPN Statistics > Sessions and verify certiﬁcate authentication for VPN sessions.

Certificates can be revoked and unrevoked on the ASA with commands crypto ca server revoke cert-serial-no and crypto ca server unrevoke cert-serial-no.

Deploying Certiﬁcate-Based Authentication Using External CAs
Instead of ASA-issued certificates, external CA-issued certificates can be used for authentication in AnyConnect SSL VPNs. On Microsoft Windows devices, user or computer certificates can be used. If multiple certificates exist, selection can be made manually or automatically through Extensible Markup Language (XML) profiles. AnyConnect can use existing client certificates from the
■ ■ ■ ■

System certiﬁcate store Browser certiﬁcate store Smartcards/smart tokens Filesystem store (Linux)
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 138 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Alternatively, AnyConnect can enroll itself to a PKI using SCEP. SCEP enrollments are controlled through XML profiles and can be achieved
■

Inside an SSL VPN tunnel. This is mostly used when SCEP enrollment needs to be secure and the CA server is accessible only through a tunnel. It requires a dedicated connection proﬁle that does not use certiﬁcate authentication, scoped for SCEP enrollment only. Starting with ASA 8.4(1), support for SCEP proxy has been added. It requires AnyConnect Premium license and transforms the ASA into a proxy for SCEP requests between AnyConnect clients and the third-party CA. Outside an SSL VPN tunnel. This is used when the client has direct connectivity with the CA without need for a tunnel. Because the certiﬁcate is not present, the AnyConnect session will fail, but the user is presented with a Get Certiﬁcate button to process the enrollment.

■

This section covers just the first option (without SCEP proxy), which requires the following configuration steps: STEP 1. Conﬁgure the XML proﬁle enrollment process.Start the AnyConnect Client Proﬁle Editor, navigate to the Certiﬁcate Enrollment tab, and
■ ■ ■ ■

Check the Certiﬁcate Enrollment check box. In the Automatic SCEP Host ﬁeld, enter the ASA FQDN followed by an alias of connection proﬁle used for enrollment process. In the CA URL ﬁeld, enter the URL for enrollment, which is in the form http://10.10.10.10/certsrv/mscep/mscep.dll. Conﬁgure certiﬁcate attributes such as canonical name (CN) and organizational unit (OU).The XML proﬁle needs to be uploaded into ASA. Using ASDM, navigate to Conﬁguration >Remote Access VPN > Network (Client) Access > AnyConnect Client Proﬁle, click Add to create a client proﬁle, and click Upload to bring the XML ﬁle onto ASA.

STEP 2. Conﬁgure a dedicated enrollment connection proﬁle. Because the XML client proﬁle is a postlogin setting, it can be speciﬁed only into group policy settings. Therefore, you ﬁrst create a group policy and then a connection proﬁle on which you attach it. To conﬁgure a group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and click Add. Navigate further to Advanced > AnyConnect Client and select the XML proﬁle in the Client Proﬁles to Download section.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 139 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

To conﬁgure the connection proﬁle using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Proﬁles, click Add, name it to match the alias from XML proﬁle, leave the authentication method as AAA, and assign the previously created group policy in the Group Policy ﬁeld. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# anyconnect proﬁles SCEP-XML-PROFILE disk0:/SCEP-XML-PROFILE.XML ciscoasa(conﬁg)# group-policy ENROLLMENT-POLICY internal ciscoasa(conﬁg)# group-policy ENROLLMENT-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect proﬁles value SCEP-XML-PROFILE ciscoasa(conﬁg)# tunnel-group ENROLLMENT-PROFILE type remote-access ciscoasa(conﬁg)# tunnel-group ENROLLMENT-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy ENROLLMENT-POLICY ciscoasa(conﬁg)# tunnel-group ENROLLMENT-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# group-alias SCEP-ENROLLMENT enable

STEP 3. Enroll the client into PKI. The user needs to start the AnyConnect Client, initiate the connection, select the previously created connection proﬁle by its alias, and follow the onscreen messages to complete the enrollment and install the certiﬁcate. When the certiﬁcate is installed, AnyConnect automatically disconnects the session. STEP 4. Optionally, conﬁgure the client certiﬁcate selection. Client certiﬁcate selection can be forced through XML proﬁles. In the Client Proﬁle Editor, navigate to the Certiﬁcate Match tab and conﬁgure match rules in the Distinguished Name section. Save the proﬁle and upload it to ASA. Another option is to disable automatic selection and allow the end user to choose the certiﬁcate. In the Client Proﬁle Editor, navigate to the Preferences (cont) tab and choose both Disable Cert Selection and User Controllable. Save the proﬁle and upload it to ASA. Whichever option is used, the XML proﬁle needs to be mapped to the group policy used by the certiﬁcate authentication connection proﬁle or to the DﬂtGrpPolicy, which will apply settings to all existing group policies. STEP 5. Import the CA certiﬁcate into ASA. ASA needs the CA certiﬁcate that issued identity certiﬁcates to clients so that it can verify identity certiﬁcates. You can install it using SCEP or from a base64-encoded ﬁle as in Easy VPN. STEP 6. Enable identity certiﬁcate authentication and mapping for a connection proﬁle.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 140 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Finally, you must create a group policy and connection profile for certificate authentication and certificate to connection profile mapping. To configure a group policy using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies and click Add. Navigate further to Advanced > AnyConnect Client and select the XML profile created in Step 4 in the Client Profiles to Download section. To configure the connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles, click Add, change the authentication method to Certificate, and assign the previously created group policy in the Default Group Policy field. To configure certificate to connection profile mapping using the ASDM, navigate to Configuration > Remote Access VPN > Advanced > Certificate to AnyConnect and clientless SSL VPN Connection Profile Maps and
■ ■ ■ ■

Click Add under Certiﬁcate to Connection Proﬁle Maps. Choose New, give it a name, and select the created connection proﬁle from Mapped to Connection Proﬁle. Click OK to accept the certiﬁcate map. Click Add under Mapping Criteria and specify the DN matching criteria.

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy EXTERNAL-CA-POLICY internal ciscoasa(conﬁg)# group-policy EXTERNAL-CA-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect proﬁles value CERT-XML-PROFILE ciscoasa(conﬁg)# tunnel-group EXTERNAL-CA-PROFILE type remote-access ciscoasa(conﬁg)# tunnel-group EXTERNAL-CA-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy EXTERNAL-CA-POLICY ciscoasa(conﬁg)# tunnel-group EXTERNAL-CA-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate ciscoasa(conﬁg)# crypto ca certiﬁcate map EXTERNAL-CA-MAP 10 ciscoasa(conﬁg-ca-cert-map)# subject-name attr ou eq Financial ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# certiﬁcate-group-map EXTERNAL-CA-MAP 10 EXTERNAL-CA-PROFILE ciscoasa(conﬁg-webvpn)# anyconnect proﬁles CERT-XML-PROFILE disk0:/CERT-XML-PROFILE.XML

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 141 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Deploying Advanced PKI Integration
To maintain a high level of security, you must configure a revocation method to reduce the risk of compromised certificates. It can be implemented in the following ways:
■ ■ ■

CRLs OCSP AAA authorization of user identity certiﬁcates

Because the configuration tasks are identical to ones used in IKEv1 Easy VPN, we do not repeat them in detail here:
■ ■

Conﬁgure a certiﬁcate-revocation checking policy. Conﬁgure AAA authorization revocation.

Deploying Multiple-Client Authentication
The AnyConnect Secure Mobility VPN solution offers the possibility of multiple-client authentication to further strengthen the authentication process:
■ ■ ■ ■ ■

Certiﬁcate based + one AAA authentication Certiﬁcate based + one AAA authentication + username preﬁll Certiﬁcate based + one AAA authentication + preﬁll + hide Certiﬁcate based + double AAA authentication with optional username preﬁll and hide Double AAA authentication (no certiﬁcate) with optional username reuse

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 142 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Certiﬁcate Based + One AAA Authentication
During the AnyConnect session, AAA authentication is performed after certificate authentication. To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles, select the existing connection profile, and click Edit. In the Basic pane, choose Both as authentication method and select the AAA server group to perform AAA authentication. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RADIUS-SRV ciscoasa(conﬁg)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate aaa

Certiﬁcate Based + One AAA Authentication + Username Preﬁll
This is similar to the preceding section, except that the username is extracted automatically by the ASA from the client identity certificate and used for AAA authentication. Users cannot modify it and are prompted only for the password. To enable this feature using the ASDM, navigate to the connection profile, and in the Advanced > Authentication section choose Pre-Fill Username from Certificate and choose the Specify the Certificate Fields to Be Used as the Username radio button to select the certificate attribute the username will be derived from. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RADIUS-SRV ciscoasa(conﬁg)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate aaa ciscoasa(conﬁg-tunnel-webvpn)# pre-ﬁll-username ssl-client

Certiﬁcate Based + One AAA Authentication + Preﬁll + Hide
This is similar to the preceding section, except that the username is not presented to the authenticating client; only the password is being asked for. To enable it using the ASDM, navigate to the connection profile, and in the Advanced > Authentication section check the Hide Username from End User and the Pre-Fill Username from Certificate check boxes (see Figure 3-9).

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 143 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RADIUS-SRV ciscoasa(conﬁg)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate aaa ciscoasa(conﬁg-tunnel-webvpn)# pre-ﬁll-username ssl-client hide

Figure 3-9 Certiﬁcate Based + AAA Authentication
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 144 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Certiﬁcate Based + Double AAA Authentication with Optional Username Preﬁll and Hide
This is similar to the preceding section, except that a secondary AAA authentication scheme is present. To enable it using the ASDM, navigate to connection profile and in Advanced > Secondary Authentication select the AAA server used for secondary authentication and optionally check Use Primary Username (Hide Secondary Username on Login Page) so that second username is not presented to the authenticating client (see Figure 3-10). To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RADIUS-SRV ciscoasa(conﬁg-tunnel-general)# secondary-authentication-server-group TEST-LDAP-SRV use-primary-username ciscoasa(conﬁg)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate aaa ciscoasa(conﬁg-tunnel-webvpn)# pre-ﬁll-username ssl-client hide

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 145 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Figure 3-10 Certiﬁcate Based + Double AAA Authentication

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 146 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

Double AAA Authentication (No Certiﬁcate) with Optional Username Reuse
You can enable double AAA authentication without certificate authentication, as well. To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles, select the existing connection profile, and click Edit. In the Basic pane, choose AAA as the authentication method and select the AAA server group to perform AAA authentication. Navigate to Advanced > Secondary Authentication, select the server group used for secondary authentication, and optionally choose Use Primary Username (Hide Secondary Username on Login Page). To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RADIUS-SRV ciscoasa(conﬁg-tunnel-general)# secondary-authentication-server-group TEST-LDAP-SERV use-primary-username ciscoasa(conﬁg)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate aaa

LDAP Password Management
When you are using LDAP authentication, VPN users can be notified when their password is about to expire and needs to be changed. Password management is supported by all types of remote-access VPNs, but works only with the following:
■ ■

Native LDAP (Microsoft and iPlanet) Radius to AD (RADIUS acts as authentication proxy to external Active Directory.)

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 147 ] Chapter 3: Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions

The following steps need to be completed: STEP 1. Enable the password management feature in the connection proﬁle settings.To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Proﬁles, select the existing connection proﬁle, and click Edit. Navigate further to Advanced > General, check the Enable Password Management check box, and optionally choose the number of days a user should be notiﬁed before the password expires.To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-LDAP-SRV ciscoasa(conﬁg-tunnel-general)# password-management password-expire-in-days 14

STEP 2. On the Active Directory server, enable that attribute that requires password change at the next login. This is needed only for the Radius to AD method. STEP 3. Conﬁgure LDAP Secure (LDAPS). It is required to work with Windows 2008 AD. STEP 4. Ensure that the Login DN has Account Operator privileges into Active Directory.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 148 ] CCNP Security VPN 642-648 Quick Reference

Chapter 4

Deploying Clientless Remote-Access SSL VPN Solutions
This chapter covers basic and advanced clientless Secure Sockets Layer (SSL) virtual private network (VPN) features, authentication methods, and customization of the VPN portal.

Deploying a Basic Clientless VPN Solution
A clientless SSL VPN connection does not require any sort of software installed on remote devices for the initial connection, only compatible standard web browsers. A simple implementation of it uses basic authentication with usernames and passwords, basic portal features, and single-access control policy. ASA supports only RSA certificates; it does not support DSA certificates. ASA 8.4(3) supports the following browsers for clientless SSL VPN access:
■ ■ ■ ■ ■ ■ ■

Windows 7 x86 (32-bit) and x64 (64-bit) via Internet Explorer 9.x and Firefox 4.x Windows Vista x64 via Internet Explorer 7.x-9.x, or Firefox 4.x Windows Vista x86 SP2, or Vista SP1 with KB952876 or later, via Internet Explorer 7.x or 9.x, or Firefox 4.x Windows XP x64 via Internet Explorer 7.x-8.x and Firefox 4.x Windows XP x86 SP2 or later via Internet Explorer 6.x-8.x, or Firefox 4.x Mac OS 10.6.x or 10.5 32- and 64-bit via Safari 3.x-4.x and Firefox 4.x Linux via Firefox 4.x

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 149 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

To successfully implement a basic clientless VPN solution, complete these deployment tasks: 1. 2. 3. 4. Conﬁgure the basic ASA VPN gateway features, including Secure Sockets Layer/Transport Layer Security (SSL/TLS) server authentication. Configure local user authentication. Configure the basic portal features and access control. Optionally, tune the basic SSL VPN proxy operation.

Conﬁguring Basic Cisco ASA SSL VPN Gateway Features
To enable the ASA to act as VPN gateway for clientless SSL VPN sessions, follow these steps: STEP 1. Provision an identity server certiﬁcate on the ASA.Clients authenticate the ASA with a certiﬁcate-based authentication method, and ASA authenticates clients based on username/password credentials. The process and options associated with installing an identity certiﬁcate on the ASA is identical to the AnyConnect SSL VPN solution; it is not covered here. STEP 2. Enable SSL VPN termination on the selected interface. To enable SSL VPN termination on an interface using the Adaptive Security Device Manager (ASDM), navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Connection Proﬁles. In the Access Interfaces pane, check the Allow Access check box for interfaces terminating SSL VPN connections. The difference from the AnyConnect VPN solution is that Datagram Transport Layer Security (DTLS) is not available because it is not supported by clientless solution. To conﬁgure it by command-line interface (CLI), use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# enable outside

STEP 3. Conﬁgure and optionally tune SSL/TLS settings. Optionally, enable/disable SSL/TLS version settings, enable/disable SSL/TLS cipher algorithms, and attach identity certiﬁcates to SSL-enabled interfaces. To conﬁgure these using the ASDM, navigate to Conﬁguration > Remote Access VPN > Advanced> SSL Settings. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# ssl server-version tlsv1-only ciscoasa(conﬁg)# ssl encryption aes256-sha1 aes128-sha1 3des-sha1 des-sha1 ciscoasa(conﬁg)# ssl trustpoint TEST-CA outside
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 150 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 4. Optionally, create a Domain Name System (DNS) server group. Whereas in AnyConnect VPN clients perform DNS requests if internal resources are accessed by name, in clientless VPN, because the ASA acts like a proxy, ASA is the one performing name resolution. ASA needs to have configured DNS servers for this. To configure it using the ASDM, navigate to Configuration > Device Management > DNS > DNS Client and
■

In the DNS Setup section, choose Conﬁgure One DNS Server Group if name resolution is required for a single domain or choose Conﬁgure Multiple DNS Server Groups if for multiple domains. Either way, add DNS servers and specify the domain name these servers are responsible for. In the DNS Lookup section, enable DNS lookup on interfaces facing the declared DNS servers.

■

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# dns domain-lookup inside ciscoasa(conﬁg)# dns server-group DOMAIN-CISCO-COM ciscoasa(conﬁg-dns-server-group)# domain-name cisco.com ciscoasa(conﬁg-dns-server-group)# name-server 10.10.10.10 ciscoasa(conﬁg-dns-server-group)# name-server 10.10.10.11

Conﬁguring Local Password-Based User Authentication
After ASA has been initially configured for SSL connections, you need to further configure it for authenticating and assigning appropriate policies to users. To do so, follow these steps: STEP 1. Conﬁgure the group policy. (Create a new group policy for clientless SSL VPN or modify the default group policy, although the latter is not recommended because it is inherited by all group policies by default.)To create an internal group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, click Add > Internal Group Policy, and in General > Tunneling Protocols, uncheck Inherit and check only the Clientless SSL VPN check box.To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY internal ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 151 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions ciscoasa(conﬁg-group-policy)# vpn-tunnel-protocol ssl-clientless

STEP 2. Optionally, create a connection proﬁle for clientless SSL VPN and assign the group policy to it. To conﬁgure a connection proﬁle using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Connection Proﬁle, click Add, and
■ ■ ■

In the Authentication section, leave the default local AAA authentication method. In the DNS section, select the DNS server group previously created. In the Default Group Policy section, select the group policy previously created.

To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE type remote-access ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE general-attributes ciscoasa(conﬁg-tunnel-general)# default-group-policy BASIC-CLIENTLESS-POLICY ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# dns-group DOMAIN-CISCO-COM

STEP 3. Optionally, deﬁne an alias for the connection proﬁle. In the connection proﬁle, navigate to Advanced > Clientless SSL VPN and in the Connection Aliases section click Add. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# group-alias BASIC-CLIENTLESS-PROFILE enable

STEP 4. Optionally, allow connection proﬁle selection. Using the ASDM, you can allow clients to choose the connection proﬁle within a drop-down menu in the web portal. To do so, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Connection Proﬁles and choose Allow User to Select Connection Proﬁle, Identiﬁed By Its Alias, on the Login Page under Login Page Setting. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# tunnel-group-list enable

STEP 5. Conﬁgure local users and optionally connection proﬁle lock.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 152 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

To configure local users using the ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users > Local Users and click Add. To lock the user into a specific connection profile, navigate further in the user creation window to VPN Policy and select the connection profile in the Connection Profile (Tunnel Group) Lock field. This option, allowing users to select a connection profile (as enabled in previous step), may cause confusion because the user will be able to connect only through a specific connection profile. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# username BASIC-CLIENTLESS-USER password BASIC-CLIENTLESS-PASS ciscoasa(conﬁg)# username BASIC-CLIENTLESS-USER attributes ciscoasa(conﬁg-username)# group-lock value BASIC-CLIENTLESS-PROFILE

Conﬁguring Basic Portal Features and Access Control
For clientless SSL VPN users, the availability of web portal applications such as free URL entry, bookmarks, and network file server is controlled through portal tuning. Also, because the ASA acts like a proxy for clientless SSL VPN user traffic, access control lists (ACL) and the Modular Policy Framework (MPF) access control model cannot be used. For this, webtype ACLs can be used and enforced per user or per group. Webtype ACLs can filter traffic based only on destination, not on source (because the source is always the ASA). The destination can be in the form of a URL resource with limited support of protocols. The destination can be in the form of address and service, where only TCP is supported as a service. In terms of functionality, a webtype ACL behaves like any other ACL. Although, for example, free URL entry can be disabled from the web portal, if the end user knows how to construct the rewritten internal URL the ASA creates and enter it in the browser, the user can still access resources. Therefore, webtype ACLs should be always implemented to really control access to resources, regardless of applications available in the web portal. Within a clientless SSL VPN session, any links accessed through the VPN session (such as links in a document obtained via the VPN session or available in the portal) are rewritten by the ASA, and traffic is forced through the VPN tunnel. For certain resources, this behavior can be

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 153 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

disabled so that traffic bypasses the SSL tunnel, which is known as rewrite disable or mangling in clientless SSL VPN terminology and is similar in result to split tunneling from client based SSL or IPsec VPN. Still, depending on the resource location, additional configuration might be needed:
■ ■

If the accessed resource is not protected by the ASA, located in a network outside of it, no further conﬁguration is needed. If the accessed resource is behind the ASA, trafﬁc is subject to ASA ﬁrewall policies, and so interface ACLs and MPF rules need to allow it.

To achieve these controls, complete one or all of the following configuration steps: STEP 1. Conﬁgure the basic portal feature.To conﬁgure it using the ASDM and make it applicable at group level, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select an existing policy, click Edit, and navigate further to Portal (see Figure 4-1).
■ ■ ■

Conﬁgure the bookmark list. Conﬁgure the URL entry. Conﬁgure ﬁle access control.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 154 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Figure 4-1 Basic Portal Features

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 155 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Note
URL lists can be created only through ASDM; the function is not available in the CLI, because these are saved in XML ﬁles onto ASA ﬂash. This is why content of the BOOKMARKTEST-LIST URL list is not shown in this CLI template.

To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy# webvpn ciscoasa(conﬁg-group-webvpn)# url-list value BOOKMARK-TEST-LIST ciscoasa(conﬁg-group-webvpn)# hidden-shares none ciscoasa(conﬁg-group-webvpn)# ﬁle-entry disable ciscoasa(conﬁg-group-webvpn)# ﬁle-browsing disable ciscoasa(conﬁg-group-webvpn)# url-entry disable

STEP 2. Conﬁgure per-proﬁle or per-user ACLs. To create a webtype ACL using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Web ACLs and click Add > Add ACL. Give it a name, and then click Add > Add ACE to conﬁgure rules. To apply the webtype ACL to a group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select an existing policy, and click Edit. In the General > Web ACL, apply the conﬁgured ACL. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# access-list WEB-ACL-TEST webtype permit url ftp://10.10.10.10 ciscoasa(conﬁg)# access-list WEB-ACL-TEST webtype permit url https://10.10.10.11 ciscoasa(conﬁg)# access-list WEB-ACL-TEST webtype permit tcp host 10.10.10.12 eq 3128 ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy# webvpn ciscoasa(conﬁg-group-webvpn)# ﬁlter value WEB-ACL-TEST

STEP 3. Conﬁgure direct access to resources via rewrite disable. To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Content Rewrite and click Add for an exception rule.To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# rewrite order 1 disable resource-mask *://cisco.com/* name CISCO.COM

To verify the functionality of applied restrictions, you can start a clientless SSL session and note the available applications in the portal. In addition, you can inspect ASA logs to view allowed/denied traffic patterns.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 156 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Troubleshooting Clientless SSL VPNs
As in any VPN troubleshooting scenario, you should use both client and server tools. First, make sure that proper connectivity exists between the client and ASA by means of the ping, traceroute, NSLookup, and dig utilities. If the SSL VPN session does not get established, perform the following inspections:
■ ■ ■ ■ ■

Verify IP and TCP port 443 connectivity between clients and the ASA with ping, traceroute, and Telnet tools. If connection to the ASA is performed by its name or FQDN, ensure that name resolution is functional from clients using nslookup and dig utilities. Check Secure Sockets Layer/Transport Layer Security (SSL/TLS) allowed cipher algorithms on the ASA and supported ones on the client side; identity certiﬁcates and enabled SSL interfaces. Verify user credentials and authentication methods conﬁgured on ASA and the client. Verify whether clientless SSL session is allowed in the connection proﬁle and associated group policy.

If traffic seems not to flow through the tunnel
■ ■ ■

Verify access control methods enabled. Verify content rewriting rules. Verify Domain Name System (DNS) server conﬁguration and accessibility on the ASA.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 157 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Deploying Advanced Application Access for Clientless SSL VPN
Overview
The rewriting proxy feature in the ASA allows for transparent access to web and Common Internet File System (CIFS) internal resources for clientless SSL VPN clients. Because many applications are either not web based or use proprietary protocols, ASA needs mechanisms to accommodate for such application access through the clientless SSL VPN session. For this, multiple options are available:
■

Application plug-ins Access from browser Recommended approach Limited scope of applications

■

Smart tunnels Support for native application clients on remote devices Recommended for applications for which ASA does not offer a plug-in

■

Port forwarding Older technology For use with Linux and older ASA software versions

■

SSL/TLS email proxy POP3S IMAP4S SMTPS

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 158 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Conﬁguring Application Plug-Ins
Plug-ins add functionality to the clientless SSL VPN sessions, but they have their drawbacks (see Table 4-1).

Table 4-1 Clientless SSL VPN Application Access
Beneﬁts Limitations

Do not require client installation on remote system Easy to use for remote user Does not require administrator privileges on system

Only limited number of applets available May not include all native client functionality Not supported on Windows Mobile platform

Application plug-ins are lightweight applications, Java or ActiveX applets, downloaded on request from the VPN gateway. They run inside the browser and use the SSL VPN session to transparently encapsulate traffic within it. Current supported plug-ins are SSH, Telnet, RDP, RDP2, ICA, and VNC. To make these applications available, complete the following configuration steps: STEP 1. Download the plug-ins from Cisco.com and import them into the ASA ﬂash ﬁle system.After plug-ins are downloaded, to import them into ASA using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Client-Server Plug-Ins and click the Import button. Select the plug-in to be imported and the location from local computer, ﬂash or FTP, TFTP, HTTP server.To import it using the CLI, use the following commands: ciscoasa(conﬁg)# import webvpn plug-in protocol rdp ﬂash:/ rdp-plugin.090915.jar

STEP 2. Enable application plug-in access in the SSL VPN portal. To enable plug-in application access, you have two options:
■ ■

Create bookmarks with a plug-in-related URL protocol. Enter a plug-in-related URL with free URL entry.

These options are controlled in the group policies section. To create a bookmark to use imported plug-ins using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks, click Add, and select the appropriate plug-in and create the URL.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 159 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 3. Optionally, control access to internal resources for each plug-in. Access to applications related to plug-ins can be controlled through portal customization and webtype ACLs restrictions applied at user level or group policy level.

Conﬁguring Smart Tunnels
Because application plug-ins support a limited range of applications, smart tunnels further enhance the clientless SSL VPN user experience, but have drawbacks (see Table 4-2). Smart tunnels also require an applet downloaded to the client system so that it can intercept WinSock2 TCP applications and transparently redirect them into the SSL VPN tunnel. Basically, this is how it works:
■ ■ ■

If a smart tunnel is enabled in the user or group policy with the auto-start option, after the SSL VPN session is active, an applet is automatically downloaded to the remote client. If a smart tunnel is enabled in the user or group policy without the auto-start option, after the SSL VPN session is active, the user needs to manually launch the applet for Smart Tunnels to work. From here, it intercepts TCP local socket calls and redirects allowed sessions over the SSL VPN tunnel.

Table 4-2 Smart Tunnels
Beneﬁts Limitations

Supports native client applications over SSL VPN Easy to use for remote user and better performance than plug-ins Does not require administrator privileges on the system like port forwarding does

Only Winsock2 TCP-based applications supported Bypasses advanced ASA application control, secure services module (SSM) Supported only on Windows and Mac OS

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 160 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

To configure smart tunnels, follow these steps: STEP 1. For applications with native clients on remote devices
■ ■

Create a smart tunnel application list or smart tunnel network list. Assign the smart tunnel list to a group policy or user proﬁle.

To create a smart tunnel application list using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Smart Tunnels, click Add under Smart Tunnel Application List for a new tunnel application list, and then click Add to create applications. In the opened window (see Figure 4-2), conﬁgure the following:
■ ■ ■ ■

Application ID is just a friendly name for the application. Process Name is the executable that initiates network connection on remote system. OS is one of supported operating systems. Hash is Secure Hash (SHA-1) of the executable and is supported only on Windows.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 161 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Figure 4-2 Smart Tunnel Application List

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 162 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Although, as an example, we used Outlook, support for smart tunnels and Outlook is available only starting in ASA 8.4.1 and only with Exchange 2010. To assign it to a group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select a policy, and click Edit. Navigate further to Portal > Smart Tunnel > Smart Tunnel Application and assign the created list. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# smart-tunnel list OUTLOOK Outlook outlook.exe platform windows ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# smart-tunnel enable OUTLOOK ciscoasa(conﬁg-group-webvpn)# smart-tunnel auto-start OUTLOOK

Note that you can use only smart-tunnel auto-start or smart-tunnel enable. These commands are mutually exclusive. The ﬁrst one simply starts the Smart Tunnel applet upon successful VPN session connection, whereas the second one needs the user to launch it from the Application Access pane of the portal. Also the auto-start option is applicable only to smart tunnel application lists. To create a smart tunnel network list using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Smart Tunnels, click Add under Smart Tunnel Networks for a new tunnel network list, and then click Add. In the opened window (see Figure 4-3), complete the following ﬁelds:
■ ■

Hostname or IP Address and optionally Subnet Mask

To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# smart-tunnel network NET-LIST ip 10.10.10.10 255.255.255.255 ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# smart-tunnel tunnel-policy tunnelspeciﬁed NET-LIST ciscoasa(conﬁg-group-webvpn)# smart-tunnel tunnel-policy excludespeciﬁed NET-LIST

Note that the you can use only smart-tunnel tunnel-policy tunnelspeciﬁed NET-LIST or smart-tunnel tunnel-policy excludespeciﬁed NET-LIST. These are mutually exclusive. The ﬁrst one speciﬁes trafﬁc for which destination networks to be smart tunneled. The second one speciﬁes that all trafﬁc except those destinations needs to be smart tunneled. There is also a

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 163 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

third option, which does not require a tunnel network list to be created, with the result being that all trafﬁc is smart tunneled. There is also a third option, which does not require a tunnel network list to be created and result being that all trafﬁc is smart tunneled. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# smart-tunnel tunnel-policy tunnelall

Figure 4-3 Smart Tunnel Network List

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 164 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

This second option of conﬁguring a smart tunnel network list brings the split-tunneling functionality to clientless SSL VPN sessions and makes the smart tunneling conﬁguration easier, because you no longer have to know the application executable and operating system of the client. In addition, by using this function, TCP applications using secondary sessions with dynamic ports is now supported with smart tunnels. STEP 2. For web-based applications
■ ■ ■

Add a bookmark to bookmark list. Enable a bookmark for smart tunnel access. Assign the bookmark list to a group policy or user proﬁle.

This is an alternative to problematic sites that are not functional with the normal SSL VPN proxy rewriting function. To conﬁgure smart tunnels for web-based applications, create a bookmark for smart tunnels. Using ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks and click Add. Create a regular bookmark entry and check the Enable Smart Tunnel check box. STEP 3. Control access to internal resources. Restricting smart tunnel applications is ultimately controlled through webtype ACLs.

Conﬁguring Port Forwarding
Port forwarding allows for relaying static port TCP applications over the SSL VPN session. It is the predecessor of smart tunnels, a Java applet, and is more difficult to use because it is not transparent in nature, requiring some application tweaking and some restrictions (see Table 4-3). Given the current functionality if Smart Tunnels, port forwarding has no advantage and is no longer recommended by Cisco. However, here is how it works:
■ ■

If port forwarding is enabled in the user or group policy with the auto-start option, after the SSL VPN session is active the applet is automatically started inside the browser. If port forwarding is enabled in the user or group policy without the auto-start option, after the SSL VPN session is active the user needs to manually launch the applet.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 165 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions ■ ■

Based on the ASA conﬁguration, it modiﬁes the local host ﬁle and starts listening on a preconﬁgured TCP port on the remotehost loopback address of 127.0.0.1. TCP sessions destined for 127.0.0.1 and the respective TCP port are tunneled over the SSL VPN session to ASA.

Table 4-3 Port Forwarding
Beneﬁts Limitations

Support for native client application

Only simple static-port TCP applications supported Bypasses advanced ASA application control, SSM Requires the presence of a native client application Requires users to change their application settings Requires administrator rights to change host ﬁles

To enable port forwarding, complete these steps: STEP 1. Specify the client ports subject to port forwarding. To conﬁgure a port forwarding list using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Port Forwarding and click Add for a New List, and then click Add to create rules. You have the following options (see Figure 4-4):
■ ■ ■ ■

Local TCP Port is the port on which the applet is listening and TCP sessions are initiated on the remote device. Remote Server is the address or name of the ASA protected resource. Remote TCP Port is the port on which the resource is listening for incoming connections and on which ASA directs received sessions for the Local TCP Port. Description is a user-friendly name for this entry.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 166 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Figure 4-4 Port Forwarding List
To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# port-forward RDP 5005 10.10.10.10 3389 Remote Desktop

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 167 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 2. Enable port forwarding in a user proﬁle or group policy. To assign the port forwarding list to a group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select a policy, and click Edit. Navigate further to Portal > Port Forwarding Control and select the created list. To conﬁgure it via the CLI, use the following commands. (Two options are available.) ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# port-forward enable RDP ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# port-forward auto-start RDP

Note that the you can use only port-forward auto-start or port-forward enable. These commands are mutually exclusive. The ﬁrst one simply starts the applet upon successful VPN session connection, whereas the second one needs the user to launch it after successful VPN session connection from the Application Access pane of the portal. STEP 3. Control access to internal resources. Restricting port forwarding applications is ultimately controlled through webtype ACLs.

Troubleshooting Advanced Application Access
To troubleshoot application plug-in problems, follow this methodology:
■ ■ ■ ■

If URLs are not available in the conﬁguration, verify whether the plug-ins were imported. If URLs or bookmarks are not available in the portal, verify group policy or user proﬁle conﬁguration. If a plug-in does not start, verify browser settings for Java and ActiveX applets. If a plug-in does not connect, verify URL conﬁguration, DNS resolution, and webtype ACLs.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 168 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

To troubleshoot smart tunnel problems, follow this methodology:
■ ■ ■ ■

If the agent does not start, verify browser settings for Java and ActiveX. If browser settings are correct, verify the group policy or user proﬁle conﬁguration. If the application does not connect, check webtype ACLs. Verify the smart tunnel list and conﬁgured split-tunneling policy for conﬁguration for errors.

To troubleshoot port forwarding problems, follow this methodology:
■ ■ ■ ■

If an applet does not start, verify Java support in the browser. If Java is supported, verify group policy or user proﬁle conﬁguration. If an application does not connect, check webtype ACLs. Verify the port forwarding list for errors, ASA name resolution, and admin rights on the remote device.

Deploying Advanced Authentication and Single Signon in Clientless SSL VPN
The authentication process within SSL VPN is a key process that you should design to achieve a high level of security, scalability, and integration with existing user databases. The SSL VPN authentication process consists of two different stages: 1. Server-side authentication, where the client veriﬁes the authenticity of the server, multiple options being available
■ ■

Self-signed certiﬁcate The identity certiﬁcate issued by an external certiﬁcate authority (CA), an external Public Key Infrastructure (PKI) scheme

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 169 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

2.

Client-side authentication, where the server veriﬁes the authenticity of clients
■ ■ ■ ■

Identity certiﬁcates issued by the CA residing on ASA Identity certiﬁcates issued by an external CA, an external PKI scheme Passwords (static or one-time passwords) Multiple combined sequential authentications

Deploying Client Certiﬁcate-Based Authentication
When deploying client certificate-based authentication, you have two deployment options: using the ASA local CA or external CA integration.

Client Authentication Using the Local CA
Client authentication using the local CA requires following configuration steps: STEP 1. Conﬁgure the ASA local CA. STEP 2. Create CA user accounts. Because the ﬁrst two steps are identical to AnyConnect Client authentication, a detailed description of the steps is unnecessary here. STEP 3. Enable client certiﬁcate authentication for a connection proﬁle. To conﬁgure certiﬁcate-based authentication in a connection proﬁle using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Connection Proﬁle, select a proﬁle, and click Edit. In Basic > Authentication, choose Certiﬁcate as the authentication method. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# authentication certiﬁcate

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 170 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 4. Optionally, conﬁgure mapping of certiﬁcates to connection proﬁles. To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Advanced > Certiﬁcate to AnyConnect and Clientless SSL VPN Connection Proﬁle Maps. Under Certiﬁcate to Connection Proﬁle Maps, click Add to create a new map and select the connection proﬁle it maps to. Under Mapping Criteria, click Add to create certiﬁcate matching rules. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# crypto ca certiﬁcate map CLIENTLESS-MAP 10 ciscoasa(conﬁg-ca-cert-map)# subject-name attr cn eq ﬁnancial ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# certiﬁcate-group-map CLIENTLESS-MAP 10 BASIC-CLIENTLESS-PROFILE

STEP 5. Provision client identity certiﬁcates to clientless users. The client enrollment process is completed in several steps: 1. 2. 3. 4. 5. The user initiates the clientless SSL VPN session for the certiﬁcate authentication connection proﬁle. The user receives an authentication failure but also a link for obtaining a identity certificate. Following the link, users are asked for their username and one-time password. If credentials are correct, ASA sends the user a Personal Information Exchange (PKCS#12) file that contains the private/ public key pair and user identity certificate. By opening the ﬁle, the user starts the Installation Wizard for the certiﬁcate.

Alternatively, users may receive an e-mail from the ASA with their username, one-time password and the URL to download their certificate from the ASA Local CA. Note that although the ASA has a self-signed certificate in order to run the local CA server, in order for client and server certificate authentication to be successful, the ASA needs an identity certificate for its own. You can either use a user certificate or issue a dedicated one.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 171 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Client Authentication Using an External CA
Client authentication using an external CA requires the following configuration steps: STEP 1. Import the external CA certiﬁcate onto ASA (manually or through Simple Certiﬁcate Enrollment Protocol [SCEP]). STEP 2. Optionally, enroll clients into PKI. If no client identity certiﬁcate exists, only server-side authentication will use the certiﬁcate; client-side authentication will use AAA. STEP 3. Optionally, enable client certiﬁcate authentication for the connection proﬁle. This is required if clients are enrolled into the PKI for client-side certiﬁcate authentication.

Deploying Advanced Gateway PKI Integration, Certiﬁcate Authorization, and Double Authentication
From a security perspective, PKI integration requires methods to verify the availability of certificates, called revocation checking. The same options as for AnyConnect SSL VPNs are available:
■ ■

Optionally, conﬁgure certiﬁcate-revocation checking policy. Optionally, conﬁgure AAA certiﬁcate authorization.

Multiple-client authentications strengthen the authentication process because users have to pass up to three authentication methods (in a row) for the clientless SSL VPN tunnel to establish successfully. Authentication schemes available are identity certificate based and different AAA databases. To achieve a high level of security while improving the user experience, two options are available in multiple authentication schemes:
■ ■

Usernames can be automatically retrieved from certiﬁcate attributes and can be used for primary and secondary AAA authentication. Usernames can be copied for secondary AAA authentication from the primary AAA authentication.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 172 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Available deployment options are the same as for AnyConnect SSL VPN:
■ ■ ■ ■ ■

Certiﬁcate based + one AAA authentication Certiﬁcate based + one AAA authentication + username preﬁll Certiﬁcate based + one AAA authentication + username preﬁll + hide Certiﬁcate based + double AAA authentication with optional username preﬁll and hide Double AAA authentication with optional username reuse

Troubleshooting PKI Integration
PKI integration offers an additional level of security but might introduce potential problems if not understood and configured correctly. A basic troubleshooting approach in certificate-based authentication is as follows:
■ ■ ■ ■ ■

Verify that the enrollment process was successful on both ASA and clients. Verify the current time on both ASA and clients, so that it falls within the certiﬁcate validity period. Verify potential revoked certiﬁcates. Verify the matching criteria in a certiﬁcate to connection proﬁle mappings. Verify correct AAA operations.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 173 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Deploying Clientless VPN SSO
Single signon (SSO) is a clientless SSL VPN feature that allows clients to authenticate only once, when the SSL VPN tunnel is created; accessing resources later through the tunnel does not require additional authentication. This functionality consists of five independent areas and implementation steps: STEP 1. Conﬁgure dedicated SSO servers. ASA supports two dedicated SSO platforms:
■ ■

Computer Associates eTrust SiteMinder (formerly Netegrity SiteMinder) SAML version 1.1 Browser Post Preﬁll

The SSO mechanism is triggered either as part of the AAA process (HTTP Forms), either after successful authentication through an AAA server (SiteMinder) or SAML Browser Post Proﬁle server. When a user logs in, ASA acts like a proxy and sends an SSO authentication request, with username and password, to the authenticating server. If the credentials are correct, the ASA receives back a cookie for the respective clientand it will keep it to authenticate the user against resources protected by the SSO server. Within a clientless SSL VPN session, if the user is authenticated by digital certiﬁcates only, no credentials are available and so integration with an SSO platform is not possible. To conﬁgure an SSO server using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Single Signon Servers and choose Add. In the new window, conﬁgure these parameters for a SiteMinder conﬁguration (see Figure 4-5):
■ ■ ■ ■ ■ ■

In the Server Name ﬁeld, use a name that is signiﬁcant to you. In the Authentication Type ﬁeld, select between the two supported servers. In the Assertion URL ﬁeld, conﬁgure the URL where authentication requests are sent. In the Secret Key ﬁeld, enter the key used to encrypt authentication requests. In the Maximum retries ﬁeld, enter number of requests send to the server for authentication. In the Request Timeout ﬁeld, enter the number of seconds before an authentication request times out.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 174 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Figure 4-5 SSO Server

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 175 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

After the SSO server is conﬁgured, SSO authentication must be enabled in the user proﬁle or group policy. To enable it in a group policy using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select a policy, and click Edit. Navigate further to More Options > Single Signon and specify the SSO server under Single Signon Server.To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# sso-server SITEMINDER-TEST type siteminder ciscoasa(conﬁg-webvpn-sso-siteminder)# web-agent-url https://10.10.10.10 ciscoasa(conﬁg-webvpn-sso-siteminder)# policy-server-secret siteminder ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# sso-server value SITEMINDER-TEST

STEP 2. Besides dedicated SSO servers, two other SSO methods are available for simpliﬁed auto signon scope:
■ ■

HTTP Basic, NTLMv1, and FTP authentication HTTP Form Protocol, which is not covered by the course

HTTP Basic can be used for pages that support HTTP Basic authentication, NTLM can be used for CIFS shares, and FTP can be used for FTP servers. One or all of these methods can be enabled. To enable this feature using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies select to edit the existing policy, navigate to More Options > Single Signon and click Add under Auto Signon Servers. You can use user’s login credentials or specify different credentials (see Figure 4-6):
■ ■ ■ ■ ■

In the IP Address ﬁeld, enter destination networks for which you want SSO. In the Network Mask ﬁeld, enter the mask to identify the subnet. Optionally, instead of conﬁguring a subnet, specify the destination URI for which SSO is desired In the Authentication Type ﬁeld, select the protocols for which SSO is desired. In the Authentication Credential ﬁeld, specify to use login credentials or different ones.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 176 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Figure 4-6 HTTP BASIC, NTLM, FTP
To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# auto-signon allow ip 10.0.0.0 255.0.0.0 auth-type all username Cristian. Matei password easypassword

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 177 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 3. Conﬁgure variable/macro substitution for SSO. Variable and macro substitution allows for certain variables to be injected in bookmarks to substitute for dynamic values, such as usernames and passwords. The most frequently used variable is an internal password, variable being CSCO_WEBVPN_INTERNAL_ PASSWORD, which is entered by the user in the VPN portal separate from the username password and is retained by the ASA to be used for internal services authentication. To enable this feature using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Connection Proﬁles. Under Login Page Setting, check the Allow User to Enter Internal Password on the Login Page check box. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# internal-password enable

Values of variables and macros can be obtained in two ways:
■ ■

From the login page From RADIUS/LDAP vendor-speciﬁc attributes (VSA)

To enable variables in certain bookmarks using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks and click Add. In the new window, click Add and navigate further to Advanced Options. Two macros are commonly used in here which represent the user’s credentials from the login page (CSCO_WEBVPN_USERNAME and CSCO_WEBVPN_PASSWORD) and are supported only for POSTbased methods, not for GET. STEP 4. Conﬁgure SSO for application plug-ins. The application plug-ins do not support variable/macro substitution syntax, but SSO functionality is enabled by embedding the csco_sso=1 parameter in the URI ﬁeld when creating bookmarks. If you want SSO with plug-ins, you need to use this method of creating bookmarks, because users cannot enter the SSO-enabled URL on the clientless SSL VPN page. Two notations are possible within the URI:
■ ■

server/?Parameter&Parameter&csco_sso=1 server/?csco_sso=1¶meter&Parameter

For this, SSO credentials are obtained from VPN login credentials, and an internal password always overrides any other password. If variable/macro substitution is needed, the Cisco POST plug-in should be deployed. You can download this from Cisco.com (and any other plug-ins) and import it into ASA.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 178 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 5. Conﬁgure auto signon with smart tunnels for Internet Explorer. Auto signon is supported for smart tunnel application access from Internet Explorer only:
■ ■ ■

It supports Basic, NTLM, and HTTP authentication. It does not support Form-based authentication. The browser requires Java, ActiveX, or both enabled.

It allows SSO for applications such as SharePoint, Outlook Web Access (OWA), and Citrix by using the SSL VPN session login credentials and passing them to configured servers. To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Smart Tunnels and click Add under Smart Tunnel Auto Signon Server List. Then, you need to enable it in a user profile or group policy. To enable it at group policy level using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select a policy, and click Edit. Navigate further to Portal > Smart Tunnel and configure it in the Auto Signon Server field. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# smart-tunnel auto-signon AUTO-SIGNO-ON ip 10.10.10.10 255.255.255.255 ciscoasa(conﬁg)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# smart-tunnel auto-signon enable AUTO-SIGNO-ON

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 179 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Customizing the Clientless SSL VPN User Interface and Portal
The user interface (that is, the VPN portal) supports both basic and advanced customization, as explored in this section.

Deploying Basic Navigation Customization
The clientless SSL VPN prelogin and postlogin user interface consists of customizable HTML panels. There are two approaches for doing this:
■ ■

ASDM customization, which allows customization of most portal elements Full customization, which allows for personal creation of HTML/XML content imported into ASA

ASA supports an onscreen Java-based keyboard that can be used only at login time or anytime authentication is required. ASDMdriven customization can be achieved through following steps: STEP 1. Create a new customization object.To conﬁgure the onscreen keyboard, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Customization, and in the OnScreen Keyboard section, choose your desired option:
■ ■ ■

Do Not Show Onscreen Keyboard Show Only for Login Page Show for All Portal Pages Requiring Authentication

To create a customization object, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Customization and click Add. Give it a name and select the connection proﬁles it applies to. STEP 2. Edit the customization object. Select the created object and click Edit. Doing so launches the Customization Editor in a new ASDM window, where three main sections are available:
■ ■ ■

Logon Page Portal Page Logout Page
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 180 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

STEP 3. Associate the object with a connection proﬁle. Because customized objects relate to both prelogin and postlogin settings, you can apply them in multiple places: connection proﬁle, group policy, user proﬁle. To map the created object to a connection proﬁle using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Connection Proﬁles, select a connection proﬁle, and click Edit. Navigate further to Advanced > Clientless SSL VPN and select the customized object in the Login and Logout Customization ﬁeld. To map it using the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# customization TEST-CUSTOMIZATION

STEP 4. Optionally, update the default DﬂtCustomization object; all connection proﬁles, which have not been assigned a customized portal, will inherit settings from the DﬂtCustomization.

Deploying Full-Portal Customization
Full customization is based on importing self-made XML components, and there are two possibilities:
■ ■

Replacing the logon screen Using a custom XML portal

To replace the logon screen, follow these steps: STEP 1. Create the custom logon ﬁle. Here, you create the code for logon screen and save it in a ﬁle called logon.inc. STEP 2. Import the ﬁle and images into ASA. Here, the logon.inc and images it references need to be imported into ASA. To do so, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Web Contents and click Import. STEP 3. Conﬁgure the customization object to replace the logon screen. To activate the created logon.inc within the logon screen, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Portal > Customization, select the object, and click Edit. Within the Customization Editor, navigate to Logon Page > Full Customization, enable it, and select the logon.inc ﬁle. STEP 4. Attach the customization object to a connection proﬁle.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 181 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

To map the created object to a connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles, select a connection profile, and click Edit. Navigate further to Advanced > Clientless SSL VPN and select it in the Logon and Logout Page Customization field. To use a custom XML portal, follow these steps: STEP 1. Optionally, export the customization template.To export the customization template so that it can be used as a draft, navigate to Conﬁguration > Remote Access PVN > Clientless SSL VPN >Portal > Customization, select the template, and click Export. STEP 2. Create and XML ﬁle using third-party tools. STEP 3. Import the XML ﬁle as a customization object. After the XML ﬁle is created with third-party tools, you need to import it into ASA. Navigate to Conﬁguration > Remote Access PVN > Clientless SSL VPN >Portal > Customization and click Import. STEP 4. Associate it with a connection proﬁle. To map the imported object to a connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles, select a connection profile, and click Edit. Navigate further to Advanced > Clientless SSL VPN and select it in the Logon and Logout Page Customization field.

Deploying Portal Localization
ASA offers language translation for portal and screens on
■ ■ ■

Clientless SSL VPN sessions Screens associated with plug-ins User interfaces of the Cisco AnyConnect VPN Client

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 182 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

For ease of management, language support is based on multiple translation tables that correspond to functional areas of the SSL VPN portal. There are 11 translation domains, and each can be edited, imported, and exported. Several translation domains have three preconfigured languages in addition to English: French, Russian, and Japanese. To configure language localization, follow these steps: STEP 1. View, export, import, and edit language translation tables. STEP 2. Enable customization of the language selector. STEP 3. Conﬁgure customization languages. STEP 4. Associate the customization object with a connection proﬁle. To manage translation tables, navigate to Configuration > Remote Access VPN >Language Localization. After localization tables are created, you need to enable the language selector. Navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Customization, select the desired customization object, and click Edit. Within the Customization Editor, navigate to Logon Page > Language Selector, choose Enable, and edit the available language list. To configure customization languages, within the Customization Editor navigate to Logon Page > Languages and add languages. To map the imported object to a connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles, select a connection profile, and click Edit. Navigate further to Advanced > Clientless SSL VPN and select it in the Logon and Logout Page Customization field.

Deploying Portal Help Customization
ASA provides help content during clientless sessions. Each clientless application pane displays its own help file content using a predetermined filename. Existing help files can be modified or additional help files may be added. To configure portal help customization, follow these steps: STEP 1. Display the help ﬁle in a browser by accessing the help ﬁle URL, after successful authentication. STEP 2. Save the help ﬁle on the local computer. STEP 3. Customize the help ﬁle. STEP 4. Import the customized help ﬁle into ASA.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 183 ] Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

Help file URLs are in the form https://IP_ADDRESS/+CSCOE+/help/language/filename. Open it and, from the browser, choose File > Save As. Use only *.htm or *.html formats. After customization, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Help Customization and click Import.

Cisco AnyConnect Portal Integration
From within a clientless SSL VPN session, the AnyConnect panel enables users to start the AnyConnect Client. When a user clicks the AnyConnect button in the AnyConnect panel, one of two actions is triggered:
■ ■

AnyConnect Client software is launched if already installed on remote device. If AnyConnect is not installed, the client is downloaded from ASA, and the installation procedure starts.

In both cases, an AnyConnect tunnel is established; the clientless session remains active, but only one license is used. This postlogin behavior can be controlled in user profile or group policy settings. To configure it using the ASDM at group level, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select a policy, and click Edit. Navigate further to More Options > Login Setting:
■ ■

Under Post Login Setting, you can allow users to choose, or apply the default post login selection. Under Default Post Login Selection, choose Download AnyConnect Client if a client-based tunnel is established.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 184 ] CCNP Security VPN 642-648 Quick Reference

Chapter 5

Deploying Advanced Cisco ASA VPN Solutions
This chapter analyzes the advanced features of virtual private network (VPN) solutions, such as VPN authorization and accounting, Cisco Secure Desktop (CSD), dynamic access policies (DAP), and high availability.

Deploying VPN Authorization, Access Control, and Accounting
The terms access control and authorization are often used interchangeably. VPN implementation on ASA supports the following authorization methods:
■ ■

Local authorization through access control lists (ACL) or webtype ACLs. Control can be applied at a user or group level. RADIUS or Lightweight Directory Access Protocol (LDAP) authorization.

In contrast, VPN accounting is supported only with external authentication, authorization, and accounting (AAA) servers (TACACS+ and RADIUS), keeping track of VPN session activity (including start and stop time). Control mechanisms can be applied at multiple levels in the VPN system, but ASA applies it according to this hierarchy, the top ones taking priority over the others: 1. 2. 3. 4. 5. DAP rules User profile rules Group policy attached to user profile Group policy attached to the connection profile DﬂtGrpPolicy settings

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 185 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Some supported authentication servers (for example, RSA SDI) do not provide authorization/accounting services. In such cases, a AAA system can be daisy-chained to satisfy all requirements. In this case, you’ll have a
■ ■

AAA front-end server that acts as authentication proxy between ASA and back-end AAA AAA back end that stores the user database

Deploying Local Authorization
To configure local VPN authorization, follow these steps: STEP 1. Conﬁgure an ACL (for full-tunnel VPN, both Secure Sockets Layer [SSL] and IP Security [IPsec] IKEv1/IKEv2). To conﬁgure it using the Adaptive Security Device Manager (ASDM), navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Advanced > ACL Manager. Click Add ACL to create a new ACL, and then click Add ACE to create rules within the ACL.To conﬁgure it by command-line interface (CLI), use the following command: ciscoasa(conﬁg)# access-list TEST-ACL permit tcp any host 10.10.10.10 eq 80

STEP 2. Conﬁgure a webtype ACL (clientless SSL VPN). To conﬁgure it using the ASDM, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Web ACLs. Click Add ACL to create a new ACL, and then click Add ACE to create rules within the ACL. To conﬁgure it via the CLI, use the following command: ciscoasa(conﬁg)# access-list TEST-WEB-ACL webtype permit url https://10.10.10.10

STEP 3. Conﬁgure group policy restrictions. To create/edit a group policy using the ASDM, two GUI options are available. We’ll use the one for full VPN (IPsec or AnyConnect). Navigate to Conﬁguration > Remote Access VPN > Network (Client) Access > Group Policies and click Add or Edit. To conﬁgure clientless SSL-speciﬁc group settings, navigate to Conﬁguration > Remote Access VPN > Clientless SSL VPN Access > Group Policies, select the policy, and click Edit. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy ciscoasa(conﬁg)# group-policy ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-policy)# ciscoasa(conﬁg-group-webvpn)# BASIC-GROUP-POLICY internal BASIC-GROUP-POLICY attributes vpn-tunnel-protocol IPSec svc webvpn vpn-ﬁlter value TEST-ACL webvpn ﬁlter value TEST-WEB-ACL

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 186 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

STEP 4. Apply a group policy to connection proﬁles, user proﬁles, or both. To apply the group policy (for example, at user level) using the ASDM, navigate to Configuration >Remote Access VPN > AAA/ Local Users, select the user, and click Edit. Navigate further to VPN Policy and select the group policy in the Group Policy field. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# username TEST-USER password TEST-PASS ciscoasa(conﬁg)# username TEST-USER attributes ciscoasa(conﬁg-username)# vpn-group-policy BASIC-GROUP-POLICY

Verification can be made on the client side by trying to access resources restricted by ACLs. On the server side, verify that proper group policy has been assigned to the user by navigating to Monitoring > VPN > VPN Statistics > Sessions or by using the following CLI commands (see Example 5-1 and Example 5-2): ciscoasa# show vpn-sessiondb webvpn ciscoasa# show vpn-sessiondb anyconnect ciscoasa# show vpn-sessiondb ra-ikev1-ipsec

Example 5-1

Verify Clientless SSL VPN Sessions

ciscoasa# show vpn-sessiondb webvpn ﬁlter name cristian.matei Session Type: WebVPN Username Public IP Protocol License Encryption Bytes Tx Group Policy Login Time Duration Inactivity NAC Result VLAN Mapping : : : : : : : : : : : : cristian.matei Index 188.26.145.25 Clientless SSL VPN RC4 Hashing 127870 Bytes Rx BASIC-GROUP-POLICY Tunnel Group 03:23:12 UTC Sun Jan 9 2011 0h:02m:01s 0h:00m:00s Unknown N/A VLAN : 1588

: SHA1 : 20635 : BASIC-CONNECTION-PROFILE

: none

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 187 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Example 5-2

Verify IPsec VPN Sessions

ciscoasa# show vpn-sessiondb ra-ikev1-ipsec ﬁlter name cristian.matei Session Type: IPsec Username Assigned IP Protocol License Encryption Bytes Tx Group Policy Login Time Duration Inactivity NAC Result VLAN Mapping : : : : : : : : : : : : cristian.matei Index 192.168.16.1 Public IP IKE IPsecOverNatT IPsec 3DES AES256 Hashing 10968 Bytes Rx TEST-POLICY Tunnel Group 03:29:29 UTC Sun Jan 9 2011 0h:01m:42s 0h:00m:00s Unknown N/A VLAN : 1589 : 188.26.145.25

: SHA1 : 23219 : TEST-GROUP

: none

Deploying External Authorization
To enable external authorization, both ASA and an external server need to be configured. On the ASA side, perform the following tasks:
■ ■ ■ ■

Add an external AAA server (RADIUS or LDAP). Optionally, conﬁgure an LDAP attribute map. Assign an external AAA server to a connection proﬁle. Optionally, create baseline group policies referenced by an external AAA server.

On the AAA server (for example, Cisco Secure Access Control Server [ACS]), perform the following tasks:
■ ■

Conﬁgure the ASA as a AAA client. Create users and user groups.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 188 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions ■ ■ ■

Optionally, deﬁne Internet Engineering Task Force (IETF) attribute 25 to reference a baseline group policy. Optionally, prepare the authorization interface. Optionally, conﬁgure speciﬁc authorization parameters.

To add an external RADIUS server using the ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups. Under AAA Server Groups, click Add and choose RADIUS as the protocol. Highlight the created group, click Add under Servers in the Selected Group, and configure the necessary parameters. To add an external LDAP server using the ASDM, the procedure is the same, except that when you create a server group, choose LDAP as the protocol. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# aaa-server TEST-RADIUS protocol radius ciscoasa(conﬁg)# aaa-server TEST-RADIUS (inside) host 10.10.10.10 ciscoasa(conﬁg-aaa-server-host)# key CISCO ciscoasa(conﬁg)# aaa-server TEST-LDAP-SRV protocol ldap ciscoasa(conﬁg)# aaa-server TEST-LDAP-SRV (inside) host 10.10.10.11 ciscoasa(conﬁg-aaa-server-host)# server-type Microsoft ciscoasa(conﬁg-aaa-server-host)# ldap-over-ssl enable ciscoasa(conﬁg-aaa-server-host)# server-port 636 ciscoasa(conﬁg-aaa-server-host)# sasl-mechanism digest-md5 ciscoasa(conﬁg-aaa-server-host)# ldap-scope subtree ciscoasa(conﬁg-aaa-server-host)# ldap-base-dn cn=users, dc=cisco, dc=com ciscoasa(conﬁg-aaa-server-host)# ldap-naming-attribute cn ciscoasa(conﬁg-aaa-server-host)# ldap-login-password TEST-LDAP-PASSWORD ciscoasa(conﬁg-aaa-server-host)# ldap-login-dn cn=ASAUSER, dc=cisco, dc=com

When attribute names used by LDAP are different from ones used by ASA or you just want to bind a certain LDAP attribute to a certain Cisco attribute, an LDAP attribute map needs to be created. Using ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users > LDAP Attribute Map and choose Add. Enter an LDAP attribute name, select the corresponding Cisco attribute name, and choose Add to move the mapping to the configured list. You now need to assign the map to the LDAP server group. Navigate to the LDAP server, click Edit, and assign the LDAP map in the LDAP Attribute Map field.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 189 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# aaa-server TEST-LDAP-SRV (inside) host 10.10.10.11 ciscoasa(conﬁg-aaa-server-host)# ldap-attribute-map LDAP-MAP

To configure the connection profile for external authentication using the created group server, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profile, select a profile, and click Edit. Under Authentication, check the AAA check box and select the server group. To enable authorization, navigate further to Advanced > Authorization and select the server group under Authorization Server Group. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# authorization-required ciscoasa(conﬁg-tunnel-general)# authentication-server-group TEST-RADIUS ciscoasa(conﬁg-tunnel-general)# authorization-server-group TEST-RADIUS

In Cisco ACS Version 4.x, to add ASA as a client, navigate to Network Configuration > Add Entry, specify the ASA IP address, shared secret configured, and protocol used as RADIUS (Cisco VPN 3000/ASA/PIX 7.x+). To configure groups in ACS, navigate to Group Setup. To configure users, navigate to User Setup > Add/Edit. Any RADIUS attribute, before it can be configured in the group setup of ACS, first needs to be enabled. You can do so from Interface Configuration > RADIUS (Cisco VPN 3000/ASA/PIX 7.x+) or Interface Configuration > RADIUS (IETF). In the authorization process, to specify the ASA local group policy to be used, enable the ACS IETF attribute 25. To do so, navigate to Interface Configuration > RADIUS (IETF) and enable the [025] Class attribute. Navigate to the group or user setup in ACS and specify for this attribute the group policy name from the ASA. Because VPN authorization primarily focuses on ACLs, these can be pushed from the ASA as part of the authorization process. Downloadable ACLs are created in the Shared Profile Components area and assigned afterward at user or group level in ACS.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 190 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Conﬁguring VPN Session Accounting
Deployment tasks are as follows:
■ ■

Add a RADIUS or TACACS+ server; optionally, use an existing one. Enable accounting in the connection proﬁle.

Note
Downloadable ACLs override local ASA ACL conﬁgurations.

To enable accounting using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles, select a profile, and click Edit. Navigate further to Advanced >Accounting and select the server under Server Group. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group TEST-GROUP general-attributes ciscoasa(conﬁg-tunnel-general)# accounting-server-group TEST-RADIUS

To verify functionality, initiate a VPN session and navigate into ACS to Reports and Activity > RADIUS Accounting. Check the presence of records for the respective VPN session. Accounting information includes the following:
■ ■ ■

Session start and stop times. Trafﬁc volume in bytes for the VPN session Services used and duration of each session

Accounting information is maintained by username if such credentials were requested by VPN authentication method.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 191 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Troubleshooting Authorization and Accounting of Clientless SSL VPN
Troubleshooting the authorization and accounting process should be performed on both the ASA and the external AAA server. If a VPN session gets established but an authorization profile does not get applied, or accounting records are not present on the AAA server, follow these steps: STEP 1. Verify connectivity with the AAA server and whether authorization is properly conﬁgured on ASA. STEP 2. Verify logging on the AAA server for any granted or failed authorization attempts. STEP 3. Check whether the required group policy has been applied to the VPN session. STEP 4. Verify whether the authorization policy on the AAA server is correctly conﬁgured.

Deploying Cisco Secure Desktop in SSL VPNs
Overview
You can implement Cisco Secure Desktop (CSD) to reduce risks introduced by untrusted endpoints that connect to the enterprise network via AnyConnect Client (SSL VPN and IPsec IKEv2) or clientless SSL VPN sessions. It provides a set of features that you can configure to work together or independently:
■ ■ ■ ■

Prelogin Assessment installs itself before user login and can check the remote device for certain ﬁles, digital certiﬁcates, OS, IP address, and Windows Registry keys. Host Scan is a module part of the Prelogin Assessment and consists of any combination of Basic Host Scan, Endpoint Assessment, and Advanced Endpoint Assessment. Vault (Secure Desktop) encrypts data and ﬁles associated to the VPN session into a secure desktop partition. Upon VPN termination, it removes the partition in a secure fashion. Cache Cleaner is a limited alternative to Secure Desktop, but it supports more operating systems. It cleans the browser cache at the end of the VPN session.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 192 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions ■ ■ ■ ■ ■ ■ ■

Keystroke Logger Detection scans for processes that record keystrokes entered by users. CSD Policies speciﬁes the remote user restrictions based on prelogin assessment results. Integration with DAP, one or more endpoint attributes can be used as conditions for assigning a DAP. Host Emulation Detection determines whether a remote Windows OS is running over virtualized software. Windows Mobile Device Management allows posture checks speciﬁc to mobile devices; it does not apply for clientless sessions. Standalone Installation Packages offers a manual installation option (instead of being distributed by the ASA). CSD Manual Launch allows starting a clientless SSL VPN session by launching CSD.

To better understand all these features, here is how a VPN session will go: Note
Host Scan and Cache Cleaner do not support the 64-bit version of Microsoft IE. CSD is not supported for IKEv1 IPsec VPN sessions.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

The remote user starts an AnyConnect or clientless SSL VPN session. The operating system detection module is downloaded and started. The Prelogin Assessment module is downloaded and started. Based on the Prelogin Assessment result, the login is denied or CSD policies are applied. A check is made for keystroke logger and host emulation. Secure Vault or Cache Cleaner is downloaded and started. The user authenticates. DAP checks are applied. The VPN tunnel becomes active. Post-session cleanup occurs at VPN termination.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 193 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Not all these features are available for all operating systems (see Table 5-1).

Table 5-1 Cisco Secure Desktop Compatibility Table
Operating System Prelogin Assessment Host Scan Vault Cache Cleaner Keystroke Logger Host Emulation

Windows 7 Windows Vista Windows XP Windows Mobile Apple Mac OS Linux

Yes Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes Yes

32-bit only 32-bit only 32-bit only N/A N/A N/A

Yes Yes Yes N/A Yes Yes

32-bit only 32-bit only 32-bit only N/A N/A N/A

32-bit only 32-bit only 32-bit only N/A N/A N/A

For clientless SSL VPN, IE 6.0, IE 7.0, Mozilla 3.0.x, and Safari 3.2.1 is the minimum browser version for Prelogin Assessment and Host Scan functions. For Linux, only 32-bit and 64-bit versions of Red Hat Enterprise Linux 3/4/5, Fedora Core 4 or later, and Ubuntu have been tested. CSD can be installed on remote devices as follows: 1. AnyConnect SSL VPN
■ ■ ■

If installed after AnyConnect, it does not require administrative privileges. If installed together with AnyConnect, it requires administrative privileges. If an executable ﬁle is used on a remote client, it requires administrative privileges. ActiveX, requires administrative privileges Sun JVM, does not require administrative privileges Executable ﬁle, requires administrative privileges
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

2.

Clientless SSL VPN
■ ■ ■

[ 194 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To enable functionality of CSD, follow these deployment steps: STEP 1. Install and enable CSD on the ASA.Complete these conﬁguration tasks:
■ ■ ■

Download, install CSD, and enable it globally on the ASA. Optionally, disable CSD on a per-connection proﬁle basis. Customize CSD to display custom banners and background.

To upload CSD into ASA using the ASDM, navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Setup, click Upload, and check the Enable Secure Desktop check box.To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# csd image disk0:/csd_3.5.2008-k9.pkg ciscoasa(conﬁg-webvpn)# csd enable

To disable CSD in a speciﬁc connection proﬁle, edit the connection proﬁle and navigate to Advanced > Clientless SSL VPN or to Advanced > Group Alias/Group URL and check the Do Not Run Cisco Secure Desktop (CSD) check box. To conﬁgure it via the CLI, use the following commands: ciscoasa(conﬁg)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributes ciscoasa(conﬁg-tunnel-webvpn)# without-csd

To customize CSD (supported only for 32-bit Windows Vista, XP SP2 and SP3) using the ASDM, navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Secure Desktop Customization and click the Choose Color button to change colors. To modify background or banner images, you need to import new images into ASA using the Import button. STEP 2. Conﬁgure prelogin criteria. In this step, you can check for the presence and integrity of certain ﬁles, the presence of digital certiﬁcates, the type of operating system, IP address, and Windows Registry keys. To conﬁgure these using the ASDM, navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin policy. ASDM provides a simple tool to deﬁne prelogin policies in a graph form with if-then conditions. To add criteria, click the circle with the + sign to open the Check Options window. Each criterion has multiple results, which effectively creates branches in the decision tree. These branches lead to an end node, which can be one of three types:

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 195 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions ■ ■ ■

Login Denied, which cuts off any further processing for this branch and login access is blocked Policy, which deﬁnes the endpoint proﬁle, the state endpoint achieves at this point of the tree Subsequence, which allows terminating the branch and continuing it in another place in the graph to avoid cluttering

Policies can be labeled and appear automatically under Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin policy (the default policy being available as a start). On a Windows PC, users can verify the received Prelogin Assessment data by viewing logs in Event Viewer, Application Log section. STEP 3. Conﬁgure prelogin policies. Based on assessment, CSD policies can be assigned to hosts. Under CSD policies, you can enable the following: 1. Vault
■ ■ ■ ■

A new, temporary desktop environment is created. Access to the original desktop is allowed by default; it is called desktop switching. All disk writes are to the newly created encrypted environment. At VPN termination, everything is overwritten using a Department of Defense (DoD) sanitation algorithm. At VPN termination, it removes browser data using the DoD sanitation algorithm. It can monitor only one browser application per SSL VPN session. Detects host emulation or virtualization Conﬁgurable to disallow virtualized hosts from connecting Detection for loggers running as a process or kernel module Does not detect hardware-based loggers

2.

Cache Cleaner
■ ■

3.

Detect Host Emulation
■ ■

4.

Detect Keystroke Logger
■ ■

STEP 4. Conﬁgure advanced endpoint assessment.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 196 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Host Scan installs on the remote device and runs periodically during the SSL VPN session to detect whether changes have occurred. It can be installed as a standalone module or along with AnyConnect client and consists of three modules:
■ ■ ■

Basic Host Scan detects OS, ﬁles, Registry, IP address, and certiﬁcates. Endpoint Assessment scans for personal ﬁrewall, antivirus, and antispyware and provides information to DAP but does not perform remediation. Advanced Endpoint Assessment scans for personal ﬁrewall, antivirus, and antispyware and performs remediation (rules, updates).

To install Host Scan as a standalone package using ASDM, navigate to Configuration > Remote Access VPN > Host Scan Images and specify the package to use from flash or upload it from your PC. To configure prelogin policies, follow these steps: STEP 1. Enable Vault or Cache Cleaner.Navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies, select a policy, and check the Secure Desktop (Vault) or Cache Cleaner check box. If Secure Desktop (Vault) is selected in cases where it is not supported by the client, Cache Cleaner installs instead. STEP 2. Conﬁgure Vault parameters. Navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies and select a policy. From here, you have multiple options:
■ ■ ■

Secure Desktop (Vault) General. Conﬁgure settings such as allowing switching between secure and local desktops or Vault inactivity timeout. Secure Desktop (Vault) Settings. Conﬁgure settings such as disabling printing, command prompt and Registry access, and network drives access. Secure Desktop (Vault) Browser. In Vault, the browser does not show user bookmarks or favorites but only CSD bookmarks, which are conﬁgured here.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 197 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

STEP 3. Alternatively, conﬁgure Cache Cleaner parameters. Navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies, select a policy, and navigate further to Cache Cleaner. Here, conﬁgure settings, such as launching cleanup based on inactivity timeout or closing of all browser instances. STEP 4. Enable keystroke logger detection. Navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies, select a policy, and navigate further to Keystroke Logger & Safety Checks. Check the Check for Keystroke Loggers check box to enable the feature and optionally add loggers to be exempted from scanning by checking the Force Admin Control on List of Safe Module check box. STEP 5. Enable host emulation detection. Navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies, select a policy, and navigate further to Keystroke Logger & Safety Checks. Check the Check for Host Emulation check box. STEP 6. Enable Host Scan. Navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Host Scan and click Add to perform one or more scans: Registry, Scan, or Process. To enable endpoint assessment, check the Endpoint Assessment check box under Host Scan Extensions.

Conﬁguring Advanced Endpoint Assessment
This requires an Advanced Endpoint Assessment license and can be used to remediate with following actions:
■ ■ ■

Enable the antivirus software if it was disabled. Update the signature deﬁnition for antivirus and antispyware if not updated for a deﬁned number of days. Enable and reconﬁgure ﬁrewall rules if they do not meet deﬁned requirements.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 198 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To configure Advanced Endpoint Assessment, follow these steps: STEP 1. Enable Advanced Endpoint Assessment.Navigate to Conﬁguration > Remote Access VPN > Secure Desktop Manager > Host Scan and check the Advanced Endpoint Assessment check box under Host Scan Extensions. From here, click Conﬁgure to achieve the following steps. STEP 2. Conﬁgure antivirus software assessment. STEP 3. Conﬁgure antivirus software remediation. STEP 4. Conﬁgure personal ﬁrewall software assessment. STEP 5. Conﬁgure personal ﬁrewall software remediation. STEP 6. Conﬁgure antispyware software assessment. STEP 7. Conﬁgure antispyware software remediation.

Troubleshooting CSD Operation for Clientless Connections
If CSD does not operate as intended, use this approach for troubleshooting:
■ ■ ■ ■

Check the correct SSL/TLS session functionality. Check Prelogin Assessment policies. Check whether CSD is downloaded and installed; if not, verify browser settings for ActiveX and Sun JVM and PC logs. Check the creation of the secure desktop session; check PC and ASA logs.

Deploying Cisco NAC Appliance Integration
You can use the Cisco Identity Services Engine (ISE), formerly NAC Appliance, as an alternative to CSD. You can use ISE to determine the posture of AnyConnect and IPsec VPN clients. ISE can
■ ■

Recognize users, devices, and user roles Evaluate endpoint posture
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 199 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions ■ ■

Enforce security policies to endpoints based on posture Enable endpoint remediation by allowing access to remediation and update servers

You can integrate Cisco ISE with Cisco ASA to support single signon (SSO). To make this possible
■ ■

On ASA, conﬁgure a AAA server to be the trusted interface of the Cisco ISE appliance. Enable accounting of VPN connections in a connection proﬁle.

Deploying Dynamic Access Policies
Overview
Note
Trying to conﬁgure DAP records using the CLI might cause DAP to stop working. So, using the ASDM for DAP is recommended.

Dynamic access policies (DAP) enhance the authorization process of VPN sessions to address the dynamics of VPN environments. Therefore, for example, a user may receive different authorization policies depending on its client or session type. A DAP is generated for each VPN session during the user authentication process by selecting/aggregating attributes from one or more DAP records or DAP rule sets. DAP selection attributes are stored in an XML file called dap.xml in ASA flash system memory. DAP applies to remote-access VPNs (IKEv1/IKEv2 IPsec and client/clientless SSL VPN), but here we discuss it as it applies to SSL VPN. The components of DAP are as follows:
■ ■ ■

One or more DAP records, deﬁning a limited set of authorization attributes that can override authorization deﬁned locally or received from AAA server. Local and AAA attributes, upon which DAP records are selected. Endpoint attributes of connecting clients, which can be determined using CSD, upon which DAP records are selected.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 200 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

In each DAP record one or more attributes can be configured as conditions for the VPN session, as well as one or more authorization policies. Multiple DAP records can be combined in a resulting DAP that is assigned to the remote-access VPN session upon connection. Each DAP record has its own name and priority, a value used by ASA to sequence ACLs when aggregating network and webtype ACLs from multiple records. Authorization parameters that can be provided by DAP are as follows: 1. Action
■ ■ ■

Continue applies policy attributes to session Terminate terminates VPN session Quarantine used for remediation

2. 3. 4. 5. 6. 7. 8.

Network ACLs Webtype ACLs Port forwarding lists Bookmarks Functions, allows configuring file server and URL entry, HTTP proxy, file server browsing Access method, enforces type of remote access VPN session allowed AnyConnect, select status of always-on VPN ﬂag

DAP is applied in the following sequence of events: 1. 2. 3. 4. 5. 6. 7. The remote client attempts a VPN session. ASA performs a posture assessment using NAC and CSD Host Scan. ASA authenticates the user via AAA; AAA returns authorization attributes. ASA applies authorization attributes to the session. ASA selects one or more DAP records based on AAA authorization and posture assessment. ASA aggregates attributes from selected DAP records to become a DAP policy. ASA applies the DAP policy to the VPN session.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 201 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Conﬁguring DAP
To configure DAP, follow these steps: STEP 1. Create a DAP policy. STEP 2. Specify AAA attributes matching criteria. STEP 3. Specify endpoint attributes matching criteria. STEP 4. Conﬁgure authorization parameters. STEP 5. Conﬁgure the action for DﬂtAccessPolicy. To create a DAP policy using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Dynamic Access Policies and click Add:
■ ■

Give it a name and optionally a description. Specify ACL priority. A higher number means higher priority; this is important when network or webtype ACLs are combined in case of multiple DAP records matching. If multiple DAP records have the same priority and conﬂicting ACL rules, the most restrictive one applies; however, you should avoid this conﬁguration if possible. Add local/AAA and endpoint attributes. Conﬁgure one or more authorization parameters.

■ ■

Optionally, you can configure the DfltAccessPolicy authorization result to terminate as an action so that any VPN session that does not match at least one configured DAP record is disallowed. By default, DfltAccessPolicy has its action set to continue, with no configured authorization attributes, acting as a catchall method and allowing VPN sessions. This is because DAP is enabled by default, and if it were not configured in this way, it would have denied all incoming VPN sessions. Note that the DfltAccessPolicy is matched only if no other DAP records are configured or none of these were matched. DAP can be verified on both the client and server side. For clientless SSL VPN, after authentication a user message is displayed as a yellow exclamation mark. On the server side, use the following commands to verify whether the DAP policy was applied. (If any network or webtype ACL has been applied as a result of the DAP, it shows up in the ASA running configuration and as a filter for the VPN session.) ciscoasa# show vpn-sessiondb detail ciscoasa# show access-list | i DAP
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 202 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Aggregating DAP Records
A VPN session can match multiple DAP records, and the following occurs:
■ ■

Authorization attributes, such as network ACLs, webtype ACLs, and bookmarks, are concatenated and ordered based on the ACL priority of each DAP record, order being from higher priority to lower priority. Other authorization attributes concatenation behaves as follows. If at least one record has its action set to Terminate, ﬁnal action will be Terminate. For the Continue action to be applied, all matched DAP records need to have the action set to Continue. For functions like port forwarding, ﬁle server browsing, ﬁle server entry, HTTP proxy, and URL entry, the end result does not depend on the ACL priority, and the following rules apply: 1. If for the same function at least one DAP record has its value set to Auto-Start, the resulting action is Auto-Start. 2. If for the same function, at least one DAP record has its value set to Enable and no DAP record has its value set to Auto-Start, the resulting action is Enable. 3. If for the same function, at least one DAP record has its value set to Disable and no DAP record has its value set to Auto-Start or Enable, the resulting action is Disable. 4. Otherwise, the resulting action is the default Unchanged, which means to inherit values from the group policy that applies to the session.

If multiple DAP records are matched, and these have port forwarding lists configured, these will be concatenated, in an order based on the ACL priority. Because DAP records are automatically ordered top-down based on the ACL priority, this is the order in which ASA process it for concatenating port forwarding lists. To configure the aggregation of records, follow these steps: STEP 1. Conﬁgure an additional DAP record policy. STEP 2. Specify local/AAA attributes matching criteria. STEP 3. Conﬁgure authorization parameters.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 203 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To verify whether policies have been aggregated, check whether authorization parameters from multiple DAP records exist. See whether required attributes to match multiple DAP records are present on the client side. On the server side, use following commands to verify whether DAP policies have been applied: ciscoasa# show vpn-sessiondb detail ciscoasa# show access-list | i DAP

Integrating CSD with DAP
DAP supports two posture assessment methods to collect endpoint attributes:
■ ■

CSD Host Scan (not available for IKEv1 IPsec VPNs) Cisco NAC

To integrate DAP with CSD, complete these tasks:
■ ■ ■

Create a DAP policy or edit an existing one. Specify endpoint assessment matching criteria. Conﬁgure authorization parameters.

The endpoints attribute types resulting from CSD scans that can be matched inside DAP policy are as follows:
■ ■ ■ ■ ■

Antispyware Antivirus Application AnyConnect File

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 204 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions ■ ■ ■ ■ ■ ■ ■

Device NAC Operating system Personal ﬁrewall Policy Process Registry

You should implement DAPs to apply authorization profiles based on the client assessment CSD result, or to assign authorization attributes that might not be available in external AAA authorization profiles (external group policies configuration). You should avoid using the same authorization functions in static group policies (internal or external) and DAP because it results in configuration overhead without any benefit.

Custom LUA Functions
LUA is a fast and lightweight scripting language supported by the ASA. Custom LUA scripts can be used when the ASDM GUI for DAP does not provide needed granularity in matching criteria. In production environments, Technical Assistance Center (TAC) assistance is recommended. ASDM provides a guide with sample LUA scripts, accessible from Configuration > Remote Access VPN > Clientless SSL VPN Access > Dynamic Access Policies. Select a DAP, click Edit, and navigate to Advanced > Guide.

Troubleshooting Dynamic Access Policy
To troubleshoot DAP issues, you can use the ASDM test feature, ASA logging, and DAP debugging commands. From the ASDM GUI, in the DAP configuration section, a Test Dynamic Access Policies button is available. It enables you to define attribute matching criteria and test to verify which DAP policy will apply for selected attributes. You can use the debug dap trace and debug dap errors commands for advanced investigations.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 205 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Deploying High Availability/Performance in SSL and IPsec VPNs
Most of the time, VPN deployments require high availability and high performance. High availability ensures service operation if one or more VPN gateways fail, and high performance boosts system performance and end-user experience by load balancing VPN sessions among multiple VPN gateways. Cisco ASA offers these methods for high availability:
■ ■ ■ ■

Redundant peering using multiple independent ASAs. Users have proﬁle backup servers deﬁned in their AnyConnect or IPsec VPN clients. IKEv1 IPsec site to site also supports redundant peering, but clientless SSL VPN does not. Server load balancing (SLB) requires installing a Catalyst 6500 or 7600 series router with Application Control Engine (ACE) module or using a dedicated ACE appliance to balance VPN sessions to multiple VPN gateways. Active/standby failover requires two identical ASA appliances conﬁgured in a failover scenario. It does not provide load balancing, but stateful failover, if conﬁgured, includes the VPN subsystem. Cluster load balancing shares VPN sessions across a cluster of VPN gateways without the need for additional load balancers.

Deploying Redundant Peering
This approach does not apply to clientless SSL VPN. Because backup VPN gateways can be defined, a mechanism to detect failure of a primary VPN gateway within a VPN session is needed. Dead peer detection (DPD), a standard-based mechanism that is enabled by default, is used. DPD is also required for AnyConnect SSL VPN sessions for DTLS tunnel fallback to a TLS tunnel. DPD messages are exchanged when there is no tunnel traffic, is challenge-response based, and both tunnel endpoints can initiate and detect it. However, we are interested in client-side detection, to reconnect the VPN session as fast as possible to the next available VPN gateway.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 206 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

AnyConnect and IPsec VPN clients are assigned static or dynamic IP addresses for which ASA proxies. For VPN users to have access to internal resources, their assigned IP addresses need to be known in the routing domain. You have two options:
■ ■

Conﬁgure static routing for VPN user subnets to point toward their respective ASAs. If ASA is running dynamic routing protocols with an internal network, redistribute static routes of VPN subnets into an interior gateway protocol (IGP).

For AnyConnect clients, ASA automatically configures a static host route for each client, whereas for IKEv1 IPsec clients it needs Reverse Route Injection (RRI) configured. To configure redundant peering for each of the VPN supported types, follow the steps in Table 5-2.

Table 5-2 VPN Redundant Peering
Step AnyConnect Easy VPN IPsec Site to Site

1 2 3 4 5

Create a proﬁle. Upload the proﬁle to ASA. Assign the proﬁle to a user or group. Optionally, tune DPD. Optionally, redistribute static routes into an IGP.

Conﬁgure backup servers on ASA or the client. Optionally, tune DPD. Optionally, enable RRI. Optionally, redistribute static routes to an IGP.

Conﬁgure backup servers. Optionally, tune DPD. Optionally, enable RRI. Optionally, redistribute static routes to an IGP.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 207 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

AnyConnect Redundant Peering
An AnyConnect client profile to include backup servers can be created with AnyConnect Profile Editor available on the ASA or as standalone application. To upload an XML file into ASA using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile and click Import to add it to flash file system. Then, click Add to create a profile. To assign a profile to group using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select a policy, and click Edit. Navigate further to Advanced > AnyConnect Client and select the profile under Client Profiles to Download. To modify DPD settings using the ASDM, edit a group policy and navigate further to Advanced > AnyConnect Client > Dead Peer Detection. Here enable or disable client-side/gateway-side settings and modify the interval. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# webvpn ciscoasa(conﬁg-webvpn)# anyconnect proﬁles REDUNDANT disk0:/REDUNDANT.xml ciscoasa(conﬁg)# group-policy BASIC-ANYCONNECT attributes ciscoasa(conﬁg-group-policy)# webvpn ciscoasa(conﬁg-group-webvpn)# anyconnect dpd-interval gateway 20 ciscoasa(conﬁg-group-webvpn)# anyconnect dpd-interval client 20 ciscoasa(conﬁg-group-webvpn)# anyconnect proﬁles value REDUNDANT

Easy VPN Redundant Peering
For Easy VPN (IKEv1 IPSec sessions), backup servers can be defined on clients or an ASA VPN gateway can push back the server list in the Mode Config phase. To define, using the ASDM, how clients obtain backup server configuration, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select a policy, and click Edit. Navigate further to Advanced > IPSec Client and, under IPSec Backup Servers, choose between:
■ ■ ■

Keep Client Conﬁguration (the default). With this option, you must conﬁgure backup servers on the client. Use the Backup Servers Below (and specify the servers). This is pushed to clients in the Mode Conﬁg phase. Clear Client Conﬁguration. This makes the client not use backup servers.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 208 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To configure servers on a client, open IPsec VPN Client, navigate to Backup Servers and specify servers here by name or IP address. To modify DPD settings, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPSec(IKEv1) Connection Profile, select one, and click Edit. Navigate further to Advanced > IPSec, and you have following options:
■ ■ ■

Disable Keepalives Headend Will Never Initiate Keepalive Monitoring (Response is allowed, and client can initiate DPD.) Monitor Keepalives and specify Conﬁdence Interval (idle timer before DPD starts) and Retry Interval (interval between DPD retries)

To enable RRI using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPSec > Crypto Maps, select a crypto map, and click Edit. Navigate further to Tunnel Policy (Crypto Map) > Advanced and check the Enable Reverse Route Injection check box. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# group-policy BASIC-GROUP-POLICY attributes ciscoasa(conﬁg-group-policy)# backup-servers 10.10.10.10 10.10.10.11 ciscoasa(conﬁg)# tunnel-group BASIC-TUNNEL-GROUP ipsec-attributes ciscoasa(conﬁg-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2 ciscoasa(conﬁg)# crypto dynamic-map MY-DYNAMIC-MAP 65535 set reverse-route

IPsec Site-to-Site Redundant Peering
To specify backup servers using the ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > Crypto Maps, select one, and click Edit. Add backup servers under IPsec Address of Peer to Be Added. To enable RRI, navigate further to Tunnel Policy (Crypto Map) > Advanced and check the Enable Reverse Route Injection check box. DPD settings are the same as for Easy VPN, except that is configured elsewhere. Navigate to Configuration > Site-to-Site VPN > Connection Profiles, select one, and click Edit. Navigate further to Advanced > Tunnel Group and configure it under IKE Keepalive.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 209 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Deploying High Availability and High Performance Using Network SLB
In AnyConnect and Easy VPN, ACE does not terminate the VPN connection but distributes it to different VPN gateways based on the source IP address and connection “stickiness.” In clientless SSL VPN, ACE can terminate SSL sessions from users, and based on decrypted session attributes, a load-balancing algorithm is used to distribute sessions to ASAs. ACE supports VPN load balancing based on the following features:
■ ■ ■ ■

The virtual server IP address to which clients connects Class and policy maps to establish and maintain connections ACE role in SSL VPN (clientless SSL VPN), acting as server for VPN users and as client for ASA User authentication (clientless SSL VPN)

Deploying Cisco ASA Active/Standby Failover
In this scenario, there is a primary and secondary unit that initially have the roles of active and standby, each configured with active and standby IP addresses and MAC addresses for each interface. When the failover criteria is met, the secondary unit becomes active and takes over the active IP and MAC addresses so that failover is transparent in the network. To configure a pair of ASA into active/ standby failover mode, complete the following steps: STEP 1. Conﬁgure the failover link. STEP 2. Conﬁgure active and standby addresses on used interfaces. STEP 3. Deﬁne the failover criteria. STEP 4. Optionally, conﬁgure nondefault MAC addresses. To enable and configure failover using the ASDM, navigate to Configuration > Device Management > High-Availability > Failover. In the Setup pane, check the Enable Failover check box (see Figure 5-1):
■ ■ ■

Select the machine role, primary or secondary. Conﬁgure the LAN and state failover interfaces. Optionally, enable HTTP replication (HTTP sessions replication) and failover shared key to secure failover messages.
© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 210 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Note that an ASA, which is involved in a failover scenario be it active/active or active/standby, cannot act as a local CA. These two functions, failover and local CA, are mutually exclusive for the moment. To configure active and standby addresses on interfaces, open the Interfaces tab, configure IP addresses and mask, and select which interfaces are monitored (taken into consideration for failover). Failover is based on a defined number/percentage of failed interfaces or unit failure. To specify these and timers for unit/interface polling and hold timers, open the Criteria tab. To configure failover via the CLI on the primary unit, use the following commands: ciscoasa(conﬁg)# failover lan unit primary ciscoasa(conﬁg)# failover lan interface FAILOVER GigabitEthernet0/2 ciscoasa(conﬁg)# failover polltime unit 2 holdtime 6 ciscoasa(conﬁg)# failover polltime interface 4 holdtime 12 ciscoasa(conﬁg)# failover interface-policy 10% ciscoasa(conﬁg)# failover key CISCO-FAILOVER ciscoasa(conﬁg)# failover link FAILOVER GigabitEthernet0/3 ciscoasa(conﬁg)# failover interface ip FAILOVER 1.1.1.1 255.255.255.252 standby 1.1.1.2 ciscoasa(conﬁg)# interface GigabitEthernet0/2 ciscoasa(conﬁg-interface)# no shutdown ciscoasa(conﬁg)# interface GigabitEthernet0/3 ciscoasa(conﬁg-interface)# no shutdown ciscoasa(conﬁg)# failover

Configuration on the secondary unit is identical except for the first command, which designates the device as secondary: ciscoasa(conﬁg)# failover lan unit secondary

For two ASAs to run in failover, identical hardware except for flash size is required. From a software perspective, identical major and minor software release is required. On a long term, however, to ensure feature parity and configuration consistency, both devices should run identical software release. Starting with ASA code 8.3.x, the two devices running in failover can have different licenses (exception is that ASA 5510 needs a Security Plus license for failover to be enabled), as licenses from both devices will be combined into a running active license.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 211 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Figure 5-1 ASA Failover

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 212 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Deploying Dynamic Routing-Based VPN Failover
If multiple site-to-site tunnels exist from one site to another, dynamic routing protocols are commonly used to fail over from the primary tunnel to secondary ones if the primary path becomes unavailable. Cisco ASA supports running Open Shortest Path First (OSPF) Protocol over IPsec without generic routing encapsulation (GRE), because GRE is not available on ASA. To configure such a scenario, follow these steps: STEP 1. Add OSPF as interesting trafﬁc to the IPsec tunnel. (Add it to a crypto ACL.) STEP 2. Enable the OSPF process. STEP 3. Specify advertised networks. STEP 4. Set the OSPF network type to nonbroadcast. STEP 5. Change the OSPF cost on one path to inﬂuence the primary path. STEP 6. Manually conﬁgure the OSPF neighbor, as multicast is not supported for this speciﬁc conﬁguration. To add OSPF as interesting traffic using the ASDM, navigate to Configuration > Firewall > Advanced > ACL Manager, select the ACL used for the site-to-site VPN, and click Add > Add ACE. In the new ACE
■ ■ ■

The source is the local IP address of interface terminating the tunnel. The destination is the remote VPN tunnel interface IP address. The service is OSPF.

To enable the OSFP process using the ASDM, navigate to Configuration > Device Setup > Routing > OSPF > Setup and open the Process Instances tab. To specify OSPF networks, open the Area/Networks tab from same path and click Add. Specify the area ID and optionally modify the area type from normal. Under Area Networks, you need to add at a minimum networks for both VPN endpoints, local and remote. (This is an exception to the regular OSPF functionality.) To change cost and modify network type using the ASDM, navigate to Configuration > Device Setup > Routing > OSPF > Interface and open the Properties tab. Choose the interface terminating VPN tunnel and click Edit. Disable the Broadcast type and specify cost. To enable the static OSPF neighbor using the ASDM, navigate to Configuration > Device Setup > Routing > OSPF > Static Neighbor and click Add. Specify the neighbor IP address and outgoing interface to reach the neighbor.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 213 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# access-list IPSEC-ACL extended permit ospf interface outside host 20.20.20.20 ciscoasa(conﬁg)# router ospf 1 ciscoasa(conﬁg-router)# network 10.10.10.10 255.255.255.255 area 0 ciscoasa(conﬁg-router)# network 20.20.20.20 255.255.255.255 area 0 ciscoasa(conﬁg-router)# neighbor 20.20.20.20 interface outside ciscoasa(conﬁg)# interface GigabitEthernet0/0 ciscoasa(conﬁg-if)# ospf cost 1 ciscoasa(conﬁg-if)# ospf network point-to-point non-broadcast

Deploying ASA VPN Clustering
With this approach, a group of ASA appliances works as a single entity, a cluster that is identified by a virtual IP address to outside users. This virtual IP address is not tied to a specific physical device and is managed by the cluster master that redirects all VPN sessions on the virtual IP to the least-loaded machine from the cluster. Each appliance periodically sends load information in a keepalive message to the master. Load is calculated as percentage of current active sessions divided by the maximum supported by the platform. Cluster load balancing supports all types of remote-access VPN (SSL and IKEv1/IKEv2 IPsec). When ASA is part of a cluster, the virtual cluster agent (VCA) automatically starts and its scope is for
■ ■ ■ ■ ■ ■

Joining and exiting the cluster Establishing IPsec connections between peers in the cluster Calculating the load Sending periodic load and health information to cluster master Determining a failed cluster master Electing the cluster master

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 214 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

When VPN requires certificate authentication, the remote device must verify both the identity certificate of the master and participant to which it is redirected. Three types of certificates can be used in this scenario, the last two being recommended:
■ ■

Standard X.509 identity certiﬁcate. This option requires an identity certiﬁcate for each cluster member and one identity certiﬁcate for the cluster master. The cluster master certiﬁcate needs to be imported on all members as well. Uniﬁed Client Certiﬁcate (UCC). This uses an extension attribute called Subject Alternative Name (SAN) to deﬁne an alternative trusted subject name. This option requires only one UCC certiﬁcate installed on all cluster members. Basically, the UCC certiﬁcate will have its Subject Name CN equal to the cluster master fully qualiﬁed domain name (FQDN) and its SAN CN equal to the cluster members FQDN. This is the recommended approach as it offers the best security and functionality, while using only one certiﬁcate for all devices. Wildcard certiﬁcate. This identity certiﬁcate is issued for an FQDN that does not contain a CN, thus being valid for multiple devices within same FQDN but less secure. This option requires only one certiﬁcate installed on all cluster members.

■

The following aspects need to be considered for VPN clustering:
■ ■ ■ ■ ■ ■

The redirection method (based on IP address or FQDN, by default on IP address) must reﬂect the certiﬁcate Subject Name to avoid mismatch pop-up warnings. Failure of the current member requires the user to reconnect the VPN session. Failure of the master triggers an election process. Licensing. The number of licenses per cluster is the sum of all member licenses. Active/standby failover may be deployed along with VPN clustering. VPN licenses from all participating devices are added to identify the total number of sessions per cluster.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 215 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To deploy VPN cluster, follow these steps: STEP 1. Install UCC, wildcard, or multiple standard certiﬁcates. STEP 2. Conﬁgure the cluster IP address. STEP 3. Optionally, conﬁgure encryption. STEP 4. Conﬁgure internal and external interfaces. STEP 5. Optionally, conﬁgure member priority. STEP 6. Optionally, conﬁgure FQDN-based redirection. UCC or wildcard certificates require the following procedure: STEP 1. On the master, conﬁgure a trustpoint. STEP 2. On the master, import a UCC certiﬁcate. STEP 3. On the master, export the trustpoint certiﬁcate and keys as pkcs12. STEP 4. On each member, import the pkcs12. Multiple standard X.509 certificates require the following procedure:
■ ■ ■ ■ ■

On each member, deﬁne two trustpoints: cluster and individual. On each member, import a certiﬁcate for the individual trustpoint. On the master, import a cluster certiﬁcate. On the master, export the cluster certiﬁcate as pkcs12. On each member, import the pkcs12.

To configure all other cluster parameters using the ASDM, navigate to Configuration > Remote Access VPN > Load Balancing or Configuration > Device Management > High Availability > VPN Load Balancing.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 216 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# vpn load-balancing ciscoasa(conﬁg-load-balancing)# cluster ip address 198.52.1.2 ciscoasa(conﬁg-load-balancing)# cluster key CISCO ciscoasa(conﬁg-load-balancing)# cluster encryption ciscoasa(conﬁg-load-balancing)# redirect-fqdn enable ciscoasa(conﬁg-load-balancing)# participate ciscoasa(conﬁg-load-balancing)# priority 10

Deploying VPN Quality of Service
Because traffic inside the VPN tunnel needs to be treated differently, quality of service (QoS) is implemented. It is supported only for IKEv1 IPsec VPNs remote-access or IKEv1/IKEv2 IPsec VPNs site-to-site. Cisco Modular Policy Framework (MPF) structure allows for QoS to be applied and supports these features:
■ ■ ■ ■

Input policing Output policing Low-latency queuing (LLQ) Shaping only for class default

To deploy QoS, follow these steps: STEP 1. Optionally, deﬁne the priority queue on the required interfaces. STEP 2. Create a service policy. STEP 3. Deﬁne the trafﬁc class criteria. STEP 4. Deﬁne the match criteria. STEP 5. Deﬁne an action. STEP 6. Optionally, repeat this process for other classes.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 217 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Priority queuing is enabled per interface (needed for LLQ). To configure it using the ASDM, navigate to Configuration > Device Management > Advanced > Priority Queue and click Add. Select the interface, priority queue buffer, and transmit queue size. To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# priority-queue outside ciscoasa(conﬁgpriority-queue)# tx-ring-limit 80 ciscoasa(conﬁgpriority-queue)# queue-limit 2048

To create a service policy using the ASDM and prioritize VPN traffic, navigate to Configuration > Firewall > Service Policy Rules, click Add > Add Service Policy Rule, and
■ ■ ■ ■

Select the interface-terminating VPN tunnel and click Next. Create a trafﬁc class and use match criteria of Tunnel Group and click Next. Select the connection proﬁle whose trafﬁc will be matched and click Next. Open the QoS tab and deﬁne actions.

To configure it via the CLI, use the following commands: ciscoasa(conﬁg)# class-map VPN-CLASS ciscoasa(conﬁg-cmap)# match dscp 46 ciscoasa(conﬁg-cmap)# match tunnel-group BASIC-CONNECTION-PROFILE ciscoasa(conﬁg)# policy-map VPN-POLICY ciscoasa(conﬁg)-pmap)# class VPN-CLASS ciscoasa(conﬁg)-pmap-c)# priority ciscoasa(conﬁg)# service-policy VPN-POLICY interface outside

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 218 ] Chapter 5: Deploying Advanced Cisco ASA VPN Solutions

Troubleshooting ASA VPN Failover and Clustering
If active/standby failover is not functioning, perform these inspections:
■ ■ ■

Verify failover conﬁguration on both machines. Use the command show failover to see the status of failover and verify IP connectivity between machines on all interfaces. Verify that plug-ins, XML proﬁles, and images are loaded on both machines. If failover occurred, verify the switching infrastructure content-addressable memory (CAM) table for active-unit MAC addresses.

If cluster load balancing is not functional, perform these inspections:
■ ■ ■

Verify cluster settings on all members. If certiﬁcates are used, verify whether needed certiﬁcates are installed on members. Verify route redistribution.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 219 for more details.

[ 219 ] CCNP Security VPN 642-648 Quick Reference

CCNP Security VPN 642-648 Quick Reference
Cristian Matei Copyright © 2012 Pearson Education, Inc. Published by Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA All rights reserved. No part of this digital Quick Reference may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. First Release May 2012 ISBN-13: 978-1-58714-315-1

Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members of the professional technical community. Reader feedback is a natural continuation of this process. If you have any comments on how we could improve the quality of this digital Quick Reference, or otherwise alter it to better suit your needs, you can contact us through e-mail at feedback@ciscopress.com. Please be sure to include the digital Quick Reference title and ISBN in your message. We greatly appreciate your assistance.

Corporate and Government Sales
The publisher offers excellent discounts on this digital Quick Reference when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales 1-800-382-3419 corpsales@pearsontechgroup.com. For sales outside the United States please contact: International Sales international@pearsoned.com

Warning and Disclaimer
This digital Quick Reference is designed to provide information about the CCNP Security Certiﬁcation. Every effort has been made to make this digital Quick Reference as complete and accurate as possible, but no warranty or ﬁtness is implied. The information is provided on an “as is” basis. The author, Cisco Press, and Cisco Systems, Inc., shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this digital Quick Reference. The opinions expressed in this digital Quick Reference belong to the author and are not necessarily those of Cisco Systems, Inc.

Trademark Acknowledgments
All terms mentioned in this digital Quick Reference that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the accuracy of this information. Use of a term in this digital Quick Reference should not be regarded as affecting the validity of any trademark or service mark.

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright.

Cisco Ccnp Security Training

Similar Documents

New Technology My Field

Dude

Ccnp Bsci 642 901

Network Plus

Answer

Student

Doc, Docx Pdf

Ccna

Alksdjf

Cisco

Work

Cataolog

Damsel

Computer

Popular Essays