Remote Access VPN Overview
Firepower Threat Defense provides secure gateway capabilities that support remote access SSL and IPsec-IKEv2 VPNs. The full tunnel client, AnyConnect Security Mobility Client, provides secure SSL and IPsec-IKEv2 connections to the security gateway for remote users. When the client negotiates an SSL VPN connection with FTD, it connects using Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS)
AnyConnect is the only client supported on endpoint devices for remote VPN connectivity to FTD 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 AnyConnect Security Mobility Client for Windows, Mac, and Linux is deployed from the secure gateway upon connectivity. The AnyConnect 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 FTD secure gateway devices.
Remote Access VPN Features
The following table describes the features of Firepower Threat Defense remote access VPN:
Description |
|
---|---|
Firepower Threat Defense remote access VPN features |
|
AAA features |
|
VPN tunneling features |
|
Remote access VPN monitoring features |
|
AnyConnect Components
AnyConnect Security Mobility Client Deployment
Your remote access VPN policy can include the AnyConnect Client Image and the AnyConnect Client Profile for distribution to connecting endpoints. Or, the client software can be distributed using other methods. See the Deploy AnyConnect chapter in the appropriate version of the Cisco AnyConnect Secure Mobility Client Administrator Guide.
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 FTD security gateway examines the client version and upgrades it as necessary.
AnyConnect Security Mobility 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.
AnyConnect Client Profile and Editor
The AnyConnect 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 AnyConnect Profile Editor. This editor is a convenient GUI-based configuration tool that is available as part of the AnyConnect software package. It is an independent program that you run outside of the FMC.
Remote Access VPN Authentication
Remote Access VPN Server Authentication
Firepower 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 FTD 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 Firepower Threat Defense or Firepower 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 FTD 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 Firepower 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 Firepower 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 Firepower 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 FTD device. If the FTD 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 FTD 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 FTD 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 FTD 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 FTD 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 FTD, the Management interface has a separate routing process and configuration from the regular interfaces used by VPN.
-
VPN authentication—the servers must be reachable over one of the regular interfaces: the Diagnostic interface or a data interface.
For regular interfaces, two routing tables are used. A management-only routing table for the Diagnostic interface as well as any other interfaces configured for management-only, and a data routing table used for data interfaces. When a route-lookup is done, the management-only routing table is checked first, and then the data routing table. The first match is chosen to reach the AAA server.
Note
If you place a AAA server on a data interface, be sure the management-only routing policies do not match traffic destined for a data interface. For example, if you have a default route through the Diagnostic interface, then traffic will never fall back to the data routing table. Use the show route management-only and show route commands to verify routing determination.
For both activities on the same AAA servers, in addition to making the servers reachable over the Management interface for user-identity handling, do one of the following to provide VPN authentication access to the same AAA servers:
-
Enable and configure the Diagnostic interface with an IP address on the same subnet as the Management interface, and then configure a route to the AAA server through this interface. The Diagnostic interface access will be used for VPN activity, the Management interface access for identity handling.
Note
When configured this way, you cannot also have a data interface on the same subnet as the Diagnostic and Management interfaces. If you want the Management interface and a data interface on the same network, for example when using the device itself as a gateway, you will not be able to use this solution because the Diagnostic interface must remain disabled.
-
Configure a route through a data interface to the AAA server. The data interface access will be used for VPN activity, the Management interface access for user-identity handling.
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 FTD device:
-
show aaa-server to display AAA server statistics.
-
show route management-only to view the management-only routing table entries.
-
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 Diagnostic and 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 .