Managing Virtual Private Network in Security Cloud Control
Introduction to Site-to-Site Virtual Private Network
Introduction to Remote Access Virtual Private Network
- Configuring Remote Access VPN for an FDM-Managed Device

Managing Virtual Private Network in Security Cloud Control

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 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 FTD.

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	Yes	No	No	No
Cloud-delivered Firewall Management Center-managed Firewall Threat Defense	No	Yes	Yes	Yes
Secure Firewall ASA	No	Yes	Yes	Yes
Multicloud Defense	No	Yes	Yes	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 FTD.

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.

The following procedure explains how to configure the global policy through the Objects page. You can also enable, disable, and create policies when editing a VPN connection by clicking Edit for the IKE Policy settings.

The following topics explain how to configure IKE policies for each version:

Configuring IKEv1 Policies
Configuring IKEv2 Policies

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

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 Objects.
Step 2	Do one of these things: Click the blue plus button and select FDM > IKEv1 Policy to create a new IKEv1 policy. In the object page, select the IKEv1 policy you want to edit and click Edit in the Actions pane at the right.
Step 3	Enter an object name, up to 128 characters.
Step 4	Configure the IKEv1 properties. Priority - The relative priority of the IKE policy, from 1 to 65,535. The priority determines the order of the IKE policy compared by the two negotiating peers when attempting to find a common security association (SA). If the remote IPsec peer does not support the parameters selected in your highest priority policy, it tries to use the parameters defined in the next lowest priority. The lower the number, the higher the priority. Encryption - The encryption algorithm used to establish the Phase 1 security association (SA) for protecting Phase 2 negotiations. For an explanation of the options, see Deciding Which Encryption Algorithm to Use. Diffie-Hellman Group - The Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two peers must have a matching modulus group. For an explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use. Lifetime - The lifetime of the security association (SA), in seconds, from 120 to 2147483647 or blank. When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes. The default is 86400. To specify an unlimited lifetime, enter no value (leave the field blank). Authentication - The method of authentication to use between the two peers. For more information, see Deciding Which Authentication Method to Use. Preshared Key - Use the preshared key that is defined on each device. These keys allow for a secret key to be shared between two peers and to be used by IKE during the authentication phase. If the peer is not configured with the same preshared key, the IKE SA cannot be established. Certificate - Use the device identity certificates for the peers to identify each other. You must obtain these certificates by enrolling each peer in a Certificate Authority. You must also upload the trusted CA root and intermediate CA certificates used to sign the identity certificates in each peer. The peers can be enrolled in the same or a different CA. You cannot use self-signed certificates for either peer. Hash - The hash algorithm for creating a message digest, which is used to ensure message integrity. For an explanation of the options, see Deciding Which Hash Algorithms to Use.
Step 5	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

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 Objects.
Step 2	Do one of these things: Click the blue plus button and select FDM > IKEv2 Policy to create a new IKEv2 policy. In the object page, select the IKEv2 policy you want to edit and click Edit in the Actions pane at the right.
Step 3	Enter an object name, up to 128 characters.
Step 4	Configure the IKEv2 properties. Priority - The relative priority of the IKE policy, from 1 to 65,535. The priority determines the order of the IKE policy compared by the two negotiating peers when attempting to find a common security association (SA). If the remote IPsec peer does not support the parameters selected in your highest priority policy, it tries to use the parameters defined in the next lowest priority. The lower the number, the higher the priority. State - Whether the IKE policy is enabled or disabled. Click the toggle to change the state. Only enabled policies are used during IKE negotiations. Encryption - The encryption algorithm used to establish the Phase 1 security association (SA) for protecting Phase 2 negotiations. Select all algorithms that you want to allow, although you cannot include both mixed-mode (AES-GCM) and normal mode options in the same policy. (Normal mode requires that you select an integrity hash, whereas mixed-mode prohibits a separate integrity hash selection.) The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Encryption Algorithm to Use. Diffie-Hellman Group - The Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two peers must have a matching modulus group. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest group until a match is agreed upon. For an explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use. Integrity Hash - The integrity portion of the hash algorithm for creating a message digest, which is used to ensure message integrity. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. The integrity hash is not used with the AES-GCM encryption options. For an explanation of the options, see Deciding Which Hash Algorithms to Use. Pseudo-Random Function (PRF) Hash - The pseudo-random function (PRF) portion of the hash algorithm, which is used as the algorithm to derive keying material and hashing operations required for the IKEv2 tunnel encryption. In IKEv1, the Integrity and PRF algorithms are not separated, but in IKEv2, you can specify different algorithms for these elements. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Hash Algorithms to Use. Lifetime - The lifetime of the security association (SA), in seconds, from 120 to 2147483647 or blank. When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes. The default is 86400. To specify an unlimited lifetime, enter no value (leave the field blank).
Step 5	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.

The following topics explain how to configure IPsec proposals for each IKE version:

Create and Edit IKEv1 IPsec Proposal Object
Create and Edit IKEv2 IPsec Proposal Object

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: Click the blue plus button and select FDM > IKEv1 IPsec Proposal to create the new object. In the object page, select the IPsec proposal you want to edit and click Edit in the Actions pane at the right.
Step 3	Enter an object name for the new object.
Step 4	Select the Mode in which the IKEv1 IPsec Proposal object operates. Tunnel mode encapsulates the entire IP packet. The IPSec header is added between the original IP header and a new IP header. This is the default. Use tunnel mode when the firewall is protecting traffic to and from hosts positioned behind the 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. Transport mode encapsulates only the upper-layer protocols of an IP packet. The IPSec header is inserted between the IP header and the upper-layer protocol header (such as TCP). Transport mode requires that both the source and destination hosts support IPSec, and can only be used when the destination peer of the tunnel is the final destination of the IP packet. Transport mode is generally used only when protecting a Layer 2 or Layer 3 tunneling protocol such as GRE, L2TP, and DLSW.
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

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: Click the blue plus button and select FDM > IKEv2 IPsec Proposal to create the new object. In the object page, select the IPsec proposal you want to edit and click Edit in the Actions pane at the right.
Step 3	Enter an object name for the new object.
Step 4	Configure the IKE2 IPsec proposal objects: Encryption - The Encapsulating Security Protocol (ESP) encryption algorithm for this proposal. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Encryption Algorithm to Use. Integrity Hash - The hash or integrity algorithm to use for authentication. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Hash Algorithms to Use.
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 Manage > Secure Connections > Network Connections > Site to Site VPN.

Step 2

Click the Create Tunnel () icon and then click Site-to-Site VPN.

Step 3

In the Peer Selection area, provide the following information:

Configuration Name: Enter a unique topology name.

We recommend naming your topology to indicate that it is an FDM-managed device VPN, and its topology type.
Peer 1: Click the FDM tab and select an FDM-managed device.

Peer 2: Click the FDM tab and select an FDM-managed device.

If you choose an extranet device, select Static and specify an IP address or select Dynamic for extranet devices with DHCP assigned IP. The IP Address displays the IP address for static interface or DHCP Assigned for the dynamic interface.

Note

If one or both endpoint devices have dynamic IP addresses, see Configure Site-to-Site VPN Connections with Dynamically-Addressed Peers for additional instructions.

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

VPN Access Interface: Select the interface to establish a connection between peer 1 and peer 2.
Routing: Click Add Networks and select one or more protected networks to establish a site-to-site tunnel between the protected networks of peer 1 and peer 2
(Optional) NAT Exempt Interface: Select NAT Exempt for peer 1 and peer 2 to exempt the VPN traffic from NAT policies on the local VPN access interface. It must be configured manually for individual peers. If you do not want NAT rules to apply to the local network, select the interface that hosts the local network. This option works only if the local network resides behind a single routed interface (not a bridge group member). If the local network is behind more than one routed interface or one or more bridge group members, you must manually create the NAT exempt rules.

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.

Note

IKE policies are global to a device and apply to all VPN tunnels associated with it. Therefore, adding or deleting policies affect all VPN tunnels in which this device is participating.

Select either or both options as appropriate.

Note

By default, IKEV Version 2 is enabled.

Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.
The Local Pre-Shared Key and Remote Pre-Shared Key for the participating devices are auto-genreated. Preshared keys are secret key strings configured on each peer in the connection. These keys are used by IKE during the authentication phase.
Click IKE Version 1 to enable it.
Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.
The IPEv1 Pre-Shared Key is auto-generated.

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.

Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.
Choose the Diffie-Hellman Group for Perfect Forward Secrecy. For more information, see Deciding Which Diffie-Hellman Modulus Group to Use.
Click Next.

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.

Note

You must create AC policies for incoming and outgoing traffic on both peers.

In the Security Cloud Control navigation bar at the left, click Policies and select the option that you want.
Create policies for incoming and outgoing traffic on both peers.

The following example shows steps for creating AC policies on both peers.

Consider two FDM-managed devices 'FTD_BGL_972' and 'FTD_BGL_973' with Site-To-Site VPN connection between two protected networks 'boulder-network' and 'sanjose-network' respectively.

Creating the AC policy for permitting incoming traffic:

The policy 'Permit_incoming_VPN_traffic_from_973' is created on the 'FTD_BGL_972' device for allowing incoming traffic from the peer ('FTD_BGL_973').
- Source Zone: Set the zone of the peer device from which the network traffic originates. In this example, the traffic is originating from FTD_BGL_973 and reaching FTD_BGL_972.
- Source Network: Set the protected network of the peer device from which the network traffic originates. In this example, traffic is originating from 'sanjose-network' which is the protected network behind the peer device (FTD_BGL_973).
- Destination Network: Set the protected network of the device on which the network traffic arrives. In this example, traffic is arriving at 'boulder-network' which is the protected network behind the peer device (FTD_BGL_972). Note: The remaining fields can have the default value ("Any").
- Set Action to Allow for allowing the traffic subject to the intrusion and other inspection settings in the policy.
Creating the AC policy for permitting outgoing traffic:

The policy 'Permit_outgoing_VPN_traffic_to_973' is created on the 'FTD_BGL_972' device for permitting outgoing traffic to the peer ('FTD_BGL_973').
- Source Network: Set the protected network of the peer device from which the network traffic originates. In this example, traffic is originating from 'boulder-network' which is the protected network behind the peer device (FTD_BGL_972).
- Destination Zone: Set the zone of the peer device on which the network traffic arrives. In this example, the traffic is arriving from FTD_BGL_972 and reaching FTD_BGL_973.
- Destination Network: Set the protected network of the peer on which the network traffic arrives. In this example, traffic is arriving on 'sanjose-network' which is the protected network behind the peer device (FTD_BGL_972). Note: The remaining fields can have the default value ("Any").
- Set Action to Allow for allowing the traffic subject to the intrusion and other inspection settings in the policy.

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.

For more information, see Configure Routing.

Gateway-Select the network object that identifies the IP address for the gateway to the destination network. Traffic is sent to this address.
Interface-Select the interface through which you want to send traffic. In this example, the traffic is sent through 'outside' interface.
Destination Networks-Select one or network objects, that identify the destination network. In this example, the destination is 'sanjose-network' which is behind peer (FTD_BGL_973).

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 left pane, choose Manage > Secure Connections > Network Connections > Site to Site VPN.

Step 2

Select the desired site-to-site VPN tunnel that you want to edit.

Step 3

In the Actions pane, click Edit.

Note

Alternatively, you can perform the following to edit the configuration:

Open the VPN page and click Global View button in the filter panel (for more information, see Global View).

The illustration of all site-to-site VPN tunnels available across all devices appears.

To edit the configuration, one of the peers must be FDM-managed device.
Select a device by clicking the box.
Click View details to view its peers.
Click the peer device to view the tunnel details.

You can view the tunnel details, NAT information, and key exchange information pertaining to the device.
Click Edit in Tunnel Details.

Step 4

In the Peer Devices section, you can modify the following device configurations: Configuration Name, VPN Access Interface, and Protected Networks.

Note

You cannot change the participating devices.

Step 5

In the IKE Settings section, you can modify the following IKEv2 policies configurations:

Click the blue plus button for the respective device and select new IKEv2 policies. To delete an existing IKEv2 Policy, hover-over the selected policy and click the x icon.
Modify the Pre-Shared Key for the participating devices. If the pre-shared keys are different for endpoint devices, click the blue settings button and enter the appropriate pre-shared keys for the devices.
Click Next.

Step 6

In the IPSec Settings section, you can modify the following IPSec configurations:

Click the blue plus button to select new IKEv2 proposals. To delete an existing IKEv2 Proposal, hover-over the selected proposal and click the x icon.
Choose the Diffie-Hellman Group for Perfect Forward Secrecy.
Click Edit VPN, and then Finish.

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, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.
Step 2	Select the desired site-to-site VPN tunnel that you want to delete.
Step 3	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. In the left pane, click Objects. Click the blue plus button to create an object. Click FTD > Network. Identify the Boulder inside network. Enter an object name (for example, boulder-network). Select Create a network object. In the Value section: Select eq and enter a single IP address or a subnet address expressed in CIDR notation. Select range and enter an IP address range. For example, enter the network address as 10.1.1.0/24. Click Add. Click the blue plus button to create an object. Define the inside San Jose network. Enter the object name (for example, san-jose). Select Create a network object. In the Value section: Select eq and enter a single IP address or a subnet address expressed in CIDR notation. Select range and enter an IP address range. For example, enter the network address as 10.1.1.0/24. Click Add.
Step 2	Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder). In the left pane, click Security Devices > All Devices. Use the filter to find the device for which you want to create the NAT rule. In the Management area of the details panel, click NAT . Click > Twice NAT. In section 1, select Static. Click Continue. In section 2, select Source Interface = inside and Destination Interface = outside. Click Continue. In section 3, select Source Original Address = 'boulder-network' and Source Translated Address = 'boulder-network'. Select Use Destination. Select Destination Original Address = 'sanjose-network' and Source Translated Address = 'sanjose-network'. Note: Because you do not want to translate the destination address, you need to configure identity NAT for it by specifying the same address for the original and translated destination addresses. Leave all of the port fields blank. This rule configures identity NAT for both source and destination. Select Disable proxy ARP for incoming packets. Click Save. Repeat the process to create equivalent rules for each of the other inside interfaces.
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. Click > Twice NAT. In section 1, select Dynamic. Click Continue. In section 2, select Source Interface = inside and Destination Interface = outside. Click Continue. In section 3, select Source Original Address = 'boulder-network' and Source Translated Address = 'interface'. Click Save. Repeat the process to create equivalent rules for each of the other inside interfaces.
Step 4	Deploy configuration changes to Security Cloud Control. For more information, see Deploy Configuration Changes from Security Cloud Control to FTD.
Step 5	If you are also managing Firewall2 (San Jose), you can configure similar rules for that device. The manual identity NAT rule would be for 'sanjose-network' when the destination is boulder-network. Create new interface objects for the Firewall2 inside and outside networks. The manual dynamic interface PAT rule would be for 'sanjose-network' when the destination is "any."

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 Manage > Secure Connections > Network Connections > Site to Site VPN.

Step 2

Click the Create Tunnel () icon and then click Site-to-Site VPN.

Step 3

In the Peer Selection area, provide the following information:

Configuration Name: Enter a unique topology name.

We recommend naming your topology to indicate that it is a Firewall Threat Defense device VPN, and its topology type.
Peer 1: Click the FTD tab and select a Firewall Threat Defense device.
Peer 2: Click the FTD tab and select a Firewall Threat Defense device.

If you choose an extranet device, select Static and specify an IP address or select Dynamic for extranet devices with DHCP assigned IP. The IP Address displays the IP address for static interface or DHCP Assigned for the dynamic interface.

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

VPN Access Interface: Select the interface for both peer 1 and peer 2 to establish a connection between them.
LAN Interfaces: Select the interface for both peer 1 and peer 2 that controls the LAN subnet. You can select multiple interfaces
Routing: Click Add Networks and select one or more protected networks for peer 1 and peer 2 to establish a site-to-site tunnel between between them.

Step 6

Click Next.

Step 7

Note

IKE policies are global to a device and apply to all VPN tunnels associated with it. Therefore, adding or deleting policies affect all VPN tunnels in which this device is participating.

Select either or both options as appropriate.

Note

By default, IKEV Version 2 is enabled.

Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.
The Local Pre-Shared Key and Remote Pre-Shared Key for the participating devices are auto-genreated. Preshared keys are secret key strings configured on each peer in the connection. These keys are used by IKE during the authentication phase.
Click IKE Version 1 to enable it.
Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.
The IPEv1 Pre-Shared Key is auto-generated.

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.

Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.
Choose the Diffie-Hellman Group for Perfect Forward Secrecy. For more information, see Encryption and Hash Algorithms Used in VPN.
Click Next.

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:

Choose Administration > Integrations > Firewall Management Center.
Ensure the check box corresponding to Cloud-Delivered FMC is checked and in the Actions pane on the right, click Deployment.
Select the device participating in the site-to-site VPN configuration and click Deploy.
Choose Devices > VPN > Site To Site. You can see the same VPN topology that was configured in Security Cloud Control.

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 Manage > Secure Connections > Network Connections > Site to Site VPN.
Step 2	Click the Create Tunnel () icon and then click Site-to-Site VPN.
Step 3	In the Peer Selection area, provide the following information: Configuration Name: Enter a unique topology name. Peer 1: Click the FTD tab and select a Firewall Threat Defense device. Peer 2: Click the Multicloud Defense tab and select the gateway you want. If you choose an extranet device, select Static and specify an IP address or select Dynamic for extranet devices with DHCP assigned IP. The IP Address displays the IP address for static interface or DHCP Assigned for the dynamic interface.
Step 4	Click Next.
Step 5	In the Peer Details area, provide the following information: VPN Access Interface: Select the interface for Firewall Threat Defense to establish a connection with the gateway. Public IP (optional): Specify the public IP address of the NAT that maps to the outside interface of the selected Firewall Threat Defense. Routing: Click Add Networks and select one or more protected networks from Firewall Threat Defense to create a site-to-site tunnel between the selected networks and the Multicloud Defense Gateway
Step 6	Click Next.
Step 7	In the Tunnel Details area, provide the following information: Virtual Tunnel Interface IP: Specify the addresses for the new Virtual Tunnel Interfaces on the peer. You can assign any unused IP address that is currently not used on this device. Autonomous System Number: Specify the autonomous system number of the network.
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. 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 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: Choose Administration > Integrations > Firewall Management Center. Ensure the check box corresponding to Cloud-Delivered FMC is checked and in the Actions pane on the right, click Deployment. Select the device participating in the site-to-site VPN configuration and click Deploy. Choose Devices > VPN > Site To Site. You can see the same VPN topology that was configured in Security Cloud Control.

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 Manage > Secure Connections > Network Connections > Site to Site VPN.

Step 2

Click the Create Tunnel () icon and then click Site-to-Site VPN.

Step 3

In the Peer Selection area, provide the following information:

Configuration Name: Enter a unique topology name.

We recommend naming your topology to indicate that it is a Firewall Threat Defense device VPN, and its topology type.
Peer 1: Click the FTD tab and select a Firewall Threat Defense device.
Peer 2: Click the ASA tab and select a Secure Firewall ASAdevice.

If you choose an extranet device, select Static and specify an IP address or select Dynamic for extranet devices with DHCP assigned IP. The IP Address displays the IP address for static interface or DHCP Assigned for the dynamic interface.

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

VPN Access Interface: Select the interface for both peer 1 and peer 2 to establish a connection between them.
LAN Interfaces: Select the interface for both peer 1 and peer 2 that controls the LAN subnet. You can select multiple interfaces
Routing: Click Add Networks and select one or more protected networks for peer 1 and peer 2 to establish a site-to-site tunnel between between them.

Step 6

Click Next.

Step 7

In the Tunnel Details area, provide the following information:

Virtual Tunnel Interface IP: Specify the address for the new Virtual Tunnel Interfaces for Secure Firewall ASA. Security Cloud Control provides a sample address for Secure Firewall ASA which you can change if it causes conflict. You can assign any unused IP address that is currently not used on this device.

Step 8

Click Next.

Step 9

Note

IKE policies are global to a device and apply to all VPN tunnels associated with it. Therefore, adding or deleting policies affect all VPN tunnels in which this device is participating.

Select either or both options as appropriate.

Note

By default, IKEV Version 2 is enabled.

Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.
The Local Pre-Shared Key and Remote Pre-Shared Key for the participating devices are auto-genreated. Preshared keys are secret key strings configured on each peer in the connection. These keys are used by IKE during the authentication phase.
Click IKE Version 1 to enable it.
Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.
The IPEv1 Pre-Shared Key is auto-generated.

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.

Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.
Choose the Diffie-Hellman Group for Perfect Forward Secrecy. For more information, see Deciding Which Diffie-Hellman Modulus Group to Use.

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:

Choose Administration > Integrations > Firewall Management Center.
Ensure the check box corresponding to Cloud-Delivered FMC is checked and in the Actions pane on the right, click Deployment.
Select the device participating in the site-to-site VPN configuration and click Deploy.
Choose Devices > VPN > Site To Site. You can see the same VPN topology that was configured in Security Cloud Control.

Site-to-Site VPN Configuration 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

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.

Note

A site-to-site VPN connection cannot be configured in the following scenario:

If a device has more than one dynamic peer connection.

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.

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 Secure Connections > Site to Site VPN > ASA & FDM.

Step 2

Click the Create Tunnel () icon and then click Site-to-Site VPN.

Step 3

Step 4

In the Peer Selection area, provide the following information:

Configuration Name: Enter a unique topology name.
Peer 1: Click the ASA tab and select a Secure Firewall ASA device.
Peer 2: Click the ASA tab and select a Secure Firewall ASAdevice.

If you choose an extranet device, select Static and specify an IP address or select Dynamic for extranet devices with DHCP assigned IP. The IP Address displays the IP address for static interface or DHCP Assigned for the dynamic interface.

Step 5

Click Next.

Step 6

In the Peer Details area, provide the following information:

Select one of the options to create a new Policy Based or Route Based site-to-site VPN.
VPN Access Interface: Select the interface for both peer 1 and peer 2 to establish a connection between them.
(Applicable to Route Based) LAN Interfaces: Select the interface for both peer 1 and peer 2 that controls the LAN subnet. You can select multiple interfaces
Routing: Click Add Networks and select one or more protected networks for peer 1 and peer 2 to establish a site-to-site tunnel between between them.
(Applicable to Policy Based) NAT Exempt: Select to exempt the VPN traffic from NAT policies on the local VPN access interface. It must be configured manually for individual peers. If you do not want NAT rules to apply to the local network, select the interface that hosts the local network. This option works only if the local network resides behind a single routed interface (not a bridge group member). If the local network is behind more than one routed interface or one or more bridge group members, you must manually create the NAT exempt rules. For information on manually creating the required rules, see Exempt ASA Site-to-Site VPN Traffic from NAT.

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

Note

IKE policies are global to a device and apply to all VPN tunnels associated with it. Therefore, adding or deleting policies affect all VPN tunnels in which this device is participating.

Select either or both options as appropriate.

Note

By default, IKEV Version 2 is enabled.

Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.
The Local Pre-Shared Key and Remote Pre-Shared Key for the participating devices are auto-genreated. Preshared keys are secret key strings configured on each peer in the connection. These keys are used by IKE during the authentication phase.
Click IKE Version 1 to enable it.
Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.
The IPEv1 Pre-Shared Key is auto-generated.

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.

Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.
Choose the Diffie-Hellman Group for Perfect Forward Secrecy. For more information, see Encryption and Hash Algorithms Used in VPN.

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.

You are directed to the VPN Tunnels page that shows the newly configured site-to-site VPN tunnel. The changes are staged and must be deployed manually. A routing policy is created to route the VTI traffic automatically between the devices over the VTI tunnel. To see this policy, select the device from the Security Devices page and choose Configuration > Diff.

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 Manage > Secure Connections > Network Connections > Site to Site VPN.
Step 2	Click the Create Tunnel () icon and then click Site-to-Site VPN.
Step 3	In the Peer Selection area, provide the following information: Configuration Name: Enter a unique topology name. Peer 1: Click the ASA tab and select a Secure Firewall ASA device. Peer 2: Click the Multicloud Defense tab and select a multicloud gateway. If you choose an extranet device, select Static and specify an IP address or select Dynamic for extranet devices with DHCP assigned IP. The IP Address displays the IP address for static interface or DHCP Assigned for the dynamic interface.
Step 4	Click Next.
Step 5	In the Peer Details area, provide the following information: VPN Access Interface: Select the interface for Secure Firewall ASA to establish a connection with Multicloud Defense Gateway. LAN Interfaces: Select the interface for Secure Firewall ASA that controls the LAN subnet. You can select multiple interfaces Public IP (optional): Specify the public IP address of the NAT that maps to the outside interface of the selected Secure Firewall ASA. Routing: Click Add Networks and select one or more protected networks for Secure Firewall ASA to establish a site-to-site tunnel with Multicloud Defense Gateway.
Step 6	Click Next.
Step 7	In the Tunnel Details area, provide the following information: Virtual Tunnel Interface IP: Specify the addresses for the new Virtual Tunnel Interfaces on the peers. Security Cloud Control provides a sample address for Secure Firewall ASA which you can change if it causes conflict. You can assign any unused IP address that is currently not used on this device. Autonomous System Number (Peer 1): If the Secure Firewall ASA device does not have an autonomous system number configured, Security Cloud Control will suggest one for the device, which can be modified. If the device already has an autonomous system number configured, the current value will be displayed and cannot be modified. Autonomous System Number (Peer 2): If a BGP profile is assigned to the Multicloud Defense Gateway, the autonomous number associated with the profile is displayed, which cannot be modified. See Add a Multicloud Defense Gateway.
Step 8	Click Next.
Step 9	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 10	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 11	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

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.

Note

Procedure

Step 1	Create objects to define the various networks. In the left pane, click Objects. Click the blue plus button to create an object. Click FTD > Network. Identify the Boulder inside network. Enter an object name (for example, boulder-network). Select Create a network object. In the Value section: Select eq and enter a single IP address or a subnet address expressed in CIDR notation. Select range and enter an IP address range. For example, enter the network address as 10.1.1.0/24. Click Add. Click the blue plus button to create an object. Define the inside San Jose network. Enter the object name (for example, san-jose). Select Create a network object. In the Value section: Select eq and enter a single IP address or a subnet address expressed in CIDR notation. Select range and enter an IP address range. For example, enter the network address as 10.1.1.0/24. Click Add.
Step 2	Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder). In the left pane, click Security Devices > All Devices. Use the filter to find the device for which you want to create the NAT rule. In the Management area of the details panel, click NAT . Click > Twice NAT. In section 1, select Static. Click Continue. In section 2, select Source Interface = inside and Destination Interface = outside. Click Continue. In section 3, select Source Original Address = 'boulder-network' and Source Translated Address = 'boulder-network'. Select Use Destination. Select Destination Original Address = 'sanjose-network' and Source Translated Address = 'sanjose-network'. Note: Because you do not want to translate the destination address, you need to configure identity NAT for it by specifying the same address for the original and translated destination addresses. Leave all of the port fields blank. This rule configures identity NAT for both source and destination. Select Disable proxy ARP for incoming packets. Click Save. Repeat the process to create equivalent rules for each of the other inside interfaces.
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. Click > Twice NAT. In section 1, select Dynamic. Click Continue. In section 2, select Source Interface = inside and Destination Interface = outside. Click Continue. In section 3, select Source Original Address = 'boulder-network' and Source Translated Address = 'interface'. Click Save. Repeat the process to create equivalent rules for each of the other inside interfaces.
Step 4	Deploy configuration changes to Security Cloud Control. For more information, see Deploy Configuration Changes from Security Cloud Control to FTD.
Step 5	If you are also managing Firewall2 (San Jose), you can configure similar rules for that device. The manual identity NAT rule would be for 'sanjose-network' when the destination is boulder-network. Create new interface objects for the Firewall2 inside and outside networks. The manual dynamic interface PAT rule would be for 'sanjose-network' when the destination is "any."

Monitor Site-to-Site Virtual Private Networks

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

Security Cloud Control runs this connectivity check command on the FTD to determine if a tunnel is active or idle:
```
show vpn-sessiondb l2l sort ipaddress
```
Model ASA device(s) tunnels will always show as Idle.

To check tunnel connectivity from the VPN page:

Procedure

Step 1	In the left pane, choose Manage > Secure Connections > Network Connections > 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 FTD. (This feature is not yet available for AWS VPC site-to-site VPN tunnels.) This article describes:

Find VPN Tunnels with Missing Peers
Find VPN Peers with Encryption Key Issues
Find Incomplete or Misconfigured Access Lists Defined for a Tunnel
Find Issues in Tunnel Configuration

Resolve Tunnel Configuration Issues

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 Manage > Secure Connections > Network Connections > Site to Site VPN 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. Security Cloud Control reports the other peer name as, "[Missing peer IP.]"

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 Manage > Secure Connections > Network Connections > Site to Site VPN 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 and look in the Peers pane at the right. The peer information will show you both peers.
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 Manage > Secure Connections > Network Connections > Site to Site VPN 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 and look in the Peers pane at the right. The peer information shows you both peers.
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 Manage > Secure Connections > Network Connections > Site to Site VPN 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 icon appears for the peer having the issue. Hover over the icon to see the issue and resolution. 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 Security Devices.
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	Accept the device changes.
Step 5	In the left pane, click VPN > ASA/FDM Site-to-Site VPN 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	Preview and Deploy Configuration Changes for All Devices.

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 Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.
Step 2	Click the filter icon to open the filter pane.
Step 3	Use these filters to refine your search: Filter by Device-Click Filter by Device, select the device type tab, and check the devices you want to find by filtering. Tunnel Issues-Whether or not we have detected either side of the tunnel has issues. Some examples of a device having issues may be but not limited to is: missing associated interface or peer IP address or access list, IKEv1 proposal mismatches, etc. (Detecting tunnel issues is not yet available for AWS VPC VPN tunnels.) Devices/Services-Filter by type of device. Status–Tunnel status can be active or idle. Active-There is an open session where network packets are traversing the VPN tunnel or a successful session was established and hasn’t been timed-out yet. Active can assist to indicate that tunnel is active and relevant. Idle - Security Cloud Control is unable to discover an open session for this tunnel. The tunnel may either be not in use or there is an issue with this tunnel. Onboarded - Devices could be managed by Security Cloud Control or not managed (unmanaged) by Security Cloud Control. Managed – Filter by devices that Security Cloud Control manages. Unmanaged – Filter by devices that Security Cloud Control does not manage. Device Types - Whether or not either side of the tunnel is a live (connected device) or model device.
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 Manage > Secure Connections > Network Connections > Site to Site VPN 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 Manage > Secure Connections > Network Connections > Site to Site VPN 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 Manage > Secure Connections > Network Connections > Site to Site VPN 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.

Note

Use Search and Filter Site-to-Site VPN Tunnels to find a specific tunnel.

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 Manage > Secure Connections > Network Connections > Site to Site VPN 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.

Note

Use Search and Filter Site-to-Site VPN Tunnels to find a specific tunnel.

Site-to-Site VPN Global View

This is an example fo the global view. In the illustration, 'FTD_BGL_972' has a site-to-site connection with FTD_BGL_973 and FTD_BGL_974 devices.

Procedure

Step 1	In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN.
Step 2	Click the Global view button.
Step 3	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 4	Select one of the peers represented in the Global View.
Step 5	Click View Details.
Step 6	Click the other end of the VPN tunnel and Security Cloud Control displays Tunnel Details, NAT Information, and Key Exchange information for that connection: Tunnel Details-Displays the name and connectivity information about the tunnel. Clicking the Refresh icon updates the connectivity information for the tunnels. Tunnel Details specific to AWS connections-Tunnel details for AWS site-to-site connections are slightly different than for other connections. For each connection from the AWS VPC to your VPN gateway, AWS creates two VPN tunnels. This is for high availability. The name of the tunnel represents the name of the VPC your VPN gateway is connected to. The IP address named in the tunnel is the IP address that your VPN gateway knows as the VPC. If the Security Cloud Control Connectivity status shows active, the AWS tunnel state is Up. If the Security Cloud Control Connectivity state is inactive, the AWS tunnel state is Down. NAT Information-Displays the type of NAT rule being used, original and translated packet information, and provides links to the NAT table to view the NAT rule for that tunnel. (Not yet available for AWS VPC site-to-site VPN.) Key Exchange-Displays the cryptographic keys in use by the tunnel and key-exchange issues. (Not yet available for AWS VPC site-to-site VPN.)

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, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.
Step 2	Select the desired site-to-site VPN tunnel that you want to delete.
Step 3	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.

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.

Table 1. Attributes Secure Firewall Threat Defense Sends to RADIUS
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: group policy name OU=group policy name OU=group policy name;
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
Duo Two-Factor Authentication using LDAP

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
Configure Device for Duo RADIUS Using Security Cloud Control

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	Sign up for a Duo account.
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.

In the left pane, click Manage > Objects.
Click > RA VPN Objects (ASA & FTD) > Identity Source.
Provide a name and set the Device Type as FTD.
Select Radius Server Group and click Continue.

For details, see step 6 in Create a RADIUS Server Group.
In the Radius Server section, click the Add button and click Create New Radius Server.

See Create a RADIUS Server Object.

In the Server Name or IP Address field, enter your Duo Authentication Proxy server's fully-qualified hostname or IP address.
Once you have added the Duo RADIUS server to the group, click Add to create the new Duo RADIUS server group.

Step 2

Change the Remote Access VPN Authentication Method to Duo RADIUS.

In the left pane, click Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Expand the VPN configuration and click on the connection profile to which you want to add Duo.
In the Actions pane on the right, click Edit.
Select the Authentication Type can be AAA or AAA and Client Certificate.
In the Primary Identity Source for User Authentication list, select the server group you created earlier.
You typically do not need to select an "Authorization Server" or "Accounting Server".
Click Continue.
In the Summary and Instructions step, click Done to save the configuration.

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

The following topics explain the configuration in more detail:

System Flow for Duo LDAP Secondary Authentication
Configure Duo LDAP Secondary Authentication

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	Sign up for a Duo account.
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.

In the Security Cloud Control navigation bar on the left, click Manage > Objects.
Click the to create an object > RA VPN Objects (ASA & FTD) > Identity Source.
Enter a name for the object, for example, Duo-LDAP-server.
Select the Device Type as FTD.
Click Duo Ldap Identity Source and click Continue.
In the Edit Identity Source area, provide the following details:
- API Hostname: Enter the API Hostname that you obtained from your Duo account. The hostname should look like the following, with the X’s replaced with your unique value: API-XXXXXXXX.DUOSECURITY.COM. Uppercase is not required.
- Port: Enter the TCP port to use for LDAPS. This should be 636 unless you have been told by Duo to use a different port. Note that you must ensure that your access control list allows traffic to the Duo LDAP server through this port.
- Timeout: Enter the timeout, in seconds, to connect to the Duo server. The value can be 1-300 seconds. The default is 120. To use the default, either enter 120 or delete the attribute line.
- Integration Key: Enter the integration key that you obtained from your Duo account.
- Secret Key: Enter the secret key that you obtained from your Duo account. This key will subsequently be masked.
- Interface used to connect to Duo Server: Select the interface that is used for connecting to Duo Server.
  - Resolve via route lookup: Select this option to use the routing table to find the right path. For creating a routing table, see Routing.
  - Manually choose interface: Select this option and choose one of the interfaces from the list. The default interface is the diagnostic interface, but this will work only if you configure an IP address on the interface. Note: Ensure that the selected interface is present on the same device you want to connect to Duo Server.
  - Click Add.

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.

If you have not already done so, download and install the AnyConnect profile editor package. You can find this in the Cisco Software center (software.cisco.com) in the folder for your AnyConnect version. The base path at the time of this writing is Downloads Home > Security > VPN and Endpoint Security Clients > Cisco VPN Clients > AnyConnect Secure Mobility Client.
Open the AnyConnect VPN Profile Editor.
Select Preferences (Part 2) in the table of contents, scroll to the end of the page, and change Authentication Timeout to 60 (or more). The following image is from the AnyConnect 4.7 VPN Profile Editor; previous or subsequent versions might be different.
Choose File > Save, and save the profile XML file to your workstation with an appropriate name, for example, duo-ldap-profile.xml.
You can now close the VPN Profile Editor application.
In Security Cloud Control, upload RA VPN AnyConnect Client Profile.

Step 3

Create a group policy and select the AnyConnect profile in the policy.

The group policy that you assign to a user controls many aspects of the connection. The following procedure explains how to assign the profile XML file to the group. For more information, see Create New FTD RA VPN Group Policies.

In the Security Cloud Control navigation bar on the left, click Manage > Objects.
To edit an existing group policy, use the RA VPN Group Policy filter to view only the existing group policies and modify the policy that you want and save it.
To create a new group policy, click RA VPN Objects (ASA & FTD) > RA VPN Group Policy.
On the General page, configure the following properties:
- Name — For a new profile, enter a name. For example, Duo-LDAP-group.
- AnyConnect Client Profiles — Select the AnyConnect client profile object that you created.
Click Add to save the object.
Click Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Click the remote access VPN configuration that you want to update.
In the Actions pane on the right, click Group Policies.
Click + to select the group policies that you want to associate with the VPN configuration.
Click Save to save the group 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.

On the Security Cloud Control navigation page, click VPN > Remote Access VPN Configuration.
Expand the remote access VPN configuration and click the connection profile that you want to update.
In the Actions pane on the right, click Edit.

Under Primary Identity Source, configure the following:

Authentication Type — Choose either AAA Only or AAA and Client Certificate. You cannot configure two-factor authentication unless you use AAA.
Primary Identity Source for User Authentication — Select your primary Active Directory or RADIUS server. Note that you can select a Duo-LDAP identity source as the primary source. However, Duo-LDAP provides authentication services only, not identity services, so if you use it as a primary authentication source, you will not see usernames associated with RA VPN connections in any dashboards, and you will not be able to write access control rules for these users. (You can configure fallback to the local identity source if you want to.)

Secondary Identity Source — Select the Duo-LDAP identity source.

Note

If username in Primary Identity Source and Secondary Identity Source are the same, we recommend enabling Use Primary username for Secondary login in the Advanced options in the Connection Profile. Configuring this way allows the end-user to use a single username for both primary and secondary identity sources.

Click Continue.
On the Group Policy page, select the group policy that you created or edited.
Click Continue.
Click Done to save your changes to the connection profile.

Step 5

Preview and Deploy Configuration Changes for All Devices.

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.

When you register the device, you must do so with a Smart Software Manager account that is enabled for export-controlled features. The license must meet export control requirements before you can configure remote access VPN. You also cannot configure the feature using the evaluation license. Your purchase of an FDM-managed device automatically includes an license. The license covers all features not covered by the optional licenses. It is a perpetual license. The device must be registered to Secure Firewall Device Manager. See the Registering the Device section in the Licensing the System chapter of the Cisco Secure Firewall Threat Defense Configuration Guide for the version your device is running.
A license. For details, see Licensing Requirements for Remote Access VPN.
- To enable the license, see the Enabling or Disabling Optional Licenses section in the Licensing the System chapter of the Secure Firewall Threat Defense Configuration Guide for the version your device is running.

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.

If you use an encrypted connection for the directory realm used for authentication, you must upload a trusted CA certificate. For more information on certificates and how to upload them, see Configuring Certificates.

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.

Active Directory identity realm: As a primary authentication source. The user accounts are defined in your Active Directory (AD) server. See Configuring AD Identity Realms. See Create and Edit an Active Directory Realm Object.
RADIUS server group: As a primary or secondary authentication source, and for authorization and accounting. See Create or Edit a RADIUS Server Object or Group.

Local Identity Source (the local user database): As a primary or fallback source. You can define users directly on the device and not use an external server. If you use the local database as a fallback source, ensure that you define the same usernames/passwords as the ones described in the external server.

Note

You can create user accounts directly on the FDM-managed device only from Secure Firewall Device Manager. See Configure Local Users.

Step 4

(Optional.) Create New RA VPN Group Policies.

The group policy defines user-related attributes. You can configure group policies to provide differential access to resources based on group membership. Alternatively, use the default policy for all connections.

Step 5

Create an RA VPN Configuration.

Step 6

Configure an RA VPN Connection Profile.

Step 7

Review and deploy configuration changes to the devices.

Step 8

Allow Traffic Through the Remote Access VPN.

Step 9

(Optional.) Enable the identity policy and configure a rule for passive authentication. If you enable passive user authentication, users who logged in through the remote access VPN will be shown in the dashboards, and they will also be available as traffic-matching criteria in policies. If you do not enable passive authentication, RA VPN users will be available only if they match an active authentication policy. You must enable the identity policy to get any username information in the dashboards or for traffic matching. See Configure Identity Policies.

Important

If you change the Remote Access VPN configuration by using a local manager like Secure Firewall 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.

See Monitoring Remote Access Virtual Private Network.

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. Make sure you accept the EULA and have K9 (encrypted image) privileges. Select the "AnyConnect Headend Deployment Package" package for your operating system. The package name will be similar to, "anyconnect-win-4.7.04056-webdeploy-k9.pkg. There are separate headend Webs Deploy packages for Windows, macOS, and Linux.
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 Upload > /action/uploaddiskfile.
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. { "version": null, "name": "691f47e1-90c7-11e9-a361-79e2452f0c57.pkg", "fileName": "691f47e1-90c7-11e9-a361-79e2452f0c57.pkg", "id": "691f47e1-90c7-11e9-a361-79e2452f0c57.pkg", "type": "fileuploadstatus", "links": { "self": 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 AnyConnectPackageFile > POST /object/anyconnectpackagefiles. 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: { "platformType": "WINDOWS", "diskFileName": "691f47e1-90c7-11e9-a361-79e2452f0c57.pkg", "type": "anyconnectpackagefile", "name": "AnyConnectWindowsBGL" } In the platformType field, enter the OS platform as WINDOWS, MACOS, or LINUX. In the diskFileName field, enter the fileName that you have recorded after uploading disk file. In the name field, enter a name that you want for the package. Click TRY IT OUT!. In the Response Body field, the API response appears in the following format after a successful POST operation. { "version": "ni7xeneslft3p", "name": "AnyConnectWindowsBGL", "description": null, "diskFileName": "41d592e3-90ca-11e9-a361-6d05320a165d.pkg", "md5Checksum": "9bbe53dcf92e515d3ce5423048212488", "platformType": "WINDOWS", "id": "c9c9dfe3-9cd8-11e9-a361-23534f081c43", "type": "anyconnectpackagefile", "links": { "self": "https:/>/ftd.example.com:972...1-cf32937ce0df" } } The AnyConnect package is created on Firewall Device Manager.
Step 11	Click AnyConnectPackageFile > GET /object/anyconnectpackagefiles > TRY IT OUT!. The Response Body shows all AnyConnect package files. A sample response is shown below. { "items": [ { "version": "la4nwceqk2sg4", "name": "AnyConnectWindowsBGL", "description": null, "diskFileName": "82f1e362-9cd8-11e9-a361-9758ba07962d.pkg", "md5Checksum": "9bbe53dcf92e515d3ce5423048212488", "platformType": "WINDOWS", "id": "c9c9dfe3-9cd8-11e9-a361-23534f081c43", "type": "anyconnectpackagefile", "links": { "self": "https://ftd.example.com:972...1-23534f081c43" } } ],
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 AnyConnectPackageFile > Delete. 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 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.

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.

Make sure you accept the EULA and have K9 (encrypted image) privileges.
Select the "AnyConnect Headend Deployment Package" package for your operating system. The package name will be similar to "anyconnect-win-4.7.04056-webdeploy-k9.pkg." There are separate headend packages for Windows, macOS, and Linux.

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.

Note

If you are uploading the AnyConnect package to an HTTPS server, ensure that the following steps are performed:

Upload the trusted CA certificate of that server on the FDM-managed device from Firewall Device Manager. To upload the certificate, see the "Uploading Trusted CA Certificates" section in the "Certificates" chapter of Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version X.Y.
Install the trusted CA certificate on the 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	Create an RA VPN Configuration from steps 1-4.
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 to upload the package. Security Cloud Control validates if the path is reachable, and the specified filename is a valid package. When the validation is successful, the names of the AnyConnect packages appear. As you add more FDM-managed devices to the RA VPN configuration, you can upload the AnyConnect packages to them.
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 Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Step 2	Select the RA VPN configuration to be modified, and under Actions, click Edit.
Step 3	In AnyConnect Packages Detected, click 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 Edit. The existing package disappears from the corresponding field.
Step 4	Specify the server's path where the new AnyConnect package is preloaded and click to upload the package.
Step 5	Click OK. The new AnyConnect package is added to the RA VPN configuration.
Step 6	Continue to Create an RA VPN Configuration from step 6 onwards.

Delete the AnyConnect Package

Procedure

Step 1

In the left pane, click Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.

Step 2

Select the RA VPN configuration to be modified, and under Actions, click Edit.

Step 3

In AnyConnect Packages Detected, click 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.

Note

Click Cancel to stop the delete operation and retain the existing package.

Step 4

Click OK. The device's Configuration Status is in 'Not Synced' state.

Note

If you want to undo the delete action at this stage, click Security Devices page and click Discard Changes to retain the existing AnyConnect package.

Step 5

Review and deploy configuration changes to the devices.

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 > RA VPN Objects (ASA & FTD) > 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.

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.

You can create access control rules with user identities. See How to Implement an Identity Policy for more information.

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	mail 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 (Start > Run > adsiedit.msc). 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 , then click RA VPN Objects (ASA & FTD) > Identity Source.

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.

Directory Username, Directory Password - The distinguished username and password for a user with appropriate rights to the user information you want to retrieve. For AD, the user does not need elevated privileges. You can specify any user in the domain. The username must be fully qualified; for example, Administrator@example.com (not simply Administrator).

Note

The system generates ldap-login-dn and ldap-login-password from this information. For example, Administrator@example.com is translated as cn=administrator,cn=users,dc=example,dc=com. Note that cn=users is always part of this translation, so you must configure the user you specify here under the common name "users" folder.

Base Distinguished Name - The directory tree for searching or querying user and group information, that is, the common parent for users and groups. For example, cn=users,dc=example,dc=com.
AD Primary Domain - The fully qualified AD domain name that the device should join. For example, example.com.

Step 7

Configure the directory server properties.

Hostname/IP Address - The hostname or IP address of the directory server. If you use an encrypted connection to the server, you must enter the fully-qualified domain name, not the IP address.
Port - The port number used for communications with the server. The default is 389. Use port 636 if you select LDAPS as the encryption method.
Encryption - To use an encrypted connection for downloading user and group information, select the desired method,STARTTLS or LDAPS. The default is None, which means that user and group information is downloaded in clear text.
- STARTTLS negotiates the encryption method and uses the strongest method supported by the directory server. Use port 389. This option is not supported if you use the realm for remote access VPN.
- LDAPS requires LDAP over SSL. Use port 636.
Trusted CA Certificate - If you select an encryption method, upload a Certificate Authority (CA) certificate to enable a trusted connection between the system and the directory server. If you are using a certificate to authenticate, the name of the server in the certificate must match the server Hostname / IP Address. For example, if you use 10.10.10.250 as the IP address but ad.example.com in the certificate, the connection fails.

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 in the Actions pane of the details panel.
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 , then click RA VPN Objects (ASA & FTD) > Identity Source.
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: Server Name or IP Address - The fully-qualified host name (FQDN) or IP address of the server. Authentication Port (Optional) - The port on which RADIUS authentication and authorization are performed. The default is 1812. Timeout - The length of time, 1-300 seconds, that the system waits for a response from the server before sending the request to the next server. The default is 10 seconds. Enter the Server Secret Key(Optional) - The shared secret that is used to encrypt data between the Firepower Threat Defense device and the RADIUS server. The key is a case-sensitive, alphanumeric string of up to 64 characters, with no spaces. The key must start with an alphanumeric character or an underscore, and it can contain the special characters: $ & - _ . + @. The string must match the one configured on the RADIUS server. If you do not configure a secret key, the connection is not encrypted.
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: Redirect ACL - Select the extended Access Control List (ACL) to use for the RA VPN redirect ACL. If you do not have an extended ACL you must create the required extended ACL object from a Smart CLI template in the FDM-managed device console. See the Configuring Smart CLI Objects section of the Advanced Configuration chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running. The purpose of the redirect ACL is to send initial traffic to ISE to 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. See the Configure Change of Authorization section of the Virtual Private Networks (VPN) chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Managerfor the version your device is running. Diagnostic Interface -Enabling this option allows the system to always use the "Diagnostic" interface to communicate with the server. If you leave this disabled, Security Cloud Control will default to using the routing table to determine the which interface to use.
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 , then click FTD > Identity Source.

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:

Dead Time - Failed servers are reactivated only after all servers have failed. The dead time is how long to wait after the last server fails before reactivating all servers.
Maximum Failed Attempts - The number of failed requests (that is, requests that do not get a response) sent to a RADIUS server in the group before trying the next server. When the maximum number of failed attempts is exceeded, the system marks the server as Failed. For a given feature, if you configured a fallback method using the local database, and all the servers in the group fail to respond, then the group is considered to be unresponsive, and the fallback method is tried. The server group remains marked as unresponsive for the duration of the dead time, so that additional AAA requests within that period do not attempt to contact the server group, and the fallback method is used immediately.
Dynamic Authorization/Port (Optional) - If you enable RADIUS dynamic authorization or change of authorization (CoA) services for this RADIUS server group, the group will be registered for CoA notification and listen on the specified port for CoA policy updates from Cisco Identity Services Engine (ISE). Enable dynamic authorization only if you are using this server group in a remote access VPN in conjunction with ISE.

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 to add existing RADIUS server objects. Optionally, you can create a new RADIUS server object from this window is necessary.

Note

Add these objects in priority, as the first server in the list is used until it is unresponsive. FDM-managed device then defaults to the next server in the list.

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 in the Actions pane of the details panel.
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 > RA VPN Objects (ASA & FTD) > RA VPN Group Policy.
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: Click the required tabs and configure the attributes on the page: General Attributes AnyConnect Client Profiles Session Setting Attributes Address Assignment Attributes Split Tunneling Attributes AnyConnect Attributes Traffic Filters Attributes Windows Browser Proxy Attributes
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 Device > Advanced Configuration > Smart CLI > Objects, 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

You are not allowed to add ASA and FDM-managed device in the same Remote Access VPN Configuration.
An FDM-managed device can't have more than one RA VPN Configuration.

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.
1. In the left pane, click Security Devices and search for one or more FDM-managed devices to be synchronized.
2. 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

Step 1

In the left pane, click Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.

Step 2

Click the blue plus button to create a new RA VPN configuration.

Step 3

Enter a name for the Remote Access VPN configuration.

Step 4

Click the blue plus button to add FDM-managed devices to the configuration. You can add the device details and configure network traffic-related permissions that are associated with the device.

Provide the following device details:

Device: Select an FDM-managed device that you want to add and click Select.

Important

You are not allowed to add ASA and FDM-managed device in the same Remote Access VPN Configuration.

Certificate of Device Identity: Select the internal certificate used for establishing the identity of the device. This establishes the device identity for AnyConnect clients when they make a connection to the device. Clients must accept this certificate to complete a secure VPN connection. If you do not already have a certificate, click Create New Internal Certificate in the drop-down list. See Generating Self-Signed Internal and Internal CA Certificates.
Outside Interface: The interface to which users connect when making the remote access VPN connection. Although this is normally the outside (internet-facing) interface, choose whichever interface is between the device and the end-users you are supporting with this connection profile.

To create a new subinterface, see Configure Firepower VLAN Subinterfaces and 802.1Q Trunking.
Fully Qualified Domain Name or IP for the Outside Interface: The name of the interface, for example, ravpn.example.com or the IP address must be provided. If you specify a name, the system can create a client profile for you. Note: You are responsible for ensuring that the DNS servers used in the VPN and by clients can resolve this name to the outside interface's IP address. Add the FQDN to the relevant DNS servers.

Click Continue to configure the traffic permissions.
- Bypass Access Control policy for decrypted traffic (sysopt permit-vpn): Decrypted traffic is subjected to Access Control Policy inspection by default. Enabling this option bypasses the decrypted traffic option bypasses the access control policy inspection, but the VPN Filter ACL and the authorization ACL downloaded from the AAA server are still applied to VPN traffic. Note that if you select this option, the system configures the sysopt connection permit-vpn command, which is a global setting. This will also impact the behavior of site-to-site VPN connections. If you do not select this option, it might be possible for external users to spoof IP addresses in your remote access VPN address pool, and thus gain access to your network. This can happen because you will need to create access control rules that allow your address pool to have access to internal resources. If you use access control rules, consider using user specifications to control access, rather than source IP address alone. The downside of selecting this option 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.
- NAT Exempt: Enable 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 RA 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.

Step 5

Click OK.

If you have onboarded an Firewall Device Manager Version 6.4.0 device, the AnyConnect Packages Detected shows the AnyConnect packages available in the device.
If you have onboarded an Firewall Device Manager Version 6.5.0 or later device, you must add the AnyConnect packages from the server where the AnyConnect packages are pre-uploaded. See Upload AnyConnect Software Packages to an FDM-Managed Device Running Version 6.5.0 for instructions.

Step 6

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.
- Click + to select the required group policies. To create a new RA VPN group policy, see Create New FTD RA VPN 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.

Modify the name if required.
Click the blue plus button to add a new device
Click to perform the following on the FDM-managed device.
- Click Edit to modify the existing RA VPN configuration.
- Click Remove to remove the FDM-managed device from the RA VPN configuration. All connection profiles and RA VPN settings associated with that device except the group policies are deleted. You can remove the group policies explicitly from the objects page. Note: You cannot remove the FDM-managed device if that is the only device using the configuration. Alternatively, you can remove the RA VPN configuration.

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

Step 1

Step 2

In the left pane, click Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM. 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.

Connection Profile Name: The name for this connection, up to 50 characters without spaces. For example, MainOffice.

Note

The name you enter here is what users will see in the connection list in the AnyConnect client. Choose a name that will make sense to your users.

Group Alias, Group URL: Aliases contain alternate names or URLs for a specific connection profile. VPN users can choose an alias name in the AnyConnect client in the list of connections when they connect to the FDM-managed device. The connection profile name is automatically added as a group alias. You can also configure the list of group URLs, which your endpoints can select while initiating the Remote Access VPN connection. If users connect using the group URL, the system will automatically use the connection profile that matches the URL. This URL would be used by clients who do not yet have the AnyConnect client installed. Add as many group aliases and URLs as required. These aliases and URLs must be unique across all connection profiles defined on the device. Group URLs must start with https://.
For example, you might have the alias Contractor and the group URL https://ravpn.example.com/contractor. Once the AnyConnect client is installed, the user would simply select the group alias in the AnyConnect VPN drop-down list of connections.

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:

AAA Only: Authenticate and authorize users based on username and password. For details, see Configure AAA for a Connection Profile.
Client Certificate Only: Authenticate users based on client device identity certificate. For details, see Configure Certificate Authentication for a Connection Profile.
AAA and ClientCertificate: Use both username/password and client device identity certificate.

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.

Note

If the group policy you need does not yet exist, create the group policy on the Objects page and then associate the policy to the RA VPN configuration. For detailed information about group policies, see Create New RA VPN Group Policies.

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 to copy the instructions to the clipboard, and then distribute them to your users.

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.

See Configure the FDM Access Control Policy.

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. Remove the old package and upload the new package from the Firewall Device Manager UI. Remove the old package and upload the new package from the Firewall Device Manager API explorer.
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 Device > Remote Access VPN group. The group shows summary information on how many connection profiles and group policies are currently configured.

Step 4

Click the view () button (View configuration button.) to open a summary of the connection profile and connection instructions.

Note

You can edit any one of the connection profiles to upload the AnyConnect package to the FDM-managed device.

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.

Note

Alternatively, you can use the Firewall Device Manager API explorer to remove and upload a new AnyConnect package.

Edit the URL to point to /#/api-explorer, for example, https://ftd.example.com/#/api-explorer.
Delete a package from the FDM-managed device, click AnyConnectPackageFile > Delete. In the objID field, type the package id and click TRY IT OUT!.
Upload a new package by performing the steps that are described in the Upload AnyConnect Software Packages to Firepower Threat Defense Devices section.

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.

Verify the new package is referenced in the RA VPN connection profile

Procedure

Step 1	In the left pane, click Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and select the FDM-managed device which has the upgraded AnyConnect package. This device would be reporting conflict.
Step 4	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 5	View the new AnyConnect package by performing the following: Click VPN > Remote Access VPN. Click the RA VPN configuration that is associated with this FDM-managed device. Click Edit under Actions. The new package is displayed under Devices.

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 button.
Step 3	Click RA VPN Objects (ASA & FDM) > AnyConnect Client Profile.
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

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

Procedure

Step 1	In the left pane, choose Manage > Objects.
Step 2	Click the blue plus button.
Step 3	Click RA VPN Objects (ASA & FDM) > AnyConnect Client Profile.
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 Security Devices.
Step 2	Click the Devices device.
Step 3	Click the FTD tab and select a device that you want.
Step 4	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

Step 1

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:

access-list redirect extended deny ip any host <ISE server IP>

access-list redirect extended deny ip any host <DNS server IP>

access-list redirect extended deny icmp any any

access-list redirect extended permit tcp any any eq www

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.

Choose Device > Advanced Configuration > Smart CLI > Objects.
Click + to create a new object.
Enter a name for the ACL. For example, redirect.
For CLI Template, select Extended Access List.
Configure the following in the Template body:
- configure access-list-entry action = permit
- source-network = any-ipv4
- destination-network = any-ipv4
- configure permit port = any-source
- destination-port = HTTP
- configure logging = disabled
  
  The ACE should look like the following:

Click OK.

This ACL will be configured the next time you deploy changes. You do not need to use the object in any other policy to force deployment.

Note

This ACL applies to IPv4 only. If you also want to support IPv6, simply add a second ACE with all the same attributes, except select any-ipv6 for the source and destination networks. You can also add the other ACEs to ensure traffic to the ISE or DNS server is not redirected. You will first need to create host network objects to hold the IP addresses of those servers.

Step 3

Configure a RADIUS server group for dynamic authorization.

Perform the below steps by following the instructions provided in the Create or Edit a Firepower Threat Defense RADIUS Server Object or Group section.

Create a RADIUS Server Object
Create a RADIUS Server Group

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 Manage > Secure Connections > End User Connections > Remote Access VPN > ASA & FDM

Step 2

Click on a VPN configuration object present.

The group shows summary information on how many connection profiles and group policies are currently configured.

Expand the RA VPN configuration to view all connection profiles associated with them.
- Click the add + button to add a new connection profile.
- Click the view button ( ) to open a summary of the connection profile and connection instructions. Under Actions, you can click Edit to modify the changes.
You can click one of the following options under Actions to perform additional tasks:
- Click Group Policies to assign/add group policies.
- Click a configuration object or connection profile that you no longer need and click Remove to delete.

Monitor Remote Access Virtual Private Network Sessions

Remote access Virtual Private Network provides secure connections for remote users, such as mobile users or telecommuters. Monitoring these connections provides important indicators of connection and user session performance at a glance. Security Cloud Control remote access VPN monitoring capabilities enable you to determine quickly whether remote access VPN problems exist and where they exist. You can then apply this knowledge and use your network management tools to reduce or eliminate problems for your network and users. You can also disconnect remote access VPN sessions as needed.

The Remote Access Virtual Private Monitoring page provides the following information:

A list of active and historical sessions for up to a year.
Shows intuitive graphical visuals to provide at-a-glance views from all active VPN headends managed by Security Cloud Control.
The live session screen shows the most used operating system and VPN connection profile in the Security Cloud Control tenant. It also shows the average session duration and data uploaded and downloaded.
Filtering capabilities to narrow your search based on criteria such as device type, device names, session length, and the amount of data transmitted and received.

Monitor Live AnyConnect Remote Access VPN Sessions

You can monitor real-time data from active AnyConnect remote access VPN sessions on the devices. This data is automatically refreshed every 10 minutes. If you want to retrieve the latest list of sessions at any point, you click the reload iconappearing on the right corner of the screen.

Before you begin

Onboard the remote access VPN head-ends to Security Cloud Control.
Ensure that the connectivity status of the devices you want to monitor live data is "Online" on the Security Devices page.

Procedure

Step 1

In the left pane, click Monitor > Insights & Reports > Reports & Analytics > Remote Access Monitoring.

Step 2

Click RA VPN.

Step 3

Click Live.

You can search and filter RA VPN sessions to narrow down your search based on criteria such as device type, session length, and upload and download data range.

Note

The Data TX and Data RX information are not available for FTD.

View Live Remote Access VPN Data

The live data is presented both in the dashboard and tabular form.

Dashboard View

You have to click the Show Charts View icon appearing at the top right corner of the screen to see the dashboard.

The dashboard provides at-a-glance views from all active VPN headends managed by Security Cloud Control.

Breakdown (All Devices): Shows a total number of live sessions. It also shows a pie chart that is divided into four arc lengths. It illustrates the percentage of VPN sessions of the top three devices with the highest number of sessions. The remaining arc length represents the aggregate of other devices.
Shows most used operating system and connection profile in the Security Cloud Control tenant.
Shows average session duration and data uploaded and downloaded.
Active Sessions by Country: Shows an interactive heat map of the location of the users connected to your RA VPN headends.
- Countries from which users have connected are shown in progressively darker shades of blue, depending on the relative proportion of the sessions established from that country — the darker the blue color means more sessions are established from that country.
- The legend at the bottom of the map provides a scale that indicates the correlation between the number of sessions in a country and the shade of blue used to color the country.
- Hover the mouse pointer on the map to see the country's name and the total number of active user sessions established from that country.
- Hover the mouse pointer on the table to see the country's location and the total number of active user sessions on the map.

Tabular View

Click the Show Tabular View icon on the top right corner of the screen to view the data in tabular format.

The tabular form provides a complete list of VPN users connected presently.

The Location column shows the location of all the users connected to the VPN headends by geolocating their public IP addresses. Click a row to view the user details. On clicking the location link in the left pane, the location of the user is shown on the Google map.

Important

Security Cloud Control applies a standard filter to the live data and represents them on the dashboard. You can apply new filters only when tabular data is shown, since the custom filters are not supported in the visual dashboard view. Click Clear to remove all filters you have applied. You cannot remove the standard filter.

You can use Search and Filter RA VPN Sessions functionalities to narrow down your search based on criteria such as device type, session length, and upload and download data range. Note that a maximum of 10,000 results can be displayed at once.

A green dot with an Active label in the status column indicates an active VPN user's session.

Monitor Historical AnyConnect Remote Access VPN Sessions

You can monitor the historical data from AnyConnect Remote Access VPN sessions recorded over the past 1 year.

Before you begin

Onboard the RA VPN head-ends to Security Cloud Control.

Procedure

Step 1

In the left pane, click Monitor > Insights & Reports > Reports & Analytics > Remote Access Monitoring.

Step 2

Click RA VPN.

Step 3

Click Historical.

Remote Access VPN Session data is stored and available to query for 1 year.
You can use Search and Filter RA VPN Sessions functionalities to narrow down your search based on criteria such as device type, session length, and upload and download data range.
The Data TX and Data RX information are not available for Secure Firewall Threat Defense.

View Historical Remote Access VPN Data

The historical data is presented both in the dashboard and tabular form.

Dashboard View

You have to click the Show Charts View icon appearing at the top right corner of the screen to see the dashboard. You will see the dashboard view along with the tabular view.

The dashboard provides at-a-glance views from all active VPN headends managed by Security Cloud Control. It provides a bar graph showing the VPN sessions recorded for all devices in the last 24 hours, 7 days, and 30 days. You can select the duration from the drop-down. You can hover over on individual bars to see the date and the total number of sessions on that day.

Tabular View

You have to click the Show Tabular View icon appearing at the top right corner of the screen to see only the tabular view. The tabular form provides a complete list of VPN users connected over the last year.

Important

Security Cloud Control applies a standard filter to the historical data and represents them on the dashboard. You can apply new filters only when tabular data is shown, since the dashboard is not supported for custom filters. Clearing the newly applied filters relaunches the dashboard (On the screen, click Clear to remove manually applied filters). You cannot remove the standard filter.

You can use Search and Filter RA VPN Sessions functionalities to narrow down your search based on criteria such as session date and time range, session length, and upload and download data range. Note that a maximum of 10,000 results can be displayed at once.

A green dot with an Active label in the status column indicates an active VPN user's session.

Search and Filter Remote Access VPN Sessions

Search

Use the search bar functionality to find remote access VPN sessions. Start typing device name, IP address, or serial number in the search bar, and remote access VPN sessions that fit the search criteria will be displayed. Search is not case-sensitive.

Filter

Use the filter sidebar to find remote access VPN sessions based on criteria such as session time range, session length, and upload and download data range. The filter functionality is available to both live and historical views.

Filter by Devices: Select one or all devices from the All Types tab to view sessions from selected devices. The window also categorizes the devices based on their type and displays them under the corresponding tabs.
Sessions Time Range (Applicable only for historical data): View historical sessions from a specified date and time range. Note that you can view data recorded over the last three months.
Sessions Length: View sessions based on a specified session's duration length. Set the time unit (hours, minutes, or seconds) and specify the minimum and maximum duration length by moving the slider. You can also specify the length in the provided fields.
Upload (TX): View sessions based on a specified amount of data uploaded or transferred to the secured network. Set the unit (GB, MB, or KB) and select the range by moving the slider accordingly. You can also specify the values in the available fields.
Download (RX): View sessions based on a specified amount of data downloaded or received from the secured network. Set the unit (GB, MB, or KB) and select the range by moving the slider accordingly. You can also specify the values in the available fields.

Customize the Remote Access VPN Monitoring View

You can modify the remote access VPN monitoring view in both live and historical modes to only include column headers that apply to the view you want. Click the column filter icon located to the right of the columns and select or deselect the columns you want.

Security Cloud Control remembers your selection the next time you sign in to Security Cloud Control.

Export Remote Access VPN Sessions to a CSV File

You can export the remote access VPN sessions of one or more devices to a comma-separated value (.csv) file. You can open the .csv file in a spreadsheet application such as Microsoft Excel to sort and filter the items on your list. This information helps you to analyze the remote access VPN sessions. Every time you export the sessions, Security Cloud Control creates a new .csv file, where the file created has a date and time in its name.

Security Cloud Control can export a maximum of 100,000 active sessions to the CSV file. If the total number of sessions from all devices exceeds the maximum limit, you can use the View By Device filter and generate reports for individual devices.

Procedure

Step 1	In the left pane, click Monitor > Insights & Reports > Reports & Analytics > Remote Access Monitoring.
Step 2	In the View By Devices area, select one of the following: All Devices to export active sessions from all devices listed below it. Click on a device that you want to export sessions of that device.
Step 3	Click the icon on the top right corner. Security Cloud Control exports the rules you see on the screen to a .csv file.
Step 4	Open the .csv file in a spreadsheet application to sort and filter the results.

Remote Access VPN Dashboard

Security Cloud Control provides a consolidated information about remote access VPN connections from ASA, Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense, and FDM-managed devices.

In the left pane, click Secure Connections > Remote Access VPN.

VPN Tunnel Status: Displays a pie chart representing the active and idle VPN tunnels, each in appropriate colors. This chart shows the top ten number of remote access VPN sessions by headends.
Statistics: Shows the average session duration and data uploaded and downloaded.

Disconnect Remote Access VPN Sessions on FDM-Managed Device

Currently, it is not possible to terminate remote access VPN sessions on an FDM-managed device using the Security Cloud Control interface. Instead, you can connect to the Firewall Threat Defense CLI using SSH and disconnect the desired user. You can perform this task on an online FDM-managed device onboarded to Security Cloud Control.

Procedure

Step 1	Log on to Firewall Device Manager and use the device CLI as explained in the Logging Into the Command Line Interface (CLI) section of the "Getting Started" chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.
Step 2	Execute the `vpn-sessionsdb logoff {name}` command and replace name with the user name. This command terminates all sessions for the username that you specify.

Managing FDM Devices with Security Cloud Control

Bias-Free Language

Results

Chapter: Managing Virtual Private Network in Security Cloud Control

Managing Virtual Private Network in Security Cloud Control

Introduction to Site-to-Site Virtual Private Network

Simplifying Site-to-Site VPNs with Security Cloud Control

Site-to-Site VPN Concepts

VPN Topology

IPsec and IKE Protocols

Authentication VPN Tunnels

Virtual Tunnel Interface (VTI)

VPN Encryption Domain

About Extranet Devices

About Global IKE Policies

Managing IKEv1 Policies

About IKEv1 Policy

Create an IKEv1 Policy

Procedure

Managing IKEv2 Policies

About IKEv2 Policy

Create an IKEv2 Policy

Procedure

About IPsec Proposals

Managing an IKEv1 IPsec Proposal Object

Create an IKEv1 IPsec Proposal Object

Procedure

Managing an IKEv2 IPsec Proposal Object

Create or Edit an IKEv2 IPsec Proposal Object

Procedure

Encryption and Hash Algorithms Used in VPN

Deciding Which Encryption Algorithm to Use

Deciding Which Hash Algorithms to Use

Deciding Which Diffie-Hellman Modulus Group to Use

Deciding Which Authentication Method to Use

Preshared Keys

Site-to-Site VPN Configuration for FDM-Managed

Configure Site-to-Site VPN Connections with Dynamically Addressed Peers

FDM-Managed Device Site-to-Site VPN Guidelines and Limitations

Create a Site-To-Site VPN Tunnel Between FDM-managed Devices

Procedure

Configure Networking for Protected Traffic Between the Site-To-Site Peers

Procedure

Edit an Existing Security Cloud Control Site-To-Site VPN

Procedure

Delete a Security Cloud Control Site-To-Site VPN Tunnel

Procedure

Exempt Site-to-Site VPN Traffic from NAT

Procedure

Configure Static and Default Routes for FDM-Managed Devices

Site-to-Site VPN Configuration for Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense

Create a Site-to-Site VPN Tunnel Between Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense Devices

Before you begin

Procedure

Create a Site-to-Site VPN Tunnel Between Cloud-delivered Firewall Management Center-Managed Firewall Threat Defense and Multicloud Defense

Before you begin

Procedure

Create a Site-to-Site VPN Between Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense and Secure Firewall ASA

Before you begin

Procedure

Site-to-Site VPN Configuration for Secure Firewall ASA

Configure Site-to-Site VPN Connections with Dynamically Addressed Peers

Secure Firewall ASA Site-to-Site VPN Guidelines and Limitations

Guidelines for Virtual Tunnel Interfaces

Create a Site-to-Site VPN Tunnel Between Secure Firewall ASA

Procedure

Create a Site-to-Site VPN Between ASA and Multicloud Defense Gateway

Before you begin

Procedure

Exempt Site-to-Site VPN Traffic from NAT

Procedure

Monitor Site-to-Site Virtual Private Networks

Check Site-to-Site VPN Tunnel Connectivity

Procedure

Site-To-Site VPN Dashboard

Identify VPN Issues

Find VPN Tunnels with Missing Peers

Procedure

Find VPN Peers with Encryption Key Issues

Procedure