Managing Virtual Private Network in Security Cloud Control

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

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

Security Cloud Control supports the following types of VPN connections:

Introduction to Site-to-Site Virtual Private Network

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

Simplifying Site-to-Site VPNs with Security Cloud Control

Site-to-Site VPNs are a reliable solution for securely connecting multiple networks over the internet. To make this process easier and more efficient, Security Cloud Control provides a consolidated Site-to-Site VPN wizard. This intuitive tool is designed to simplify the creation and management of secure VPN tunnels while reducing the complexity involved in traditional VPN configurations.

The Site-to-Site VPN wizard provides a single, unified interface for configuring VPN tunnels across a variety of managed devices. This consistency ensures a streamlined experience for administrators, regardless of the specific device or network environment. By offering a centralized and intuitive configuration process, the wizard helps organizations enhance operational efficiency, reduce errors, and maintain a high level of security in their network infrastructure.

The table below specifies the permitted site-to-site VPN configurations for the managed devices.

FDM-managed

Cloud-delivered Firewall Management Center-managed Firewall Threat Defense

Secure Firewall ASA

Multicloud Defense

FDM-managed

Yes

No

No

No

Cloud-delivered Firewall Management Center-managed Firewall Threat Defense

No

Yes

Yes

Yes

Secure Firewall ASA

No

Yes

Yes

Yes

Multicloud Defense

No

Yes

Yes

No

Site-to-Site VPN Concepts

VPN Topology

To create a new site-to-site VPN topology you must provide a unique name, specify a topology type, choose the IKE version that is used for IPsec IKEv1 or IKEv2, or both and authentication method. Once configured, you deploy the topology to FTD.

IPsec and IKE Protocols

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

Authentication VPN Tunnels

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

Virtual Tunnel Interface (VTI)

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

VPN Encryption Domain

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

  • Policy-Based: The encryption domain is set to allow any traffic which enters the IPSec tunnel. IPSec Local and remote traffic selectors are set to 0.0.0.0. This means that any traffic routed into the IPSec tunnel is encrypted regardless of the source/destination subnet. ASA supports policy-based VPN with crypto maps.

  • Route-Based: The encryption domain is set to encrypt only specific IP ranges for both source and destination. It creates a virtual IPsec interface, and whatever traffic enters that interface is encrypted and decrypted. ASA supports route-based VPN with the use of Virtual Tunnel Interfaces (VTIs).

About Extranet Devices

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

  • Non-Cisco Device: You cannot use Security Cloud Control to create and deploy configurations to non-Cisco devices.

  • Unmanaged Cisco Device: Cisco device not managed by your organization, such as spokes in networks managed by other organizations within your company, or a connection to a service provider or partner's network.

About Global IKE Policies

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

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

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

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

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

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

Managing IKEv1 Policies
About IKEv1 Policy

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

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

Create an IKEv1 Policy

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

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

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

Procedure

Step 1

In the left pane, click Objects.

Step 2

Do one of these things:

  • Click the blue plus button and select FDM > IKEv1 Policy to create a new IKEv1 policy.

  • In the object page, select the IKEv1 policy you want to edit and click Edit in the Actions pane at the right.

Step 3

Enter an object name, up to 128 characters.

Step 4

Configure the IKEv1 properties.

  • Priority - The relative priority of the IKE policy, from 1 to 65,535. The priority determines the order of the IKE policy compared by the two negotiating peers when attempting to find a common security association (SA). If the remote IPsec peer does not support the parameters selected in your highest priority policy, it tries to use the parameters defined in the next lowest priority. The lower the number, the higher the priority.

  • Encryption - The encryption algorithm used to establish the Phase 1 security association (SA) for protecting Phase 2 negotiations. For an explanation of the options, see Deciding Which Encryption Algorithm to Use.

  • Diffie-Hellman Group - The Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two peers must have a matching modulus group. For an explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use.

  • Lifetime - The lifetime of the security association (SA), in seconds, from 120 to 2147483647 or blank. When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes. The default is 86400. To specify an unlimited lifetime, enter no value (leave the field blank).

  • Authentication - The method of authentication to use between the two peers. For more information, see Deciding Which Authentication Method to Use.

    • Preshared Key - Use the preshared key that is defined on each device. These keys allow for a secret key to be shared between two peers and to be used by IKE during the authentication phase. If the peer is not configured with the same preshared key, the IKE SA cannot be established.

    • Certificate - Use the device identity certificates for the peers to identify each other. You must obtain these certificates by enrolling each peer in a Certificate Authority. You must also upload the trusted CA root and intermediate CA certificates used to sign the identity certificates in each peer. The peers can be enrolled in the same or a different CA. You cannot use self-signed certificates for either peer.

  • Hash - The hash algorithm for creating a message digest, which is used to ensure message integrity. For an explanation of the options, see Deciding Which Hash Algorithms to Use.

Step 5

Click Add.


Managing IKEv2 Policies
About IKEv2 Policy

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

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

Create an IKEv2 Policy

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

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

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

Procedure

Step 1

In the left pane, click Objects.

Step 2

Do one of these things:

  • Click the blue plus button and select FDM > IKEv2 Policy to create a new IKEv2 policy.

  • In the object page, select the IKEv2 policy you want to edit and click Edit in the Actions pane at the right.

Step 3

Enter an object name, up to 128 characters.

Step 4

Configure the IKEv2 properties.

  • Priority - The relative priority of the IKE policy, from 1 to 65,535. The priority determines the order of the IKE policy compared by the two negotiating peers when attempting to find a common security association (SA). If the remote IPsec peer does not support the parameters selected in your highest priority policy, it tries to use the parameters defined in the next lowest priority. The lower the number, the higher the priority.

  • State - Whether the IKE policy is enabled or disabled. Click the toggle to change the state. Only enabled policies are used during IKE negotiations.

  • Encryption - The encryption algorithm used to establish the Phase 1 security association (SA) for protecting Phase 2 negotiations. Select all algorithms that you want to allow, although you cannot include both mixed-mode (AES-GCM) and normal mode options in the same policy. (Normal mode requires that you select an integrity hash, whereas mixed-mode prohibits a separate integrity hash selection.) The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Encryption Algorithm to Use.

  • Diffie-Hellman Group - The Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two peers must have a matching modulus group. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest group until a match is agreed upon. For an explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use.

  • Integrity Hash - The integrity portion of the hash algorithm for creating a message digest, which is used to ensure message integrity. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. The integrity hash is not used with the AES-GCM encryption options. For an explanation of the options, see Deciding Which Hash Algorithms to Use.

  • Pseudo-Random Function (PRF) Hash - The pseudo-random function (PRF) portion of the hash algorithm, which is used as the algorithm to derive keying material and hashing operations required for the IKEv2 tunnel encryption. In IKEv1, the Integrity and PRF algorithms are not separated, but in IKEv2, you can specify different algorithms for these elements. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Hash Algorithms to Use.

  • Lifetime - The lifetime of the security association (SA), in seconds, from 120 to 2147483647 or blank. When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes. The default is 86400. To specify an unlimited lifetime, enter no value (leave the field blank).

Step 5

Click Add.


About IPsec Proposals

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

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

  • When you create an IKEv1 IPsec proposal, you select the mode in which IPsec operates, and define the required encryption and authentication types. You can select single options for the algorithms. If you want to support multiple combinations in a VPN, create and select multiple IKEv1 IPsec Proposal objects.

  • When you create an IKEv2 IPsec proposal, you can select all of the encryption and hash algorithms allowed in a VPN. The system orders the settings from the most secure to the least secure and negotiates with the peer until a match is found. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.

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


Note


We recommend using both encryption and authentication on IPsec tunnels.


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

Managing an IKEv1 IPsec Proposal Object

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

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


Note


We recommend using both encryption and authentication on IPsec tunnels.


Create an IKEv1 IPsec Proposal Object

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

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


Note


We recommend using both encryption and authentication on IPsec tunnels.


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

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

Procedure

Step 1

In the left pane, click Manage > Objects.

Step 2

Do one of these things:

  • Click the blue plus button and select FDM > IKEv1 IPsec Proposal to create the new object.

  • In the object page, select the IPsec proposal you want to edit and click Edit in the Actions pane at the right.

Step 3

Enter an object name for the new object.

Step 4

Select the Mode in which the IKEv1 IPsec Proposal object operates.

  • Tunnel mode encapsulates the entire IP packet. The IPSec header is added between the original IP header and a new IP header. This is the default. Use tunnel mode when the firewall is protecting traffic to and from hosts positioned behind the firewall. Tunnel mode is the normal way regular IPSec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.

  • Transport mode encapsulates only the upper-layer protocols of an IP packet. The IPSec header is inserted between the IP header and the upper-layer protocol header (such as TCP). Transport mode requires that both the source and destination hosts support IPSec, and can only be used when the destination peer of the tunnel is the final destination of the IP packet. Transport mode is generally used only when protecting a Layer 2 or Layer 3 tunneling protocol such as GRE, L2TP, and DLSW.

Step 5

Select the ESP Encryption (Encapsulating Security Protocol encryption) algorithm for this proposal. For more information, see Deciding Which Encryption Algorithm to Use.

Step 6

Select the ESP Hash or integrity algorithm to use for authentication. For more information, see Deciding Which Hash Algorithms to Use.

Step 7

Click Add.


Managing an IKEv2 IPsec Proposal Object

IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel.

When you create an IKEv2 IPsec proposal, you can select all of the encryption and hash algorithms allowed in a VPN. The system orders the settings from the most secure to the least secure and negotiates with the peer until a match is found. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.

Create or Edit an IKEv2 IPsec Proposal Object

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

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

Procedure

Step 1

In the left pane, click Manage > Objects.

Step 2

Do one of these things:

  • Click the blue plus button and select FDM > IKEv2 IPsec Proposal to create the new object.

  • In the object page, select the IPsec proposal you want to edit and click Edit in the Actions pane at the right.

Step 3

Enter an object name for the new object.

Step 4

Configure the IKE2 IPsec proposal objects:

  • Encryption - The Encapsulating Security Protocol (ESP) encryption algorithm for this proposal. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Encryption Algorithm to Use.

  • Integrity Hash - The hash or integrity algorithm to use for authentication. Select all the algorithms that you want to allow. The system negotiates with the peer, starting from the strongest to the weakest algorithm until a match is agreed upon. For an explanation of the options, see Deciding Which Hash Algorithms to Use.

Step 5

Click Add.


Encryption and Hash Algorithms Used in VPN

Because a VPN tunnel typically traverses a public network, most likely the Internet, you need to encrypt the connection to protect the traffic. You define the encryption and other security techniques to apply using IKE policies and IPsec proposals.

If your device license allows you to apply strong encryption, there is a wide range of encryption and hash algorithms, and Diffie-Hellman groups, from which to choose. However, as a general rule, the stronger the encryption that you apply to the tunnel, the worse the system performance. Find a balance between security and performance that provides sufficient protection without compromising efficiency.

We cannot provide specific guidance on which options to choose. If you operate within a larger corporation or other organization, there might already be defined standards that you need to meet. If not, take the time to research the options.

The following topics explain the available options:

Deciding Which Encryption Algorithm to Use

When determining which encryption algorithms to use for the IKE policy or IPsec proposal, your choice is limited to algorithms supported by the devices in the VPN.

For IKEv2, you can configure multiple encryption algorithms. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.

For IPsec proposals, the algorithm is used by the Encapsulating Security Protocol (ESP), which provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50. In IKEv1 IPsec proposals, the algorithm name is prefixed with ESP.

If your device license qualifies for strong encryption, you can choose from the following encryption algorithms. If you are not qualified for strong encryption, you can select DES only.

  • AES-GCM - (IKEv2 only.) Advanced Encryption Standard in Galois/Counter Mode is a block cipher mode of operation providing confidentiality and data-origin authentication and provides greater security than AES. AES-GCM offers three different key strengths: 128-, 192-, and 256-bit keys. A longer key provides higher security but a reduction in performance. GCM is a mode of AES that is required to support NSA Suite B. NSA Suite B is a set of cryptographic algorithms that devices must support to meet federal standards for cryptographic strength.

  • AES-GMAC - (IKEv2 IPsec proposals only.) Advanced Encryption Standard Galois Message Authentication Code is a block cipher mode of operation providing only data-origin authentication. It is a variant of AES-GCM that allows data authentication without encrypting the data. AES-GMAC offers three different key strengths: 128-, 192-, and 256-bit keys.

  • AES - Advanced Encryption Standard is a symmetric cipher algorithm that provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192-, and 256-bit keys. A longer key provides higher security but a reduction in performance.

  • DES - Data Encryption Standard, which encrypts using 56-bit keys, is a symmetric secret-key block algorithm. If your license account does not meet the requirements for export controls, this is your only option. It is faster than 3DES and uses fewer system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, choose DES.

  • 3DES - Triple DES, which encrypts three times using 56-bit keys, is more secure than DES because it processes each block of data three times with a different key. However, it uses more system resources and is slower than DES.

  • NULL - A null encryption algorithm provides authentication without encryption. This is typically used for testing purposes only.

Deciding Which Hash Algorithms to Use

In IKE policies, the hash algorithm creates a message digest, which is used to ensure message integrity. In IKEv2, the hash algorithm is separated into two options, one for the integrity algorithm, and one for the pseudo-random function (PRF).

In IPsec proposals, the hash algorithm is used by the Encapsulating Security Protocol (ESP) for authentication. In IKEv2 IPsec Proposals, this is called the integrity hash. In IKEv1 IPsec proposals, the algorithm name is prefixed with ESP-, and there is also an -HMAC suffix (which stands for "hash method authentication code").

For IKEv2, you can configure multiple hash algorithms. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.

You can choose from the following hash algorithms:

  • SHA (Secure Hash Algorithm) - Standard SHA (SHA-1) produces a 160-bit digest. SHA is more resistant to brute-force attacks than MD5. However, it is also more resource-intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.

  • The following SHA-2 options, which are even more secure, are available for IKEv2 configurations. Choose one of these if you want to implement the NSA Suite B cryptography specification.

    • SHA-256 - Specifies the Secure Hash Algorithm SHA-2 with the 256-bit digest.

    • SHA-384 - Specifies the Secure Hash Algorithm SHA-2 with the 384-bit digest.

    • SHA-512 - Specifies the Secure Hash Algorithm SHA-2 with the 512-bit digest.

  • MD5 (Message Digest 5) - Produces a 128-bit digest. MD5 uses less processing time for overall faster performance than SHA, but it is considered to be weaker than SHA.

  • Null or None (NULL, ESP-NONE) - (IPsec Proposals only.) A null Hash Algorithm; this is typically used for testing purposes only. However, you should choose the null integrity algorithm if you select one of the AES-GCM/GMAC options as the encryption algorithm. Even if you choose a non-null option, the integrity hash is ignored for these encryption standards.

Deciding Which Diffie-Hellman Modulus Group to Use

You can use the following Diffie-Hellman key derivation algorithms to generate IPsec security association (SA) keys. Each group has different size modules. A larger modulus provides higher security but requires more processing time. You must have a matching modulus group on both peers.

If you select AES encryption, to support the large key sizes required by AES, you should use Diffie-Hellman (DH) Group 5 or higher. IKEv1 policies do not support all of the groups listed below.

To implement the NSA Suite B cryptography specification, use IKEv2 and select one of the elliptic curves Diffie-Hellman (ECDH) options: 19, 20, or 21. Elliptic curve options and groups that use 2048-bit modulus are less exposed to attacks such as Logjam.

For IKEv2, you can configure multiple groups. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.

  • 2 - Diffie-Hellman Group 2: 1024-bit modular exponential (MODP) group. This option is no longer considered good protection.

  • 5 - Diffie-Hellman Group 5: 1536-bit MODP group. Formerly considered good protection for 128-bit keys, this option is no longer considered good protection.

  • 14 - Diffie-Hellman Group 14: 2048-bit modular exponential (MODP) group. Considered good protection for 192-bit keys.

  • 19 - Diffie-Hellman Group 19: National Institute of Standards and Technology (NIST) 256-bit elliptic curve modulo a prime (ECP) group.

  • 20 - Diffie-Hellman Group 20: NIST 384-bit ECP group.

  • 21 - Diffie-Hellman Group 21: NIST 521-bit ECP group.

  • 24 - Diffie-Hellman Group 24: 2048-bit MODP group with 256-bit prime order subgroup. This option is no longer recommended.

Deciding Which Authentication Method to Use

You can use the following methods to authenticate the peers in a site-to-site VPN connection.

Preshared Keys

Preshared keys are secret key strings configured on each peer in the connection. These keys are used by IKE during the authentication phase. For IKEv1, you must configure the same preshared key on each peer. For IKEv2, you can configure unique keys on each peer.

Preshared keys do not scale well compared to certificates. If you need to configure a large number of site-to-site VPN connections, use the certificate method instead of the preshared key method.

Site-to-Site VPN Configuration for FDM-Managed

Security Cloud Control supports these aspects of site-to-site VPN functionality on FDM-managed devices:

  • Both IPsec IKEv1 & IKEv2 protocols are supported.

  • Automatic or manual pre-shared keys for authentication.

  • IPv4 and IPv6. All combinations of inside and outside are supported.

  • IPsec IKEv2 site-to-site VPN topologies provide configuration settings to comply with Security Certifications.

  • Static and dynamic interfaces.

  • Support for the dynamic IP address for the extranet device as an endpoint.

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

Security Cloud Control allows you to create a site-to-site VPN connection between peers when one of the peers' VPN interface IP address is not known or when the interface obtains its address from a DHCP server. Any dynamic peer whose preshared key, IKE settings, and IPsec configurations match with another peer can establish a site-to-site VPN connection.

Consider two peers, A and B. The static peer is a device whose IP address of its VPN interface is fixed and a dynamic peer is a device whose IP address of the VPN interface is not known or has a temporary IP address.

The following use cases describe different scenarios for establishing a secure site-to-site VPN connection with dynamically-addressed peers:

  • A is a static peer, and B is a dynamic peer or conversely.

  • A is a static peer, and B is a dynamic peer with a resolved IP address from the DHCP server or conversely. You can select Bind VPN to the assigned IP to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.

  • A and B are dynamic with resolved IP addresses from the DHCP server. In such a case, you must select Bind VPN to the assigned IP for at least one peer to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.

  • A is a dynamic peer, and B is an extranet device with a static or dynamic IP address.

  • A is a dynamic peer with a resolved IP address from the DHCP server, and B is an Extranet device with a static or dynamic IP address. You can select Bind VPN to the assigned IP to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.


Important


If you select Bind VPN to the assigned IP, the VPN binds statically to the DHCP assigned IP address. However, this dynamic interface can receive many new IP addresses after the peer restarts. Although the VPN tunnel updates the new IP address, the other peer is not updated with the new configuration. You must deploy the site-to-site configuration again for out-of-band changes on the other peer.



Note


If the IP address of the interface is changed by using a local manager like Firewall Device Manager, the Configuration Status of that peer in Security Cloud Control shows "Conflict Detected". When you resolve this out-of-band change, the Configuration Status of the other peer changes to the "Not Synced" state. You must deploy the Security Cloud Control configuration to the device which is in "Not Synced" state.


Typically, the dynamic peer must be the one that initiates the connection as the other peer would not know the IP address of the dynamic peer. When the remote peer attempts to establish the connection, the other peer validates the connection using the preshared key, IKE settings, and IPsec configurations.

Because the VPN connection is established only after the remote peer initiates the connection, any outbound traffic that matches access control rules that allow traffic in the VPN tunnel will be dropped until that connection is established. This ensures that data does not leave your network without the appropriate encryption and VPN protection.


Note


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


  • If both peers have DHCP assigned IP addresses.

    • Workaround: You can configure a site-to-site VPN, if one of the peers has a resolved IP address from the DHCP server. In such a case, you must select Bind VPN to the assigned IP to configure site-to-site VPN.

  • If a device has more than one dynamic peer connection.

    • Workaround: You can configure a site-to-site VPN by performing the following steps:

      • Consider three devices A, B, and C.

      • Configure site-to-site VPN connection between A (static peer) and B (dynamic peer).

      • Configure site-to-site VPN connection between A and C (dynamic peer) by creating an Extranet device. Assign the static VPN interface IP address of A to the Extranet device and establish a connection with C.

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

  • Security Cloud Control does not support a crypto-acl to design the interesting traffic for S2S VPN. It only supports protected networks.

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

  • Whenever IKE ports 500/4500 are in use or when there are some PAT translations that are active, the site-to-site VPN cannot be configured on the same ports as it fails to start the service on those ports.

  • Transport mode is not supported only tunnel mode. IPsec tunnel mode encrypts the entire original IP datagram which becomes the payload in a new IP packet. Use tunnel mode when the firewall is protecting traffic to and from hosts positioned behind a firewall. Tunnel mode is the normal way regular IPsec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.

  • For this release, only PTP topology is supported, containing one or more VPN tunnels. Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.

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

Note that an FDM-managed device has the capability to establish a secure VPN tunnel either with another FDM-managed device or with an extranet device.

Procedure

Step 1

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

Step 2

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

Step 3

In the Peer Selection area, provide the following information:

  • Configuration Name: Enter a unique topology name.

    We recommend naming your topology to indicate that it is an FDM-managed device VPN, and its topology type.

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

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

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

    Note

     

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

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

  • VPN Access Interface: Select the interface to establish a connection between peer 1 and peer 2.

  • Routing: Click Add Networks and select one or more protected networks to establish a site-to-site tunnel between the protected networks of peer 1 and peer 2

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

Step 6

Click Next.

Step 7

In the IKE Settings area, choose the IKE versions to use during Internet Key Exchange (IKE) negotiations and specify the privacy configurations: For more information on the IKE policies, see Configuring the Global IKE Policy.

Note

 

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

  1. Select either or both options as appropriate.

    Note

     

    By default, IKEV Version 2 is enabled.

  2. Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.

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

  4. Click IKE Version 1 to enable it.

  5. Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.

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

  1. Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.

  2. Choose the Diffie-Hellman Group for Perfect Forward Secrecy. For more information, see Deciding Which Diffie-Hellman Modulus Group to Use.

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

  1. In the Security Cloud Control navigation bar at the left, click Policies and select the option that you want.

  2. Create policies for incoming and outgoing traffic on both peers.

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

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

    Creating the AC policy for permitting incoming traffic:

    The policy 'Permit_incoming_VPN_traffic_from_973' is created on the 'FTD_BGL_972' device for allowing incoming traffic from the peer ('FTD_BGL_973').

    • Source Zone: Set the zone of the peer device from which the network traffic originates. In this example, the traffic is originating from FTD_BGL_973 and reaching FTD_BGL_972.

    • Source Network: Set the protected network of the peer device from which the network traffic originates. In this example, traffic is originating from 'sanjose-network' which is the protected network behind the peer device (FTD_BGL_973).

    • Destination Network: Set the protected network of the device on which the network traffic arrives. In this example, traffic is arriving at 'boulder-network' which is the protected network behind the peer device (FTD_BGL_972). Note: The remaining fields can have the default value ("Any").

    • Set Action to Allow for allowing the traffic subject to the intrusion and other inspection settings in the policy.

    Creating the AC policy for permitting outgoing traffic:

    The policy 'Permit_outgoing_VPN_traffic_to_973' is created on the 'FTD_BGL_972' device for permitting outgoing traffic to the peer ('FTD_BGL_973').

    • Source Network: Set the protected network of the peer device from which the network traffic originates. In this example, traffic is originating from 'boulder-network' which is the protected network behind the peer device (FTD_BGL_972).

    • Destination Zone: Set the zone of the peer device on which the network traffic arrives. In this example, the traffic is arriving from FTD_BGL_972 and reaching FTD_BGL_973.

    • Destination Network: Set the protected network of the peer on which the network traffic arrives. In this example, traffic is arriving on 'sanjose-network' which is the protected network behind the peer device (FTD_BGL_972). Note: The remaining fields can have the default value ("Any").

    • Set Action to Allow for allowing the traffic subject to the intrusion and other inspection settings in the policy.

After creating AC policies on one device, you must create similar policies on its peer.

Step 2

If NAT is configured on either of the peer devices, you need to configure the NAT exempt rules manually. See Exempting Site-to-Site VPN Traffic from NAT.

Step 3

Configure routing for receiving the return VPN traffic on each peer.

For more information, see Configure Routing.

  1. Gateway-Select the network object that identifies the IP address for the gateway to the destination network. Traffic is sent to this address.

  2. Interface-Select the interface through which you want to send traffic. In this example, the traffic is sent through 'outside' interface.

  3. Destination Networks-Select one or network objects, that identify the destination network. In this example, the destination is 'sanjose-network' which is behind peer (FTD_BGL_973).

After configuring routing settings on one device, you must configure similar settings on its peer.


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

The advanced configuration wizard is used by default to modify an existing site-to-site VPN configuration.

Procedure

Step 1

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

Step 2

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

Step 3

In the Actions pane, click Edit.

Note

 

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

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

  2. Select a device by clicking the box.

  3. Click View details to view its peers.

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

  5. Click Edit in Tunnel Details.

Step 4

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

Note

 

You cannot change the participating devices.

Step 5

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

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

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

  3. Click Next.

Step 6

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

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

  2. Choose the Diffie-Hellman Group for Perfect Forward Secrecy.

  3. Click Edit VPN, and then Finish.


The Point to point VPN is modified and updated with all the changes you have made.

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

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

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

Step 3

In the Actions pane on the right, click Delete.


The selected site-to-site VPN tunnel is deleted.

Exempt Site-to-Site VPN Traffic from NAT

When you have a site-to-site VPN connection defined on an interface, and you also have NAT rules for that interface, you can optionally exempt the traffic on the VPN from the NAT rules. You might want to do this if the remote end of the VPN connection can handle your internal addresses.

When you create the VPN connection, you can select the NAT Exempt option to create the rules automatically. However, this works only if your local protected network is connected through a single routed interface (not a bridge group member). If instead, the local networks in the connection reside behind two or more routed interfaces or one or more bridge group members, you need to configure the NAT exempt rules manually.

To exempt VPN traffic from NAT rules, you create an identity manual NAT rule for the local traffic when the destination is the remote network. Then, apply NAT to the traffic when the destination is anything else (for example, the Internet). If you have more than one interface for the local network, create rules for each interface. Also, consider the following suggestions:

  • If there is more than one local network in the connection, create a network object group to hold the objects that define the networks.

  • If you are including both IPv4 and IPv6 networks in the VPN, create separate identity NAT rules for each.

Consider the following example, which shows a site-to-site tunnel connecting the Boulder and San Jose offices. For traffic that you want to go to the Internet (for example from 10.1.1.6 in Boulder to www.example.com), you need a public IP address provided by NAT to access the Internet. The below example uses interface Port Address Translation (PAT) rules. However, for traffic that you want to go over the VPN tunnel (for example from 10.1.1.6 in Boulder to 10.2.2.78 in San Jose), you do not want to perform NAT; you need to exempt that traffic by creating an identity NAT rule. Identity NAT translates an address to the same address.

The following example explains the configuration for Firewall1 (Boulder). The example assumes that the inside interface is a bridge group, so you need to write the rules for each member interface. The process is the same if you have a single or multiple routed inside interfaces.


Note


This example assumes IPv4 only. If the VPN also includes IPv6 networks, create parallel rules for IPv6. Note that you cannot implement IPv6 interface PAT, so you need to create a host object with a unique IPv6 address to use for PAT.


Procedure

Step 1

Create objects to define the various networks.

  1. In the left pane, click Objects.

  2. Click the blue plus button to create an object.

  3. Click FTD > Network.

  4. Identify the Boulder inside network.

  5. Enter an object name (for example, boulder-network).

  6. Select Create a network object.

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

  8. Click Add.

  9. Click the blue plus button to create an object.

  10. Define the inside San Jose network.

  11. Enter the object name (for example, san-jose).

  12. Select Create a network object.

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

  14. Click Add.

Step 2

Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder).

  1. In the left pane, click Security Devices > All Devices.

  2. Use the filter to find the device for which you want to create the NAT rule.

  3. In the Management area of the details panel, click NAT .

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

  1. Click > Twice NAT.

  2. In section 1, select Dynamic. Click Continue.

  3. In section 2, select Source Interface = inside and Destination Interface = outside. Click Continue.

  4. In section 3, select Source Original Address = 'boulder-network' and Source Translated Address = 'interface'.

  5. Click Save.

  6. 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 Firewall Management to FTD.

Step 5

If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.

  • The manual identity NAT rule would be for 'sanjose-network' when the destination is boulder-network. Create new interface objects for the Firewall2 inside and outside networks.

  • The manual dynamic interface PAT rule would be for 'sanjose-network' when the destination is "any."


Configure Static and Default Routes for FDM-Managed Devices

Define static routes on an FDM-managed device so it knows where to send packets bound for networks not directly connected to the interfaces on the system.

Consider creating a default route. This is the route for network 0.0.0.0/0. This route defines where to send packets whose egress interface cannot be determined by existing NAT translations, static NAT rules, or other static routes.

You might need other static routes if the default gateway cannot be used to get to all networks. For example, the default route is usually an upstream router on the outside interface. If there are additional inside networks that are not directly connected to the device, and they cannot be accessed through the default gateway, you need static routes for each of those inside networks.

You cannot define static routes for the networks that are directly connected to system interfaces. The system automatically creates these routes.

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

You can create site-to-site IPsec connections between a Cloud-Delivered Firewall Management Center-managed Firewall Threat Defense device and the following devices:

  • Firewall Threat Defense

  • Secure Firewall ASA

  • Multicloud Defense

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

Use the following procedure to create a site-to-site VPN tunnel between two Firewall Threat Defense devices managed by Cloud-Delivered Firewall Management Center.

Before you begin

There should not be any pending deployments on the Firewall Threat Defense device.

Procedure

Step 1

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

Step 2

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

Step 3

In the Peer Selection area, provide the following information:

  • Configuration Name: Enter a unique topology name.

    We recommend naming your topology to indicate that it is a Firewall Threat Defense device VPN, and its topology type.

  • Peer 1: Click the FTD tab and select a Firewall Threat Defense device.

  • Peer 2: Click the FTD tab and select a Firewall Threat Defense device.

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

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

  • VPN Access Interface: Select the interface for both peer 1 and peer 2 to establish a connection between them.

  • LAN Interfaces: Select the interface for both peer 1 and peer 2 that controls the LAN subnet. You can select multiple interfaces

  • Routing: Click Add Networks and select one or more protected networks for peer 1 and peer 2 to establish a site-to-site tunnel between between them.

Step 6

Click Next.

Step 7

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.

  1. Select either or both options as appropriate.

    Note

     

    By default, IKEV Version 2 is enabled.

  2. Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.

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

  4. Click IKE Version 1 to enable it.

  5. Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.

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

  1. Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.

  2. Choose the Diffie-Hellman Group for Perfect Forward Secrecy. For more information, see Encryption and Hash Algorithms Used in VPN.

  3. 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:

  1. Choose Administration > Integrations > Firewall Management Center.

  2. Ensure the check box corresponding to Cloud-Delivered FMC is checked and in the Actions pane on the right, click Deployment.

  3. Select the device participating in the site-to-site VPN configuration and click Deploy.

  4. 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:

Procedure

Step 1

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

Step 2

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

Step 3

In the Peer Selection area, provide the following information:

  • Configuration Name: Enter a unique topology name.

  • Peer 1: Click the FTD tab and select a Firewall Threat Defense device.

  • Peer 2: Click the Multicloud Defense tab and select the gateway you want.

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

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

  • VPN Access Interface: Select the interface for Firewall Threat Defense to establish a connection with the gateway.

  • Public IP (optional): Specify the public IP address of the NAT that maps to the outside interface of the selected Firewall Threat Defense.

  • Routing: Click Add Networks and select one or more protected networks from Firewall Threat Defense to create a site-to-site tunnel between the selected networks and the Multicloud Defense Gateway

Step 6

Click Next.

Step 7

In the Tunnel Details area, provide the following information:

  • Virtual Tunnel Interface IP: Specify the addresses for the new Virtual Tunnel Interfaces on the peer. You can assign any unused IP address that is currently not used on this device.

  • Autonomous System Number: Specify the autonomous system number of the network.

Step 8

Click Next.

Step 9

In the IKE Settings area, click Add IKEv2 and add the IKE version for the Internet Key Exchange (IKE) negotiations and specify the privacy configurations.

Security Cloud Control generates a default Local Pre-Shared Key. This is a secret key string that is configured on the peers. IKE uses this key during the authentication phase. It is used to verify each other when establishing a tunnel between the peers.

Step 10

Click Next.

Step 11

In the IPSec Settings area, click Add IKEv2 IPSec Proposals and select the IKE IPSec configuration. The proposals are available depending on the selection that is made in the IKE Settings step. See Configuring IPSec Proposals.

Step 12

Click Next.

Step 13

In the Finish area, review the configuration and continue further only if you’re satisfied with the configuration.

Step 14

Click Submit.

The configurations are pushed to the Multicloud Defense Gateway.

Step 15

Perform the following steps to deploy the configuration to a cloud-delivered Firewall Management Center-managed Firewall Threat Defense device:

  1. Choose Administration > Integrations > Firewall Management Center.

  2. Ensure the check box corresponding to Cloud-Delivered FMC is checked and in the Actions pane on the right, click Deployment.

  3. Select the device participating in the site-to-site VPN configuration and click Deploy.

  4. Choose Devices > VPN > Site To Site. You can see the same VPN topology that was configured in Security Cloud Control.


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

Before you begin

There should not be any pending deployments on the Firewall Threat Defense device.

Procedure

Step 1

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

Step 2

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

Step 3

In the Peer Selection area, provide the following information:

  • Configuration Name: Enter a unique topology name.

    We recommend naming your topology to indicate that it is a Firewall Threat Defense device VPN, and its topology type.

  • Peer 1: Click the FTD tab and select a Firewall Threat Defense device.

  • Peer 2: Click the ASA tab and select a Secure Firewall ASAdevice.

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

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

  • VPN Access Interface: Select the interface for both peer 1 and peer 2 to establish a connection between them.

  • LAN Interfaces: Select the interface for both peer 1 and peer 2 that controls the LAN subnet. You can select multiple interfaces

  • Routing: Click Add Networks and select one or more protected networks for peer 1 and peer 2 to establish a site-to-site tunnel between between them.

Step 6

Click Next.

Step 7

In the Tunnel Details area, provide the following information:

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

Step 8

Click Next.

Step 9

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.

  1. Select either or both options as appropriate.

    Note

     

    By default, IKEV Version 2 is enabled.

  2. Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.

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

  4. Click IKE Version 1 to enable it.

  5. Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.

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

  1. Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.

  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:

  1. Choose Administration > Integrations > Firewall Management Center.

  2. Ensure the check box corresponding to Cloud-Delivered FMC is checked and in the Actions pane on the right, click Deployment.

  3. Select the device participating in the site-to-site VPN configuration and click Deploy.

  4. Choose Devices > VPN > Site To Site. You can see the same VPN topology that was configured in Security Cloud Control.


Site-to-Site VPN Configuration for Secure Firewall ASA

Security Cloud Control supports these aspects of site-to-site VPN functionality on Secure Firewall ASA devices:

  • Both IPsec IKEv1 & IKEv2 protocols are supported.

  • Automatic or manual pre-shared keys for authentication.

  • IPv4 and IPv6. All combinations of inside and outside are supported.

  • IPsec IKEv2 site-to-site VPN topologies provide configuration settings to comply with Security Certifications.

  • Static and dynamic interfaces.

  • Support the static or dynamic IP address for the extranet device as an endpoint.

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

Security Cloud Control allows you to create a site-to-site VPN connection between peers when one of the peers' VPN interface IP address is not known or when the interface obtains its address from a DHCP server. Any dynamic peer whose preshared key, IKE settings, and IPsec configurations match with another peer can establish a site-to-site VPN connection.

Consider two peers, A and B. The static peer is a device whose IP address of its VPN interface is fixed and a dynamic peer is a device whose IP address of the VPN interface is not known or has a temporary IP address.

The following use cases describe different scenarios for establishing a secure site-to-site VPN connection with dynamically-addressed peers:

  • A is a static peer, and B is a dynamic peer or conversely.

  • A is a static peer, and B is a dynamic peer with a resolved IP address from the DHCP server or conversely.

  • A is a dynamic peer, and B is an extranet device with a static or dynamic IP address.

  • A is a dynamic peer with a resolved IP address from the DHCP server, and B is an Extranet device with a static or dynamic IP address.


Note


If the IP address of the interface is changed by using a local manager like Adaptive Security Device Manager (ASDM), the Configuration Status of that peer in Security Cloud Control shows "Conflict Detected". When you resolve this out-of-band change, the Configuration Status of the other peer changes to the "Not Synced" state. You must deploy the Security Cloud Control configuration to the device which is in "Not Synced" state.


Typically, the dynamic peer must be the one that initiates the connection as the other peer would not know the IP address of the dynamic peer. When the remote peer attempts to establish the connection, the other peer validates the connection using the preshared key, IKE settings, and IPsec configurations.

Because the VPN connection is established only after the remote peer initiates the connection, any outbound traffic that matches access control rules that allow traffic in the VPN tunnel will be dropped until that connection is established. This ensures that data does not leave your network without the appropriate encryption and VPN protection.


Note


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

If a device has more than one dynamic peer connection.

  • 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

In the IKE Settings area, choose the IKE versions to use during Internet Key Exchange (IKE) negotiations and specify the privacy configurations: For more information on the IKE policies, see About Global IKE Policies.

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.

  1. Select either or both options as appropriate.

    Note

     

    By default, IKEV Version 2 is enabled.

  2. Click Add IKEv2 Policies to select the IKEv2 policies for peer 1 and peer 2.

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

  4. Click IKE Version 1 to enable it.

  5. Click Add IKEv1 Policies to select the IKEv1 policies for peer 1 and peer 2.

  6. The IPEv1 Pre-Shared Key is auto-generated.

Step 10

Click Next.

Step 11

In the IPSec Settings area, specify the IPSec configurations for peer 1 and peer 2. The corresponding IKEV proposals are available depending on the selection that is made in the IKE Settings step.

For more information on the IPSec settings, see the About Global IKE Policies.

  1. Click Add IKEv2 IPSec Proposals and select the IKEv2 proposals you want for peer 1 and peer 2.

  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:

Procedure

Step 1

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

Step 2

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

Step 3

In the Peer Selection area, provide the following information:

  • Configuration Name: Enter a unique topology name.

  • Peer 1: Click the ASA tab and select a Secure Firewall ASA device.

  • Peer 2: Click the Multicloud Defense tab and select a multicloud gateway.

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

Step 4

Click Next.

Step 5

In the Peer Details area, provide the following information:

  • VPN Access Interface: Select the interface for Secure Firewall ASA to establish a connection with Multicloud Defense Gateway.

  • LAN Interfaces: Select the interface for Secure Firewall ASA that controls the LAN subnet. You can select multiple interfaces

  • Public IP (optional): Specify the public IP address of the NAT that maps to the outside interface of the selected Secure Firewall ASA.

  • Routing: Click Add Networks and select one or more protected networks for Secure Firewall ASA to establish a site-to-site tunnel with Multicloud Defense Gateway.

Step 6

Click Next.

Step 7

In the Tunnel Details area, provide the following information:

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

  • Autonomous System Number (Peer 1): If the Secure Firewall ASA device does not have an autonomous system number configured, Security Cloud Control will suggest one for the device, which can be modified. If the device already has an autonomous system number configured, the current value will be displayed and cannot be modified.

  • Autonomous System Number (Peer 2): If a BGP profile is assigned to the Multicloud Defense Gateway, the autonomous number associated with the profile is displayed, which cannot be modified. See Add a Multicloud Defense Gateway.

Step 8

Click Next.

Step 9

In the IKE Settings area, Security Cloud Control generates a default Local Pre-Shared Key. This is a secret key string that is configured on the peers. IKE uses this key during the authentication phase. It is used to verify each other when establishing a tunnel between the peers.

Step 10

In the Finish area, review the configuration and continue further only if you’re satisfied with the configuration.

By default, the Deploy changes to ASA immediately check box is checked to deploy the configurations immediately to the ASA device after clicking Submit.

If you want to review and deploy the configurations manually later, then uncheck this check box.

Step 11

Click Submit.

The configurations are pushed to the Multicloud Defense Gateway.


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

Exempt Site-to-Site VPN Traffic from NAT

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.

  1. In the left pane, click Objects.

  2. Click the blue plus button to create an object.

  3. Click FTD > Network.

  4. Identify the Boulder inside network.

  5. Enter an object name (for example, boulder-network).

  6. Select Create a network object.

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

  8. Click Add.

  9. Click the blue plus button to create an object.

  10. Define the inside San Jose network.

  11. Enter the object name (for example, san-jose).

  12. Select Create a network object.

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

  14. Click Add.

Step 2

Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder).

  1. In the left pane, click Security Devices > All Devices.

  2. Use the filter to find the device for which you want to create the NAT rule.

  3. In the Management area of the details panel, click NAT .

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

  1. Click > Twice NAT.

  2. In section 1, select Dynamic. Click Continue.

  3. In section 2, select Source Interface = inside and Destination Interface = outside. Click Continue.

  4. In section 3, select Source Original Address = 'boulder-network' and Source Translated Address = 'interface'.

  5. Click Save.

  6. 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 Firewall Management to FTD.

Step 5

If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.

  • The manual identity NAT rule would be for 'sanjose-network' when the destination is boulder-network. Create new interface objects for the Firewall2 inside and outside networks.

  • The manual dynamic interface PAT rule would be for 'sanjose-network' when the destination is "any."


Monitor Site-to-Site Virtual Private Networks

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

Check Site-to-Site VPN Tunnel Connectivity

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


Note


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


To check tunnel connectivity from the VPN page:

Procedure

Step 1

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

Step 2

Search and filter the list of tunnels for your site-to-site VPN tunnel and select it.

Step 3

In the Actions pane at the right, click Check Connectivity.


Site-To-Site VPN Dashboard

Security Cloud Control provides a consolidated information about site-to-site VPN connections created in the tenant.

  1. In the left pane, click Secure Connections > Site to Site VPN. The Site-to-Site VPN provides the information in the following widgets:

  • Sessions & Insights: Displays a bar graph representing Active VPN Tunnels and Idle VPN Tunnels, each in appropriate colors.

  • Issues: Shows the total number of tunnels detected with issues.

  • Pending Deploy: Shows the total number of tunnels with pending deployment.

By clicking on a value in the pie chart or any link in the widget, the site-to-site VPN listing page is displayed with a filter based on the selected value. For instance, in the VPN Tunnel Status widget, on clicking the Active VPN Tunnels, you will be directed to the site-to-site VPN listing page with the Active status filter applied, showing only the active tunnels.

Identify VPN Issues

Security Cloud Control can identify VPN issues on FTD. (This feature is not yet available for AWS VPC site-to-site VPN tunnels.) This article describes:

Find VPN Tunnels with Missing Peers

The "Missing IP Peer" condition is more likely to occur on ASA devices than FDM-managed devices.

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

Select Table View.

Step 3

Open the Filter panel by clicking the filter icon .

Step 4

Check Detected Issues.

Step 5

Select each device reporting an issue and look in the Peers pane at the right. One peer name will be listed. Security Cloud Control reports the other peer name as, "[Missing peer IP.]"


Find VPN Peers with Encryption Key Issues

Use this approach to locate VPN Peers with encryption key issues such as:

  • IKEv1 or IKEv2 keys are invalid, missing, or mismatched

  • Obsolete or low encryption tunnels

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

Select Table View.

Step 3

Open the Filter panel by clicking the filter icon .

Step 4

Select each device reporting an issue and look in the Peers pane at the right. The peer information will show you both peers.

Step 5

Click on View Peers for one of the devices.

Step 6

Double-click the device reporting the issue in the Diagram View.

Step 7

Click Key Exchange in the Tunnel Details panel at the bottom. You will be able to view both devices and diagnose the key issue from that point.


Find Incomplete or Misconfigured Access Lists Defined for a Tunnel

The "incomplete or misconfigured access-list" condition could only occur on ASA devices.

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

Select Table View.

Step 3

Open the Filter panel by clicking the filter icon .

Step 4

Select each device reporting an issue and look in the Peers pane at the right. The peer information shows you both peers.

Step 5

Click on View Peers for one of the devices.

Step 6

Double-click the device reporting the issue in the Diagram View.

Step 7

Click Tunnel Details in the Tunnel Details panel at the bottom. You will see the message, "Network Policy: Incomplete"


Find Issues in Tunnel Configuration

The tunnel configuration error can occur in the following scenarios:

  • When the IP address of a site-to-site VPN interface changes, the "Peer IP Address Value has changed".

  • When the IKE value of a VPN tunnel doesn't match the other VPN tunnel, the "IKE value Mismatch" message appears.

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

Select Table View.

Step 3

Open the Filter panel by clicking the filter icon .

Step 4

In the Tunnel Issues, click Detected Issues to view the VPN configuration reporting errors. You can view the configuration reporting issues .

Step 5

Select the VPN configuration reporting issues.

Step 6

In the Peers pane on the right, the icon appears for the peer having the issue. Hover over the icon to see the issue and resolution.

Next Step: Resolve Tunnel Configuration Issues.


Resolve Tunnel Configuration Issues

This procedure attempts to resolve these tunnel configuration issues:

  • When the IP address of a site-to-site VPN interface changes, the "Peer IP Address Value has changed".

  • When the IKE value of a VPN tunnel doesn’t match the other VPN tunnel, the "IKE value Mismatch" message appears.

See Find Issues in Tunnel Configuration for more information.

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the appropriate device type tab and select the device associated with the VPN configuration reporting an issue.

Step 4

Accept the device changes.

Step 5

In the left pane, click VPN > ASA/FDM Site-to-Site VPN to open the VPN page.

Step 6

Select the VPN configuration reporting this issue.

Step 7

In the Actions pane, click the Edit icon.

Step 8

Click Next in each step until you click the Finish button in step 4.

Step 9

Preview and Deploy Configuration Changes for All Devices.


Search and Filter Site-to-Site VPN Tunnels

Use the filter sidebar in combination with the search field to focus your search of VPN tunnels presented in the VPN tunnel diagram.

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

Click the filter icon to open the filter pane.

Step 3

Use these filters to refine your search:

  • Filter by Device-Click Filter by Device, select the device type tab, and check the devices you want to find by filtering.

  • Tunnel Issues-Whether or not we have detected either side of the tunnel has issues. Some examples of a device having issues may be but not limited to is: missing associated interface or peer IP address or access list, IKEv1 proposal mismatches, etc. (Detecting tunnel issues is not yet available for AWS VPC VPN tunnels.)

  • Devices/Services-Filter by type of device.

  • Status–Tunnel status can be active or idle.

    • Active-There is an open session where network packets are traversing the VPN tunnel or a successful session was established and hasn’t been timed-out yet. Active can assist to indicate that tunnel is active and relevant.

    • Idle - Security Cloud Control is unable to discover an open session for this tunnel. The tunnel may either be not in use or there is an issue with this tunnel.

  • Onboarded - Devices could be managed by Security Cloud Control or not managed (unmanaged) by Security Cloud Control.

    • Managed – Filter by devices that Security Cloud Control manages.

    • Unmanaged – Filter by devices that Security Cloud Control does not manage.

  • Device Types - Whether or not either side of the tunnel is a live (connected device) or model device.

Step 4

You can also search the filtered results by device name or IP address by entering that information in the search bar. The search is case-insensitive.


Onboard an Unmanaged Site-to-Site VPN Peer

Security Cloud Control will discover a site-to-site VPN tunnel when one of the peers is onboarded. If the second peer is not managed by Security Cloud Control, you can filter the list of VPN tunnels to find the unmanaged device and onboard it:

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

Select Table View.

Step 3

Open the filter panel by clicking .

Step 4

Check Unmanaged.

Step 5

Select a tunnel from the table from the results.

Step 6

In the Peers pane on the right, click Onboard Device and follow the instructions on the screen.


View IKE Object Details of Site-To-Site VPN Tunnels

You can view the details of the IKE objects configured on the peers/devices of the selected tunnel. These details appear in a tree structure in a hierarchy based on the priority of the IKE policy object.


Note


Extranet devices don't show the IKE Objects details.


Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

In the VPN Tunnels page, click the name of the VPN tunnel that connects the peers.

Step 3

Under Relationships on the right, expand the object that you want to see its details.


View Last Successful Site-to-Site VPN Tunnel Establishment Date

This information typically provides the date and time when the VPN tunnel was last successfully established, ensuring connectivity between the two sites. Accessing this data can help you monitor VPN health and troubleshoot any connectivity issues that might arise.

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

The VPN Tunnels page displays all the site-to-site VPN tunnels configured across your managed devices. You can click a tunnel to view more details in the right pane.

Note

 

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

The Last Active field shows the date and time the VPN tunnel was successfully established.


View Site-to-Site VPN Tunnel Information

The site-to-site VPN table view is a complete listing of all site-to-site VPN tunnels available across all devices onboarded to Security Cloud Control. A tunnel only exists once in this list. Clicking on a tunnel listed in the table provides an option in the right side bar to navigate directly to a tunnel's peers for further investigation.

In cases where Security Cloud Control does not manage both sides of a tunnel, you can click Onboard Device to open the main onboarding page an onboard the unmanaged peer. In cases where Security Cloud Control manages both side of a tunnel, the Peer 2 column contains the name of the managed device. However, in the case of an AWS VPC, the Peer 2 column contains the IP address of the VPN gateway.

To view site-to-site VPN connections in the table view:

Procedure

Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

The VPN Tunnels page displays all the site-to-site VPN tunnels configured across your managed devices. You can click on a tunnel to view more details in the right pane.

Note

 

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


Site-to-Site VPN Global View

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

Procedure

Step 1

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

Step 2

Click the Global view button.

Step 3

Use Search and Filter Site-to-Site VPN Tunnels to find a specific tunnel, or zoom into the Global View graphic to find the VPN gateway and its peers that you are looking for.

Step 4

Select one of the peers represented in the Global View.

Step 5

Click View Details.

Step 6

Click the other end of the VPN tunnel and Security Cloud Control displays Tunnel Details, NAT Information, and Key Exchange information for that connection:

  • Tunnel Details-Displays the name and connectivity information about the tunnel. Clicking the Refresh icon updates the connectivity information for the tunnels.

  • Tunnel Details specific to AWS connections-Tunnel details for AWS site-to-site connections are slightly different than for other connections. For each connection from the AWS VPC to your VPN gateway, AWS creates two VPN tunnels. This is for high availability.

    • The name of the tunnel represents the name of the VPC your VPN gateway is connected to. The IP address named in the tunnel is the IP address that your VPN gateway knows as the VPC.

    • If the Security Cloud Control Connectivity status shows active, the AWS tunnel state is Up. If the Security Cloud Control Connectivity state is inactive, the AWS tunnel state is Down.

  • NAT Information-Displays the type of NAT rule being used, original and translated packet information, and provides links to the NAT table to view the NAT rule for that tunnel. (Not yet available for AWS VPC site-to-site VPN.)

  • Key Exchange-Displays the cryptographic keys in use by the tunnel and key-exchange issues. (Not yet available for AWS VPC site-to-site VPN.)


Site-to-Site VPN Tunnels Pane

The Tunnels pane displays a list of all the tunnels associated with a particular VPN gateway. For site-to-site VPN connections between your VPN gateway and an AWS VPC, the tunnels pane shows all the tunnels from your VPN gateway to the VPC. Since each site-to-site VPN connection between your VPN gateway and an AWS VPC has two tunnels, you will see double the number of tunnels you normally would for other devices.

VPN Gateway Details

Displays the number of peers connected to the VPN gateway and the IP address of the VPN gateway. This is only visible in the VPN Tunnels page.

View Peer

After you select a site-to-site VPN peer pair, the peers pane lists the two devices in the pair and allows you to click View Peer for one of the devices. By clicking View Peer, you see any other site-to-site peer that device is associated with. This is visible in the Table view and in the Global view.

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

Procedure


Step 1

In the left pane, click Manage > Secure Connections > Network Connections > Site to Site VPN to open the VPN page.

Step 2

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

Step 3

In the Actions pane on the right, click Delete.


The selected site-to-site VPN tunnel is deleted.

Monitor Remote Access Virtual Private Network Sessions

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

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

  • A list of active and historical sessions for up to a year.

  • Shows intuitive graphical visuals to provide at-a-glance views from all active VPN headends managed by Security Cloud Control.

  • The live session screen shows the most used operating system and VPN connection profile in the Security Cloud Control tenant. It also shows the average session duration and data uploaded and downloaded.

  • Filtering capabilities to narrow your search based on criteria such as device type, device names, session length, and the amount of data transmitted and received.

Monitor Live AnyConnect Remote Access VPN Sessions

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

Before you begin

  • Onboard the remote access VPN head-ends to Security Cloud Control.

  • Ensure that the connectivity status of the devices you want to monitor live data is "Online" on the Security Devices page.

Procedure


Step 1

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

Step 2

Click RA VPN.

Step 3

Click Live.

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

Note

 

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


View Live Remote Access VPN Data

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

Dashboard View

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

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

  • Breakdown (All Devices): Shows a total number of live sessions. It also shows a pie chart that is divided into four arc lengths. It illustrates the percentage of VPN sessions of the top three devices with the highest number of sessions. The remaining arc length represents the aggregate of other devices.

  • Shows most used operating system and connection profile in the Security Cloud Control tenant.

  • Shows average session duration and data uploaded and downloaded.

  • Active Sessions by Country: Shows an interactive heat map of the location of the users connected to your RA VPN headends.

    • Countries from which users have connected are shown in progressively darker shades of blue, depending on the relative proportion of the sessions established from that country — the darker the blue color means more sessions are established from that country.

    • The legend at the bottom of the map provides a scale that indicates the correlation between the number of sessions in a country and the shade of blue used to color the country.

    • Hover the mouse pointer on the map to see the country's name and the total number of active user sessions established from that country.

    • Hover the mouse pointer on the table to see the country's location and the total number of active user sessions on the map.

Tabular View

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

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

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


    Important


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


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

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

Monitor Historical AnyConnect Remote Access VPN Sessions

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

Before you begin

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

Procedure


Step 1

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

Step 2

Click RA VPN.

Step 3

Click Historical.

  • Remote Access VPN Session data is stored and available to query for 1 year.

  • You can use Search and Filter RA VPN Sessions functionalities to narrow down your search based on criteria such as device type, session length, and upload and download data range.

  • The Data TX and Data RX information are not available for Secure Firewall Threat Defense.


View Historical Remote Access VPN Data

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

Dashboard View

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

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

Tabular View

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

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


Important


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


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

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

Search and Filter Remote Access VPN Sessions

Search

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

Filter

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

  • Filter by Devices: Select one or all devices from the All Types tab to view sessions from selected devices. The window also categorizes the devices based on their type and displays them under the corresponding tabs.

  • Sessions Time Range (Applicable only for historical data): View historical sessions from a specified date and time range. Note that you can view data recorded over the last three months.

  • Sessions Length: View sessions based on a specified session's duration length. Set the time unit (hours, minutes, or seconds) and specify the minimum and maximum duration length by moving the slider. You can also specify the length in the provided fields.

  • Upload (TX): View sessions based on a specified amount of data uploaded or transferred to the secured network. Set the unit (GB, MB, or KB) and select the range by moving the slider accordingly. You can also specify the values in the available fields.

  • Download (RX): View sessions based on a specified amount of data downloaded or received from the secured network. Set the unit (GB, MB, or KB) and select the range by moving the slider accordingly. You can also specify the values in the available fields.

Customize the Remote Access VPN Monitoring View

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

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

Export Remote Access VPN Sessions to a CSV File

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

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

Procedure


Step 1

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

Step 2

In the View By Devices area, select one of the following:

  • All Devices to export active sessions from all devices listed below it.

  • Click on a device that you want to export sessions of that device.

Step 3

Click the icon on the top right corner. Security Cloud Control exports the rules you see on the screen to a .csv file.

Step 4

Open the .csv file in a spreadsheet application to sort and filter the results.


Remote Access VPN Dashboard

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

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

  • VPN Tunnel Status: Displays a pie chart representing the active and idle VPN tunnels, each in appropriate colors. This chart shows the top ten number of remote access VPN sessions by headends.

  • Statistics: Shows the average session duration and data uploaded and downloaded.

Disconnect Remote Access VPN Sessions on FDM-Managed Device

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

Procedure


Step 1

Log on to Firewall Device Manager and use the device CLI as explained in the Logging Into the Command Line Interface (CLI) section of the "Getting Started" chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.

Step 2

Execute the vpn-sessionsdb logoff {name} command and replace name with the user name. This command terminates all sessions for the username that you specify.