CLI Book 3: Cisco ASA Series VPN CLI Configuration Guide, 9.2

Switching Off URL Entry on the Portal Page

The portal page opens when the user establishes a browser-based connection.

Prerequisites

Configure a group policy for all users who require Clientless SSL VPN access, and enable Clientless SSL VPN only for that group policy.

DETAILED STEPS

Prerequisites

• Clientless SSL VPN must be enabled on the ASA to provide remote access to the plug-ins.
• To configure SSO support for a plug-in, you install the plug-in, add a bookmark entry to display a link to the server, and specify SSO support when adding the bookmark.
• The minimum access rights required for remote use belong to the guest privilege mode.
• Plug-ins require ActiveX or Oracle Java Runtime Environment (JRE); see the compatibility matrix for version requirements.

Restrictions

Note The remote desktop protocol plug-in does not support load balancing with a session broker. Because of the way the protocol handles the redirect from the session broker, the connection fails. If a session broker is not used, the plug-in works.

• The plug-ins support single sign-on (SSO). They use the same credentials entered to open the Clientless SSL VPN session. Because the plug-ins do not support macro substitution, you do not have the options to perform SSO on different fields such as the internal domain password or on an attribute on a RADIUS or LDAP server.
• A stateful failover does not retain sessions established using plug-ins. Users must reconnect following a failover.
• If you use stateless failover instead of stateful failover, clientless features such as bookmarks, customization, and dynamic access-policies are not synchronized between the failover ASA pairs. In the event of a failover, these features do not work.

Preparing the Security Appliance for a Plug-in

Before installing a plug-in, prepare the ASA as follows:

Prerequisites

Ensure that Clientless SSL VPN is enabled on an ASA interface.

Restrictions

Do not specify an IP address as the common name (CN) for the SSL certificate. The remote user attempts to use the FQDN to communicate with the ASA. The remote PC must be able to use DNS or an entry in the System32\drivers\etc\hosts file to resolve the FQDN.

DETAILED STEPS

Go to the section that identifies the type of plug-in to provide for Clientless SSL VPN access.

• Installing Plug-ins Redistributed by Cisco
• Providing Access to a Citrix XenApp Server

Installing Plug-ins Redistributed by Cisco

Cisco redistributes the following open-source, Java-based components to be accessed as plug-ins for Web browsers in Clientless SSL VPN sessions.

Prerequisites

Ensure Clientless SSL VPN is enabled on an interface on the ASA. To do so, enter the show running-config command.

* Consult the plug-in documentation for information on deployment configuration and restrictions.

These plug-ins are available on the Cisco Adaptive Security Appliance Software Download site.

DETAILED STEPS

Note The ASA does not retain the import webvpn plug-in protocol command in the configuration. Instead, it loads the contents of the csco-config/97/plugin directory automatically. A secondary ASA obtains the plug-ins from the primary ASA.

Step 1 .

Providing Access to a Citrix XenApp Server

As an example of how to provide Clientless SSL VPN browser access to third-party plug-ins, this section describes how to add Clientless SSL VPN support for the Citrix XenApp Server Client.

With a Citrix plug-in installed on the ASA, Clientless SSL VPN users can use a connection to the ASA to access Citrix XenApp services.

A stateful failover does not retain sessions established using the Citrix plug-in. Citrix users must reauthenticate after failover.

To provide access to the Citrix plug-in, follow the procedures in the following sections.

• Preparing the Citrix XenApp Server for Clientless SSL VPN Access
• Creating and Installing the Citrix Plug-in

Preparing the Citrix XenApp Server for Clientless SSL VPN Access

You must configure the Citrix Web Interface software to operate in a mode that does not use the (Citrix) “secure gateway.” Otherwise, the Citrix client cannot connect to the Citrix XenApp Server.

Note If you are not already providing support for a plug-in, you must follow the instructions in the Preparing the Security Appliance for a Plug-in before using this section.

Creating and Installing the Citrix Plug-in

DETAILED STEPS

Step 1 Download the ica-plugin.zip file from the Cisco Software Download website.

This file contains files that Cisco customized for use with the Citrix plug-in.

Step 2 Download the Citrix Java client from the Citrix site.

In the download area of the Citrix website, select Citrix Receiver, and Receiver for Other Platforms, and click Find. Click the Receiver for Java hyperlink and download the archive..

Step 3 Extract the following files from the archive, and then add them to the ica-plugin.zip file:

• JICA-configN.jar
• JICAEngN.jar

Step 4 Ensure the EULA included with the Citrix Java client grants you the rights and permissions to deploy the client on your Web servers.

Step 5 Install the plug-in by using ASDM, or entering the following CLI command in privileged EXEC mode:

import webvpn plug-in protocol ica URL

URL is the hostname or IP address and path to the ica-plugin.zip file .

Note Adding a bookmark is required to provide SSO support for Citrix sessions. We recommend that you use URL parameters in the bookmark the provide convenient viewing, for example:

ica://10.56.1.114/?DesiredColor=4&DesiredHRes=1024&DesiredVRes=768

Step 6 Establish an SSL VPN clientless session and click the bookmark or enter the URL for the Citrix server.

Use the Client for Java Administrator’s Guide as needed.

Viewing the Plug-ins Installed on the Security Appliance

DETAILED STEPS

Information About Port Forwarding

Port forwarding lets users access TCP-based applications over a Clientless SSL VPN connection. Such applications include the following:

• Lotus Notes
• Microsoft Outlook
• Microsoft Outlook Express
• Perforce
• Sametime
• Secure FTP (FTP over SSH)
• SSH
• Telnet
• Windows Terminal Service
• XDDTS

Other TCP-based applications may also work, but we have not tested them. Protocols that use UDP do not work.

Port forwarding is the legacy technology for supporting TCP-based applications over a Clientless SSL VPN connection. You may choose to use port forwarding because you have built earlier configurations that support this technology.

Consider the following alternatives to port forwarding:

• Smart tunnel access offers the following advantages to users:

– Smart tunnel offers better performance than plug-ins.

– Unlike port forwarding, smart tunnel simplifies the user experience by not requiring the user connection of the local application to the local port.

– Unlike port forwarding, smart tunnel does not require users to have administrator privileges.

• Unlike port forwarding and smart tunnel access, a plug-in does not require the client application to be installed on the remote computer.

When configuring port forwarding on the ASA, you specify the port the application uses. When configuring smart tunnel access, you specify the name of the executable file or its path.

Prerequisites

• The remote host must be running a 32-bit version of one of the following:

– Microsoft Windows Vista, Windows XP SP2 or SP3; or Windows 2000 SP4.

– Apple Mac OS X 10.4 or 10.5 with Safari 2.0.4(419.3).

– Fedora Core 4

• The remote host must also be running Oracle Java Runtime Environment (JRE) 5 or later.
• Browser-based users of Safari on Mac OS X 10.5.3 must identify a client certificate for use with the URL of the ASA, once with the trailing slash and once without it, because of the way Safari interprets URLs. For example,

– https://example.com/

– https://example.com

For details, go to the Safari, Mac OS X 10.5.3: Changes in client certificate authentication .

• Users of Microsoft Windows Vista or later who use port forwarding or smart tunnels must add the URL of the ASA to the Trusted Site zone. To access the Trusted Site zone, they must start Internet Explorer and choose the Tools > Internet Options > Security tab. Vista (or later) users can also switch off Protected Mode to facilitate smart tunnel access; however, we recommend against this method because it increases the computer’s vulnerability to attack.
• Ensure Oracle Java Runtime Environment (JRE) 1.5.x or later is installed on the remote computers to support port forwarding (application access) and digital certificates. If JRE 1.4.x is running and the user authenticates with a digital certificate, the application fails to start because JRE cannot access the Web browser certificate store.

Restrictions

• Port forwarding supports only TCP applications that use static TCP ports. Applications that use dynamic ports or multiple TCP ports are not supported. For example, SecureFTP, which uses port 22, works over Clientless SSL VPN port forwarding, but standard FTP, which uses ports 20 and 21, does not.
• Port forwarding does not support protocols that use UDP.
• Port forwarding does not support Microsoft Outlook Exchange (MAPI) proxy. However, you can configure smart tunnel support for Microsoft Office Outlook in conjunction with Microsoft Outlook Exchange Server.
• A stateful failover does not retain sessions established using Application Access (either port forwarding or smart tunnel access). Users must reconnect following a failover.
• Port forwarding does not support connections to personal digital assistants.
• Because port forwarding requires downloading the Java applet and configuring the local client, and because doing so requires administrator permissions on the local system, it is unlikely that users will be able to use applications when they connect from public remote systems.

The Java applet displays in its own window on the end user HTML interface. It shows the contents of the list of forwarded ports available to the user, as well as which ports are active, and amount of traffic in bytes sent and received.

• The port forwarding applet displays the local port and the remote port as the same when the local IP address 127.0.0.1 is being used and cannot be updated by the Clientless SSL VPN connection from the ASA. As a result, the ASA creates new IP addresses 127.0.0.2, 127.0.0.3, and so on for local proxy IDs. Because you can modify the hosts file and use different loopbacks, the remote port is used as the local port in the applet. To connect, you can use Telnet with the hostname, without specifying the port. The correct local IP addresses are available in the local hosts file.

Configuring DNS for Port Forwarding

Port forwarding forwards the domain name of the remote server or its IP address to the ASA for resolution and connection. In other words, the port forwarding applet accepts a request from the application and forwards it to the ASA. The ASA makes the appropriate DNS queries and establishes the connection on behalf of the port forwarding applet. The port forwarding applet only makes DNS queries to the ASA. It updates the host file so that when a port forwarding application attempts a DNS query, the query redirects to a loopback address. Configure the ASA to accept the DNS requests from the port forwarding applet as follows:

Making Applications Eligible for Port Forwarding

The Clientless SSL VPN configuration of each ASA supports port forwarding lists , each of which specifies local and remote ports used by the applications for which to provide access. Because each group policy or username supports only one port forwarding list, you must group each set of ca supported into a list. To display the port forwarding list entries already present in the ASA configuration, enter the following commands:

DETAILED STEPS

Following the configuration of a port forwarding list, assign the list to group policies or usernames, as described in the next section.

Assigning a Port Forwarding List

You can add or edit a named list of TCP applications to associate with users or group policies for access over Clientless SSL VPN connections. For each group policy and username, you can configure Clientless SSL VPN to do one of the following:

• Start port forwarding access automatically upon user login.

Note These options are mutually exclusive for each group policy and username. Use only one.

Prerequisites

Before initiating the port-forward enable <list name> command, the user is required to start port forwarding manually, using Application Access > Start Applications on the Clientless SSL VPN portal page.

DETAILED STEPS

These commands are available to each group policy and username. The configuration of each group policy and username supports only one of these commands at a time, so when you enter one, the ASA replaces the one present in the configuration of the group policy or username in question with the new one, or in the case of the last command, simply removes the port-forward command from the group policy or username configuration.

Step 7

Automating Port Forwarding

To start port forwarding automatically upon user login, enter the following commands:

DETAILED STEPS

Enabling and Switching off Port Forwarding

By default, port forwarding is switched off.

DETAILED STEPS

CIFS File Access Requirement and Limitation

To access \\server\share\subfolder\personal folder , the user must have a minimum of read permission for all parent folders, including the share itself.

Use Download or Upload to copy and paste files to and from CIFS directories and the local desktop. The Copy and Paste buttons are intended for remote to remote actions only, not local to remote, or remote to local.

The CIFS browse server feature does not support double-byte character share names (share names exceeding 13 characters in length). This only affects the list of folders displayed, and does not affect user access to the folder. As a workaround, you can pre-configure the bookmark(s) for the CIFS folder(s) that use double-byte share names, or the user can enter the URL or bookmark of the folder in the format cifs://server/<long-folder-name>. For example:

Adding Support for File Access

Configure file access as follows:

Note The procedure describes how to specify the master browser and WINS servers. As an alternative, you can use ASDM to configure URL lists and entries that provide access to file shares.

Adding a share in ASDM does not require a master browser or a WINS server. However, it does not provide support for the Browse Networks link. You can use a hostname or an IP address to refer to ServerA when entering the nbns-server command. If you use a hostname, the ASA requires a DNS server to resolve it to an IP address.

DETAILED STEPS

For a complete description of these commands, see the command reference.

Limitations

• Authentication using certificates or Smart Cards is not supported for auto sign-on, since these forms of authentication do not allow the ASA in the middle.
• The XML service must be installed and configured on the XenApp and XenDesktop servers.
• Client certificate verifications, double Auth, internal passwords and CSD (all of CSD, not just Vault) are not supported when standalone mobile clients are used.

Citrix Mobile Support

A mobile user running the Citrix Receiver can connect to the Citrix server by:

• Connecting to the ASA with AnyConnect, and then connecting to the Citrix server.
• Connecting to the Citrix server through the ASA, without using the AnyConnect client. Logon credentials can include:

– A connection profile alias (also referred to as a tunnel-group alias) in the Citrix logon screen. A VDI server can have several group policies, each with different authorization and connection settings.

– An RSA SecureID token value, when the RSA server is configured. RSA support includes next token for an invalid entry, and also for entering a new PIN for an initial or expired PIN.

Supported Mobile Devices

• iPad—Citrix Receiver version 4.x or later
• iPhone/iTouch—Citrix Receiver version 4.x or later
• Android 2.x/3.x/4.0/4.1 phone—Citrix Receiver version 2.x or later
• Android 4.0 phone—Citrix Receiver version 2.x or later

Limitations

Certificate Limitations

• Certificate/Smart Card authentication is not supported as means of auto sign-on.
• Client certificate verifications and CSD are not supported
• Md5 signature in the certificates are not working because of security issue, which is a known problem on iOS: http://support.citrix.com/article/CTX132798
• SHA2 signature is not supported except for Windows, as described on the Citrix website: http://www.citrix.com/
• A key size >1024 is not supported

Other Limitations

• HTTP redirect is not supported; the Citrix Receiver application does not work with redirects.
• XML service must be installed and configured on the XenApp and XenDesktop servers.

About Citrix Mobile Receiver User Logon

The logon for mobile users connecting to the Citrix server depends on whether the ASA has configured the Citrix server as a VDI server or a VDI proxy server.

When the Citrix server is configured as a VDI server:

1. Using the AnyConnect Secure Mobility Client, connect to ASA with VPN credentials.

2. Using Citrix Mobile Receiver, connect to Citrix server with Citrix server credentials (if single-signon is configured, the Citrix credentials are not required).

When the ASA is configured as a to a VDI proxy server:

1. Using Citrix Mobile Receiver, connect to the ASA entering credentials for both the VPN and Citrix server. After the first connection, if properly configured, subsequent connections only require VPN credentials.

Configuring the ASA to Proxy a Citrix Server

You can configure the ASA to act as a proxy for the Citrix servers, so that connections to the ASA appear to the user like connections to the Citrix servers. The AnyConnect client is not required when you enable VDI proxy in ASDM. The following high-level steps show how the end user connects to Citrix.

1. A mobile user opens Citrix Receiver and connects to ASA's URL.

2. The user provides credentials for the XenApp server and the VPN credentials on the Citrix logon screen.

3. For each subsequent connection to the Citrix server, the user only needs to enter the VPN credentials.

Using the ASA as a proxy for XenApp and XenDesktop removes the requirement for a Citrix Access Gateway. XenApp server info is logged on the ASA, and displays in ASDM.

Configure the Citrix server's address and logon credentials, and assign that VDI server to a Group Policy or username. If both username and group-policy are configured, username settings override group-policy settings.

Additional Information

http://www.youtube.com/watch?v=JMM2RzppaG8 - This video describes the advantages of using that ASA as a Citrix proxy.

Assigning a VDI Server to a Group Policy

VDI servers are configured and assigned to Group Policies by:

• Adding the VDI server on the VDI Access pane, and assigning a group policy to the server.
• Adding a VDI server to the group policy.

If both username and group policy are configured, username settings take precedence over group policy. Enter the following:

The syntax options are defined as follows:

• type—Type of VDI. For a Citrix Receiver type, this value must be citrix .
• url—Full URL of the XenApp or XenDesktop server including http or https, hostname, and port number, as well as the path to the XML service.
• username—Username for logging into the virtualization infrastructure server. This value can be a clientless macro.
• password—Password for logging into the virtualization infrastructure server. This value can be a clientless macro.
• domain—Domain for logging into the virtualization infrastructure server. This value can be a clientless macro.

Using HTTPS for Clientless SSL VPN Sessions

Prerequisites

In a Web browser, users enter the ASA address in the format https://address where address is the IP address or DNS hostname of the ASA interface.

Restrictions

• You must enable Clientless SSL VPN sessions on the ASA interface that users connect to.
• You must use HTTPS to access the ASA or load-balancing cluster.

Configuring Clientless SSL VPN and ASDM Ports

From version 8.0(2), the ASA supports both Clientless SSL VPN sessions and ASDM administrative sessions simultaneously on port 443 of the outside interface. You can configure these applications on different interfaces.

Configuring Support for Proxy Servers

The ASA can terminate HTTPS connections and forward HTTP and HTTPS requests to proxy servers. These servers act as intermediaries between users and the public or private network. Requiring network access via a proxy server that the organization controls provides another opportunity for filtering, to assure secure network access and administrative control.

When configuring support for HTTP and HTTPS proxy services, you can assign preset credentials to send with each request for basic authentication. You can also specify URLs to exclude from HTTP and HTTPS requests.

Restrictions

You can specify a proxy autoconfiguration (PAC) file to download from an HTTP proxy server, however, you may not use proxy authentication when specifying the PAC file.

The ASA Clientless SSL VPN configuration supports only one http-proxy and one https-proxy command each. For example, if one instance of the http-proxy command is already present in the running configuration and you enter another, the CLI overwrites the previous instance.

Note Proxy NTLM authentication is not supported in http-proxy. Only proxy without authentication and basic authentication is supported.

Configuring SSL/TLS Encryption Protocols

Port forwarding requires the Oracle Java Runtime Environment (JRE). Port forwarding does not work when a user of Clientless SSL VPN connects with some SSL versions. Refer to the compatibility matrix for supported JRE versions.

Authenticating with Digital Certificates

SSL uses digital certificates for authentication. The ASA creates a self-signed SSL server certificate when it boots; or you can install in the ASA an SSL certificate that has been issued in a PKI context. For HTTPS, this certificate must then be installed on the client.

Restrictions

Email clients such as MS Outlook, MS Outlook Express, and Eudora lack the ability to access the certificate store.

For more information on authentication and authorization using digital certificates, see the section on using certificates and user login credentials in the general operations configuration guide.

About Installing Browser Plug-ins

A browser plug-in is a separate program that a Web browser invokes to perform a dedicated function, such as connect a client to a server within the browser window. The ASA lets you import plug-ins for download to remote browsers in Clientless SSL VPN sessions. Of course, Cisco tests the plug-ins it redistributes, and in some cases, tests the connectivity of plug-ins we cannot redistribute. However, we do not recommend importing plug-ins that support streaming media at this time.

The ASA does the following when you install a plug-in onto the flash device:

• (Cisco-distributed plug-ins only) Unpacks the jar file specified in the URL .
• Writes the file to the csco-config/97/plugin directory on the ASA file system.
• Populates the drop-down list next to the URL attributes in ASDM.
• Enables the plug-in for all future Clientless SSL VPN sessions, and adds a main menu option and an option to the drop-down list next to the Address field of the portal page.

Table 15-3 shows the changes to the main menu and address field of the portal page when you add the plug-ins described in the following sections.

Note A secondary ASA obtains the plug-ins from the primary ASA.

When the user in a Clientless SSL VPN session clicks the associated menu option on the portal page, the portal page displays a window to the interface and displays a help pane. The user can select the protocol displayed in the drop-down list and enter the URL in the Address field to establish a connection.

Note Some Java plug-ins may report a status of connected or online even when a session to the destination service is not set up. The open-source plug-in reports the status, not the ASA.

Before installing the first plug-in, you must follow the instructions in the next section.

Prerequisites

• The plug-ins do not work if the security appliance configures the clientless session to use a proxy server.

Note The remote desktop protocol plug-in does not support load balancing with a session broker. Because of the way the protocol handles the redirect from the session broker, the connection fails. If a session broker is not used, the plug-in works.

• The plug-ins support single sign-on (SSO). They use the same credentials entered to open the Clientless SSL VPN session. Because the plug-ins do not support macro substitution, you do not have the options to perform SSO on different fields such as the internal domain password or on an attribute on a RADIUS or LDAP server.
• To configure SSO support for a plug-in, you install the plug-in, add a bookmark entry to display a link to the server, and specify SSO support when adding the bookmark.
• The minimum access rights required for remote use belong to the guest privilege mode.

Requirements

• Per the GNU General Public License (GPL), Cisco redistributes plug-ins without having made any changes to them. Per the GPL, Cisco cannot directly enhance these plug-ins.
• Clientless SSL VPN must be enabled on the ASA to provide remote access to the plug-ins.
• A stateful failover does not retain sessions established using plug-ins. Users must reconnect following a failover.
• Plug-ins require that ActiveX or Oracle Java Runtime Environment (JRE) 1.4.2 (or later) is enabled on the browser. There is no ActiveX version of the RDP plug-in for 64-bit browsers.

RDP Plug-in ActiveX Debug Quick Reference

To set up and use an RDP plug-in, you must add a new environment variable.

Step 1 Right-click My Computer to access the System Properties, and choose the Advanced tab.

Step 2 On the Advanced tab, choose the environment variables button.

Step 3 In the new user variable dialog box, enter the RF_DEBUG variable.

Step 4 Verify the new Environment Variable in the user variables section.

Step 5 If you used the client computer with versions of Clientless SSL VPN before version 8.3, you must remove the old Cisco Portforwarder Control. Go to the C:/WINDOWS/Downloaded Program Files directory, right-click portforwarder control, and choose Remove .

Step 6 Clear all of the Internet Explorer browser cache.

Step 7 Launch your Clientless SSL VPN session and establish an RDP session with the RDP ActiveX Plug-in.

You can now observe events in the Windows Application Event viewer.

Preparing the Security Appliance for a Plug-in

Step 1 Ensure that Clientless SSL VPN is enabled on an ASA interface.

Step 2 Install an SSL certificate onto the ASA interface to which remote users use a fully-qualified domain name (FQDN) to connect.

Note Do not specify an IP address as the common name (CN) for the SSL certificate. The remote user attempts to use the FQDN to communicate with the ASA. The remote PC must be able to use DNS or an entry in the System32\drivers\etc\hosts file to resolve the FQDN.

Configuring the ASA to Use the New HTML File

DETAILED STEPS