Site-to-Site VPN on FTD: A Clean First Tunnel

By Taylor Thomas · 2026-09-01

A site-to-site VPN extends a private network across an untrusted transport by encrypting traffic between two gateways, and on Cisco Secure Firewall the clean way to build one is to make four decisions in order: the topology, the IKE version, how traffic is selected into the tunnel, and what NAT must leave alone. Tunnels that will not come up commonly trace back to one of the last two.

Topology First

Secure Firewall Management Center treats a site-to-site VPN as a topology object rather than a per-device configuration: you define a point-to-point, hub-and-spoke, or full-mesh topology, name the endpoints, and FMC generates the matching configuration for every managed device in it. That model matters at two moments — day one, because both ends of a managed-to-managed tunnel are generated from one definition instead of two hand-kept configurations, which removes the usual source of mismatch, and year two, when adding a spoke to a hub-and-spoke topology is an edit to one object rather than a fresh configuration on every device.

IKEv2, and What Each Exchange Does

Both IKE versions are supported; IKEv2 is the right choice wherever both peers speak it — fewer exchanges, liveness detection defined in the core protocol, and cleaner rekeying, as covered in IKEv1 vs IKEv2. Knowing what each IKEv2 exchange accomplishes is the troubleshooting map. IKE_SA_INIT runs first: the peers agree on cryptographic algorithms and perform the key exchange that protects everything after it. IKE_AUTH runs second, inside that protection: the peers prove their identities — pre-shared key or certificate — and establish the first Child SA, the pair of IPsec SAs that will carry data. The practical consequence: a mismatched pre-shared key does not fail in IKE_SA_INIT, because authentication has not happened yet. A negotiation dying in the first exchange points at proposals or reachability; one dying in IKE_AUTH points first at credentials or identity — but the first Child SA also rides inside IKE_AUTH, so traffic-selector and IPsec-proposal problems can surface there as well.

Selecting Traffic: Policy-Based or Route-Based

FTD builds tunnels in two styles, and the difference is how traffic is chosen for encryption. A policy-based VPN defines protected networks on each side; traffic matching those selectors is encrypted, everything else bypasses the tunnel. A route-based VPN uses a virtual tunnel interface: the tunnel is an interface with routes pointing into it, and whatever the routing table sends there gets encrypted. Route-based designs scale more gracefully — extending the VPN is a route change, and dynamic routing can run across the tunnel — which is why VTI is named alongside the other deployment types in SCOR objective 1.6. Policy-based remains the interoperability workhorse, because two peers agreeing on explicit traffic selectors is the least ambiguous contract between different vendors.

Either way, the selectors must be compatible. IKEv2 lets a responder narrow the initiator’s proposed traffic selectors to an acceptable subset — but in a policy-based tunnel, a proposed network with no acceptable overlap on the other side fails the Child SA even though IKE authentication succeeded: a tunnel that is “up” for IKE and down for data. Route-based designs avoid per-prefix selector negotiation — the tunnel negotiates broad selectors and routing chooses the traffic — but they move the same responsibility into routing: a route missing on one side sends replies down the wrong path outside the tunnel, a failure that looks like the tunnel’s fault and is not.

One more behavior worth internalizing: tunnels are normally brought up by traffic — a policy-based SA by traffic matching its selectors, a VTI by traffic routed into the tunnel interface. An idle tunnel that nothing has tried to use may simply never negotiate, and an engineer staring at a down tunnel should first ask whether anything has tried. Generating interesting traffic — a ping from a host on one protected network to a host on the other — is the honest first test, because it exercises selection, negotiation, and routing in one packet.

NAT Is the Usual Suspect

The same firewall terminating the tunnel is usually also translating outbound traffic to the internet, and those two jobs collide. In a policy-based tunnel, a dynamic NAT rule that translates internal sources before encryption produces packets whose addresses no longer match the crypto selectors; in a route-based tunnel the selectors are broad, but unwanted translation still sends the wrong addresses across, breaking the far side’s routing and policy. The fix is to keep VPN-bound flows out of the overlapping translation — most commonly a NAT exemption, an identity NAT rule for site-to-site traffic ordered ahead of the general translation, so those flows keep their original addresses. When a tunnel authenticates but traffic never arrives, check NAT before touching the crypto. Then remember the access control policy: decrypted tunnel traffic is evaluated by it by default, so a missing permit rule produces the same symptom as a broken tunnel.

Where This Sits on the Blueprint

Site-to-site VPN on FTD is core-exam material: SCOR 350-701 v2 objective 2.9 covers configuring it, 2.10 covers troubleshooting tunnel establishment, and 1.6 covers the deployment types — virtual tunnel interfaces included. The SCOR course builds a first tunnel on real FTD and then breaks it the ways this guide describes, because reading a dead negotiation is the skill the exam and the job both test. For the full path, start at the course catalog.

Frequently Asked Questions

Should I build a policy-based or route-based site-to-site VPN on FTD?

Route-based, using a virtual tunnel interface, is the more flexible default for new designs: the tunnel becomes a routable interface, traffic selection is a routing decision, and adding a new network to the VPN is a route change rather than a crypto configuration change. Policy-based tunnels remain common for interoperability with peers that expect specific traffic selectors, and they are what many existing designs already run.

Why does my FTD tunnel fail even though both sides have matching crypto settings?

Common culprits sit outside the crypto proposal: NAT rules translating traffic that the tunnel expects to see with original addresses, mismatched protected-network definitions so the peers cannot agree on traffic selectors, or the tunnel simply never being triggered because nothing has matched its selectors or been routed into it. Check NAT exemption and traffic selection alongside the proposals, not after ruling everything else out.

Does site-to-site VPN traffic on FTD go through the access control policy?

By default, yes — traffic arriving through the tunnel is decrypted and then evaluated by the access control policy like any other traffic, so your rules must permit it. FTD also offers a documented option to bypass access control inspection for decrypted VPN traffic; leaving inspection on is the more defensible default because it keeps one policy authority over what enters each zone.