Understanding Remote Access VPNs
Security Manager supports two types of remote access VPNs: IPSec and SSL.
This section contains the following topics:
Understanding Remote Access IPSec VPNs
Remote access IPSec VPNs permit secure, encrypted connections between a company’s private network and remote users, by establishing an encrypted IPSec tunnel across the Internet using broadband cable, DSL, dial-up, or other connections.
A remote access IPSec VPN consists of a VPN client and a VPN headend device, or VPN gateway. The VPN client software resides on a user’s workstation and initiates the VPN tunnel access to the corporate network. At the other end of the VPN tunnel is the VPN gateway at the edge of the corporate site.
When a VPN client initiates a connection to the VPN gateway device, negotiation consists of authenticating the device through Internet Key Exchange (IKE), followed by user authentication using IKE Extended Authentication (Xauth). Next the group profile is pushed to the VPN client using mode configuration, and an IPsec security association (SA) is created to complete the VPN connection.
Tip |
For a remote access IPsec VPN hosted on an ASA 8.4(x) device, you have the option of configuring IKE version 2 (IKEv2). If you decide to use IKEv2, you must configure several SSL VPN policies in addition to the regular IPSec policies. The user also must use the AnyConnect 3.0+ VPN client to make an IKEv2 connection. For more information, see -Creating IPSec VPNs Using the Remote Access VPN Configuration Wizard (ASA and PIX 7.0+ Devices). |
For remote access IPSec VPNs, AAA (authentication, authorization, and accounting) is used for secure access. With user authentication, a valid user name and password must be entered before the connection is completed. User names and passwords can be stored on the VPN device itself, or on an external AAA server that can provide authentication to numerous other databases. For more information on using AAA servers, see Understanding AAA Server and Server Group Objects.
Note |
Site-to-site Easy VPN topologies use some of the same policies and policy objects that are used in remote access IPsec VPNs, but the policies are kept distinct from the remote access policies. In Easy VPN, the remote clients are hardware clients, such as routers, whereas in remote access IPSec VPNs, remote clients are workstations or other devices that use VPN client software. For more information, see Understanding Easy VPN. |
Related Topics
Understanding Remote Access SSL VPNs
An SSL VPN lets users access enterprise networks from any Internet-enabled location. Users can make clientless connections, which use only a Web browser that natively supports Secure Socket Layer (SSL) encryption, or they can make connections using a full client (such as AnyConnect) or a thin client.
Note |
SSL VPN is supported on ASA 5500 devices running software version 8.0 and later, running in single-context and router modes, on Cisco 870, 880, 890, 1800, 2800, 3700, 3800, 7200, and 7301 Series routers running software version 12.4(6)T and later, and on Cisco 1900, 2900, and 3900 Series routers running software version 15.0(1)M and later. For the 880 Series routers, the minimum software version is 12.4(15)XZ, which is mapped to 12.4(20)T in Security Manager. |
On IOS devices, remote access is provided through an SSL-enabled VPN gateway. Using an SSL-enabled Web browser, the remote user establishes a connection to the SSL VPN gateway. After the remote user is authenticated to the secure gateway via the Web browser, an SSL VPN session is established and the user can access the internal corporate network. A portal page lets users access all the resources available on the SSL VPN networks.
On ASA devices, remote users establish a secure, remote access VPN tunnel to the security appliance using the Web browser. The SSL protocol provides the secure connection between remote users and specific, supported internal resources that you configure at a central site. The security appliance recognizes connections that need to be proxied, and the HTTP server interacts with the authentication subsystem to authenticate users.
User authentication can be done using usernames and passwords, certificates, or both.
Note |
Network administrators provide user access to SSL VPN resources on a group basis instead of on an individual user basis. |
This section contains the following topics:
Remote Access SSL VPN Example
The following illustration shows how a mobile worker can access protected resources from the main office and branch offices. Site-to-site IPsec connectivity between the main and remote sites is unaltered. The mobile worker needs only Internet access and supported software (Web browser and operating system) to securely access the corporate network.
SSL VPN Access Modes
SSL VPN provides three modes of remote access on IOS routers: Clientless, Thin Client and Full Client. On ASA devices, there are two modes: Clientless (which includes Clientless and Thin Client port forwarding) and AnyConnect Client (a full client).
Clientless Access Mode
In Clientless mode, the remote user accesses the internal or corporate network using a Web browser on the client machine. No applet downloading is required.
Clientless mode is useful for accessing most content that you would expect in a Web browser, such as Internet access, databases, and online tools that employ a Web interface. It supports Web browsing (using HTTP and HTTPS), file sharing using Common Internet File System (CIFS), and Outlook Web Access (OWA) email. For Clientless mode to work successfully, the remote user’s PC must be running Windows 2000, Windows XP, or Linux operating systems.
Browser-based SSL VPN users connecting from Windows operating systems can browse shared file systems and perform the following operations: view folders, view folder and file properties, create, move, copy, copy from the local host to the remote host, copy from the remote host to the local host, and delete. Internet Explorer indicates when a Web folder is accessible. Accessing this folder launches another window, providing a view of the shared folder, on which users can perform web folder functions, assuming the properties of the folders and documents permit them.
Thin Client Access Mode
Thin Client mode, also called TCP port forwarding, assumes that the client application uses TCP to connect to a well-known server and port. In this mode, the remote user downloads a Java applet by clicking the link provided on the portal page. The Java applet acts as a TCP proxy on the client machine for the services configured on the SSL VPN gateway. The Java applet starts a new SSL connection for every client connection.
The Java applet initiates an HTTP request from the remote user client to the SSL VPN gateway. The name and port number of the internal email server is included in the HTTP request. The SSL VPN gateway creates a TCP connection to that internal email server and port.
Thin Client mode extends the capability of the cryptographic functions of the Web browser to enable remote access to TCP-based applications such as Post Office Protocol version 3 (POP3), Simple Mail Transfer Protocol (SMTP), Internet Message Access protocol (IMAP), Telnet, and Secure Shell (SSH).
Note |
The TCP port-forwarding proxy works only with Sun’s Java Runtime Environment (JRE) version 1.4 or later. A Java applet is loaded through the browser that verifies the JRE version. The Java applet refuses to run if a compatible JRE version is not detected. |
When using Thin Client mode, you should be aware of the following:
-
The remote user must allow the Java applet to download and install.
-
For TCP port-forwarding applications to work seamlessly, administrative privileges must be enabled for remote users.
-
You cannot use Thin Client mode for applications such as FTP, where the ports are negotiated dynamically. That is, you can use TCP port forwarding only with static ports.
Full Tunnel Client Access Mode
Full Tunnel Client mode enables access to the corporate network completely over an SSL VPN tunnel, which is used to move data at the network (IP) layer. This mode supports most IP-based applications, such as Microsoft Outlook, Microsoft Exchange, Lotus Notes E-mail, and Telnet. Being part of the SSL VPN is completely transparent to the applications run on the client. A Java applet is downloaded to handle the tunneling between the client host and the SSL VPN gateway. The user can use any application as if the client host was in the internal network.
The tunnel connection is determined by the group policy configuration. The SSL VPN client (SVC) or AnyConnect client is downloaded and installed to the remote client, and the tunnel connection is established when the remote user logs in to the SSL VPN gateway. By default, the client software is removed from the remote client after the connection is closed, but you can keep it installed, if required.
Note |
Full Tunnel SSL VPN access requires administrative privileges on the remote client. |
Understanding and Managing SSL VPN Support Files
SSL VPNs sometimes require supporting files that reside in the device’s flash storage. This is especially true of SSL VPNs configured on ASA devices. Supporting files include Cisco Secure Desktop (CSD) packages, AnyConnect client images, and plug-in files. Security Manager includes many of these files for your use. However, some supporting files, such as graphic files used for portal pages, or client profiles used for AnyConnect clients are not provided by Security Manager.
Typically, you need to create a File Object to specify a supporting file, and you then select the File Object when you create a policy that refers to it. You can create the File Objects that you need when you create the policies, or you can create them before you start defining policies. For more information, see Add and Edit File Object Dialog Boxes.
When you deploy policies to the devices, any supporting files referenced in your policies are copied to the device and placed in flash memory in the \csm folder. For the most part, you do not have to do any manual work to make this happen. The following are some situations where you might need to do some manual work:
-
If you are trying to discover existing SSL VPN policies, or rediscover them, file references from the SSL VPN policies must be correct. For detailed information on how supporting files are handled during policy discovery, see Discovering Remote Access VPN Policies.
-
If you have configured the ASA device in an Active/Failover configuration, you must get the supporting files onto the failover device. The supporting files are not copied over to the failover device during a failover. You have these choices for getting the files onto the failover device:
-
Manually copy the files from the \csm folder on the active unit to the failover unit.
-
After deploying the policies to the active unit, force a failover and redeploy the policies to the now-active unit.
-
-
If you are using a VPN cluster for load balancing, the same supporting files must be deployed to all devices in the cluster.
Cisco Secure Desktop (CSD) Packages
These packages are for ASA SSL VPNs. You select a package in the Dynamic Access policy. The package you select must be compatible with the ASA operating system version running on the device. When you create a Dynamic Access policy for an ASA device, the version number that is compatible with the device’s operating system is displayed in the Version field.
You can find the CSD packages in Program Files\CSCOpx\files\vms\repository\. The file names are in the form securedesktop-asa_k9-version .pkg or csd_version .pkg, where version is the CSD version number such as 3.5.1077.
Following is the CSD compatibility with ASA versions for the CSD packages shipped with Security Manager:
-
csd_3_6_181-3.6.181.pkg—ASA 8.4 or later.
-
csd_3_5_2008-3.5.2008.pkg—ASA 8.0(4) or later.
-
csd_3_5_2001-3.5.2001.pkg—ASA 8.0(4) or later.
-
csd_3_5_1077-3.5.1077.pkg—ASA 8.0(4) or later.
-
csd_3_5_841-3.5.841.pkg—ASA 8.0(4) or later.
-
csd_3_4_2048-3.4.2048.pkg—ASA 8.0(4) or later.
-
csd_3_4_1108-3.4.1108.pkg—ASA 8.0(4) or later.
-
securedesktop_asa_k9-3.3.0.151.pkg—ASA 8.0(3.1) or later.
-
securedesktop_asa-k9-3.3.0.118.pkg—ASA 8.0(3.1) or later.
-
securedesktop-asa-k9-3.2.1.126.pkg—ASA 8.0(3) or later.
-
securedesktop-asa_k9-3.2.0.136.pkg—ASA 8.0(2) or later.
For more information on CSD version compatibility with ASA versions, see the CSD release notes at http://www.cisco.com/en/US/products/ps6742/prod_release_notes_list.html and Supported VPN Platforms on Cisco.com.
For more information on creating Dynamic Access policies to specify the CSD, see Configuring Cisco Secure Desktop Policies on ASA Devices .
AnyConnect Client Images
These images are for remote access SSL and IKEv2 IPsec VPNs hosted on an ASA. The AnyConnect client is downloaded to the user’s PC and manages the client’s VPN connection. Security Manager includes several AnyConnect images, which you can find in Program Files\CSCOpx\files\vms\repository\. The package names indicate the workstation operating system and the anyconnect release number in this general pattern: anyconnect-client_OS_information -anyconnect_release .pkg. For example, anyconnect-win-3.0.0610-k9-3.0.0610.pkg is the AnyConnect 3.0(0610) client for Windows workstations. The k9 indicates that the package includes encryption. In this example, the AnyConnect release number is repeated; in some file names, the release number appears once.
Packages are available for the following workstation operating systems (OS). For specific information on which OS versions that each client supports, see the documentation for the AnyConnect client on Cisco.com.
-
Linux—Packages start with anyconnect-linux, or anyconnect-linux-64 for 64-bit versions.
-
Mac OS—Packages start with anyconnect-macosx for Mac OS X on i386 workstations, and anyconnect-macosx-powerpc for Mac OS X on Power PC workstations.
-
Windows—Packages start with anyconnect-win.
You can also download other AnyConnect client packages to the Security Manager server or your local Security Manager client and use them in remote access policies. However, Security Manager might not be able to configure newer parameters for those clients, although it might be possible to use FlexConfigs to configure newer parameters.
For more information on the AnyConnect client, its profiles, and how to configure policies to load the client onto the device, see the following topics:
Plug-in Files
These files are used as browser plug-ins. You can find plug-in files in Program Files\CSCOpx\files\vms\repository\. For complete information on the available files, see Configuring SSL VPN Browser Plug-ins (ASA).
Prerequisites for Configuring SSL VPNs
For a remote user to securely access resources on a private network behind an SSL VPN gateway, the following prerequisites must be met:
-
A user account (login name and password).
-
An SSL-enabled browser (such as Internet Explorer, Netscape, Mozilla, or Firefox).
-
An email client (such as Eudora, Microsoft Outlook, or Netscape Mail).
-
One of the following operating systems:
-
Microsoft Windows 2000 or Windows XP, with either JRE for Windows version 1.4 or later, or a browser that supports ActiveX controls.
-
Linux with JRE for Linux version 1.4 or later. To access Microsoft shared files from Linux in clientless remote access mode, Samba must also be installed.
-
Related Topics
SSL VPN Limitations
SSL VPN configurations in Security Manager are subject to the following limitations:
-
SSL VPN license information cannot be imported into Security Manager. As a result, certain command parameters, such as vpn sessiondb and max-webvpn-session-limit, cannot be validated.
-
You must configure DNS on each device in the topology in order to use clientless SSL VPN. Without DNS, the device cannot retrieve named URLs, but only URLs with IP addresses.
-
If you share your Connection Profiles policy among multiple ASA devices, bear in mind that all devices share the same address pool unless you use device-level object overrides to replace the global definition with a unique address pool for each device. Unique address pools are required to avoid overlapping addresses in cases where the devices are not using NAT.
-
If the device configuration contains an address pool for SSL VPN with a name that begins CSM_ (the naming convention used by Cisco Security Manager), Cisco Security Manager cannot detect whether the addresses in that pool overlap with the pool configured in your SSL VPN policy. (This can occur, for example, when the pool was configured by a user on a different installation of Security Manager.) This can lead to errors during deployment. Therefore, we recommend that you configure the same IP address pool as a network/host object in Security Manager and define it as part of the SSL VPN policy. This enables the proper validation to take place.
-
The same IP address and port number cannot be shared by multiple SSL VPN gateways on the same IOS device. As a result, deployment errors can occur if a duplicate gateway exists in the device configuration but was not redefined using the Security Manager interface. If such an error occurs, you must choose a different IP address and port number and redeploy.
-
If you define AAA authentication or accounting as part of an SSL VPN policy, the aaa new-model command is deployed to enable AAA services. Bear in mind that this command is not removed if you later delete the SSL VPN policy, as there might be other parts of the device configuration that require the aaa new-model command for AAA services.
Note |
In addition, we recommend that you define at least one local user on the device with a privilege level of 15. This ensures that you will not be locked out of the device if the aaa new-model command is configured without an associated AAA server. |