Site-to-Site VPNs

About Site-to-Site VPN

Firepower Threat Defense site-to-site VPN supports the following features:

  • Both IPsec IKEv1 & IKEv2 protocols.

  • Certificates and automatic or manual preshared keys for authentication.

  • IPv4 & 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.

  • HA environments for both FMC and FTD.

  • VPN alerts when the tunnel goes down.

  • Tunnel statistics available using the FTD Unified CLI.

  • KEv1 and IKEv2 back-up peer configuration for point-to-point extranet and hub-and-spoke VPNs.

  • Extranet device as hub in 'Hub and Spokes' deployments.

  • Dynamic IP address for a managed endpoint pairing with extranet device in 'Point to Point' deployments.

  • Dynamic IP address for extranet device as an endpoint.

  • Hub as extranet in 'Hub and Spokes' deployments.

VPN Topology

To create a new site-to-site VPN topology you must, specify a unique name, a topology type, choose the IKE version that is used for IPsec IKEv1 or IKEv2, or both. Also, determine your authentication method. Once configured, you deploy the topology to FTD devices. The Firepower Management Center configures site-to-site VPNs on FTD devices only.

You can select from three types of topologies, containing one or more VPN tunnels:

  • Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.

  • Hub and Spoke deployments establish a group of VPN tunnels connecting a hub endpoint to a group of spoke nodes.

  • Full Mesh deployments establish a group of VPN tunnels among a set of endpoints.

IPsec and IKE

In the Firepower Management Center, 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

For authentication of VPN connections, configure a preshared key in the topology, or a trustpoint on each device. Preshared keys allow for a secret key, used during the IKE authentication phase, to be shared between two peers. A trustpoint includes the identity of the CA, CA-specific parameters, and an association with a single enrolled identity certificate.

Extranet Devices

Each topology type can include extranet devices, devices that you don’t manage in FMC. These include:

  • Cisco devices that Firepower Management Center supports, but for which your organization isn’t responsible. Such as spokes in networks managed by other organizations within your company, or a connection to a service provider or partner's network.

  • Non-Cisco devices. You can’t use Firepower Management Center to create and deploy configurations to non-Cisco devices.

Add non-Cisco devices, or Cisco devices not managed by the Firepower Management Center, to a VPN topology as "Extranet" devices. Also specify the IP address of each remote device.

Firepower Threat Defense Site-to-site VPN Guidelines and Limitations

  • Site-to-site VPN supports ECMP zone interfaces.

  • You must configure all nodes in a topology with either crypto ACL or a protected network. You cannot configure a topology with crypto ACL on one node and protected network on another.

  • You can configure a VPN connection across domains by using an extranet peer for the endpoint not in the current domain.

  • You can backup FTD VPNs using the FMC backup.

  • IKEv1 does not support CC/UCAPL-compliant devices. We recommend that you use IKEv2 for these devices.

  • You cannot move a VPN topology between domains.

  • VPN does not support network objects with a 'range' option.

  • FTD VPNs do not currently support PDF export and policy comparison.

  • There is no per-tunnel or per-device edit option for FTD VPNs, you can edit only the whole topology.

  • The FMC does not verify the device interface address verification for transport mode when you select a crypto ACL.

  • There is no support for automatic mirror ACE generation. Mirror ACE generation for the peer is a manual process on either side.

  • With crypto ACL, the FMC supports only point to point VPN and does not support tunnel health events.

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

  • Tunnel status is not updated in realtime, but at an interval of five minutes in the FMC.

  • You cannot use the character " (double quote) as part of pre-shared keys. If you have used " in a pre-shared key, ensure that you change the character.

Types of Site-to-Site VPN Topologies

Site-to-Site VPN Topology

Description

More Information

Route-Based VPN

Configure secure traffic dynamically between peers in a network based on routing over Virtual Tunnel Interfaces (VTIs).

Create a Route-based Site-to-Site VPN

Policy-Based VPN

Configure secure traffic between peers in a network based on a static policy using protected networks.

Configure a Policy-based Site-to-Site VPN

Requirements and Prerequisites for Site-to-Site VPN

Model Support

FTD

Supported Domains

Leaf

User Roles

Admin

Supported Interfaces

Topology Type

Interface Type

Policy-Based

  • Physical interfaces

    • Non-management

    • Interface Mode must be either Routed or None

  • Subinterface interfaces

  • Redundant interfaces

  • Etherchannel interfaces

  • VLAN interfaces

Route-Based

Static Virtual Tunnel Interfaces

Manage Site to Site VPNs

The Site to Site VPN page provides a snapshot of site to site VPN tunnels. You can view the status of the tunnels and filter the tunnels based on the device, topology, or tunnel type. The page lists 20 topologies per page and you can navigate between pages to view more topology details. You can click individual VPN topologies to expand and view details of the endpoints.

Before you begin

For certificate authentication of your site to site VPNs, you must prepare the devices by allocating trustpoints as described in Certificates.

Procedure


Select Devices > VPN > Site To Site to manage your Firepower Threat Defense Site-to-site VPN configurations and deployments.

Choose from the following:

  • Add—To create a new VPN topology, click Add (add icon) Add VPN > Firepower Threat Defense Device, and continue as instructed in Configure a Policy-based Site-to-Site VPN:

    Note

     

    VPNs topologies can be created only on leaf domains.

  • Edit—Modify the settings of an existing VPN topology.

    Note

     

    You cannot edit the topology type after you initially save it. To change the topology type, delete the topology and create a new one.

    Two users shouldn’t edit the same topology simultaneously; however, the web interface doesn’t prevent simultaneous editing.

  • Delete—To delete a VPN deployment, click Delete (delete icon).

  • View VPN status—This status applies to Firepower VPNs ONLY. Currently, no status is displayed for FTD VPNs. To determine the status of the FTD VPNs, see VPN Monitoring and Troubleshooting.

  • Deploy—Choose Deploy > Deployment; see Deploy Configuration Changes.

    Note

     

    Some VPN settings are validated only during deployment. Be sure to verify that your deployment was successful.


Configure a Policy-based Site-to-Site VPN

Procedure


Step 1

Choose Devices > VPN > Site To Site.Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN Topology.

Step 2

Enter a unique Topology Name. We recommend naming your topology to indicate that it is a FTD VPN, and its topology type.

Step 3

Click Policy Based (Crypto Map) to configure a site-to-site VPN.

Step 4

Choose the Network Topology for this VPN.

Step 5

Choose the IKE versions to use during IKE negotiations. IKEv1 or IKEv2.

Default is IKEv2. Select either or both options as appropriate; select IKEv1 if any device in the topology doesn’t support IKEv2.

You can also configure a backup peer for point-to-point extranet VPNs. For more information, see FTD VPN Endpoint Options.

Step 6

Add Endpoints for this VPN deployment by clicking Add (add icon) for each node in the topology.

Configure each endpoint field as described in FTD VPN Endpoint Options.

  • For Point to point, configure Node A and Node B.

  • For Hub and Spoke, configure a Hub Node and Spoke Nodes

  • For Full Mesh, configure multiple Nodes

Step 7

(Optional) Specify non-default IKE options for this deployment as described in FTD VPN IKE Options

Step 8

(Optional) Specify non-default IPsec options for this deployment as described in FTD VPN IPsec Options

Step 9

(Optional) Specify non-default Advanced options for this deployment as described in FTD Advanced Site-to-site VPN Deployment Options.

Step 10

Click Save.

The endpoints are added to your configuration.

What to do next

Deploy configuration changes; see Deploy Configuration Changes.


Note


Some VPN settings are validated only during deployment. Be sure to verify that your deployment was successful.

If you get an alert that your VPN tunnel is inactive even when the VPN session is up, follow the VPN troubleshooting instructions to verify and ensure that your VPN is active. For more information, see VPN Monitoring and Troubleshooting and VPN Troubleshooting.


FTD VPN Endpoint Options

Navigation Path

Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN Topology. Open the Endpoint tab.

Fields

Device

Choose an endpoint node for your deployment:

  • A FTD device managed by this FMC

  • A FTD high availability container managed by this FMC

  • An Extranet device, any device (Cisco or third party) not managed by this FMC.

Device Name
For extranet devices only, provide a name for this device. We recommend naming it such that it is identifiable as an unmanaged device.
Interface

If you chose a managed device as your endpoint, choose an interface on that managed device.

For 'Point to Point' deployments, you can also configure an endpoint with dynamic interface. An endpoint with a dynamic interface can pair only with an extranet device and can’t pair with an endpoint, which has a managed device.

You can configure device interfaces at Devices > Device Management > Add/Edit device > Interfaces.

IP Address
  • If you choose an extranet device, a device not managed by the FMC, specify an IP address for the endpoint.

    For an extranet device, select Static and specify an IP address or select Dynamic to allow dynamic extranet devices.

    If you have chosen point-to-point topology and either IKEv1 or IKEv2, you can configure backup peers by entering the primary and backup peer IP addresses separated by a comma.

  • If you chose a managed device as an endpoint, choose a single IPv4 address or multiple IPv6 addresses from the drop-down list. These IP addresses are already assigned to this interface on the managed device.

  • All endpoints in a topology must have the same IP addressing scheme. IPv4 tunnels can carry IPv6 traffic and vice versa. The Protected Networks define which addressing scheme the tunneled traffic uses.

  • If the managed device is a high-availability container, choose from a list of interfaces.

This IP is Private

Check the check box if the endpoint resides behind a firewall with network address translation (NAT).


Note


Use this option only when the peer is managed by the same FMC and don’t use this option if the peer is an extranet device.


Public IP address

If you checked the This IP is Private check box, specify a public IP address for the firewall. If the endpoint is a responder, specify this value.

Connection Type

Specify the allowed negotiation as bidirectional, answer-only, or originate-only. Supported combinations for the connection type are:

Table 1. Connection Type Supported Combinations

Remote Node

Central Node

Originate-Only

Answer-Only

Bi-Directional

Answer-Only

Bi-Directional

Bi-Directional

Certificate Map

Choose a preconfigured certificate map object, or click Add (add icon) to add a certificate map object. The certificate map defines what information is necessary in the received client certificate to be valid for VPN connectivity. See Certificate Map Objects for details.

Protected Networks

Caution


Hub and Spoke topology—To avoid traffic drop for a dynamic crypto map, ensure that you don’t select the protected network any for both the endpoints.

If the protected network is configured as any, on both the endpoints, the crypto ACL that works upon the tunnel is not generated.


Defines the networks that are protected by this VPN endpoint. Select the networks by selecting the list of Subnet/IP Address that define the networks that are protected by this endpoint. Click Add (add icon) to select from available Network Objects or add new Network Objects. See Creating Network Objects. Access control lists are generated from the choices made here.

  • Subnet/IP Address (Network)—VPN endpoints can’t have the same IP address and protected networks in a VPN endpoint pair cannot overlap. If protected networks for an endpoint contain IPv4 or IPv6 entries, the other endpoint's protected network must have at least one entry of the same type (IPv4 or IPv6). If it doesn’t, the other endpoint's IP address must be of the same type and not overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128 CIDR address blocks for IPv6.) If both of these checks fail, the endpoint pair is invalid.


    Note


    By default, Reverse Route Injection is enabled is enabled in Firepower Management Center.

    Subnet/IP Address (Network) remains the default selection.

    When you’ve selected Protected Networks as Any and observe default route traffic being dropped, disable the Reverse Route Injection. Choose VPN> Site to Site > edit a VPN > IPsec > Enable Reverse Route Injection. Deploy the configuration changes to remove set reverse-route (Reverse Route Injection) from the crypto map configuration and remove the VPN-advertised reverse route that causes the reverse tunnel traffic to be dropped.


  • Access List (Extended)—An extended access list provides the capability to control the type of traffic that will be accepted by this endpoint, like GRE or OSPF traffic. Traffic may be restricted either by address or port. Click Add (add icon) to add access control list objects.


    Note


    Access Control List is supported only in the point to point topology.
Advanced Settings
Enable Dynamic Reverse Route Injection—Reverse Route Injection (RRI) enables routes to be automatically inserted into the routing process, for the networks and hosts protected by a remote tunnel endpoint. Dynamic RRI routes are created only upon the successful establishment of IPsec security associations (SA’s).

Note


  • Dynamic RRI is supported only on IKEv2, and not supported on IKEv1 or IKEv1 + IKEv2.

  • Dynamic RRI isn’t supported on originate-only peer, Full Mesh topology, and Extranet peer.

  • In Point-to-Point, only one peer can have dynamic RRI enabled.

  • Between Hub and Spoke, only one of the endpoints can have dynamic RRI enabled.

  • Dynamic RRI cannot be combined with a dynamic crypto map.


Send Local Identity to Peers—Select this option to send local identity information to the peer device. Select one of the following Local Identity Configuration from the list and configure the local identity:
  • IP address—Use the IP address of the interface for the identity.

  • Auto—Use the IP address for pre-shared key and Cert DN for certificate-based connections.

  • Email ID—Specify the email ID to use for the identity. The email ID can be up to 127 characters.

  • Hostname—Use the fully qualified hostname.

  • Key ID—Specify the key-id to use for the identity. The key ID must be fewer than 65 characters.

The local identity is used to configure a unique identity per IKEv2 tunnel, instead of a global identity for all the tunnels. The unique identity allows FTD to have multiple IPsec tunnels behind a NAT to connect to the Cisco Umbrella Secure Internet Gateway (SIG).

For information about configuring a unique tunnel ID on Umbrella, see Cisco Umbrella SIG User Guide.

VPN Filter—Select an extended access list from the list or click Add to create a new extended access list object to filter the site-to-site VPN traffic.

The VPN filter provides more security and filters site-to-site VPN data using an extended access list. The extended access list object selected for the VPN filter lets you filter pre-encrypted traffic before entering the VPN tunnel and decrypted traffic that exits a VPN tunnel. The sysopt permit-vpn option, when enabled, would bypass the access control policy rules for the traffic coming from the VPN tunnel. When the sysopt permit-vpn option is enabled, the VPN filter helps in identifying and filtering the site-to-site VPN traffic.


Note


The VPN filter is supported only on Point to Point, and Hub and Spoke topologies. It isn’t supported on Mesh topology.


For Hub and Spoke topology, you can choose to override the hub VPN filter on the spoke endpoints in case a different VPN filter needs to enabled on a specific tunnel.

Select the Override VPN Filter on the Hub option to override the hub VPN filter on the spokes. Select the Remote VPN Filter extended access list object or create an access list to override.


Note


For an extranet device as a spoke, only the Override VPN filter on the Hub option is available.


For more information about sysopt permit-VPN, see FTD Advanced Site-to-site VPN Tunnel Options.

FTD VPN IKE Options

For the versions of IKE you have chosen for this topology, specify the IKEv1/IKEv2 Settings.


Note


Settings in this dialog apply to the entire topology, all tunnels, and all managed devices.


Navigation Path

Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN Topology. Open the IKE tab.

Fields

Policy
Choose the required IKEv1 or IKEv2 policy objects from the predefined list or create new objects to use. You can choose multiple IKEv1 and IKEv2 policies. IKEv1 and IKEv2 support a maximum of 20 IKE policies, each with a different set of values. Assign a unique priority to each policy that you create. The lower the priority number, the higher the priority.
For details, see FTD IKE Policies
Authentication Type

Site-to-site VPN supports two authentication methods, pre-shared key and certificate. For an explanation of the two methods, see Deciding Which Authentication Method to Use.


Note


In a VPN topology that supports IKEv1, the Authentication Method specified in the chosen IKEv1 Policy object becomes the default in the IKEv1 Authentication Type setting. These values must match, otherwise, your configuration will error.


  • Pre-shared Automatic Key—The FMC automatically defines the pre-shared key for this VPN. Specify the Pre-shared Key Length, the number of characters in the key, 1-27.

    The character " (double quote) isn’t supported as part of pre-shared keys. If you’ve used " in a pre-shared key, ensure that you change the character after you upgrade to Firepower Threat Defense 6.30 or higher.

  • Pre-shared Manual Key—Manually assign the pre-shared key for this VPN. Specify the Key and then reenter the same to Confirm Key.

    When you choose this option for IKEv2, the Enforce hex-based pre-shared key only check box appears, check if desired. If enforced, you must enter a valid hex value for the key, an even number of 2-256 characters, using numerals 0-9, or A-F.

  • Certificate—When you use certificates as the authentication method for VPN connections, peers obtain digital certificates from a CA server in your PKI infrastructure, and trade them to authenticate each other.

    In the Certificate field, select a preconfigured certificate enrollment object. This enrollment object generates a trustpoint with the same name on the managed device. The certificate enrollment object should be associated with and installed on the device, post which the enrollment process is complete, and then a trustpoint is created.

    A trustpoint is a representation of a CA or identity pair. A trustpoint includes the identity of the CA, CA-specific configuration parameters, and an association with one enrolled identity certificate.

    Before you select this option, note the following:

    • Ensure you’ve enrolled a certificate enrollment object on all the endpoints in the topology—A certificate enrollment object contains the Certification Authority (CA) server information and enrollment parameters that are required for creating Certificate Signing Requests (CSRs) and obtaining Identity Certificates from the specified CA. Certificate Enrollment Objects are used to enroll your managed devices into your PKI infrastructure, and create trustpoints (CA objects) on devices that support VPN connections. For instructions on creating a certificate enrollment object, see Adding Certificate Enrollment Objects, and for instructions on enrolling the object on the endpoints see one of the following as applicable:


      Note


      For a site-to-site VPN topology, ensure that the same certificate enrollment object is enrolled in all the endpoints in the topology. For further details, see the table below.


    • Refer the following table to understand the enrollment requirement for different scenarios. Some of the scenarios require you to override the certificate enrollment object for specific devices. See Managing Object Overrides to understand how to override objects.

      Certificate Enrollment Types

      Device identity certificate for all endpoints is from the same CA

      Device identity certificate for all endpoints is from different CAs

      Device-specific parameters are NOT specified in the certificate enrollment object

      Device-specific parameters are specified in the certificate enrollment object

      Manual

      No override required

      Override required

      Override required

      EST

      No override required

      Override required

      Override required

      SCEP

      No override required

      Override required

      Override required

      PKCS

      Override required

      Override required

      Override required

      Self-signed

      Not applicable

      Not applicable

      Not applicable

    • Understand the VPN certificate limitations mentioned in Firepower Threat Defense VPN Certificate Guidelines and Limitations.


    Note


    If you use a Windows Certificate Authority (CA), the default application policies extension is IP security IKE intermediate. If you use this default setting, you must select the Ignore IPsec Key Usage option in the Advanced Settings section on the Key tab in the PKI Certificate Enrollment dialog box for the object you select. Otherwise, the endpoints can’t complete the site-to-site VPN connection.


FTD VPN IPsec Options


Note


Settings in this dialog apply to the entire topology, all tunnels, and all managed devices.


Crypto-Map Type
A crypto map combines all the components required to set up IPsec security associations (SA). When two peers try to establish an SA, they must each have at least one compatible crypto map entry. The IPsec security negotiation uses the proposals defined in the crypto map entry to protect the data flows specified by that crypto map’s IPsec rules. Choose static or dynamic for this deployment's crypto-map:
  • Static—Use a static crypto map in a point-to-point or full mesh VPN topology.

  • DynamicDynamic crypto-maps essentially create a crypto map entry without all the parameters configured. The missing parameters are later dynamically configured (as the result of an IPsec negotiation) to match a remote peer’s requirements.

    Dynamic crypto map policies are applicable to both hub-and-spoke and point-to-point VPN topologies. To apply these policies, specify a dynamic IP address for one of the peers in the topology and ensure that the dynamic crypto-map is enabled on this topology. In a full mesh VPN topology, you can apply only static crypto map policies.

IKEv2 Mode

For IPsec IKEv2 only, specify the encapsulation mode for applying ESP encryption and authentication to the tunnel. This determines what part of the original IP packet has ESP applied.

  • Tunnel mode—(default) Encapsulation mode is set to tunnel mode. Tunnel mode applies ESP encryption and authentication to the entire original IP packet (IP header and data), hiding the ultimate source and destination addresses and becoming the payload in a new IP packet.

    The major advantage of tunnel mode is that you don’t need to modify the end systems to receive the benefits of IPsec. This mode allows a network device, such as a router, to act as an IPsec proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts packets and forwards them along the IPsec tunnel. The destination router decrypts the original IP datagram and forwards it onto the destination system. Tunnel mode also protects against traffic analysis; with tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.

  • Transport preferred—Encapsulation mode is set to transport mode with an option to fall back to tunnel mode if the peer doesn’t support it. In transport mode only the IP payload is encrypted, and the original IP headers are left intact. Therefore, the admin must select a protected network that matches the VPN interface IP address.

    This mode has the advantages of adding only a few bytes to each packet and allowing devices on the public network to see the final source and destination of the packet. With transport mode, you can enable special processing (for example, QoS) on the intermediate network based on the information in the IP header. However, the layer 4 header is encrypted, which limits examination of the packet.

  • Transport required— Encapsulation mode is set to transport mode only, falling back to tunnel mode is allowed. If the endpoints can’t successfully negotiate transport mode, due to one endpoint not supporting it, the VPN connection is not made.

Proposals
Click Edit (edit icon) to specify the proposals for your chosen IKEv1 or IKEv2 method. Select from the available IKEv1 IPsec Proposals or IKEv2 IPsec Proposals objects, or create and then select a new one. See Configure IKEv1 IPsec Proposal Objects and Configure IKEv2 IPsec Proposal Objects for details.
Enable Security Association (SA) Strength Enforcement

Enabling this option ensures that the encryption algorithm used by the child IPsec SA isn’t stronger (in terms of the number of bits in the key) than the parent IKE SA.

Enable Reverse Route Injection
Reverse Route Injection (RRI) enables static routes to be automatically inserted into the routing process for those networks and hosts protected by a remote tunnel endpoint.
Enable Perfect Forward Secrecy
Whether to use Perfect Forward Secrecy (PFS) to generate and use a unique session key for each encrypted exchange. The unique session key protects the exchange from subsequent decryption, even if the entire exchange was recorded and the attacker has obtained the preshared or private keys used by the endpoint devices. If you select this option, also select the Diffie-Hellman key derivation algorithm to use when generating the PFS session key in the Modulus Group list.
Modulus 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 a full explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use.
Lifetime Duration
The number of seconds a security association exists before expiring. The default is 28,800 seconds.
Lifetime Size
The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association before it expires. The default is 4,608,000 kilobytes. Infinite data isn’t allowed.
ESPv3 Settings
Validate incoming ICMP error messages
Choose whether to validate ICMP error messages received through an IPsec tunnel and destined for an interior host on the private network.
Enable 'Do Not Fragment' Policy
Define how the IPsec subsystem handles large packets that have the do-not-fragment (DF) bit set in the IP header.
Policy
  • Copy DF bit—Maintains the DF bit.

  • Clear DF bit—Ignores the DF bit.

  • Set DF bit—Sets and uses the DF bit.

Enable Traffic Flow Confidentiality (TFC) Packets
Enable dummy TFC packets that mask the traffic profile which traverses the tunnel. Use the Burst, Payload Size, and Timeout parameters to generate random length packets at random intervals across the specified SA.

Note


You can enable dummy Traffic Flow Confidentiality (TFC) packets at random lengths and intervals on an IPsec security association (SA). You must have an IKEv2 IPsec proposal set before enabling TFC.

Enabling TFC packets prevents the VPN tunnel from being idle. Thus the VPN idle timeout configured in the group policy doesn’t work as expected when you enable the TFC packets.


FTD Advanced Site-to-site VPN Deployment Options

The following sections describe the advanced options you can specify in your site-to-site VPN deployment. These settings apply to the entire topology, all tunnels, and all managed devices.

FTD VPN Advanced IKE Options

Advanced > IKE > ISAKAMP Settings
IKE Keepalive

Enable or disables IKE Keepalives. You can set this option to EnableInfinite so that the device never starts the keepalive monitoring itself.

Threshold
Specifies the IKE keep alive confidence interval. This interval is the number of seconds allowing a peer to idle before beginning keepalive monitoring. The minimum and default interval is 10 seconds; the maximum interval is 3600 seconds.
Retry Interval
Specifies number of seconds to wait between IKE keep alive retries. The default is 2 seconds, the maximum is 10 seconds.
Identity Sent to Peers:
Choose the identity that the peers will use to identify themselves during IKE negotiations:
  • autoOrDN(default)—Determines IKE negotiation by connection type: IP address for preshared key, or Cert DN for certificate authentication (not supported).

  • ipAddress—Uses the IP addresses of the hosts exchanging ISAKMP identity information.

  • hostname—Uses the fully qualified domain name of the hosts exchanging ISAKMP identity information. This name comprises the hostname and the domain name.


Note


Enable or disable this option for all your VPN connections.


Enable Aggressive Mode
Select this negotiation method for exchanging key information if the IP address isn’t known and DNS resolution might not be available on the devices. Negotiation is based on hostname and domain name.
Enable Notification on Tunnel Disconnect
Allows an administrator to enable or disable the sending of an IKE notification to the peer when an inbound packet that is received on an SA does not match the traffic selectors for that SA. This notification is disabled by default.
Advanced > IKE > IVEv2 Security Association (SA) Settings

More session controls are available for IKE v2 that limit the number of open SAs. By default, there’s no limit to the number of open SAs.

Cookie Challenge
Whether to send cookie challenges to peer devices in response to SA initiate packets, which can help thwart denial of service (DoS) attacks. The default is to use cookie challenges when 50% of the available SAs are in negotiation. Select one of these options:
  • Custom

  • Never (default)

  • Always

Threshold to Challenge Incoming Cookies
The percentage of the total allowed SAs that are in-negotiation. This triggers cookie challenges for any future SA negotiations. The range is zero to 100%.
Number of SAs Allowed in Negotiation
Limits the maximum number of SAs that can be in negotiation at any time. If used with Cookie Challenge, configure the cookie challenge threshold lower than this limit for an effective cross-check.
Maximum number of SAs Allowed
Limits the number of allowed IKEv2 connections. Default is unlimited.
Enable Notification on Tunnel Disconnect
Allows an administrator to enable or disable the sending of an IKE notification to the peer when an inbound packet that is received on an SA doesn’t match the traffic selectors for that SA. Sending this notification is disabled by default.

FTD VPN Advanced IPsec Options

Advanced > IPsec > IPsec Settings
Enable Fragmentation Before Encryption
This option lets traffic travel across NAT devices that don’t support IP fragmentation. It doesn’t impede the operation of NAT devices that do support IP fragmentation.
Path Maximum Transmission Unit Aging
Check to enable Path Maximum Transmission Unit (PMTU) Aging, the interval to reset the PMTU of a Security Association (SA).
Value Reset Interval
Enter the number of minutes at which the PMTU value of an SA is reset to its original value. Valid range is 10 to 30 minutes, default is unlimited.

FTD Advanced Site-to-site VPN Tunnel Options

Navigation Path

Devices > VPN > Site To Site, then select Add VPN > Firepower Threat Defense Device, or edit a listed VPN Topology. Open the Advanced tab, and select Tunnel in the navigation pane.

Tunnel Options

Only available for Hub and Spoke, and Full Mesh topologies. This section doesn’t appear for Point to Point configurations.

  • Enable Spoke to Spoke Connectivity through Hub—Disabled by default. Choosing this field enables the devices on each end of the spokes to extend their connection through the hub node to the other device.

NAT Settings
  • Keepalive Messages Traversal —Elect whether to enable NAT keepalive message traversal. NAT traversal keepalive is used for the transmission of keepalive messages when there’s a device (middle device) located between a VPN-connected hub and spoke, and that device performs NAT on the IPsec flow.

    If you select this option, configure the Interval, in seconds, between the keepalive signals sent between the spoke and the middle device to indicate that the session is active. The value can be from 5 to 3600 seconds. The default is 20 seconds.

Access Control for VPN Traffic
  • Bypass Access Control policy for decrypted traffic (sysopt permit-vpn)—By default, the FTD applies access control policy inspection on the decrypted traffic. Enable this option to bypass the ACL inspection. The FTD still applies the VPN Filter ACL and authorization ACL downloaded from the AAA server to the VPN traffic.

    Enable or disable the option for all your VPN connections. If you disable this option, ensure that the traffic is allowed by the access control policy or prefilter policy.

Certificate Map Settings
  • Use the certificate map configured in the Endpoints to determine the tunnel—If this option is enabled (checked), the tunnel is determined by matching the contents of the received certificate to the certificate map objects configured in the endpoint nodes.

  • Use the certificate OU field to determine the tunnel—Indicates that if a node isn’t determined based on the configured mapping (the above option) if selected, then use the value of the organizational unit (OU) in the subject distinguished name (DN) of the received certificate to determine the tunnel.

  • Use the IKE identity to determine the tunnel—Indicates that if a node isn’t determined based on a rule matching or taken from the OU (the above options) if selected, then the certificate-based IKE sessions are mapped to a tunnel based on the content of the phase1 IKE ID.

  • Use the peer IP address to determine the tunnel—Indicates that if a tunnel isn’t determined based on a rule matching or taken from the OU or IKE ID methods (the above options) if selected, then use the established peer IP address.

About Virtual Tunnel Interfaces

FMC supports a routable logical interface called the Virtual Tunnel Interface (VTI). VTIs do not require a static mapping of IPsec sessions to a physical interface. The IPsec tunnel endpoint is associated with a virtual interface. You can use these interfaces like other interfaces and apply static and dynamic routing policies.

As an alternative to policy-based VPN, you can create a VPN tunnel between peers using VTIs. VTIs support route-based VPN with IPsec profiles attached to the end of each tunnel. VTIs use static or dynamic routes. The device encrypts or decrypts the traffic from or to the tunnel interface and forwards it according to the routing table. Deployments become easier, and having VTI which supports route-based VPN with dynamic routing protocol also satisfies many requirements of a virtual private cloud. FMC enables you to easily migrate from crypto-map based VPN configuration to VTI-based VPN.

You can configure route-based VPN with static VTI using the site-to-site VPN wizard. Traffic is encrypted using static route or BGP.

You can create a routed security zone, add VTI interfaces to it, and define access control rules for the decrypted traffic control over the VTI tunnel.

You can create VTI-based VPNs between:

  • Two FTD devices.

  • A FTD and public cloud.

  • One FTD and another FTD with service provider redundancy.

  • A FTD and any other device with VTI interfaces.

  • A FTD and another device with policy-based VPN configuration.

For more information, see Static VTI .

Static VTI

Static VTI uses tunnel interfaces to create a tunnel that is always-on between two sites. You must define a physical interface as a tunnel source for a static VTI. You can associate a maximum of 1024 VTIs per device. To create a static VTI interface in the management center, see Add a VTI Interface.

The figure below shows a VPN topology using static VTIs.

On Threat Defense 1:

  • Static VTI IP address is 192.168.10.1

  • Tunnel source is 10.0.149.220

  • Tunnel destination is 10.0.149.221

On Threat Defense 2:

  • Static VTI IP address is 192.168.10.2

  • Tunnel source is 10.0.149.221

  • Tunnel destination is 10.0.149.220

Benefits

  • Minimizes and simplifies configuration.

    You do not have to track all remote subnets for a crypto map access list, and configure complex access lists or crypto maps.

  • Provides a routable interface.

    Supports IP routing protocols such as BGP, and static routes.

  • Supports backup VPN tunnels

  • Supports load balancing using ECMP.

  • Supports virtual routers.

  • Provides differential access control for VPN traffic.

    You can configure a VTI with a security zone and use it in an AC policy. This configuration:

    • Allows you to classify and differentiate VPN traffic from clear-text traffic and permit VPN traffic selectively.

    • Provides differential access-control for VPN traffic across different VPN tunnels.

Guidelines and Limitations for Virtual Tunnel Interfaces

IPv6 Support

  • VTI supports IPv6.

  • You can use an IPv6 address for the tunnel source interface and use the same address as the tunnel endpoint.

  • The FMC supports the following combinations of VTI IP (or internal networks IP version) over public IP versions:

    • IPv6 over IPv6

    • IPv4 over IPv6

    • IPv4 over IPv4

    • IPv6 over IPv4

  • VTI supports static and dynamic IPv6 addresses as the tunnel source and destination.

  • The tunnel source interface can have IPv6 addresses and you can specify the tunnel endpoint address. If you don’t specify the address, by default, the FTD uses the first IPv6 global address in the list as the tunnel endpoint.

BGP IPv6 Support

VTI supports IPv6 BGP.

Multi-instance and Clustering

  • VTI is supported in multi-instance.

  • VTIs aren’t supported with clustering.

Firewall Mode

VTI is supported in routed mode only.

Limitations for Static VTI

  • Only 20 unique IPSec profiles are supported.

  • Dynamic VTI, OSPF, and QoS aren’t supported.

  • Site-to-site VPN tunnels created with VTIs don’t generate health alerts when the tunnel goes down. If you experience packet loss over a VPN with VTIs, check your VPN configuration.

  • In policy-based routing, you can configure VTI only as an egress interface.

General Configuration Guidelines for Static VTI

  • VTIs are only configurable in IPsec mode.

  • You can use BGP or static routes for traffic using the tunnel interface.

  • In an HA configuration with dynamic routing, the standby device cannot access the known subnets through the VTI tunnels as these tunnels are created with the active IP address.

  • You can configure a maximum of 1024 static VTIs on a device. While calculating the VTI count, consider the following:

    • Include nameif subinterfaces to derive the total number of VTIs that can be configured on the device.

    • You can’t configure nameif on the member interfaces of a portchannel. Therefore, the tunnel count is reduced by the count of actual main portchannel interfaces alone and not any of its member interfaces.

    • The VTI count on a platform is limited to the number of VLANs configurable on that platform. For example, Firepower 1120 supports 512 VLANs, the tunnel count is 512 minus the number of physical interfaces configured.

  • If you’re configuring more than 400 VTIs on a device in a high-availability setup, you must configure 45 seconds as the unit holdtime for the FTD HA.

  • The MTU for VTIs is automatically set, according to the underlying physical interface.

  • Static VTI supports IKE versions v1, v2, and uses IPsec for sending and receiving data between the tunnel's source and destination.

  • If NAT has to be applied, the IKE and ESP packets are encapsulated in the UDP header.

  • IKE and IPsec security associations are 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 sends as its IKEv1 or IKEv2 identity.

  • For IKEv1 in LAN-to-LAN tunnel groups, you can use names which aren’t 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 coexist on the same physical interface, if the peer address configured in the crypto map and the tunnel destination for the VTI are different.

  • By default, all traffic sent through a VTI is encrypted.

  • Access rules can be applied on a VTI interface to control traffic through VTI.

  • You can associate VTI interfaces with ECMP zones and configure ECMP static routes to achieve the following:

    • Load balancing (Active/Active VTIs)—Connection can flow over any of the parallel VTI tunnels.

    • Seamless connection migration—When a VTI tunnel becomes unreachable, the flows are seamlessly migrated to another VTI interface that is configured in the same zone.

    • Asymmetric routing—Forward traffic flow through one VTI interface and configure the reverse traffic flow through another VTI interface.

    For information on configuring ECMP, see Configure an Equal Cost Static Route.

Backup VTI Guidelines and Limitations

  • Flow resiliency across tunnel failovers isn’t supported. For example, the clear text TCP connection gets lost after a tunnel failover, and you need to reinitiate any FTP transfer that took place during the failover.

  • Certificate authentication isn’t supported in backup VTI.

Add a VTI Interface

For configuring a route-based site-to-site VPN, you must create a VTI interface on the devices at both the nodes of the VTI tunnel.

Procedure


Step 1

Choose Devices > Device Management.

Step 2

Click the Edit icon next to the device on which you want to create a VTI interface.

Step 3

Choose Add Interfaces > Virtual Tunnel Interface.

Step 4

Enter the name and description for the interface. By default, the interface is enabled.

Ensure that you specify a name that is not longer than 28 characters.

Step 5

(Optional) Choose a security zone from the Security Zone drop-down list to add the static VTI interface to that zone.

If you want to perform traffic inspection based on a security zone, add the VTI interface to the security zone and configure an access control (AC) rule. To permit the VPN traffic over the tunnel, you need to add an AC rule with this security zone as the source zone.

Step 6

Enter the priority to load balance the traffic across multiple VTIs in the Priority field.

The range is from 0 to 65535. The lowest number has the highest priority. This option is not applicable for dynamic VTI.

Step 7

For a static VTI, enter a unique tunnel ID in the range of 0 to 10413 in the Tunnel ID field.

Step 8

Choose the tunnel source interface from the Tunnel Source drop-down list.

The VPN tunnel terminates at this interface, a physical interface. Choose the IP address of the interface from the drop-down list. You can select the IP address irrespective of the IPsec tunnel mode. In case of multiple IPv6 addresses, select the address that you want to use as the tunnel endpoint.

Step 9

Under IPSec Tunnel Mode, click the IPv4 or IPv6 radio button to specify the traffic type over the IPsec tunnel.

Step 10

In the IP Address field, enter the IP address and subnet to use for the tunnel endpoint. The VTI IP addresses of both endpoints of a route-based VPN must be in the same subnet.

Note

 

We recommend that you use an IP from 169.254.x.x/16 range excluding the FTD reserved range (169.254.1.x/24). Also, use /30 as net-mask to optimally use only two addresses for the two ends of the VTI tunnel. For example, 169.254.100.1/30.

Step 11

Click OK.

Step 12

Click Save.


Create a Route-based Site-to-Site VPN

You can configure a route-based site-to-site VPN between two nodes. To configure a VTI-based VPN you need VTIs at both the nodes of the tunnel.

For more information on VTI, see About Virtual Tunnel Interfaces.

Procedure


Step 1

Choose Devices > Site To Site.

Step 2

In the Add VPN drop-down menu, choose Firepower Threat Defense Device.

Step 3

Choose Add.

Step 4

Enter a name for the VPN topology in the Topology Name field.

Step 5

Choose Route Based (VTI) as the topology type. By default, the network topology is point-to-point and the IKE protocol is selected for the site-to-site configuration. For more information, see Configure Endpoints for a Point to Point Topology.

Step 6

(Optional) Specify the IKE options for the deployment as described in FTD VPN IKE Options.

Step 7

(Optional) Specify the IPsec options for the deployment as described in FTD VPN IPsec Options.

Step 8

(Optional) Specify the Advanced options for the deployment as described in FTD Advanced Site-to-site VPN Deployment Options.

Step 9

Click Save.


What to do next

After you configure VTI interfaces and VTI tunnel on both the devices, you must configure:

  • A routing policy to route the VTI traffic between the devices over the VTI tunnel. For more information, see Configure Routing and AC Policies for VTI.

  • An access control rule to allow encrypted traffic. Choose Policies > Access Control.

Configure Endpoints for a Point to Point Topology

Configure the following parameters to configure endpoints for a route-based site-to-site VPN for the Point to Point topology nodes:

Before you begin

Configure the basic parameters for a point-to-point topology in a route-based VPN as described in Create a Route-based Site-to-Site VPN and click the Endpoints tab.

Procedure


Step 1

Under Node A, in the Device drop-down menu, select the name of the registered device (FTD) or extranet as the first endpoint of your VTI tunnel.

For an extranet peer, specify the following parameters:

  1. Specify the name of the device.

  2. Enter the primary IP address in the Endpoint IP address field. If you configure a backup VTI, add a comma and, specify the backup IP address.

  3. Click OK.

After configuring the above parameters for the extranet hub, specify the pre-shared key for the extranet in the IKE tab.

Note

 

The AWS VPC has AES-GCM-NULL-SHA-LATEST as the default policy. If the remote peer connects to AWS VPC, select AES-GCM-NULL-SHA-LATEST from the Policy drop-down list to establish the VPN connection without changing the default value in AWS.

Step 2

For a registered device, you can specify the VTI interface for Node A from the Virtual Tunnel Interface drop-down list.

The selected tunnel interface is the source interface for Node A and the tunnel destination for Node B.

If you want to create a new interface on Node A, click the + icon and configure the fields as described in Add a VTI Interface.

If you want to edit the configuration of an existing VTI, select the VTI in the Virtual Tunnel Interface drop-down field and click Edit VTI.

Step 3

If your Node A device is behind a NAT device, check the Tunnel Source IP is Private check box. In the Tunnel Source Public IP Address field, enter the tunnel source public IP address.

Step 4

Send Local Identity to Peers—Select this option to send local identity information to the peer device. Select one of the following Local Identity Configuration from the list and configure the local identity:

  • IP address—Use the IP address of the interface for the identity.

  • Auto—Use the IP address for pre-shared key and Cert DN for certificate-based connections.

  • Email ID—Specify the email ID to use for the identity. The email ID can be up to 127 characters.

  • Hostname—Use the fully qualified hostname.

  • Key ID—Specify the key-id to use for the identity. The key ID must be fewer than 65 characters.

The local identity is used to configure a unique identity per IKEv2 tunnel, instead of a global identity for all the tunnels. The unique identity allows FTD to have multiple IPsec tunnels behind a NAT to connect to a Cisco Umbrella Secure Internet Gateway (SIG).

For information about configuring a unique tunnel ID on Umbrella, see Cisco Umbrella SIG User Guide.

Step 5

(Optional) Click Add Backup VTI to specify an extra VTI as the backup interface and configure the parameters.

Note

 

Ensure that both peers of the topology do not have the same tunnel source for the backup VTI. A device cannot have two VTIs with the same tunnel source and tunnel destination; hence, configure a unique tunnel source and tunnel destination combination.

Though the virtual tunnel interface is specified under Backup VTI, the routing configuration determines which tunnel to be used as primary or backup.

Step 6

In the Connection Type drop-down menu, select Answer Only or Bidirectional. If you have selected the IKE protocol version as IKEv1, one of the nodes must be Answer Only.

Answer Only: The device can only respond when a peer device initiates a connection, it cannot initiate any connection.

Bidirectional: The device can initiate or respond to a connection. This is the default option.

Step 7

Under Additional Configuration, do the following:

  • To route traffic to the VTI, click Routing Policy. FMC displays the Devices > Routing page.

    You can configure the Static or BGP routing for the VPN traffic.

  • To permit VPN traffic, click AC Policy. FMC displays the access control policy page of the device. Proceed to add an allow/block rule specifying the security zone of the VTI. If you configure a backup VTI, ensure to include the backup tunnel to the same security zone as that of the primary VTI. No specific settings are required for the backup VTI in the AC policy page.

Step 8

Repeat the above procedure for Node B.

Step 9

Click OK.


Configure Endpoints for a Hub and Spoke Topology

Configure the following parameters to configure endpoints for a route-based site-to-site VPN for the Hub and Spoke topology nodes:

Before you begin

Configure the basic parameters for a hub and spoke topology in a route-based VPN as described in Create a Route-based Site-to-Site VPN and click the Endpoints tab.

Procedure


Step 1

Under Node A in the Endpoints tab, in the Device drop-down menu, select the name of the registered device (FTD) or Extranet to be used as the first endpoint of your VTI tunnel.

Step 2

For a registered device, you can specify the interface for Node A:

  • In the Virtual Tunnel Interface drop-down menu, select the VTI interface, which you had created on FTD device that you’ve selected as Node A.

  • If you want to create a new interface on Node A, click the + icon and fill the fields as described in Add a VTI Interface.

  • If you want to edit the configuration of an existing VTI, select the VTI in the Virtual Tunnel Interface drop-down field and click Edit VTI.

    Note

     

    The selected tunnel interface is the source interface for Node A and it becomes the tunnel destination for Node B.

Step 3

If your Node A device is behind a NAT device, check the Tunnel Source IP is Private check box. In the Tunnel Source Public IP Address field, enter the tunnel source public IP address.

Step 4

Send Local Identity to Peers—Select this option to send local identity information to the peer device. Select one of the following Local Identity Configuration from the list and configure the local identity:

  • IP address—Use the IP address of the interface for the identity.

  • Auto—Use the IP address for pre-shared key and Cert DN for certificate-based connections.

  • Email ID—Specify the email ID to use for the identity. The email ID can be up to 127 characters.

  • Hostname—Use the fully qualified hostname.

  • Key ID—Specify the key-id to use for the identity. The key ID must be less than 65 characters.

The local identity is used to configure a unique identity per IKEv2 tunnel, instead of a global identity for all the tunnels. The unique identity allows FTD to have multiple IPsec tunnels behind a NAT to connect to Cisco Umbrella Secure Internet Gateway (SIG).

For information about configuring unique tunnel Id on Umbrella, see Cisco Umbrella SIG User Guide.

Step 5

(Optional) Click Add Backup VTI to specify an additional VTI as the backup interface.

Note

 

Ensure that both peers of the topology do not have backup VTI configured on the same tunnel source. For instance, if Peer A is having 2 VTIs (primary and a backup) configured with a single tunnel source interface, say, 10.10.10.1/30, then Peer B also can’t have its 2 VTIs with a single tunnel source IP, say 20.20.20.1/30.

Note

 

Though the virtual tunnel interface is specified under Backup VTI, the routing configuration determines which tunnel to be used as primary or backup.

You can do the following:

  • To create a new backup interface, use the + icon.

  • To edit the configuration of an existing Backup VTI, use Edit VTI.

Note

 

If your Node A device is behind a NAT device, check the Tunnel Source IP is Private check box. In the Tunnel Source Public IP Address field, enter the tunnel source public IP address.

Step 6

In the Connection Type drop-down menu, select Answer Only or Bidirectional. If you have selected the IKE protocol version as IKEv1, one of the nodes must be Answer Only.

Step 7

Under Additional Configuration, do the following:

  • To route traffic to the VTI, click Routing Policy. FMC displays the Devices > Routing page. You can configure the Static or BGP routing for the VPN traffic.

  • To permit VPN traffic, click AC Policy. FMC displays the access control policy page of the device. Proceed to add allow/block rule specifying the security zone of the VTI. If a backup VTI is being configured, ensure to include the backup tunnel to the same security zone as that of the primary VTI. No specific settings are required for the backup VTI in the AC policy page.

Step 8

For an extranet peer, specify the following parameters:

  1. In the Device Name, enter the name of the device.

  2. In the Endpoint IP address, enter the primary IP address. If you are configuring a backup VTI, enter a comma and then specify the backup IP address.

  3. Click the IKE tab and specify the pre-shared key provided on the extranet.

    Note

     

    The AWS VPC has AES-GCM-NULL-SHA-LATEST as the default policy. If the remote peer connects to AWS VPC, select AES-GCM-NULL-SHA-LATEST from the Policy drop-down list to establish the VPN connection without changing the default value in AWS.

Step 9

Repeat the above procedure for Node B.


What to do next

Route Traffic Through a Backup VTI Tunnel

Firepower Threat Defense supports the configuration of a backup tunnel for the route-based (VTI) VPN. When the primary VTI is unable to route the traffic, the traffic in the VPN is tunneled through the backup VTI.

You can deploy the backup VTI tunnel in the following scenarios:

  • Both peers having service provider redundancy backup.

    In this case, there are two physical interfaces, acting as the tunnel sources for the two VTIs of the peers.

  • Only one of the peers having service provider redundancy backup.

    In this case, there’s an interface backup on only one side of the peer and on the other end, there is only one tunnel source interface.

Step

Do This

More Info

1

Review the guidelines and limitations.

Guidelines and Limitations for Virtual Tunnel Interfaces

2

Create the VTI interface.

Add a VTI Interface

3

In the Add Endpoint dialog box of the Create New VPN Topology wizard, click Add Backup VTI to configure the respective backup interface for each peer.

4

Configure the routing policy.

  • Choose Devices > Device Management, and edit the threat defense device.

  • Click Routing.

5

Configure the access control policy.

  • Choose Policies > Access Control.

Guidelines for Configuring a Backup VTI Tunnel

  • For an extranet peer, you can specify the tunnel source IP address of the backup interface and configure the tunnel destination IP on the managed peer.

    You can specify the backup peer IP address in the Endpoint IP Address field of the Create New VPN Topology wizard.

  • After you configure the backup interfaces, configure the routing policy and access control policy for routing traffic.

    Though primary and backup VTIs are always available, traffic flows only through the tunnel that is configured in the routing policy. For detailed information, see Configure Routing and AC Policies for VTI.

  • When you configure a backup VTI, ensure that you include the backup tunnel to the same security zone as that of the primary VTI. No specific settings are required for the backup VTI in the AC policy page.

  • If you configure a static route for the backup tunnel, configure a static route with a different metric to handle the failover of the traffic flow over the backup tunnel.

Configure Routing and AC Policies for VTI

After you configure VTI interfaces and the VTI tunnel on both the devices, you must configure:

  • A routing policy to route VTI traffic between the devices over the VTI tunnel.

  • An access control rule to allow encrypted traffic.

Routing Configuration for VTI

For the VTI interfaces, you can configure static route or routing protocols such as BGP.

  1. Choose Devices > Device Management, and edit the FTD device.

  2. Click Routing.

  3. Configure static route, or BGP.

Routing

Parameters

More Information

Static Route

  • Interface—Select the VTI interface. For a backup tunnel, select the backup VTI interface.

  • Selected Network—Remote peer’s protected network.

  • Gateway—Remote peer’s tunnel interface IP address. For a backup tunnel, select the remote peer’s backup tunnel interface IP address.

  • Metric—For a backup tunnel, configure a different metric to handle the failover of the traffic flow over the backup tunnel.

Add a Static Route

BGP

  • Under General Settings > BGP, enable BGP, provide the AS number of the local device, and add Router ID (if you choose Manual).

  • Under BGP, enable IPv4/IPv6 and click the Neighbor tab to configure the neighbors.

    • IP Address—Remote peer’s VTI interface IP address. For a backup tunnel, add a neighbor with the remote peer's backup VTI interface IP address.

    • Remote AS—Remote peer’s AS number.

  • Click the Redistribution tab, select the Source Protocol as Connected to enable connected route redistribution.

Configure BGP

AC Policy Rule

Add an access control rule to the access control policy on the device to allow encrypted traffic between the VTI tunnels with the following settings:

  1. Create the rule with the Allow action.

  2. Select the VTI security zone of the local device as the source zone and the VTI security zone of the remote peer as the destination zone.

  3. Select the VTI security zone of the remote peer as the source zone and the VTI security zone of the local device as the destination zone.

For more information about configuring an access control rule, see Create and Edit Access Control Rules.

Monitoring the Site-to-Site VPNs

The Firepower Management Center provides a snapshot of the site-to-site VPN tunnels to determine the status of the site-to-site VPN tunnels. You can view the list of tunnels between peer devices and the status of each tunnel: Active, Inactive, or No Active Data. You can filter the data in the table according to the topology, device, and status. The table in the monitoring dashboard presents live data and you can configure to refresh the data at a specified interval. The table shows the peer-to-peer, hub and spoke, and full mesh topologies for crypto map-based VPNs. The tunnel information also contains the data for the route-based VPNs or Virtual Tunnel Interfaces (VTIs).

You can use this data to:

  • Identify problematic VPN tunnels and troubleshoot.

  • Verify connectivity between the site to site VPN peers devices.

  • Monitor the health of the VPN tunnels to provide uninterrupted VPN connectivity between sites.

For information about configuring crypto-map based site to site VPNs, see Configure a Policy-based Site-to-Site VPN.

For information about VTIs, see About Virtual Tunnel Interfaces.

For information about FTD VPN monitoring and troubleshooting, see VPN Monitoring and Troubleshooting.

Guidelines and Limitations

  • The table shows the list of site-to-site VPNs that are deployed. It does not show the tunnels that are created and not deployed.

  • The table does not show the information about the backup tunnels of policy-based VPNs and backup VTIs.

  • For cluster deployments, the table does not show director change in real-time data. It shows only the director information that existed when the VPN was deployed. The director change reflects in the table only after the tunnel AM redeployed after the change.

Site-to-site VPN Monitoring Dashboard

The site-to-site VPN monitoring dashboard displays the following widgets for the site-to-site VPN tunnels:

  • Tunnel Status Table—A table listing the site to site VPNs configured using the FMC

  • Tunnel Status Distribution Chart—Aggregated status of the tunnels in a donut graph.

  • Topology Summary Listing—Tunnel status summarized by topology.

Status of VPN Tunnels

The site-to-site monitoring dashboard lists the VPN tunnels in the following states:

  • Inactive—A policy-based (crypto map-based) VPN tunnel is inactive if all the IPSec tunnels are down. A VTI or tunnel is down if the tunnel encounters any configuration or connectivity issues.

  • Active—In the FMC, policy-based site-to-site VPNs are configured based on IKE policies and IPsec proposals that are assigned to VPN topologies. A policy-based VPN tunnel is in the Active state if the FMC identifies interesting traffic through the tunnel after the deployment. An IKE tunnel is up only if a minimum of one IPsec tunnel is up.

    Route-based VPN (VTI) tunnels do not require interesting traffic to be in the Active state. They are in the Active state if they are configured and deployed without errors.

  • No Active Data—Policy-based tunnels remain in the No Active Data state until there is a traffic flow event through the tunnel for the first time. The No Active Data state also lists the policy-based and route-based VPNs that have been deployed with errors.

Automatic Data Refresh

The site to site VPN data in the table refreshes periodically. You can configure the refresh interval of the VPN monitoring data at a specific interval or turn the automatic data refresh off.

Click the Refresh interval drop-down to select from the available intervals to refresh the data in the table.

Figure 1. Refresh the Tunnel Data

Click Pause to stop the automatic data refresh for as long as you want. You can click the same button to resume refreshing the tunnel data.

Figure 2. Pause the Periodic Data Refresh

Filter and Sort the Site to Site VPN Monitoring Data

You can filter and view the data in the VPN monitoring table by topology, device, and status.

For example, you can view the tunnels that are in the Down state in a specific topology.

Click within the filter box to choose the filter criteria and then specify the values to filter.

Figure 3. Filter the Tunnel Data

You can use multiple filtering criteria to view the data based on your requirement.

For example, you can choose to view only the tunnels that are in the Up and Down states, and ignore the ones in the Unknown state.

Figure 4. Example: Filter Tunnel Data

Sort the data—To sort the data by a column, click the column heading.

History for Site-to-Site VPN

Feature

Minimum FMC

Minimum FTD

Details

Site-to-Site VPN Filter

7.1

Any

You can control site-to-site VPN traffic by using an access control policy.

Local tunnel ID support

7.1

Any

For each endpoint on a site-to-site VPN, you can configure a unique tunnel ID to be shared with the peers.

Multiple IKE Policy Support

7.1

Any

You can add multiple IKEv1 and IKEv2 policy objects for each endpoint.

Site-to-Site VPN Monitoring Dashboard

7.1

Any

Use the Site-to-Site VPN Monitoring dashboard to view and monitor the status of site-to-site VPN tunnels.

Backup virtual tunnel interfaces (VTI) for route-based site-to-site VPN.

7.0

Any

When you configure a site-to-site VPN that uses virtual tunnel interfaces, you can select a backup VTI for the tunnel. Specifying a backup VTI provides resiliency, so that if the primary connection goes down, the backup connection might still be functional. For example, you could point the primary VTI to the endpoint of one service provider, and the backup VTI to the endpoint of a different service provider.

You can add a backup VTI in the site-to-site VPN wizard by selecting route-based as the VPN type for a point-to-point connection.

Enhance the number of VTI from 100 per interface to 1024 per device

7.0

Any

Support for maximum number of VTIs is enhanced from 100 per physical interface to 1024 VTIs per device.

IPv6 Support

7.0

Any

You can configure IPv6 addressed VTIs. While only static IPv6 address is supported as the tunnel source and destination, IPv6 BGP isn’t supported over VTI.

Removal and deprecation of weak ciphers

6.7

Any

Support has been removed for less secure ciphers. We recommend that you update your VPN configuration before you upgrade to FTD 6.70 to supported DH and encryption algorithms to ensure the VPN works correctly.

Update your IKE proposals and IPSec policies to match the ones supported in FTD 6.70 and then deploy the configuration changes.

The following less secure ciphers have been removed or deprecated in FTD 6.70 onwards:

  • Diffie-Hellman GROUP 5 is deprecated for IKEv1 and removed for IKEv2

  • Diffie-Hellman groups 2 and 24 have been removed.

  • Encryption algorithms: 3DES, AES-GMAC, AES-GMAC-192, AES-GMAC-256 have been removed.

    Note

     

    DES is supported in evaluation mode or for users who do not satisfy export controls for strong encryption.

    NULL is removed in IKEv2 policy, but supported in both IKEv1 and IKEv2 IPsec transform-sets.

Dynamic RRI support

6.7

Any

Dynamic Reverse Route Injection is supported with IKEv2 based static crypto maps.

Backup peer for site-to-site VPN

6.6

Any

You can use the FMC to add a backup peer to a site-to-site VPN connection. For example, if you have two ISPs, you can configure the VPN connection to fail over to the backup ISP if the connection to the first ISP becomes unavailable.

New/modified pages:

Devices > VPN > Site to Site. When adding or editing a point to point or hub and spoke FTD VPN topology to add an endpoint, the IP Address field supports comma-separated backup peers.