Cisco Security Cloud Control: Secure Firewall ASA Management

PDF

Cisco Security Cloud Control: Secure Firewall ASA Management

Site-to-Site VPN for Secure Firewall ASA

Updated: July 17, 2026

Want to summarize with AI?

Log in

Learn how to create site-to-site VPN tunnels for Secure Firewall ASA devices, including ASA-to-ASA, ASA-to-extranet, and ASA-to-Multicloud Defense connections.

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

1.

From the Security Cloud Control Home page, click Firewall.
2.

In the left pane, click Secure Connections > Site to Site VPN > ASA & FDM.
3.

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

4.

5.

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.

6.

Click Next.
7.

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

Click Next.
9.

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

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

Click Next.
12.

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

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

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

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.

See the Deploy Configuration Changes section to deploy site-to-site VPN configuration on the devices associated with the new tunnel.

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

Note

If you are a new customer and you want to use Security Cloud Control to configure a site-to-site VPN between Multicloud Defense and an ASA device, contact Cisco Technical Assistance Center (Cisco TAC) to enable this feature.

To manually configure a site-to-site VPN between ASA and Multicloud Defense, you can configure the VPN in the Multicloud Defense application and also on the ASA device manually, and bring up the site-to-site VPN.

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

1.

From the Security Cloud Control Home page, click Firewall.
2.

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

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

4.

In the Peer Selection area, provide the following information:

  • Configuration Name: Enter a unique topology name.

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

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

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

5.

Click Next.
6.

In the Peer Details area, provide the following information:

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

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

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

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

Click Next.
8.

In the Tunnel Details area, provide the following information:

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

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

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

Click Next.
10.

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

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

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

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

Click Submit.

The configurations are pushed to the Multicloud Defense Gateway.

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