Cisco Secure Access Help

PDF

Cisco Secure Access Help

Configure Tunnels with Cisco Secure Firewall

Updated: August 24, 2026

Want to summarize with AI?

Log in

Understand how to configure network tunnels with Cisco Secure Firewall to support site-to-site VPN between Firewall Threat Defense devices and Secure Access through Cisco Secure Firewall Management Center.

Cisco Secure Firewall is a family of threat-focused next-generation firewalls. It can be managed centrally through Cisco Secure Firewall Management Center or through the on-box manager Secure Firewall Device Manager (FDM). This guide covers the steps to configure site-to-site VPN between FTD devices and Secure Access through Cisco Secure Firewall Management Center.

Until version 6.7, FTD only supports policy-based VPN (Crypto-map). Version 6.7+ supports Virtual tunnel interface (VTI), version 7.1+ supports IKE identity and policy-based routing (PBR) through graphic interface.

The Secure Firewall configuration process consists of the following steps.

  1. Add Network Object

  2. Add Traffic Selector ACL

  3. Configure Site-to-Site VPN

  4. Configure NAT Policy

  5. Configure Access Policy

Procedure

  1. To start the configuration, log in to your Cisco Secure Firewall Management Center web interface at its IP address or FQDN; for example, https://FMC_IP_OR_FQDN.

  2. Secure Firewall authenticates to the Secure Access IPsec headend by using a Pre-Shared Key (PSK) and IKEv2 IP identity. Follow the steps in Add Network Tunnel Group to add an FTD device to Secure Access.

    Note
    Secure Access does not support dynamic IP addresses for ASA and Secure Firewall devices.
    The new tunnel appears in Secure Access with a status of Unestablished. The tunnel status is updated once the first IKEv2 INIT message containing the tunnel identity is received in one of the Secure Access data centers.

  3. Create a network object type “Group”: in Secure Firewall, navigate to Objects > Object Management > Network > Add Network > Add Group, then add the Secure Access resolvers IP address so the DNS queries are not sent through the tunnel.


    New Network Group page with an option to add a new network object type Group in Secure Firewall
    Note

    Optionally, add 146.112.0.0/16 as a network. Web traffic from endpoints with PAC file or Cisco Secure Client as well as proxy chaining traffic can then go outside the IPSec tunnel and achieve higher throughput.

    Currently, if the DNS queries are sent through the tunnel it will be NATed to 146.112.0.0/16 IP range and queries will not be linked to the user's dashboard. By bypassing the traffic to the Secure Access resolvers it is possible to add a public IP address to the dashboard (network deployment) and retrain DNS visibility and enforcement capabilities.

    Note
    Public IP traffic from SIG users will appear to come from the address ranges 146.112.0.0/16 and 155.190.0.0/16. Depending on your organization, you may be required to inform service providers that you access through the Secure Access service of these additional IP address ranges. For example, some service providers require prior knowledge of the IP address ranges used before allowing access to their service.

  4. Add the traffic selector ACL: Navigate to Objects > Object Management > Access List > Extended > Add Extended Access List.

    This ACL is used in the IKEv2 security association negotiation as well as when Secure Firewall makes decisions about when to encrypt traffic. It does not encrypt traffic denied in the ACL when the deny statement comes before the permit statement.
    1. Enter a name for the ACL and then click Add to add the Access Control Entries (ACE).

      New Extended Access List Object page displaying a field to enter a ACL name and an option to add Access Control Entries
    2. The first entry denies traffic to the network object type group containing the Secure Access resolvers. Optionally, traffic to the 146.112.0.0/16 and 155.190.0.0/16 subnets can also be denied.

      Add Extended Access List Entry page displaying an option to block traffic to the network object type group containing Secure Access resolvers
    3. The second entry allows traffic from any IPv4 address to any IPv4 address. This is also the entry IKEv2 uses to negotiate the IPSec Security Association (traffic selector).

      Add Extended Access List Entry page with an option to allow traffic from any IPv4 address to any IPv4 address
    4. Click Save.

  5. You can now configure the site-to-site VPN. Navigate to Devices > VPN > Site to Site > Add VPN > Secure Firewall Threat Defense Device.


    Firewall Management Center page with an option to select a Secure Firewall Threat Defense device for configuring site-to-site VPN

  6. Enter a name for the topology. Check IKEv2 box (Secure Access supports IKEv2 only). For more information about supported protocols, see Supported IPSec Parameters.


    Create New VPN Topology page displaying fields for creating a new VPN topology

  7. Add two peers: the local peer (FTD device) and the remote peer (Secure Access).


    Create New VPN Topology page displaying fields to add local and remote peers
    1. Node A: Click Add and select the FTD device as the local peer and the interface sourcing the IPSec connection. The IP address is automatically populated.
    2. Protected Networks: Select Access List (Extended), then select the ACL you created in the traffic selector ACL. Click OK.
    3. Node B: Click Add to add the remote peer (Secure Access).
    4. Select Extranet and enter a name. Select Static, and enter one of the Secure Access datacenter IP addresses. Then select the same ACL, then click OK.

  8. Click the IKE tab to add a new IKEv2 Policy containing the desired crypto algorithms. For more information about encryption supported by Secure Access, see Supported IPsec Parameters.


    Create New VPN Topology page with an option to add an IKEv2 Policy with desired cryptographic algorithms in the IKE tab

  9. Enter a name for the IKEv2 policy, then select the parameters from the Supported IPsec Parameters.

    Note
    If you create a tunnel to a Cisco SD-WAN device, we strongly recommend configuring the Lifetime value to three hours or less; this prevents the cEdge router of the SD-WAN device from rekeying and minimizes the chance of the tunnel going down.

    New IKEv2 Policy page displaying fields to configure the policy parameters

  10. After saving the IKEv2 Policy, select it. Choose Pre-shared Manual Key from the Authentication drop-down menu and enter the key.


    Create New VPN Topology page displaying fields for selecting the authentication type for the IKEv2 policy

  11. Under IPSec:


    Create New VPN Topology page displaying fields for configuring IPSec parameters
    1. IKEv2 Mode: Select Tunnel.
    2. Add a new IKEv2 IPsec Proposal with your crypto algorithms or select an existing profile.
    3. Uncheck Enable Reverse Route Injection.
    4. Uncheck Enable Perfect Forward Secrecy.

  12. Under Advanced:


    Create New VPN Topology page displaying fields for configuring Advanced ISAKAMP settings
    1. Select IKE.
    2. IKE Keepalive: Select Enable.
    3. Identity Sent to Peers: Select ipAddress.
    4. Peer Identity Validation: Select Do not check.
    5. Select IPsec.

      Create New VPN Topology page with option for configuring advanced IPSec settings
    6. IPsec Settings check the box to Enable Fragmentation Before Encryption.
    7. Click Save.

Configure NAT Policy

If a NAT policy currently exists in the Secure Firewall device, this policy must be changed to exempt traffic going through the tunnel from being NATed. Secure Access requires the source of the connection to be the client's original private IP address — the public IP is not currently supported.

If you use the public IP in your internal network, you must NAT the traffic to a private IP address pool before sending the traffic to Secure Access, as most of the traffic goes through the Secure Access IPSec tunnel. It is easier to create NAT for the traffic not going through the tunnel and use no NAT for all other traffic.

In this example, the network object containing the Secure Access resolvers' IP address is referred to in the NAT statement. All traffic sourced from the internal network with a destination matching the network object will have the source IP NATed to the firewall interface address. All other traffic does not match the NAT statement, and so is forwarded to Secure Access without being NATed.

Procedure

  1. In Cisco Secure Firewall Management Center, navigate to Devices > NAT > New Policy > Threat Defense NAT.

  2. Enter a name, then select the FTD device to apply the policy.


    New Policy page with options to provide a name and select an FTD device for the policy

  3. Click Save.

  4. Click Add Rule.


    Add NAT Rule page with options to select the NAT rule type and add interface objects
    1. NAT Rule: Select Manual NAT Rule.
    2. Type: Select Dynamic.
    3. Under Interface Objects > Source Interface Objects > , select > Inside.
    4. Destination Interface Objects: Select Outside.
    5. Under Translation > Original Source, select a network object containing the internal subnet.
    6. Original Destination: Specify the Secure Access bypass network object created previously (UMB_BYPASS in this example).

      Add NAT Rule page displaying fields to specify the Secure Access bypass network object
      Note

      This object contains the Secure Access resolvers' IP address, as well as (optionally) the 146.112.0.0/16 and 155.190.0.0/16 networks, plus any other traffic you may want to exempt from the tunnel. Using this object facilitates the configuration, because when hosts and subnets are added or removed from the object, both the IPsec traffic selector and NAT statement are updated.

    7. Translated Source: Select Destination Interface IP.
    8. Translated Destination: Select the same object selected for Original Destination (UMB_BYPASS in this example).
      This ensures that the internal network is NATed to the interface IP address only when the destination is the network object containing the resolver's IP address. Other destinations do not match the NAT statement.
    9. Click OK.
    10. Click Save.

    Firewall Management Center page with an option to save the NAT rule configuration
    The NAT policy is configured.

Configure Access Policy

The Access Policy in Secure Firewall combines all the other policies (SSL Decryption, DNS, Pre-filter, Identity).

Procedure

  1. At a minimum, an entry permitting inside traffic going out should exist. In production environments, you normally add more specific access entries.


    Firewall Management Center page with an option to enable the policy for deployment

  2. Enable the policy by clicking Deploy in the top configuration bar.

Configure Secure Firewall VTI, PBR, and Per Tunnel Identity

Configure Tunnels in Secure Access

Threat Defense can authenticate to Secure Access by using a pre-shared key (PSK) and email or IP address identity. If the Secure Firewall is behind a NAT device, email identity is the only possible option.

You can use virtual tunnel interface with policy-based routing (PBR) and per-tunnel identity when you configure the Threat Defense side of the tunnel.

Follow the steps in Add Network Tunnel Group to create the Secure Access side of the tunnel for the Threat Defense tunnels. When you configure the network tunnel group, be sure to select email as the tunnel ID.

The new tunnel appears in Secure Access with a status of UnEstablished. The tunnel status is updated once the first IKEv2 INIT message containing the tunnel identity is received in one of the Secure Access data centers.

For an end-to-end configuration example of setting up redundant tunnels in Firewall Threat Defense, see Configure Secure Access with Secure Firewall with High Availability, https://www.cisco.com/c/en/us/support/docs/security/secure-access/222648-configure-secure-access-with-secure-fire.html.

Configure Site-to-Site VPN

You can now configure the site-to-site VPN.

This example configures a single tunnel to the primary Secure Access hub. You can configure as many tunnels as needed for bandwidth and backup so long as the VTI IP addresses are unique. Simply repeat the process and ensure that you use the email for the primary or the secondary tunnel ID as appropriate for each site-to-site VPN connection. You should have tunnels to both hubs to ensure redundancy in case or failure or when Secure Access performs maintenance.

For an example of configuring a single site-to-site VPN connection with both primary and secondary VTIs, see Configure Secure Access with Secure Firewall with High Availability, https://www.cisco.com/c/en/us/support/docs/security/secure-access/222648-configure-secure-access-with-secure-fire.html.

Procedure

  1. Navigate to Devices > VPN > Site to Site > Add VPN > Secure Firewall Threat Defense Device.


    Firewall Management Center page with an option to select Secure Firewall Threat Defense Device for VPN Configuration

  2. Enter a name for the topology, select Route Based (VTI), and check IKEv2 box. For more information about supported protocols, see Supported IPSec Parameters.


    Create New VPN Topology with option to provide a name and select a Route Based (VTI) topology

  3. Choose a Secure Firewall device from the Device drop-down list for Node A and click Add to add a Virtual Tunnel Interface.


    Endpoints tab with options to select a Secure Firewall device for Node A and add a Virtual Tunnel Interface

  4. Enter a name for the VTI, choose an existing Security Zone or create a new for the tunnel, enter a Tunnel ID and an IP address (a /30 subnet to accommodate local device and remote IP), and select the OUTSIDE interface as tunnel source. Then click Ok.


    Add Virtual Tunnel Interface page displaying fields to configure VTI for the tunnel

  5. Select the VTI you just created and check Send Local Identity to Peers.

    1. Select Email ID from the Local Identity Configuration dropdown.

    2. Enter the email address that is the primary tunnel ID from the Secure Access network tunnel group to which you are connecting.

  6. Under Node B, choose Extranet as the device, enter a name and IP address of a Secure Access data center.


    Node B page displaying fields to configure an extranet device

  7. Enter a name for the IKEv2 policy, then select the parameters from the list.


    New IKEv2 Policy page displaying fields to configure the policy parameters

  8. After saving the IKEv2 Policy, select it. Choose Pre-shared Manual Key from the Authentication drop-down list and enter the key.


    Create New VPN Topology page displaying fields for selecting the authentication type for the IKEv2 policy

  9. Under IPSec Configuration, add a new IKEv2 IPsec Proposal with your crypto algorithms or select an existing profile. Select Tunnel for IKEv2 Mode and uncheck Enable Reverse Route Injection and Enable Perfect Forward Secrecy.


    Create New VPN Topology page displaying fields to configure IPSec parameters

  10. In the Advanced tab under IKE, enable IKE Keepalive. Select autoOrDN as the Identity Sent to Peers, and disable Peer Identity Validation. Then click Save.


    Create New VPN Topology page displaying fields for configuring Advanced ISAKAMP settings

Configure Policy-based Routing

Use policy-based routing to determine the traffic that is sent to each tunnel. If you configure multiple tunnels, use the policy-based routing ACLs to divide traffic appropriately among the tunnels for load balancing.

Procedure

  1. Navigate to Devices > Device Management and click the name of the device to edit.

  2. Under Routing > Policy Based Routing, click Add to add a new policy

  3. Choose the Inside for the Ingress Interface (user's facing interface where PBR will be applied) and click Add.



  4. Choose the existing extended ACL, and click Add.


    To add a new policy Choose the Inside for the Ingress Interface (user's facing interface where PBR will be applied) and click Add. Choose the existing extended ACL, and click Add.

    Alternatively, if you are creating a new ACL, enter a name and add Access Control Entries (ACE) matching the traffic that should be redirected to Secure Access.

  5. Click Save to add the access entries.

  6. Under Match ACL, choose the newly created ACL and under Send To choose IP Address. Type the IP address in the same subnet previously used for VTI and click Save


    Access entries. Under Match ACL, choose the newly created ACL and under Send To choose IP Address. Type the IP address in the same subnet previously used for VTI and click Save.

  7. Click Save to save the configuration and deploy.

Configure Access Policy

If not yet allowed by the access policy, add an access entry allowing traffic from inside the network to the Secure Access tunnel.

Troubleshooting

Cisco Secure Firewall Management Center has a VPN troubleshooting tab where VPN-related events are displayed. By default, only error messages are sent from FTD to Cisco Secure Firewall Management Center, as LINA code (ASA) is responsible for the IPSec tasks the same commands available for troubleshooting the ASA devices are available in FTD.

If you need to send VPN debug messages to Cisco Secure Firewall Management Center, change the logging level in the Platform Settings policy. This policy is configured and added in Devices > Platform Settings. VPN logging to Cisco Secure Firewall Management Center is in the Syslog section of the Platform Settings policy from the Logging Setup tab. It is also possible to send logging messages to other destinations, such as the FTD device internal buffer.

Enable Logging for Debugging

Procedure

  1. In Cisco Secure Firewall Management Center, navigate to Devices > Platform Settings.

  2. Under Basic Logging Settings, add a logging destination.


    Add Logging Filter page with an option to add a logging destination

  3. Under Logging Destinations tab, click Add, then select Internal Buffer (or another logging destination). Set the logging level to Debugging.


    Add Logging Filter page with options to add a logging filter and configure the logging level

    When logging is enabled, you can enable IKEv2 debug, SSH to FTD. Then enter type debug crypto ikev2 platform and debug crypto ikev2 protocol. These two debugging options provide detailed information about IKEv2 negotiation.


    Cisco Firepower Threat Defense (FTD) SSH displaying commands to retrieve detailed IKEv2 negotiation messages

  4. After enabling debugging in the FTD device, return to Cisco Secure Firewall Management Center and navigate to Devices > VPN > Troubleshooting. IKEv2 negotiation debugging information is available.

    If debug destination internal buffer was configured, going back to the FTD device via SSH is also possible. This enables you to see debug messages in the FTD terminal.


    Cisco Firepower Threat Defense (FTD) SSH displaying the command to view debug messages after configuring the debug destination internal buffer

    To access the LINE portion of the code, enter the command system support diagnostic-cli.


    Cisco Firepower Threat Defense (FTD) SSH displaying the command to access the LINE portion of the code