Virtual tunnel interfaces (VTIs) allow for VPNs to be established without the need for the more complex crypto map configurations. VTI tunnels allow for protected traffic to be routed through the tunnel using the routing table, as opposed to creating access control lists (ACLs) to define the protected traffic.
This training demonstrates the configuration of route-based VPNs using VTIs on Cisco Secure Firewall Threat Defense (formerly Firepower Threat Defense, or FTD). You will configure point-to-point route-based VPN tunnels, add VTIs to the routing table, and configure identity Network Address Translation (NAT) and access control rules for use with point-to-point VPN tunnels. Lastly, the training explains the steps to verify VTI VPN operations.
What You’ll Learn
- How to create a route-based VPN topology
- How to add a VTI to the route table
- How to create an identity NAT rule for the VPN
- How to add an access control policy to allow VPN traffic
Note: There is no lab environment associated with this tutorial; please follow along with the screenshots.
Configuration of site-to-site VPNs is performed in Cisco Secure Firewall Management Center by navigating to Devices > VPN > Site To Site.
- To create a new topology, open the Site-to-Site VPN wizard by clicking the Add button in the upper-right corner of the screen.
- Alternatively, if no topologies are configured, you can click the VPN Tunnel hyperlink in the message in the middle of the page.
Once the Create New VPN Topology window is open, perform the following steps to create a point-to-point route-based (VTI) VPN topology:
Give the topology a name. The example uses the name HQ_to_SiteA.
Select the Route Based (VTI) radio button. The fields in the Endpoints tab will change based on whether you have chosen Policy Based (Crypto Map) or Route Based (VTI). The example shows the fields for Route Based (VTI).
Under Network Topology, select Point to Point. The values will change again in the Endpoints tab based on the network topology selected. The example shows the fields for Point to Point.
Select the Internet Key Exchange (IKE) version that you wish to use for the topology. As shown in the example, the default value is IKEv2.
Under the Endpoints tab, configure the following for Node A, a managed threat defense device:
Using the Device drop-down menu, select a threat defense device. The options are to choose from the configured threat defense devices currently registered with the management center, or an extranet device. The example shows that Node A is the threat defense device named FTD-1. If you choose a managed device for a node, all the configuration parameters defined in the topology that apply to that device will be deployed to the device.
From the Virtual Tunnel Interface drop-down menu, select the VTI to use for the corresponding device. The VTI needs to be configured before it can be selected. You can configure the VTI by clicking the add (+) button to the right of the Virtual Tunnel Interface drop-down menu; the Add Virtual Tunnel Interface pop-up window will open.
In the Add Virtual Tunnel Interface pop-up, configure the following:
If necessary, change the VTI name from the default. The example uses the default name provided by the management center. As new VTIs are added, the integer at the end of the name will increase. You can change this name if desired, but it is not necessary. By default, the interface is enabled. Use a name that is not longer than 28 characters.
Optionally, provide a description for the VTI.
Optionally, from the drop-down menu, select the security zone for the VTI. 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 rule. To permit the VPN traffic over the tunnel, you need to add an access control rule with this security zone as the source zone. The example uses the security zone named OUTZONE.
In the Priority field, enter the priority to load-balance the traffic across multiple VTIs. The range is from 0 to 65535. The lowest number has the highest priority. This option is not applicable for dynamic VTI. The default value is 0.
For a static VTI, enter a unique tunnel ID in the range of 0 to 10413 in the Tunnel ID field.
Choose the tunnel source interface from the Tunnel Source drop-down menu. The VPN tunnel terminates at this interface, a physical interface. Choose the IP address of the interface from the drop-down list. The example uses the outside interface (GigabitEthernet0/0) as the source interface.
Under IPsec Tunnel Mode, click the IPv4 or IPv6 radio button to specify the traffic type over the IPsec tunnel. 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. It is recommended that you use an IP from the 169.254.x.x/16 range excluding the threat defense reserved range (169.254.1.x/24). Also, use /30 as netmask to optimally use only two addresses for the two ends of the VTI tunnel—for example, 169.254.100.1/30. The example uses the default 169.254.2.1/30 address. If the peer is an extranet device, you must confirm that it uses the other available address on that subnet (169.254.2.2/30 in the example), or else the tunnel will not be able to route traffic.
Click OK. If adding the VTI from the Create New VPN Topology window, you will be returned to that window to complete the configuration.
Back in the Create New VPN Topology window, continue to configure the following:
Select the new VTI from the Virtual Tunnel Interface drop-down menu.
If the Node A device is behind a NAT device, select the Tunnel Source IP is Private check box. In the Tunnel Source Public IP Address field that appears, enter the tunnel source public IP address. This option is not selected in the example.
Select the Send Local Identity to Peers check box to send local identity information to the peer device. Select one of the following local identity configurations from the list to 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 Secure Firewall Threat Defense to have multiple IPsec tunnels behind a NAT to connect to a Cisco Umbrella Secure Internet Gateway (SIG). This option is not configured in the example.
Optionally, click Add Backup VTI to specify an extra VTI as a backup interface and configure its parameters. Confirm 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, therefore, 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.
Using 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. The option allows for the following:
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.
If Node B is also a managed threat defense device, perform the previous steps for it as well. If the device is an extranet device, perform the following steps:
From the Device drop-down menu, choose the device Extranet.
Specify the name of the device. The example uses the name Site_A_Router.
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.
Next, you need to make sure that that IKE is configured properly. If both endpoints are managed threat defense devices, you can use the default values under the IKE tab. The example uses an extranet device for Node B, which is not managed by the management center. To help ensure that the IKE negotiation will establish correctly, you must verify that the IKE policies match between the nodes and that the pre-shared keys are the same.
Although not shown in the example, if IKEv1 is enabled, confirm that the IKEv1 values are configured correctly.
The IKE policies that are selected must include a match for the extranet device’s IKE policies.
If using an extranet device for one of the nodes, you must use either a pre-shared manual key or certificate for authentication.
After confirming the IKEv1 values, perform the following steps under the IKE tab:
Make sure that you have selected an IKEv2 policy that will match with the peer. If you do not see a matching policy, click the pencil icon to edit the applied policies. The IKEv2 Policy window will open allowing you to add or remove policies from the available policies list. If multiple policies are selected, the peers will negotiate to the most secure policy that both peers agree on.
In the Authentication Type field, select the authentication that you wish to use for the tunnel. The default is Pre-Shared Automatic Key, which will allow the management center to create a key dynamically based on the defined key length. If using an extranet device for one of the peers, you must use either Pre-Shared Manual Key or Certificate for the authentication method. The example uses Pre-Shared Manual Key.
Configure and confirm the key that will be used for authentication.
Select the Enforce hex-based pre-share key only check box to require that the key is to be defined in a hexadecimal format.
The IPsec tab of the Create New VPN Topology window allows you to manage the transform sets, lifetimes, and other values that will be used for the negotiated tunnels for the protected traffic.
If both peers are registered devices in the management center, the default values will work. If one of the peers is an extranet device, or you need to use a different level of security for the protected traffic, you can adjust the values. Confirm that the transform sets for the IKEv1 (if enabled) and IKEv2 IPsec proposals (transform sets) meet your security requirements and that they will match transform sets on an extranet peer (if used).
The Enable Security Association (SA) Strength Enforcement option helps ensure 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.
Checking the Enable Perfect Forward Secrecy check box generates 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 pre-shared 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 is 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.
The Lifetime Duration field defines the number of seconds that an SA exists before expiring. The default is 28,800 seconds.
The Lifetime Size field defines the volume of traffic (in kilobytes) that can pass between IPsec peers using a given SA before it expires. The default is 4,608,000 kilobytes. Infinite data isn’t allowed.
Lastly, the Advanced tab has three sections: IKE, IPsec, and Tunnel. The Advanced tab allows you to configure various settings that will affect the tunnel stability.
The settings under the Advanced tab, include:
IKE > ISAKMP Settings:
IKE Keepalive: Enables or disables IKE keepalives. You can set this option to Enable Infinite so that the device never starts the keepalive monitoring itself.
Threshold: Specifies the IKE keepalive 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 the number of seconds to wait between IKE keepalive retries. The default is 2 seconds; the maximum is 10 seconds.
Identity Sent to Peers: Determines the identity that the peers use to identify themselves during IKE negotiations:
autoOrDN (default): Determines IKE negotiation by connection type—IP address for Pre-Shared Key or Cert DN for certificate authentication (not supported).
ipAddress: Uses the IP addresses of the hosts exchanging Internet Security Association and Key Management Protocol (ISAKMP) identity information.
hostname: Uses the fully qualified domain name (FQDN) of the hosts exchanging ISAKMP identity information. This name comprises the hostname and the domain name.
Peer Identity Validation: Choose if the device needs to validate the peer identity:
Do not check: Peer identity should not be checked.
Required: Peer identity must be verified to negotiate the tunnel.
If Supported by Certificate: Validate peer identity only if the peer certificate used for identity validation supports it.
Enable Aggressive Mode: Exchanges key information if the IP address is not known and Domain Name System (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.
IKE > IKEv2 Security Association (SA) Settings:
More session controls are available for IKEv2 that limit the number of open SAs. By default, there is no limit to the number of open SAs.
Cookie Challenge: Determines 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 percent of the available SAs are in negotiation. Select one of these options:
Custom
Never (default)
Always
IPsec > IPsec Settings:
Enable Fragmentation Before Encryption: Allows traffic to travel across NAT devices that do not support IP fragmentation. It does not impede the operation of NAT devices that do support IP fragmentation.
Path Maximum Transmission Unit Aging: Enables path maximum transmission unit (PMTU) aging, the interval to reset the PMTU of an SA.
Value Reset Interval: Determines the number of minutes at which the PMTU value of an SA is reset to its original value. The valid range is 10 to 30 minutes; the default is unlimited.
Tunnel > NAT Settings:
- Keepalive Messages Traversal: Determines whether to enable NAT keepalive message traversal. NAT traversal keepalive is used for the transmission of keepalive messages when there is 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.
Tunnel > Access Control for VPN Traffic:
- Bypass Access Control policy for decrypted traffic (sysopt permit-vpn): By default, Secure Firewall Threat Defense applies access control policy inspection on the decrypted traffic. Enable this option to bypass the ACL inspection. The threat defense still applies the VPN filter ACL and authorization ACL downloaded from the authentication, authorization, and accounting (AAA) server to the VPN traffic. Enable or disable the option for all your VPN connections. If you disable this option, confirm that the traffic is allowed by the access control policy or prefilter policy.
Tunnel > Certificate Map Settings:
Use the certificate map configured in the Endpoints to determine the tunnel: Specifies that the tunnel is determined by matching the contents of the received certificate to the certificate map objects that are configured in the endpoint nodes.
Use the certificate OU field to determine the tunnel: Indicates that if a node is not 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 is not determined based on a rule matching or taken from the organizational unit (the above options) if selected, then the certificate-based IKE sessions are mapped to a tunnel based on the content of the phase 1 IKE ID.
Use the peer IP address to determine the tunnel: Indicates that if a tunnel is not determined based on a rule matching or taken from the organizational unit or IKE ID methods (the above options) if selected, then use the established peer IP address.
Once you have finished the Create New VPN Topology wizard, click the Save button in the lower-right corner of the wizard. This step will take you back to the Devices > VPN > Site To Site window, where you can see a summary of the topology that was just created. As seen in the example, the topology will not go into effect until the configuration has been deployed to the managed devices that are defined in the configuration.
After you have configured VTI interfaces and a VTI tunnel on both peers, you must configure a routing policy to route VTI traffic between the peer devices over the VTI tunnel. You must also configure an access control rule to allow encrypted traffic.
Configure static routing on both peer devices to route the traffic flow between the devices over the VTI tunnel. If you configure a backup tunnel for the VPN, configure a static route with a different metric to handle the failover of the traffic flow over the backup tunnel.
Confirm that you have configured the following when you configure a static route:
Interface: Select the VTI interface used in the VPN. In case of a backup tunnel, select the backup VTI interface used in the VPN.
Selected Network: Select the remote peer’s protected network (added as a network object).
Gateway: Select the remote peer’s tunnel interface IP address as the gateway. For a backup tunnel, select the remote peer’s backup tunnel interface IP address as the gateway.
Traffic from the protected networks to the internet is subject to NAT in order to communicate with internet services. Traffic over the VPN tunnel should not be translated.
When creating an identity NAT rule for the managed threat defense device, use the same network object for both the original and translated source. Using the same network object helps ensure that the private IP address will be seen by hosts at the peer location. By defining the peer protected network as the destination, you help ensure that the identity NAT will only be used for tunneled traffic.
Tunneled traffic is still subject to the inspections that are defined in the access control policy for the managed threat defense device. To help ensure that tunneled traffic is allowed through the firewall, you should define a rule in the access control policy that allows the tunneled traffic.
To add an access control rule to allow tunneled traffic, perform the following tasks:
Create the rule with the Allow action.
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 (if the remote device is not an extranet device).
Select the VTI security zone of the remote peer as the source zone (if the remote device is not an extranet device) and the VTI security zone of the local device as the destination zone.
If the remote device is an extranet device and is not managed by the management center, it will not have any security zones defined. For these deployments, you can use the protected network objects, as shown in the example, to define the traffic match criteria for the Allow rule.
The Cisco Secure Firewall Management Center monitoring dashboard presents a list of tunnels between peer devices and the status of each tunnel. The dashboard displays the hub-and-spoke, peer-to-peer, or full-mesh topologies for crypto map-based VPNs, and the tunnel information contains the data for the route-based VPNs or VTIs.
You can filter the site-to-site VPN data according to topology, device, and status. The data refreshes periodically. You can configure the refresh interval of the VPN monitoring data at a specific interval or turn the automatic data refresh off.
To open the Site to Site Monitoring page, navigate to Devices > VPN > Site to Site Monitoring. The Site to Site VPN Monitoring dashboard displays the following widgets:
Tunnel Status Table: A table listing the site-to-site VPNs configured using the management center and their statuses. Tunnel statuses include:
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 management center, 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 management center 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.
Tunnel Status Distribution Chart: Aggregated status of the tunnels in a donut graph.
Topology Summary Listing: Status of tunnels summarized by topology.
You’ve completed this tutorial, advancing in your learning journey. To continue building your networking skills, check out our additional tutorials, courses, and learning paths.
Why Create a Free Cisco U. Account?
A Cisco U. account helps you:
Personalize Training: Set your learning goals and pace.
Track Progress: Monitor your achievements and learning milestones.
Resume Anytime: Continue your learning exactly where you stopped.
Further Learning Resources
Cisco U. Demo: Step-by-Step Guide to Learning Paths, Courses, Labs, and Tutorials
Explore More on Cisco U:
Need Help or Want to Engage?
To ask questions and share ideas, join our Cisco Learning Community.
For technical issues, feedback, or more resources, visit our Cisco U. Support page.
Finishing Up
Don’t forget to click “Exit Tutorial” to log your completed content