Cisco Security Cloud Control: Firewall Management for Government

Configure Virtual Private Network Management

A virtual private network (VPN) connection establishes a secure tunnel between endpoints over a public network such as the Internet.

This section applies to Remote Access and Site-to-site VPNs on Adaptive Security Appliances (ASA) FDM-managed device. It describes the Internet Protocol Security (IPsec) standards to build site-to-site VPNs connection on FTD. It also describes the SSL standards that are used to build and remote access VPN connections on ASAFTD.

For additional information about Virtual Private Networks, refer to the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager.

Security Cloud Control supports the following types of VPN connections:

Introduction to Site-to-Site Virtual Private Network

A site-to-site VPN tunnel connects networks in different geographic locations. You can create site-to-site IPsec connections between managed devices and between managed devices and other Cisco or third-party peers that comply with all relevant standards. These peers can have any mix of inside and outside IPv4 and IPv6 addresses. Site-to-site tunnels are built using the Internet Protocol Security (IPsec) protocol suite and Internet Key Exchange version 2 (IKEv2). After the VPN connection is established, the hosts behind the local gateway can connect to the hosts behind the remote gateway through the secure VPN tunnel.

Simplifying Site-to-Site VPNs with Security Cloud Control Firewall Management

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 Firewall Management 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 ASAFTD.

IPsec and IKE Protocols

In Security Cloud Control, site-to-site VPNs are configured based on IKE policies and IPsec proposals that are assigned to VPN topologies. Policies and proposals are sets of parameters that define the characteristics of a site-to-site VPN, such as the security protocols and algorithms that are used to secure traffic in an IPsec tunnel. Several policy types may be required to define a full configuration image that can be assigned to a VPN topology.

Authentication VPN Tunnels

For authentication of VPN connections, configure a pre-shared key in the topology on each device. Pre-shared keys allow a secret key, used during the IKE authentication phase, to be shared between two peers.

Virtual Tunnel Interface (VTI)

Security Cloud Control does not currently support the management, monitoring, or use of Virtual Tunnel Interface (VTI) tunnels on FTD. Devices with configured VTI tunnels can be onboarded to Security Cloud Control but it ignores the VTI interfaces. If a security zone or static route references a VTI, Security Cloud Control reads the security zone and static route without the VTI reference.

VPN Encryption Domain

There are two methods to define the VPN's encryption domain: route-based or policy-based traffic selectors.

Policy-Based: The encryption domain is set to allow any traffic which enters the IPSec tunnel. IPSec Local and remote traffic selectors are set to 0.0.0.0. This means that any traffic routed into the IPSec tunnel is encrypted regardless of the source/destination subnet. ASA supports policy-based VPN with crypto maps.
Route-Based: The encryption domain is set to encrypt only specific IP ranges for both source and destination. It creates a virtual IPsec interface, and whatever traffic enters that interface is encrypted and decrypted. ASA supports route-based VPN with the use of Virtual Tunnel Interfaces (VTIs).

About Extranet Devices

You can add non-Cisco or unmanaged Cisco devices to a VPN topology as "Extranet" devices with either static or dynamic IP addresses.

Non-Cisco Device: You cannot use Security Cloud Control to create and deploy configurations to non-Cisco devices.
Unmanaged Cisco Device: Cisco device not managed by your organization, such as spokes in networks managed by other organizations within your company, or a connection to a service provider or partner's network.

Global IKE policies

Internet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).

The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for other applications, such as IPsec. Both phases use proposals when they negotiate a connection. An IKE proposal is a set of algorithms that two peers use to secure the negotiation between them. IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters are used to protect subsequent IKE negotiations.

IKE policy objects define the IKE proposals for these negotiations. The objects that you enable are the ones used when the peers negotiate a VPN connection: you cannot specify different IKE policies per connection. The relative priority of each object determines which of these policies are tried first, with the lower number being a higher priority. The connection is not established if the negotiation fails to find a policy that both peers can support.

To define the global IKE policy, you select which objects to enable for each IKE version. If the pre-defined objects do not satisfy your requirements, create new policies to enforce your security policy.

Managing IKEv1 Policies

About IKEv1 Policy

Internet Key Exchange (IKE) version 1 policy objects contain the parameters required for IKEv1 policies when defining VPN connections. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).

There are several pre-defined IKEv1 policies. If any suit your needs, simply enable them by clicking the State toggle. You can also create new policies to implement other combinations of security settings. You cannot edit or delete system-defined objects.

Create an IKEv1 Policy

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	In the left pane, click Objects.
Step 3	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 4	Enter an object name, up to 128 characters.
Step 5	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 6	Click Add.

Managing IKEv2 Policies

About IKEv2 Policy

Internet Key Exchange (IKE) version 2 policy objects contain the parameters required for IKEv2 policies when defining VPN connections. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).

There are several pre-defined IKEv2 policies. If any suit your needs, simply enable them by clicking the State toggle. You can also create new policies to implement other combinations of security settings. You cannot edit or delete system-defined objects.

Create an IKEv2 Policy

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	In the left pane, click Objects.
Step 3	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 4	Enter an object name, up to 128 characters.
Step 5	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 6	Click Add.

IPsec proposal and IKE policy objects

IPsec is one of the most secure methods for setting up a VPN. IPsec provides data encryption at the IP packet level, offering a robust security solution that is standards-based. With IPsec, data is transmitted over a public network through tunnels. A tunnel is a secure, logical communication path between two peers. Traffic that enters an IPsec tunnel is secured by a combination of security protocols and algorithms called a transform set. During the IPsec security association (SA) negotiation, peers search for a transform set that is the same at both peers.

There are separate IPsec proposal objects based on the IKE version, IKEv1, or IKEv2:

When you create an IKEv1 IPsec proposal, you select the mode in which IPsec operates, and define the required encryption and authentication types. You can select single options for the algorithms. If you want to support multiple combinations in a VPN, create and select multiple IKEv1 IPsec Proposal objects.
When you create an IKEv2 IPsec proposal, you can select all of the encryption and hash algorithms allowed in a VPN. The system orders the settings from the most secure to the least secure and negotiates with the peer until a match is found. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.

The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec proposals. It provides authentication, encryption, and antireplay services. ESP is IP protocol type 50.

Note

We recommend using both encryption and authentication on IPsec tunnels.

Managing an IKEv1 IPsec Proposal Object

IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel. There are separate objects for IKEv1 and IKEv2. Currently, Security Cloud Control supports IKEv1 IPsec proposal objects.

The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec proposals. It provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50.

Note

We recommend using both encryption and authentication on IPsec tunnels.

Create an IKEv1 IPsec Proposal Object

IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel. There are separate objects for IKEv1 and IKEv2. Currently,Security Cloud Control supports IKEv1 IPsec proposal objects.

The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec proposals. It provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50.

Note

We recommend using both encryption and authentication on IPsec tunnels.

There are several pre-defined IKEv1 IPsec proposals. You can also create new proposals to implement other combinations of security settings. You cannot edit or delete system-defined objects.

The following procedure explains how you can create and edit objects directly through the Objects page. You can also create IKEv1 IPsec Proposals objects while editing the IKEv1 IPsec settings in a Site-to-Site VPN connection by clicking the Create New IKEv1 Proposal link shown in the object list.

Procedure

Step 1	In the left pane, click 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 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 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 IPsec proposal and IKE policy objects.

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.

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 navigation pane, choose VPN > Site-to-Site VPN.

Step 2

In the left pane, choose Secure Connections > Network Connections > Site to Site VPN.

Step 3

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

Step 4

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 5

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 6

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 7

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 Firewall Management Site-To-Site VPN Tunnel

Procedure

Step 1	In the left pane, click 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. In the left pane, click Objects. Click the blue plus button to create an object. Click FTD > Network. Click ASA > 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 Inventory. 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	Deploy configuration changes to Security Cloud Control. For more information, see Deploy configuration changes made using the Security Cloud Control GUI.
Step 6	If you are also managing Firewall2 (San Jose), you can configure similar rules for that device. 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 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 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 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 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 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 Secure Connections > Network Connections > Site to Site VPN.
Step 2	In the left pane, choose VPN > Site-to-Site VPN.
Step 3	Click the Create Tunnel () icon and then click Site-to-Site VPN.
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 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 5	Click Next.
Step 6	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 7	Click Next.
Step 8	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 9	Click Next.
Step 10	In the IKE Settings area, Security Cloud Control generates a default Local Pre-Shared Key. This is a secret key string that is configured on the peers. IKE uses this key during the authentication phase. It is used to verify each other when establishing a tunnel between the peers.
Step 11	In the Finish area, review the configuration and continue further only if you’re satisfied with the configuration. By default, the Deploy changes to ASA immediately check box is checked to deploy the configurations immediately to the ASA device after clicking Submit. If you want to review and deploy the configurations manually later, then uncheck this check box.
Step 12	Click Submit. The configurations are pushed to the Multicloud Defense Gateway.

The VPN page in Security Cloud Control shows the site-to-site tunnel created between the peers. You will be able to see the corresponding tunnel in the Multicloud Defense Gateway portal.

Exempt Site-to-Site VPN Traffic from NAT

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. In the left pane, click Objects. Click the blue plus button to create an object. Click FTD > Network. Click ASA > 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 Inventory. 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	Deploy configuration changes to Security Cloud Control. For more information, see Deploy configuration changes made using the Security Cloud Control GUI.
Step 6	If you are also managing Firewall2 (San Jose), you can configure similar rules for that device. 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 ASA Site-to-Site Virtual Private Networks

Security Cloud Control allows you to monitor already existing site-to-site VPN configurations on onboarded ASA devices. It doesn't allow you to modify or delete the site-to-site configuration.

Security Cloud Control allows you to monitor, modify, and delete existing or newly created site-to-site VPN configurations on onboarded FDM-managed devices.

Check Site-to-Site VPN Tunnel Connectivity

Use the Check Connectivity button to trigger a real-time connectivity check against the tunnel to identify whether the tunnel is currently active or idle. Unless you click the on-demand connectivity check button, a check across all tunnels, available across all onboarded devices, occurs once an hour.

Note

Security Cloud Control runs this connectivity check command on the ASAFTD 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 ASAFTD. (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 VPN > ASA/FDM Site-to-Site VPNSecure 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 InventorySecurity 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 Filter icon. in combination with the search field to focus your search of VPN tunnels presented in the VPN tunnel diagram.

Procedure

Step 1	Choose Secure Connections > Network Connections > Site to Site VPN.
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: Indicates whether issues have been detected on either side of the tunnel. For example, a device may be missing an associated interface, peer IP address, access list, or may have IKEv1 proposal mismatches. (Detecting tunnel issues is not yet available for AWS VPC VPN tunnels.) Devices/Services: Filters by type of device. Status: Indicates tunnel status, which can be active or idle. Active: An open session exists in which network packets traverse the VPN tunnel, or a successful session was established that has not timed out yet. The "Active" status indicates that the tunnel is operational 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: Filters by devices that Security Cloud Control manages. Unmanaged: Filters by devices that Security Cloud Control does not manage. Device Types: Indicates whether either side of the tunnel is a live (connected) 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 VPN > ASA/FDM Site-to-Site VPNSecure 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 VPN > ASA/FDM Site-to-Site VPNSecure 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

Procedure

Step 1	In the left pane, click VPN > ASA/FDM Site-to-Site VPN.
Step 2	In the left pane, click Secure Connections > Network Connections > Site to Site VPN.
Step 3	Click the Global view button.
Step 4	Use Search and Filter Site-to-Site VPN Tunnels to find a specific tunnel, or zoom into the Global View graphic to find the VPN gateway and its peers that you are looking for.
Step 5	Select one of the peers represented in the Global View.
Step 6	Click View Details.
Step 7	Click the other end of the VPN tunnel and Security Cloud Control displays Tunnel Details, NAT Information, and Key Exchange information for that connection: 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 Firewall Management Site-To-Site VPN Tunnel

Procedure

Step 1	In the left pane, click 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.

Introduction to Remote Access Virtual Private Network

Configure Remote Access Virtual Private Network for ASA

The ASA creates a remote access virtual private network (VPN) by creating a secure connection across a TCP/IP network (such as the Internet) that users see as a private connection. It can create single-user-to-LAN connections and LAN-to-LAN connections.

The secure connection is called a tunnel, and the ASA uses tunneling protocols to negotiate security parameters, create and manage tunnels, encapsulate packets, transmit or receive them through the tunnel, and unencapsulate them. The ASA functions as a bidirectional tunnel endpoint: it can receive plain packets, encapsulate them, and send them to the other end of the tunnel where they are unencapsulated and sent to their final destination. It can also receive encapsulated packets, unencapsulate them, and send them to their final destination.

Security Cloud Control provides an intuitive user interface for configuring a new remote access Virtual Private Network. It also allows you to quickly and easily configure remote access VPN connection for multiple Adaptive Security Appliance (ASA) devices onboarded in Security Cloud Control.

Security Cloud Control allows you to configure the remote access VPN configuration on ASA devices from scratch. It also allows you to manage the remote access VPN settings that have already been configured using another ASA management tool, such as the Adaptive Security Defense Manager (ASDM) or Cisco Security Manager (CSM). When you onboard an ASA device that already has remote access VPN settings, Security Cloud Control automatically creates a "Default remote access VPN Configuration" and associates the ASA device with this configuration. This default configuration can contain all the connection profile objects that are defined on the device. If you want to understand the RAVPN attributes that are read into Security Cloud Control, see the Read RA VPN Configuration of an Onboarded ASA Device section. Otherwise, you can start performing steps described in the "End-to-End Remote Access VPN Configuration Process for ASA" section.

End-to-End Remote Access VPN Configuration Process for ASA

This section provides the end-to-end procedure for configuring remote access VPN on an ASA device onboarded to Security Cloud Control.

To enable remote access VPN for your clients, you need to configure several separate items. The following procedure provides the end-to-end process.

Procedure

Step 1

Configure the identity source used for authenticating remote users.

You can use the following sources to authenticate users attempting to connect to your network using remote access VPN. Additionally, you can use client certificates for authentication, either alone or in conjunction with an identity source.

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 ASA device only from the Adaptive Security Device Manager (ASDM). See the "Configure Local User Groups" section in the Objects for Access Control" chapter of the Cisco ASA Series Firewall ASDM Configuration Guide, X.Y.

Step 2

Create ASA Remote Access VPN Configuration.

Step 3

Configure ASA Remote Access VPN Connection Profile.

Step 4

(optional) Exempt Remote Access VPN Traffic from NAT.

Step 5

Review and deploy configuration changes to the devices.

Important

If you change the Remote Access VPN configuration by using a local manager like Adaptive Security Device Manager (ASDM), the Configuration Status of that device in Security Cloud Control shows "Conflict Detected". See Out-of-Band Changes on an ASA Device. You can Resolve Configuration Conflicts on this ASA.

Once the remote access VPN configuration is downloaded to the ASA devices, the users can connect to your network from a remote location using a computer or other supported iOS or Android device connected to the Internet. You can monitor live AnyConnect remote access VPN sessions from all onboarded ASA remote access VPN head-ends in your tenant.

Identity sources for ASA

Identity sources, such as Microsoft Active Directory (AD) realms and RADIUS Servers, are AAA servers and databases that define user accounts for the people in your organization. You can use this information in a variety of ways, such as providing the user identity associated with an IP address or authenticating remote access VPN connections or access to Security Cloud Control.

Click Objects, then click ()>Identity Source to create your sources. You would then use these objects when you configure the services that require an identity source. You can apply appropriate filters to search existing sources and manage them.

Determining the directory base DN

When you configure directory properties, you need to specify the common base distinguished name (DN) for users and groups. The base is defined in your directory server and differs from network to network. You must enter the correct bases for identity policies to work. If the base is wrong, the system cannot determine user or group names, and thus identity-based policies will be inoperable.

Note

To get the correct bases, consult the administrator who is responsible for the directory servers.

For an active directory, you can determine the correct bases by logging into the Active Directory server as a domain administrator, and using the dsquery command at a command prompt as follows to determine the bases:

User search base

Enter the dsquery user command with known username (partial or complete) to determine the base distinguished name. For example, the following command uses the partial name "John*" to return information for all users that start with "John."

C:\Users\Administrator>dsquery user -name "John*"

"CN=John Doe,CN=Users,DC=csc-lab,DC=example,DC=com"

The base DN would be "DC=csc-lab,DC=example,DC=com."

Group search base

Enter the dsquery group command with a known group name to determine the base distinguished name. For example, the following command uses the group name Employees to return the distinguished name:

C:\>dsquery group -name "Employees"

"CN=Employees,CN=Users,DC=csc-lab,DC=example,DC=com"

The group base DN would be "DC=csc-lab,DC=example,DC=com."

You can also use the ADSI Edit program to browse the Active Directory structure (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. See Create or Edit an ASA Active Directory Realm Object for more information.

RADIUS servers and groups

You can use RADIUS servers to authenticate and authorize administration users. When you configure a feature to use RADIUS servers, you select a RADIUS group instead of individual servers. A RADIUS group is a collection of RADIUS servers that are copies of each other. If a group has more than one server, they form a chain of backup servers to provide redundancy in case one server becomes unavailable. But even if you have only one server, you must create a one-member group to configure RADIUS support for a feature.

You can use this source for the following purposes:

Remote Access VPN, as an identity source for authentication, and for authorization and accounting. You can use AD in conjunction with a RADIUS server.
Identity policy, as a passive identity source to collect user identity from remote access VPN logins.

See Create and Edit an Adaptive Security Appliance RADIUS Server Object or Group for more information.

Create an ASA Active Directory realm object

When you create or edit an identity source object such as an AD realm object, Security Cloud Control Firewall Management sends the configuration request to the ASA devices through the SDC. The ASA then communicates with the configured AD realm.

Use the following procedure to create an object:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click Create Object ()RA VPN Objects (ASA & FDM) > Identity Source.

Step 3

Enter an Object Name for the object.

Step 4

Select the Device Type as ASA.

Step 5

In the first part of the wizard, select Active Directory Realm as the Identity Source Type. Click Continue.

Step 6

Configure the basic realm properties.

Directory Username, Directory Password - The distinguished username and password for a user with appropriate rights to the user information you want to retrieve. For Active Directory, 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.

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 LDAPS to use SSL to secure communications between the ASA and the LDAP server. It requires LDAP over SSL. Use port 636.

The default is None, which means that user and group information is downloaded in clear text.

Step 8

(Optional) Use the Test button to validate the configuration.

Step 9

(Optional) Click Add another configuration to add multiple Active Directory (AD) servers to the AD realm. The AD servers need to be duplicates of each other and support the same AD domain. Therefore, the basic realm properties such as Directory name, Directory Password, and Base Distinguished Name must be the same across all AD servers associated with that AD realm.

Step 10

Click Add.

Edit an ASA Active Directory realm object

Note that you cannot change the Identity Source Type when editing an Identity source object. You must create a new object with the correct type.

Procedure

Step 1	In the left pane, click 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 an ASA RADIUS server object or group

When you create or edit an identity source object such as a RADIUS server object or a group of RADIUS server objects, Security Cloud Control sends the configuration request to ASA devices through the SDC.

Create an ASA RADIUS server object

RADIUS servers provide AAA (authentication, authorization, and accounting) services.

Use the following procedure to create an object:

Procedure

Step 1	From the Security Cloud Control Home page, click Firewall.
Step 2	In the left pane, click Objects.
Step 3	Click Create Object ()> RA VPN Objects (ASA & FDM) > Identity Source.
Step 4	Enter an Object name for the object.
Step 5	Select the Device Type as ASA.
Step 6	Select RADIUS Server as the Identity Source Type. Click Continue.
Step 7	Edit the Identity Source configuration with the following properties: 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 ASA 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 8	Click Add.
Step 9	Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Create an ASA RADIUS server group

A RADIUS server group contains one or more RADIUS server objects. Servers in the group must be copies of each other and form a backup chain.

Use the following procedure to create an object group:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click Create Object () RA VPN Objects (ASA & FDM) Identity Source.

Step 3

Enter an Object name for the object.

Step 4

Select the Device Type as ASA.

Step 5

Select RADIUS Server Group as the Identity Source Type. Click Continue.

Step 6

Edit the Identity Source configuration with the following properties:

Dead Time : Time to wait after the last server fails before reactivating all servers. Failed servers are reactivated only after all servers have failed.
Maximum Failed Attempts : Number of failed requests sent to a RADIUS server before the system tries the next server. When this number is exceeded, the system marks the server as failed.
Dynamic Authorization/Port Optional change of authorization (CoA) services. Enable only when this server group is used in RA VPN with Cisco 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 RADIUS SERVER Add button to add existing RADIUS server objects. Optionally, you can create a new RADIUS server object from this window is necessary.

Note

Add RADIUS server objects in priority order. The first server is used until it becomes unresponsive, and ASA then uses 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 an ASA Radius server object or group

Use the following procedure to edit a Radius server object or Radius server group:

Procedure

Step 1	In the left pane, click 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 ASA 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 remote access VPN configuration. Resolve all inconsistencies before adding the group policy to the remote access VPN Configuration.

Procedure

Step 1	In the left pane, click Objects.
Step 2	Click > RA VPN Objects (ASA & FDM) > 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 ASA.
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.

ASA RA VPN group policy attributes

The section describes the attributes associated with the ASA remote access VPN group policy.

General Attributes

The general attributes of a group policy define the name of the group and some other basic settings.

DNS Server: Enter the IP address(s) of DNS servers for domain name resolution when connected to the VPN. You can separate the addresses using a comma.
Banner: The banner text, or welcome message, to present to users at login. The default is no banner. The length can be up to 496 characters. The AnyConnect client supports partial HTML. To ensure that the banner displays properly to remote users, use the <BR> tag to indicate line breaks.
Default Domain: The default domain name for users in the remote access VPN. For example, example.com. This domain is added to hostnames that are not fully-qualified, for example, serverA instead of serverA.example.com.

AnyConnect Client Profiles

This feature is supported on FTD running software version 6.7 or later versions.

Cisco AnyConnect VPN client offers enhanced security through various built-in modules. These modules provide services such as web security, network visibility into endpoint flows, and off-network roaming protection. Each client module includes a client profile that includes a group of custom configurations as per your requirement.

You can select the AnyConnect VPN profile object and AnyConnect modules to be downloaded to clients when the VPN user downloads the VPN AnyConnect client software.

Choose or create an AnyConnect VPN profile object. See Upload RA VPN AnyConnect Client Profile. Except for DART and Start Before Login modules, the AnyConnect VPN profile object must be selected.
Click Add Any Connect Client Module.

The following AnyConnect modules are optional and you can configure these modules to be downloaded with VPN AnyConnect client software:
- AMP Enabler — Deploys advanced malware protection (AMP) for endpoints.
- DART — Captures a snapshot of system logs and other diagnostic information and creates a .zip file on your desktop so you can conveniently send troubleshooting information to Cisco TAC.
- Feedback — Provides information about the features and modules customers have enabled and used.
- ISE Posture — Uses the OPSWAT library to perform posture checks to assess an endpoint's compliance.
- Network Access Manager — Provides 802.1X (Layer 2) and device authentication to access both wired and wireless networks.
- Network Visibility — Enhances the enterprise administrator's ability to do capacity and service planning, auditing, compliance, and security analytics.
- Start Before Login — Forces the user to connect to the enterprise infrastructure over a VPN connection before logging on to Windows by starting AnyConnect before the Windows login dialog box appears.
- Umbrella Roaming Security — Provides DNS-layer security when no VPN is active.
- Web Security — Analyzes the elements of a web page, allows acceptable content, and blocks malicious or unacceptable content based on a defined security policy.
In the Client Module list, select an AnyConnect module.
In the Profile list, choose or create a profile object containing an AnyConnect Client Profile.
Select Enable Module Download to enable endpoints to download the client module along with the profile. If not selected, the endpoints can download only the client profile.

Session Setting Attributes

The session settings of a group policy control how long users can connect through the VPN and how many separate connections they can establish.

Maximum Connection Time: The maximum length of time, in minutes, that users can stay connected to the VPN without logging out and reconnecting, from 1- 4473924 or blank. The default is unlimited (blank), but the idle timeout still applies.
Connection Time Alert Interval: If you specify a maximum connection time, the alert interval defines the amount of time before the maximum time is reached to display a warning to the user about the upcoming automatic disconnect. The user can choose to end the connection and reconnect to restart the timer. The default is 1 minute. You can specify 1 to 30 minutes.
Idle Time: The length of time, in minutes, that the VPN connection can be idle before it is automatically closed, from 1-35791394. If there is no communication activity on the connection for this consecutive number of minutes, the system stops the connection. The default is 30 minutes.
Idle Time Alert Interval: The amount of time before the idle time is reached to display a warning to the user about the upcoming automatic disconnect due to an idle session. Any activity resets the timer. The default is 1 minute. You can specify 1 to 30 minutes.
Simultaneous Login Per User: The maximum number of simultaneous connections allowed for a user. The default is 3. You can specify 1 to 2147483647 connections. Allowing many simultaneous connections might compromise security and affect performance.

Address Assignment Attributes

The address assignment attributes of a group policy define the IP address pool for the group. The pool defined here overrides the pool defined in any connection profile that uses this group. Leave these settings blank if you want to use the pool defined in the connection profile.

IPv4 Address Pool, IPv6 Address Pool: These options define the address pools for the remote endpoints. Clients are assigned an address from these pools based on the IP version they use to make the VPN connection. Select the IP address pool that defines a subnet for each IP type you want to support. Leave the list empty if you do not want to support that IP version. For example, you could define an IPv4 pool as 10.100.10.0/24. The address pool cannot be on the same subnet as the IP address for the outside interface.
DHCP Scope: If you configure DHCP servers for the address pool in the connection profile, the DHCP scope identifies the subnets to use for the pool for this group. The DHCP server must also have addresses in the same pool identified by the scope. The scope allows you to select a subset of the address pools defined in the DHCP server to use for this specific group. If you do not define a network scope, the DHCP server assigns IP addresses in the order of the address pools configured. It goes through the pools until it identifies an unassigned address. To specify a scope, enter the network object that contains the network number host address. For example, to tell the DHCP server to use addresses from the 192.168.5.0/24 subnet pool, enter a network object that specifies 192.168.5.0 as a host address. You can use DHCP for IPv4 addressing only.

Split Tunneling Attributes

The split tunneling attributes of a group policy define how the system should handle traffic meant for the internal network vs. externally-directed traffic. Split tunneling directs some network traffic through the VPN tunnel (encrypted) and the remaining network traffic outside the VPN tunnel (unencrypted or in clear text).

Typically, in remote access VPN, you might want the VPN users to access the Internet through your device. However, you can allow your VPN users to access an outside network while they are connected to an remote access VPN. This technique is called split tunneling or hair pinning. The split tunnel allows VPN connectivity to a remote network across a secure tunnel, and it also allows connectivity to a network outside the VPN tunnel. Split tunneling reduces the network load on the FTD devices and increases the bandwidth on the outside interface.

Before you begin

For creating a split tunnel policy for IPv4 networks and another for IPv6 networks, the access-list you specify is used for both protocols. So, the access-list should contain access control entries (ACEs) for both IPv4 and IPv6 traffic.

When an ASA device is onboarded to Security Cloud Control, it reads the extended ACLs associated with the device. See Split Tunnel Configuration for more information.

Note

Ensure that you specify the network intended for split tunneling as the source network in the ACL you are creating.

IPv4 Split Tunneling, IPv6 Split Tunneling: You can specify different options based on whether the traffic uses IPv4 or IPv6 addresses, but the options for each are the same. If you want to enable split tunneling, specify one of the options that require you to select network objects.
- Allow all traffic over tunnel: Do no split tunneling. Once the user makes an remote access VPN connection, all the user's traffic goes through the protected tunnel. This is the default. It is also considered the most secure option.
- Allow specified traffic over the tunnel: Select the extended access list that defines the source network. Any traffic from these sources goes through the protected tunnel. The client routes traffic from any other source to connections outside the tunnel (such as a local Wi-Fi or network connection).
- Exclude networks specified below: Select the network objects that define the source network. The client routes any traffic from these sources to connections outside the tunnel. Traffic from any other source goes through the tunnel.
- Network List: Select the extended ACL network that can have both IPv4 and IPv6 networks.
Split DNS: You can configure the system to send some DNS requests through the secure connection while allowing the client to send other DNS requests to the DNS servers configured on the client. You can configure the following DNS behavior:
- Send DNS Request as per split tunnel policy: With this option, DNS requests are handled the same way as the split tunnel options are defined. If you enable split tunneling, DNS requests are sent based on the destination addresses. If you do not enable split tunneling, all DNS requests go over the protected connection.
- Always send DNS requests over tunnel: Select this option if you enable split tunneling, but you want all DNS requests sent through the protected connection to the DNS servers defined for the group.
- Send only specified domains over tunnel: Select this option if you want your protected DNS servers to resolve addresses for certain domains only. Then, specify those domains, separating domain names with commas. For example, example.com, example1.com. Use this option if you want your internal DNS servers to resolve names for internal domains, while external DNS servers handle all other Internet traffic.

AnyConnect Attributes

The AnyConnect attributes of a group policy define some SSL and connection settings used by the AnyConnect client for a remote access VPN connection.

SSL Settings
- Enable Datagram Transport Layer Security (DTLS): Whether to allow the AnyConnect client to use two simultaneous tunnels: an SSL tunnel and a DTLS tunnel. Using DTLS avoids latency and bandwidth problems associated with some SSL connections and improves the performance of real-time applications that are sensitive to packet delays. If you do not enable DTLS, AnyConnect client users establishing SSL VPN connections connect with an SSL tunnel only.
- DTLS Compression: Whether to compress Datagram Transport Layer Security (DTLS) connections for this group using LZS. DTLS Compression is disabled by default.
- SSL Compression: Whether to enable data compression, and if so, the method of data compression to use, Deflate, or LZS. SSL Compression is Disabled by default. Data compression speeds up transmission rates but also increases the memory requirement and CPU usage for each user session. Therefore, SSL compression decreases the overall throughput of the device.
- SSL Rekey Method, SSL Rekey Interval: The client can rekey the VPN connection, renegotiating the crypto keys and initialization vectors, to increase the security of the connection. Disable rekeying by selecting None. To enable rekey, select New Tunnel to create a new tunnel each time. (The Existing Tunnel option results in the same action as New Tunnel.) If you enable rekeying, also set the rekey interval, which is 4 minutes by default. You can set the interval to 4-10080 minutes (1 week).
Connection Settings
- Ignore the DF (Don't Fragment) bit: Whether to ignore the Don't Fragment (DF) bit in packets that need fragmentation. Select this option to allow the forced fragmentation of packets that have the DF bit set, so that these packets can pass through the tunnel.
- Client Bypass Protocol: Allows you to configure how the secure gateway manages IPv4 traffic (when it is expecting only IPv6 traffic), or how it manages IPv6 traffic (when it is expecting only IPv4 traffic).
  
  When the AnyConnect client makes a VPN connection to the headend, the headend assigns it an IPv4, IPv6, or both an IPv4 and IPv6 address. If the headend assigns the AnyConnect connection only an IPv4 address or only an IPv6 address, you can configure the Client Bypass Protocol to drop network traffic for which the headend did not assign an IP address (default, disabled, not checked), or allow that traffic to bypass the headend and be sent from the client unencrypted or "in the clear" (enabled, checked).
  
  For example, assume that the secure gateway assigns only an IPv4 address to an AnyConnect connection and the endpoint is dual-stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass Protocol is disabled, the IPv6 traffic is dropped; however, if Client Bypass Protocol is enabled, the IPv6 traffic is sent from the client in the clear.
- MTU: The maximum transmission unit (MTU) size for SSL VPN connections established by the Cisco AnyConnect VPN Client. The default is 1406 bytes. The range is 576 to 1462 bytes.
  - Keepalive Messages Between AnyConnect and VPN Gateway: Whether to exchange keepalive messages between peers to demonstrate that they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals. The default interval is 20 seconds, and the valid range is 15 to 600 seconds.
  - DPD on Gateway Side Interval, DPD on Client Side Interval: Enable Dead Peer Detection (DPD) to ensure that the VPN gateway or VPN client quickly detects when the peer is no longer responding. You can separately enable gateway or client DPD. The default interval is 30 seconds for sending DPD messages. The interval can be 5-3600 seconds.

Traffic Filters Attributes

The traffic filter attributes of a group policy define restrictions you want to place on users assigned to the group. You can use these attributes instead of creating access control policy rules to restrict remote access VPN users to specific resources, based on host or subnet address and protocol, or VLAN. By default, remote access VPN users are not restricted by the group policy from accessing any destination on your protected network.

Access List Filter: Restrict access using an extended access control list (ACL). Select the Smart CLI Extended ACL object. The extended ACL lets you filter based on source address, a destination address, and protocol (such as IP or TCP). ACLs are evaluated on a top-down, first-match basis, so ensure that you place specific rules before more general rules. There is an implicit "deny any" at the end of the ACL, so if you intend to deny access to a few subnets while allowing all other access, ensure that you include a "permit any" rule at the end of the ACL. Because you cannot create network objects while editing an extended ACL Smart CLI object, you should create the ACL before editing the group policy. Otherwise, you might need to simply create the object, then go back later to create the network objects and then all the access control entries that you need. To create the ACL, log in to FDM, go to 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 ASA Remote Access VPN Configuration

Security Cloud Control allows you to add one or more Adaptive Security Appliance (ASA) devices to the remote access VPN configuration wizard and configure the VPN interfaces, access control, and NAT exemption settings associated with the devices. Therefore, each remote access VPN configuration can have connection profiles and group policies shared across multiple ASA devices that are associated with the remote access VPN configuration. Further, you can enhance the configuration by creating connection profiles and group policies.

You can either onboard an ASA device that has already been configured with remote access VPN settings or a new device without remote access VPN settings. See Onboard ASA device to Security Cloud Control Firewall Management. When you onboard an ASA device that already has remote access VPN settings, Security Cloud Control automatically creates a "Default remote access VPN Configuration" and associates the ASA device with this configuration. Also, this default configuration can contain all the connection profile objects that are defined on the device. See Read RA VPN Configuration of an Onboarded ASA Device for more information. Security Cloud Control allows you to delete the default configuration.

Important

You are not allowed to add ASA and FTD in the same Remote Access VPN Configuration.
An ASA device cannot have more than one remote access VPN Configuration.

Before you begin

Before adding the ASA device to the remote access VPN configuration, the following prerequisites must be met on the ASA device:

License requirements.

Device must be enabled for export-controlled functionality.

To view the license summary of your ASA device, execute the show license summary command in the ASA command-line interface.

To use the Security Cloud Control ASA CLI interface, see Use the command line interface.
- Example of export-controlled functionality enabled in the license summary :
Registration: Status: REGISTERED Smart Account: Cisco SVS temp-request access licensing@cisco.comExport-Controlled Functionality: ALLOWED

Last Renewal Attempt: None

Next Renewal Attempt: Jun 08 2021 09:46:22 UTC

The 'Export-Controlled Functionality' property must be in the 'Allowed' state for creating or editing the VPN configuration.

If this property is in the 'Not Allowed' state, Security Cloud Control displays an error message ('remote access VPN cannot be configured for devices which are not export compliant.') when you are creating or modifying the VPN configuration and doesn't allow remote access VPN configuration on the device.
Device Identity Certificates.

Certificates are required to authenticate connections between the clients and the ASA device. Before starting the VPN configuration, ensure that the identity certificate is already present on the ASA device.

To determine whether or not the certificate is present on the device, execute the show crypto CA Certificates command in the ASA command-line interface.

To use the Security Cloud Control ASA CLI interface, see ASA command line interface.

If the identity certificate is not present or you want to enroll in a new certificate, install them on ASA using Security Cloud Control. See ASA Certificate Management.

The usage of digital certificates in remote access VPN context is explained in Remote Access VPN Certificate-Based Authentication.
Outside interfaces.

The outside interfaces must be configured already on the ASA device. You need to use either ASDM or ASA CLI to configure interfaces. To know configure interfaces using ASDM, see the "Interfaces" book of the Cisco ASA Series General Operations CLI Configuration Guide, X.Y.
Download the AnyConnect packages and upload them to a remote server. Later, use the remote access VPN wizard or ASA File Management wizard to upload the AnyConnect software packages from the server to ASAs. See Manage AnyConnect Software Packages on an ASA Device for instructions.
There are no configuration deployments pending.
If you are using the local database for authentication Add user accounts to the local database using ASDM or ASA CLI.

To add user accounts using ASDM, see the "Add a User Account to the Local Database" section in the "AAA Servers and the Local Database" book of the Cisco ASA Series VPN CLI Configuration Guide, X.Y.

To add user accounts using ASA CLI, execute username[username] password [password] privilege [priv_level] command.
ASA changes are synchronized to Security Cloud Control.
1. In the left pane, click Security Devices and search for one or more ASA devices to be synchronized.
2. Select one or more devices and then click Check for changes. Security Cloud Control communicates with one or more FTD devices to synchronize the changes.
Remote access VPN configuration group policy objects are consistent.
- Ensure that all inconsistent group policy objects are resolved as they cannot be added to the remote access VPN configuration. Either address the issue or remove inconsistent group policy objects from the Objects page. For more information see, Resolve Duplicate Object Issues and Resolve Inconsistent Object Issues.

Procedure

Step 1

Onboard ASA device to Security Cloud Control Firewall Management.

Step 2

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

Step 3

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

Step 4

Enter a name for the Remote Access VPN configuration.

Step 5

Click the blue plus button to add ASA 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 ASA device that you want to add and click Select. Important: You are not allowed to add ASA and FTD 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.

Outside Interface: Select 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.

Attention

You cannot create or modify remote access VPN configuration for devices that are not export compliant. You must license the ASA device with export-controlled functionality enabled and try again.

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: NAT exemption exempts addresses from translation and allows both translated and remote hosts to initiate connections with your protected hosts. Configure NAT Exempt to exempt traffic to and from the remote access VPN endpoints from NAT translation. See Exempt Remote Access VPN Traffic from NAT.

Click OK.

The AnyConnect Packages Detected shows the AnyConnect packages that are already available on the device.

There are two options to upload AnyConnect package to ASA from remote access VPN wizard:

(Option 1): Select a package from Security Cloud Control's repository. The ASA must have access to the internet.
(Option 2): Specify the ftp/http/https/scp/smb/tftp URL location where the AnyConnect package is preloaded.

See Upload new AnyConnect Software Packages for instructions.

Note

Note: If you want to replace an existing package, see Replace an Existing AnyConnect Package.

Step 6

Click OK.

The ASA VPN configuration is created.

Modify ASA Remote Access VPN Configuration

You can modify the name and the device details of an existing remote access VPN configuration.

Procedure

Step 1

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

Modify the name if required.
Click the blue plus button to add a new device

Click to perform the following on the ASA device.

Click Edit to modify the existing remote access VPN configuration.

Click Remove to remove the ASA device from the remote access VPN configuration. All connection profiles and remote access 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 ASA if that is the only device using the configuration. Alternatively, you can remove the remote access VPN configuration.

Step 2

Deploy Configuration Changes.

You can also search for remote access VPN configuration by typing the name of the configuration or device.

Configure ASA Remote Access VPN Connection Profile

A Remote Access VPN connection profile defines the characteristics that allow external users to create a VPN connection to the system using the AnyConnect client. Each profile defines the AAA servers and certificates used for authenticating users, the address pools for assigning users IP addresses, and the group policies that define various user-oriented attributes.

You can create multiple profiles within the remote access VPN configuration if you need to provide variable services to different user groups, or if you have various authentication sources. For example, if your organization merges with a different organization that uses different authentication servers, you can create a profile for the new group that uses those authentication servers.

A remote access VPN connection profile allows your users to connect to your inside networks when they are on external networks, such as their home network. Create separate profiles to accommodate different authentication methods.

Before you begin

Create ASA Remote Access VPN Configuration.

Procedure

Step 1

In the left pane, click 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.

Note

To know the group policies assigned to the device, in Actions, click Group Policies. Group Policies assigned to connection profiles are automatically added to the list and cannot be removed.

Step 2

Click the connection profile and under Actions in the sidebar at the right, click Add Connection Profile.

Step 3

Configure the basic connection attributes.

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 ASA 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 URLhttps://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 4

Configure the primary and optionally, secondary identity sources. These options determine how remote users authenticate to the device to enable the remote access VPN connection. The simplest approach is to use AAA only and then select an AD realm or use the LocalIdentitySource. You can use the following approaches for Authentication Type:

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 5

Configure the address pool for clients. The address pool defines the IP addresses that the system can assign to remote clients when they establish a VPN connection. For more information, see Configure Client Address Pool Assignment.

Step 6

Click Continue.

Step 7

Select the Group Policy to use for this profile from the list and click Select.

Step 8

Click Continue.

Step 9

Review the summary. First, verify that the summary is correct. You can see what end-users need to do to initially install the AnyConnect software and test that they can complete a VPN connection. Click to copy the instructions to the clipboard, and then distribute them to your users.

Step 10

Click Done.

Step 11

Perform step 5 of End-to-End Remote Access VPN Configuration Process for ASA.

Configure AAA for a Connection Profile

Authentication, Authorization, and Accounting (AAA) servers use username and password to determine if a user is allowed access to the remote access VPN. If you use RADIUS servers, you can distinguish authorization levels among authenticated users, to provide differential access to protected resources. You can also use RADIUS accounting services to keep track of usage.

When configuring AAA, you must configure a primary identity source. Secondary and fallback sources are optional. Use a secondary source if you want to implement dual authentication, for example, using RSA tokens or DUO.

Primary Identity Source Options

Primary Identity Source for User Authentication: Authentication provides a way to identify a user, typically by having the user enter a valid username and valid password before access is granted. The primary identity source used for authenticating remote users. End-users must be defined in this source or the optional fallback source to complete a VPN connection. Select one of the following:
- An Active Directory (AD) identity realm.
- A RADIUS server group.
- LocalIdentitySource (the local user database): You can define users directly on the device and not use an external server.
Fallback Local Identity Source: If the primary source is an external server, you can select the LocalIdentitySource as a fallback in case the primary server is unavailable. If you use the local database as a fallback source, ensure that you define the same local usernames/passwords as the ones defined in the external server.
Strip options: A realm is an administrative domain. Enabling the following options allows the authentication to be based on the username alone. You can enable any combination of these options. However, you must select both check boxes if your server cannot parse delimiters.
- Strip Identity Source Server from Username: Whether to remove the identity source name from the username before passing the username on to the AAA server. For example, if you select this option and the user enters domain\username as the username, the domain is stripped off from the username and sent to the AAA server for authentication. By default, this option is unchecked.
- Strip Group from Username: Whether to remove the group name from the username before passing the username on to the AAA server. This option applies to names given in the username@domain format; the option strips the domain and @ sign. By default, this option is unchecked.

Secondary Identity Source

Secondary Identity Source for User Authorization: The optional second identity source. If the user successfully authenticates with the primary source, the user is prompted to authenticate with the secondary source. You can select an AD realm, RADIUS server group, or the local identity source.
Advanced options: Click the Advanced link and configure the following options:
- Fallback Local Identity Source for Secondary: If the secondary source is an external server, you can select the LocalIdentitySource as a fallback in case the secondary server is unavailable. If you use the local database as a fallback source, ensure that you define the same local usernames/passwords as the ones defined in the secondary external server.
- Use Primary Username for Secondary Login: By default, when using a secondary identity source, the system will prompt for both username and password for the secondary source. If you select this option, the system prompts for the secondary password only and uses the same username for the secondary source that was authenticated against the primary identity source. Select this option if you configure the same usernames in both the primary and secondary identity sources.
  - Username for Session Server: After successful authentication, the username is shown in events and statistical dashboards, is used for determining matches for a user- or group-based SSL decryption and access control rules and is used for accounting. Because you are using two authentication sources, you need to tell the system whether to use the Primary or Secondary username as the user identity. By default, the primary name is used.
  - Password Type: How to obtain the password for the secondary server. The default is Prompt, which means the user is asked to enter the password. Select Primary Identity Source Password to automatically use the password entered when the user authenticated to the primary server. Select Common Password to use the same password for every user, then enter that password in the Common Password field.
- Authorization Server: The RADIUS server group that has been configured to authorize remote access, VPN users. After authentication is complete, authorization controls the services and commands available to each authenticated user. Authorization works by assembling a set of attributes that describe what the user is authorized to perform, their actual capabilities, and restrictions. Were you not to use authorization, authentication alone would provide the same access to all authenticated users.
  
  Note that if the system obtains authorization attributes from the RADIUS server that overlap those defined in the group policy, the RADIUS attributes override the group policy attributes.
- Accounting Server: (Optional.) The RADIUS server group to use to account for the remote access VPN session. Accounting tracks the services users are accessing as well as the number of network resources they are consuming. The ASA device reports user activity to the RADIUS server. Accounting information includes when sessions start and stop, usernames, the number of bytes that pass through the device for each session, the service used, and the duration of each session. You can then analyze the data for network management, client billing, or auditing. You can use accounting alone or together with authentication and authorization.

Configure Certificate Authentication for a Connection Profile

Note

This section is not applicable for Authentication Type as AAA Only.

You can use certificates installed on the client device to authenticate remote access VPN connections.

When using client certificates, you can still configure a secondary identity source, fallback source, and authorization and accounting servers. These are AAA options; for details, see Configure ASA Remote Access VPN Connection Profile.

The following are the certificate-specific attributes. You can configure these attributes separately for primary and secondary identity sources. Configuring a secondary source is optional.

Username from Certificate: Select one of the following:
- Map Specific Field: Use the certificate elements in the order of Primary Field and Secondary Field. The defaults are CN (Common Name) and OU (Organizational Unit). Select the options that work for your organization. The fields are combined to provide the username, and this is the name used in events, dashboards, and for matching purposes in SSL decryption and access control rules.
- Use entire DN (distinguished name) as username: The system automatically derives the username from the DN fields.
Advanced options (not applicable for Authentication Type as Client Certificate Only): Click the Advanced link and configure the following options:
- Prefill username from certificate on user login window: Whether to fill in the username field with the retrieved username when prompting the user to authenticate.
- Hide username in login window: If you select the Prefill option, you can hide the username, which means the user cannot edit the username in the password prompt.

Configure Client Address Pool Assignment

There must be a way for the system to provide an IP address to endpoints that connect to the remote access VPN. The AAA server can provide these addresses, a DHCP server, an IP address pool configured in the group policy, or an IP address pool configured in the connection profile. The system tries these resources in that order and stops when it obtains an available address, which it then assigns to the client. Thus, you can configure multiple options to create a failsafe in case of an unusual number of concurrent connections.

Use one or more of the following methods to configure the address pool for a connection profile.

IPv4 Address Pool and IPv4 Address Pool: First, create up to six network objects that specify subnets. You can configure separate pools for IPv4 and IPv6. Then, select these objects in the IPv4 Address Pool and IPv6 Address Pool options, either in the group policy or in the connection profile. You do not need to configure both IPv4 and IPv6, configure the addressing scheme you want to support. You also do not need to configure the pool in both the group policy and the connection profile. The group policy overrides the connection profile settings, so if you configure the pools in the group policy, leave the options empty in the connection profile. Note that the pools are used in the order in which you list them.
DHCP Servers: First, configure a DHCP server with one or more IPv4 address ranges for the remote access VPN (you cannot configure IPv6 pools using DHCP). Then, create a host network object with the IP address of the DHCP server. You can then select this object in the DHCP Servers attribute of the connection profile.

Manage AnyConnect Software Packages on ASA Devices

You can perform one of the following steps to upload an AnyConnect package using the remote access VPN wizard:

Upload the package from the Security Cloud Control repository.
Upload the package from the server using HTTP, HTTPS, TFTP, FTP, SMB, or SCP protocols.

Upload an AnyConnect Package from Security Cloud Control Repository

The remote access VPN Configuration wizard presents AnyConnect packages per operating system from the Security Cloud Control repository, which you can select and upload to device. Make sure that the device has access to the internet and proper DNS configuration.

Note

If the desired package is unavailable in the presented list or the device has no access to the internet, you can upload the package using the server where the AnyConnect packages are preloaded.

Procedure

Step 1	Click on the field that corresponds to an operating system and select an AnyConnect package.
Step 2	Click to upload the package. If the checksum doesn't match, the AnyConnect package upload fails. You can see the device's workflow tab for more details about the failure.

Upload an AnyConnect Package to ASA from Server

Download the AnyConnect client software packages to your computer and upload them to a remote server accessible from ASAs. Later, use the RA VPN wizard or ASA File Management wizard to upload the AnyConnect software packages from that server to ASAs. DNS must be configured correctly on the device for URLs that use a domain name.

The ASA RA VPN wizard supports uploading packages using HTTP, HTTPS, TFTP, FTP, SMB, or SCP protocols.

The syntax of supported protocols for uploading the file:


Protocol	Syntax	Example
HTTP	http://[[path/ ]filename]	http://www.geonames.org/data-sources.html
HTTPS	https://[[path/ ]filename]	https://docs.aws.amazon.com/amazov/tagging.html
TFTP	tftp://[[path/ ]filename]	tftp://10.10.16.6/ftd/components.html
FTP	ftp://[[user[:password]@]server[:port]/[path/ ]filename]	ftp://'dlpuser:rNrKYTX9g7z3RgJRmxWuGHbeu'@ftp.dlptest.com/image0-000.jpg
SMB	smb://[[path/ ]filename]	smb://10.10.32.145//sambashare/hello.txt
SCP	scp://[[user[:password]@]server[/path]/ filename]	scp://root:cisco123@10.10.16.6//root/events_send.py

Before you begin

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.

Important

If you choose to upload the package using the ASA File Management wizard, do not modify the package's name after downloading them.

Note

You can upload one AnyConnect package per Operating System (OS): Windows, Mac, and Linux. You cannot upload multiple versions for a given OS type.

Procedure

Step 1

Download the AnyConnect packages from https://software.cisco.com/download/home/283000185.

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 server. Ensure that there is a network route from the ASA device and the server.

The ASA RA VPN wizard supports uploading packages HTTP, HTTPS, TFTP, FTP, SMB, or SCP protocols.

Important

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 ASA device.
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, you can download the file by specifying the RA VPN wizard's URL.

Step 4

If the remote server IP address is NATed, you have to provide the NATed public IP address of the remote server location.

Upload new AnyConnect Packages to ASA

You can either use the remote access VPN wizard or ASA File Management wizard to upload the AnyConnect software packages to ASAs.

Use the following procedure to upload new AnyConnect packages to an ASA device from an HTTP or HTTPS server:

Procedure

Step 1	In the AnyConnect Package Detected, you can upload separate packages for Windows, Mac, and Linux endpoints.
Step 2	In the corresponding platform field, specify the server's paths where the AnyConnect packages compatible for Windows, Mac, and Linux are pre-uploaded. Examples of server paths: 'http://<ip_address>:port_number/<folder_name>/anyconnect-win-4.8.01090-webdeploy-k9.pkg', 'https://<ip_address>:port_number/<folder_name>/anyconnect-linux64-4.7.03052-webdeploy-k9.pkg'.
Step 3	Click 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 ASA devices to the remote access VPN configuration, you can upload the AnyConnect packages to them.
Step 4	Click OK. The AnyConnect packages are added to the remote access VPN configuration.
Step 5	Continue to Create an ASA RA VPN Configuration from step 5 onwards. To complete a VPN connection, your users must install the AnyConnect client software on their workstation. For more information, see How Users Can Install the AnyConnect Client Software on ASA.

Upload AnyConnect Packages using File Management Wizard

Use the File Management wizard to upload AnyConnect packages to a single or multiple ASA devices from an HTTP, HTTPS, TFTP, FTP, SMB, or SCP server. When you want to push AnyConnect packages to multiple ASA devices simultaneously, the bulk upload comes in handy.

For more information, see ASA File Management.

Important

If you choose to upload the package using the ASA File Management wizard, do not modify the package's name after downloading them.

Once the upload is complete, open the ASA RA VPN Configuration wizard and notice that the packages are auto-detected. If you upload multiple packages for an OS version, the wizard lists them in a drop-down allowing you to select one among them. Then, you can create the RA VPN configuration and deploy them to the devices.

Replace an AnyConnect Package

If the AnyConnect packages are already present on the devices, you can see them in the remote access VPN wizard. You can see all the available AnyConnect packages for an operating system in a drop-down list. You can select an existing package from the list and replace it with a new one but can't add a new package to the list.

Note

If you want to replace an existing package with a new one, ensure that the new AnyConnect package is uploaded already to a server on the network that the ASA can reach.

Procedure

Step 1	In the left pane, click Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Step 2	Select the remote access 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 remote access VPN configuration.
Step 6	Continue to Create ASA Remote Access VPN Configuration from step 6 onwards.

Delete an AnyConnect Package

Procedure

Step 1

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

Step 2

Select the remote access 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, go to Security Devices page and click Discard Changes to retain the existing AnyConnect package.

Step 5

Review and deploy configuration changes to the devices.

Manage and Deploy Pre-existing ASA Remote Access VPN Configuration

When you onboard an ASDM managed ASA device that already has remote access VPN settings, it discovers and displays the existing remote access VPN configurations. Security Cloud Control automatically creates a "Default remote access VPN Configuration" and associates the ASA device with this configuration. There are some remote access VPN configurations that aren't read or supported in the Security Cloud Control but can be configured in the Security Cloud Control command-line interface.

Note

This section doesn't cover every supported or unsupported configuration in Security Cloud Control. Instead, it only describes the most commonly used ones.

To see the remote access VPN configurations from an onboarded ASA, perform the following steps:

Procedure

Step 1

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

Step 2

Click the remote access VPN configuration corresponding to the onboarded ASA device. Security Cloud Control automatically creates a "Default_RA_VPN_Configuration" and associates the ASA device with this configuration. You can delete the default configuration. The ASA remote access VPN configurations that are read in Security Cloud Control are classified as follows:

Device settings
Connection profiles
Group policies

Device Settings

The RA VPN configurations associated with the onboarded ASA device appear in Default_RA_VPN_Configuration. You need to click on this configuration to see the name of the ASA device (in the Devices pane on the right) associated with that configuration. You can also see the AnyConnect packages present in the ASA devices by clicking the edit button.

Connection Profile

Security Cloud Control supports and reads the connection profiles defined in "AnyConnect Client VPN Access" of the ASA device. It does not support the "Clientless SSL VPN Access" configuration.

To see the connection profile attributes, perform the following:

Procedure

Step 1	Expand Default_RA_VPN_Configuration.
Step 2	Click one of the connection profiles that you want and click Edit.

All the basic and advanced ASA RA VPN attributes can be seen in the Connection Profile name and details of the Security Cloud Control RA VPN configuration page.

Note

You can delete the default configuration (Select the default RA VPN configuration and in the Actions pane on the right, click Remove).

Primary Identity Source

Security Cloud Control reads the Connection Aliases and Group URLs attributes as Group Alias and Group URL.

Note

The connection profiles configured with SAML, Multiple certificates and AAA, and Multiple certificates aren't read.
The authentication server group with the interface and server group is not supported.

Security Cloud Control supports the AnyConnect connection profiles configured with "AAA", "AAA and certificate", and "Certificate only" authentication methods in Primary Identity Source.
The AAA Server Group is read in Security Cloud Control as Primary Identity Source for User Authentication inPrimary Identity Source (You can see this attribute by selecting AAA or AAA and Client Certificate as the Authentication Type).
- If the AAA Server Group has been configured something other than LOCAL, Security Cloud Control reads and displays this attribute in the Fallback Local Identity Source field under Primary Identity Source. (You can see this attribute by selecting AAA as the authentication type).
  
  To learn more about the server group attributes read in Security Cloud Control, see AAA Server Groups.

Secondary Identity Source

The Secondary Identity Source displays the secondary authentication attributes of the ASA device. To see these attributes, select AAA or AAA and Client Certificate as the authentication type, and click View Secondary Identity Source.

The Secondary Identity Source for User Authentication displays the secondary authentication Server Group attribute.
- If the Server Group has been configured something other than LOCAL, Security Cloud Control reads and displays this attribute in the Fallback Local Identity Source for Secondaryfield under Secondary Identity Source.
Security Cloud Control doesn't support the Attribute Server and Interface-Specific Authorization Server Groups attributes.

To learn more about the server group attributes read in Security Cloud Control, see AAA Server Groups.

Authorization Server

The Authorization Server displays the authorization Server Group attribute.
Security Cloud Control doesn't support the authorization server group with interface and server group.

To learn more about the RADIUS server group attributes read in Security Cloud Control, see RADIUS Server Groups.

Accounting Server

The Accounting Server displays the accounting Server Group attribute. To learn more about the server group attributes read in Security Cloud Control, see RADIUS Server Groups.

Client Address Pool Assignment

Security Cloud Control reads the Client Address Assignment attributes (DHCP Servers, Client Address Pools, and Client IPv6 Address Pools) as objects. (You can see these attributes in Client Address Pool Assignment). The DHCP server details are read as literals.

Note

Security Cloud Control doesn't support the IP address pools assigned on specific interfaces. However, these attributes can be seen in the ASA command-line interface (CLI).

AAA Server Groups

Security Cloud Control represents an LDAP Server Group and its associated LDAP Servers as an Active Directory Realm object. For Active Directory (AD), a realm is equivalent to an Active Directory domain. Note that Security Cloud Control does read the AD password for AD realm objects that are already present.

Procedure

Step 1

In the navigation bar on the left, choose Objects.

Step 2

Apply the Active Directory Realms filter to see this object.

Step 3

Select the Active Directory Realm object that you want and click Edit to see its details.

You can see that the AD realm contains the associated AD server and its configuration. If there are multiple Active Directory (AD) servers for the AD realm, the AD servers need to be duplicates of each other and support the same AD domain. Therefore, the basic realm properties such as Directory name, Directory Password, and Base Distinguished Name must be the same across all AD servers associated with that AD realm. Security Cloud Control displays a warning message in the Active Directory Realm object if these properties aren't the same. You have to correct these properties to make them consistent across the AD servers. If you continue without addressing this warning, Security Cloud Control uses one of the AD server properties and applies it to other servers in that realm object.

RADIUS Server Group

The AAA RADIUS Server Group attributes of the ASA device are read in Security Cloud Control as RADIUS Server Group objects.

Procedure

Step 1

In the left pane, click Objects.

Step 2

Apply the RADIUS Server Group filter to see this object.

Step 3

Select the object that you want and then click Edit to see its details.

The Enable dynamic authorization in ASA is read in Security Cloud Control as Dynamic Authorization (for RA VPN only).
The Depletion option in Reactivation Mode is read in Security Cloud Control, and therefore the Dead Time value associated with depletion time is read in Security Cloud Control. However, the Timed attribute is not read in Security Cloud Control.
Security Cloud Control doesn't support Accounting Mode, Timed, Enable interim accounting update, Enable interim accounting update, and Use authorization only mode.

RADIUS Server

When Security Cloud Control reads the Radius Servers from ASA, it creates a Radius server object specifies the name as "Name of the Radius server group_server name or IP address".

Procedure

Step 1	In the left pane, click Objects.
Step 2	Apply the RADIUS Server filter to see this object.
Step 3	Select the object that you want and then click Edit to see its details.

Group Policy

In the Group Policy section, click the drop-down to view the group policies associated with the device.

Attention

Security Cloud Control reads the group policies configured with tunneling protocol as SSL VPN Client.

Security Cloud Control reads most of the group policy attributes configured in ASA. The information is displayed across the tabs in the RA VPN Group policy wizard. To see the details of group policies read from the ASA device, you need to perform the following:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Filter for RA VPN Group Policy.

Step 3

Select the group policy associated with that device and click Edit.

Note

Security Cloud Control doesn't support the Standard Access Control Lists (ACL) defined in the split tunneling in the ASA device. It supports the Extended Access Control Lists (ACL) and reads them as ACLs in the ASA policies.

To see the policies, on the navigation bar, you can click Policies > ASA Access Policies.

To select the extended ACLs, perform the following:

Click the Split Tunneling tab.
Based on whether the traffic in ASA uses IPv4 or IPv6 addresses, select "Allow specified traffic over tunnel" or "Exclude networks specified below" from the corresponding drop-down list. Select the extended ACLs that are imported from ASA.

Create an ASA IP address pool

ASA address pool objects define IPv4 or IPv6 address pools that ASA devices assign to remote VPN clients. If you configure more than one address pool for a connection profile or group policy, the ASA uses the pools in the order in which you added them.

To define an IPv4 address pool, provide the IP address range. For example, 10.10.147.100 - 10.10.147.177.

To define an IPv6 address pool, provide the starting IP address, prefix, and number of addresses in the pool. For example, 2001:DB8:1::1.

If you assign addresses from a nonlocal subnet, add pools that fall on subnet boundaries so that routes for these networks are easier to add.

Perform the following to create an IP address pool:

Procedure

Step 1	In the left pane, click Objects.
Step 2	Click the blue plus button and select ASA > Address Pool.
Step 3	In the Create IP Address Pool dialog box, enter this information: Object Name: Enter the name of the address pool. It can be up to 64 characters IPv4 address pool: Select this radio button to configure IPv4 address pools. IPv4 Address Range: Enter the first IP address and the last IP address available in each configured pool. For example, 10.10.147.100 - 10.10.147.177. Mask: Identifies the subnet on which this IP address pool resides. IPv6 address pool: Select this radio button to configure IPv6 address pools. IPv6 Address: Enter the first IP address available in the configured pool and prefix length in bits in <address>/<prefix> format. For example, 2001:DB8:1::1/3. Number of Addresses: Identifies the number of IPv6 addresses, starting at the IP Address, that are in the pool.
Step 4	Click Save.

Remote Access VPN Certificate-Based Authentication

The remote access VPN uses digital certificates for authenticating secure gateways and AnyConnect clients (endpoints) in the following scenarios:

Important

Security Cloud Control handles the installation of digital certificates on the VPN headends (ASA FTD). It does not handle the installation of certificates on the AnyConnect client device. The administrator of your organization must handle it.

Identify and authenticate the VPN headend device (ASA FTD):

VPN headends require an identity certificate to identify and authenticate themselves when the AnyConnect client requests a VPN connection. Using Security Cloud Control, you must install the identity certificate on the device. See Installing an Identity Certificate Using PKCS12 or Certificate And Key. It is not mandatory to install the issuer's CA certificate on the AnyConnect client.

While creating the Remote Access VPN configuration from Security Cloud Control, assign the enrolled identity certificate to the outside interface of the device and download the configuration to the device. The identity certificate becomes fully operational on the outside interface of the device.

When the AnyConnect client attempts to connect to VPN, the device authenticates itself by presenting its identity certificate to the AnyConnect client. The AnyConnect client verifies this identity certificate with its trusted CA certificate and trusts the certificate and thereby the device. If the CA certificate isn’t installed on the AnyConnect client, the user must manually trust the device when prompted.

Identify and authenticate the AnyConnect client:

Note

This applies when you use "Client Certificate Only" or "AAA and Client Certificate" as the authentication method in the connection profile of remote access VPN configuration. It does not apply for "AAA Only".

Once the device is trusted, the AnyConnect client needs to authenticate itself to complete the VPN connection. You must install an identity certificate on the AnyConnect client and using Security Cloud Control, install a trusted CA certificate on the device. These certificates must be issued from the same certificate authority. See Installing Trusted CA Certificate in ASA.

The AnyConnect client presents its identity certificate and the device verifies this certificate with its trusted CA certificate and establishes the VPN connection.

Exempt Remote Access VPN Traffic from NAT

Configure NAT Exempt to exempt traffic to and from the remote access VPN endpoints from NAT translation. If you do not exempt VPN traffic from NAT, ensure that the existing NAT rules for the outside and inside interfaces do not apply to the remote access VPN pool of addresses. NAT exempt rules are manual static identity NAT rules for a given source/destination interface and network combination, but they are not reflected in the NAT policy, they are hidden. If you enable NAT Exempt, you must also configure the following.

Inside Interfaces: Select the interfaces for the internal networks remote users will be accessing. NAT rules are created for these interfaces.
Inside Networks: Select the network objects that represent internal networks remote users will be accessing. The networks list must contain the same IP types as the address pools you are supporting.

Before you begin

Create ASA network objects that match the configuration of the local IP address pools used in the connection profile and group policy of that device. These network objects must be assigned as the destination address and translated address when configuring the NAT rule.

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Use the filter and search field to find the ASA device for which you want to create the NAT rule.
Step 3	In the Management area of the details panel, click NAT .
Step 4	Click > Twice NAT. In section 1, select Static. Click Continue. In section 2, select Source Interface = 'any' and Destination Interface = 'any'.Click Continue. In section 3, select Source Original Address = 'any' and Source Translated Address = 'any'. Select Use Destination. Destination Original Address and Source Translated Address: Click Choose in the drop-down and select the network objects that match the configuration of the local IP address pools. In the below example, 'IPV4_Object' is the network object with the same configuration as the IPv4 address pool object used in the connection profile and group policy settings of the ASA (BGL_ASA1_SH) device. Select Disable proxy ARP for incoming packets. Click Save. Repeat the process (from step 4) to create equivalent rules for each of the other network objects equivalent to IP address pools.
Step 5	Review and deploy configuration changes to the devices.

Install the AnyConnect Client Software on ASA

To complete a VPN connection, your users must install the AnyConnect client software. You can use your existing software distribution methods to install the software directly. Or, you can have users install the AnyConnect client directly from the ASA device.

Note

Users must have Administrator rights on their workstations to install the software.

If you decide to have users initially install the software from the ASA device, inform users to perform the following steps:

Note

Android and iOS users should download AnyConnect from the appropriate App Store.

Procedure

Step 1

Using a web browser, open https://ravpn-address, where ravpn-address is the IP address or hostname of the outside interface on which you are allowing VPN connections. You identify this interface when you configure the remote access VPN. The system prompts the user to log in.

Step 2

Log into the site. Users are authenticated using the directory server configured for the remote access VPN. Log in must be successful to continue. If the login is successful, the system determines if the user already has the required version of the AnyConnect client. If the AnyConnect client is absent from the user's computer or is down-level, the system automatically starts installing the AnyConnect software. When the installation is finished, AnyConnect completes the remote access VPN connection.

Modify ASA Remote Access VPN Configuration

When ASA devices are onboarded to Security Cloud Control, it discovers and displays the pre-existing remote access VPN configurations from onboarded ASA devices. For more information, see Manage and Deploy Pre-existing ASA Remote Access VPN Configuration.

You can modify these configurations and download the new configuration to the device.

Procedure

Step 1	In the left pane, click Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Step 2	If you want to add or remove group policies to the VPN configuration, click the VPN configuration associated with the onboarded ASA device. In the Actions pane on the left, click Group Policies. Click the blue + icon and configure the selections and click Select.
Step 3	Click the VPN configuration, and in the Actions pane, click Edit. The wizard lists the ASA device associated with the configuration. You can modify the following details in the same fashion as it was created: Change the name of the remote access VPN configuration. Click the three dots appearing in the row that shows the device details and click Edit. For more information, see Create ASA Remote Access VPN Configuration
Step 4	Click OK.
Step 5	Preview and deploy configuration changes for all devices

Modify ASA Connection Profile

Procedure

Step 1	In the left pane, click Secure Connections > End User Connections > Remote Access VPN > ASA & FDM.
Step 2	Expand the VPN configuration associated with the onboarded ASA device, and select a connection profile.
Step 3	Under Actions, click Edit.
Step 4	Edit the values in the same fashion as it was created and click Done. For more information, see Configure ASA Remote Access VPN Connection Profile
Step 5	Preview and deploy configuration changes for all 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 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.

Verify ASA Remote Access VPN Configuration

After you configure the remote access VPN and deploy the configuration to the device, verify that you can make remote connections.

Procedure

Step 1	From an external network, establish a VPN connection using the AnyConnect client. Using a web browser, open https://ravpn-address, where ravpn-address is the IP address or hostname of the outside interface on which you are allowing VPN connections. If necessary, install the client software and complete the connection. See How Users Can Install the AnyConnect Client Software. If you configured group URLs, also try those URLs.
Step 2	In the Security Devices page, select the device (FTD or ASA) you want to verify and click Command Line Interface under Device Actions.
Step 3	Use the show vpn-sessiondb command to view summary information about current VPN sessions.
Step 4	The statistics should show your active AnyConnect Client session, and information on cumulative sessions, the peak concurrent number of sessions, and inactive sessions. Following is sample output from the command.
Step 5	Use the show vpn-sessiondb anyconnect command to view detailed information about current AnyConnect VPN sessions. Detailed information includes encryption used, bytes transmitted and received, and other statistics. If you use your VPN connection, you should see the bytes transmitted/received numbers change as you re-issue this command.
Step 6	Use the show vpn-sessiondb anyconnect command to view detailed information about current AnyConnect VPN sessions. Detailed information includes encryption used, bytes transmitted and received, and other statistics. If you use your VPN connection, you should see the bytes transmitted/received numbers change as you re-issue this command.

View ASA Remote Access VPN Configuration Details

Procedure

Step 1

In the left pane, choose 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 remote access 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.

Bias-Free Language

Results

Chapter: Virtual Private Network Management

Virtual Private Network Management

Configure Virtual Private Network Management

Introduction to Site-to-Site Virtual Private Network

Simplifying Site-to-Site VPNs with Security Cloud Control Firewall Management

Site-to-Site VPN concepts

VPN Topology

IPsec and IKE Protocols

Authentication VPN Tunnels

Virtual Tunnel Interface (VTI)

VPN Encryption Domain

About Extranet Devices

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

IPsec proposal and IKE policy objects

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 Firewall Management 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 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 ASA 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