Configure Virtual Private Network Management
A virtual private network (VPN) connection establishes a secure tunnel between endpoints over a public network such as the Internet.
This section applies to Remote Access and Site-to-site VPNs on Adaptive Security Appliances (ASA) FDM-managed device. It describes the Internet Protocol Security (IPsec) standards to build site-to-site VPNs connection on FTD. It also describes the SSL standards that are used to build and remote access VPN connections on ASAFTD.
For additional information about Virtual Private Networks, refer to the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager.
Security Cloud Control supports the following types of VPN connections:
Introduction to Site-to-Site Virtual Private Network
A site-to-site VPN tunnel connects networks in different geographic locations. You can create site-to-site IPsec connections between managed devices and between managed devices and other Cisco or third-party peers that comply with all relevant standards. These peers can have any mix of inside and outside IPv4 and IPv6 addresses. Site-to-site tunnels are built using the Internet Protocol Security (IPsec) protocol suite and Internet Key Exchange version 2 (IKEv2). After the VPN connection is established, the hosts behind the local gateway can connect to the hosts behind the remote gateway through the secure VPN tunnel.
Simplifying Site-to-Site VPNs with Security Cloud Control
Site-to-Site VPNs are a reliable solution for securely connecting multiple networks over the internet. To make this process easier and more efficient, Security Cloud Control provides a consolidated Site-to-Site VPN wizard. This intuitive tool is designed to simplify the creation and management of secure VPN tunnels while reducing the complexity involved in traditional VPN configurations.
The Site-to-Site VPN wizard provides a single, unified interface for configuring VPN tunnels across a variety of managed devices. This consistency ensures a streamlined experience for administrators, regardless of the specific device or network environment. By offering a centralized and intuitive configuration process, the wizard helps organizations enhance operational efficiency, reduce errors, and maintain a high level of security in their network infrastructure.
The table below specifies the permitted site-to-site VPN configurations for the managed devices.
|
FDM-managed |
Cloud-delivered Firewall Management Center-managed Firewall Threat Defense |
Secure Firewall ASA |
Multicloud Defense |
|
|---|---|---|---|---|
|
FDM-managed |
No |
No |
No |
|
|
Cloud-delivered Firewall Management Center-managed Firewall Threat Defense |
No |
|||
|
Secure Firewall ASA |
No |
|||
|
Multicloud Defense |
No |
No |
Site-to-Site VPN Concepts
VPN Topology
To create a new site-to-site VPN topology you must provide a unique name, specify a topology type, choose the IKE version that is used for IPsec IKEv1 or IKEv2, or both and authentication method. Once configured, you deploy the topology to ASAFTD.
IPsec and IKE Protocols
In Security Cloud Control, site-to-site VPNs are configured based on IKE policies and IPsec proposals that are assigned to VPN topologies. Policies and proposals are sets of parameters that define the characteristics of a site-to-site VPN, such as the security protocols and algorithms that are used to secure traffic in an IPsec tunnel. Several policy types may be required to define a full configuration image that can be assigned to a VPN topology.
Authentication VPN Tunnels
For authentication of VPN connections, configure a pre-shared key in the topology on each device. Pre-shared keys allow a secret key, used during the IKE authentication phase, to be shared between two peers.
Virtual Tunnel Interface (VTI)
Security Cloud Control does not currently support the management, monitoring, or use of Virtual Tunnel Interface (VTI) tunnels on FTD. Devices with configured VTI tunnels can be onboarded to Security Cloud Control but it ignores the VTI interfaces. If a security zone or static route references a VTI, Security Cloud Control reads the security zone and static route without the VTI reference.
VPN Encryption Domain
There are two methods to define the VPN's encryption domain: route-based or policy-based traffic selectors.
-
Policy-Based: The encryption domain is set to allow any traffic which enters the IPSec tunnel. IPSec Local and remote traffic selectors are set to 0.0.0.0. This means that any traffic routed into the IPSec tunnel is encrypted regardless of the source/destination subnet. ASA supports policy-based VPN with crypto maps.
-
Route-Based: The encryption domain is set to encrypt only specific IP ranges for both source and destination. It creates a virtual IPsec interface, and whatever traffic enters that interface is encrypted and decrypted. ASA supports route-based VPN with the use of Virtual Tunnel Interfaces (VTIs).
About Extranet Devices
You can add non-Cisco or unmanaged Cisco devices to a VPN topology as "Extranet" devices with either static or dynamic IP addresses.
-
Non-Cisco Device: You cannot use Security Cloud Control to create and deploy configurations to non-Cisco devices.
-
Unmanaged Cisco Device: Cisco device not managed by your organization, such as spokes in networks managed by other organizations within your company, or a connection to a service provider or partner's network.
About Global IKE Policies
Internet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).
The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for other applications, such as IPsec. Both phases use proposals when they negotiate a connection. An IKE proposal is a set of algorithms that two peers use to secure the negotiation between them. IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters are used to protect subsequent IKE negotiations.
IKE policy objects define the IKE proposals for these negotiations. The objects that you enable are the ones used when the peers negotiate a VPN connection: you cannot specify different IKE policies per connection. The relative priority of each object determines which of these policies are tried first, with the lower number being a higher priority. The connection is not established if the negotiation fails to find a policy that both peers can support.
To define the global IKE policy, you select which objects to enable for each IKE version. If the pre-defined objects do not satisfy your requirements, create new policies to enforce your security policy.
Managing IKEv1 Policies
About IKEv1 Policy
Internet Key Exchange (IKE) version 1 policy objects contain the parameters required for IKEv1 policies when defining VPN connections. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).
There are several pre-defined IKEv1 policies. If any suit your needs, simply enable them by clicking the State toggle. You can also create new policies to implement other combinations of security settings. You cannot edit or delete system-defined objects.
Create an IKEv1 Policy
Internet Key Exchange (IKE) version 1 policy objects contain the parameters required for IKEv1 policies when defining VPN connections. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).
There are several pre-defined IKEv1 policies. If any suit your needs, simply enable them by clicking the State toggle. You can also create new policies to implement other combinations of security settings. You cannot edit or delete system-defined objects.
The following procedure explains how you can create and edit objects directly through the Objects page. You can also create an IKEv1 policy while editing the IKE settings in a Site-to-Site VPN connection by clicking the Create New IKEv1 Policy link shown in the object list.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
In the left pane, click Objects. |
|
Step 3 |
Do one of these things:
|
|
Step 4 |
Enter an object name, up to 128 characters. |
|
Step 5 |
Configure the IKEv1 properties.
|
|
Step 6 |
Click Add. |
Managing IKEv2 Policies
About IKEv2 Policy
Internet Key Exchange (IKE) version 2 policy objects contain the parameters required for IKEv2 policies when defining VPN connections. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).
There are several pre-defined IKEv2 policies. If any suit your needs, simply enable them by clicking the State toggle. You can also create new policies to implement other combinations of security settings. You cannot edit or delete system-defined objects.
Create an IKEv2 Policy
Internet Key Exchange (IKE) version 2 policy objects contain the parameters required for IKEv2 policies when defining VPN connections. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).
There are several pre-defined IKEv2 policies. If any suit your needs, simply enable them by clicking the State toggle. You can also create new policies to implement other combinations of security settings. You cannot edit or delete system-defined objects.
The following procedure explains how you can create and edit objects directly through the Objects page. You can also create an IKEv2 policy while editing the IKE settings in a Site-to-Site VPN connection by clicking the Create New IKEv2 Policy link shown in the object list.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
In the left pane, click Objects. |
|
Step 3 |
Do one of these things:
|
|
Step 4 |
Enter an object name, up to 128 characters. |
|
Step 5 |
Configure the IKEv2 properties.
|
|
Step 6 |
Click Add. |
About IPsec Proposals
IPsec is one of the most secure methods for setting up a VPN. IPsec provides data encryption at the IP packet level, offering a robust security solution that is standards-based. With IPsec, data is transmitted over a public network through tunnels. A tunnel is a secure, logical communication path between two peers. Traffic that enters an IPsec tunnel is secured by a combination of security protocols and algorithms called a transform set. During the IPsec security association (SA) negotiation, peers search for a transform set that is the same at both peers.
There are separate IPsec proposal objects based on the IKE version, IKEv1, or IKEv2:
-
When you create an IKEv1 IPsec proposal, you select the mode in which IPsec operates, and define the required encryption and authentication types. You can select single options for the algorithms. If you want to support multiple combinations in a VPN, create and select multiple IKEv1 IPsec Proposal objects.
-
When you create an IKEv2 IPsec proposal, you can select all of the encryption and hash algorithms allowed in a VPN. The system orders the settings from the most secure to the least secure and negotiates with the peer until a match is found. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.
The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec proposals. It provides authentication, encryption, and antireplay services. ESP is IP protocol type 50.
 Note |
We recommend using both encryption and authentication on IPsec tunnels. |
Managing an IKEv1 IPsec Proposal Object
IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel. There are separate objects for IKEv1 and IKEv2. Currently, Security Cloud Control supports IKEv1 IPsec proposal objects.
The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec proposals. It provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50.
Note |
We recommend using both encryption and authentication on IPsec tunnels. |
Create an IKEv1 IPsec Proposal Object
IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel. There are separate objects for IKEv1 and IKEv2. Currently,Security Cloud Control supports IKEv1 IPsec proposal objects.
The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec proposals. It provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50.
Note |
We recommend using both encryption and authentication on IPsec tunnels. |
There are several pre-defined IKEv1 IPsec proposals. You can also create new proposals to implement other combinations of security settings. You cannot edit or delete system-defined objects.
The following procedure explains how you can create and edit objects directly through the Objects page. You can also create IKEv1 IPsec Proposals objects while editing the IKEv1 IPsec settings in a Site-to-Site VPN connection by clicking the Create New IKEv1 Proposal link shown in the object list.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Do one of these things:
|
|
Step 3 |
Enter an object name for the new object. |
|
Step 4 |
Select the Mode in which the IKEv1 IPsec Proposal object operates.
|
|
Step 5 |
Select the ESP Encryption (Encapsulating Security Protocol encryption) algorithm for this proposal. For more information, see Deciding Which Encryption Algorithm to Use. |
|
Step 6 |
Select the ESP Hash or integrity algorithm to use for authentication. For more information, see Deciding Which Hash Algorithms to Use. |
|
Step 7 |
Click Add. |
Managing an IKEv2 IPsec Proposal Object
IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel.
When you create an IKEv2 IPsec proposal, you can select all of the encryption and hash algorithms allowed in a VPN. The system orders the settings from the most secure to the least secure and negotiates with the peer until a match is found. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.
Create or Edit an IKEv2 IPsec Proposal Object
There are several pre-defined IKEv2 IPsec proposals. You can also create new proposals to implement other combinations of security settings. You cannot edit or delete system-defined objects.
The following procedure explains how you can create and edit objects directly through the Objects page. You can also create IKEv2 IPsec Proposals objects while editing the IKEv2 IPsec settings in a VPN connection by clicking the Create New IPsec Proposal link shown in the object list.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Do one of these things:
|
|
Step 3 |
Enter an object name for the new object. |
|
Step 4 |
Configure the IKE2 IPsec proposal objects:
|
|
Step 5 |
Click Add. |
Encryption and Hash Algorithms Used in VPN
Because a VPN tunnel typically traverses a public network, most likely the Internet, you need to encrypt the connection to protect the traffic. You define the encryption and other security techniques to apply using IKE policies and IPsec proposals.
If your device license allows you to apply strong encryption, there is a wide range of encryption and hash algorithms, and Diffie-Hellman groups, from which to choose. However, as a general rule, the stronger the encryption that you apply to the tunnel, the worse the system performance. Find a balance between security and performance that provides sufficient protection without compromising efficiency.
We cannot provide specific guidance on which options to choose. If you operate within a larger corporation or other organization, there might already be defined standards that you need to meet. If not, take the time to research the options.
The following topics explain the available options:
Deciding Which Encryption Algorithm to Use
When determining which encryption algorithms to use for the IKE policy or IPsec proposal, your choice is limited to algorithms supported by the devices in the VPN.
For IKEv2, you can configure multiple encryption algorithms. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.
For IPsec proposals, the algorithm is used by the Encapsulating Security Protocol (ESP), which provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50. In IKEv1 IPsec proposals, the algorithm name is prefixed with ESP.
If your device license qualifies for strong encryption, you can choose from the following encryption algorithms. If you are not qualified for strong encryption, you can select DES only.
-
AES-GCM - (IKEv2 only.) Advanced Encryption Standard in Galois/Counter Mode is a block cipher mode of operation providing confidentiality and data-origin authentication and provides greater security than AES. AES-GCM offers three different key strengths: 128-, 192-, and 256-bit keys. A longer key provides higher security but a reduction in performance. GCM is a mode of AES that is required to support NSA Suite B. NSA Suite B is a set of cryptographic algorithms that devices must support to meet federal standards for cryptographic strength.
-
AES-GMAC - (IKEv2 IPsec proposals only.) Advanced Encryption Standard Galois Message Authentication Code is a block cipher mode of operation providing only data-origin authentication. It is a variant of AES-GCM that allows data authentication without encrypting the data. AES-GMAC offers three different key strengths: 128-, 192-, and 256-bit keys.
-
AES - Advanced Encryption Standard is a symmetric cipher algorithm that provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192-, and 256-bit keys. A longer key provides higher security but a reduction in performance.
-
DES - Data Encryption Standard, which encrypts using 56-bit keys, is a symmetric secret-key block algorithm. If your license account does not meet the requirements for export controls, this is your only option. It is faster than 3DES and uses fewer system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, choose DES.
-
3DES - Triple DES, which encrypts three times using 56-bit keys, is more secure than DES because it processes each block of data three times with a different key. However, it uses more system resources and is slower than DES.
-
NULL - A null encryption algorithm provides authentication without encryption. This is typically used for testing purposes only.
Deciding Which Hash Algorithms to Use
In IKE policies, the hash algorithm creates a message digest, which is used to ensure message integrity. In IKEv2, the hash algorithm is separated into two options, one for the integrity algorithm, and one for the pseudo-random function (PRF).
In IPsec proposals, the hash algorithm is used by the Encapsulating Security Protocol (ESP) for authentication. In IKEv2 IPsec Proposals, this is called the integrity hash. In IKEv1 IPsec proposals, the algorithm name is prefixed with ESP-, and there is also an -HMAC suffix (which stands for "hash method authentication code").
For IKEv2, you can configure multiple hash algorithms. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.
You can choose from the following hash algorithms:
-
SHA (Secure Hash Algorithm) - Standard SHA (SHA-1) produces a 160-bit digest. SHA is more resistant to brute-force attacks than MD5. However, it is also more resource-intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.
-
The following SHA-2 options, which are even more secure, are available for IKEv2 configurations. Choose one of these if you want to implement the NSA Suite B cryptography specification.
-
SHA-256 - Specifies the Secure Hash Algorithm SHA-2 with the 256-bit digest.
-
SHA-384 - Specifies the Secure Hash Algorithm SHA-2 with the 384-bit digest.
-
SHA-512 - Specifies the Secure Hash Algorithm SHA-2 with the 512-bit digest.
-
-
MD5 (Message Digest 5) - Produces a 128-bit digest. MD5 uses less processing time for overall faster performance than SHA, but it is considered to be weaker than SHA.
-
Null or None (NULL, ESP-NONE) - (IPsec Proposals only.) A null Hash Algorithm; this is typically used for testing purposes only. However, you should choose the null integrity algorithm if you select one of the AES-GCM/GMAC options as the encryption algorithm. Even if you choose a non-null option, the integrity hash is ignored for these encryption standards.
Deciding Which Diffie-Hellman Modulus Group to Use
You can use the following Diffie-Hellman key derivation algorithms to generate IPsec security association (SA) keys. Each group has different size modules. A larger modulus provides higher security but requires more processing time. You must have a matching modulus group on both peers.
If you select AES encryption, to support the large key sizes required by AES, you should use Diffie-Hellman (DH) Group 5 or higher. IKEv1 policies do not support all of the groups listed below.
To implement the NSA Suite B cryptography specification, use IKEv2 and select one of the elliptic curves Diffie-Hellman (ECDH) options: 19, 20, or 21. Elliptic curve options and groups that use 2048-bit modulus are less exposed to attacks such as Logjam.
For IKEv2, you can configure multiple groups. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.
-
2 - Diffie-Hellman Group 2: 1024-bit modular exponential (MODP) group. This option is no longer considered good protection.
-
5 - Diffie-Hellman Group 5: 1536-bit MODP group. Formerly considered good protection for 128-bit keys, this option is no longer considered good protection.
-
14 - Diffie-Hellman Group 14: 2048-bit modular exponential (MODP) group. Considered good protection for 192-bit keys.
-
19 - Diffie-Hellman Group 19: National Institute of Standards and Technology (NIST) 256-bit elliptic curve modulo a prime (ECP) group.
-
20 - Diffie-Hellman Group 20: NIST 384-bit ECP group.
-
21 - Diffie-Hellman Group 21: NIST 521-bit ECP group.
-
24 - Diffie-Hellman Group 24: 2048-bit MODP group with 256-bit prime order subgroup. This option is no longer recommended.
Deciding Which Authentication Method to Use
You can use the following methods to authenticate the peers in a site-to-site VPN connection.
Preshared Keys
Preshared keys are secret key strings configured on each peer in the connection. These keys are used by IKE during the authentication phase. For IKEv1, you must configure the same preshared key on each peer. For IKEv2, you can configure unique keys on each peer.
Preshared keys do not scale well compared to certificates. If you need to configure a large number of site-to-site VPN connections, use the certificate method instead of the preshared key method.
Site-to-Site VPN Configuration for FDM-Managed
Security Cloud Control supports these aspects of site-to-site VPN functionality on FDM-managed devices:
-
Both IPsec IKEv1 & IKEv2 protocols are supported.
-
Automatic or manual pre-shared keys for authentication.
-
IPv4 and IPv6. All combinations of inside and outside are supported.
-
IPsec IKEv2 site-to-site VPN topologies provide configuration settings to comply with Security Certifications.
-
Static and dynamic interfaces.
-
Support for the dynamic IP address for the extranet device as an endpoint.
Configure Site-to-Site VPN Connections with Dynamically Addressed Peers
Security Cloud Control allows you to create a site-to-site VPN connection between peers when one of the peers' VPN interface IP address is not known or when the interface obtains its address from a DHCP server. Any dynamic peer whose preshared key, IKE settings, and IPsec configurations match with another peer can establish a site-to-site VPN connection.
Consider two peers, A and B. The static peer is a device whose IP address of its VPN interface is fixed and a dynamic peer is a device whose IP address of the VPN interface is not known or has a temporary IP address.
The following use cases describe different scenarios for establishing a secure site-to-site VPN connection with dynamically-addressed peers:
-
A is a static peer, and B is a dynamic peer or conversely.
-
A is a static peer, and B is a dynamic peer with a resolved IP address from the DHCP server or conversely. You can select Bind VPN to the assigned IP to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.
-
A and B are dynamic with resolved IP addresses from the DHCP server. In such a case, you must select Bind VPN to the assigned IP for at least one peer to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.
-
A is a dynamic peer, and B is an extranet device with a static or dynamic IP address.
-
A is a dynamic peer with a resolved IP address from the DHCP server, and B is an Extranet device with a static or dynamic IP address. You can select Bind VPN to the assigned IP to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.
Important |
If you select Bind VPN to the assigned IP, the VPN binds statically to the DHCP assigned IP address. However, this dynamic interface can receive many new IP addresses after the peer restarts. Although the VPN tunnel updates the new IP address, the other peer is not updated with the new configuration. You must deploy the site-to-site configuration again for out-of-band changes on the other peer. |
Note |
If the IP address of the interface is changed by using a local manager like Firewall Device Manager, the Configuration Status of that peer in Security Cloud Control shows "Conflict Detected". When you resolve this out-of-band change, the Configuration Status of the other peer changes to the "Not Synced" state. You must deploy the Security Cloud Control configuration to the device which is in "Not Synced" state. |
Typically, the dynamic peer must be the one that initiates the connection as the other peer would not know the IP address of the dynamic peer. When the remote peer attempts to establish the connection, the other peer validates the connection using the preshared key, IKE settings, and IPsec configurations.
Because the VPN connection is established only after the remote peer initiates the connection, any outbound traffic that matches access control rules that allow traffic in the VPN tunnel will be dropped until that connection is established. This ensures that data does not leave your network without the appropriate encryption and VPN protection.
Note |
A site-to-site VPN connection cannot be configured in the following scenarios: |
-
If both peers have DHCP assigned IP addresses.
-
Workaround: You can configure a site-to-site VPN, if one of the peers has a resolved IP address from the DHCP server. In such a case, you must select Bind VPN to the assigned IP to configure site-to-site VPN.
-
-
If a device has more than one dynamic peer connection.
-
Workaround: You can configure a site-to-site VPN by performing the following steps:
-
Consider three devices A, B, and C.
-
Configure site-to-site VPN connection between A (static peer) and B (dynamic peer).
-
Configure site-to-site VPN connection between A and C (dynamic peer) by creating an Extranet device. Assign the static VPN interface IP address of A to the Extranet device and establish a connection with C.
-
-
FDM-Managed Device Site-to-Site VPN Guidelines and Limitations
-
Security Cloud Control does not support a crypto-acl to design the interesting traffic for S2S VPN. It only supports protected networks.
-
Security Cloud Control does not currently support the management, monitoring, or use of Virtual Tunnel Interface (VTI) tunnels on ASA or FDM-managed devices. Devices with configured VTI tunnels can be onboarded to Security Cloud Control but it ignores the VTI interfaces. If a security zone or static route references a VTI, Security Cloud Control reads the security zone and static route without the VTI reference. Security Cloud Control support for VTI tunnels is coming soon.
-
Whenever IKE ports 500/4500 are in use or when there are some PAT translations that are active, the site-to-site VPN cannot be configured on the same ports as it fails to start the service on those ports.
-
Transport mode is not supported only tunnel mode. IPsec tunnel mode encrypts the entire original IP datagram which becomes the payload in a new IP packet. Use tunnel mode when the firewall is protecting traffic to and from hosts positioned behind a firewall. Tunnel mode is the normal way regular IPsec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.
-
For this release, only PTP topology is supported, containing one or more VPN tunnels. Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.
Create a Site-To-Site VPN Tunnel Between FDM-managed Devices
Note that an FDM-managed device has the capability to establish a secure VPN tunnel either with another FDM-managed device or with an extranet device.
Procedure
|
Step 1 |
In the left pane, choose . |
||||
|
Step 2 |
Click the Create Tunnel ( |
||||
|
Step 3 |
In the Peer Selection area, provide the following information:
|
||||
|
Step 4 |
Click Next. |
||||
|
Step 5 |
In the Peer Details area, provide the following information:
|
||||
|
Step 6 |
Click Next. |
||||
|
Step 7 |
In the IKE Settings area, choose the IKE versions to use during Internet Key Exchange (IKE) negotiations and specify the privacy configurations: For more information on the IKE policies, see Configuring the Global IKE Policy.
|
||||
|
Step 8 |
Click Next. |
||||
|
Step 9 |
In the IPSec Settings area, specify the IPSec configurations for peer 1 and peer 2. The corresponding IKEV proposals are available depending on the selection that is made in the IKE Settings step. For more information on the IPSec settings, see the About IPsec Proposals.
|
||||
|
Step 10 |
In the Finish area, you will find a summary of the configurations you have completed. Read the configuration and then click Submit if you're satisfied. |
Configure Networking for Protected Traffic Between the Site-To-Site Peers
After completing the configuring of the Site-To-Site connection, make sure that you perform the following configuration for VPN to function on all targeted devices.
Procedure
|
Step 1 |
Configure AC policies: Configure AC policies for permitting bidirectional traffic between the protected networks behind both peers. These policies help the packets to traverse to the intended destination without being dropped.
After creating AC policies on one device, you must create similar policies on its peer. |
||
|
Step 2 |
If NAT is configured on either of the peer devices, you need to configure the NAT exempt rules manually. See Exempting Site-to-Site VPN Traffic from NAT. |
||
|
Step 3 |
Configure routing for receiving the return VPN traffic on each peer.
After configuring routing settings on one device, you must configure similar settings on its peer. |
Edit an Existing Security Cloud Control Site-To-Site VPN
The advanced configuration wizard is used by default to modify an existing site-to-site VPN configuration.
Procedure
|
Step 1 |
In the navigation pane, choose . |
||
|
Step 2 |
In the left pane, choose . |
||
|
Step 3 |
Select the desired site-to-site VPN tunnel that you want to edit. |
||
|
Step 4 |
In the Actions pane, click Edit.
|
||
|
Step 5 |
In the Peer Devices section, you can modify the following device configurations: Configuration Name, VPN Access Interface, and Protected Networks.
|
||
|
Step 6 |
In the IKE Settings section, you can modify the following IKEv2 policies configurations:
|
||
|
Step 7 |
In the IPSec Settings section, you can modify the following IPSec configurations:
|
button and enter the appropriate pre-shared keys for the devices.
The Point to point VPN is modified and updated with all the changes you have made.
Delete a Security Cloud Control Site-To-Site VPN Tunnel
Procedure
|
Step 1 |
In the left pane, choose VPN> Site-to-Site VPN. |
|
Step 2 |
In the left pane, click to open the VPN page. |
|
Step 3 |
Select the desired site-to-site VPN tunnel that you want to delete. |
|
Step 4 |
In the Actions pane on the right, click Delete. |
The selected site-to-site VPN tunnel is deleted.
Exempt Site-to-Site VPN Traffic from NAT
When you have a site-to-site VPN connection defined on an interface, and you also have NAT rules for that interface, you can optionally exempt the traffic on the VPN from the NAT rules. You might want to do this if the remote end of the VPN connection can handle your internal addresses.
When you create the VPN connection, you can select the NAT Exempt option to create the rules automatically. However, this works only if your local protected network is connected through a single routed interface (not a bridge group member). If instead, the local networks in the connection reside behind two or more routed interfaces or one or more bridge group members, you need to configure the NAT exempt rules manually.
To exempt VPN traffic from NAT rules, you create an identity manual NAT rule for the local traffic when the destination is the remote network. Then, apply NAT to the traffic when the destination is anything else (for example, the Internet). If you have more than one interface for the local network, create rules for each interface. Also, consider the following suggestions:
-
If there is more than one local network in the connection, create a network object group to hold the objects that define the networks.
-
If you are including both IPv4 and IPv6 networks in the VPN, create separate identity NAT rules for each.
Consider the following example, which shows a site-to-site tunnel connecting the Boulder and San Jose offices. For traffic that you want to go to the Internet (for example from 10.1.1.6 in Boulder to www.example.com), you need a public IP address provided by NAT to access the Internet. The below example uses interface Port Address Translation (PAT) rules. However, for traffic that you want to go over the VPN tunnel (for example from 10.1.1.6 in Boulder to 10.2.2.78 in San Jose), you do not want to perform NAT; you need to exempt that traffic by creating an identity NAT rule. Identity NAT translates an address to the same address.
The following example explains the configuration for Firewall1 (Boulder). The example assumes that the inside interface is a bridge group, so you need to write the rules for each member interface. The process is the same if you have a single or multiple routed inside interfaces.
Note |
This example assumes IPv4 only. If the VPN also includes IPv6 networks, create parallel rules for IPv6. Note that you cannot implement IPv6 interface PAT, so you need to create a host object with a unique IPv6 address to use for PAT. |
Procedure
|
Step 1 |
Create objects to define the various networks.
|
|
Step 2 |
Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder).
|
|
Step 3 |
Configure manual dynamic interface PAT when going to the Internet for the inside Boulder network on Firewall1 (Boulder). Note: There might already be dynamic interface PAT rules for the inside interfaces, covering any IPv4 traffic, as these are created by default during initial configuration. However, the configuration is shown here for completeness. Before completing these steps, check whether a rule already exists that covers the inside interface and network, and skip this step if it does.
|
|
Step 4 |
Deploy configuration changes to Security Cloud Control. For more information, see Deploy Configuration Changes from Security Cloud Control to FTD. |
|
Step 5 |
Deploy configuration changes to Security Cloud Control. For more information, see Deploy Configuration Changes Made Using the Security Cloud Control GUI. |
|
Step 6 |
If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.
|
.
Configure Static and Default Routes for FDM-Managed Devices
Define static routes on an FDM-managed device so it knows where to send packets bound for networks not directly connected to the interfaces on the system.
Consider creating a default route. This is the route for network 0.0.0.0/0. This route defines where to send packets whose egress interface cannot be determined by existing NAT translations, static NAT rules, or other static routes.
You might need other static routes if the default gateway cannot be used to get to all networks. For example, the default route is usually an upstream router on the outside interface. If there are additional inside networks that are not directly connected to the device, and they cannot be accessed through the default gateway, you need static routes for each of those inside networks.
You cannot define static routes for the networks that are directly connected to system interfaces. The system automatically creates these routes.
Site-to-Site VPN Configuration for Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense
You can create site-to-site IPsec connections between a Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense device and the following devices:
-
Firewall Threat Defense
-
Secure Firewall ASA
-
Multicloud Defense
Create a Site-to-Site VPN Tunnel Between Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense Devices
Use the following procedure to create a site-to-site VPN tunnel between two Firewall Threat Defense devices managed by Cloud-Delivered Firewall Management Center.
Before you begin
There should not be any pending deployments on the Firewall Threat Defense device.
Procedure
|
Step 1 |
In the left pane, choose . |
||||
|
Step 2 |
Click the Create Tunnel ( |
||||
|
Step 3 |
In the Peer Selection area, provide the following information:
|
||||
|
Step 4 |
Click Next. |
||||
|
Step 5 |
In the Peer Details area, provide the following information:
|
||||
|
Step 6 |
Click Next. |
||||
|
Step 7 |
In the IKE Settings area, choose the IKE versions to use during Internet Key Exchange (IKE) negotiations and specify the privacy configurations: For more information on the IKE policies, see Configuring the Global IKE Policy.
|
||||
|
Step 8 |
Click Next. |
||||
|
Step 9 |
In the IPSec Settings area, specify the IPSec configurations for peer 1 and peer 2. The corresponding IKEV proposals are available depending on the selection that is made in the IKE Settings step. For more information on the IPSec settings, see the About IPSec Proposals.
|
||||
|
Step 10 |
In the Finish area, you will find a summary of the configurations you have completed. Read the configuration and then click Submit if you're satisfied. |
||||
|
Step 11 |
|||||
|
Step 12 |
Perform the following steps to deploy the configuration to a Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense device:
|
Create a Site-to-Site VPN Tunnel Between Cloud-delivered Firewall Management Center-Managed Firewall Threat Defense and Multicloud Defense
You can create site-to-site IPsec connections between a Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense and Multicloud Defense from the Security Cloud Control dashboard that complies with all relevant standards. After the VPN connection is established, the hosts behind the firewall can connect to the hosts behind the gateway through the secure VPN tunnel.
Multicloud Defense currently supports Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), and Oracle OCI cloud accounts.
Use the following procedure to create a VPN tunnel between a cloud-delivered Firewall Management Center-managed Firewall Threat Defense device and Multicloud Defense from the Security Cloud Control dashboard:
Before you begin
Ensure that the following prerequisites are met:
-
The cloud-delivered Firewall Management Center-managed Firewall Threat Defense device must not have any pending changes.
-
The Multicloud Defense must be onboarded to Security Cloud Control. See Connect Cloud Account.
-
The Multicloud Defense Gateway must be in the Active state.
-
The Multicloud Defense Gateway must be VPN enabled. See Enable VPN within the gateway.
-
Read the Multicloud Defense Gateway prerequisites and limitations for more information.
Procedure
|
Step 1 |
In the navigation pane, choose . |
|
Step 2 |
Click the Create Tunnel ( |
|
Step 3 |
In the Peer Selection area, provide the following information:
|
|
Step 4 |
Click Next. |
|
Step 5 |
In the Peer Details area, provide the following information:
|
|
Step 6 |
Click Next. |
|
Step 7 |
In the Tunnel Details area, provide the following information:
|
|
Step 8 |
Click Next. |
|
Step 9 |
In the IKE Settings area, click Add IKEv2 and add the IKE version for the Internet Key Exchange (IKE) negotiations and specify the privacy configurations. |
|
Step 10 |
Click Next. |
|
Step 11 |
In the IPSec Settings area, click Add IKEv2 IPSec Proposals and select the IKE IPSec configuration. The proposals are available depending on the selection that is made in the IKE Settings step. See Configuring IPSec Proposals. |
|
Step 12 |
Click Next. |
|
Step 13 |
In the Finish area, review the configuration and continue further only if you’re satisfied with the configuration. |
|
Step 14 |
Click Submit. The configurations are pushed to the Multicloud Defense Gateway. |
|
Step 15 |
Perform the following steps to deploy the configuration to a cloud-delivered Firewall Management Center-managed Firewall Threat Defense device:
|
Create a Site-to-Site VPN Between Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense and Secure Firewall ASA
Before you begin
There should not be any pending deployments on the Firewall Threat Defense device.
Procedure
|
Step 1 |
In the navigation pane, choose . |
||||
|
Step 2 |
Click the Create Tunnel ( |
||||
|
Step 3 |
In the Peer Selection area, provide the following information:
|
||||
|
Step 4 |
Click Next. |
||||
|
Step 5 |
In the Peer Details area, provide the following information:
|
||||
|
Step 6 |
Click Next. |
||||
|
Step 7 |
In the Tunnel Details area, provide the following information:
|
||||
|
Step 8 |
Click Next. |
||||
|
Step 9 |
In the IKE Settings area, choose the IKE versions to use during Internet Key Exchange (IKE) negotiations and specify the privacy configurations: For more information on the IKE policies, see Configuring the Global IKE Policy.
|
||||
|
Step 10 |
Click Next. |
||||
|
Step 11 |
In the IPSec Settings area, specify the IPSec configurations for peer 1 and peer 2. The corresponding IKEV proposals are available depending on the selection that is made in the IKE Settings step. For more information on the IPSec settings, see the About IPSec Proposals.
|
||||
|
Step 12 |
Click Next. |
||||
|
Step 13 |
In the Finish area, you will find a summary of the configurations you have completed. Read the configuration and then click Submit if you're satisfied. |
||||
|
Step 14 |
Perform the following steps to deploy the configuration to a Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense device:
|
Site-to-Site VPN for Secure Firewall ASA
Security Cloud Control supports these aspects of site-to-site VPN functionality on Secure Firewall ASA devices:
-
Both IPsec IKEv1 & IKEv2 protocols are supported.
-
Automatic or manual pre-shared keys for authentication.
-
IPv4 and IPv6. All combinations of inside and outside are supported.
-
IPsec IKEv2 site-to-site VPN topologies provide configuration settings to comply with Security Certifications.
-
Static and dynamic interfaces.
-
Support the static or dynamic IP address for the extranet device as an endpoint.
Configure Site-to-Site VPN Connections with Dynamically Addressed Peers
Security Cloud Control allows you to create a site-to-site VPN connection between peers when one of the peers' VPN interface IP address is not known or when the interface obtains its address from a DHCP server. Any dynamic peer whose preshared key, IKE settings, and IPsec configurations match with another peer can establish a site-to-site VPN connection.
Consider two peers, A and B. The static peer is a device whose IP address of its VPN interface is fixed and a dynamic peer is a device whose IP address of the VPN interface is not known or has a temporary IP address.
The following use cases describe different scenarios for establishing a secure site-to-site VPN connection with dynamically-addressed peers:
-
A is a static peer, and B is a dynamic peer or conversely.
-
A is a static peer, and B is a dynamic peer with a resolved IP address from the DHCP server or conversely.
-
A is a dynamic peer, and B is an extranet device with a static or dynamic IP address.
-
A is a dynamic peer with a resolved IP address from the DHCP server, and B is an Extranet device with a static or dynamic IP address.
Note |
If the IP address of the interface is changed by using a local manager like Adaptive Security Device Manager (ASDM), the Configuration Status of that peer in Security Cloud Control shows "Conflict Detected". When you resolve this out-of-band change, the Configuration Status of the other peer changes to the "Not Synced" state. You must deploy the Security Cloud Control configuration to the device which is in "Not Synced" state. |
Typically, the dynamic peer must be the one that initiates the connection as the other peer would not know the IP address of the dynamic peer. When the remote peer attempts to establish the connection, the other peer validates the connection using the preshared key, IKE settings, and IPsec configurations.
Because the VPN connection is established only after the remote peer initiates the connection, any outbound traffic that matches access control rules that allow traffic in the VPN tunnel will be dropped until that connection is established. This ensures that data does not leave your network without the appropriate encryption and VPN protection.
Note |
A site-to-site VPN connection cannot be configured in the following scenario: If a device has more than one dynamic peer connection.
|
Secure Firewall ASA Site-to-Site VPN Guidelines and Limitations
-
Security Cloud Control does not support a crypto-acl to design the interesting traffic for S2S VPN. It only supports protected networks.
-
Whenever IKE ports 500/4500 are in use or when there are some PAT translations that are active, the site-to-site VPN cannot be configured on the same ports as it fails to start the service on those ports.
-
Transport mode is not supported only tunnel mode. IPsec tunnel mode encrypts the entire original IP datagram which becomes the payload in a new IP packet. Use tunnel mode when the firewall is protecting traffic to and from hosts positioned behind a firewall. Tunnel mode is the normal way regular IPsec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.
-
For this release, only PTP topology is supported, containing one or more VPN tunnels. Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.
Guidelines for Virtual Tunnel Interfaces
-
VTIs are only configurable in IPsec mode. To terminate GRE tunnels on an Secure Firewall ASA is unsupported.
-
You can use dynamic or static routes for traffic using the tunnel interface.
-
The MTU for VTIs is automatically set, according to the underlying physical interface. However, if you change the physical interface MTU after the VTI is enabled, you must disable and reenable the VTI to use the new MTU setting.
-
If Network Address Translation has to be applied, the IKE and ESP packets will be encapsulated in the UDP header.
-
IKE and IPsec security associations will be re-keyed continuously regardless of data traffic in the tunnel. This ensures that VTI tunnels are always up.
-
Tunnel group name must match what the peer will send as its IKEv1 or IKEv2 identity.
-
For IKEv1 in LAN-to-LAN tunnel groups, you can use names which are not IP addresses, if the tunnel authentication method is digital certificates and/or the peer is configured to use aggressive mode.
-
VTI and crypto map configurations can co-exist on the same physical interface, provided the peer address configured in the crypto map and the tunnel destination for the VTI are different.
-
By default, all traffic through VTI is encrypted.
-
By default, the security level for VTI interfaces is 0.
-
Access list can be applied on a VTI interface to control traffic through VTI.
-
Only BGP is supported over VTI.
-
If Secure Firewall ASA is terminating IOS IKEv2 VTI clients, disable the config-exchange request on IOS, because Secure Firewall ASA cannot retrieve the mode-CFG attributes for this L2L session initiated by an IOS VTI client.
-
IPv6 is not supported.
Create a Site-to-Site VPN Tunnel Between Secure Firewall ASA
Use the following procedure to create a site-to-site VPN tunnel between two ASAs or an ASA with an Extranet device:
Procedure
|
Step 1 |
In the left pane, click . |
||||
|
Step 2 |
Click the Create Tunnel ( |
||||
|
Step 3 |
|||||
|
Step 4 |
In the Peer Selection area, provide the following information:
|
||||
|
Step 5 |
Click Next. |
||||
|
Step 6 |
In the Peer Details area, provide the following information:
|
||||
|
Step 7 |
Click Next. |
||||
|
Step 8 |
(Applicable to Route Based) In the Tunnel Details, the VTI Address fields are automatically filled once the peer devices are configured in the previous step. If necessary, you can manually enter an IP address that will be used as the new VTI. |
||||
|
Step 9 |
In the IKE Settings area, choose the IKE versions to use during Internet Key Exchange (IKE) negotiations and specify the privacy configurations: For more information on the IKE policies, see About Global IKE Policies.
|
||||
|
Step 10 |
Click Next. |
||||
|
Step 11 |
In the IPSec Settings area, specify the IPSec configurations for peer 1 and peer 2. The corresponding IKEV proposals are available depending on the selection that is made in the IKE Settings step. For more information on the IPSec settings, see the About Global IKE Policies.
|
||||
|
Step 12 |
In the Finish area, review the configuration and continue further only if you’re satisfied with the configuration. By default, the Deploy changes to ASA immediately check box is checked to deploy the configurations immediately to the ASA device after clicking Submit. If you want to review and deploy the configurations manually later, then uncheck this check box. |
Create a Site-to-Site VPN Between ASA and Multicloud Defense Gateway
You can create site-to-site IPsec connections between an ASA and a Multicloud Defense Gateway that complies with all relevant standards. After the VPN connection is established, the hosts behind the firewall can connect to the hosts behind the gateway through the secure VPN tunnel.
Multicloud Defense currently supports Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), and Oracle OCI cloud accounts.
Use the following procedure to create a VPN tunnel between an ASA device that is managed by Security Cloud Control and Multicloud Defense Gateway from the Security Cloud Control dashboard:
Before you begin
Ensure that the following prerequisites are met:
-
The ASA device must not have any pending changes.
-
Create a BGP profile in the ASA console prior to creating a VPN tunnel. See Configure ASA Border Gateway Protocol for more information.
-
The Multicloud Defense Gateway must be in the Active state.
-
The Multicloud Defense Gateway must be VPN enabled. See Enable VPN within the gateway.
-
Read the ASA site-to-site VPN limitations and guidelines for more information.
-
Read the Multicloud Defense Gateway prerequisites and limitations for more information.
Procedure
|
Step 1 |
In the left pane, choose . |
|
Step 2 |
In the left pane, choose VPN > Site-to-Site VPN. |
|
Step 3 |
Click the Create Tunnel ( |
|
Step 4 |
In the Peer Selection area, provide the following information:
|
|
Step 5 |
Click Next. |
|
Step 6 |
In the Peer Details area, provide the following information:
|
|
Step 7 |
Click Next. |
|
Step 8 |
In the Tunnel Details area, provide the following information:
|
|
Step 9 |
Click Next. |
|
Step 10 |
In the IKE Settings area, Security Cloud Control generates a default Local Pre-Shared Key. This is a secret key string that is configured on the peers. IKE uses this key during the authentication phase. It is used to verify each other when establishing a tunnel between the peers. |
|
Step 11 |
In the Finish area, review the configuration and continue further only if you’re satisfied with the configuration. By default, the Deploy changes to ASA immediately check box is checked to deploy the configurations immediately to the ASA device after clicking Submit. If you want to review and deploy the configurations manually later, then uncheck this check box. |
|
Step 12 |
Click Submit. The configurations are pushed to the Multicloud Defense Gateway. |
The VPN page in Security Cloud Control shows the site-to-site tunnel created between the peers. You will be able to see the corresponding tunnel in the Multicloud Defense Gateway portal.
Exempt Site-to-Site VPN Traffic from NAT
When you have a site-to-site VPN connection defined on an interface, and you also have NAT rules for that interface, you can optionally exempt the traffic on the VPN from the NAT rules. You might want to do this if the remote end of the VPN connection can handle your internal addresses.
When you create the VPN connection, you can select the NAT Exempt option to create the rules automatically. However, this works only if your local protected network is connected through a single routed interface (not a bridge group member). If instead, the local networks in the connection reside behind two or more routed interfaces or one or more bridge group members, you need to configure the NAT exempt rules manually.
To exempt VPN traffic from NAT rules, you create an identity manual NAT rule for the local traffic when the destination is the remote network. Then, apply NAT to the traffic when the destination is anything else (for example, the Internet). If you have more than one interface for the local network, create rules for each interface. Also, consider the following suggestions:
-
If there is more than one local network in the connection, create a network object group to hold the objects that define the networks.
-
If you are including both IPv4 and IPv6 networks in the VPN, create separate identity NAT rules for each.
Consider the following example, which shows a site-to-site tunnel connecting the Boulder and San Jose offices. For traffic that you want to go to the Internet (for example from 10.1.1.6 in Boulder to www.example.com), you need a public IP address provided by NAT to access the Internet. The below example uses interface Port Address Translation (PAT) rules. However, for traffic that you want to go over the VPN tunnel (for example from 10.1.1.6 in Boulder to 10.2.2.78 in San Jose), you do not want to perform NAT; you need to exempt that traffic by creating an identity NAT rule. Identity NAT translates an address to the same address.
The following example explains the configuration for Firewall1 (Boulder). The example assumes that the inside interface is a bridge group, so you need to write the rules for each member interface. The process is the same if you have a single or multiple routed inside interfaces.
Note |
This example assumes IPv4 only. If the VPN also includes IPv6 networks, create parallel rules for IPv6. Note that you cannot implement IPv6 interface PAT, so you need to create a host object with a unique IPv6 address to use for PAT. |
Procedure
|
Step 1 |
Create objects to define the various networks.
|
|
Step 2 |
Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder).
|
|
Step 3 |
Configure manual dynamic interface PAT when going to the Internet for the inside Boulder network on Firewall1 (Boulder). Note: There might already be dynamic interface PAT rules for the inside interfaces, covering any IPv4 traffic, as these are created by default during initial configuration. However, the configuration is shown here for completeness. Before completing these steps, check whether a rule already exists that covers the inside interface and network, and skip this step if it does.
|
|
Step 4 |
Deploy configuration changes to Security Cloud Control. For more information, see Deploy Configuration Changes from Security Cloud Control to FTD. |
|
Step 5 |
Deploy configuration changes to Security Cloud Control. For more information, see Deploy Configuration Changes Made Using the Security Cloud Control GUI. |
|
Step 6 |
If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.
|
Monitor ASA Site-to-Site Virtual Private Networks
Security Cloud Control allows you to monitor already existing site-to-site VPN configurations on onboarded ASA devices. It doesn't allow you to modify or delete the site-to-site configuration.
Security Cloud Control allows you to monitor, modify, and delete existing or newly created site-to-site VPN configurations on onboarded FDM-managed devices.
Check Site-to-Site VPN Tunnel Connectivity
Use the Check Connectivity button to trigger a real-time connectivity check against the tunnel to identify whether the tunnel is currently active or idle. Unless you click the on-demand connectivity check button, a check across all tunnels, available across all onboarded devices, occurs once an hour.
Note |
|
To check tunnel connectivity from the VPN page:
Procedure
|
Step 1 |
In the left pane, choose VPN > ASA/FDM Site-to-Site VPN. |
|
Step 2 |
Search and filter the list of tunnels for your site-to-site VPN tunnel and select it. |
|
Step 3 |
In the Actions pane at the right, click Check Connectivity. |
Site-To-Site VPN Dashboard
Security Cloud Control provides a consolidated information about site-to-site VPN connections created in the tenant.
-
In the left pane, click Secure Connections > Site to Site VPN. The Site-to-Site VPN provides the information in the following widgets:
-
Sessions & Insights: Displays a bar graph representing Active VPN Tunnels and Idle VPN Tunnels, each in appropriate colors.
-
Issues: Shows the total number of tunnels detected with issues.
-
Pending Deploy: Shows the total number of tunnels with pending deployment.
By clicking on a value in the pie chart or any link in the widget, the site-to-site VPN listing page is displayed with a filter based on the selected value. For instance, in the VPN Tunnel Status widget, on clicking the Active VPN Tunnels, you will be directed to the site-to-site VPN listing page with the Active status filter applied, showing only the active tunnels.
Identify VPN Issues
Security Cloud Control can identify VPN issues on ASAFTD. (This feature is not yet available for AWS VPC site-to-site VPN tunnels.) This article describes:
Find VPN Tunnels with Missing Peers
The "Missing IP Peer" condition is more likely to occur on ASA devices than FDM-managed devices.
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
Select Table View. |
|
Step 3 |
Open the Filter panel by clicking the filter icon |
|
Step 4 |
Check Detected Issues. |
|
Step 5 |
Select each device reporting an issue |
and look in the Peers pane at the right. One peer name will be listed. Find VPN Peers with Encryption Key Issues
Use this approach to locate VPN Peers with encryption key issues such as:
-
IKEv1 or IKEv2 keys are invalid, missing, or mismatched
-
Obsolete or low encryption tunnels
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
Select Table View. |
|
Step 3 |
Open the Filter panel by clicking the filter icon |
|
Step 4 |
Select each device reporting an issue |
|
Step 5 |
Click on View Peers for one of the devices. |
|
Step 6 |
Double-click the device reporting the issue in the Diagram View. |
|
Step 7 |
Click Key Exchange in the Tunnel Details panel at the bottom. You will be able to view both devices and diagnose the key issue from that point. |
Find Incomplete or Misconfigured Access Lists Defined for a Tunnel
The "incomplete or misconfigured access-list" condition could only occur on ASA devices.
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
Select Table View. |
|
Step 3 |
Open the Filter panel by clicking the filter icon |
|
Step 4 |
Select each device reporting an issue |
|
Step 5 |
Click on View Peers for one of the devices. |
|
Step 6 |
Double-click the device reporting the issue in the Diagram View. |
|
Step 7 |
Click Tunnel Details in the Tunnel Details panel at the bottom. You will see the message, "Network Policy: Incomplete" |
Find Issues in Tunnel Configuration
The tunnel configuration error can occur in the following scenarios:
-
When the IP address of a site-to-site VPN interface changes, the "Peer IP Address Value has changed".
-
When the IKE value of a VPN tunnel doesn't match the other VPN tunnel, the "IKE value Mismatch" message appears.
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
Select Table View. |
|
Step 3 |
Open the Filter panel by clicking the filter icon |
|
Step 4 |
In the Tunnel Issues, click Detected Issues to view the VPN configuration reporting errors. You can view the configuration reporting issues |
|
Step 5 |
Select the VPN configuration reporting issues. |
|
Step 6 |
In the Peers pane on the right, the Next Step: Resolve Tunnel Configuration Issues. |
Resolve Tunnel Configuration Issues
This procedure attempts to resolve these tunnel configuration issues:
-
When the IP address of a site-to-site VPN interface changes, the "Peer IP Address Value has changed".
-
When the IKE value of a VPN tunnel doesn’t match the other VPN tunnel, the "IKE value Mismatch" message appears.
See Find Issues in Tunnel Configuration for more information.
Procedure
|
Step 1 |
In the left pane, click Inventory. |
|
Step 2 |
Click the Devices tab. |
|
Step 3 |
Click the appropriate device type tab and select the device associated with the VPN configuration reporting an issue. |
|
Step 4 |
|
|
Step 5 |
In the left pane, click to open the VPN page. |
|
Step 6 |
Select the VPN configuration reporting this issue. |
|
Step 7 |
In the Actions pane, click the Edit icon. |
|
Step 8 |
Click Next in each step until you click the Finish button in step 4. |
|
Step 9 |
Search and Filter Site-to-Site VPN Tunnels
Use the filter sidebar 
in combination with the search field to focus your search of VPN tunnels presented in the VPN tunnel diagram.
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
Click the filter icon |
|
Step 3 |
Use these filters to refine your search:
|
|
Step 4 |
You can also search the filtered results by device name or IP address by entering that information in the search bar. The search is case-insensitive. |
Onboard an Unmanaged Site-to-Site VPN Peer
Security Cloud Control will discover a site-to-site VPN tunnel when one of the peers is onboarded. If the second peer is not managed by Security Cloud Control, you can filter the list of VPN tunnels to find the unmanaged device and onboard it:
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
Select Table View. |
|
Step 3 |
Open the filter panel by clicking |
|
Step 4 |
Check Unmanaged. |
|
Step 5 |
Select a tunnel from the table from the results. |
|
Step 6 |
In the Peers pane on the right, click Onboard Device and follow the instructions on the screen. |
View IKE Object Details of Site-To-Site VPN Tunnels
You can view the details of the IKE objects configured on the peers/devices of the selected tunnel. These details appear in a tree structure in a hierarchy based on the priority of the IKE policy object.
Note |
Extranet devices don't show the IKE Objects details. |
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
|
Step 2 |
In the VPN Tunnels page, click the name of the VPN tunnel that connects the peers. |
|
Step 3 |
Under Relationships on the right, expand the object that you want to see its details. |
View Last Successful Site-to-Site VPN Tunnel Establishment Date
This information typically provides the date and time when the VPN tunnel was last successfully established, ensuring connectivity between the two sites. Accessing this data can help you monitor VPN health and troubleshoot any connectivity issues that might arise.
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
||
|
Step 2 |
The VPN Tunnels page displays all the site-to-site VPN tunnels configured across your managed devices. You can click a tunnel to view more details in the right pane.
The Last Active field shows the date and time the VPN tunnel was successfully established. |
View Site-to-Site VPN Tunnel Information
The site-to-site VPN table view is a complete listing of all site-to-site VPN tunnels available across all devices onboarded to Security Cloud Control. A tunnel only exists once in this list. Clicking on a tunnel listed in the table provides an option in the right side bar to navigate directly to a tunnel's peers for further investigation.
In cases where Security Cloud Control does not manage both sides of a tunnel, you can click Onboard Device to open the main onboarding page an onboard the unmanaged peer. In cases where Security Cloud Control manages both side of a tunnel, the Peer 2 column contains the name of the managed device. However, in the case of an AWS VPC, the Peer 2 column contains the IP address of the VPN gateway.
To view site-to-site VPN connections in the table view:
Procedure
|
Step 1 |
In the left pane, click to open the VPN page. |
||
|
Step 2 |
The VPN Tunnels page displays all the site-to-site VPN tunnels configured across your managed devices. You can click on a tunnel to view more details in the right pane.
|
Site-to-Site VPN Global View
Procedure
|
Step 1 |
In the left pane, click VPN > ASA/FDM Site-to-Site VPN. |
|
Step 2 |
In the left pane, click . |
|
Step 3 |
Click the Global view button. |
|
Step 4 |
Use Search and Filter Site-to-Site VPN Tunnels to find a specific tunnel, or zoom into the Global View graphic to find the VPN gateway and its peers that you are looking for. |
|
Step 5 |
Select one of the peers represented in the Global View. |
|
Step 6 |
Click View Details. |
|
Step 7 |
Click the other end of the VPN tunnel and Security Cloud Control displays Tunnel Details, NAT Information, and Key Exchange information for that connection:
|
Site-to-Site VPN Tunnels Pane
The Tunnels pane displays a list of all the tunnels associated with a particular VPN gateway. For site-to-site VPN connections between your VPN gateway and an AWS VPC, the tunnels pane shows all the tunnels from your VPN gateway to the VPC. Since each site-to-site VPN connection between your VPN gateway and an AWS VPC has two tunnels, you will see double the number of tunnels you normally would for other devices.
VPN Gateway Details
Displays the number of peers connected to the VPN gateway and the IP address of the VPN gateway. This is only visible in the VPN Tunnels page.
View Peer
After you select a site-to-site VPN peer pair, the peers pane lists the two devices in the pair and allows you to click View Peer for one of the devices. By clicking View Peer, you see any other site-to-site peer that device is associated with. This is visible in the Table view and in the Global view.
Delete a Security Cloud Control Site-To-Site VPN Tunnel
Procedure
|
Step 1 |
In the left pane, choose VPN> Site-to-Site VPN. |
|
Step 2 |
In the left pane, click to open the VPN page. |
|
Step 3 |
Select the desired site-to-site VPN tunnel that you want to delete. |
|
Step 4 |
In the Actions pane on the right, click Delete. |
The selected site-to-site VPN tunnel is deleted.
Introduction to Remote Access Virtual Private Network
Remote Access virtual Private Network (RA VPN) capability enables users to connect to your network from a location outside the physical office premises. This means that they can use a computer or a supported iOS/Android device that is connected to the internet and access your network resources securely. This feature is particularly useful for mobile workers who need to connect from their home network or a public Wi-Fi network while ensuring that their data remains safe and protected.
Introduction to Remote Access Virtual Private Network
Remote Access virtual Private Network (RA VPN) capability enables users to connect to your network from a location outside the physical office premises. This means that they can use a computer or a supported iOS/Android device that is connected to the internet and access your network resources securely. This feature is particularly useful for mobile workers who need to connect from their home network or a public Wi-Fi network while ensuring that their data remains safe and protected.
Configure Remote Access Virtual Private Network for ASA
The ASA creates a remote access virtual private network (VPN) by creating a secure connection across a TCP/IP network (such as the Internet) that users see as a private connection. It can create single-user-to-LAN connections and LAN-to-LAN connections.
The secure connection is called a tunnel, and the ASA uses tunneling protocols to negotiate security parameters, create and manage tunnels, encapsulate packets, transmit or receive them through the tunnel, and unencapsulate them. The ASA functions as a bidirectional tunnel endpoint: it can receive plain packets, encapsulate them, and send them to the other end of the tunnel where they are unencapsulated and sent to their final destination. It can also receive encapsulated packets, unencapsulate them, and send them to their final destination.
Security Cloud Control provides an intuitive user interface for configuring a new remote access Virtual Private Network. It also allows you to quickly and easily configure remote access VPN connection for multiple Adaptive Security Appliance (ASA) devices onboarded in Security Cloud Control.
Security Cloud Control allows you to configure the remote access VPN configuration on ASA devices from scratch. It also allows you to manage the remote access VPN settings that have already been configured using another ASA management tool, such as the Adaptive Security Defense Manager (ASDM) or Cisco Security Manager (CSM). When you onboard an ASA device that already has remote access VPN settings, Security Cloud Control automatically creates a "Default remote access VPN Configuration" and associates the ASA device with this configuration. This default configuration can contain all the connection profile objects that are defined on the device. If you want to understand the RAVPN attributes that are read into Security Cloud Control, see the Read RA VPN Configuration of an Onboarded ASA Device section. Otherwise, you can start performing steps described in the "End-to-End Remote Access VPN Configuration Process for ASA" section.
End-to-End Remote Access VPN Configuration Process for ASA
This section provides the end-to-end procedure for configuring remote access VPN on an ASA device onboarded to Security Cloud Control.
To enable remote access VPN for your clients, you need to configure several separate items. The following procedure provides the end-to-end process.
Procedure
|
Step 1 |
Configure the identity source used for authenticating remote users. You can use the following sources to authenticate users attempting to connect to your network using remote access VPN. Additionally, you can use client certificates for authentication, either alone or in conjunction with an identity source.
|
||
|
Step 2 |
|||
|
Step 3 |
|||
|
Step 4 |
(optional) Exempt Remote Access VPN Traffic from NAT. |
||
|
Step 5 |
Review and deploy configuration changes to the devices.
|
What to do next
Next Steps
Once the remote access VPN configuration is downloaded to the ASA devices, the users can connect to your network from a remote location using a computer or other supported iOS or Android device connected to the Internet. You can monitor live AnyConnect remote access VPN sessions from all onboarded ASA remote access VPN head-ends in your tenant.
Configure Identity Sources for ASA
Identity sources, such as Microsoft Active Directory (AD) realms and RADIUS Servers, are AAA servers and databases that define user accounts for the people in your organization. You can use this information in a variety of ways, such as providing the user identity associated with an IP address or authenticating remote access VPN connections or access to Security Cloud Control.
Click Manage > Objects, then click (
)>Identity Source to create your sources. You would then use these objects when you configure the services that require an identity source.
You can apply appropriate filters to search existing sources and manage them.
Determining the Directory Base DN
When you configure directory properties, you need to specify the common base distinguished name (DN) for users and groups. The base is defined in your directory server and differs from network to network. You must enter the correct bases for identity policies to work. If the base is wrong, the system cannot determine user or group names, and thus identity-based policies will be inoperable.
Note |
To get the correct bases, consult the administrator who is responsible for the directory servers. |
For an active directory, you can determine the correct bases by logging into the Active Directory server as a domain administrator, and using the dsquery command at a command prompt as follows to determine the bases:
User search base
Enter the dsquery user command with known username (partial or complete) to determine the base distinguished name. For example, the following command uses the partial name "John*" to return information for all users that start with "John."
C:\Users\Administrator>dsquery user -name "John*"
"CN=John Doe,CN=Users,DC=csc-lab,DC=example,DC=com"
The base DN would be "DC=csc-lab,DC=example,DC=com."
Group search base
Enter the dsquery group command with a known group name to determine the base distinguished name. For example, the following command uses the group name Employees to return the distinguished name:
C:\>dsquery group -name "Employees"
"CN=Employees,CN=Users,DC=csc-lab,DC=example,DC=com"
The group base DN would be "DC=csc-lab,DC=example,DC=com."
You can also use the ADSI Edit program to browse the Active Directory structure (). In ADSI Edit, right-click any object, such as an organizational unit (OU), group, or user, and choose Properties to view the distinguished name. You can then copy the string of DC values as the base.
To verify that you have the correct base:
Procedure
|
Step 1 |
Click the Test Connection button in the directory properties to verify connectivity. Resolve any problems, and save the directory properties. |
|
Step 2 |
Commit changes to the device. |
|
Step 3 |
Create an access rule, select the Users tab, and try to add known user and group names from the directory. You should see auto-complete suggestions as you type for matching users and groups in the realm that contains the directory. If these suggestions appear in a drop-down list, then the system was able to query the directory successfully. If you see no suggestions, and you are certain the string you typed should appear in a user or group name, you need to correct the corresponding search base. |
What to do next
See Create or Edit an ASA Active Directory Realm Object for more information.
RADIUS Servers and Groups
You can use RADIUS servers to authenticate and authorize administration users. When you configure a feature to use RADIUS servers, you select a RADIUS group instead of individual servers. A RADIUS group is a collection of RADIUS servers that are copies of each other. If a group has more than one server, they form a chain of backup servers to provide redundancy in case one server becomes unavailable. But even if you have only one server, you must create a one-member group to configure RADIUS support for a feature.
You can use this source for the following purposes:
-
Remote Access VPN, as an identity source for authentication, and for authorization and accounting. You can use AD in conjunction with a RADIUS server.
-
Identity policy, as a passive identity source to collect user identity from remote access VPN logins.
See Create and Edit an Adaptive Security Appliance RADIUS Server Object or Group for more information.
Create an ASA Active Directory Realm Object
When you create or edit an identity source object such as an AD realm object, Security Cloud Control sends the configuration request to the ASA devices through the SDC. The ASA then communicates with the configured AD realm.
Use the following procedure to create an object:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
||
|
Step 2 |
Click Create Object ( |
||
|
Step 3 |
Enter an Object Name for the object. |
||
|
Step 4 |
Select the Device Type as ASA. |
||
|
Step 5 |
In the first part of the wizard, select Active Directory Realm as the Identity Source Type. Click Continue. |
||
|
Step 6 |
Configure the basic realm properties.
|
||
|
Step 7 |
Configure the directory server properties.
|
||
|
Step 8 |
(Optional) Use the Test button to validate the configuration. |
||
|
Step 9 |
(Optional) Click Add another configuration to add multiple Active Directory (AD) servers to the AD realm. The AD servers need to be duplicates of each other and support the same AD domain. Therefore, the basic realm properties such as Directory name, Directory Password, and Base Distinguished Name must be the same across all AD servers associated with that AD realm. |
||
|
Step 10 |
Click Add. |
)Edit an ASA Active Directory Realm Object
Note that you cannot change the Identity Source Type when editing an Identity source object. You must create a new object with the correct type.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Locate the object you want to edit by using object filters and search field. |
|
Step 3 |
Select the object you want to edit. |
|
Step 4 |
Click the edit icon |
|
Step 5 |
Edit the values in the dialog box in the same fashion that you created in the procedures above. Expand the configuration bar listed below to edit or test the hostname/IP address or encryption information. |
|
Step 6 |
Click Save. |
|
Step 7 |
Security Cloud Control displays the policies that will be affected by the change. Click Confirm to finalize the change to the object and any policy affected by it. |
|
Step 8 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
in the Create an ASA RADIUS Server Object or Group
When you create or edit an identity source object such as a RADIUS server object or a group of RADIUS server objects, Security Cloud Control sends the configuration request to ASA devices through the SDC.
Create an ASA RADIUS Server Object
RADIUS servers provide AAA (authentication, authorization, and accounting) services.
Use the following procedure to create an object:
Procedure
|
Step 1 |
In the Security Cloud Control platform menu, choose . |
|
Step 2 |
In the left pane, click Manage > Objects. |
|
Step 3 |
Click Create Object ( |
|
Step 4 |
Enter an Object name for the object. |
|
Step 5 |
Select the Device Type as ASA. |
|
Step 6 |
Select RADIUS Server as the Identity Source Type. Click Continue. |
|
Step 7 |
Edit the Identity Source configuration with the following properties:
|
|
Step 8 |
Click Add. |
|
Step 9 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Create an ASA RADIUS Server Group
A RADIUS server group contains one or more RADIUS server objects. The servers within a group must be copies of each other. These servers form a chain of backup servers, so that if the first server is unavailable, the system can try the next server in the list.
Use the following procedure to create an object group:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
||
|
Step 2 |
Click Create Object ( |
||
|
Step 3 |
Enter an Object name for the object. |
||
|
Step 4 |
Select the Device Type as ASA. |
||
|
Step 5 |
Select RADIUS Server Group as the Identity Source Type. Click Continue. |
||
|
Step 6 |
Edit the Identity Source configuration with the following properties:
|
||
|
Step 7 |
Select an AD realm that supported the RADIUS server from the drop-down menu. If you have not already created an AD realm, click Create from inside the drop-down menu. |
||
|
Step 8 |
Click the RADIUS SERVER Add button
|
||
|
Step 9 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Edit an ASA Radius Server Object or Group
Use the following procedure to edit a Radius server object or Radius server group:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Locate the object you want to edit by using object filters and search field. |
|
Step 3 |
Select the object you want to edit. |
|
Step 4 |
Click the edit icon |
|
Step 5 |
Edit the values in the dialog box in the same fashion that you created them in the procedures above. To edit or test the hostname/IP address or encryption information, expand the configuration bar. |
|
Step 6 |
Click Save. |
|
Step 7 |
Security Cloud Control displays the policies that will be affected by the change. Click Confirm to finalize the change to the object and any policy affected by it. |
|
Step 8 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Create ASA Remote Access VPN Group Policies
A group policy is a set of user-oriented attribute/value pairs for remote access VPN connections. The connection profile uses a group policy that sets terms for user connections after the tunnel is established. Group policies let you apply whole sets of attributes to a user or a group of users, rather than having to specify each attribute individually for each user.
The system includes a default group policy named "DfltGrpPolicy". You can create additional group policies to provide the services you require.
Note |
You cannot add inconsistent group policy objects to remote access VPN configuration. Resolve all inconsistencies before adding the group policy to the remote access VPN Configuration. |
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Click |
|
Step 3 |
Enter a name for the group policy. The name can be up to 64 characters and spaces are allowed. |
|
Step 4 |
In the Device Type drop-down, select ASA. |
|
Step 5 |
Do any of the following:
|
|
Step 6 |
Click Save to create the group policy. |
ASA Remote Access VPN Group Policy Attributes
The section describes the attributes associated with the ASA remote access VPN group policy.
General Attributes
The general attributes of a group policy define the name of the group and some other basic settings.
-
DNS Server: Enter the IP address(s) of DNS servers for domain name resolution when connected to the VPN. You can separate the addresses using a comma.
-
Banner: The banner text, or welcome message, to present to users at login. The default is no banner. The length can be up to 496 characters. The AnyConnect client supports partial HTML. To ensure that the banner displays properly to remote users, use the <BR> tag to indicate line breaks.
-
Default Domain: The default domain name for users in the remote access VPN. For example, example.com. This domain is added to hostnames that are not fully-qualified, for example, serverA instead of serverA.example.com.
AnyConnect Client Profiles
This feature is supported on FTD running software version 6.7 or later versions.
Cisco AnyConnect VPN client offers enhanced security through various built-in modules. These modules provide services such as web security, network visibility into endpoint flows, and off-network roaming protection. Each client module includes a client profile that includes a group of custom configurations as per your requirement.
You can select the AnyConnect VPN profile object and AnyConnect modules to be downloaded to clients when the VPN user downloads the VPN AnyConnect client software.
-
Choose or create an AnyConnect VPN profile object. See Upload RA VPN AnyConnect Client Profile. Except for DART and Start Before Login modules, the AnyConnect VPN profile object must be selected.
-
Click Add Any Connect Client Module.
The following AnyConnect modules are optional and you can configure these modules to be downloaded with VPN AnyConnect client software:
-
AMP Enabler — Deploys advanced malware protection (AMP) for endpoints.
-
DART — Captures a snapshot of system logs and other diagnostic information and creates a .zip file on your desktop so you can conveniently send troubleshooting information to Cisco TAC.
-
Feedback — Provides information about the features and modules customers have enabled and used.
-
ISE Posture — Uses the OPSWAT library to perform posture checks to assess an endpoint's compliance.
-
Network Access Manager — Provides 802.1X (Layer 2) and device authentication to access both wired and wireless networks.
-
Network Visibility — Enhances the enterprise administrator's ability to do capacity and service planning, auditing, compliance, and security analytics.
-
Start Before Login — Forces the user to connect to the enterprise infrastructure over a VPN connection before logging on to Windows by starting AnyConnect before the Windows login dialog box appears.
-
Umbrella Roaming Security — Provides DNS-layer security when no VPN is active.
-
Web Security — Analyzes the elements of a web page, allows acceptable content, and blocks malicious or unacceptable content based on a defined security policy.
-
-
In the Client Module list, select an AnyConnect module.
-
In the Profile list, choose or create a profile object containing an AnyConnect Client Profile.
-
Select Enable Module Download to enable endpoints to download the client module along with the profile. If not selected, the endpoints can download only the client profile.
Session Setting Attributes
The session settings of a group policy control how long users can connect through the VPN and how many separate connections they can establish.
-
Maximum Connection Time: The maximum length of time, in minutes, that users can stay connected to the VPN without logging out and reconnecting, from 1- 4473924 or blank. The default is unlimited (blank), but the idle timeout still applies.
-
Connection Time Alert Interval: If you specify a maximum connection time, the alert interval defines the amount of time before the maximum time is reached to display a warning to the user about the upcoming automatic disconnect. The user can choose to end the connection and reconnect to restart the timer. The default is 1 minute. You can specify 1 to 30 minutes.
-
Idle Time: The length of time, in minutes, that the VPN connection can be idle before it is automatically closed, from 1-35791394. If there is no communication activity on the connection for this consecutive number of minutes, the system stops the connection. The default is 30 minutes.
-
Idle Time Alert Interval: The amount of time before the idle time is reached to display a warning to the user about the upcoming automatic disconnect due to an idle session. Any activity resets the timer. The default is 1 minute. You can specify 1 to 30 minutes.
-
Simultaneous Login Per User: The maximum number of simultaneous connections allowed for a user. The default is 3. You can specify 1 to 2147483647 connections. Allowing many simultaneous connections might compromise security and affect performance.
Address Assignment Attributes
The address assignment attributes of a group policy define the IP address pool for the group. The pool defined here overrides the pool defined in any connection profile that uses this group. Leave these settings blank if you want to use the pool defined in the connection profile.
-
IPv4 Address Pool, IPv6 Address Pool: These options define the address pools for the remote endpoints. Clients are assigned an address from these pools based on the IP version they use to make the VPN connection. Select the IP address pool that defines a subnet for each IP type you want to support. Leave the list empty if you do not want to support that IP version. For example, you could define an IPv4 pool as 10.100.10.0/24. The address pool cannot be on the same subnet as the IP address for the outside interface.
-
DHCP Scope: If you configure DHCP servers for the address pool in the connection profile, the DHCP scope identifies the subnets to use for the pool for this group. The DHCP server must also have addresses in the same pool identified by the scope. The scope allows you to select a subset of the address pools defined in the DHCP server to use for this specific group. If you do not define a network scope, the DHCP server assigns IP addresses in the order of the address pools configured. It goes through the pools until it identifies an unassigned address. To specify a scope, enter the network object that contains the network number host address. For example, to tell the DHCP server to use addresses from the 192.168.5.0/24 subnet pool, enter a network object that specifies 192.168.5.0 as a host address. You can use DHCP for IPv4 addressing only.
Split Tunneling Attributes
The split tunneling attributes of a group policy define how the system should handle traffic meant for the internal network vs. externally-directed traffic. Split tunneling directs some network traffic through the VPN tunnel (encrypted) and the remaining network traffic outside the VPN tunnel (unencrypted or in clear text).
Typically, in remote access VPN, you might want the VPN users to access the Internet through your device. However, you can allow your VPN users to access an outside network while they are connected to an remote access VPN. This technique is called split tunneling or hair pinning. The split tunnel allows VPN connectivity to a remote network across a secure tunnel, and it also allows connectivity to a network outside the VPN tunnel. Split tunneling reduces the network load on the FTD devices and increases the bandwidth on the outside interface.
Before you begin
For creating a split tunnel policy for IPv4 networks and another for IPv6 networks, the access-list you specify is used for both protocols. So, the access-list should contain access control entries (ACEs) for both IPv4 and IPv6 traffic.
When an ASA device is onboarded to Security Cloud Control, it reads the extended ACLs associated with the device. See Split Tunnel Configuration for more information. If you want to create new ACLs, see ASA Lists to create them.
Note |
Ensure that you specify the network intended for split tunneling as the source network in the ACL you are creating. |
-
IPv4 Split Tunneling, IPv6 Split Tunneling: You can specify different options based on whether the traffic uses IPv4 or IPv6 addresses, but the options for each are the same. If you want to enable split tunneling, specify one of the options that require you to select network objects.
-
Allow all traffic over tunnel: Do no split tunneling. Once the user makes an remote access VPN connection, all the user's traffic goes through the protected tunnel. This is the default. It is also considered the most secure option.
-
Allow specified traffic over the tunnel: Select the extended access list that defines the source network. Any traffic from these sources goes through the protected tunnel. The client routes traffic from any other source to connections outside the tunnel (such as a local Wi-Fi or network connection).
-
Exclude networks specified below: Select the network objects that define the source network. The client routes any traffic from these sources to connections outside the tunnel. Traffic from any other source goes through the tunnel.
-
Network List: Select the extended ACL network that can have both IPv4 and IPv6 networks.
-
-
Split DNS: You can configure the system to send some DNS requests through the secure connection while allowing the client to send other DNS requests to the DNS servers configured on the client. You can configure the following DNS behavior:
-
Send DNS Request as per split tunnel policy: With this option, DNS requests are handled the same way as the split tunnel options are defined. If you enable split tunneling, DNS requests are sent based on the destination addresses. If you do not enable split tunneling, all DNS requests go over the protected connection.
-
Always send DNS requests over tunnel: Select this option if you enable split tunneling, but you want all DNS requests sent through the protected connection to the DNS servers defined for the group.
-
Send only specified domains over tunnel: Select this option if you want your protected DNS servers to resolve addresses for certain domains only. Then, specify those domains, separating domain names with commas. For example, example.com, example1.com. Use this option if you want your internal DNS servers to resolve names for internal domains, while external DNS servers handle all other Internet traffic.
-
AnyConnect Attributes
The AnyConnect attributes of a group policy define some SSL and connection settings used by the AnyConnect client for a remote access VPN connection.
-
SSL Settings
-
Enable Datagram Transport Layer Security (DTLS): Whether to allow the AnyConnect client to use two simultaneous tunnels: an SSL tunnel and a DTLS tunnel. Using 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. If you do not enable DTLS, AnyConnect client users establishing SSL VPN connections connect with an SSL tunnel only.
-
DTLS Compression: Whether to compress Datagram Transport Layer Security (DTLS) connections for this group using LZS. DTLS Compression is disabled by default.
-
SSL Compression: Whether to enable data compression, and if so, the method of data compression to use, Deflate, or LZS. SSL Compression is Disabled by default. Data compression speeds up transmission rates but also increases the memory requirement and CPU usage for each user session. Therefore, SSL compression decreases the overall throughput of the device.
-
SSL Rekey Method, SSL Rekey Interval: The client can rekey the VPN connection, renegotiating the crypto keys and initialization vectors, to increase the security of the connection. Disable rekeying by selecting None. To enable rekey, select New Tunnel to create a new tunnel each time. (The Existing Tunnel option results in the same action as New Tunnel.) If you enable rekeying, also set the rekey interval, which is 4 minutes by default. You can set the interval to 4-10080 minutes (1 week).
-
-
Connection Settings
-
Ignore the DF (Don't Fragment) bit: Whether to ignore the Don't Fragment (DF) bit in packets that need fragmentation. Select this option to allow the forced fragmentation of packets that have the DF bit set, so that these packets can pass through the tunnel.
-
Client Bypass Protocol: Allows you to configure how the secure gateway manages IPv4 traffic (when it is expecting only IPv6 traffic), or how it manages IPv6 traffic (when it is expecting only IPv4 traffic).
When the AnyConnect client makes a VPN connection to the headend, the headend assigns it an IPv4, IPv6, or both an IPv4 and IPv6 address. If the headend assigns the AnyConnect connection only an IPv4 address or only an IPv6 address, you can configure the Client Bypass Protocol to drop network traffic for which the headend did not assign an IP address (default, disabled, not checked), or allow that traffic to bypass the headend and be sent from the client unencrypted or "in the clear" (enabled, checked).
For example, assume that the secure gateway assigns only an IPv4 address to an AnyConnect connection and the endpoint is dual-stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass Protocol is disabled, the IPv6 traffic is dropped; however, if Client Bypass Protocol is enabled, the IPv6 traffic is sent from the client in the clear.
-
MTU: The maximum transmission unit (MTU) size for SSL VPN connections established by the Cisco AnyConnect VPN Client. The default is 1406 bytes. The range is 576 to 1462 bytes.
-
Keepalive Messages Between AnyConnect and VPN Gateway: Whether to exchange keepalive messages between peers to demonstrate that they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals. The default interval is 20 seconds, and the valid range is 15 to 600 seconds.
-
DPD on Gateway Side Interval, DPD on Client Side Interval: Enable Dead Peer Detection (DPD) to ensure that the VPN gateway or VPN client quickly detects when the peer is no longer responding. You can separately enable gateway or client DPD. The default interval is 30 seconds for sending DPD messages. The interval can be 5-3600 seconds.
-
-
Traffic Filters Attributes
The traffic filter attributes of a group policy define restrictions you want to place on users assigned to the group. You can use these attributes instead of creating access control policy rules to restrict remote access VPN users to specific resources, based on host or subnet address and protocol, or VLAN. By default, remote access VPN users are not restricted by the group policy from accessing any destination on your protected network.
-
Access List Filter: Restrict access using an extended access control list (ACL). Select the Smart CLI Extended ACL object. The extended ACL lets you filter based on source address, a destination address, and protocol (such as IP or TCP). ACLs are evaluated on a top-down, first-match basis, so ensure that you place specific rules before more general rules. There is an implicit "deny any" at the end of the ACL, so if you intend to deny access to a few subnets while allowing all other access, ensure that you include a "permit any" rule at the end of the ACL. Because you cannot create network objects while editing an extended ACL Smart CLI object, you should create the ACL before editing the group policy. Otherwise, you might need to simply create the object, then go back later to create the network objects and then all the access control entries that you need. To create the ACL, log in to FDM, go to , create an object, and select Extended Access List as the object type.
-
Restrict VPN to VLAN: Also called "VLAN mapping," this attribute specifies the egress VLAN interface for sessions to which this group policy applies. The system forwards all traffic from this group to the selected VLAN. Use this attribute to assign a VLAN to the group policy to simplify access control. Assigning a value to this attribute is an alternative to using an ACL to filter traffic on a session. Ensure that you specify a VLAN number that is defined on a subinterface on the device. Values range from 1 to 4094.
Windows Browser Proxy Attributes
The Windows browser proxy attributes of a group policy determine how, and whether, a proxy defined on the user's browser operates.
You can select one of the following values for Browser Proxy During VPN Session:
-
No change in endpoint settings: Allow the user to configure (or not configure) a browser proxy for HTTP and use the proxy if it is configured.
-
Disable browser proxy: Do not use the proxy defined for the browser, if any. No browser connections will go through the proxy.
-
Auto detect settings: Enable the use of automatic proxy server detection in the browser for the client device.
-
Use custom settings: Define a proxy that should be used by all client devices for HTTP traffic. Configure the following settings:
-
Proxy Server IP or Hostname, Port: The IP address, or hostname, of the proxy server, and the port used for proxy connections by the proxy server. The host and port combined cannot exceed 100 characters.
-
Browser Proxy Exemption List: Connections to the hosts/ports in the exemption list do not go through the proxy. Add all the host/port values for destinations that should not use the proxy. For example, www.example.com port 80. Click Add proxy exemption to add items to the list. Click the trash can icon to delete items. The entire proxy exception list, combining all addresses and ports, cannot be longer than 255 characters.
-
Create ASA Remote Access VPN Configuration
Security Cloud Control allows you to add one or more Adaptive Security Appliance (ASA) devices to the remote access VPN configuration wizard and configure the VPN interfaces, access control, and NAT exemption settings associated with the devices. Therefore, each remote access VPN configuration can have connection profiles and group policies shared across multiple ASA devices that are associated with the remote access VPN configuration. Further, you can enhance the configuration by creating connection profiles and group policies.
You can either onboard an ASA device that has already been configured with remote access VPN settings or a new device without remote access VPN settings. See Onboard ASA Device to Security Cloud Control. When you onboard an ASA device that already has remote access VPN settings, Security Cloud Control automatically creates a "Default remote access VPN Configuration" and associates the ASA device with this configuration. Also, this default configuration can contain all the connection profile objects that are defined on the device. See Read RA VPN Configuration of an Onboarded ASA Device for more information. Security Cloud Control allows you to delete the default configuration.
Important |
|
Before you begin
Before adding the ASA device to the remote access VPN configuration, the following prerequisites must be met on the ASA device:
-
License requirements.
Device must be enabled for export-controlled functionality.
To view the license summary of your ASA device, execute the show license summary command in the ASA command-line interface. To use the Security Cloud Control ASA CLI interface, see Use the command line interface.
-
Example of export-controlled functionality enabled in the license summary :
Registration: Status: REGISTEREDSmart Account: Cisco SVS temp-request access licensing@cisco.comExport-Controlled Functionality: ALLOWEDLast Renewal Attempt: NoneNext Renewal Attempt: Jun 08 2021 09:46:22 UTCThe 'Export-Controlled Functionality' property must be in the 'Allowed' state for creating or editing the VPN configuration.
If this property is in the 'Not Allowed' state, Security Cloud Control displays an error message ('remote access VPN cannot be configured for devices which are not export compliant.') when you are creating or modifying the VPN configuration and doesn't allow remote access VPN configuration on the device.
-
-
Device Identity Certificates.
Certificates are required to authenticate connections between the clients and the ASA device. Before starting the VPN configuration, ensure that the identity certificate is already present on the ASA device.
To determine whether or not the certificate is present on the device, execute the show crypto CA Certificates command in the ASA command-line interface. To use the Security Cloud Control ASA CLI interface, see ASA Command Line Interface.
If the identity certificate is not present or you want to enroll in a new certificate, install them on ASA using Security Cloud Control. See ASA Certificate Management.
The usage of digital certificates in remote access VPN context is explained in Remote Access VPN Certificate-Based Authentication.
-
Outside interfaces.
The outside interfaces must be configured already on the ASA device. You need to use either ASDM or ASA CLI to configure interfaces. To know configure interfaces using ASDM, see the "Interfaces" book of the Cisco ASA Series General Operations CLI Configuration Guide, X.Y.
-
Download the AnyConnect packages and upload them to a remote server. Later, use the remote access VPN wizard or ASA File Management wizard to upload the AnyConnect software packages from the server to ASAs. See Manage AnyConnect Software Packages on an ASA Device for instructions.
-
There are no configuration deployments pending.
-
If you are using the local database for authentication Add user accounts to the local database using ASDM or ASA CLI.
To add user accounts using ASDM, see the "Add a User Account to the Local Database" section in the "AAA Servers and the Local Database" book of the Cisco ASA Series VPN CLI Configuration Guide, X.Y.
To add user accounts using ASA CLI, execute username[username] password [password] privilege [priv_level] command.
-
ASA changes are synchronized to Security Cloud Control.
-
In the left pane, click and search for one or more ASA devices to be synchronized.
-
Select one or more devices and then click Check for changes. Security Cloud Control communicates with one or more FTD devices to synchronize the changes.
-
-
Remote access VPN configuration group policy objects are consistent.
-
Ensure that all inconsistent group policy objects are resolved as they cannot be added to the remote access VPN configuration. Either address the issue or remove inconsistent group policy objects from the Objects page. For more information see, Resolve Duplicate Object Issues and Resolve Inconsistent Object Issues.
-
Procedure
|
Step 1 |
|||||
|
Step 2 |
In the left pane, click . |
||||
|
Step 3 |
Click the blue plus |
||||
|
Step 4 |
Enter a name for the Remote Access VPN configuration. |
||||
|
Step 5 |
Click the blue plus You can add the device details and configure network traffic-related permissions that are associated with the device.
|
||||
|
Step 6 |
Click OK. The ASA VPN configuration is created. |
Modify ASA Remote Access VPN Configuration
You can modify the name and the device details of an existing remote access VPN configuration.
Procedure
|
Step 1 |
Select the configuration to be modified and under Actions, click Edit.
|
||
|
Step 2 |
to perform the following on the ASA device.
What to do next
Configure ASA Remote Access VPN Connection Profile
A Remote Access VPN connection profile defines the characteristics that allow external users to create a VPN connection to the system using the AnyConnect client. Each profile defines the AAA servers and certificates used for authenticating users, the address pools for assigning users IP addresses, and the group policies that define various user-oriented attributes.
You can create multiple profiles within the remote access VPN configuration if you need to provide variable services to different user groups, or if you have various authentication sources. For example, if your organization merges with a different organization that uses different authentication servers, you can create a profile for the new group that uses those authentication servers.
A remote access VPN connection profile allows your users to connect to your inside networks when they are on external networks, such as their home network. Create separate profiles to accommodate different authentication methods.
Before you begin
Procedure
|
Step 1 |
In the left pane, click . You can click a VPN configuration to view the summary information on how many connection profiles and group policies are currently configured.
|
||
|
Step 2 |
Click the connection profile and under Actions in the sidebar at the right, click Add Connection Profile. |
||
|
Step 3 |
Configure the basic connection attributes.
|
||
|
Step 4 |
Configure the primary and optionally, secondary identity sources. These options determine how remote users authenticate to the device to enable the remote access VPN connection. The simplest approach is to use AAA only and then select an AD realm or use the LocalIdentitySource. You can use the following approaches for Authentication Type:
|
||
|
Step 5 |
Configure the address pool for clients. The address pool defines the IP addresses that the system can assign to remote clients when they establish a VPN connection. For more information, see Configure Client Address Pool Assignment. |
||
|
Step 6 |
Click Continue. |
||
|
Step 7 |
Select the Group Policy to use for this profile from the list and click Select. |
||
|
Step 8 |
Click Continue. |
||
|
Step 9 |
Review the summary. First, verify that the summary is correct. You can see what
end-users need to do to initially install the AnyConnect software and test that
they can complete a VPN connection. Click |
||
|
Step 10 |
Click Done. |
||
|
Step 11 |
Perform step 5 of End-to-End Remote Access VPN Configuration Process for ASA. |
to copy the instructions to the clipboard, and then distribute
them to your users.
Configure AAA for a Connection Profile
Authentication, Authorization, and Accounting (AAA) servers use username and password to determine if a user is allowed access to the remote access VPN. If you use RADIUS servers, you can distinguish authorization levels among authenticated users, to provide differential access to protected resources. You can also use RADIUS accounting services to keep track of usage.
When configuring AAA, you must configure a primary identity source. Secondary and fallback sources are optional. Use a secondary source if you want to implement dual authentication, for example, using RSA tokens or DUO.
Primary Identity Source Options
-
Primary Identity Source for User Authentication: Authentication provides a way to identify a user, typically by having the user enter a valid username and valid password before access is granted. The primary identity source used for authenticating remote users. End-users must be defined in this source or the optional fallback source to complete a VPN connection. Select one of the following:
-
An Active Directory (AD) identity realm.
-
A RADIUS server group.
-
LocalIdentitySource (the local user database): You can define users directly on the device and not use an external server.
-
-
Fallback Local Identity Source: If the primary source is an external server, you can select the LocalIdentitySource as a fallback in case the primary server is unavailable. If you use the local database as a fallback source, ensure that you define the same local usernames/passwords as the ones defined in the external server.
-
Strip options: A realm is an administrative domain. Enabling the following options allows the authentication to be based on the username alone. You can enable any combination of these options. However, you must select both check boxes if your server cannot parse delimiters.
-
Strip Identity Source Server from Username: Whether to remove the identity source name from the username before passing the username on to the AAA server. For example, if you select this option and the user enters domain\username as the username, the domain is stripped off from the username and sent to the AAA server for authentication. By default, this option is unchecked.
-
Strip Group from Username: Whether to remove the group name from the username before passing the username on to the AAA server. This option applies to names given in the username@domain format; the option strips the domain and @ sign. By default, this option is unchecked.
-
Secondary Identity Source
-
Secondary Identity Source for User Authorization: The optional second identity source. If the user successfully authenticates with the primary source, the user is prompted to authenticate with the secondary source. You can select an AD realm, RADIUS server group, or the local identity source.
-
Advanced options: Click the Advanced link and configure the following options:
-
Fallback Local Identity Source for Secondary: If the secondary source is an external server, you can select the LocalIdentitySource as a fallback in case the secondary server is unavailable. If you use the local database as a fallback source, ensure that you define the same local usernames/passwords as the ones defined in the secondary external server.
-
Use Primary Username for Secondary Login: By default, when using a secondary identity source, the system will prompt for both username and password for the secondary source. If you select this option, the system prompts for the secondary password only and uses the same username for the secondary source that was authenticated against the primary identity source. Select this option if you configure the same usernames in both the primary and secondary identity sources.
-
Username for Session Server: After successful authentication, the username is shown in events and statistical dashboards, is used for determining matches for a user- or group-based SSL decryption and access control rules and is used for accounting. Because you are using two authentication sources, you need to tell the system whether to use the Primary or Secondary username as the user identity. By default, the primary name is used.
-
Password Type: How to obtain the password for the secondary server. The default is Prompt, which means the user is asked to enter the password. Select Primary Identity Source Password to automatically use the password entered when the user authenticated to the primary server. Select Common Password to use the same password for every user, then enter that password in the Common Password field.
-
-
Authorization Server: The RADIUS server group that has been configured to authorize remote access, VPN users. After authentication is complete, authorization controls the services and commands available to each authenticated user. Authorization works by assembling a set of attributes that describe what the user is authorized to perform, their actual capabilities, and restrictions. Were you not to use authorization, authentication alone would provide the same access to all authenticated users.
Note that if the system obtains authorization attributes from the RADIUS server that overlap those defined in the group policy, the RADIUS attributes override the group policy attributes.
-
Accounting Server: (Optional.) The RADIUS server group to use to account for the remote access VPN session. Accounting tracks the services users are accessing as well as the number of network resources they are consuming. The ASA device reports user activity to the RADIUS server. Accounting information includes when sessions start and stop, usernames, the number of bytes that pass through the device for each session, the service used, and the duration of each session. You can then analyze the data for network management, client billing, or auditing. You can use accounting alone or together with authentication and authorization.
-
Configure Certificate Authentication for a Connection Profile
Note |
This section is not applicable for Authentication Type as AAA Only. |
You can use certificates installed on the client device to authenticate remote access VPN connections.
When using client certificates, you can still configure a secondary identity source, fallback source, and authorization and accounting servers. These are AAA options; for details, see Configure ASA Remote Access VPN Connection Profile.
The following are the certificate-specific attributes. You can configure these attributes separately for primary and secondary identity sources. Configuring a secondary source is optional.
-
Username from Certificate: Select one of the following:
-
Map Specific Field: Use the certificate elements in the order of Primary Field and Secondary Field. The defaults are CN (Common Name) and OU (Organizational Unit). Select the options that work for your organization. The fields are combined to provide the username, and this is the name used in events, dashboards, and for matching purposes in SSL decryption and access control rules.
-
Use entire DN (distinguished name) as username: The system automatically derives the username from the DN fields.
-
-
Advanced options (not applicable for Authentication Type as Client Certificate Only): Click the Advanced link and configure the following options:
-
Prefill username from certificate on user login window: Whether to fill in the username field with the retrieved username when prompting the user to authenticate.
-
Hide username in login window: If you select the Prefill option, you can hide the username, which means the user cannot edit the username in the password prompt.
-
Configure Client Address Pool Assignment
There must be a way for the system to provide an IP address to endpoints that connect to the remote access VPN. The AAA server can provide these addresses, a DHCP server, an IP address pool configured in the group policy, or an IP address pool configured in the connection profile. The system tries these resources in that order and stops when it obtains an available address, which it then assigns to the client. Thus, you can configure multiple options to create a failsafe in case of an unusual number of concurrent connections.
Use one or more of the following methods to configure the address pool for a connection profile.
-
IPv4 Address Pool and IPv4 Address Pool: First, create up to six network objects that specify subnets. You can configure separate pools for IPv4 and IPv6. Then, select these objects in the IPv4 Address Pool and IPv6 Address Pool options, either in the group policy or in the connection profile. You do not need to configure both IPv4 and IPv6, configure the addressing scheme you want to support. You also do not need to configure the pool in both the group policy and the connection profile. The group policy overrides the connection profile settings, so if you configure the pools in the group policy, leave the options empty in the connection profile. Note that the pools are used in the order in which you list them.
-
DHCP Servers: First, configure a DHCP server with one or more IPv4 address ranges for the remote access VPN (you cannot configure IPv6 pools using DHCP). Then, create a host network object with the IP address of the DHCP server. You can then select this object in the DHCP Servers attribute of the connection profile.
Manage AnyConnect Software Packages on ASA Devices
You can perform one of the following steps to upload an AnyConnect package using the remote access VPN wizard:
-
Upload the package from the Security Cloud Control repository.
-
Upload the package from the server using HTTP, HTTPS, TFTP, FTP, SMB, or SCP protocols.
Upload an AnyConnect Package from Security Cloud Control Repository
The remote access VPN Configuration wizard presents AnyConnect packages per operating system from the Security Cloud Control repository, which you can select and upload to device. Make sure that the device has access to the internet and proper DNS configuration.
Note |
If the desired package is unavailable in the presented list or the device has no access to the internet, you can upload the package using the server where the AnyConnect packages are preloaded. |
Procedure
|
Step 1 |
Click on the field that corresponds to an operating system and select an AnyConnect package. |
|
Step 2 |
Click |
to upload the package. If the checksum doesn't match, the AnyConnect package upload fails. You can see the device's workflow
tab for more details about the failure.
Upload an AnyConnect Package to ASA from Server
Download the AnyConnect client software packages to your computer and upload them to a remote server accessible from ASAs. Later, use the RA VPN wizard or ASA File Management wizard to upload the AnyConnect software packages from that server to ASAs. DNS must be configured correctly on the device for URLs that use a domain name.
The ASA RA VPN wizard supports uploading packages using HTTP, HTTPS, TFTP, FTP, SMB, or SCP protocols.
The syntax of supported protocols for uploading the file:
|
Protocol |
Syntax |
Example |
|---|---|---|
| HTTP | http://[[path/ ]filename] | http://www.geonames.org/data-sources.html |
| HTTPS | https://[[path/ ]filename] | https://docs.aws.amazon.com/amazov/tagging.html |
| TFTP | tftp://[[path/ ]filename] | tftp://10.10.16.6/ftd/components.html |
| FTP | ftp://[[user[:password]@]server[:port]/[path/ ]filename] | ftp://'dlpuser:rNrKYTX9g7z3RgJRmxWuGHbeu'@ftp.dlptest.com/image0-000.jpg |
| SMB | smb://[[path/ ]filename] | smb://10.10.32.145//sambashare/hello.txt |
| SCP | scp://[[user[:password]@]server[/path]/ filename] | scp://root:cisco123@10.10.16.6//root/events_send.py |
Before you begin
Important |
If you choose to upload the package using the ASA File Management wizard, do not modify the package's name after downloading them. |
Note |
You can upload one AnyConnect package per Operating System (OS): Windows, Mac, and Linux. You cannot upload multiple versions for a given OS type. |
Procedure
|
Step 1 |
Download the AnyConnect packages from https://software.cisco.com/download/home/283000185.
|
||
|
Step 2 |
Upload the AnyConnect packages to a remote server. Ensure that there is a network route from the ASA device and the server. The ASA RA VPN wizard supports uploading packages HTTP, HTTPS, TFTP, FTP, SMB, or SCP protocols.
|
||
|
Step 3 |
The remote server's URL must be a direct link without prompting for authentication. If the URL is pre-authenticated, you can download the file by specifying the RA VPN wizard's URL. |
||
|
Step 4 |
If the remote server IP address is NATed, you have to provide the NATed public IP address of the remote server location. |
Upload new AnyConnect Packages to ASA
You can either use the remote access VPN wizard or ASA File Management wizard to upload the AnyConnect software packages to ASAs.
Use the following procedure to upload new AnyConnect packages to an ASA device from an HTTP or HTTPS server:
Procedure
|
Step 1 |
In the AnyConnect Package Detected, you can upload separate packages for Windows, Mac, and Linux endpoints. |
|
Step 2 |
In the corresponding platform field, specify the server's paths where the AnyConnect packages compatible for Windows, Mac, and Linux are pre-uploaded. Examples of server paths: 'http://<ip_address>:port_number/<folder_name>/anyconnect-win-4.8.01090-webdeploy-k9.pkg', 'https://<ip_address>:port_number/<folder_name>/anyconnect-linux64-4.7.03052-webdeploy-k9.pkg'. |
|
Step 3 |
Click |
|
Step 4 |
Click OK. The AnyConnect packages are added to the remote access VPN configuration. |
|
Step 5 |
Continue to Create an ASA RA VPN Configuration from step 5 onwards. |
to upload the package. What to do next
To complete a VPN connection, your users must install the AnyConnect client software on their workstation. For more information, see How Users Can Install the AnyConnect Client Software on ASA.
Upload AnyConnect Packages using File Management Wizard
Use the File Management wizard to upload AnyConnect packages to a single or multiple ASA devices from an HTTP, HTTPS, TFTP, FTP, SMB, or SCP server. When you want to push AnyConnect packages to multiple ASA devices simultaneously, the bulk upload comes in handy. For more information, see ASA File Management.
Important |
If you choose to upload the package using the ASA File Management wizard, do not modify the package's name after downloading them. |
Once the upload is complete, open the ASA RA VPN Configuration wizard and notice that the packages are auto-detected. If you upload multiple packages for an OS version, the wizard lists them in a drop-down allowing you to select one among them. Then, you can create the RA VPN configuration and deploy them to the devices.
Replace an AnyConnect Package
If the AnyConnect packages are already present on the devices, you can see them in the remote access VPN wizard. You can see all the available AnyConnect packages for an operating system in a drop-down list. You can select an existing package from the list and replace it with a new one but can't add a new package to the list.
Note |
If you want to replace an existing package with a new one, ensure that the new AnyConnect package is uploaded already to a server on the network that the ASA can reach. |
Procedure
|
Step 1 |
In the left pane, click . |
|
Step 2 |
Select the remote access VPN configuration to be modified, and under Actions, click Edit. |
|
Step 3 |
In AnyConnect Packages Detected, click |
|
Step 4 |
Specify the server's path where the new AnyConnect package is preloaded and click |
|
Step 5 |
Click OK. The new AnyConnect package is added to the remote access VPN configuration. |
|
Step 6 |
Continue to Create ASA Remote Access VPN Configuration from step 6 onwards. |
icon appearing beside the existing AnyConnect package. If there are multiple versions of AnyConnect package for an operating
system, select the package you want to replace from the list and click Delete an AnyConnect Package
Procedure
|
Step 1 |
In the left pane, click . |
||
|
Step 2 |
Select the remote access VPN configuration to be modified, and under Actions, click Edit. |
||
|
Step 3 |
In AnyConnect Packages Detected, click
|
||
|
Step 4 |
Click OK. The device's Configuration Status is in 'Not Synced' state.
|
||
|
Step 5 |
icon appearing beside the AnyConnect package that you want to delete. If there are multiple versions of AnyConnect package
for an operating system, select the package you want to delete from the list. The existing package disappears from the corresponding
field.
Manage and Deploy Pre-existing ASA Remote Access VPN Configuration
When you onboard an ASDM managed ASA device that already has remote access VPN settings, it discovers and displays the existing remote access VPN configurations. Security Cloud Control automatically creates a "Default remote access VPN Configuration" and associates the ASA device with this configuration. There are some remote access VPN configurations that aren't read or supported in the Security Cloud Control but can be configured in the Security Cloud Control command-line interface.
Note |
This section doesn't cover every supported or unsupported configuration in Security Cloud Control. Instead, it only describes the most commonly used ones. |
To see the remote access VPN configurations from an onboarded ASA, perform the following steps:
Procedure
|
Step 1 |
In the left pane, click . |
|
Step 2 |
Click the remote access VPN configuration corresponding to the onboarded ASA device. Security Cloud Control automatically creates a "Default_RA_VPN_Configuration" and associates the ASA device with this configuration. You can delete the default configuration. The ASA remote access VPN configurations that are read in Security Cloud Control are classified as follows:
|
Device Settings
The RA VPN configurations associated with the onboarded ASA device appear in Default_RA_VPN_Configuration. You need to click on this configuration to see the name of the ASA device (in the Devices pane on the right) associated with that configuration. You can also see the AnyConnect packages present in the ASA devices by clicking the edit button.
Connection Profile
Security Cloud Control supports and reads the connection profiles defined in "AnyConnect Client VPN Access" of the ASA device. It does not support the "Clientless SSL VPN Access" configuration.
To see the connection profile attributes, perform the following:
Procedure
|
Step 1 |
Expand Default_RA_VPN_Configuration. |
|
Step 2 |
Click one of the connection profiles that you want and click Edit. |
All the basic and advanced ASA RA VPN attributes can be seen in the Connection Profile name and details of the Security Cloud Control RA VPN configuration page.
Note |
You can delete the default configuration (Select the default RA VPN configuration and in the Actions pane on the right, click Remove). |
Primary Identity Source
-
Security Cloud Control reads the Connection Aliases and Group URLs attributes as Group Alias and Group URL.
Note
-
The connection profiles configured with SAML, Multiple certificates and AAA, and Multiple certificates aren't read.
-
The authentication server group with the interface and server group is not supported.
-
-
Security Cloud Control supports the AnyConnect connection profiles configured with "AAA", "AAA and certificate", and "Certificate only" authentication methods in Primary Identity Source.
-
The AAA Server Group is read in Security Cloud Control as Primary Identity Source for User Authentication inPrimary Identity Source (You can see this attribute by selecting AAA or AAA and Client Certificate as the Authentication Type).
-
If the AAA Server Group has been configured something other than LOCAL, Security Cloud Control reads and displays this attribute in the Fallback Local Identity Source field under Primary Identity Source. (You can see this attribute by selecting AAA as the authentication type).
To learn more about the server group attributes read in Security Cloud Control, see AAA Server Groups.
-
Secondary Identity Source
The Secondary Identity Source displays the secondary authentication attributes of the ASA device. To see these attributes, select AAA or AAA and Client Certificate as the authentication type, and click View Secondary Identity Source.
-
The Secondary Identity Source for User Authentication displays the secondary authentication Server Group attribute.
-
If the Server Group has been configured something other than LOCAL, Security Cloud Control reads and displays this attribute in the Fallback Local Identity Source for Secondaryfield under Secondary Identity Source.
-
-
Security Cloud Control doesn't support the Attribute Server and Interface-Specific Authorization Server Groups attributes.
To learn more about the server group attributes read in Security Cloud Control, see AAA Server Groups.
Authorization Server
-
The Authorization Server displays the authorization Server Group attribute.
-
Security Cloud Control doesn't support the authorization server group with interface and server group.
To learn more about the RADIUS server group attributes read in Security Cloud Control, see RADIUS Server Groups.
Accounting Server
The Accounting Server displays the accounting Server Group attribute. To learn more about the server group attributes read in Security Cloud Control, see RADIUS Server Groups.
Client Address Pool Assignment
Security Cloud Control reads the Client Address Assignment attributes (DHCP Servers, Client Address Pools, and Client IPv6 Address Pools) as objects. (You can see these attributes in Client Address Pool Assignment). The DHCP server details are read as literals.
Note |
Security Cloud Control doesn't support the IP address pools assigned on specific interfaces. However, these attributes can be seen in the ASA command-line interface (CLI). |
AAA Server Groups
Security Cloud Control represents an LDAP Server Group and its associated LDAP Servers as an Active Directory Realm object. For Active Directory (AD), a realm is equivalent to an Active Directory domain. Note that Security Cloud Control does read the AD password for AD realm objects that are already present.
Procedure
|
Step 1 |
In the navigation bar on the left, choose Objects. |
|
Step 2 |
Apply the Active Directory Realms filter to see this object. |
|
Step 3 |
Select the Active Directory Realm object that you want and click Edit to see its details. |
What to do next
You can see that the AD realm contains the associated AD server and its configuration. If there are multiple Active Directory (AD) servers for the AD realm, the AD servers need to be duplicates of each other and support the same AD domain. Therefore, the basic realm properties such as Directory name, Directory Password, and Base Distinguished Name must be the same across all AD servers associated with that AD realm. Security Cloud Control displays a warning message in the Active Directory Realm object if these properties aren't the same. You have to correct these properties to make them consistent across the AD servers. If you continue without addressing this warning, Security Cloud Control uses one of the AD server properties and applies it to other servers in that realm object.
RADIUS Server Group
The AAA RADIUS Server Group attributes of the ASA device are read in Security Cloud Control as RADIUS Server Group objects.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Apply the RADIUS Server Group filter to see this object. |
|
Step 3 |
Select the object that you want and then click Edit to see its details.
|
RADIUS Server
When Security Cloud Control reads the Radius Servers from ASA, it creates a Radius server object specifies the name as "Name of the Radius server group_server name or IP address".
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Apply the RADIUS Server filter to see this object. |
|
Step 3 |
Select the object that you want and then click Edit to see its details. |
Group Policy
In the Group Policy section, click the drop-down to view the group policies associated with the device.
Attention |
Security Cloud Control reads the group policies configured with tunneling protocol as SSL VPN Client. |
Security Cloud Control reads most of the group policy attributes configured in ASA. The information is displayed across the tabs in the RA VPN Group policy wizard. To see the details of group policies read from the ASA device, you need to perform the following:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Filter for RA VPN Group Policy. |
|
Step 3 |
Select the group policy associated with that device and click Edit. |
What to do next
Note |
Security Cloud Control doesn't support the Standard Access Control Lists (ACL) defined in the split tunneling in the ASA device. It supports the Extended Access Control Lists (ACL) and reads them as ACLs in the ASA policies. To see the policies, on the navigation bar, you can click Policies > ASA Access Policies. |
To select the extended ACLs, perform the following:
-
Click the Split Tunneling tab.
-
Based on whether the traffic in ASA uses IPv4 or IPv6 addresses, select "Allow specified traffic over tunnel" or "Exclude networks specified below" from the corresponding drop-down list. Select the extended ACLs that are imported from ASA.
Create IP Address Pool
You can configure IPv4 and IPv6 IP address pools for ASAs to assign them to clients connecting remotely to your network using a VPN connection. The order in which you specify the pools is important. If you configure more than one address pool for a connection profile or group policy, the ASA uses them in the order in which you added them to the ASA.
To define the IPv4 address pool, provide the IP address range. An example of an IPv4 address pool is 10.10.147.100 - 10.10.147.177.
To define the IPv6 address pool, provide a starting IP address range, the address prefix, and the number of addresses configurable in the pool. An example of an IPv6 address pool is 2001:DB8:1::1.
If you assign addresses from a non-local subnet, we suggest that you add pools that fall on subnet boundaries to make adding routes for these networks easier.
Perform the following to create an IP address pool:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
In the left pane, click Objects. |
|
Step 3 |
Click the blue plus button |
|
Step 4 |
In the Create IP Address Pool dialog box, enter this information:
|
|
Step 5 |
Click Save. |
Remote Access VPN Certificate-Based Authentication
The remote access VPN uses digital certificates for authenticating secure gateways and AnyConnect clients (endpoints) in the following scenarios:
Important |
Security Cloud Control handles the installation of digital certificates on the VPN headends (ASA FTD). It does not handle the installation of certificates on the AnyConnect client device. The administrator of your organization must handle it. |
-
Identify and authenticate the VPN headend device (ASA FTD):
VPN headends require an identity certificate to identify and authenticate themselves when the AnyConnect client requests a VPN connection. Using Security Cloud Control, you must install the identity certificate on the device. See Installing an Identity Certificate Using PKCS12 or Certificate And Key. It is not mandatory to install the issuer's CA certificate on the AnyConnect client.
While creating the Remote Access VPN configuration from Security Cloud Control, assign the enrolled identity certificate to the outside interface of the device and download the configuration to the device. The identity certificate becomes fully operational on the outside interface of the device.
When the AnyConnect client attempts to connect to VPN, the device authenticates itself by presenting its identity certificate to the AnyConnect client. The AnyConnect client verifies this identity certificate with its trusted CA certificate and trusts the certificate and thereby the device. If the CA certificate isn’t installed on the AnyConnect client, the user must manually trust the device when prompted.
-
Identify and authenticate the AnyConnect client:
Note
This applies when you use "Client Certificate Only" or "AAA and Client Certificate" as the authentication method in the connection profile of remote access VPN configuration. It does not apply for "AAA Only".
Once the device is trusted, the AnyConnect client needs to authenticate itself to complete the VPN connection. You must install an identity certificate on the AnyConnect client and using Security Cloud Control, install a trusted CA certificate on the device. These certificates must be issued from the same certificate authority. See Installing Trusted CA Certificate in ASA.
The AnyConnect client presents its identity certificate and the device verifies this certificate with its trusted CA certificate and establishes the VPN connection.
Exempt Remote Access VPN Traffic from NAT
Configure NAT Exempt to exempt traffic to and from the remote access VPN endpoints from NAT translation. If you do not exempt VPN traffic from NAT, ensure that the existing NAT rules for the outside and inside interfaces do not apply to the remote access VPN pool of addresses. NAT exempt rules are manual static identity NAT rules for a given source/destination interface and network combination, but they are not reflected in the NAT policy, they are hidden. If you enable NAT Exempt, you must also configure the following.
-
Inside Interfaces: Select the interfaces for the internal networks remote users will be accessing. NAT rules are created for these interfaces.
-
Inside Networks: Select the network objects that represent internal networks remote users will be accessing. The networks list must contain the same IP types as the address pools you are supporting.
Before you begin
Create ASA network objects that match the configuration of the local IP address pools used in the connection profile and group policy of that device. These network objects must be assigned as the destination address and translated address when configuring the NAT rule.
Procedure
|
Step 1 |
In the left pane, click . |
|
Step 2 |
Use the filter and search field to find the ASA device for which you want to create the NAT rule. |
|
Step 3 |
In the Management area of the details panel, click NAT |
|
Step 4 |
Click
|
|
Step 5 |
Install the AnyConnect Client Software on ASA
To complete a VPN connection, your users must install the AnyConnect client software. You can use your existing software distribution methods to install the software directly. Or, you can have users install the AnyConnect client directly from the ASA device.
Note |
Users must have Administrator rights on their workstations to install the software. |
If you decide to have users initially install the software from the ASA device, inform users to perform the following steps:
Note |
Android and iOS users should download AnyConnect from the appropriate App Store. |
Procedure
|
Step 1 |
Using a web browser, open https://ravpn-address, where ravpn-address is the IP address or hostname of the outside interface on which you are allowing VPN connections. You identify this interface when you configure the remote access VPN. The system prompts the user to log in. |
|
Step 2 |
Log into the site. Users are authenticated using the directory server configured for the remote access VPN. Log in must be successful to continue. If the login is successful, the system determines if the user already has the required version of the AnyConnect client. If the AnyConnect client is absent from the user's computer or is down-level, the system automatically starts installing the AnyConnect software. When the installation is finished, AnyConnect completes the remote access VPN connection. |
Modify ASA Remote Access VPN Configuration
When ASA devices are onboarded to Security Cloud Control, it discovers and displays the pre-existing remote access VPN configurations from onboarded ASA devices. For more information, see Manage and Deploy Pre-existing ASA Remote Access VPN Configuration.
You can modify these configurations and download the new configuration to the device.
Procedure
|
Step 1 |
In the left pane, click . |
|
Step 2 |
If you want to add or remove group policies to the VPN configuration, click the VPN configuration associated with the onboarded ASA device. In the Actions pane on the left, click Group Policies.
|
|
Step 3 |
Click the VPN configuration, and in the Actions pane, click Edit. The wizard lists the ASA device associated with the configuration. |
|
Step 4 |
Click OK. |
|
Step 5 |
Modify ASA Connection Profile
Procedure
|
Step 1 |
In the left pane, click . |
|
Step 2 |
Expand the VPN configuration associated with the onboarded ASA device, and select a connection profile. |
|
Step 3 |
Under Actions, click Edit. |
|
Step 4 |
Edit the values in the same fashion as it was created and click Done. For more information, see Configure ASA Remote Access VPN Connection Profile |
|
Step 5 |
Upload RA VPN AnyConnect Client Profile
The Remote Access VPN AnyConnect Client Profile is a group of configuration parameters stored in a file. There are different AnyConnect client profiles containing configuration settings for the core client VPN functionality and for the optional client modules Network Access Manager, AMP Enabler, ISE posture, Network Visibility, Customer Feedback Experience profiles, Umbrella roaming security, and Web Security.
Security Cloud Control allows uploading of these profiles as objects which can be used in the group policy later.
-
AnyConnect VPN Profile — AnyConnect client profiles are downloaded to clients along with the VPN AnyConnect client software. These profiles define many client-related options, such as auto-connect on startup and auto-reconnect, and whether the end-user can change the option from the AnyConnect client preferences and advanced settings. Security Cloud Control supports the XML file format.
-
AMP Enabler Service Profile — The profile is used for the AnyConnect AMP Enabler. The AMP Enabler and this profile are pushed to the endpoints from FDM-managed device when a remote access VPN user connects to the VPN. Security Cloud Control supports XML and ASP file formats.
-
Feedback Profile — You can add a Customer Experience Feedback profile and select this type to receive information about the features and modules customers have enabled and used. Security Cloud Control supports the FSP file format.
-
ISE Posture Profile — Choose this option if you add a profile file for the AnyConnect ISE Posture module. Security Cloud Control supports XML and ISP file formats.
-
Network Access Manager Service Profile — Configure and add the NAM profile file using the Network Access Manager profile editor. Security Cloud Control supports XML and NSP file formats.
-
Network Visibility Service Profile — Profile file for AnyConnect Network Visibility module. You can create the profile using the NVM profile editor. Security Cloud Control supports XML and NVMSP file formats.
-
Umbrella Roaming Security Profile — You must select this file type if you deploy the Umbrella Roaming Security module. Security Cloud Control supports XML and JSON file formats.
-
Web Security Service Profile — Select this file type when you add a profile file for the Web security module. Security Cloud Control supports XML, WSO, and WSP file formats.
Before you begin
Use the suitable GUI-based AnyConnect profile editors to create the profiles you need. You can download the profile editors from Cisco Software Download Center in the AnyConnect Secure Mobility Client category and install the AnyConnect “Profile Editor - Windows / Standalone installer (MSI).” The profile editor installer contains stand-alone versions of the profile editors. The installation file is for Windows only and has the file name anyconnect-profileeditor-win-<version>-k9.msi, where <version> is the AnyConnect version. For example, anyconnect-profileeditor-win-4.3.04027-k9.msi. You must also install Java JRE 1.6 (or higher) before installing the profile editor.
Except for the Umbrella Roaming Security profile editor, this package contains all the profile editors required for creating the modules. For detailed information, see the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect Secure Mobility Client Administrator Guide for details. Download the Umbrella Roaming Security profile separately from the Umbrella dashboard. For detailed information, see the "Download the AnyConnect Roaming Security Profile from the Umbrella Dashboard" section of the "Umbrella Roaming Security" chapter in the Cisco Umbrella User Guide.
Procedure
|
Step 1 |
In the left pane, choose Manage > Objects. |
|
Step 2 |
Click the blue plus |
|
Step 3 |
Click . |
|
Step 4 |
In the Object Name field, enter a name for the AnyConnect client profile. |
|
Step 5 |
Click Browse and select the file you created using the Profile Editor. |
|
Step 6 |
Click Open to upload the profile. |
|
Step 7 |
Click Add to add the object. |
Verify ASA Remote Access VPN Configuration
After you configure the remote access VPN and deploy the configuration to the device, verify that you can make remote connections.
Procedure
|
Step 1 |
From an external network, establish a VPN connection using the AnyConnect client. Using a web browser, open https://ravpn-address, where ravpn-address is the IP address or hostname of the outside interface on which you are allowing VPN connections. If necessary, install the client software and complete the connection. See How Users Can Install the AnyConnect Client Software. If you configured group URLs, also try those URLs. |
|
Step 2 |
In the Security Devices page, select the device (FTD or ASA) you want to verify and click Command Line Interface under Device Actions. |
|
Step 3 |
Use the show vpn-sessiondb command to view summary information about current VPN sessions. |
|
Step 4 |
The statistics should show your active AnyConnect Client session, and information on cumulative sessions, the peak concurrent
number of sessions, and inactive sessions. Following is sample output from the command. |
|
Step 5 |
Use the show vpn-sessiondb anyconnect command to view detailed information about current AnyConnect VPN sessions. Detailed information includes encryption used, bytes transmitted and received, and other statistics. If you use your VPN connection, you should see the bytes transmitted/received numbers change as you re-issue this command. |
|
Step 6 |
Use the show vpn-sessiondb anyconnect command to view detailed information about current AnyConnect VPN sessions. Detailed information includes encryption used,
bytes transmitted and received, and other statistics. If you use your VPN connection, you should see the bytes transmitted/received
numbers change as you re-issue this command. |
View ASA Remote Access VPN Configuration Details
Procedure
|
Step 1 |
In the left pane, choose |
|
Step 2 |
In the left pane, click . |
|
Step 3 |
Click on a VPN configuration object present. The group shows summary information on how many connection profiles and group policies are currently configured.
|
) to open a summary of the connection profile and connection instructions. Under Configuring Remote Access VPN for an FDM-Managed Device
Security Cloud Control provides an intuitive user interface for configuring a new Remote Access Virtual Private Network (RA VPN). It also allows you to quickly and easily configure RA VPN connection for multiple FDM-managed devices that are on board in Security Cloud Control. AnyConnect is the only client that is supported on endpoint devices for an RA VPN connectivity to FDM-managed devices.
When the AnyConnect client negotiates an SSL VPN connection with the FDM-managed device, it connects using Transport Layer Security (TLS) or 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. The client and the FDM-managed device negotiate the TLS/DTLS version to use. DTLS is used if the client supports it.
Security Cloud Control supports the following aspects of RA VPN functionality on FDM-managed devices:
-
SSL client-based remote access
-
IPv4 and IPv6 addressing
-
Shared RA VPN configuration across multiple FDM-managed devices
Important |
If an onboarded FDM-managed device (running on software version 6.7 or later) contains RA VPN configuration with SAML server as the authentication source, Security Cloud Control doesn't populate the AAA details in the connection profile as it doesn't manage SAML server objects in the current release. Thus you can't manage such RA VPN configuration from Security Cloud Control. However, Security Cloud Control reads the RA VPN connection profile and associated trusted CA certificate and SAML server objects. |
Split Tunneling for RA VPN Users (Hair Pinning)
This article describes the split tunneling for RA VPN.
Typically, in remote access VPN, you might want the VPN users to access the Internet through your device. However, you can allow your VPN users to access an outside network while they are connected to an RA VPN. This technique is called split tunneling or hair pinning. The split tunnel allows VPN connectivity to a remote network across a secure tunnel, and it also allows connectivity to a network outside the VPN tunnel. Split tunneling reduces the network load on the FDM-managed devices and increases the bandwidth on the outside interface.
To configure a split-tunnel list, you must create a Standard Access List or Extended Access List. Follow the instructions explained in the How to Provide Internet Access on the Outside Interface for Remote Access VPN Users (Hair Pinning) section of Virtual Private Networks (VPN) chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.
Control User Permissions and Attributes Using RADIUS and Group Policies
This article provides information on applying attributes to RA VPN connections from an external RADIUS server or a group policy.
You can apply user authorization attributes (also called user entitlements or permissions) to RA VPN connections from an external RADIUS server or from a group policy defined on the FDM-managed device. If the FDM-managed device receives attributes from the external AAA server that conflict with those configured on the group policy, then attributes from the AAA server always take precedence.
The FDM-managed device applies attributes in the following order:
Procedure
|
Step 1 |
User attributes defined on the external AAA server - The server returns these attributes after successful user authentication or authorization. |
|
Step 2 |
Group policy configured on the FDM-managed device - If a RADIUS server returns the value of the RADIUS CLASS attribute IETF-Class-25 (OU= group-policy) for the user, the FDM-managed 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. |
|
Step 3 |
Group policy assigned by the connection profile - The connection profile has the preliminary settings for the connection and includes a default group policy applied to the user before authentication. All users connecting to the FDM-managed device initially belong to this group, which provides any attributes that are missing from the user attributes returned by the AAA server, or the group policy assigned to the user. |
FDM-managed devices support RADIUS attributes with vendor ID 3076. If the RADIUS server you use does not have these attributes defined, you must manually define them. To define an attribute, use the attribute name or number, type, value, and vendor code (3076).
The following topics explain the supported attributes based on whether the values are defined in the RADIUS server, or whether they are values the system sends to the RADIUS server.
Attributes Sent to the RADIUS Server
RADIUS attributes 146 and 150 are sent from the FDM-managed device to the RADIUS server for authentication and authorization requests. All the following attributes are sent from the FDM-managed device to the RADIUS server for accounting start, interim-update, and stop requests.
|
Attribute |
Attribute |
Syntax, Type |
Single or Multi-valued |
Description or Value |
|---|---|---|---|---|
|
Client Type |
150 |
Integer |
Single |
The type of client this is connecting to the VPN: 2= AnyConnect Client SSL VPN |
|
Session Type |
151 |
Integer |
Single |
The type of connection: 1 = AnyConnect Client SSL VPN |
|
Tunnel Group Name |
146 |
String |
Single |
The name of the connection profile that was used for establishing the session, as defined on the FDM-managed device. The name can be 1 - 253 characters. |
Attributes Received from the RADIUS Server
The following user authorization attributes are sent to the FDM-managed device from the RADIUS server.
| Attribute | Attribute Number | Syntax, Type | Single or Multi-valued | Description or Value |
|---|---|---|---|---|
| Access-List-Inbound | 86 | String | Single | Both Access-List attributes take the name of an ACL that is configured on the FDM-managed device. Create these ACLs in Firewall Device Manager using the Smart CLI Extended Access List object type (Log in to Firewall Device Manager and select Device > Advanced Configuration > Smart CLI > Objects). These ACLs control traffic flow in the inbound (traffic entering the FDM-managed device) or outbound (traffic leaving the FDM-managed device) direction. |
| Access-List-Outbound | 87 | String | Single | |
| Address-Pools | 217 | String | Single | The name of a network object defined on the FDM-managed device that identifies a subnet, which will be used as the address pool for clients connecting to the RA VPN. Define the network object on the Objects page. |
| Banner1 | 15 | String | Single | The banner to display when the user logs in. |
| Banner2 | 36 | String | Single | The second part of the banner to display when the user logs in. Banner2 is appended to Banner1. |
| Group-Policy | 25 | String | Single |
The group policy to use in the connection. You must create the group policy on the RA VPN Group Policy page. You can use one of the following formats:
|
| Simultaneous-Logins | 2 | Integer | Single | The number of separate simultaneous connections the user can establish, 0 - 2147483647. |
| VLAN | 140 | Integer | Single | The VLAN on which to confine the user's connection, 0 - 4094. You must also configure this VLAN on a subinterface on the FDM-managed device. |
Two-Factor Authentication
You can configure two-factor authentication for the RA VPN. With two-factor authentication, the user must supply a username and static password, plus an additional item such as a Duo passcode. Two-factor authentication differs from using a second authentication source in that two-factor is configured on a single authentication source, with the relationship to the Duo server tied to the primary authentication source. The exception is Duo LDAP, where you configure the Duo LDAP server as the secondary authentication source.
Duo Two-Factor Authentication Using RADIUS
You can configure the Duo RADIUS server as the primary authentication source. This approach uses the Duo RADIUS Authentication Proxy.
For the detailed steps to configure Duo, please see https://duo.com/docs/cisco-firepower.
You would then configure Duo to forward authentication requests directed to the proxy server to use another RADIUS server, or a Microsoft Active Directory(AD) server, as the first authentication factor, and the Duo Cloud Service as the second factor.
When using this approach, the user must authenticate using a username that is configured on both the Duo Authentication Proxy and the associated RADIUS/AD server, and the password for the username configured in the RADIUS/AD server, followed by one of the following Duo codes:
Duo-passcode. For example, my-password,12345.
push. For example, my-password,push. Use push to tell Duo to send a push authentication to the Duo Mobile app, which the user must have already installed and registered.
sms. For example, my-password,sms. Use sms to tell Duo to send an SMS message with a new batch of passcodes to the user’s mobile device. The user’s authentication attempt will fail when using sms. The user must then re-authenticate and enter the new passcode as the secondary factor.
phone. For example, my-password,phone. Use phone to tell Duo to perform phone callback authentication.
If the username and password are authenticated, the Duo Authentication Proxy contacts the Duo Cloud Service, which validates that the request is from a valid configured proxy device and then pushes a temporary passcode to the mobile device of the user as directed. When the user accepts this passcode, the session is marked authenticated by Duo and the RA VPN is established.
For a detailed explanation, see How to Configure Two-Factor Authentication using Duo RADIUS
How to Configure Two-Factor Authentication using Duo RADIUS
You can configure the Duo RADIUS server as the primary authentication source. This approach uses the Duo RADIUS Authentication Proxy.
You would then configure Duo to forward authentication requests directed to the proxy server to use another RADIUS server, or an AD server, as the first authentication factor, and the Duo Cloud Service as the second factor.
The following topics explain the configuration in more detail:
System Flow for Duo RADIUS Secondary Authentication
Following is an explanation of the system flow:
-
The user makes a remote access VPN connection to the FDM-managed device and provides username associated with RADIUS/AD server, the password for the username configured in the RADIUS/AD server, followed by one of the DUO codes, Duo-password, push, SMS, or phone. For more information, Duo Two-Factor Authentication Using RADIUS
-
FDM-managed device sends the authentication request to the Duo Authentication proxy.
-
Duo Authentication proxy authenticates this primary authentication attempt with the primary authentication server, which might be Active Directory or RADIUS.
-
If the credentials are authenticated, the Duo Authentication Proxy connection is established to Duo Security over TCP port 443.
-
Duo then authenticates the user separately through push notification, text message with a passcode, or a telephone call. The user must complete this authentication successfully.
-
Duo authentication proxy receives the authentication response.
-
If the secondary authentication was successful, the FDM-managed device establishes a remote access VPN connection with the user’s AnyConnect client.
Configure Duo RADIUS Secondary Authentication
Duo Authentication proxy authenticates this primary authentication attempt with the primary authentication server, which might be Active Directory or RADIUS.
Create a Duo Account
Create a Duo account and obtain the integration key, secret key, and API hostname.
Following is an overview of the process. For details, please see the Duo web site,
Procedure
|
Step 1 |
|
|
Step 2 |
Log in to the Duo Admin Panel and navigate to Applications. |
|
Step 3 |
Click Protect an Application and locate Cisco Firepower Threat Defense VPN in the applications list. |
|
Step 4 |
Click Protect this Application to get your integration key, secret key, and API hostname. You'll need this information when configuring the proxy. For help, see the Duo Getting Started guide, https://duo.com/docs/getting-started. |
|
Step 5 |
Install and configure the Duo Authentication Proxy. For instructions, see the "Install the Duo Authentication Proxy" section in https://duo.com/docs/cisco-firepower. |
|
Step 6 |
Start the Authentication Proxy. For instructions, see the "Start the Proxy" section in https://duo.com/docs/cisco-firepower. For enrolling new users in Duo, see https://duo.com/docs/enrolling-users. |
Configure Device for Duo RADIUS Using Security Cloud Control
Procedure
|
Step 1 |
Configure FTD Radius Server Object.
|
|
Step 2 |
Change the Remote Access VPN Authentication Method to Duo RADIUS.
|
|
Step 3 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Duo Two-Factor Authentication using LDAP
You can use the Duo LDAP server as the secondary authentication source along with a Microsoft Active Directory (AD) or RADIUS server as the primary source. With Duo LDAP, the secondary authentication validates the primary authentication with a Duo passcode, push notification, or phone call.
Note |
The Duo two-factor authentication feature is available in Security Cloud Control for devices running Firepower Threat version 6.5 or later. |
The FDM-managed device communicates with Duo LDAP using LDAPS over port TCP/636.
When using this approach, the user must authenticate using a username that is configured on both the AD/RADIUS server and the Duo LDAP server. When prompted to log in by AnyConnect, the user provides the AD/RADIUS password in the primary Password field, and for the Secondary Password, provides one of the following to authenticate with Duo. For more details, see the "Second Password for Factor Selection" section in https://guide.duo.com/anyconnect.
-
Duo passcode—Authenticate using a passcode, either generated with Duo Mobile, sent via SMS, generated by your hardware token, or provided by an administrator. For example, 1234567.
-
push—Push a login request to your phone, if you have installed and activated the Duo Mobile app. Review the request and tap Approve to log in.
-
phone—Authenticate using a phone callback.
-
sms—Request a Duo passcode in a text message. The login attempt will fail. Log in again using the new passcode.
For a detailed explanation, see How to Configure Two-Factor Authentication using Duo LDAP.
How to Configure Two-Factor Authentication using Duo LDAP
You can use the Duo LDAP server as the secondary authentication source along with a Microsoft Active Directory (AD) or RADIUS server as the primary source. With Duo LDAP, the secondary authentication validates the primary authentication with a Duo passcode, push notification, or phone call..
The following topics explain the configuration in more detail:
System Flow for Duo LDAP Secondary Authentication
The following graphic shows how Firewall Threat Defense and Duo work together to provide two-factor authentication using LDAP.
Following is an explanation of the system flow:
-
The user makes a remote access VPN connection to the FDM-managed device and provides username and password.
-
FDM-managed device authenticates this primary authentication attempt with the primary authentication server, which might be Active Directory or RADIUS.
-
If the primary authentication works, FDM-managed device sends a request for secondary authentication to the Duo LDAP server.
-
Duo then authenticates the user separately, through push notification, text message with a passcode, or a telephone call. The user must complete this authentication successfully.
-
Duo responds to the FDM-managed device to indicate whether the user authenticated successfully.
-
If the secondary authentication was successful, the FDM-managed device establishes a remote access VPN connection with the user’s AnyConnect client.
Configure Duo LDAP Secondary Authentication
The following procedure explains the end-to-end process of configuring two-factor authentication, using Duo LDAP as the secondary authentication source, for remote access VPN. You must have an account with Duo, and obtain some information from Duo, to complete this configuration.
Create a Duo Account
Create a Duo account and obtain the integration key, secret key, and API hostname.
Following is an overview of the process. For details, please see the Duo web site,
Procedure
|
Step 1 |
|
|
Step 2 |
Log in to the Duo Admin Panel and navigate to Applications. |
|
Step 3 |
Click Protect an Application and locate Cisco Firepower Threat Defense VPN in the applications list. |
|
Step 4 |
Click Protect this Application to get your Integration key, Secret key, and API hostname. For help, see the Duo Getting Started guide, https://duo.com/docs/getting-started. For enrolling new users in Duo, see https://duo.com/docs/enrolling-users. |
Upload a Trusted CA Certificate to an FDM-Managed Device
The FDM-managed device must have the trusted CA certificate needed to validate the connection to the Duo LDAP server. You can go directly to https://www.digicert.com/digicert-root-certificates.htm and download either DigiCertSHA2HighAssuranceServerCA or DigiCert High Assurance EV Root CA and upload it using Firewall Device Manager (FDM).
Procedure
|
Step 1 |
Access the Firewall Device Manager page of the FDM-managed device, choose Objects > Certificates. |
|
Step 2 |
Click + > Add Trusted CA Certificate. |
|
Step 3 |
Enter a name for the certificate, for example, DigiCert_High_Assurance_EV_Root_CA. (Spaces are not allowed.) |
|
Step 4 |
Click Upload Certificate and select the file that you downloaded. |
|
Step 5 |
Click OK. |
|
Step 6 |
Onboard the device to Security Cloud Control if you haven't onboarded it already. |
|
Step 7 |
Read Configuration Changes from FTD to Security Cloud Control. |
Configure FTD for Duo LDAP in Security Cloud Control
Procedure
|
Step 1 |
Create a Duo LDAP identity source object for the Duo LDAP server.
|
||
|
Step 2 |
(optional) Use the AnyConnect Profile Editor to create a profile that specifies 60 seconds or more for authentication timeout. You need to give users extra time to obtain the Duo passcode and complete the secondary authentication. We recommend at least 60 seconds. The following procedure explains how to configure the authentication timeout only and then upload the profile to FDM-managed device. If you want to change other settings, you can do so now.
|
||
|
Step 3 |
Create a group policy and select the AnyConnect profile in the policy. |
||
|
Step 4 |
Create or edit the remote access VPN connection profile to use for Duo-LDAP secondary authentication. The following procedure just mentions the key changes to enable Duo-LDAP as the secondary authentication source and apply the AnyConnect client profile. For new connection profiles, you must configure the rest of the required fields. For this procedure, we assume you are editing an existing connection profile, and you simply must change these two settings.
|
||
|
Step 5 |
End-to-End Remote Access VPN Configuration Process for an FDM-Managed Device
This section provides the end-to-end procedure for configuring Remote Access Virtual Private Network (RA VPN) on an FDM-managed device onboarded to Security Cloud Control.
To enable remote access VPN for your clients, you need to configure several separate items. The following procedure provides the end-to-end process.
Procedure
|
Step 1 |
Enable two licenses.
|
||
|
Step 2 |
Configure Certificates. Certificates are required to authenticate SSL connections between the clients and the device. You can use the pre-defined DefaultInternalCertificate for the VPN or create your own. |
||
|
Step 3 |
Configure the identity source used for authenticating remote users. You can use the following sources to authenticate users attempting to connect to your network using RA VPN. Additionally, you can use client certificates for authentication, either alone or in conjunction with an identity source.
|
||
|
Step 4 |
|||
|
Step 5 |
|||
|
Step 6 |
|||
|
Step 7 |
Important |
If you change the Remote Access VPN configuration by using a local manager like Firepower Device Manager, the Configuration Status of that device in Security Cloud Control shows "Conflict Detected". See Out-of-Band Changes on an FDM-Managed Device. You can Resolve Configuration Conflicts on this FDM-managed device. |
What to do next
Once the RA VPN configuration is downloaded to the FDM-managed devices, the users can connect to your network from a remote location using a computer or other supported iOS or Android device connected to the Internet. You can monitor live AnyConnect Remote Access Virtual Private Network (RA VPN) sessions from all onboarded RA VPN head-ends in your tenant.
Download AnyConnect Client Software Packages
Before configuring a remote access VPN, you must download the AnyConnect software packages from https://software.cisco.com/download/home/283000185 to your workstation. Ensure that you download the "AnyConnect Headend Deployment Package" for your desired operating systems. Later, you can upload these packages to FDM-managed devices when defining the VPN.
Always download the latest AnyConnect version, to ensure that you have the latest features, bug fixes, and security patches. Regularly update the packages on the device.
Note |
You can upload one AnyConnect package per Operating System (OS): Windows, Mac, and Linux. You cannot upload multiple versions for a given OS type. |
Upload AnyConnect Software Packages to an FDM-Managed Device Running Version 6.4.0
You can upload the AnyConnect software packages to the FDM-managed devices version 6.4.0 using Firewall Device Manager API explorer. A minimum of one AnyConnect software package must be present on the device to create an RA VPN connection.
Important |
The procedure applies only to Firewall Device Manager Version 6.4. If you are using Firewall Device Manager Version 6.5 or later, use the Security Cloud Control interface to upload the AnyConnect package. |
Use the following procedure to upload the AnyConnect package to Firewall Device Manager Version 6.4.0:
Procedure
|
Step 1 |
Download the AnyConnect packages from https://software.cisco.com/download/home/283000185.
|
|
Step 2 |
Using a browser, open the home page of the system. For example, https://ftd.example.com. |
|
Step 3 |
Log into Firewall Device Manager. |
|
Step 4 |
Edit the URL to point to /#/api-explorer, for example, https://ftd.example.com/#/api-explorer. |
|
Step 5 |
Scroll down and click |
|
Step 6 |
In fileToUpload field, click Choose File and select the required AnyConnect package. You can upload the packages one at a time. 
|
|
Step 7 |
Click Open. |
|
Step 8 |
Scroll down and click TRY IT OUT!. Wait until the package uploads completely. In the Response Body, the API response appears in the following format. https://ftd.example.com:972/api/fdm/...90d111e9-a361- cf32937ce0df.pkg Record the fileName of the package from the response as you must enter the same string when performing the POST operation. In this example, the fileName is 691f47e1-90c7-11e9-a361-79e2452f0c57.pkg. |
|
Step 9 |
Scroll up near the top of Firewall Threat Defense REST API page and click . Perform a POST operation to the API providing the temp staged diskFilename and the OS type of the package file in the payload. This action creates the AnyConnect package file. |
|
Step 10 |
In the body field, enter the package details in the following format only:
The AnyConnect package is created on Firewall Device Manager. |
|
Step 11 |
Click The Response Body shows all AnyConnect package files. A sample response is shown below. { |
|
Step 12 |
Upload other AnyConnect packages for each OS type. Repeat steps from 4 to 10. |
|
Step 13 |
Edit the URL to point to the web page, for example, https://ftd.example.com |
|
Step 14 |
Click the Deploy Changes icon in the upper right of the web page. The icon is highlighted with a dot when there are undeployed changes. |
|
Step 15 |
If you are satisfied with the changes, you can click Deploy Now to start the job immediately. The window will show that the deployment is in progress. You can close the window or wait for the deployment to complete. |
Note |
To delete a package from the FDM-managed device, click . In the objID field, type the package id and click TRY IT OUT!. |
To complete a VPN connection, your users must install the AnyConnect client software on their workstation. For more information, see How Users Can Install the AnyConnect Client Software on FDM-Managed Device.
Upload AnyConnect Software Packages to an FDM-Managed Device Running Version 6.5 or Later
If you're using an FDM-managed device, running version 6.5 or later, for configuring RA VPN, you can use the RA VPN wizard in Security Cloud Control to upload AnyConnect software packages to the device. In the RA VPN wizard, you must provide the URL of the remote HTTP or HTTPS server where the AnyConnect packages are preloaded.
Note |
You can upload the AnyConnect package using the FDM API procedure as well. |
Upload an AnyConnect Package from Security Cloud Control Repository
The remote access VPN Configuration wizard presents AnyConnect packages per operating system from the Security Cloud Control repository, which you can select and upload to device. Make sure that the device has access to the internet and proper DNS configuration.
Note |
If the desired package is unavailable in the presented list or the device has no access to the internet, you can upload the package using the server where the AnyConnect packages are preloaded. |
Procedure
|
Step 1 |
Click on the field that corresponds to an operating system and select an AnyConnect package. |
|
Step 2 |
Click |
Before you Begin
Make sure that you download the "AnyConnect Headend Deployment Package" for your desired operating systems. Always download the latest AnyConnect version, to ensure that you have the latest features, bug fixes, and security patches. Regularly update the packages on the device.
Note |
You can upload one AnyConnect package per Operating System (OS): Windows, Mac, and Linux. You cannot upload multiple versions for a given OS type. |
Procedure
|
Step 1 |
Download the AnyConnect packages from https://software.cisco.com/download/home/283000185.
|
||
|
Step 2 |
Upload the AnyConnect packages to a remote HTTP or HTTPS server. Ensure that there is a network route from the FDM-managed device to the HTTP or HTTPS server.
|
||
|
Step 3 |
The remote server's URL must be a direct link without prompting for authentication. If the URL is pre-authenticated, the file can be downloaded by specifying the RA VPN wizard's URL. |
||
|
Step 4 |
If the remote server IP address is NATed, you have to provide the NATed public IP address of the remote server location. |
Upload new AnyConnect Packages
Use the following procedure to upload a new AnyConnect packages to an FDM-managed device running Version 6.5.0:
Procedure
|
Step 1 |
|
|
Step 2 |
In the AnyConnect Package Detected, you can upload separate packages for Windows, Mac, and Linux endpoints. |
|
Step 3 |
In the corresponding platform field, specify the server's paths where the AnyConnect packages compatible for Windows, Mac, and Linux are pre-uploaded. Examples of server paths: 'http://<ip_address>:port_number/<folder_name>/anyconnect-win-4.8.01090-webdeploy-k9.pkg', 'https://<ip_address>:port_number/<folder_name>/anyconnect-linux64-4.7.03052-webdeploy-k9.pkg'. |
|
Step 4 |
Click |
|
Step 5 |
Click OK. The AnyConnect packages are added to the RA VPN configuration. |
|
Step 6 |
Continue to perform procedure in Create an RA VPN Configuration from here onwards. |
What to do next
To complete a VPN connection, users must install the AnyConnect client software on their workstation. For more information, see How Users Can Install the AnyConnect Client Software on FTD.
Replace an Existing AnyConnect Package
If the AnyConnect packages are already present on the devices, you can see them in the RA VPN wizard. You can see all the available AnyConnect packages for an operating system in a drop-down list. You can select an existing package from the list and replace it with a new one but can't add a new package to the list.
Note |
If you want to replace an existing package with a new one, ensure that the new AnyConnect package is uploaded already to a server on the network that the FDM-managed device can reach. |
Procedure
|
Step 1 |
In the left pane, click . |
|
Step 2 |
In the left pane, click . |
|
Step 3 |
Select the RA VPN configuration to be modified, and under Actions, click Edit. |
|
Step 4 |
In AnyConnect Packages Detected, click |
|
Step 5 |
Specify the server's path where the new AnyConnect package is preloaded and click |
|
Step 6 |
Click OK. The new AnyConnect package is added to the RA VPN configuration. |
|
Step 7 |
Continue to Create an RA VPN Configuration from step 6 onwards. |
Delete the AnyConnect Package
Procedure
|
Step 1 |
In the left pane, click . |
||
|
Step 2 |
In the left pane, click . |
||
|
Step 3 |
Select the RA VPN configuration to be modified, and under Actions, click Edit. |
||
|
Step 4 |
In AnyConnect Packages Detected, click
|
||
|
Step 5 |
Click OK. The device's Configuration Status is in 'Not Synced' state.
|
||
|
Step 6 |
Configure Identity Sources for FDM-Managed Device
Identity Sources, such as Microsoft AD realms and RADIUS Servers, are AAA servers and databases that define user accounts for the people in your organization. You can use this information in a variety of ways, such as providing the user identity associated with an IP address, or authenticating remote access VPN connections or access to Security Cloud Control.
Click Manage > Objects, then click and choose to create your sources. You would then use these objects when you configure the services that require an identity source.
You can apply appropriate filters to search existing sources and manage them.
Active Directory Realms
Active Directory provides user account and authentication information. When you deploy a configuration that includes an AD realm to an FDM-managed device, Security Cloud Control fetches users and groups from the AD server.
You can use this source for the following purposes:
-
Remote Access VPN, as a primary identity source. You can use AD in conjunction with a RADIUS server.
-
Identity policy, for active authentication and as the user identity source used with passive authentication.
-
Identity rule, for active authentication for a user.
Security Cloud Control requests an updated list of user groups once every 24 hours. Because you can add a maximum of 50 users or groups to a rule, selecting groups usually makes more sense than selecting individual users. For example, you could create a rule allowing the Engineering group access to a development network, and create a subsequent rule that denies all other access to the network. Then, to make the rule apply to new engineers, you only need to add the engineer to the Engineering group in the directory server.
Active Directory Realms In Security Cloud Control
You configure the AD realm when you create an AD Identity object. The identity source objects wizard assists in determining how to connect to the AD server and where the AD server is located in the network.
Note |
If you create an AD realm in Security Cloud Control, Security Cloud Control remembers the AD password when you create affiliate identity source objects and when you add those objects to an identity rule. |
Active Directory Realms In FDM
You can point to AD realm objects that were created in FDM from the Security Cloud Control objects wizard. Note that Security Cloud Control does not read the AD password for AD realm objects that are created in FDM. You must manually enter the correct AD password in Security Cloud Control.
To configure an AD realm in Firewall Device Managers, see the Configuring AD Identity Realms section of the Reusable Objects chapters of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.
Supported Directory Servers
You can use AD on Windows Server 2008 and 2012.
Note the following about your server configuration:
-
If you want to perform user control on user groups or on users within groups, you must configure user groups on the directory server. The system cannot perform user group control if the server organizes the users in a basic object hierarchy.
-
The directory server must use the field names listed in the following table in order for the system to retrieve user metadata from the servers for that field:
|
Metadata |
Active Directory Field |
|---|---|
| LDAP user name | samaccountname |
| First name | givename |
| Last Name | sn |
| email address |
userprincipalname (if mail has no value) |
| Department |
department distinguishedname (if department has no value) |
| Telephone number | telephonenumber |
Determining the Directory Base DN
When you configure directory properties, you need to specify the common base Distinguished Name (DN) for users and groups. The base is defined in your directory server and differs from network to network. You must enter the correct bases for identity policies to work. If the base is wrong, the system cannot determine user or group names, and thus identity-based policies will be inoperable.
Note |
To get the correct bases, consult the administrator who is responsible for the directory servers. |
For an active directory, you can determine the correct bases by logging into the AD server as a domain administrator, and using the dsquery command at a command prompt as follows to determine the bases:
User search base
Enter the dsquery user command with known username (partial or complete) to determine the base distinguished name. For example, the following command uses the partial name "John*" to return information for all users that start with "John."
C:\Users\Administrator>dsquery user -name "John*"
"CN=John Doe,CN=Users,DC=csc-lab,DC=example,DC=com"
The base DN would be "DC=csc-lab,DC=example,DC=com."
Group search base
Enter the dsquery group command with a known group name to determine the base DN. For example, the following command uses the group name Employees to return the distinguished name:
C:\>dsquery group -name "Employees"
"CN=Employees,CN=Users,DC=csc-lab,DC=example,DC=com"
The group base DN would be "DC=csc-lab,DC=example,DC=com."
You can also use the ADSI Edit program to browse the AD structure (). In ADSI Edit, right click any object, such as an organizational unit (OU), group, or user, and choose Properties to view the distinguished name. You can then copy the string of DC values as the base.
To verify that you have the correct base:
Procedure
|
Step 1 |
Click the Test Connection button in the directory properties to verify connectivity. Resolve any problems, and save the directory properties. |
|
Step 2 |
Commit changes to the device. |
|
Step 3 |
Create an access rule, select the Users tab, and try to add known user and group names from the directory. You should see auto-complete suggestions as you type for matching users and groups in the realm that contains the directory. If these suggestions appear in a drop-down list, then the system was able to query the directory successfully. If you see no suggestions, and you are certain the string you typed should appear in a user or group name, you need to correct the corresponding search base. |
What to do next
See Create and Edit a Firepower Threat Defense Active Directory Realm Object for more information.
RADIUS Servers and Groups
You can use RADIUS servers to authenticate and authorize administration users.
When you configure a feature to use RADIUS servers, you select a RADIUS group instead of individual servers. A RADIUS group is a collection of RADIUS servers that are copies of each other. If a group has more than one server, they form a chain of backup servers to provide redundancy in case one server becomes unavailable. But even if you have only one server, you must create a one-member group to configure RADIUS support for a feature.
You can use this source for the following purposes:
-
Remote Access VPN, as an identity source for authentication, and for authorization and accounting. You can use AD in conjunction with a RADIUS server.
-
Identity policy, as a passive identity source to collect user identity from remote access VPN logins.
See Create and Edit a Firepower Threat Defense RADIUS Server Object or Group for more information.
Create or Edit an Active Directory Realm Object
About Active Directory Realm Objects
When you create or edit an identity source object such as an AD realm object, Security Cloud Control sends the configuration request to the FDM-managed devices through the SDC. The FDM-managed device then communicates with the configured AD realm.
Note that Security Cloud Control does not read the Directory Password for AD realms that are configured through the Firewall Device Manager console. If you use an AD realm object that was originally created in Firewall Device Manager, you must manually enter the Directory Password.
Create an FTD Active Directory Realm Object
Use the following procedure to create an object:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
||
|
Step 2 |
Click |
||
|
Step 3 |
Enter an Object Name for the object. |
||
|
Step 4 |
Select the Device Type is as FTD. |
||
|
Step 5 |
In the first part of the wizard, select Active Directory Realm as the Identity Source Type. Click Continue. |
||
|
Step 6 |
Configure the basic realm properties.
|
||
|
Step 7 |
Configure the directory server properties.
|
||
|
Step 8 |
(Optional) Use the Test button to validate the configuration. |
||
|
Step 9 |
(Optional) Click Add another configuration to add multiple AD servers to the AD realm. The AD servers need to be duplicates of each other and support the same AD domain. Therefore, the basic realm properties such as Directory name, Directory Password, and Base Distinguished Name must be the same across all AD servers associated with that AD realm. |
||
|
Step 10 |
Click Add. |
||
|
Step 11 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Edit an FTD Active Directory Realm Object
Note that you cannot change the Identity Source Type when editing an Identity source object. You must create a new object with the correct type.
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Locate the object you want to edit by using object filters and search field. |
|
Step 3 |
Select the object you want to edit. |
|
Step 4 |
Click the edit icon |
|
Step 5 |
Edit the values in the dialog box in the same fashion that you created in the procedures above. Expand the configuration bar listed below to edit or test the hostname/IP address or encryption information. |
|
Step 6 |
Click Save. |
|
Step 7 |
Security Cloud Control displays the policies that will be affected by the change. Click Confirm to finalize the change to the object and any policy affected by it. |
|
Step 8 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Create or Edit a RADIUS Server Object or Group
About RADIUS Server Objects or Groups
When you create or edit an identity source object such as a RADIUS server object or a group of RADIUS server objects, Security Cloud Control sends the configuration request to the FDM-managed devices through the SDC. The FDM-managed device then communicates with the configured AD realm.
Create a RADIUS Server Object
RADIUS servers provide AAA (authentication, authorization, and accounting) services.
Use the following procedure to create an object:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Click |
|
Step 3 |
Enter an Object name for the object. |
|
Step 4 |
For the Device Type, select FTD. |
|
Step 5 |
For the Identity Source type, select RADIUS Server. Click Continue. |
|
Step 6 |
Edit the Identity Source configuration with the following properties:
|
|
Step 7 |
If you have Cisco Identity Services Engine (ISE) already configured for your network and are using the server for remote access VPN Change of Authorization configuration, click the RA VPN Only link and configure the following:
|
|
Step 8 |
Click Add. |
|
Step 9 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Create a RADIUS Server Group
A RADIUS server group contains one or more RADIUS server objects. The servers within a group must be copies of each other. These servers form a chain of backup servers, so that if the first server is unavailable, the system can try the next server in the list.
Use the following procedure to create an object group:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
||
|
Step 2 |
Click |
||
|
Step 3 |
Enter an Object name for the object. |
||
|
Step 4 |
Select the Device Type as FTD. |
||
|
Step 5 |
Select RADIUS Server Group as the Identity Source Type. Click Continue. |
||
|
Step 6 |
Edit the Identity Source configuration with the following properties:
|
||
|
Step 7 |
Select an AD realm that supported the RADIUS server from the drop-down menu. If you have not already created an AD realm, click Create from inside the drop-down menu. |
||
|
Step 8 |
Click the Add button
|
||
|
Step 9 |
Review and deploy now the changes you made, or wait and deploy multiple changes at once. |
Edit a Radius Server Object or Group
Use the following procedure to edit a Radius server object or Radius server group:
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Locate the object you want to edit by using object filters and search field. |
|
Step 3 |
Select the object you want to edit. |
|
Step 4 |
Click the edit icon |
|
Step 5 |
Edit the values in the dialog box in the same fashion that you created them in the procedures above. To edit or test the hostname/IP address or encryption information, expand the configuration bar. |
|
Step 6 |
Click Save. |
|
Step 7 |
Security Cloud Control displays the policies that will be affected by the change. Click Confirm to finalize the change to the object and any policy affected by it. |
|
Step 8 |
Review and Deploy now the changes you made, or wait and deploy multiple changes at once. |
Create New RA VPN Group Policies
A group policy is a set of user-oriented attribute/value pairs for remote access VPN connections. The connection profile uses a group policy that sets terms for user connections after the tunnel is established. Group policies let you apply whole sets of attributes to a user or a group of users, rather than having to specify each attribute individually for each user.
The system includes a default group policy named "DfltGrpPolicy". You can create additional group policies to provide the services you require.
Note |
You cannot add inconsistent group policy objects to RA VPN configuration. Resolve all inconsistencies before adding the group policy to the RA VPN Configuration. |
Procedure
|
Step 1 |
In the left pane, click Manage > Objects. |
|
Step 2 |
Click |
|
Step 3 |
Enter a name for the group policy. The name can be up to 64 characters and spaces are allowed. |
|
Step 4 |
In the Device Type drop-down, select FTD. |
|
Step 5 |
Do any of the following:
|
|
Step 6 |
Click Save to create the group policy. |
RA VPN Group Policy Attributes
The general attributes of a group policy define the name of the group and some other basic settings. The Name attribute is the only required attribute.
-
DNS Server: Select the DNS server group that defines the DNS servers clients should use for domain name resolution when connected to the VPN. If the group you need is not yet defined, click Create DNS Group and create it now.
-
Banner: The banner text, or welcome message, to present to users at login. The default is no banner. The length can be up to 496 characters. The AnyConnect client supports partial HTML. To ensure that the banner displays properly to remote users, use the <BR> tag to indicate line breaks.
-
Default Domain: The default domain name for users in the RA VPN. For example, example.com. This domain is added to hostnames that are not fully-qualified, for example, serverA instead of serverA.example.com.
-
AnyConnect Client Profiles: Click + and select the AnyConnect Client Profiles to use for this group. See Configure and Upload AnyConnect Client Profiles. If you configure a fully-qualified domain name for the outside interface (in the connection profile), a default profile will be created for you. Alternatively, you can upload your client profile. Create these profiles using the Standalone AnyConnect Profile Editor, which you can download and install from software.cisco.com. If you do not select a client profile, the AnyConnect client uses default values for all options. The items in this list are AnyConnect Client Profile objects rather than the profiles themselves. You can create (and upload) new profiles by clicking Create New AnyConnect Client Profile in the drop-down list.
AnyConnect Client Profiles
This feature is supported on Firewall Device Manager running software version 6.7 or later versions.
Cisco AnyConnect VPN client offers enhanced security through various built-in modules. These modules provide services such as web security, network visibility into endpoint flows, and off-network roaming protection. Each client module includes a client profile that includes a group of custom configurations as per your requirement.
You can select the AnyConnect VPN profile object and AnyConnect modules to be downloaded to clients when the VPN user downloads the VPN AnyConnect client software.
-
Choose or create an AnyConnect VPN profile object. See Upload RA VPN AnyConnect Client Profile. Except for DART and Start Before Login modules, the AnyConnect VPN profile object must be selected.
-
Click Add Any Connect Client Module.
The following AnyConnect modules are optional and you can configure these modules to be downloaded with VPN AnyConnect client software:
-
AMP Enabler — Deploys advanced malware protection (AMP) for endpoints.
-
DART — Captures a snapshot of system logs and other diagnostic information and creates a .zip file on your desktop so you can conveniently send troubleshooting information to Cisco TAC.
-
Feedback — Provides information about the features and modules customers have enabled and used.
-
ISE Posture — Uses the OPSWAT library to perform posture checks to assess an endpoint's compliance.
-
Network Access Manager — Provides 802.1X (Layer 2) and device authentication to access both wired and wireless networks.
-
Network Visibility — Enhances the enterprise administrator's ability to do capacity and service planning, auditing, compliance, and security analytics.
-
Start Before Login — Forces the user to connect to the enterprise infrastructure over a VPN connection before logging on to Windows by starting AnyConnect before the Windows login dialog box appears.
-
Umbrella Roaming Security — Provides DNS-layer security when no VPN is active.
-
Web Security — Analyzes the elements of a web page, allows acceptable content, and blocks malicious or unacceptable content based on a defined security policy.
-
-
In the Client Module list, select an AnyConnect module.
-
In the Profile list, choose or create a profile object containing an AnyConnect Client Profile.
-
Select Enable Module Download to enable endpoints to download the client module along with the profile. If not selected, the endpoints can download only the client profile.
Session Setting Attributes
The session settings of a group policy control how long users can connect through the VPN and how many separate connections they can establish.
-
Maximum Connection Time: The maximum length of time, in minutes, that users can stay connected to the VPN without logging out and reconnecting, from 1- 4473924 or blank. The default is unlimited (blank), but the idle timeout still applies.
-
Connection Time Alert Interval: If you specify a maximum connection time, the alert interval defines the amount of time before the maximum time is reached to display a warning to the user about the upcoming automatic disconnect. The user can choose to end the connection and reconnect to restart the timer. The default is 1 minute. You can specify 1 to 30 minutes.
-
Idle Time: The length of time, in minutes, that the VPN connection can be idle before it is automatically closed, from 1-35791394. If there is no communication activity on the connection for this consecutive number of minutes, the system stops the connection. The default is 30 minutes.
-
Idle Time Alert Interval: The amount of time before the idle time is reached to display a warning to the user about the upcoming automatic disconnect due to an idle session. Any activity resets the timer. The default is 1 minute. You can specify 1 to 30 minutes.
-
Simultaneous Login Per User: The maximum number of simultaneous connections allowed for a user. The default is 3. You can specify 1 to 2147483647 connections. Allowing many simultaneous connections might compromise security and affect performance.
Address Assignment Attributes
The address assignment attributes of a group policy define the IP address pool for the group. The pool defined here overrides the pool defined in any connection profile that uses this group. Leave these settings blank if you want to use the pool defined in the connection profile.
-
IPv4 Address Pool, IPv6 Address Pool: These options define the address pools for the remote endpoints. Clients are assigned an address from these pools based on the IP version they use to make the VPN connection. Select a network object that defines a subnet for each IP type you want to support. Leave the list empty if you do not want to support that IP version. For example, you could define an IPv4 pool as 10.100.10.0/24. The address pool cannot be on the same subnet as the IP address for the outside interface. You can specify a list of up to six address pools to use for local address allocation. The order in which you specify the pools is significant. The system allocates addresses from these pools in the order in which the pools appear.
-
DHCP Scope: If you configure DHCP servers for the address pool in the connection profile, the DHCP scope identifies the subnets to use for the pool for this group. The DHCP server must also have addresses in the same pool identified by the scope. The scope allows you to select a subset of the address pools defined in the DHCP server to use for this specific group. If you do not define a network scope, the DHCP server assigns IP addresses in the order of the address pools configured. It goes through the pools until it identifies an unassigned address. To specify a scope, select the network object that contains the network number host address. Click Create New Network if the object does not yet exist. For example, to tell the DHCP server to use addresses from the 192.168.5.0/24 subnet pool, select a network object that specifies 192.168.5.0 as a host address. You can use DHCP for IPv4 addressing only.
Split Tunneling Attributes
The split tunneling attributes of a group policy define how the system should handle traffic meant for the internal network vs. externally-directed traffic. Split tunneling directs some network traffic through the VPN tunnel (encrypted) and the remaining network traffic outside the VPN tunnel (unencrypted or in clear text).
-
IPv4 Split Tunneling, IPv6 Split Tunneling: You can specify different options based on whether the traffic uses IPv4 or IPv6 addresses, but the options for each are the same. If you want to enable split tunneling, specify one of the options that require you to select network objects.
-
Allow all traffic over tunnel: Do no split tunneling. Once the user makes an RA VPN connection, all the user's traffic goes through the protected tunnel. This is the default. It is also considered the most secure option.
-
Allow specified traffic over the tunnel: Select the network objects that define destination network and host addresses. Any traffic to these destinations goes through the protected tunnel. The client routes traffic to any other destination to connections outside the tunnel (such as a local Wi-Fi or network connection).
-
Exclude networks specified below: Select the network objects that define destination network or host addresses. The client routes any traffic to these destinations to connections outside the tunnel. Traffic to any other destination goes through the tunnel.
-
-
Split DNS - You can configure the system to send some DNS requests through the secure connection while allowing the client to send other DNS requests to the DNS servers configured on the client. You can configure the following DNS behavior:
-
Send DNS Request as per split tunnel policy: With this option, DNS requests are handled the same way as the split tunnel options are defined. If you enable split tunneling, DNS requests are sent based on the destination addresses. If you do not enable split tunneling, all DNS requests go over the protected connection.
-
Always send DNS requests over tunnel: Select this option if you enable split tunneling, but you want all DNS requests sent through the protected connection to the DNS servers defined for the group.
-
Send only specified domains over tunnel: Select this option if you want your protected DNS servers to resolve addresses for certain domains only. Then, specify those domains, separating domain names with commas. For example, example.com, example1.com. Use this option if you want your internal DNS servers to resolve names for internal domains, while external DNS servers handle all other Internet traffic.
-
AnyConnect Attributes
The AnyConnect attributes of a group policy define some SSL and connection settings used by the AnyConnect client for a remote access VPN connection.
-
SSL Settings
-
Enable Datagram Transport Layer Security (DTLS): Whether to allow the AnyConnect client to use two simultaneous tunnels: an SSL tunnel and a DTLS tunnel. Using 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. If you do not enable DTLS, AnyConnect client users establishing SSL VPN connections connect with an SSL tunnel only.
-
DTLS Compression: Whether to compress Datagram Transport Layer Security (DTLS) connections for this group using LZS. DTLS Compression is disabled by default.
-
SSL Compression: Whether to enable data compression, and if so, the method of data compression to use, Deflate, or LZS. SSL Compression is Disabled by default. Data compression speeds up transmission rates but also increases the memory requirement and CPU usage for each user session. Therefore, SSL compression decreases the overall throughput of the device.
-
SSL Rekey Method, SSL Rekey Interval: The client can rekey the VPN connection, renegotiating the crypto keys and initialization vectors, to increase the security of the connection. Disable rekeying by selecting None. To enable rekey, select New Tunnel to create a new tunnel each time. (The Existing Tunnel option results in the same action as New Tunnel.) If you enable rekeying, also set the rekey interval, which is 4 minutes by default. You can set the interval to 4-10080 minutes (1 week).
-
-
Connection Settings
-
Ignore the DF (Don't Fragment) bit: Whether to ignore the Don't Fragment (DF) bit in packets that need fragmentation. Select this option to allow the forced fragmentation of packets that have the DF bit set, so that these packets can pass through the tunnel.
-
Client Bypass Protocol - Allows you to configure how the secure gateway manages IPv4 traffic (when it is expecting only IPv6 traffic), or how it manages IPv6 traffic (when it is expecting only IPv4 traffic).
When the AnyConnect client makes a VPN connection to the headend, the headend assigns it an IPv4, IPv6, or both an IPv4 and IPv6 address. If the headend assigns the AnyConnect connection only an IPv4 address or only an IPv6 address, you can configure the Client Bypass Protocol to drop network traffic for which the headend did not assign an IP address (default, disabled, not checked), or allow that traffic to bypass the headend and be sent from the client unencrypted or "in the clear" (enabled, checked).
For example, assume that the secure gateway assigns only an IPv4 address to an AnyConnect connection and the endpoint is dual-stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass Protocol is disabled, the IPv6 traffic is dropped; however, if Client Bypass Protocol is enabled, the IPv6 traffic is sent from the client in the clear.
-
MTU: The maximum transmission unit (MTU) size for SSL VPN connections established by the Cisco AnyConnect VPN Client. The default is 1406 bytes. The range is 576 to 1462 bytes.
-
Keepalive Messages Between AnyConnect and VPN Gateway: Whether to exchange keepalive messages between peers to demonstrate that they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals. The default interval is 20 seconds, and the valid range is 15 to 600 seconds.
-
DPD on Gateway Side Interval, DPD on Client Side Interval: Enable Dead Peer Detection (DPD) to ensure that the VPN gateway or VPN client quickly detects when the peer is no longer responding. You can separately enable gateway or client DPD. The default interval is 30 seconds for sending DPD messages. The interval can be 5-3600 seconds.
-
-
Traffic Filters Attributes
The traffic filter attributes of a group policy define restrictions you want to place on users assigned to the group. You can use these attributes instead of creating access control policy rules to restrict RA VPN users to specific resources, based on host or subnet address and protocol, or VLAN. By default, RA VPN users are not restricted by the group policy from accessing any destination on your protected network.
-
Access List Filter: Restrict access using an extended access control list (ACL). Select the Smart CLI Extended ACL object. The extended ACL lets you filter based on source address, a destination address, and protocol (such as IP or TCP). ACLs are evaluated on a top-down, first-match basis, so ensure that you place specific rules before more general rules. There is an implicit "deny any" at the end of the ACL, so if you intend to deny access to a few subnets while allowing all other access, ensure that you include a "permit any" rule at the end of the ACL. Because you cannot create network objects while editing an extended ACL Smart CLI object, you should create the ACL before editing the group policy. Otherwise, you might need to simply create the object, then go back later to create the network objects and then all the access control entries that you need. To create the ACL, log in to Firewall Device Manager, go to , create an object, and select Extended Access List as the object type.
-
Restrict VPN to VLAN: Also called "VLAN mapping," this attribute specifies the egress VLAN interface for sessions to which this group policy applies. The system forwards all traffic from this group to the selected VLAN. Use this attribute to assign a VLAN to the group policy to simplify access control. Assigning a value to this attribute is an alternative to using an ACL to filter traffic on a session. Ensure that you specify a VLAN number that is defined on a subinterface on the device. Values range from 1 to 4094.
Windows Browser Proxy Attributes
The Windows browser proxy attributes of a group policy determine how, and whether, a proxy defined on the user's browser operates.
You can select one of the following values for Browser Proxy During VPN Session:
-
No change in endpoint settings: Allow the user to configure (or not configure) a browser proxy for HTTP and use the proxy if it is configured.
-
Disable browser proxy: Do not use the proxy defined for the browser, if any. No browser connections will go through the proxy.
-
Auto detect settings: Enable the use of automatic proxy server detection in the browser for the client device.
-
Use custom settings: Define a proxy that should be used by all client devices for HTTP traffic. Configure the following settings:
-
Proxy Server IP or Hostname, Port: The IP address, or hostname, of the proxy server, and the port used for proxy connections by the proxy server. The host and port combined cannot exceed 100 characters.
-
Browser Proxy Exemption List: Connections to the hosts/ports in the exemption list do not go through the proxy. Add all the host/port values for destinations that should not use the proxy. For example, www.example.com port 80. Click Add proxy exemption to add items to the list. Click the trash can icon to delete items. The entire proxy exception list, combining all addresses and ports, cannot be longer than 255 characters.
-
Create an RA VPN Configuration
Security Cloud Control allows you to add one or more FDM-managed devices to the RA VPN configuration wizard and configure the VPN interfaces, access control, and NAT exemption settings associated with the devices. Therefore, each RA VPN configuration can have connection profiles and group policies shared across multiple FDM-managed devices that are associated with the RA VPN configuration. Further, you can enhance the configuration by creating connection profiles and group policies.
You can either onboard an FDM-managed device that has already been configured with RA VPN settings or a new device without RA VPN settings. When you onboard an FDM-managed device that already has RA VPN settings, Security Cloud Control automatically creates a "Default RA VPN Configuration" and associates the FDM-managed device with this configuration. Also, this default configuration can contain all the connection profile objects that are defined on the device.
Important |
|
Prerequisites
Before adding the FDM-managed devices to RA VPN configuration, the following prerequisites must be met:
-
Make sure that the FDM-managed devices have the following:
-
A valid license. For more information, see Licensing Requirements for Remote Access VPN.
-
For FDM Version 6.4.0, ensure that a minimum of one AnyConnect software package pre-uploaded to the device. For more information, see Upload AnyConnect Software Packages to Firepower Threat Defense Devices version 6.4.0.
-
For FDM Version 6.5.0 and later, you can upload AnyConnect package using Security Cloud Control. For more information, see Upload AnyConnect Software Packages to Firepower Threat Defense Devices version 6.5.0.
-
There are no configuration deployments pending.
-
-
FDM changes are synchronized to Security Cloud Control.
-
In the left pane, click and search for one or more FDM-managed devices to be synchronized.
-
Select one or more devices and then click Check for changes. Security Cloud Control communicates with one or more FDM-managed devices to synchronize the changes.
-
-
RA VPN configuration group policy objects are consistent.
-
Ensure that all inconsistent group policy objects are resolved as they cannot be added to the RA VPN configuration. Either address the issue or remove inconsistent group policy objects from the Objects page. For more information see, Resolve Duplicate Object Issues and Resolve Inconsistent Object Issues.
-
-
RA VPN group policies of the FDM-managed device match RA VPN configuration group policies.
Procedure
Procedure
|
Step 1 |
In the left pane, click . |
||
|
Step 2 |
In the left pane, click . |
||
|
Step 3 |
Click the blue plus |
||
|
Step 4 |
Enter a name for the Remote Access VPN configuration. |
||
|
Step 5 |
Click the blue plus
|
||
|
Step 6 |
Click OK.
|
||
|
Step 7 |
Click OK. The device is added to the configuration. |
What to do next
Note |
Select a configuration and under Actions, click the appropriate action: |
-
Group Policies to add or remove group policies.
-
Remove to delete the selected RA VPN configuration.
Modify RA VPN Configuration
You can modify the name and the device details of an existing RA VPN configuration.
Procedure
|
Select the configuration to be modified and under Actions, click Edit.
|
You can also search for remote access VPN configuration by typing the name of the configuration or device.
Configure an RA VPN Connection Profile
An RA VPN connection profile defines the characteristics that allow external users to create a VPN connection to the system using the AnyConnect client. Each profile defines the AAA servers and certificates used for authenticating users, the address pool for assigning users IP addresses, and the group policies that define various user-oriented attributes.
You can create multiple profiles within the RA VPN configuration if you need to provide variable services to different user groups, or if you have various authentication sources. For example, if your organization merges with a different organization that uses different authentication servers, you can create a profile for the new group that uses those authentication servers.
An RA VPN connection profile allows your users to connect to your inside networks when they are on external networks, such as their home network. Create separate profiles to accommodate different authentication methods.
Before you begin
Before configuring the remote access (RA) VPN connection:
-
The outside interface, the one that terminates remote access VPN connections, cannot also have a management access list that allows HTTPS connections. Delete any HTTPS rules from the outside interface before configuring RA VPN. See the "Configuring the Management Access List" section in the "System Settings" chapter of Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version X.Y.
-
Create an RA VPN configuration. See Create an RA VPN Configuration.
Procedure
Procedure
|
Step 1 |
|||
|
Step 2 |
In the left pane, click . You can click a VPN configuration to view the summary information on how many connection profiles and group policies are currently configured. |
||
|
Step 3 |
Click the connection profile and under Actions in the sidebar at the right, click Add Connection Profile. |
||
|
Step 4 |
Configure the basic connection attributes.
|
||
|
Step 5 |
Configure the primary and optionally, secondary identity sources. These options determine how remote users authenticate to the device to enable the remote access VPN connection. The simplest approach is to use AAA only and then select an AD realm or use the LocalIdentitySource. You can use the following approaches for Authentication Type:
|
||
|
Step 6 |
Configure the address pool for clients. The address pool defines the IP addresses that the system can assign to remote clients when they establish a VPN connection. For more information, see Configure Client Address Pool Assignment. |
||
|
Step 7 |
Click Continue. |
||
|
Step 8 |
Select the Group Policy to use for this profile from the list and click Select. The group policy sets terms for user connections after the tunnel is established. The system includes a default group policy named DfltGrpPolicy. You can create additional group policies to provide the services you require. |
||
|
Step 9 |
Click Continue. |
||
|
Step 10 |
Review the summary. First, verify that the summary is correct. You can see what end-users need to do to initially install
the AnyConnect software and test that they can complete a VPN connection. Click |
||
|
Step 11 |
Click Done. |
What to do next
Ensure that traffic is allowed in the VPN tunnel, as explained in Allow Traffic Through the Remote Access VPN.
Configure AAA for a Connection Profile
Authentication, Authorization, and Accounting (AAA) servers use username and password to determine if a user is allowed access to the remote access VPN. If you use RADIUS servers, you can distinguish authorization levels among authenticated users, to provide differential access to protected resources. You can also use RADIUS accounting services to keep track of usage.
When configuring AAA, you must configure a primary identity source. Secondary and fallback sources are optional. Use a secondary source if you want to implement dual authentication, for example, using RSA tokens or DUO.
Primary Identity Source Options
-
Primary Identity Source for User Authentication: The primary identity source used for authenticating remote users. End users must be defined in this source or the optional fallback source to complete a VPN connection. Select one of the following:
-
An Active Directory (AD) identity realm. If the realm you need does not yet exist, click Create New Identity Realm.
-
A RADIUS server group.
-
LocalIdentitySource (the local user database): You can define users directly on the device and not use an external server.
-
-
Fallback Local Identity Source: If the primary source is an external server, you can select the LocalIdentitySource as a fallback in case the primary server is unavailable. If you use the local database as a fallback source, ensure that you define the same local usernames/passwords as the ones defined in the external server.
-
Strip options: A realm is an administrative domain. Enabling the following options allows the authentication to be based on the username alone. You can enable any combination of these options. However, you must select both check boxes if your server cannot parse delimiters.
-
Strip Identity Source Server from Username: Whether to remove the identity source name from the username before passing the username on to the AAA server. For example, if you select this option and the user enters domain\username as the username, the domain is stripped off from the username and sent to AAA server for authentication. By default, this option is unchecked.
-
Strip Group from Username: Whether to remove the group name from the username before passing the username on to the AAA server. This option applies to names given in the username@domain format; the option strips the domain and @ sign. By default, this option is unchecked.
-
Secondary Identity Source
-
Secondary Identity Source for User Authorization: The optional second identity source. If the user successfully authenticates with the primary source, the user is prompted to authenticate with the secondary source. You can select an AD realm, RADIUS server group, or the local identity source.
-
Advanced options: Click the Advanced link and configure the following options:
-
Fallback Local Identity Source for Secondary: If the secondary source is an external server, you can select the LocalIdentitySource as a fallback in case the secondary server is unavailable. If you use the local database as a fallback source, ensure that you define the same local usernames/passwords as the ones defined in the secondary external server.
-
Use Primary Username for Secondary Login: By default, when using a secondary identity source, the system will prompt for both username and password for the secondary source. If you select this option, the system prompts for the secondary password only and uses the same username for the secondary source that was authenticated against the primary identity source. Select this option if you configure the same usernames in both the primary and secondary identity sources.
-
Username for Session Server: After successful authentication, the username is shown in events and statistical dashboards, is used for determining matches for a user- or group-based SSL decryption and access control rules and is used for accounting. Because you are using two authentication sources, you need to tell the system whether to use the Primary or Secondary username as the user identity. By default, the primary name is used.
-
Password Type: How to obtain the password for the secondary server. The default is Prompt, which means the user is asked to enter the password. Select Primary Identity Source Password to automatically use the password entered when the user authenticated to the primary server. Select Common Password to use the same password for every user, then enter that password in the Common Password field.
-
-
Authorization Server: The RADIUS server group that has been configured to authorize remote access, VPN users. After authentication is complete, authorization controls the services and commands available to each authenticated user. Authorization works by assembling a set of attributes that describe what the user is authorized to perform, their actual capabilities, and restrictions. Were you not to use authorization, authentication alone would provide the same access to all authenticated users. For information on configuring RADIUS for authorization, see Control User Permissions and Attributes Using RADIUS and Group Policies. Note that if the system obtains authorization attributes from the RADIUS server that overlap those defined in the group policy, the RADIUS attributes override the group policy attributes.
-
Accounting Server: (Optional.) The RADIUS server group to use to account for the remote access VPN session. Accounting tracks the services users are accessing as well as the number of network resources they are consuming. The FDM-managed device reports user activity to the RADIUS server. Accounting information includes when sessions start and stop, usernames, the number of bytes that pass through the device for each session, the service used, and the duration of each session. You can then analyze the data for network management, client billing, or auditing. You can use accounting alone or together with authentication and authorization.
-
Configure Certificate Authentication for a Connection Profile
Note |
This section is not applicable for Authentication Type as AAA Only. |
You can use certificates installed on the client device to authenticate remote access VPN connections.
When using client certificates, you can still configure a secondary identity source, fallback source, and authorization and accounting servers. These are AAA options; for details, see Configure an RA VPN Connection Profile.
Following are the certificate-specific attributes. You can configure these attributes separately for primary and secondary identity sources. Configuring a secondary source is optional.
-
Username from Certificate: Select one of the following:
-
Map Specific Field: Use the certificate elements in the order of Primary Field and Secondary Field. The defaults are CN (Common Name) and OU (Organizational Unit). Select the options that work for your organization. The fields are combined to provide the username, and this is the name used in events, dashboards, and for matching purposes in SSL decryption and access control rules.
-
Use entire DN (distinguished name) as username: The system automatically derives the username from the DN fields. •
-
-
Advanced options (not applicable for Authentication Type as Client Certificate Only): Click the Advanced link and configure the following options:
-
Prefill username from certificate on user login window: Whether to fill in the username field with the retrieved username when prompting the user to authenticate.
-
Hide username in login window: If you select the Prefill option, you can hide the username, which means the user cannot edit the username in the password prompt.
-
Configure Client Address Pool Assignment
There must be a way for the system to provide an IP address to endpoints that connect to the remote access VPN. The AAA server can provide these addresses, a DHCP server, an IP address pool configured in the group policy, or an IP address pool configured in the connection profile. The system tries these resources in that order and stops when it obtains an available address, which it then assigns to the client. Thus, you can configure multiple options to create a failsafe in case of an unusual number of concurrent connections.
Use one or more of the following methods to configure the address pool for a connection profile.
-
IPv4 Address Pool and IPv4 Address Pool: First, create up to six network objects that specify subnets. You can configure separate pools for IPv4 and IPv6. Then, select these objects in the IPv4 Address Pool and IPv6 Address Pool options, either in the group policy or in the connection profile. You do not need to configure both IPv4 and IPv6, configure the addressing scheme you want to support. You also do not need to configure the pool in both the group policy and the connection profile. The group policy overrides the connection profile settings, so if you configure the pools in the group policy, leave the options empty in the connection profile. Note that the pools are used in the order in which you list them.
-
DHCP Servers: First, configure a DHCP server with one or more IPv4 address ranges for the RA VPN (you cannot configure IPv6 pools using DHCP). Then, create a host network object with the IP address of the DHCP server. You can then select this object in the DHCP Servers attribute of the connection profile. You can configure more than one DHCP server. If the DHCP server has multiple address pools, you can use the DHCP Scope attribute in the group policy that you attach to the connection profile to select which pool to use. Create a host network object with the network address of the pool. For example, if the DHCP pool contains 192.168.15.0/24 and 192.168.16.0/24, setting the DHCP scope to 192.168.16.0 will ensure that an address from the 192.168.16.0/24 subnet will be selected.
Allow Traffic Through the Remote Access VPN
You can use one of the following techniques to enable traffic flow in the remote access VPN tunnel.
-
Configure the sysopt connection permit-vpn command, which exempts traffic that matches the VPN connection from the access control policy. The default for this command is no sysopt connection permit-vpn, which means VPN traffic must also be allowed by the access control policy. This is the more secure method to allow traffic in the VPN because external users cannot spoof IP addresses in the remote access VPN address pool. The downside is that the VPN traffic will not be inspected, which means that intrusion and file protection, URL filtering, or other advanced features will not be applied to the traffic. This also means that no connection events will be generated for the traffic, and thus statistical dashboards will not reflect VPN connections. To configure this command, select the Bypass Access Control policy for decrypted traffic option in your RA VPN Configuration. See Create an RA VPN Configuration.
-
Create access control rules to allow connections from the remote access VPN address pool. This method ensures that VPN traffic is inspected, and advanced services can be applied to the connections. The downside is that it opens the possibility for external users to spoof IP addresses and thus gain access to your internal network.
Upgrade AnyConnect Package on an FDM-Managed Device Running Version 6.4.0
You can use Security Cloud Control to upgrade the AnyConnect package available on an FDM-managed device so that it can be distributed to RA VPN users.
The following are the major steps that are involved in upgrading the AnyConnect package:
Procedure
|
Step 1 |
Use Firewall Device Manager to remove the AnyConnect package and upload a later version of the package. Use one of these methods to accomplish this task.
|
|
Step 2 |
Deploy Firewall Device Manager changes to device. |
|
Step 3 |
Read the new configuration information into Security Cloud Control. |
|
Step 4 |
Verify the new package in the RA VPN connection profile. |
Prerequisites
-
A minimum of one RA VPN configuration with connection profile is already deployed to FDM-managed device.
-
Download the AnyConnect package that you want from https://software.cisco.com/download/home/283000185. Cisco recommends upgrading to the latest available package.
Upload your desired AnyConnect Package to Secure Firewall Threat Defense using Firewall Device Manager
Procedure
|
Step 1 |
Using a browser, open the home page of the system. For example, https://ftd.example.com. |
||
|
Step 2 |
Log into Firewall Device Manager. |
||
|
Step 3 |
Click View Configuration in the group. The group shows summary information on how many connection profiles and group policies are currently configured. |
||
|
Step 4 |
Click the view (
|
||
|
Step 5 |
Click the Edit button to make changes. |
||
|
Step 6 |
Click Next until the Global Settings screen appears. The AnyConnect Package shows AnyConnect packages available on the FDM-managed device. |
||
|
Step 7 |
Click 'X' button to remove the AnyConnect package which you want to replace.
|
||
|
Step 8 |
Click Upload Package and then click the OS that you want for uploading the compatible package. |
||
|
Step 9 |
Select the package and click Open. You can see the package being uploaded on the Firewall Device Manager UI. |
||
|
Step 10 |
Click Finish. The configuration is saved.
|
||
|
Step 11 |
Click the Deploy Changes icon in the upper right of the web page. The icon is highlighted with a dot when there are undeployed changes. |
||
|
Step 12 |
If you are satisfied with the changes, you can click Deploy Now to start the job immediately. The window shows that the deployment is in progress. You can close the window, or wait for the deployment to complete. |
) button (
Verify the new package is referenced in the RA VPN connection profile
Procedure
|
Step 1 |
In the left pane, click Inventory. |
|
Step 2 |
In the left pane, click . |
|
Step 3 |
Click the Devices tab. |
|
Step 4 |
Click the FTD tab and select the FDM-managed device which has the upgraded AnyConnect package. This device would be reporting conflict. |
|
Step 5 |
Accept the Out-of-band changes to overwrite the configuration and any pending changes stored on Security Cloud Control with the device's running configuration. For more information, see Resolve "Conflict Detected Status." |
|
Step 6 |
View the new AnyConnect package by performing the following:
|
Upload RA VPN AnyConnect Client Profile
The Remote Access VPN AnyConnect Client Profile is a group of configuration parameters stored in a file. There are different AnyConnect client profiles containing configuration settings for the core client VPN functionality and for the optional client modules Network Access Manager, AMP Enabler, ISE posture, Network Visibility, Customer Feedback Experience profiles, Umbrella roaming security, and Web Security.
Security Cloud Control allows uploading of these profiles as objects which can be used in the group policy later.
-
AnyConnect VPN Profile — AnyConnect client profiles are downloaded to clients along with the VPN AnyConnect client software. These profiles define many client-related options, such as auto-connect on startup and auto-reconnect, and whether the end-user can change the option from the AnyConnect client preferences and advanced settings. Security Cloud Control supports the XML file format.
-
AMP Enabler Service Profile — The profile is used for the AnyConnect AMP Enabler. The AMP Enabler and this profile are pushed to the endpoints from FDM-managed device when a remote access VPN user connects to the VPN. Security Cloud Control supports XML and ASP file formats.
-
Feedback Profile — You can add a Customer Experience Feedback profile and select this type to receive information about the features and modules customers have enabled and used. Security Cloud Control supports the FSP file format.
-
ISE Posture Profile — Choose this option if you add a profile file for the AnyConnect ISE Posture module. Security Cloud Control supports XML and ISP file formats.
-
Network Access Manager Service Profile — Configure and add the NAM profile file using the Network Access Manager profile editor. Security Cloud Control supports XML and NSP file formats.
-
Network Visibility Service Profile — Profile file for AnyConnect Network Visibility module. You can create the profile using the NVM profile editor. Security Cloud Control supports XML and NVMSP file formats.
-
Umbrella Roaming Security Profile — You must select this file type if you deploy the Umbrella Roaming Security module. Security Cloud Control supports XML and JSON file formats.
-
Web Security Service Profile — Select this file type when you add a profile file for the Web security module. Security Cloud Control supports XML, WSO, and WSP file formats.
Before you begin
Use the suitable GUI-based AnyConnect profile editors to create the profiles you need. You can download the profile editors from Cisco Software Download Center in the AnyConnect Secure Mobility Client category and install the AnyConnect “Profile Editor - Windows / Standalone installer (MSI).” The profile editor installer contains stand-alone versions of the profile editors. The installation file is for Windows only and has the file name anyconnect-profileeditor-win-<version>-k9.msi, where <version> is the AnyConnect version. For example, anyconnect-profileeditor-win-4.3.04027-k9.msi. You must also install Java JRE 1.6 (or higher) before installing the profile editor.
Except for the Umbrella Roaming Security profile editor, this package contains all the profile editors required for creating the modules. For detailed information, see the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect Secure Mobility Client Administrator Guide for details. Download the Umbrella Roaming Security profile separately from the Umbrella dashboard. For detailed information, see the "Download the AnyConnect Roaming Security Profile from the Umbrella Dashboard" section of the "Umbrella Roaming Security" chapter in the Cisco Umbrella User Guide.
Procedure
|
Step 1 |
In the left pane, choose Manage > Objects. |
|
Step 2 |
Click the blue plus |
|
Step 3 |
Click . |
|
Step 4 |
In the Object Name field, enter a name for the AnyConnect client profile. |
|
Step 5 |
Click Browse and select the file you created using the Profile Editor. |
|
Step 6 |
Click Open to upload the profile. |
|
Step 7 |
Click Add to add the object. |
Guidelines and Limitations of Remote Access VPN for FDM-Managed Device
Keep the following guidelines and limitations in mind when configuring RA VPN.
-
AnyConnect packages must be pre-loaded to FDM-Managed devices running Version 6.4.0 using Firewall Device Manager.
Note |
Upload AnyConnect package separately to the FDM-Managed device running Version 6.5.0 using the Remote Access VPN Configuration wizard in Security Cloud Control. |
-
Before configuring RA VPN from Security Cloud Control:
-
Register the license for the FDM-managed devices from Firewall Device Manager.
-
Enable the license from Firewall Device Manager with export-control.
-
-
Security Cloud Control does not support the Extended Access List object. Configure the object using the Smart CLI in Firewall Device Manager and then use in VPN filter and Change of Authorization (CoA) redirect ACL.
-
The template you create from an FDM-managed device will not contain the RA VPN configuration.
-
Device-specific overrides are required for IP pool objects and RADIUS identity sources.
-
You cannot configure both Firewall Device Manager access (HTTPS access in the management access-list) and AnyConnect remote access SSL VPN on the same interface for the same TCP port. For example, if you configure remote access SSL VPN on the outside interface, you cannot also open the outside interface for HTTPS connections on port 443. Because you cannot configure the port used by these features in Firewall Device Manager, you cannot configure both features on the same interface.
-
If you configure two-factor authentication using RADIUS and RSA tokens, the default authentication timeout of 12 seconds is too quick to allow successful authentication in most cases. Increase the authentication timeout value by creating a custom AnyConnect client profile and applying it to the RA VPN connection profile, as described in Upload RA VPN AnyConnect Client Profile. We recommend an authentication timeout of at least 60 seconds so that users have enough time to authenticate and then paste the RSA token and for the round-trip verification of the token.
How Users Can Install the AnyConnect Client Software on FDM-Managed Device
Use Firewall Device Manager APIs to upload the AnyConnect Client Software package to FDM-managed device to distribute to your users. See Upload AnyConnect Software Packages to Firepower Threat Defense Devices.
To complete a VPN connection, your users must install the AnyConnect client software. You can use your existing software distribution methods to install the software directly. Or, you can have users install the AnyConnect client directly from the FDM-managed device.
Note |
Users must have Administrator rights on their workstations to install the software. |
If you decide to have users initially install the software from the FDM-managed device, inform users to perform the following steps:
Note |
Android and iOS users should download AnyConnect from the appropriate App Store. |
Procedure
|
Step 1 |
Using a web browser, open https://ravpn-address, where ravpn-address is the IP address or hostname of the outside interface on which you are allowing VPN connections. You identify this interface when you configure the remote access VPN. The system prompts the user to log in. |
|
Step 2 |
Log into the site. Users are authenticated using the directory server configured for the remote access VPN. Log in must be successful to continue. If the login is successful, the system determines if the user already has the required version of the AnyConnect client. If the AnyConnect client is absent from the user's computer or is down-level, the system automatically starts installing the AnyConnect software. When the installation is finished, AnyConnect completes the remote access VPN connection. |
Distribute new AnyConnect Client Software version
You can distribute the new version of AnyConnect client software to your users by uploading them to FDM-managed device without removing the old version. Once the AnyConnect client is uploaded successfully, you can remove the old version.
The AnyConnect client detects the new version on the next VPN connection the user makes. The system will automatically prompt the user to download and install the updated client software. This automation simplifies software distribution for you and your clients.
The following figure shows an example of an FDM-managed device with two versions of AnyConnect client software (AnyConnectWindows_3.2_BGL and AnyConnectWindows_4.2_BGL) for Windows OS.
Upload RA VPN AnyConnect Client Profile
The Remote Access VPN AnyConnect Client Profile is a group of configuration parameters stored in a file. There are different AnyConnect client profiles containing configuration settings for the core client VPN functionality and for the optional client modules Network Access Manager, AMP Enabler, ISE posture, Network Visibility, Customer Feedback Experience profiles, Umbrella roaming security, and Web Security.
Security Cloud Control allows uploading of these profiles as objects which can be used in the group policy later.
-
AnyConnect VPN Profile — AnyConnect client profiles are downloaded to clients along with the VPN AnyConnect client software. These profiles define many client-related options, such as auto-connect on startup and auto-reconnect, and whether the end-user can change the option from the AnyConnect client preferences and advanced settings. Security Cloud Control supports the XML file format.
-
AMP Enabler Service Profile — The profile is used for the AnyConnect AMP Enabler. The AMP Enabler and this profile are pushed to the endpoints from FDM-managed device when a remote access VPN user connects to the VPN. Security Cloud Control supports XML and ASP file formats.
-
Feedback Profile — You can add a Customer Experience Feedback profile and select this type to receive information about the features and modules customers have enabled and used. Security Cloud Control supports the FSP file format.
-
ISE Posture Profile — Choose this option if you add a profile file for the AnyConnect ISE Posture module. Security Cloud Control supports XML and ISP file formats.
-
Network Access Manager Service Profile — Configure and add the NAM profile file using the Network Access Manager profile editor. Security Cloud Control supports XML and NSP file formats.
-
Network Visibility Service Profile — Profile file for AnyConnect Network Visibility module. You can create the profile using the NVM profile editor. Security Cloud Control supports XML and NVMSP file formats.
-
Umbrella Roaming Security Profile — You must select this file type if you deploy the Umbrella Roaming Security module. Security Cloud Control supports XML and JSON file formats.
-
Web Security Service Profile — Select this file type when you add a profile file for the Web security module. Security Cloud Control supports XML, WSO, and WSP file formats.
Before you begin
Use the suitable GUI-based AnyConnect profile editors to create the profiles you need. You can download the profile editors from Cisco Software Download Center in the AnyConnect Secure Mobility Client category and install the AnyConnect “Profile Editor - Windows / Standalone installer (MSI).” The profile editor installer contains stand-alone versions of the profile editors. The installation file is for Windows only and has the file name anyconnect-profileeditor-win-<version>-k9.msi, where <version> is the AnyConnect version. For example, anyconnect-profileeditor-win-4.3.04027-k9.msi. You must also install Java JRE 1.6 (or higher) before installing the profile editor.
Except for the Umbrella Roaming Security profile editor, this package contains all the profile editors required for creating the modules. For detailed information, see the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect Secure Mobility Client Administrator Guide for details. Download the Umbrella Roaming Security profile separately from the Umbrella dashboard. For detailed information, see the "Download the AnyConnect Roaming Security Profile from the Umbrella Dashboard" section of the "Umbrella Roaming Security" chapter in the Cisco Umbrella User Guide.
Procedure
|
Step 1 |
In the left pane, choose Manage > Objects. |
|
Step 2 |
Click the blue plus |
|
Step 3 |
Click . |
|
Step 4 |
In the Object Name field, enter a name for the AnyConnect client profile. |
|
Step 5 |
Click Browse and select the file you created using the Profile Editor. |
|
Step 6 |
Click Open to upload the profile. |
|
Step 7 |
Click Add to add the object. |
Licensing Requirements for Remote Access VPN
Enable (register) the license for the FDM-managed devices from Firewall Device Manager to configure RA VPN connection. When you register the device, you must do so with a Smart Software Manager (SSM) account that is enabled for export-controlled features. You also cannot configure the feature using the evaluation license.
Also, you must purchase and enable a license; it can be any of the following: . These licenses are treated the same for FDM-managed devices, although they are designed to allow different feature sets when used with ASA Software-based headends.
For more information about enabling license from Firewall Device Manager, see the Licensing Requirements for Remote Access VPN section of the Remote Access VPN chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.
For more information, see the Cisco AnyConnect Ordering Guide. There are also other data sheets available on http://www.cisco.com/c/en/us/product...t-listing.html.
To view the license status, perform the following:
Procedure
|
Step 1 |
In the left pane, click Inventory. |
|
Step 2 |
In the left pane, click . |
|
Step 3 |
Click the Devices device. |
|
Step 4 |
Click the FTD tab and select a device that you want. |
|
Step 5 |
In the Device Actions pane on the right, click Manage Licenses. If the license is valid, the Status shows Enabled. |
Maximum Concurrent VPN Sessions By Device Model
There is a maximum limit to the number of concurrent remote access VPN sessions allowed on a device based on the device model. This limit is designed, so that system performance does not degrade to unacceptable levels. Use these limits for capacity planning.
|
Device Model |
Maximum Concurrent Remote Access VPN Sessions |
|---|---|
| Firepower 2110 | 1,500 |
| Firepower 2120 | 3,500 |
| Firepower 2130 | 7,500 |
| Firepower 2140 | 10,000 |
| Firepower Threat Defense Virtual | 250 |
RADIUS Change of Authorization
The RADIUS Change of Authorization (CoA) feature provides a mechanism to change the attributes of authentication, authorization, and accounting (AAA) session after it is authenticated. A key challenge for RA VPNs is to secure the internal network against compromised endpoints and to secure the endpoint itself when it is affected by viruses or malware, by remediating the attack on the endpoint. There is a need to secure the endpoint and the internal network in all phases, that is, before, during, and after the RA VPN session. The RADIUS CoA feature helps in achieving this goal.
If you use Cisco Identity Services Engine (ISE) RADIUS servers, you can configure Change of Authorization policy enforcement. When a policy changes for a user or user group in AAA, ISE sends CoA messages to the FDM-managed device to reinitialize authentication and apply the new policy. An Inline Posture Enforcement Point (IPEP) is not required to apply access control lists (ACLs) for each VPN session established with the FDM-managed device.
Configure Change of Authorization on the FDM-Managed Device
Most of the Change of Authorization policy is configured in the ISE server. However, you must configure the FDM-managed device to connect to ISE correctly.
Before you begin
If you use hostnames in any object, ensure that you configure DNS servers for use with the data interfaces, as explained in Configuring DNS for Data and Management Interfaces section of the System Settings chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.You typically need to configure DNS anyway to have a fully-functional system.
Procedure
Procedure
|
Step 1 |
Log in to the Firewall Device Manager for your FDM-managed device. |
||
|
Step 2 |
Configure the extended access control list (ACL) for redirecting initial connections to ISE. The purpose of the redirect ACL is to send initial traffic to ISE so that ISE can assess the client posture. The ACL should send HTTPS traffic to ISE, but not traffic that is already destined for ISE, or traffic that is directed to a DNS server for name resolution. A sample redirect ACL might look like the following: However, note that ACLs have an implicit "deny any any" as the last access control entry (ACE). In this example, the last ACE, which matches TCP port www (that is, port 80), will not match any traffic that matches the first 3 ACEs, so those are redundant. You could simply create an ACL with the last ACE and get the same results. Note that in a redirect ACL, the permit and deny actions simply determine which traffic matches the ACL, with permit matching and deny not matching. No traffic is actually dropped, denied traffic is simply not redirected to ISE. To create the redirect ACL, you need to configure a Smart CLI object.
|
||
|
Step 3 |
Configure a RADIUS server group for dynamic authorization. |
||
|
Step 4 |
Create a connection profile that uses this RADIUS server group. See Configure an RA VPN Connection Profile. Use AAA Authentication (either only or with certificates), and select the server group in the Primary Identity Source for User Authentication, Authorization, and Accounting options. |
Verify Remote Access VPN Configuration of FDM-Managed Device
After you configure the remote access VPN and deploy the configuration to the device, verify that you can make remote connections.
Procedure
|
Step 1 |
From an external network, establish a VPN connection using the AnyConnect client. Using a web browser, open https://ravpn-address, where ravpn-address is the IP address or hostname of the outside interface on which you are allowing VPN connections. If necessary, install the client software and complete the connection. See How Users Can Install the AnyConnect Client Software on FTD. If you configured group URLs, also try those URLs. |
|
Step 2 |
In the Security Devices page, select the device you want to verify and click Command Line Interface under Device Actions. |
|
Step 3 |
Use the show vpn-sessiondb command to view summary information about current VPN sessions. |
|
Step 4 |
The statistics should show your active AnyConnect Client session, and information on cumulative sessions, the peak concurrent number of sessions, and inactive sessions. Following is sample output from the command. 
|
|
Step 5 |
Use the show vpn-sessiondb anyconnect command to view detailed information about current AnyConnect VPN sessions. Detailed information includes encryption used, bytes transmitted and received, and other statistics. If you use your VPN connection, you should see the bytes transmitted/received numbers change as you re-issue this command. 
|
View Remote Access VPN Configuration Details of FDM-Managed Device
Procedure
|
Step 1 |
In the left pane, choose |
|
Step 2 |
In the left pane, click . |
|
Step 3 |
Click on a VPN configuration object present. The group shows summary information on how many connection profiles and group policies are currently configured.
|
Feedback