Remote Access VPN Overview
Secure Firewall Threat Defense provides secure gateway capabilities that support remote access SSL and IPsec-IKEv2 VPNs. The full tunnel client, Secure Client, provides secure SSL and IPsec-IKEv2 connections to the security gateway for remote users. When the client negotiates an SSL VPN connection with threat defense, it connects using Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS)
Secure Client is the only client supported on endpoint devices for remote VPN connectivity to threat defense devices. The client gives remote users the benefits of an SSL or IPsec-IKEv2 VPN client without the need for network administrators to install and configure clients on remote computers. The Secure Client for Windows, Mac, and Linux is deployed from the secure gateway upon connectivity. The Secure Client apps for Apple iOS and Android devices are installed from the platform app store.
Use the Remote Access VPN policy wizard to set up SSL and IPsec-IKEv2 remote access VPNs with basic capabilities. Then, enhance the policy configuration as you want and deploy it to your threat defense secure gateway devices.
Remote Access VPN Features
The following table describes the features of Secure Firewall Threat Defense remote access VPN:
Description |
|
---|---|
Secure Firewall Threat Defense remote access VPN features |
|
AAA features |
|
VPN tunneling features |
|
Remote access VPN monitoring features |
|
Secure Client Components
Secure Client Deployment
Your remote access VPN policy can include the Secure Client Image and the Secure Client Profile for distribution to connecting endpoints. Or, the client software can be distributed using other methods. See the Deploy Cisco Secure Client chapter in the Cisco Secure Client (including AnyConnect) Administrator Guide, Release 5.
Without a previously installed client, remote users enter the IP address in their browser of an interface configured to accept SSL or IPsec-IKEv2 VPN connections. Unless the security appliance is configured to redirect http:// requests to https://, remote users must enter the URL in the form https://address. After the user enters the URL, the browser connects to that interface and displays the login screen.
After a user logs in, if the secure gateway identifies the user as requiring the VPN client, it downloads the client that matches the operating system of the remote computer. After downloading, the client installs and configures itself, establishes a secure connection, and either remains or uninstalls itself (depending on the security appliance configuration) when the connection stops. In the case of a previously installed client, after login, the threat defense security gateway examines the client version and upgrades it as necessary.
Secure Client Operation
When the client negotiates a connection with the security appliance, the client connects using Transport Layer Security (TLS), and optionally, Datagram Transport Layer Security (DTLS). DTLS avoids latency and bandwidth problems associated with some SSL connections and improves the performance of real-time applications that are sensitive to packet delays.
When an IPsec-IKEv2 VPN client initiates a connection to the secure gateway, negotiation consists of authenticating the device through Internet Key Exchange (IKE), followed by user authentication using IKE Extended Authentication (Xauth). The group profile is pushed to the VPN client and an IPsec security association (SA) is created to complete the VPN.
Secure Client Profile and Editor
The Secure Client Profile is a group of configuration parameters, stored in an XML file that the VPN client uses to configure its operation and appearance. These parameters (XML tags) include the names and addresses of host computers and settings to enable more client features.
You can configure a profile using the Secure Client Profile Editor. This editor is a convenient GUI-based configuration tool that is available as part of the Secure Client software package. It is an independent program that you run outside of the management center.
Remote Access VPN Authentication
Remote Access VPN Server Authentication
Secure Firewall Threat Defense secure gateways always use certificates to identify and authenticate themselves to the VPN client endpoint.
While you use the Remote Access VPN Policy Wizard, you can enroll the selected certificate on the targeted threat defense device. In the wizard, under Access & Certificate phase, select “Enroll the selected certificate object on the target devices” option. The certificate enrollment gets automatically initiated on the specified devices. As you complete the remote access VPN policy configuration, you can view the status of the enrolled certificate under the device certificate homepage. The status provides a clear standing as to whether the certificate enrollment was successful or not. Your remote access VPN policy configuration is now fully completed and ready for deployment.
Obtaining a certificate for the secure gateway, also known as PKI enrollment, is explained in Certificates. This chapter contains a full description of configuring, enrolling, and maintaining gateway certificates.
Remote Access VPN Client AAA
For both SSL and IPsec-IKEv2, remote user authentication is done using usernames and passwords only, certificates only, or both.
Note |
If you are using client certificates in your deployment, they must be added to your client's platform independent of the Secure Firewall Threat Defense or Secure Firewall Management Center. Facilities such as SCEP or CA Services are not provided to populate your clients with certificates. |
AAA servers enable managed devices acting as secure gateways to determine who a user is (authentication), what the user is permitted to do (authorization), and what the user did (accounting). Some examples of the AAA servers are RADIUS, LDAP/AD, TACACS+, and Kerberos. For Remote Access VPN on threat defense devices, AD, LDAP, and RADIUS AAA servers are supported for authentication.
Refer to the section Understanding Policy Enforcement of Permissions and Attributes to understand more about remote access VPN authorization.
Before you add or edit the remote access VPN policy, you must configure the Realm and RADIUS server groups you want to specify. For more information, see Create an LDAP Realm or an Active Directory Realm and Realm Directory and Add a RADIUS Server Group.
Without DNS configured, the device cannot resolve AAA server names, named URLs, and CA Servers with FQDN or Hostnames, it can only resolve IP addresses.
The login information provided by a remote user is validated by an LDAP or AD realm or a RADIUS server group. These entities are integrated with the Secure Firewall Threat Defense secure gateway.
Note |
If users authenticate with remote access VPN using Active Directory as the authentication source, users must log in using their username; the format domain\username or username@domain fails. (Active Directory refers to this username as the logon name or sometimes as sAMAccountName.) For more information, see User Naming Attributes on MSDN. If you use RADIUS to authenticate, users can log in with any of the preceding formats. |
Once authenticated via a VPN connection, the remote user takes on a VPN Identity. This VPN Identity is used by identity policies on the Secure Firewall Threat Defense secure gateway to recognize and filter network traffic belonging to that remote user.
Identity policies are associated with access control policies, which determine who has access to network resources. It is in this way that the remote user blocked or allowed to access your network resources.
For more information, see the About Identity Policies and Access Control Policies sections.
Understanding Policy Enforcement of Permissions and Attributes
The Secure Firewall Threat Defense device supports applying user authorization attributes (also called user entitlements or permissions) to VPN connections from an external authentication server and/or authorization AAA server (RADIUS) or from a group policy on the threat defense device. If the threat defense device receives attributes from the external AAA server that conflicts with those configured on the group policy, then attributes from the AAA server always take the precedence.
The threat defense device applies attributes in the following order:
-
User attributes on the external AAA server—The server returns these attributes after successful user authentication and/or authorization.
-
Group policy configured on the Firepower Threat Defense device—If a RADIUS server returns the value of the RADIUS Class attribute IETF-Class-25 (OU= group-policy) for the user, the threat defense device places the user in the group policy of the same name and enforces any attributes in the group policy that are not returned by the server.
-
Group policy assigned by the Connection Profile (also known as Tunnel Group)—The Connection Profile has the preliminary settings for the connection, and includes a default group policy applied to the user before authentication.
Note |
The threat defense device does not support inheriting system default attributes from the default group policy, DfltGrpPolicy. The attributes on the group policy assigned to the connection profile are used for the user session, if they are not overridden by user attributes or the group policy from the AAA server as indicated above. |
Understanding AAA Server Connectivity
LDAP, AD, and RADIUS AAA servers must be reachable from the threat defense device for your intended purposes: user-identity handling only, VPN authentication only, or both activities. AAA servers are used in remote access VPN for the following activities:
-
User-identity handling— the servers must be reachable over the Management interface.
On the threat defense, the Management interface has a separate routing process and configuration from data interfaces.
-
VPN authentication—the servers must be reachable over a data interface or the Management interface.
To use the Management interface, you must explicitly select Management as the source interface. Other management-only interfaces cannot be used.
To use the same AAA servers for both activities, we recommend specifying the Management interface as the source interface.
For more information about various interfaces, see Regular Firewall Interfaces.
After deployment, use the following CLI commands to monitor and troubleshoot AAA server connectivity from the threat defense device:
-
show aaa-server to display AAA server statistics.
-
show network and show network-static-routes to view the Management interface default route and static routes.
-
show route to view data traffic routing table entries.
-
ping system and traceroute system to verify the path to the AAA server through the Management interface.
-
ping interface ifname and traceroute destination to verify the path to the AAA server through the data interfaces.
-
test aaa-server authentication and test aaa-server authorization to test authentication and authorization on the AAA server.
-
clear aaa-server statistics groupname or clear aaa-server statistics protocol protocol to clear AAA server statistics by group or protocol.
-
aaa-server groupname active host hostname to activate a failed AAA server, or aaa-server groupname fail host hostname to fail a AAA server.
-
debug ldap level , debug aaa authentication , debug aaa authorization , and debug aaa accounting .