Cisco CCNP Security VPN 642-648 Quick Reference

ptg7987094

ptg7987094

ciscopress.com

CCNP Security VPN 642-648 Quick Reference

Table of Contents

Chapter 1Evaluating the Cisco ASA VPN Subsystem .......................................3

Chapter 2Deploying Cisco ASA IPsec VPN Solutions ............................. 42

Chapter 3Deploying Cisco ASA AnyConnect Remote-Access SSL VPN Solutions ..............................109

Chapter 4Deploying Clientless Remote-Access SSL VPN Solutions ................148

Chapter 5Deploying Advanced Cisco ASA VPN Solutions .............................184

Cristian Matei

ptg7987094

[ 2 ]

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


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 finished the MCSE Security and MCSE Messaging tracks. He then joined Datanet Systems, where he quickly obtained his Security and Routing & Switching CCIE, among other certifications and specializations, such as CCNP, CCSP, and CCDP. Cristian has been a Cisco Certified 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 certified as a Cisco IronPort Certified 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 Certified Information Security Manager (CISM) certification. 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 field of IT since the mid 1990s, working with companies such as Cisco, Lucent, Verizon, and AT&T. Sean currently holds certifications 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 certificate 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.

http://www.sr-wconsulting.com

ptg7987094

[ 3 ]



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.

ptg7987094

[ 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.

ptg7987094

[ 5 ]



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 configured.

■ Logical name is configured.

■ Security level is assigned.

■ Interface must be enabled, removed from administratively down state. ciscoasa (config)# interface Ethernet0/1 ciscoasa (config-if)# ip address 192.1681.1 255.255.255.0ciscoasa (config-if)# nameif inside ciscoasa (config-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 configured is inside , the default security level assigned is 100 .

■ If the logical name configured 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, traffic from higher security level interfaces to lower security level interfaces is allowed; this is called outbound traffi c .

■ By default, traffic 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 traffi c .

■ Traffic between interfaces with same security level is by default denied and can be allowed to pass by enabling same-security-traffic permit inter-interface globally on the appliance.

ptg7987094

[ 6 ]



■ Traffic 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-traffic 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 traffic flows 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.

ptg7987094

[ 7 ]



■ ASA is performing outside NAT when traffic flows 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 fixed 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 specified and therefore the port can also be mapped.

■ Identity NAT translates an original address to itself, bypassing NAT; useful to exempt from NAT certain traffic which matches an existing NAT configuration.

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:

■ Traffic flowing from high- to low-security interfaces need to match on a NAT rule.

■ Traffic flowing from low- to high-security interfaces does not need to match any NAT rule. (An exception applies when outside dynamic NAT or PAT is configured for any particular traffic; then, all traffic needs to match a NAT rule.)

ptg7987094

[ 8 ]



■ Traffic flowing between interfaces at the same security level does not need any NAT rule. (An exception applies when dynamic NAT or PAT is configured on the same security level interface; then, all traffic from that interface to the same-security or lower-security interface needs to match a NAT rule.)

■ Static NAT or PAT does not trigger the need for traffic 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 traffic between chosen interfaces or between chosen source-destination pairs.

■ NAT exemption ( nat 0 access-list command) exempts traffic matched in the ACL from NAT rules regardless of the exit interface; the ACL does not support Layer 4 information to be configured.

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-traffic permit intra-interface command is globally enabled on the appliance.

■ The interface becomes both inside and outside from the NAT configuration 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).

ptg7987094

[ 9 ]



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 configured.

■ ASA does not support equal-cost load balancing over multiple interfaces. Therefore, for any given unique destination prefix, 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 defined 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 configured 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 traffic forwarding.

ptg7987094

[ 10 ]



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 configured 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 configured.

■ 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.

ptg7987094

[ 11 ]



Table 1-1 Routing Protocols on Cisco ASA

RIP OSPF EIGRP

Distance-vector routing protocol

Link-state routing protocol Hybrid routing protocol

Single RIP process Two concurrent OSPF processes (An interface cannot participate in both processes.)

Single EIGRP process

N/A Stub and NSSA areas, virtual links EIGRP stub

By default, sends V1 update and accepts both V1 and V2 updates

Broadcast and point-to-point network types Dynamic (multicast) and static (unicast) neighbors

Clear-text/MD5 authentica-tion in V2.

Clear-text/MD5 authentication MD5 authentication

Automatic summarization Manual summarization Automatic and manual summarization

Route information filtering with access lists

Interarea LSA Type 3 filtering with prefix lists Route-information filtering with access lists

Default route origination Normal and conditional default route origination

Clearing of the candidate default route bit on incoming and outgoing updates

Routed single-context mode 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.

ptg7987094

[ 12 ]



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-specific 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 .

www.cisco.com/en/US/partner/docs/security/asa/asa81/config/guide/aaa.html#wp1039490

www.cisco.com/en/US/partner/docs/security/asa/asa81/config/guide/aaa.html#wp1039490

ptg7987094

[ 13 ]



Table 1-2 Firewall Authentication Services

Service Local RADIUS TACACS+ SDI Windows NT Kerberos

VPN users Yes Yes Yes Yes Yes Yes

Administration Yes Yes Yes No No No

Firewall sessions Yes Yes Yes No No No

Table 1-3 Firewall Authorization Services

Service Local RADIUS TACACS+ SDI Windows NT Kerberos LDAP

VPN users Yes Yes No No No No Yes

Administration Yes No Yes No No No No

Firewall sessions No No Yes No No No No

Table 1-4 Firewall Accounting Services

Service Local RADIUS TACACS+ SDI Windows NT Kerberos LDAP

VPN users No Yes Yes No No No No

Administration No No Yes No No No No

Firewall sessions No Yes Yes No No No No

ptg7987094

[ 14 ]



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 traffic

■ Policy maps to set actions on identified traffic 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 traffic shaping and hierarchical priority queuing

■ Stateful application inspection at Layer 5–7

■ NetFlow Secure Event Logging (NSEL) export

■ Forwarding traffic to the Cisco Intrusion Prevention System Module (AIP-SSM)

■ Forwarding traffic to the Cisco Content Security and Control Module (CSC-SSM)

ptg7987094

[ 15 ]



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) Bidirectional Ingress

TCP sequence number randomization (IPv4 and IPv6) Bidirectional Ingress

TCP and UDP connection limits and timeouts (IPv4 and IPv6) Bidirectional Ingress

TCP state bypass (IPv4 and IPv6) Bidirectional Ingress

QoS input and output policing (only IPv4) Ingress/egress Ingress/egress

QoS standard priority queuing (only IPv4) Egress Egress

QoS traffic shaping, hierarchical priority queuing (only IPv4) Egress N/A

Stateful application inspection at Layer 5–7 (for IPv6 only FTP, HTTP, ICMP, SIP, SMTP, IPsec)

Bidirectional Ingress

NSEL export (IPv4 and IPv6) N/A Ingress

Forwarding traffic to AIP-SSM (IPv4 and IPv6) Bidirectional Ingress

Forwarding traffic to CSC-SSM (only IPv4) Bidirectional Ingress

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

■ If a flow matches multiple classes inside the same policy map, actions are combined if different.

■ If a flow matches multiple classes inside the same policy map and actions are conflicting, flow matches on first class based on the order it appears in the policy map.

ptg7987094

[ 16 ]



■ If a flow matches the same policy on both the global and interface level, the interface-level policy takes precedence and is the final action applied.

■ If a flow 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 traffic 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

■ Certificate authority (CA), which grants identity certificates

■ Digital certificates that uniquely identify endpoints

■ Optional registration authority (RA) to offload the CA for the enrollment process

■ Distribution mechanism for certificate revocation list (CRL)

ptg7987094

[ 17 ]



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. Generate an RSA key pair, resulting in one private key and one public key. 2. 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 certificate 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

■ Certificate enrollment

■ Certificate revocation

■ Certificate 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-to-any or any-to-one VPNs this imposes the following drawbacks:

■ The number of public key exchanges is not scalable.

■ Out-of-band verification is neither real time nor scalable.

ptg7987094

[ 18 ]



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:

■ Name of the identity certificate holder

■ Public key of the holder

■ Digital signature of the CA

■ Certificate serial number

■ Certificate 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 certificates; each PKI entity checks this list on a regular basis.

■ Online Certificate Status Protocol (OCSP), which is more secure than CRLs because it provides real-time verification of identity certificates against a database and does not need to download any list of revoked certificates as it is working on a query mechanism basis.

■ AAA Based Certificate Authorization, a proprietary Cisco method relying on the RADIUS protocol to query AAA servers for revocation information in real time.

Note PKI requires that time between VPN peers be synchronized to correctly identify certificate valid-ity on both sides.

ptg7987094

[ 19 ]



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 Unified 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 traffic 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.

ptg7987094

[ 20 ]



Site-to-site VPNs differ as follows:

■ Connect sites for added security over existing WAN.

■ Use peer authentication, message integrity, and traffic 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 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) , defined in RFC 2402, uses IP protocol number 51 and encapsulates user traffic to offer data integrity, data-origin authentication, and protection against replay attacks.

■ Encapsulation Security Payload (ESP) , defined in RFC 4303, uses IP protocol number 50 and encapsulates IPv4/IPv6 user traffic to offer data integrity, data-origin authentication, confidentiality, and protection against replay attacks.

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

ptg7987094

[ 21 ]



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 Diffie-Hellman (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 traffic, this being the final 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 mod e 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.

Note AH is no longer sup-ported 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 sup-ported starting with ASA software Version 8.4.x.

ptg7987094

[ 22 ]



■ 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 configuration 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 specified 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 )

Original IP Header TCP/UDP Data

AH HeaderOriginal IP Header TCP/UDP Data

Authenticated

Original IP Header ESP Header TCP/UDP Data ESP Trailer ESP Auth

AuthenticatedEncrypted

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 )

ptg7987094

[ 23 ]



Original IP Header TCP/UDP Data

New IP Header AH Header Original IP Header TCP/UDP Data

Authenticated

New IP Header ESP Header Original IP Header TCP/UDP Data ESP Trailer ESP Auth

AuthenticatedEncrypted

Figure 1-2 IPsec Tunnel Mode Encapsulation

SSL/TLS Refresher 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 certificates

■ Optionally authenticates client to server by means of X.509 identity certificates

■ Negotiates encryption algorithms and generates shared keys

■ Establishes a secure SSL/TLS tunnel to ensure confidentiality and integrity for both TCP and UDP traffic

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

Note Full tunneling is just a term meant to differenti-ate from the clientless VPN method. It does not mean that all traffic between two VPN end-points is forced through the tunnel. As discussed further, in the full-tunneling remote-access VPN, you have the option to tunnel all traffic (full tunneling) or selected traffic (split tunneling).

ptg7987094

[ 24 ]



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 certificate.

■ 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 firewalls 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.

ptg7987094

[ 25 ]



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) file 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 firewalls 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.

ptg7987094

[ 26 ]



■ 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 files 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 firewall).

■ 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:


■ 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 firewalls and NAT devices because IPsec(ESP) and IKEv1/IKEv2 might be restricted along the path between clients and VPN gateway.

ptg7987094

[ 27 ]



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 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 firewalls and NAT devices because IPsec(ESP) and IKEv1/IKEv2 might be re-stricted 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:

■ 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.

Note Telnet is not allowed in clear text on the out-side interface, but only through a VPN tunnel, so that traffic reaches the appliance encrypted.

ptg7987094

[ 28 ]



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 management-access . 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).

ptg7987094

[ 29 ]



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, firewall through Host Scan application

■ Telemetry for sending information about origin of malicious web content to Cisco IronPort WSA

■ Web Security for web proxy configuration, 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 filters

■ Dynamic access policy (DAP)-assigned ACLs

■ MPF policies

■ Redirection of traffic to security modules

ptg7987094

[ 30 ]



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 Traffic Filter

■ SSL VPN

ptg7987094

[ 31 ]



■ Cisco Intercompany Media Engine (IME)

■ Cisco ASA Unified 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.

ptg7987094

[ 32 ]



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.

ptg7987094

[ 33 ]



Licenses can be installed using the global command activation-key and can be viewed in the system with command show activation-key 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 perpetual Maximum VLANs : 150 perpetual Inside Hosts : Unlimited perpetual Failover : Active/Active perpetual VPN-DES : Enabled perpetual VPN-3DES-AES : Enabled perpetual Security Contexts : 2 perpetual GTP/GPRS : Disabled perpetual AnyConnect Premium Peers : 2 perpetual AnyConnect Essentials : Disabled perpetual Other VPN Peers : 750 perpetual Total VPN Peers : 750 perpetual Shared License : Disabled perpetual AnyConnect for Mobile : Disabled perpetual AnyConnect for Cisco VPN Phone : Disabled perpetual Advanced Endpoint Assessment : Disabled perpetual UC Phone Proxy Sessions : 2 perpetual Total UC Proxy Sessions : 2 perpetual Botnet Traffic Filter : Disabled perpetual Intercompany Media Engine : Disabled perpetual

This platform has an ASA 5520 VPN Plus license.

Follow these steps to configure the shared licensing server:

STEP 1. Globally configure the shared secret used between participants and the server with the command license-server secret secret .

STEP 2. Globally configure the backup licensing server parameters with the command license-server backup address backup-id serial_number [ ha-backup-id ha_serial_number ].

ptg7987094

[ 34 ]



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 configure the shared licensing server and optionally modify the default TCP port 50554 used for commu-nication 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 configure the shared licensing server parameters with the command license-server address address secret secret [ port port ].

STEP 2. Globally configure the backup licensing server parameters with the command license-server backup address ad-dress .

To configure any shared license role by using ASDM, navigate to Configuration > Device Management > Licensing > Shared SSL VPN Licenses .

Implementing Profiles, 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 profiles , also known as tunnel groups from the CLI, which define the prelogin requirements of a VPN session. A connection profile 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.

2. Group policies , which define the postlogin security policies applied, such as traffic filtering (authorization) or time restric-tions.

ptg7987094

[ 35 ]



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. DAP rules 2. User profiles (local or remotely pushed from the AAA server) 3. Group policy attached to user profile 4. Group policy attached to connection profile 5. DfltGrpPolicy 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 Profiles 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 configurable and can be viewed with the following command: ciscoasa# show running-config 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-config all tunnel-group DefaultWEBVPNGroup

Note If a VPN session is as-signed to an administra-tor configured connection profile and the configura-tion is correct, the ses-sion will succeed. It is not the case for the de-fault connection profiles of DefaultRAGroup and DefaultWEBVPNGroup, where if the session is mapped the connection will most probably not be successful because of the preconfigured rules for these profiles.

ptg7987094

[ 36 ]



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 profile from a drop-down menu in the browser or menu in AnyConnect Client, given that multiple configured profiles exist on the ASA.

■ In a clientless SSL VPN, users can be forced to a specific connection profile by accessing a specific URL at login time.

■ In a full-tunneling SSL VPN, users can be forced to a specific connection profile by Extensible Markup Language (XML) profiles, as discussed later.

■ If a user does not choose a connection profile, 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 certificate, users can be automatically mapped to a connection profile.

■ As in password authentication only, clients can select the connection profile or can be forced to one.

■ If no identity certificate mapping rules are configured, 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:

■ Configured 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.

ptg7987094

[ 37 ]



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 specified as a group name in the Cisco IPsec VPN client.

■ Based on information from the certificate, users can be automatically mapped to a configured connection profile.

■ If no identity certificate mapping rules are configured, ASA examines the organizational unit (OU) from the certificate and uses its value as the connection profile.

■ If no connection profile has been identified 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 Configuration > Remote Access VPN and

■ For a full-tunneling SSL VPN, navigate to Network (Client) Access > AnyConnect Connection Profiles .

■ For a clientless SSL VPN, navigate to Clientless SSL VPN Access > Connection Profiles .

■ For an IPsec remote-access VPN, navigate to Network (Client) Access > IPsec(IKEv1) Connection Profiles .

STEP 2. Click Add to create a new connection profile.

STEP 3. Assign a name to the connection profile.

STEP 4. Configure the connection profile 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 configuration section.

■ Apply button used to save the modifications from ASDM into running-configuration of ASA.

■ Save button used after Apply to save changes into the startup configuration of ASA.

ptg7987094

[ 38 ]



Figure 1-3 General ASDM Rules

ptg7987094

[ 39 ]



To create connection profiles using the CLI, follow these steps:

STEP 1. Create a connection profile ( tunnel-group ) called TEST-CP , for example, of remote-access type.

STEP 2. Enter configuration mode for general profile attributes like AAA, DHCP server: ciscoasa(config)# tunnel-group TEST-CP type remote-accessciscoasa(config)# tunnel-group TEST-CP general-attributes

The following are optional configuration steps:

1. Enter configuration mode for SSL VPN- or IPsec VPN-specific attributes; configure group-alias for a clientless SSL VPN and a pre-shared key for a remote-access IKEv1 IPsec VPN.

2. Create a certificate map called TEST-MAP , for example, and match on OU of identity certificate and CN of CA. 3. For certificate-based authentication, bind users to specific profiles. 4. Allow users to select the connection profile from the browser drop-down menu. 5. Lock a user TEST-USER to a specific connection profile:

ciscoasa(config)# tunnel-group TEST-CP webvpn-attributesciscoasa(config-tunnel-webvpn)# group-alias "Financial Department" enableciscoasa(config)# tunnel-group TEST-CP ipsec-attributesciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key *datanetsystemskey*ciscoasa(config)# crypto ca certificate map TEST-MAP 10ciscoasa(config-ca-cert-map)# subject-name attr ou eq FINANCIALciscoasa(config-ca-cert-map)# issuer-name attr cn eq TEST-CAciscoasa(config)# webvpn ciscoasa(config-webvpn)# certificate-group-map TEST-MAP 10 TEST-CPciscoasa(config-webvpn)# tunnel-group-list enable ciscoasa(config)# username TEST-USER password test-passwordciscoasa(config)# username TEST-USER attributesciscoasa(config-username)# group-lock value TEST-CP

ptg7987094

[ 40 ]



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-config all group-policy DfltGrpPolicy

To create group policies using the ASDM, follow these steps:

STEP 1. Navigate to Configuration > 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. Configure 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. Configure policy settings, such as DNS server: ciscoasa(config)# group-policy TEST-POLICY internalciscoasa(config)# group-policy TEST-POLICY attributesciscoasa(config-group-policy)# dns-server value 1.1.1.1

ptg7987094

[ 41 ]



The following are optional configuration steps:

1. Assign the group policy to a specific connection profile so that it does not inherit all the DfltGrpPolicy settings. 2. Assign the group policy to a specific user profile so that it does not inherit the group policy settings from the connection

profile: ciscoasa(config)# tunnel-group TEST-CP general-attributesciscoasa(config-tunnel-general)# default-group-policy TEST-POLICYciscoasa(config)# username TEST-USER attributesciscoasa(config-username)# vpn-group-policy TEST-POLICY

User Profiles 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)

ptg7987094

[ 42 ]



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. When interesting traffic (matched in the crypto ACL) is detected in the buffer of the interface where the crypto map is ap-plied, the process is triggered.

2. Internet Key Exchange (IKEv1) Phase 1 negotiation for the management tunnel starts, and one IKEv1 security association (SA) is created.

3. IKEv1 Phase 2 negotiation for the data-plane tunnel starts, and at least two IPsec SAs are created. 4. Data starts to flow through the tunnel using security parameters from IPsec SAs. 5. 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.

ptg7987094

[ 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-to-site VPN deployment consists of three steps:

STEP 1. Configure basic peer authentication: IKEv1 Phase 1 or IKEv2 parent SA.

STEP 2. Configure transmission protection: IKEv1 Phase 2 or IKEv2 child SA.

STEP 3. Verify communication over the encrypted tunnel.

IKEv2 IPv4 VPN Tunnel

IPv4/IPv6 Transport Network

HQ VPN Gateway

IKEv1

IPv4 VPN Tunnel

IKEv

2

IPv6

VPN Tunnel

Figure 2-1 Site-to-Site VPN

ptg7987094

[ 44 ]



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

■ IKEv1 and IKEv2 configurations 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 filtering in group policies, and peer ID verification.

■ 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 tunnel-group mappings.

■ IKEv2 supports an optional pre-shared key configuration in the crypto map, necessary when asymmetric authentication is used, to map the VPN session to a specific connection profile.

■ IKEv2 for site-to-site VPNs does not support multiple peers or IPsec transport mode (left only for L2TP).

Configuring 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 inter-face closest to the remote gateway. To enable IKEv2/IKEv2 on the interface using the Adaptive Security Device Manager (ASDM), navigate to Configuration > Site-to-Site VPN > Connection Profiles , and under Access Interfaces select the interface and protocol (see Figure 2-2 ). Optionally, you can modify the IKE identity of the ini-tiator from Configuration > Site-to-Site VPN > Advanced > IKE Parameters , and you have the following options:

ptg7987094

[ 45 ]



■ Automatic (IP address for pre-shared key authentication and certificate distinguished name [DN] for identity certificate authentication)

■ Address (IP address of the interface)

■ Hostname (fully qualified domain name [FQDN])

■ Key ID (string used by remote peer to look for pre-shared key)

Figure 2-2 Enable IKEv1/IKEv2

ptg7987094

[ 46 ]



To enable IKEv1/IKEv2 on the interface and select IKE identity using the command-line interface (CLI), use the following commands: ciscoasa(config)# c r ypto ikev1 enable outsideciscoasa(config)# c r ypto ikev2 enable outsideciscoasa(config)# crypto isakmp identity auto

STEP 2. Configure the IKE policy.

If multiple policies are configured, the VPN session initiator presents it all to the remote device in the order of their pri-ority values from low to high, which picks up the first one with a perfect match on its own policies. To create IKE poli-cies using the ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > IKE Policies and click the Add button. The following options are configurable 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)

The following options are configurable for IKEv2 (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)

■ Integrity Hash algorithm (message digest authentication 5 [MD5] or Secure Hash [SHA-160], SHA256, SHA384, SHA512)

ptg7987094

[ 47 ]



■ 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 stron-gest 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

ptg7987094

[ 48 ]



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 significant, and lifetime, which does not need to match. (On IKEv1, the life-time value is negotiated to the lowest configured value; in IKEv2, each peer can use its own local lifetime.) To create IKEv1/IKEv2 policies using the CLI, use the following commands: ciscoasa(config)# crypto ikev1 policy 10ciscoasa(config-isakmp-policy)# authentication pre-shareciscoasa(config-isakmp-policy)# encryption aes-256ciscoasa(config-isakmp-policy)# hash shaciscoasa(config-isakmp-policy)# group 2ciscoasa(config-isakmp-policy)# lifetime 7200

ciscoasa(config)# crypto ikev2 policy 10ciscoasa(config-isakmp-policy)# prf sha512 sha md5ciscoasa(config-isakmp-policy)# encryption aes-256 aes-192 3desciscoasa(config-isakmp-policy)# integrity sha512 sha md5ciscoasa(config-isakmp-policy)# group 5 2ciscoasa(config-isakmp-policy)# lifetime 7200

STEP 3. Configure the connection profile and pre-shared key. For site-to-site VPNs with pre-shared key authentication, the connection profile 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 ).

ptg7987094

[ 49 ]



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(config)# tunnel-group 5.5.5.5 type ipsec-l2lciscoasa(config)# tunnel-group 5.5.5.5 ipsec-attributesciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key *ciscotestkey*ciscoasa(config-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2

ptg7987094

[ 50 ]



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(config)# tunnel-group 5.5.5.5 type ipsec-l2l ciscoasa(config)# tunnel-group 5.5.5.5 ipsec-attributesciscoasa(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key *ciscotestkey*ciscoasa(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key *ciscotestkey*

Configuring 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. Configure an IPv4/IPv6 access control list (ACL) that defines traffic to be protected by the VPN tunnel. One re-striction for successful negotiation is that the crypto ACLs need to be configured as mirror images of each other on the two VPN gateways and describe exactly the same traffic and have the exact same number of ACE entries.

To create an ACL using the ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > ACL Manager and click the Add > Add ACL button followed by Add ACE (see Figure 2-5 ).

ptg7987094

[ 51 ]



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(config)# access-list IPSEC-ENCRYPT permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0

ptg7987094

[ 52 ]



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

■ ACL defined in Step 1.

■ Crypto peer IPv4/IPv6 address, which is a remote VPN gateway.

■ IKEv1 transform set / IKEv2 IPsec proposals, to define the protocol and algorithms used to protect data traffic.

■ Optionally, enable Perfect Forward Secrecy (PFS) so that a new Diffie-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(config)# crypto ipsec ikev1 transform-set ESP-SHA-AES esp-aes-256 esp-sha-hmacciscoasa(config)# crypto ipsec ikev2 ipsec-proposalESP-SHA-AESciscoasa(config-ipsec-proposal)# protocol esp encryption aes-256 aes-192 3desciscoasa(config-ipsec-proposal)# protocol esp integrity sha-1 md5

ptg7987094

[ 53 ]



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 ).

ptg7987094

[ 54 ]



Figure 2-7 Static Crypto Map

To configure the crypto map and transform set using the CLI, use the following commands:

ciscoasa(config)# crypto map TEST-MAP 1 set peer 5.5.5.5 ciscoasa(config)# crypto map TEST-MAP 1 set pfs group2 ciscoasa(config)# crypto map TEST-MAP 1 set ikev1 transform-set ESP-SHA-AESciscoasa(config)# crypto map TEST-MAP 1 set ikev2 ipsec-proposal ESP-SHA-AESciscoasa(config)# crypto map TEST-MAP 1 set ikev2 pre-shared-key 0 *datanetsystems*ciscoasa(config)# crypto map TEST-MAP 1 match address IPSEC-ENCRYPTciscoasa(config)# crypto map TEST-MAP interface outside

ptg7987094

[ 55 ]



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(config)# 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 Configuration > Site-to-Site VPN > Advanced and Tunnel Groups, Crypto Maps, IKE Policies, ACL Manager .

■ Go to Configuration > Site-to-Site VPN > Connection Profiles .

Troubleshooting Cisco ASA Adaptive Security Appliance Site-to-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 traffic does not flow 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, traffic identified 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 configuration on both ends. Use the debug crypto ikev1 or debug crypto ikev2 protocol commands to investigate the negotiation issues.

ptg7987094

[ 56 ]



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 Role : initiator Rekey : no State : MM_ACTIVE Encrypt : aes Hash : SHA Auth : preshared Lifetime: 86400 Lifetime Remaining: 29763

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 configuration 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.5peer 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

ptg7987094

[ 57 ]



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 traffic.

STEP 2. Is Network Address Translation (NAT) enabled on the VPN gateways? If yes, verify that the VPN traffic 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 traffic, verify that the crypto ACL matches on the translated traffic.

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 traffic is UDP encapsulated.

STEP 4. Verify that the connection is established with show conn .

ptg7987094

[ 58 ]



Deploying Certificate 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(config)# hostname ciscoasa ciscoasa(config)# domain-name cisco.com ciscoasa(config)# crypto key generate rsa general-keys modulus 2048

STEP 2. Authenticate the certificate authority (CA). (That is, install the CA certificate.)

To authenticate the CA using the ASDM, navigate to Configuration > Site-to-Site VPN > Certificate Management > CA Certificates and click Add (see Figure 2-8 ). Options are via Simple Certificate Enrollment Protocol (SCEP) or im-porting it from a base64/PEM (privacy enhanced mail) format.

ptg7987094

[ 59 ]



Figure 2-8 CA Authentication

To authenticate CA via SCEP using the CLI, use the following code: ciscoasa(config)# crypto ca trustpoint TEST-CA ciscoasa(config-ca-trustpoint)# enrollment url http://1.1.1.1/certsrv/mscep/mscep.dll ciscoasa(config)# crypto ca authenticate TEST-CA

ptg7987094

[ 60 ]



STEP 3. Enroll with the CA. (That is, install the identity certificate for the ASA.)

To enroll with the CA, a certificate request must be sent and then the identity certificate installed. To perform a certifi -cate request using the ASDM, navigate to Configuration > Site-to-Site VPN > Certificate Management > Identity Certificates 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 certificate request is completed, the certificate can be auto-matically issued by the CA and installed by ASA), manual enrollment needs both the certificate request and install to be completed by the administrator.

Figure 2-9 Certificate Request

ptg7987094

[ 61 ]



To install the digital certificate using the ASDM, navigate to Configuration > Site-to-Site VPN > Certificate Management > Identity Certificates and click the Install button (see Figure 2-10 ).

Figure 2-10 Install Identity Certificate

ptg7987094

[ 62 ]



To enroll with the CA manually using the CLI, use the following commands: ciscoasa(config)# crypto ca trustpoint TEST-CAciscoasa(config-ca-trustpoint)# enrollment terminalciscoasa(config-ca-trustpoint)# subject-name CN=TEST-ASAciscoasa(config)# crypto ca enroll TEST-CA noconfirmciscoasa(config)# crypto ca import TEST-CA certificate nointeractive

STEP 4. Configure IKEv1 Phase 1 for certificate authentication. IKEv2 policies do not specify authentication.

STEP 5. Configure the connection profile (tunnel group) for certificate authentication.

STEP 6. Configure transmission protection: IKEv1 Phase 2 or IKEv2 child SA.

STEP 7. Optionally, define certificate-to-connection profile maps.

STEP 8. Verify certificates 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 profile

■ Interface on which the tunnel is terminated

■ Protected networks where crypto ACL is configured; 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 certificate can be used.

■ IKEv1 encryption algorithms, where Phase 1 and Phase 2 algorithms are configured.

ptg7987094

[ 63 ]



■ IKEv2 authentication settings, where either a pre-shared key or device certificate can be used for the local device. For the remote device, both methods can be specified.

■ IKEv2 encryption algorithms, where IKE policies and IPsec proposals are configured.

Figure 2-11 Connection Profile

ptg7987094

[ 64 ]



Figure 2-12 Connection Profile (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 significant 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 configurations, 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 defined as a time period or traffic 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.

■ Configure the crypto map pre-shared key, only for IKEv2 sessions.

■ Select a CA certificate so that ASA can validate CA signatures from remote VPN gateways’ received identity certificates.

■ Specify IKEv1 Phase 1 mode, main or aggressive. If aggressive is used, the D-H group can also be selected.

ptg7987094

[ 65 ]



Figure 2-13 Connection Profile Crypto Map Entry

Under Advanced > Tunnel Group (see Figure 2-14 ), you can specify the following:

■ Enable sending of certificate chain to the remote VPN gateway

■ IKE peer ID validation

■ IKE DPD/keepalive settings

ptg7987094

[ 66 ]



Figure 2-14 Connection Profile Tunnel Group

To perform site-to-site IKEv1 and IKEv2 IPv4 VPN configuration using the CLI, use the following commands:

ciscoasa(config) # access-list IPSEC-ENCRYPT extended permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0 ciscoasa(config)# tunnel-group 5.5.5.5 type ipsec-l2lciscoasa(config)# tunnel-group 5.5.5.5 ipsec-attributesciscoasa(config-tunnel-ipsec)# ikev1 trust-point TEST-CA

ptg7987094

[ 67 ]



ciscoasa(config-tunnel-ipsec)# ikev2 local-authentication certificate TEST-CA ciscoasa(config-tunnel-ipsec)# ikev2 remote-authentication certificateciscoasa(config-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2ciscoasa(config)# crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmacciscoasa(config)# crypto ipsec ikev2 ipsec-proposalESP-SHA-AESciscoasa(config-ipsec-proposal)# protocol esp encryption aes-256 aes-192 3desciscoasa(config-ipsec-proposal)# protocol esp integrity sha-1 md5 ciscoasa(config)# crypto map TEST-MAP 10 set trustpoint TEST-CA ciscoasa(config)# crypto map TEST-MAP 10 match address IPSEC-ENCRYPTciscoasa(config)# crypto map TEST-MAP 10 set pfs group2 ciscoasa(config)# crypto map TEST-MAP 10 set peer 5.5.5.5 ciscoasa(config)# crypto map TEST-MAP 10 set ikev1 transform-set ESP-3DES-SHAciscoasa(config)# crypto map TEST-MAP 10 set ikev2 ipsec-proposal ESP-SHA-AES ciscoasa(config)# crypto map TEST-MAP interface outside ciscoasa(config)# crypto ikev1 policy 1 ciscoasa(config-isakmp-policy)# encryption 3des ciscoasa(config-isakmp-policy)# hash sha ciscoasa(config-isakmp-policy)# group 2 ciscoasa(config-isakmp-policy)# authentication rsa-sigciscoasa(config-isakmp-policy)# lifetime 86400 ciscoasa(config)# crypto ikev2 policy 1 ciscoasa(config-isakmp-policy)# prf sha512 sha md5ciscoasa(config-isakmp-policy)# encryption aes-256 aes-192 3desciscoasa(config-isakmp-policy)# integrity sha512 sha md5ciscoasa(config-isakmp-policy)# group 5 2 ciscoasa(config-isakmp-policy)# lifetime 7200 ciscoasa(config)# crypto ikev1 enable outside ciscoasa(config)# 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. Certificate map to connection profile mapping. This option is disabled by default and allows to match on certain attributes from identity certificates and to map VPN sessions to connection profiles based on it.

2. OU from the received identity certificate of the VPN peer. 3. IKE identity presented. 4. Peer IP address.

ptg7987094

[ 68 ]



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 Configuration > Site-to-Site VPN > Advanced > Certificate to Connection Profile Maps > Policy and check the Use the Configured Rules to Match a Certificate to Connection Profile check box.

STEP 2. Configure a certificate map and bind it to desired connection profile. Using ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > Certificate to Connection Profile Maps > Rules and click Add under Certificate to Connection Profile Maps (see Figure 2-15 ).

Figure 2-15 Certificate to Connection Profile Maps

ptg7987094

[ 69 ]



STEP 3. Configure mapping criteria, by matching on one or multiple certificate attributes. If these conditions are satisfied, the VPN session is mapped to the connection profile specified in the previous step. Using ASDM, navigate to Configuration > Site-to-Site VPN > Advanced > Certificate to Connection Profile Maps > Rules and click Add un-der Mapping Criteria (see Figure 2-16 ).

Figure 2-16 Certificate to Connection Profile Mapping Criteria

To enable and configure certificate to connection profile mapping using the CLI, use the following commands:

ciscoasa(config)# tunnel-group-map enable rulesciscoasa(config)# crypto ca certificate map TEST-MAP 10ciscoasa(config-ca-cert-map)# subject-name attr cn eq ciscociscoasa(config)# tunnel-group-map TEST-MAP 10 5.5.5.5

ptg7987094

[ 70 ]



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).

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 profile configuration, certificate enrollment, and session initiation.

■ Uninstall VPN Client , which enables you to safely remove the software from the system, retaining connection profiles and certificate configurations.

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

Note It seems that in the lat-est versions Help and Uninstall VPN Client are no longer available in the Programs menu. Help is available as a menu op-tion in the GUI, though.

ptg7987094

[ 71 ]



■ 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

IPsec Attribute Description

IKE Phase 1 main and aggressive modes Negotiation for IKE Phase 1

Authentication algorithms HMAC with MD5 HMAC with SHA-1

Authentication modes Pre-shared keys Mutual group authentication X.509 identity certificates

D-H groups Group1 – 768 bit Group2 – 1024 bit Group5 – 1536 bit

XAUTH (Extended Authentication) Capability of user authentication

Mode configuration ISAKMP configuration method

Tunnel encapsulation modes IPsec over UDP IPsec over TCP IPsec over UDP NAT-T

IP compression using LZS Data-compression algorithm

Note VPN Client sup-ports D-H group 5 only if “Certificate Authentication” or “Mutual Group Authentication” is being used along with digital certificates.

ptg7987094

[ 72 ]



Installing and Configuring 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 profile 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. Configure the basic connection properties:

■ Enter the connection name in the Connection Entry field.

■ Optionally, enter a description in the Description field.

■ Enter the hostname or IP address of the VPN gateway in the Host field.

■ On the Authentication tab, choose the authentication method. For certificate authentication, select the identity certificate; for group authentication, complete the name and password, which are actually the connection profile name and IKEv1 pre-shared key configured on the ASA.

Figure 2-16 IPsec VPN Client Connection Entry Configuration

ptg7987094

[ 73 ]



STEP 3. Optionally, configure 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.

■ Configuring the peer response timeout, which is actually the DPD timer.

STEP 4. Optionally, configure 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, configure 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

Configuring Advanced Profile 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 certificate verification 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.

ptg7987094

[ 74 ]



■ 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 specific connection entry upon startup

■ Automatic disconnect settings upon user logoff

■ Certificate 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

ptg7987094

[ 75 ]



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. Configure basic ASA Easy VPN Server features. STEP 2. Configure group authentication. STEP 3. Optionally configure extended user authentication (XAUTH). STEP 4. Configure client network configuration. STEP 5. Configure basic access control. STEP 6. Configure the Easy VPN software client, Cisco IPsec VPN Client. STEP 7. Troubleshoot Easy VPN operation.

Configuring 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 Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles and select interfaces for IPsec processing. Doing so will also automatically

■ Enable IKEv1 on selected interfaces.

■ Configure 15 IKEv1 policies

■ Configure 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 interfaces If configuration is done via the CLI, you need to manually create IKEv1 policies, transform sets, and dynamic crypto maps: ciscoasa(config)# crypto ikev1 enable outside ciscoasa(config)# crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

ptg7987094

[ 76 ]



ciscoasa(config)# crypto ikev1 policy 1 ciscoasa(config-isakmp-policy)# authentication pre-shareciscoasa(config-isakmp-policy)# encryption 3des ciscoasa(config-isakmp-policy)# hash sha ciscoasa(config-isakmp-policy)# group 2 ciscoasa(config-isakmp-policy)# lifetime 86400 ciscoasa(config)# crypto dynamic-map DYNAMIC-TEST-MAP 65535 set transform-set ESP-3DES-SHAciscoasa(config)# crypto map TEST-MAP 65535 ipsec-isakmp dynamic DYNAMIC-TEST-MAPciscoasa(config)# 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 Configuration > 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 certificate authentication with XAUTH

■ 12 IKEv1 policies for mutual group authentication

■ 13 IKEv1 policies for certificate 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 Configuration > 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 traffic volume and enable NAT-T and RRI.

ptg7987094

[ 77 ]



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.

Configuring 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. Configure a group policy. This is not mandatory for this step, but needed later. To create the group policy using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies and click Add (see Figure 2-17 ).

ptg7987094

[ 78 ]



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 configured.) ciscoasa(config)# group-policy TEST-GROUP internalciscoasa(config)# group-policy TEST-GROUP attributesciscoasa(config-group-policy)# vpn-tunnel-protocol ikev1ciscoasa(config-group-policy)# address-pools value TEST-POOL

STEP 2. Configure a connection profile with pre-shared key authentication and assign the previously created group pol-icy to it. To create the connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles and click Add (see Figure 2-18 ).

ptg7987094

[ 79 ]



Figure 2-18 Add Connection Profile

To create the connection profile using the CLI, use the following commands: ciscoasa(config)# tunnel-group TEST-PROFILE type remote-accessciscoasa(config)# tunnel-group TEST-PROFILE general-attributesciscoasa(config-tunnel-general)# default-group-policy TEST-GROUPciscoasa(config-tunnel-general)# address-pool TEST-POOLciscoasa(config)# tunnel-group TEST-PROFILE ipsec-attributesciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key 8chn4326cewfgeq

ptg7987094

[ 80 ]



Configuring 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 profile. To verify using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles , choose the profile, and click Edit . Navigate to Advanced > IPsec > IKE Authentication Mode . To enable it using the CLI, use the following commands: ciscoasa(config)# tunnel-group TEST-PROFILE ipsec-attributesciscoasa(config-tunnel-ipsec)# isakmp ikev1-user-authentication xauth

STEP 2. If using local user authentication, configure 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 Configuration > Remote Access VPN > AAA/Local Users > Local Users and click Add (see Figure 2-19 ).

ptg7987094

[ 81 ]



Figure 2-19 User Profile

To create the user using the CLI, use the following commands: ciscoasa(config)# username TEST-USER password TEST-PASSciscoasa(config)# username TEST-USER attributesciscoasa(config-username)# service-type remote-access

ptg7987094

[ 82 ]



Configuring Client Network Configuration 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. Configure DNS, WINS servers, and domain name. To configure these using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies , edit the previously configured group policy or the default DfltGrpPolicy, and go to the Servers tab (see Figure 2-20 ).

Figure 2-20 Group Policy Settings

ptg7987094

[ 83 ]



To configure these using the CLI, use the following commands: ciscoasa(config)# group-policy TEST-POLICY attributesciscoasa(config-group-policy)# dns-server value 10.10.10.10ciscoasa(config-group-policy)# wins-server value 10.10.10.10ciscoasa(config-group-policy)# default-domain value cisco.com

STEP 2. Configure 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 pro-cessing is as follows: ■ Authentication server assigned (local or remote AAA)

■ External DHCP server

■ Internal address pools (specified in connection profile or group policy)

To modify or view these settings using the ASDM, navigate to Configuration > 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-config all vpn-addr-assignvpn-addr-assign aaa vpn-addr-assign dhcp vpn-addr-assign local reuse-delay 0

STEP 3. Optionally, configure an IPv4 address pool and assign it to the group policy.

To configure an IPv4 address pool using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Address Assignment > Address Pools and click Add . To assign it to the connection profile, modify the Address Pools field value from the group policy on the General tab. To configure it using the CLI, use the following command: ciscoasa(config)# ip local pool TEST-POOL 10.11.11.1-10.11.11.100 mask 255.255.255.255

ptg7987094

[ 84 ]



STEP 4. Optionally, assign static IP addresses to users. To statically configure an IP address to users using the ASDM, navi-gate to Configuration > Remote Access VPN > AAA/Local Users > Local Users , select the user, click Edit , and en-ter the IP address in the Dedicated IP Address section under the VPN Policy tab. To configure it using the CLI, use the following commands: ciscoasa(config)# username TEST-USER attributesciscoasa(config-username)# vpn-framed-ip-address 10.11.11.5 255.255.255.255

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

■ Configure interface bypass. This disables the checking of incoming decrypted VPN traffic against inbound ACLs and is the default setting. You can view is using the ASDM by navigating to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles .

■ To view it using the CLI, use the command show running-config 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(config)# no sysopt connection permit-vpn

■ Configure interface ACLs. If ACL bypass is disabled, decrypted traffic needs to be specifically 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 traffic is allowed.

To configure it using the CLI, use the following commands: ciscoasa(config)# access-group OUTSIDE_IN in interface outside per-user-override

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

ptg7987094

[ 85 ]



To configure it using the CLI, use the following commands: ciscoasa(config)# group-policy TEST-POLICY attributesciscoasa(config-group-policy)# vpn-filter value FILTER-ACL

■ Configure per-user ACLs. This option has the advantage that the filtering is applied only to the respective user. To configure this using the ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users > Local Users , select the user, click Edit, and on the VPN Policy tab, modify the IPv4Filter section.

To configure it using the CLI, use the following commands: ciscoasa(config)# username TEST-USER attributesciscoasa(config-username)# vpn-filter value FILTER-ACL

■ Configure split tunneling. Split tunneling allows for specifically defined traffic to flow 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 traffic is tunneled) and traffic to be tunneled specified in an ACL (with only standard ACLs being supported). To configure a standard ACL using the ASDM, navigate to Configuration > Firewall > Advanced > Standard ACL and click Add . To modify group policy settings, navigate to Configuration > 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 ).

ptg7987094

[ 86 ]



Figure 2-21 Split Tunneling

To configure it via the CLI, use the following commands: ciscoasa(config)# group-policy TEST-POLICY attributesciscoasa(config-group-policy)# split-tunnel-policy tunnelspecifiedciscoasa(config-group-policy)# split-tunnel-network-list value SPLIT-ACL

ptg7987094

[ 87 ]



Configuring 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. Configure 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 configure the group name (connection profile from the Easy VPN server) and password (pre-shared key from the Easy VPN server).

■ Configure, 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 configured 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.

ptg7987094

[ 88 ]



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 profile and group policy configuration.

■ Verify correct IPv4 addressing assignment policy.

ptg7987094

[ 89 ]



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 configured 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 traffic is not subject to NAT policies; or if NAT control is enabled, configure 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 certificate authentication

■ Mutual group authentication or hybrid authentication

Deploying Cisco VPN Client Identity Certificate 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).

ptg7987094

[ 90 ]



STEP 3. Create or modify the existing IPsec VPN Client connection entry to use certificate authentication.

STEP 4. Create or modify the existing connection profile on ASA to use certificate authentication (just as in site-to-site VPN).

Cisco IPsec VPN Client supports two methods for CA enrollment:

■ Online through SCEP

■ Offline through a file-based certificate request

To enroll online, follow these steps:

STEP 1. Open the client, navigate to the Certificates 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 configure the certificate 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 certificate might be automatically approved or may need manual approval.

STEP 4. Once the identity certificate is issued, navigate to the Connection Entries tab and modify the existing entry or add a new entry to use certificate authentication.

Figure 2-23 IPsec VPN Client CA Enrollment

ptg7987094

[ 91 ]



Figure 2-24 IPsec VPN Client CA Enrollment

Configuring 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.

ptg7987094

[ 92 ]



STEP 2. Enable hybrid authentication in the connection profile on the ASA.

To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles and edit the selected profile. Navigate further to Advanced > IPsec > IKE Authentication Mode and choose Hybrid XAUTH . To configure it via the CLI, use the following commands: ciscoasa(config)# tunnel-group TEST-GROUP ipsec-attributesciscoasa(config-tunnel-ipsec)# isakmp ikev1-user-authentication hybrid

STEP 3. Configure the VPN client connection entry. VPN client configuration 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 certificate in the VPN Client Certificate Store.

■ Configure the group name and password (just like in pre-shared key authentication).

■ Configure, optionally, other settings such as NAT-T, backup server, and dial-up profiles.

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:

■ Certificate revocation lists (CRL)

■ Online Certificate Status Protocol (OCSP)

■ AAA user authorization via RADIUS based on identity certificate

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 Certificates for Revocation radio button is checked and select one or both methods: CRL/OCSP.

ptg7987094

[ 93 ]



■ On the CRL Retrieval Policy tab, you can use a static URL or distribution point from the certificate.

■ For the CRL Retrieval Method, select one or more options (LDAP, HTTP, SCEP).

■ In the OCSP Rules tab, configure 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(config)# crypto ca trustpoint TEST-CAciscoasa(config-ca-trustpoint)# revocation-check crl noneciscoasa(config-ca-trustpoint)# crl configureciscoasa(config-ca-crl)# no protocol ldapciscoasa(config-ca-crl)# no protocol scepciscoasa(config-ca-crl)# protocol http

To configure AAA certificate authorization using the ASDM, follow these steps:

STEP 1. Configure the RADIUS server. Using ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups , add or edit an existing RADIUS server, and complete the Common Password field with the password that will be sent to the RADIUS server along with the username extracted from the certificate.

STEP 2. Configure certificate authorization in the connection profile.

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 Connect option (see Figure 2-25 ), and specify one certificate attribute to be used as username. (CN is used most often.)

ptg7987094

[ 94 ]



Figure 2-25 AAA Certificate Authorization

To configure AAA certificate authorization via the CLI, use the following commands:

ciscoasa(config)# aaa-server TEST-RADIUS protocol radiusciscoasa(config)# aaa-server TEST-RADIUS (inside) host 10.10.10.10

ptg7987094

[ 95 ]



ciscoasa(config-aaa-server-host)# radius-common-pw cisco ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-tunnel-general)# authorization-requiredciscoasa(config-tunnel-general)# username-from-certificate CNciscoasa(config-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 profile is not correctly configured 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 configured. In this case, the ASA rejects the connection.

■ The certificate 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

ptg7987094

[ 96 ]



■ 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 traffic 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 Profile The configuration steps for the hardware client are as follows:

STEP 1. Enable Cisco Easy VPN Remote.

STEP 2. Configure the functional mode.

STEP 3. Configure authentication.

STEP 4. Configure 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.

ptg7987094

[ 97 ]



■ Choose between pre-shared key and X.509 certificate; the second option requires a previous enrollment with a CA.

■ Configure 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(config)# vpnclient enableciscoasa(config)# vpnclient mode client-modeciscoasa(config)# vpnclient trustpoint TEST-CAciscoasa(config)# vpnclient server 10.10.10.10

Configuring 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 configuration file. ■ 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.

ptg7987094

[ 98 ]



For automatic unit XAUTH, a username and password are also configured on the Easy VPN client in the User Settings section of easy VPN Remote pane. To configure it via the CLI, use the following commands: ciscoasa(config)# 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 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 the desired option.

To configure it using the CLI on the Easy VPN server, use the following commands: ciscoasa(config)# group-policy TEST-POLICY attributesciscoasa(config-group-policy)# secure-unit-authentication enableciscoasa(config-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 specifically allowed on VPN Remote with regular manage-

ment access commands for SSH, HTTPS

To configure 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 configure it on Easy VPN Remote via the CLI, use the following command: ciscoasa(config)# 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 configure it on Easy VPN Remote via the CLI, use the following command: ciscoasa(config)# vpnclient ipsec-over-tcp port 10000

ptg7987094

[ 99 ]



■ Device pass-through

When IUA is enabled, clients that cannot authenticate (for example, IP phones, printers, or access points) cannot pass traffic through the tunnel. These devices can bypass authentication based on their MAC addresses. To configure 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 configure it on Easy VPN Remote via the CLI, use the following command: ciscoasa(config)# vpnclient mac-exempt 0007.50d5.4d95 ffff.ffff.ffff

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 ).

ptg7987094

[ 100 ]



IKEv1 VPN Tunnel

Transport Network

Easy VPNHardware Client

Easy VPNSoftware Client

Eas

y V

PN

Sof

twar

e C

lient

HQ VPN Gateway

IKEv1

VPN TunnelIK

Ev1

VPN Tunnel

Figure 2-26 Easy VPN Software and Hardware

To configure it on Easy VPN Server via the CLI, use the following commands:

ciscoasa(config)# group-policy TEST-GROUP attributesciscoasa(config-group-policy)# leap-bypass enableciscoasa(config-group-policy)# ip-phone-bypass enable

ptg7987094

[ 101 ]



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

ptg7987094

[ 102 ]



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 configuration in remote-access sessions.

■ IKEv2 uses WebVPN attribute settings from tunnel group configuration in remote-access sessions.

■ Because AnyConnect by default connects using SSL, to use AnyConnect with IKEv2, IPsec needs to be configured as primary protocol in AnyConnect XML client profile.

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 certificate for it. Using ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles 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 certificate 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 ).

ptg7987094

[ 103 ]



Figure 2-28 Enable IKEv2 and Client Services

During the AnyConnect IKEv2 session initiation, settings like XML client profile download, automatic client ver-sion 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. Configure an IKEv2 group policy.

Using ASDM, configure a new group policy or edit an existing one to support IKEv2 protocol by navigating to Configuration > Remote Access VPN > Network (Client) Access > Group Policies (see Figure 2-29 ).

ptg7987094

[ 104 ]



Figure 2-29 IKEv2 Group Policy

STEP 4. Create an IPsec AnyConnect connection profile.

Using ASDM, configure a new connection profile or edit an existing one and specify the previously configured group policy by navigating to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles . Also specify an IPv4/IPv6 address pool or both (see Figure 2-30 ).

ptg7987094

[ 105 ]



Figure 2-30 IKEv2 Connection Profile

STEP 5. Configure an AnyConnect XML profile.

Using ASDM, configure a new XML profile to support IKEv2 IPsec as primary method by navigating to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile (see Figure 2-31 ).

ptg7987094

[ 106 ]



Figure 2-31 AnyConnect Client Profile

STEP 6. Establish an AnyConnect session to download the new client XML profile. Reconnect the AnyConnect session, this time using IKEv2 IPsec. Instead of downloading the IKEv2 IPsec-enabled XML AnyConnect client profile upon a new connection, the profile 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(config)# crypto ikev2 policy 100 ciscoasa(config-ikev2-policy)# encryption aes-256 aes-192 3des ciscoasa(config-ikev2-policy)# integrity sha512 sha md5 ciscoasa(config-ikev2-policy)# prf sha512 sha md5 ciscoasa(config-ikev2-policy)# group 14 5 2 ciscoasa(config-ikev2-policy)# group 14 5 2 ciscoasa(config-ikev2-policy)# lifetime seconds 28800 ciscoasa(config)# crypto ikev2 enable outside client-services port 443 ciscoasa(config)# crypto ikev2 remote-access trustpoint TEST-CA ciscoasa(config)# crypto ipsec ikev2 ipsec-proposal IKEv2-ANYCONNECT-PROPOSALciscoasa(config-ipsec-proposal)# protocol esp encryption aes-256 aes-192 3desciscoasa(config-ipsec-proposal)# protocol esp integrity sha-1 md5 ciscoasa(config)# crypto dynamic-map DYNAMIC-ANYCONNECT 65535 set ikev2 ipsec-proposal IKEv2-ANYCONNECT-PROPOSAL

ptg7987094

[ 107 ]



ciscoasa(config)# crypto map STATIC 65535 ipsec-isakmp dynamic DYNAMIC-ANYCONNECT ciscoasa(config)# crypto map STATIC interface outside ciscoasa(config)# group-policy IKEv2-ANYCONNECT-GROUP internal ciscoasa(config)# group-policy IKEv2-ANYCONNECT-GROUP attributesciscoasa(config-group-policy)# vpn-tunnel-protocol ikev2 ciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# anyconnect profiles value IKEv2-ANYCONNECT type userciscoasa(config-group-policy)# dns-server value 10.10.10.100 ciscoasa(config-group-policy)# wins-server value 10.10.10.100 ciscoasa(config-group-policy)# default-domain value cisco.com ciscoasa(config)# ip local pool IPv4 10.10.10.1-10.10.10.10 mask 255.255.255.0ciscoasa(config)# tunnel-group IKEv2-ANYCONNECT-TUNNEL type remote-access ciscoasa(config)# tunnel-group IKEv2-ANYCONNECT-TUNNEL general-attributesciscoasa(config-tunnel-general)# default-group-policy IKEv2-ANYCONNECT-GROUPciscoasa(config-tunnel-general)# address-pool IPv4 ciscoasa(config-tunnel-general)# tunnel-group IKEv2-ANYCONNECT-TUNNEL webvpn-attributesciscoasa(config-tunnel-webvpn)# group-alias IKEv2-ANYCONNECT-ALIAS enable ciscoasa(config)# webvpn ciscoasa(config-webvpn)# enable outside ciscoasa(config-webvpn)# tunnel-group-list enable ciscoasa(config-webvpn)# anyconnect enable ciscoasa(config-webvpn)# anyconnect profiles 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 configuration 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.

ptg7987094

[ 108 ]



■ 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 profile and group policy configuration.

■ 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 traffic is not subject to NAT policies; configure Identity NAT for client traffic if needed.

■ Check proper routing to AnyConnect Client addresses from behind the ASA.

ptg7987094

[ 109 ]



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 .

PDA Smartphone

Desktop

Laptop

SSL VPN Tunnel

HQ VPN GatewayTransportNetwork

SSL VPN Tunnel

SSL

VPN

Tun

nel

Figure 3-1 AnyConnect SSL VPN

ptg7987094

[ 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. Configure the basic ASA SSL VPN gateway features. 2. Configure local user authentication. 3. Configure IPv4/IPv6 address assignment. 4. Configure basic access control. 5. 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).

Configuring Basic Cisco ASA SSL VPN Gateway Features To initially prepare the ASA for SSL VPN termination, complete the following steps:

STEP 1. Provision the ASA with an identity certificate. Your options are as follows:

■ Use a self-signed certificate.

■ Enroll ASA in Public Key Infrastructure (PKI) with Simple Certificate Enrollment Protocol (SCEP).

■ Enroll ASA in PKI with manual cut-and-paste method enrollment.

To install a self-signed certificate using the ASDM, navigate to Configuration > Remote Access VPN > Certificate Management > Identity Certificate s and click Add . Give the PKI trustpoint a name, choose Add a New Identity Certificate , check Generate Self-Signed Certificate , and then click Add Certificate . To configure a self-signed certificate via the command-line interface (CLI), use the following commands:

Note Starting with version 2.5, AnyConnect is called AnyConnect Secure Mobility Client .

ptg7987094

[ 111 ]



ciscoasa(config)# crypto key generate rsa label SELF-SIGNED modulus 2048 ciscoasa(config)# crypto ca trustpoint TEST-CAciscoasa(config-ca-trustpoint)# id-usage ssl-ipsecciscoasa(config-ca-trustpoint)# subject-name CN=cisco.comciscoasa(config-ca-trustpoint)# enrollment selfciscoasa(config-ca-trustpoint)# keypair SELF-SIGNEDciscoasa(config)# crypto ca enroll TEST-CA noconfirm

To enroll with SCEP by using the ASDM, navigate to same section as for self-signed certificates. Give the PKI trustpoint a name, choose Add a New Identity Certificate (do not check Generate Self-Signed Certificate), and click the Advanced but-ton 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 certificate authority (CA) requires it.

■ For manual enrollment, navigate to Enrollment Mode and choose Request by Manual Enrollment . This requires an additional step: After the certificate is issued, it needs to be imported onto the ASA from a file. 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 base64-encoded certificate.

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

ptg7987094

[ 112 ]



STEP 2. Load the AnyConnect image onto the ASA.

There are different AnyConnect web deployment packages (PKG files) for different client operating systems. Choose the one you need, download it from Cisco.com, and load it into ASA flash 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 Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles 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(config)# webvpn ciscoasa(config-webvpn)# enable outside ciscoasa(config-webvpn)# anyconnect enable ciscoasa(config-webvpn)# anyconnect image disk0:/ anyconnect-win-3.0.1047-k9.pkg 1

STEP 4. Configure and optionally tune SSL Transport Layer Security (TLS) settings. Here, you can tune SSL VPN by al-lowing only certain SSL/TLS versions and algorithms and by specifying the identity certificate used (if many ex-ist). To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Advanced > SSL Settings (see Figure 3-2 ).

ptg7987094

[ 113 ]



Figure 3-2 SSL VPN Tuning

To configure it via the CLI, use the following commands: ciscoasa(config)# ssl trust-point TEST-CA outside ciscoasa(config)# webvpn ciscoasa(config-webvpn)# ssl server-version tlsv1 ciscoasa(config-webvpn)# ssl encryption aes128-sha1 aes256-sha1 3des-sha1 des-sha1

ptg7987094

[ 114 ]



Configuring 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. Configure 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 difficult to differentiate users later).

To create a group policy for AnyConnect connections using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies and click Add .

To create it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-ANYCONNECT-POLICY internalciscoasa(config)# group-policy BASIC-ANYCONNECT-POLICY attributesciscoasa (config-group-policy)# vpn-tunnel-protocol ssl-client

STEP 2. Configure a connection profile for AnyConnect connections and assign it the new group policy.

To create a connection profile for AnyConnect connections using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles and click Add . To create it via the CLI, use the following commands: ciscoasa(config)# tunnel-group BASIC-ANYCONNECT-PROFILE type remote-accessciscoasa(config)# tunnel-group BASIC-ANYCONNECT-PROFILE general-attributesciscoasa(config-tunnel-general)# default-group-policy BASIC-ANYCONNECT-POLICY

STEP 3. Optionally, define an alias for the connection profile.

This option allows users to select the desired connection profile when connecting to the SSL VPN. Navigate in the con-nection profile configuration 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(config)# tunnel-group BASIC-ANYCONNECT-PROFILE general-attributesciscoasa(config-tunnel-general)# group-alias "BASIC PROFILE" enable

ptg7987094

[ 115 ]



Figure 3-3 Connection Alias

ptg7987094

[ 116 ]



STEP 4. Configure the local user database.

To create a user account using the ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users > Local Users and click Add . To create it via the CLI, use the following commands: ciscoasa(config)# username BASIC-ANYCONNECT-USER password CISCOciscoasa(config)# username BASIC-ANYCONNECT-USER attributesciscoasa(config-username)# service-type remote-access

STEP 5. Optionally, configure the connection profile lock.

This option restricts users to a specific connection profile with no other profile being valid for them, even if it is se-lected. To configure restrictions using the ASDM, in the user-editing pane, navigate to VPN Policy and configure Connection Profile (Tunnel Group) Lock . To configure it via the CLI, use the following commands: ciscoasa(config)# username BASIC-ANYCONNECT-USER attributesciscoasa(config-username)# group-lock value BASIC-ANYCONNECT-PROFILE

Configuring 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 specific 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

Note You learn the manual installation method in this module.

ptg7987094

[ 117 ]



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

■ Define the IP address assignment methods.

■ Configure an IPv4/IPv6 address pool to use this method.

■ Assign the address pools to the group policy.

■ Assign per-user IP addresses if needed.

■ Configure interface access control list (ACL) bypass if needed.

■ Configure interface IPv4/IPv6 ACLs or global IPv4/IPv6 if bypass is disabled.

■ Configure per-profile or per-user IPv4/IPv6 ACLs.

■ Configure split tunneling.

Installing and Configuring 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 files 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)

ptg7987094

[ 118 ]



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 certificate authentication chain.

AnyConnect uses the certificate store. If an internal nonglobal CA is used, import the CA identity certificate on cli-ent devices so that the CA becomes trusted.

STEP 3. Configure basic AnyConnect profile settings.

Start the AnyConnect Client and specify the VPN gateway fully qualified domain name (FQDN), which should match the common name (CN) from the identity certificate of the ASA; otherwise, you will receive certificate 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 .

ptg7987094

[ 119 ]



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. Install DART (can be installed manually on remote devices or pushed from ASA as additional module). 2. Collect diagnostic information by starting DART. 3. Optionally examine gathered data. 4. 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 profile, group policies, and any configured 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(config)# logging enable ciscoasa(config)# logging timestamp ciscoasa(config)# logging buffered debuggingciscoasa(config)# logging class auth buffered debuggingciscoasa(config)# logging class webvpn buffered debuggingciscoasa(config)# logging class ssl buffered debuggingciscoasa(config)# logging class svc buffered debugging

ptg7987094

[ 120 ]



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) configuration; perhaps Identity NAT is needed for AnyConnect traffic.

■ 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. Configure 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 low-latency 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

ptg7987094

[ 121 ]



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 flowing 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 DTLS Payload IP Header IP PayloadDTLS

HeaderUDP

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(config)# webvpnciscoasa(config-webvpn)# enable outside INFO: WebVPN and DTLS are enabled on 'outside'. ciscoasa(config-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 .

ptg7987094

[ 122 ]




ciscoasa(config)# group-policy BASIC-ANYCONNECT-POLICY attributesciscoasa(config-group-policy)# webvpnciscoasa(config-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.


ciscoasa(config)# group-policy BASIC-ANYCONNECT-POLICY attributesciscoasa(config-group-policy)# webvpnciscoasa(config-group-webvpn)# anyconnect dtls compression lzsciscoasa(config-group-webvpn)# 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

ptg7987094

[ 123 ]



There are two optional configuration steps on the ASA for AnyConnect management:

1. Configure client persistence so that after VPN logoff AnyConnect is not automatically uninstalled. You can configure 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(config)# group-policy BASIC-ANYCONNECT-POLICY attributesciscoasa (config-group-policy)# webvpnciscoasa(config-group-webvpn)# anyconnect keep-installer installed

Figure 3-5 AnyConnect Client Persistence

ptg7987094

[ 124 ]



2. Configure 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(config)# webvpn ciscoasa(config-webvpn)# anyconnect image disk0:/ anyconnect-win-3.0.1047-k9.pkg

Configuring Cisco AnyConnect Client XML Profiles 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 profiles can be edited manually with a XML editor, directly within the ASA ASDM or by using Cisco Profile Editor, a tool installed on a client PC.

■ XML profiles are uploaded to ASA and attached to group policies.

■ After the first login, the XML profile 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 profile. Open Cisco AnyConnect Client Profile Editor and choose File > New . Change all required parameters, and then choose File > Save As .

STEP 2. Upload the XML profile on ASA and validate it.

To upload the XML profile onto the ASA using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile and click Add or Import followed by Validate if the profile was imported, to ensure it is correctly written with the offline XML Profile Editor.

ptg7987094

[ 125 ]



To configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# anyconnect profiles MY-XML-PROFILE disk0:/MY-PROFILE.XML

STEP 3. Assign the XML profile to a group policy.

To assign it using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies and edit the desired policy. Navigate further to Advanced > AnyConnect Client and edit the Client Profiles to Download field. To assign it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-ANYCONNECT-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# anyconnect profiles 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\Profile

■ Windows Vista/Windows 7 : C:\Program Data\Cisco\Cisco AnyConnect VPN Client\Profile

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

ptg7987094

[ 126 ]



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 configured in the AnyConnect XML client profile, 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 configured in the AnyConnect XML client profile, 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 configuration.

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

ptg7987094

[ 127 ]



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 certificate authentication

■ Double or triple authentication starting with ASA 8.2

ptg7987094

[ 128 ]



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 certificate. ASA is a CA and issues identity certificates to clients.

■ An external Public Key Infrastructure (PKI) certificate. 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 certificate-based client authentication using the ASA local CA.

ptg7987094

[ 129 ]



■ Configure certificates to connection profile mapping.

■ Deploy certificate-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. Configure the remote authentication server. To configure it using the ASDM, navigate to Configuration > 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 configure 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 configure an external RADIUS server via the CLI, use the following commands: ciscoasa(config)# aaa-server TEST-RADIUS-SRV protocol radiusciscoasa(config)# aaa-server TEST-RADIUS-SRV (inside) host 10.10.10.10ciscoasa(config-aaa-server-host)# key TEST-RADIUS-KEY

To configure 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, configure the base DN and Login DN, and select the authentication protocol (see Figure 3-7 ).

ptg7987094

[ 130 ]



To configure an LDAP server via the CLI, use the following commands: ciscoasa(config)# aaa-server TEST-LDAP-SRV protocol ldap ciscoasa(config)# aaa-server TEST-LDAP-SRV (inside) host 10.10.10.11ciscoasa(config-aaa-server-host)# server-type Microsoftciscoasa(config-aaa-server-host)# ldap-over-ssl enableciscoasa(config-aaa-server-host)# server-port 636ciscoasa(config-aaa-server-host)# sasl-mechanism digest-md5ciscoasa(config-aaa-server-host)# ldap-scope subtreeciscoasa(config-aaa-server-host)# ldap-base-dn cn=users, dc=cisco, dc=comciscoasa(config-aaa-server-host)# ldap-naming-attribute cnciscoasa(config-aaa-server-host)# ldap-login-password TEST-LDAP-PASSWORDciscoasa(config-aaa-server-host)# ldap-login-dn cn=ASAUSER, dc=cisco, dc=com

ptg7987094

[ 131 ]



Figure 3-6 LDAP Server Setup

ptg7987094

[ 132 ]



Figure 3-7 LDAP Server Setup

ptg7987094

[ 133 ]



To configure 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 configure an RSA server via the CLI, use the following commands: ciscoasa(config)# aaa-server TEST-RSA-SRV protocol sdiciscoasa(config)# aaa-server TEST-RSA-SRV (inside) host 10.10.10.11

STEP 2. Enable remote AAA authentication in the connection profile.

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.


ciscoasa(config)# tunnel-group BASIC-ANYCONNECT-PROFILE general-attributesciscoasa(config-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 certificates.

ptg7987094

[ 134 ]



Deploying Certificate-Based Client Authentication Using the Cisco ASA Local CA 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. Configure the ASA local CA.

To enable CA using the ASDM, navigate to Configuration > Remote Access VPN > Certificate Management > Local Certificate Authority > CA Server , check the Enable Certificate Authority Server check box (see Figure 3-8 ), and ■ Check the Enable check box to activate the local CA server.

■ Configure the passphrase used to protect the local CA certificate.

■ Configure the issuer subject name (the default being the CN=FQDN of the ASA).

■ Select the CA and client key sizes.

■ Configure the CA and client certificate lifetime.

■ Optionally, configure the Simple Mail Transfer Protocol (SMTP) server used to send instructions to users about how to obtain identity certificates.

■ Optionally, click More Options to configure the certificate revocation list (CRL) and the database storage location.

To enable it via the CLI, use the following commands: ciscoasa(config)# smtp-server 10.10.10.20 ciscoasa(config)# crypto ca server ciscoasa(config-ca-server)# keysize 2048 ciscoasa(config-ca-server)# keysize server 2048 ciscoasa(config-ca-server)# lifetime ca-certificate 3650ciscoasa(config-ca-server)# lifetime certificate 365ciscoasa(config-ca-server)# smtp from-address [email protected] ciscoasa(config-ca-server)# issuer-name [email protected] ciscoasa(config-ca-server)# cdp-url http://VPN-CA.cisco.com/+CSCOCA+/asa_ca.crl ciscoasa(config-ca-server)# no shutdown passphrase CISCO-VPN-CA INFO: Certificate server is being enabled

Note If ASA is used as a CA server, failover func-tionality is disabled. You cannot have both CA and failover capabilities concurrently configured because these are mutu-ally exclusive. Take this into account if you have a pair of ASAs deployed in a failover scenario and you want to configure local CA. You will not be allowed to do it.

ptg7987094

[ 135 ]



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 certificate from ASA. To configure them using the ASDM, navigate to Configuration > Remote Access VPN > Certificate Management > Local Certificate Authority > Manage User Database and click Add : ■ Configure the username.

■ Configure the user e-mail address.

■ Configure the distinguished name (DN) for the identity certificate.

ptg7987094

[ 136 ]



■ Check the Allow Enrollment check box.

■ Click Add User .

To configure it via the CLI, use the following commands: ciscoasa(config)# crypto ca server user-db add VPN-USER DN CN=vpn-user,OU=Financial,O=Cisco,C=RO, email [email protected] ciscoasa(config)# crypto ca server user-db allow VPN-USER

STEP 3. Provision the client identity certificates.

Users can obtain their identity certificate using a web browser or AnyConnect. Either way, before downloading the certificate, the user has to authenticate to the ASA by the previously defined 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 out-of-band (OOB) medium.

STEP 4. Install the client certificate on AnyConnect Client.

Users can click the link received via e-mail to receive the identity certificate via a browser. Alternatively, they can initi-ate the AnyConnect session, and the AnyConnect client displays a Get Certificate button (if certificate authentication was configured in the connection profile).

STEP 5. Map certificates to connection profiles.

Certificate to connection profile maps are needed so that ASA can use appropriate connection profiles for users authen-ticating with identity certificates. To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Advanced > Certificate to AnyConnect and clientless SSL VPN Connection Profile Maps and ■ Click Add under Certificate to Connection Profile Maps.

■ Choose New , give it a name, and select the desired connection profile from Mapped to Connection Profile.

■ Click OK to accept the certificate map.

■ Click Add under Mapping Criteria and specify the DN matching criteria.

To configure it via the CLI, use the following commands: ciscoasa(config)# crypto ca certificate map TEST-MAP 10ciscoasa(config-ca-cert-map)# subject-name attr ou eq Financialciscoasa(config)# webvpn ciscoasa(config-webvpn)# certificate-group-map TEST-MAP 10 BASIC-ANYCONNECT-PROFILE

ptg7987094

[ 137 ]



STEP 6. Enable client certificate authentication for the connection profiles.

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.


ciscoasa(config)# tunnel-group TEST-GROUP webvpn-attributesciscoasa(config-tunnel-webvpn)# authentication certificate

Verification can be done as follows:

■ On the client side, navigate to Internet Explorer > Tools > Internet Options >Content > Certificates to view the identity certificates.

■ On the server side, once the session is established, navigate to Monitoring > VPN > VPN Statistics > Sessions and verify certificate 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 Certificate-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 certificate store

■ Browser certificate store

■ Smartcards/smart tokens

■ Filesystem store (Linux)

ptg7987094

[ 138 ]



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 profile that does not use certificate 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 certificate is not present, the AnyConnect session will fail, but the user is presented with a Get Certificate button to process the enrollment.

This section covers just the first option (without SCEP proxy), which requires the following configuration steps:

STEP 1. Configure the XML profile enrollment process. Start the AnyConnect Client Profile Editor, navigate to the Certificate Enrollment tab, and

■ Check the Certificate Enrollment check box.

■ In the Automatic SCEP Host field, enter the ASA FQDN followed by an alias of connection profile used for enrollment process.

■ In the CA URL field, enter the URL for enrollment, which is in the form http://10.10.10.10/certsrv/mscep/mscep.dll .

■ Configure certificate attributes such as canonical name (CN) and organizational unit (OU). The XML profile needs to be uploaded into ASA. Using ASDM, navigate to Configuration >Remote Access VPN > Network (Client) Access > AnyConnect Client Profile , click Add to create a client profile, and click Upload to bring the XML file onto ASA.

STEP 2. Configure a dedicated enrollment connection profile.

Because the XML client profile is a postlogin setting, it can be specified only into group policy settings. Therefore, you first create a group policy and then a connection profile on which you attach it. 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 pro-file in the Client Profiles to Download section.

ptg7987094

[ 139 ]



To configure the connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles , click Add , name it to match the alias from XML profile, leave the authentication method as AAA, and assign the previously created group policy in the Group Policy field. To configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# anyconnect profiles SCEP-XML-PROFILE disk0:/SCEP-XML-PROFILE.XMLciscoasa(config)# group-policy ENROLLMENT-POLICY internal ciscoasa(config)# group-policy ENROLLMENT-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# anyconnect profiles value SCEP-XML-PROFILEciscoasa(config)# tunnel-group ENROLLMENT-PROFILE type remote-access ciscoasa(config)# tunnel-group ENROLLMENT-PROFILE general-attributesciscoasa(config-tunnel-general)# default-group-policy ENROLLMENT-POLICYciscoasa(config)# tunnel-group ENROLLMENT-PROFILE webvpn-attributesciscoasa(config-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 profile by its alias, and follow the onscreen messages to complete the enrollment and install the certificate. When the certifi -cate is installed, AnyConnect automatically disconnects the session.

STEP 4. Optionally, configure the client certificate selection.

Client certificate selection can be forced through XML profiles. In the Client Profile Editor, navigate to the Certificate Match tab and configure match rules in the Distinguished Name section. Save the profile and upload it to ASA. Another option is to disable automatic selection and allow the end user to choose the certificate. In the Client Profile Editor, navigate to the Preferences (cont) tab and choose both Disable Cert Selection and User Controllable . Save the profile and upload it to ASA. Whichever option is used, the XML profile needs to be mapped to the group policy used by the certificate authentication connection profile or to the DfltGrpPolicy, which will apply settings to all existing group policies.

STEP 5. Import the CA certificate into ASA.

ASA needs the CA certificate that issued identity certificates to clients so that it can verify identity certificates. You can install it using SCEP or from a base64-encoded file as in Easy VPN.

STEP 6. Enable identity certificate authentication and mapping for a connection profile.

ptg7987094

[ 140 ]



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 Certificate to Connection Profile Maps.

■ Choose New , give it a name, and select the created connection profile from Mapped to Connection Profile.

■ Click OK to accept the certificate map.

■ Click Add under Mapping Criteria and specify the DN matching criteria.


ciscoasa(config)# group-policy EXTERNAL-CA-POLICY internal ciscoasa(config)# group-policy EXTERNAL-CA-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# anyconnect profiles value CERT-XML-PROFILEciscoasa(config)# tunnel-group EXTERNAL-CA-PROFILE type remote-accessciscoasa(config)# tunnel-group EXTERNAL-CA-PROFILE general-attributesciscoasa(config-tunnel-general)# default-group-policy EXTERNAL-CA-POLICYciscoasa(config)# tunnel-group EXTERNAL-CA-PROFILE webvpn-attributesciscoasa(config-tunnel-webvpn)# authentication certificate ciscoasa(config)# crypto ca certificate map EXTERNAL-CA-MAP 10ciscoasa(config-ca-cert-map)# subject-name attr ou eq Financial ciscoasa(config)# webvpn ciscoasa(config-webvpn)# certificate-group-map EXTERNAL-CA-MAP 10 EXTERNAL-CA-PROFILEciscoasa(config-webvpn)# anyconnect profiles CERT-XML-PROFILE disk0:/CERT-XML-PROFILE.XML

ptg7987094

[ 141 ]



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 certificates

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

■ Configure a certificate-revocation checking policy.

■ Configure 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:

■ Certificate based + one AAA authentication

■ Certificate based + one AAA authentication + username prefill

■ Certificate based + one AAA authentication + prefill + hide

■ Certificate based + double AAA authentication with optional username prefill and hide

■ Double AAA authentication (no certificate) with optional username reuse

ptg7987094

[ 142 ]



Certificate 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.


ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-tunnel-general)# authentication-server-group TEST-RADIUS-SRVciscoasa(config)# tunnel-group TEST-GROUP webvpn-attributesciscoasa(config-tunnel-webvpn)# authentication certificate aaa

Certificate Based + One AAA Authentication + Username Prefill 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.


ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-tunnel-general)# authentication-server-group TEST-RADIUS-SRVciscoasa(config)# tunnel-group TEST-GROUP webvpn-attributesciscoasa(config-tunnel-webvpn)# authentication certificate aaaciscoasa(config-tunnel-webvpn)# pre-fill-username ssl-client

Certificate Based + One AAA Authentication + Prefill + 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 ).

ptg7987094

[ 143 ]




ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-tunnel-general)# authentication-server-group TEST-RADIUS-SRVciscoasa(config)# tunnel-group TEST-GROUP webvpn-attributesciscoasa(config-tunnel-webvpn)# authentication certificate aaaciscoasa(config-tunnel-webvpn)# pre-fill-username ssl-client hide

Figure 3-9 Certificate Based + AAA Authentication

ptg7987094

[ 144 ]



Certificate Based + Double AAA Authentication with Optional Username Prefill 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 ).


ciscoasa(config)# tunnel-group TEST-GROUP general-attributes ciscoasa(config-tunnel-general)# authentication-server-group TEST-RADIUS-SRVciscoasa(config-tunnel-general)# secondary-authentication-server-group TEST-LDAP-SRV use-primary-usernameciscoasa(config)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(config-tunnel-webvpn)# authentication certificate aaa ciscoasa(config-tunnel-webvpn)# pre-fill-username ssl-client hide

ptg7987094

[ 145 ]



Figure 3-10 Certificate Based + Double AAA Authentication

ptg7987094

[ 146 ]



Double AAA Authentication (No Certificate) 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) .


ciscoasa(config)# tunnel-group TEST-GROUP general-attributes ciscoasa(config-tunnel-general)# authentication-server-group TEST-RADIUS-SRVciscoasa(config-tunnel-general)# secondary-authentication-server-group TEST-LDAP-SERV use-primary-usernameciscoasa(config)# tunnel-group TEST-GROUP webvpn-attributes ciscoasa(config-tunnel-webvpn)# authentication certificate 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.)

ptg7987094

[ 147 ]



The following steps need to be completed:

STEP 1. Enable the password management feature in the connection profile settings. 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 . Navigate further to Advanced > General , check the Enable Password Management check box, and optionally choose the number of days a user should be notified before the password expires. To configure it via the CLI, use the following commands: ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-tunnel-general)# authentication-server-group TEST-LDAP-SRVciscoasa(config-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. Configure 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.

ptg7987094

[ 148 ]



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

ptg7987094

[ 149 ]


Chapter 4: Deploying Clientless Remote-Access SSL VPN Solutions

To successfully implement a basic clientless VPN solution, complete these deployment tasks:

1. Configure the basic ASA VPN gateway features, including Secure Sockets Layer/Transport Layer Security (SSL/TLS) server authentication.

2. Configure local user authentication. 3. Configure the basic portal features and access control. 4. Optionally, tune the basic SSL VPN proxy operation.

Configuring 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 certificate on the ASA. Clients authenticate the ASA with a certificate-based authenti-cation method, and ASA authenticates clients based on username/password credentials. The process and options associated with installing an identity certificate 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 Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles . 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 sup-ported by clientless solution.

To configure it by command-line interface (CLI), use the following commands: ciscoasa(config)# webvpnciscoasa(config-webvpn)# enable outside

STEP 3. Configure and optionally tune SSL/TLS settings. Optionally, enable/disable SSL/TLS version settings, enable/disable SSL/TLS cipher algorithms, and attach identity certificates to SSL-enabled interfaces. To configure these using the ASDM, navigate to Configuration > Remote Access VPN > Advanced> SSL Settings .

To configure it via the CLI, use the following commands: ciscoasa(config)# ssl server-version tlsv1-only ciscoasa(config)# ssl encryption aes256-sha1 aes128-sha1 3des-sha1 des-sha1ciscoasa(config)# ssl trustpoint TEST-CA outside

ptg7987094

[ 150 ]



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 Configure One DNS Server Group if name resolution is required for a single domain or choose Configure 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.


ciscoasa(config)# dns domain-lookup insideciscoasa(config)# dns server-group DOMAIN-CISCO-COMciscoasa(config-dns-server-group)# domain-name cisco.comciscoasa(config-dns-server-group)# name-server 10.10.10.10ciscoasa(config-dns-server-group)# name-server 10.10.10.11

Configuring 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. Configure 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 Configuration > 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 configure it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY internalciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributes

ptg7987094

[ 151 ]



ciscoasa(config-group-policy)# vpn-tunnel-protocol ssl-clientless

STEP 2. Optionally, create a connection profile for clientless SSL VPN and assign the group policy to it.

To configure a connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profile , 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 configure it via the CLI, use the following commands: ciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE type remote-accessciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE general-attributesciscoasa(config-tunnel-general)# default-group-policy BASIC-CLIENTLESS-POLICYciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributesciscoasa(config-tunnel-webvpn)# dns-group DOMAIN-CISCO-COM

STEP 3. Optionally, define an alias for the connection profile.

In the connection profile, navigate to Advanced > Clientless SSL VPN and in the Connection Aliases section click Add .

To configure it via the CLI, use the following commands: ciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributesciscoasa(config-tunnel-webvpn)# group-alias BASIC-CLIENTLESS-PROFILE enable

STEP 4. Optionally, allow connection profile selection.

Using the ASDM, you can allow clients to choose the connection profile within a drop-down menu in the web portal. To do so, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles and choose Allow User to Select Connection Profile, Identified By Its Alias, on the Login Page under Login Page Setting.

To configure it via the CLI, use the following commands: ciscoasa(config)# webvpnciscoasa(config-webvpn)# tunnel-group-list enable

STEP 5. Configure local users and optionally connection profile lock.

ptg7987094

[ 152 ]



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.


ciscoasa(config)# username BASIC-CLIENTLESS-USER password BASIC-CLIENTLESS-PASSciscoasa(config)# username BASIC-CLIENTLESS-USER attributesciscoasa(config-username)# group-lock value BASIC-CLIENTLESS-PROFILE

Configuring 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

ptg7987094

[ 153 ]



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 configuration is needed.

■ If the accessed resource is behind the ASA, traffic is subject to ASA firewall 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. Configure the basic portal feature. To configure it using the ASDM and make it applicable at group level, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies , select an existing policy, click Edit , and navigate further to Portal (see Figure 4-1 ).

■ Configure the bookmark list.

■ Configure the URL entry.

■ Configure file access control.

ptg7987094

[ 154 ]



Figure 4-1 Basic Portal Features

ptg7987094

[ 155 ]



To configure it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy# webvpnciscoasa(config-group-webvpn)# url-list value BOOKMARK-TEST-LISTciscoasa(config-group-webvpn)# hidden-shares noneciscoasa(config-group-webvpn)# file-entry disableciscoasa(config-group-webvpn)# file-browsing disableciscoasa(config-group-webvpn)# url-entry disable

STEP 2. Configure per-profile or per-user ACLs.

To create a webtype ACL using the ASDM, navigate to Configuration > 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-figure rules. To apply the webtype ACL to a group policy using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies , select an existing policy, and click Edit. In the General > Web ACL , apply the configured ACL.

To configure it via the CLI, use the following commands: ciscoasa(config)# access-list WEB-ACL-TEST webtype permit url ftp://10.10.10.10ciscoasa(config)# access-list WEB-ACL-TEST webtype permit url https://10.10.10.11ciscoasa(config)# access-list WEB-ACL-TEST webtype permit tcp host 10.10.10.12 eq 3128ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy# webvpn ciscoasa(config-group-webvpn)# filter value WEB-ACL-TEST

STEP 3. Configure direct access to resources via rewrite disable.

To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Content Rewrite and click Add for an exception rule. To configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-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.

Note URL lists can be created only through ASDM; the function is not avail-able in the CLI, because these are saved in XML files onto ASA flash. This is why content of the BOOKMARK-TEST-LIST URL list is not shown in this CLI template.

ptg7987094

[ 156 ]



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 certificates and enabled SSL interfaces.

■ Verify user credentials and authentication methods configured on ASA and the client.

■ Verify whether clientless SSL session is allowed in the connection profile 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 configuration and accessibility on the ASA.

ptg7987094

[ 157 ]



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

ptg7987094

[ 158 ]



Configuring 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

Benefits Limitations

Do not require client installation on remote system Only limited number of applets available

Easy to use for remote user May not include all native client functionality

Does not require administrator privileges on system 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 flash file system. After plug-ins are down-loaded, to import them into ASA using the ASDM, navigate to Configuration > 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, flash or FTP, TFTP, HTTP server. To import it using the CLI, use the follow-ing commands: ciscoasa(config)# import webvpn plug-in protocol rdp flash:/ 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 Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks , click Add , and select the appropriate plug-in and create the URL.

ptg7987094

[ 159 ]



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.

Configuring 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


Supports native client applications over SSL VPN Only Winsock2 TCP-based applications supported

Easy to use for remote user and better performance than plug-ins Bypasses advanced ASA application control, secure services module (SSM)

Does not require administrator privileges on the system like port forwarding does

Supported only on Windows and Mac OS

ptg7987094

[ 160 ]



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 profile.

To create a smart tunnel application list using the ASDM, navigate to Configuration > 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 ), configure 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.

ptg7987094

[ 161 ]



Figure 4-2 Smart Tunnel Application List

ptg7987094

[ 162 ]



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 Configuration > 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 configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# smart-tunnel list OUTLOOK Outlook outlook.exe platform windowsciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# smart-tunnel enable OUTLOOKciscoasa(config-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 first 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 Configuration > 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 fields: ■ Hostname or

■ IP Address and optionally Subnet Mask

To configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# smart-tunnel network NET-LIST ip 10.10.10.10 255.255.255.255ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# smart-tunnel tunnel-policy tunnelspecified NET-LISTciscoasa(config-group-webvpn)# smart-tunnel tunnel-policy excludespecified NET-LIST

Note that the you can use only smart-tunnel tunnel-policy tunnelspecified NET-LIST or smart-tunnel tunnel-policy ex-cludespecified NET-LIST . These are mutually exclusive. The first one specifies traffic for which destination networks to be smart tunneled. The second one specifies that all traffic except those destinations needs to be smart tunneled. There is also a

ptg7987094

[ 163 ]



third option, which does not require a tunnel network list to be created, with the result being that all traffic 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 traffic is smart tunneled. To configure it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpnciscoasa(config-group-webvpn)# smart-tunnel tunnel-policy tunnelall

Figure 4-3 Smart Tunnel Network List

ptg7987094

[ 164 ]



This second option of configuring a smart tunnel network list brings the split-tunneling functionality to clientless SSL VPN sessions and makes the smart tunneling configuration 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 profile.

This is an alternative to problematic sites that are not functional with the normal SSL VPN proxy rewriting function. To configure smart tunnels for web-based applications, create a bookmark for smart tunnels. Using ASDM, navigate to Configuration > 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.

Configuring 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.

ptg7987094

[ 165 ]



■ Based on the ASA configuration, it modifies the local host file and starts listening on a preconfigured TCP port on the remote-host 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


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 files

To enable port forwarding, complete these steps:

STEP 1. Specify the client ports subject to port forwarding.

To configure a port forwarding list using the ASDM, navigate to Configuration > 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.

ptg7987094

[ 166 ]



Figure 4-4 Port Forwarding List

To configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# port-forward RDP 5005 10.10.10.10 3389 Remote Desktop

ptg7987094

[ 167 ]



STEP 2. Enable port forwarding in a user profile or group policy.

To assign the port forwarding list to a group policy 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 > Port Forwarding Control and select the created list.

To configure it via the CLI, use the following commands. (Two options are available.) ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpnciscoasa(config-group-webvpn)# port-forward enable RDP

ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpnciscoasa(config-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 exclu-sive. The first 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 configuration, verify whether the plug-ins were imported.

■ If URLs or bookmarks are not available in the portal, verify group policy or user profile configuration.

■ If a plug-in does not start, verify browser settings for Java and ActiveX applets.

■ If a plug-in does not connect, verify URL configuration, DNS resolution, and webtype ACLs.

ptg7987094

[ 168 ]



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 profile configuration.

■ If the application does not connect, check webtype ACLs.

■ Verify the smart tunnel list and configured split-tunneling policy for configuration 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 profile configuration.

■ 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 verifies the authenticity of the server, multiple options being available ■ Self-signed certificate

■ The identity certificate issued by an external certificate authority (CA), an external Public Key Infrastructure (PKI) scheme

ptg7987094

[ 169 ]



2. Client-side authentication, where the server verifies the authenticity of clients

■ Identity certificates issued by the CA residing on ASA

■ Identity certificates issued by an external CA, an external PKI scheme

■ Passwords (static or one-time passwords)

■ Multiple combined sequential authentications

Deploying Client Certificate-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. Configure the ASA local CA.

STEP 2. Create CA user accounts.

Because the first two steps are identical to AnyConnect Client authentication, a detailed description of the steps is un-necessary here.

STEP 3. Enable client certificate authentication for a connection profile.

To configure certificate-based authentication in a connection profile using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profile , select a profile, and click Edit . In Basic > Authentication , choose Certificate as the authentication method.

To configure it via the CLI, use the following commands: ciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributesciscoasa(config-tunnel-webvpn)# authentication certificate

ptg7987094

[ 170 ]



STEP 4. Optionally, configure mapping of certificates to connection profiles.

To configure it using the ASDM, navigate to Configuration > Remote Access VPN > Advanced > Certificate to AnyConnect and Clientless SSL VPN Connection Profile Maps . Under Certificate to Connection Profile Maps, click Add to create a new map and select the connection profile it maps to. Under Mapping Criteria, click Add to create cer-tificate matching rules.

To configure it via the CLI, use the following commands: ciscoasa(config)# crypto ca certificate map CLIENTLESS-MAP 10ciscoasa(config-ca-cert-map)# subject-name attr cn eq financial ciscoasa(config)# webvpn ciscoasa(config-webvpn)# certificate-group-map CLIENTLESS-MAP 10 BASIC-CLIENTLESS-PROFILE

STEP 5. Provision client identity certificates to clientless users.

The client enrollment process is completed in several steps:

1. The user initiates the clientless SSL VPN session for the certificate authentication connection profile. 2. The user receives an authentication failure but also a link for obtaining a identity certificate. 3. Following the link, users are asked for their username and one-time password. 4. 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. 5. By opening the file, the user starts the Installation Wizard for the certificate.

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.

ptg7987094

[ 171 ]



Client Authentication Using an External CA Client authentication using an external CA requires the following configuration steps:

STEP 1. Import the external CA certificate onto ASA (manually or through Simple Certificate Enrollment Protocol [SCEP]).

STEP 2. Optionally, enroll clients into PKI. If no client identity certificate exists, only server-side authentication will use the certificate; client-side authentication will use AAA.

STEP 3. Optionally, enable client certificate authentication for the connection profile. This is required if clients are enrolled into the PKI for client-side certificate authentication.

Deploying Advanced Gateway PKI Integration, Certificate 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, configure certificate-revocation checking policy.

■ Optionally, configure AAA certificate 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 certificate attributes and can be used for primary and secondary AAA authentication.

■ Usernames can be copied for secondary AAA authentication from the primary AAA authentication.

ptg7987094

[ 172 ]



Available deployment options are the same as for AnyConnect SSL VPN:

■ Certificate based + one AAA authentication

■ Certificate based + one AAA authentication + username prefill

■ Certificate based + one AAA authentication + username prefill + hide

■ Certificate based + double AAA authentication with optional username prefill 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 certificate validity period.

■ Verify potential revoked certificates.

■ Verify the matching criteria in a certificate to connection profile mappings.

■ Verify correct AAA operations.

ptg7987094

[ 173 ]



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. Configure dedicated SSO servers. ASA supports two dedicated SSO platforms:

■ Computer Associates eTrust SiteMinder (formerly Netegrity SiteMinder)

■ SAML version 1.1 Browser Post Prefill

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 Profile 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 certificates only, no credentials are available and so integration with an SSO platform is not possible.

To configure an SSO server using the ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Single Signon Servers and choose Add . In the new window, configure these parameters for a SiteMinder configuration (see Figure 4-5 ):

■ In the Server Name field, use a name that is significant to you.

■ In the Authentication Type field, select between the two supported servers.

■ In the Assertion URL field, configure the URL where authentication requests are sent.

■ In the Secret Key field, enter the key used to encrypt authentication requests.

■ In the Maximum retries field, enter number of requests send to the server for authentication.

■ In the Request Timeout field, enter the number of seconds before an authentication request times out.

ptg7987094

[ 174 ]



Figure 4-5 SSO Server

ptg7987094

[ 175 ]



After the SSO server is configured, SSO authentication must be enabled in the user profile or group policy. To enable it in a group policy using the ASDM, navigate to Configuration > 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 configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# sso-server SITEMINDER-TEST type siteminderciscoasa(config-webvpn-sso-siteminder)# web-agent-url https://10.10.10.10ciscoasa(config-webvpn-sso-siteminder)# policy-server-secret siteminderciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# sso-server value SITEMINDER-TEST

STEP 2. Besides dedicated SSO servers, two other SSO methods are available for simplified 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 Configuration > 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 field, enter destination networks for which you want SSO.

■ In the Network Mask field, enter the mask to identify the subnet.

■ Optionally, instead of configuring a subnet, specify the destination URI for which SSO is desired

■ In the Authentication Type field, select the protocols for which SSO is desired.

■ In the Authentication Credential field, specify to use login credentials or different ones.

ptg7987094

[ 176 ]



Figure 4-6 HTTP BASIC, NTLM, FTP

To configure it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributes ciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# auto-signon allow ip 10.0.0.0 255.0.0.0 auth-type all username Cristian.Matei password easypassword

ptg7987094

[ 177 ]



STEP 3. Configure variable/macro substitution for SSO.

Variable and macro substitution allows for certain variables to be injected in bookmarks to substitute for dynamic val-ues, 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 Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles . Under Login Page Setting, check the Allow User to Enter Internal Password on the Login Page check box.

To configure it via the CLI, use the following commands: ciscoasa(config)# webvpnciscoasa(config-webvpn)# internal-password enable

Values of variables and macros can be obtained in two ways: ■ From the login page

■ From RADIUS/LDAP vendor-specific attributes (VSA)

To enable variables in certain bookmarks using the ASDM, navigate to Configuration > 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 POST-based methods, not for GET.

STEP 4. Configure SSO for application plug-ins.

The application plug-ins do not support variable/macro substitution syntax, but SSO functionality is enabled by embed-ding the csco_sso=1 parameter in the URI field 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&parameter&Parameter

For this, SSO credentials are obtained from VPN login credentials, and an internal password always overrides any oth-er 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.

ptg7987094

[ 178 ]



STEP 5. Configure 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.


ciscoasa(config)# webvpn ciscoasa(config-webvpn)# smart-tunnel auto-signon AUTO-SIGNO-ON ip 10.10.10.10 255.255.255.255ciscoasa(config)# group-policy BASIC-CLIENTLESS-POLICY attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# smart-tunnel auto-signon enable AUTO-SIGNO-ON

ptg7987094

[ 179 ]



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. ASDM-driven customization can be achieved through following steps:

STEP 1. Create a new customization object. To configure the onscreen keyboard, navigate to Configuration > 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 Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Customization and click Add . Give it a name and select the connection profiles 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

ptg7987094

[ 180 ]



STEP 3. Associate the object with a connection profile. Because customized objects relate to both prelogin and postlogin settings, you can apply them in multiple places: con-nection profile, group policy, user profile. 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 the customized object in the Login and Logout Customization field. To map it using the CLI, use the following commands: ciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributesciscoasa(config-tunnel-webvpn)# customization TEST-CUSTOMIZATION

STEP 4. Optionally, update the default DfltCustomization object; all connection profiles, which have not been assigned a customized portal, will inherit settings from the DfltCustomization.

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 file. Here, you create the code for logon screen and save it in a file called logon.inc .

STEP 2. Import the file and images into ASA. Here, the logon.inc and images it references need to be imported into ASA. To do so, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Web Contents and click Import .

STEP 3. Configure the customization object to replace the logon screen. To activate the created logon.inc within the logon screen, navigate to Configuration > 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 file.

STEP 4. Attach the customization object to a connection profile.

ptg7987094

[ 181 ]



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 Configuration > Remote Access PVN > Clientless SSL VPN >Portal > Customization , select the template, and click Export .

STEP 2. Create and XML file using third-party tools.

STEP 3. Import the XML file as a customization object.

After the XML file is created with third-party tools, you need to import it into ASA. Navigate to Configuration > Remote Access PVN > Clientless SSL VPN >Portal > Customization and click Import .

STEP 4. Associate it with a connection profile.

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

ptg7987094

[ 182 ]



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. Configure customization languages. STEP 4. Associate the customization object with a connection profile.

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 file in a browser by accessing the help file URL, after successful authentication.

STEP 2. Save the help file on the local computer.

STEP 3. Customize the help file.

STEP 4. Import the customized help file into ASA.

ptg7987094

[ 183 ]



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.

ptg7987094

[ 184 ]



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. DAP rules 2. User profile rules 3. Group policy attached to user profile 4. Group policy attached to the connection profile 5. DfltGrpPolicy settings

ptg7987094

[ 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. Configure an ACL (for full-tunnel VPN, both Secure Sockets Layer [SSL] and IP Security [IPsec] IKEv1/IKEv2).

To configure it using the Adaptive Security Device Manager (ASDM), navigate to Configuration > 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 configure it by command-line interface (CLI), use the following command: ciscoasa(config)# access-list TEST-ACL permit tcp any host 10.10.10.10 eq 80

STEP 2. Configure a webtype ACL (clientless SSL VPN). To configure it using the ASDM, navigate to Configuration > 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 configure it via the CLI, use the following command:

ciscoasa(config)# access-list TEST-WEB-ACL webtype permit url https://10.10.10.10

STEP 3. Configure 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 Configuration > Remote Access VPN > Network (Client) Access > Group Policies and click Add or Edit . To configure clientless SSL-specific group settings, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies , select the policy, and click Edit .

To configure it via the CLI, use the following commands: ciscoasa(config)# group-policy BASIC-GROUP-POLICY internalciscoasa(config)# group-policy BASIC-GROUP-POLICY attributesciscoasa(config-group-policy)# vpn-tunnel-protocol IPSec svc webvpnciscoasa(config-group-policy)# vpn-filter value TEST-ACLciscoasa(config-group-policy)# webvpnciscoasa(config-group-webvpn)# filter value TEST-WEB-ACL

ptg7987094

[ 186 ]



STEP 4. Apply a group policy to connection profiles, user profiles, 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.


ciscoasa(config)# username TEST-USER password TEST-PASSciscoasa(config)# username TEST-USER attributesciscoasa(config-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 webvpnciscoasa# show vpn-sessiondb anyconnectciscoasa# show vpn-sessiondb ra-ikev1-ipsec

Example 5-1 Verify Clientless SSL VPN Sessions ciscoasa# show vpn-sessiondb webvpn filter name cristian.matei

Session Type: WebVPN

Username : cristian.matei Index : 1588 Public IP : 188.26.145.25 Protocol : Clientless License : SSL VPN Encryption : RC4 Hashing : SHA1 Bytes Tx : 127870 Bytes Rx : 20635 Group Policy : BASIC-GROUP-POLICY Tunnel Group : BASIC-CONNECTION-PROFILE Login Time : 03:23:12 UTC Sun Jan 9 2011 Duration : 0h:02m:01s Inactivity : 0h:00m:00s NAC Result : Unknown VLAN Mapping : N/A VLAN : none

ptg7987094

[ 187 ]



Example 5-2 Verify IPsec VPN Sessions ciscoasa# show vpn-sessiondb ra-ikev1-ipsec filter name cristian.matei

Session Type: IPsec

Username : cristian.matei Index : 1589 Assigned IP : 192.168.16.1 Public IP : 188.26.145.25 Protocol : IKE IPsecOverNatT License : IPsec Encryption : 3DES AES256 Hashing : SHA1 Bytes Tx : 10968 Bytes Rx : 23219 Group Policy : TEST-POLICY Tunnel Group : TEST-GROUP Login Time : 03:29:29 UTC Sun Jan 9 2011 Duration : 0h:01m:42s Inactivity : 0h:00m:00s NAC Result : Unknown VLAN Mapping : N/A VLAN : 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, configure an LDAP attribute map.

■ Assign an external AAA server to a connection profile.

■ 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:

■ Configure the ASA as a AAA client.

■ Create users and user groups.

ptg7987094

[ 188 ]



■ Optionally, define Internet Engineering Task Force (IETF) attribute 25 to reference a baseline group policy.

■ Optionally, prepare the authorization interface.

■ Optionally, configure specific 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.


ciscoasa(config)# aaa-server TEST-RADIUS protocol radius ciscoasa(config)# aaa-server TEST-RADIUS (inside) host 10.10.10.10ciscoasa(config-aaa-server-host)# key CISCO ciscoasa(config)# aaa-server TEST-LDAP-SRV protocol ldap ciscoasa(config)# aaa-server TEST-LDAP-SRV (inside) host 10.10.10.11ciscoasa(config-aaa-server-host)# server-type Microsoftciscoasa(config-aaa-server-host)# ldap-over-ssl enableciscoasa(config-aaa-server-host)# server-port 636ciscoasa(config-aaa-server-host)# sasl-mechanism digest-md5ciscoasa(config-aaa-server-host)# ldap-scope subtreeciscoasa(config-aaa-server-host)# ldap-base-dn cn=users, dc=cisco, dc=comciscoasa(config-aaa-server-host)# ldap-naming-attribute cnciscoasa(config-aaa-server-host)# ldap-login-password TEST-LDAP-PASSWORDciscoasa(config-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.

ptg7987094

[ 189 ]




ciscoasa(config)# aaa-server TEST-LDAP-SRV (inside) host 10.10.10.11ciscoasa(config-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 .


ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-tunnel-general)# authorization-requiredciscoasa(config-tunnel-general)# authentication-server-group TEST-RADIUSciscoasa(config-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.

ptg7987094

[ 190 ]



Configuring VPN Session Accounting Deployment tasks are as follows:

■ Add a RADIUS or TACACS+ server; optionally, use an existing one.

■ Enable accounting in the connection profile.

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.


ciscoasa(config)# tunnel-group TEST-GROUP general-attributesciscoasa(config-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.

■ Traffic 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.

Note Downloadable ACLs override local ASA ACL configurations.

ptg7987094

[ 191 ]



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 configured 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 configured.

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 files, digital certificates, 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 files 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.

ptg7987094

[ 192 ]



■ Keystroke Logger Detection scans for processes that record keystrokes entered by users.

■ CSD Policies specifies 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 specific 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:

1. The remote user starts an AnyConnect or clientless SSL VPN session. 2. The operating system detection module is downloaded and started. 3. The Prelogin Assessment module is downloaded and started. 4. Based on the Prelogin Assessment result, the login is denied or CSD policies are applied. 5. A check is made for keystroke logger and host emulation. 6. Secure Vault or Cache Cleaner is downloaded and started. 7. The user authenticates. 8. DAP checks are applied. 9. The VPN tunnel becomes active. 10. Post-session cleanup occurs at VPN termination.

Note Host Scan and Cache Cleaner do not support the 64-bit version of Microsoft IE. CSD is not supported for IKEv1 IPsec VPN ses-sions.

ptg7987094

[ 193 ]



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 Yes Yes 32-bit only Yes 32-bit only 32-bit only

Windows Vista Yes Yes 32-bit only Yes 32-bit only 32-bit only

Windows XP Yes Yes 32-bit only Yes 32-bit only 32-bit only

Windows Mobile Yes Yes N/A N/A N/A N/A

Apple Mac OS Yes Yes N/A Yes N/A N/A

Linux Yes Yes N/A Yes 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 file is used on a remote client, it requires administrative privileges.

2. Clientless SSL VPN ■ ActiveX, requires administrative privileges

■ Sun JVM, does not require administrative privileges

■ Executable file, requires administrative privileges

ptg7987094

[ 194 ]



To enable functionality of CSD, follow these deployment steps:

STEP 1. Install and enable CSD on the ASA. Complete these configuration tasks:

■ Download, install CSD, and enable it globally on the ASA.

■ Optionally, disable CSD on a per-connection profile basis.

■ Customize CSD to display custom banners and background.

To upload CSD into ASA using the ASDM, navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Setup , click Upload , and check the Enable Secure Desktop check box. To configure it via the CLI, use the following commands: ciscoasa(config)# webvpn ciscoasa(config-webvpn)# csd image disk0:/csd_3.5.2008-k9.pkgciscoasa(config-webvpn)# csd enable

To disable CSD in a specific connection profile, edit the connection profile 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 configure it via the CLI, use the following commands: ciscoasa(config)# tunnel-group BASIC-CLIENTLESS-PROFILE webvpn-attributesciscoasa(config-tunnel-webvpn)# without-csd

To customize CSD (supported only for 32-bit Windows Vista, XP SP2 and SP3) using the ASDM, navigate to Configuration > 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. Configure prelogin criteria.

In this step, you can check for the presence and integrity of certain files, the presence of digital certificates, the type of operating system, IP address, and Windows Registry keys. To configure these using the ASDM, navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin policy . ASDM provides a simple tool to define 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:

ptg7987094

[ 195 ]



■ Login Denied , which cuts off any further processing for this branch and login access is blocked

■ Policy , which defines the endpoint profile, 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 Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin policy (the default policy being available as a start). On a Windows PC, users can verify the re-ceived Prelogin Assessment data by viewing logs in Event Viewer, Application Log section.

STEP 3. Configure 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.

2. Cache Cleaner ■ At VPN termination, it removes browser data using the DoD sanitation algorithm.

■ It can monitor only one browser application per SSL VPN session.

3. Detect Host Emulation ■ Detects host emulation or virtualization

■ Configurable to disallow virtualized hosts from connecting

4. Detect Keystroke Logger ■ Detection for loggers running as a process or kernel module

■ Does not detect hardware-based loggers

STEP 4. Configure advanced endpoint assessment.

ptg7987094

[ 196 ]



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, files, Registry, IP address, and certificates.

■ Endpoint Assessment scans for personal firewall, antivirus, and antispyware and provides information to DAP but does not perform remediation.

■ Advanced Endpoint Assessment scans for personal firewall, 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 Configuration > 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. Configure Vault parameters.

Navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies and select a poli-cy. From here, you have multiple options: ■ Secure Desktop (Vault) General. Configure settings such as allowing switching between secure and local desktops

or Vault inactivity timeout.

■ Secure Desktop (Vault) Settings. Configure 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 configured here.

ptg7987094

[ 197 ]



STEP 3. Alternatively, configure Cache Cleaner parameters.

Navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policies , select a policy, and navigate further to Cache Cleaner . Here, configure settings, such as launching cleanup based on inactivity timeout or closing of all browser instances.

STEP 4. Enable keystroke logger detection.

Navigate to Configuration > 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 Configuration > 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.

Configuring 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 definition for antivirus and antispyware if not updated for a defined number of days.

■ Enable and reconfigure firewall rules if they do not meet defined requirements.

ptg7987094

[ 198 ]



To configure Advanced Endpoint Assessment, follow these steps:

STEP 1. Enable Advanced Endpoint Assessment. Navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Host Scan and check the Advanced Endpoint Assessment check box under Host Scan Extensions . From here, click Configure to achieve the following steps.

STEP 2. Configure antivirus software assessment. STEP 3. Configure antivirus software remediation. STEP 4. Configure personal firewall software assessment. STEP 5. Configure personal firewall software remediation. STEP 6. Configure antispyware software assessment. STEP 7. Configure 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

ptg7987094

[ 199 ]



■ 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, configure a AAA server to be the trusted interface of the Cisco ISE appliance.

■ Enable accounting of VPN connections in a connection profile.

Deploying Dynamic Access Policies

Overview 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, defining a limited set of authorization attributes that can override authorization defined 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.

Note Trying to configure DAP records using the CLI might cause DAP to stop working. So, using the ASDM for DAP is rec-ommended.

ptg7987094

[ 200 ]



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. Network ACLs 3. Webtype ACLs 4. Port forwarding lists 5. Bookmarks 6. Functions, allows configuring file server and URL entry, HTTP proxy, file server browsing 7. Access method, enforces type of remote access VPN session allowed 8. AnyConnect, select status of always-on VPN flag

DAP is applied in the following sequence of events:

1. The remote client attempts a VPN session. 2. ASA performs a posture assessment using NAC and CSD Host Scan. 3. ASA authenticates the user via AAA; AAA returns authorization attributes. 4. ASA applies authorization attributes to the session. 5. ASA selects one or more DAP records based on AAA authorization and posture assessment. 6. ASA aggregates attributes from selected DAP records to become a DAP policy. 7. ASA applies the DAP policy to the VPN session.

ptg7987094

[ 201 ]



Configuring 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. Configure authorization parameters. STEP 5. Configure the action for DfltAccessPolicy.

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 conflicting ACL rules, the most restrictive one applies; however, you should avoid this configuration if possible.

■ Add local/AAA and endpoint attributes.

■ Configure 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 detailciscoasa# show access-list | i DAP

ptg7987094

[ 202 ]



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, final 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, file server browsing, file 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 ap-

plies 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. Configure an additional DAP record policy.

STEP 2. Specify local/AAA attributes matching criteria.

STEP 3. Configure authorization parameters.

ptg7987094

[ 203 ]



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 detailciscoasa# 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.

■ Configure 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

ptg7987094

[ 204 ]



■ Device

■ NAC

■ Operating system

■ Personal firewall

■ 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.

ptg7987094

[ 205 ]



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 profile backup servers defined 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 configured in a failover scenario. It does not provide load balancing, but stateful failover, if configured, 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.

ptg7987094

[ 206 ]



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:

■ Configure 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 Create a profile. Configure backup servers on ASA or the client. Configure backup servers.

2 Upload the profile to ASA. Optionally, tune DPD. Optionally, tune DPD.

3 Assign the profile to a user or group. Optionally, enable RRI. Optionally, enable RRI.

4 Optionally, tune DPD. Optionally, redistribute static routes to an IGP.

Optionally, redistribute static routes to an IGP.

5 Optionally, redistribute static routes into an IGP.

ptg7987094

[ 207 ]



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.


ciscoasa(config)# webvpn ciscoasa(config-webvpn)# anyconnect profiles REDUNDANT disk0:/REDUNDANT.xmlciscoasa(config)# group-policy BASIC-ANYCONNECT attributesciscoasa(config-group-policy)# webvpn ciscoasa(config-group-webvpn)# anyconnect dpd-interval gateway 20ciscoasa(config-group-webvpn)# anyconnect dpd-interval client 20ciscoasa(config-group-webvpn)# anyconnect profiles 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 Configuration (the default). With this option, you must configure backup servers on the client.

■ Use the Backup Servers Below (and specify the servers). This is pushed to clients in the Mode Config phase.

■ Clear Client Configuration. This makes the client not use backup servers.

ptg7987094

[ 208 ]



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 Confidence 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.


ciscoasa(config)# group-policy BASIC-GROUP-POLICY attributesciscoasa(config-group-policy)# backup-servers 10.10.10.10 10.10.10.11ciscoasa(config)# tunnel-group BASIC-TUNNEL-GROUP ipsec-attributesciscoasa(config-tunnel-ipsec)# isakmp keepalive threshold 10 retry 2ciscoasa(config)# 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.

ptg7987094

[ 209 ]



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. Configure the failover link.

STEP 2. Configure active and standby addresses on used interfaces.

STEP 3. Define the failover criteria.

STEP 4. Optionally, configure 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.

■ Configure the LAN and state failover interfaces.

■ Optionally, enable HTTP replication (HTTP sessions replication) and failover shared key to secure failover messages.

ptg7987094

[ 210 ]



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(config)# failover lan unit primary ciscoasa(config)# failover lan interface FAILOVER GigabitEthernet0/2 ciscoasa(config)# failover polltime unit 2 holdtime 6 ciscoasa(config)# failover polltime interface 4 holdtime 12 ciscoasa(config)# failover interface-policy 10% ciscoasa(config)# failover key CISCO-FAILOVER ciscoasa(config)# failover link FAILOVER GigabitEthernet0/3 ciscoasa(config)# failover interface ip FAILOVER 1.1.1.1 255.255.255.252 standby 1.1.1.2ciscoasa(config)# interface GigabitEthernet0/2 ciscoasa(config-interface)# no shutdown ciscoasa(config)# interface GigabitEthernet0/3 ciscoasa(config-interface)# no shutdown ciscoasa(config)# failover

Configuration on the secondary unit is identical except for the first command, which designates the device as secondary:

ciscoasa(config)# 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.

ptg7987094

[ 211 ]



Figure 5-1 ASA Failover

ptg7987094

[ 212 ]



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 traffic 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 influence the primary path. STEP 6. Manually configure the OSPF neighbor, as multicast is not supported for this specific configuration.

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.

ptg7987094

[ 213 ]




ciscoasa(config)# access-list IPSEC-ACL extended permit ospfinterface outside host 20.20.20.20 ciscoasa(config)# router ospf 1 ciscoasa(config-router)# network 10.10.10.10 255.255.255.255 area 0ciscoasa(config-router)# network 20.20.20.20 255.255.255.255 area 0ciscoasa(config-router)# neighbor 20.20.20.20 interface outsideciscoasa(config)# interface GigabitEthernet0/0ciscoasa(config-if)# ospf cost 1 ciscoasa(config-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

ptg7987094

[ 214 ]



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 certificate. This option requires an identity certificate for each cluster member and one identity certificate for the cluster master. The cluster master certificate needs to be imported on all members as well.

■ Unified Client Certificate (UCC). This uses an extension attribute called Subject Alternative Name (SAN) to define an alternative trusted subject name. This option requires only one UCC certificate installed on all cluster members. Basically, the UCC certificate will have its Subject Name CN equal to the cluster master fully qualified 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 certificate for all devices.

■ Wildcard certificate. This identity certificate 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 certificate 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 reflect the certificate 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.

ptg7987094

[ 215 ]



To deploy VPN cluster, follow these steps:

STEP 1. Install UCC, wildcard, or multiple standard certificates. STEP 2. Configure the cluster IP address. STEP 3. Optionally, configure encryption. STEP 4. Configure internal and external interfaces. STEP 5. Optionally, configure member priority. STEP 6. Optionally, configure FQDN-based redirection.

UCC or wildcard certificates require the following procedure:

STEP 1. On the master, configure a trustpoint. STEP 2. On the master, import a UCC certificate. STEP 3. On the master, export the trustpoint certificate and keys as pkcs12. STEP 4. On each member, import the pkcs12.

Multiple standard X.509 certificates require the following procedure:

■ On each member, define two trustpoints: cluster and individual.

■ On each member, import a certificate for the individual trustpoint.

■ On the master, import a cluster certificate.

■ On the master, export the cluster certificate 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 .

ptg7987094

[ 216 ]




ciscoasa(config)# vpn load-balancingciscoasa(config-load-balancing)# cluster ip address 198.52.1.2ciscoasa(config-load-balancing)# cluster key CISCOciscoasa(config-load-balancing)# cluster encryptionciscoasa(config-load-balancing)# redirect-fqdn enableciscoasa(config-load-balancing)# participateciscoasa(config-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, define the priority queue on the required interfaces. STEP 2. Create a service policy. STEP 3. Define the traffic class criteria. STEP 4. Define the match criteria. STEP 5. Define an action. STEP 6. Optionally, repeat this process for other classes.

ptg7987094

[ 217 ]



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.


ciscoasa(config)# priority-queue outsideciscoasa(configpriority-queue)# tx-ring-limit 80ciscoasa(configpriority-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 traffic class and use match criteria of Tunnel Group and click Next .

■ Select the connection profile whose traffic will be matched and click Next .

■ Open the QoS tab and define actions.


ciscoasa(config)# class-map VPN-CLASS ciscoasa(config-cmap)# match dscp 46 ciscoasa(config-cmap)# match tunnel-group BASIC-CONNECTION-PROFILEciscoasa(config)# policy-map VPN-POLICY ciscoasa(config)-pmap)# class VPN-CLASSciscoasa(config)-pmap-c)# priority ciscoasa(config)# service-policy VPN-POLICY interface outside

ptg7987094

[ 218 ]



Troubleshooting ASA VPN Failover and Clustering If active/standby failover is not functioning, perform these inspections:

■ Verify failover configuration 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 profiles, 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 certificates are used, verify whether needed certificates are installed on members.

■ Verify route redistribution.

ptg7987094

[ 219 ]

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright.


CCNP Security VPN 642-648 Quick Reference Cristian Matei

Copyright © 2012 Pearson Education, Inc. Published by Cisco Press800 East 96th StreetIndianapolis, 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 quota-tions in a review.

First Release May 2012

ISBN-13: 978-1-58714-315-1

Warning and Disclaimer This digital Quick Reference is designed to provide information about the CCNP Security Certification. Every effort has been made to make this digital Quick Reference as complete and accurate as possible, but no warranty or fitness 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.

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 [email protected] . 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 particu-lar 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 [email protected] . For sales outside the United States please contact: International Sales [email protected]