Most engineers think…
Most people think 'a VPN is a VPN' and configure every tunnel as a crypto-map with an ACL. That works for a couple of peers, then collapses the moment you need dynamic routing, many subnets or a clean remote-access setup.
On Cisco Secure Firewall, VPN runs in the LINA data plane and comes in distinct shapes. Site-to-site is either policy-based (an ACL picks the interesting traffic) or route-based using a VTI where you simply route into the tunnel. Tunnels build in two phases — the IKE SA authenticates peers, the IPsec SA protects data. Remote Access uses Cisco Secure Client (the rebranded AnyConnect) with connection profiles, group policies, address pools and AAA. And every one of them needs a NAT-exempt rule so the traffic is not PATed out of the tunnel. Knowing those shapes is the difference between 'the tunnel is up' and 'the tunnel actually carries traffic'.
① Site-to-site: IKEv2/IPsec — policy-based vs route-based (VTI)
Site-to-site VPN joins two networks with an encrypted IKEv2/IPsec tunnel, and on FTD it comes in two flavours.
Policy-based (the classic crypto-map style) selects what to encrypt with a crypto ACL — the 'interesting traffic'. Anything matching the ACL goes in the tunnel; anything else does not. It is precise but rigid, and it does not play nicely with dynamic routing.
Route-based with a VTI
Route-based VPN uses a VTI (Virtual Tunnel Interface). Instead of an ACL, you just route traffic into the tunnel interface — whatever you send to the VTI is encrypted. This is far cleaner for many subnets, supports dynamic routing protocols (BGP/OSPF) over the tunnel, and is the modern default for new designs.
In a route-based (VTI) site-to-site VPN, what decides which traffic is encrypted?
② S2S topologies in FMC & the IKE phases
In FMC you build site-to-site VPN as a topology, and there are three shapes. Point-to-point connects two peers directly. Hub-and-spoke has every branch (spoke) tunnel back to a central hub, which is how most enterprises run it. Full mesh connects every site to every other site — most resilient, most tunnels to manage.
How a tunnel comes up — two phases
Every IPsec tunnel builds in two phases. IKE SA (phase 1) authenticates the peers (pre-shared key or certificate) and builds a secure, encrypted management channel between them. IPsec SA (phase 2) then negotiates, over that protected channel, the keys and parameters that actually protect the data. Phase 1 builds the secure room; phase 2 carries the cargo. If phase 1 fails it is usually auth or IKE policy mismatch; if phase 2 fails it is usually a transform/proposal or interesting-traffic mismatch.
A crypto ACL selects the interesting traffic. Precise but rigid, no dynamic routing — the classic crypto-map style.
A Virtual Tunnel Interface you route traffic into. Whatever you route to it is encrypted, and it supports BGP/OSPF over the tunnel.
Phase 1 (IKE SA) authenticates the peers and builds the secure channel; phase 2 (IPsec SA) negotiates the keys that protect the data.
The rebranded AnyConnect. The RA VPN client connects over SSL/TLS or IKEv2 to a connection profile and gets a group policy and an address pool IP.
In an interview, say it crisply: phase 1 (the IKE SA) authenticates the peers and builds the secure channel; phase 2 (the IPsec SA) negotiates the keys that protect the data. Phase-1 failures are usually auth or IKE policy mismatches; phase-2 failures are usually transform/proposal or interesting-traffic mismatches. Knowing which phase fails tells you where to look.
What does IKE phase 1 (the IKE SA) accomplish?
③ Remote Access VPN with Cisco Secure Client
Remote Access VPN (RA VPN) brings individual users in. The client is Cisco Secure Client — the rebranded AnyConnect — and it connects over SSL/TLS or IKEv2.
On the FTD side you assemble RA VPN from a few layers. A connection profile (tunnel-group) is what a user actually connects to — it ties together the authentication method and the policies. A group policy defines what the connected session gets — split tunnelling, DNS, timeouts, allowed protocols. An address pool hands the remote user an inside IP for the duration of the session. The client downloads its config, authenticates, gets an address and is on the network.
The interview line: connection profile = what you connect to, group policy = what you get, address pool = the IP you are given.
The connection profile (tunnel-group) is WHAT the user connects to and how they authenticate; the group policy is WHAT the session gets — split tunnel, DNS, timeouts. Mixing them up is the classic RA VPN slip. Profile = the door; group policy = the room you walk into; address pool = the IP badge you are handed.
▶ Watch a remote worker connect by RA VPN — then break it
How a Cisco Secure Client session is built end-to-end, and the classic failure when the NAT-exempt rule is missing. Press Play for the healthy path, then Break it.
What is the current name of the AnyConnect remote-access client?
④ AAA, certificates, SAML & NAT-exempt for VPN
Authentication for RA VPN runs through AAA. Common back-ends: RADIUS (often to Cisco ISE) for authentication, MFA and authorization; LDAP/Active Directory for directory auth; and SAML for SSO to a cloud identity provider. You can also use certificate authentication, and combine factors. Beyond auth, posture / DAP (Dynamic Access Policy) can check the device's health and adjust what the session is allowed to do.
The rule everyone forgets
VPN-interesting traffic must reach the tunnel with its real source IP. If a broad dynamic PAT rule catches it first, it is translated and never enters the tunnel. The fix — shared with the NAT lesson — is a NAT-exempt rule for the pool ↔ internal subnets, placed in NAT Section 1, above the PAT rule.
Sneha at a Chennai SaaS firm faces this
Remote staff connect with Cisco Secure Client, get an IP from the pool and the tunnel shows 'connected', but they cannot open the internal HR app.
There is a broad dynamic PAT rule for inside traffic, and no NAT-exempt rule for the RA pool, so the pool↔internal traffic is PATed instead of staying inside the tunnel.
Run packet-tracer from a pool address to the HR app: it shows the packet being PATed to the outside interface IP rather than being NAT-exempt and routed to the internal subnet.
FMC ▸ Devices ▸ NAT ▸ (policy) ▸ Add Manual NAT (identity), Section 1Add a Manual (twice) identity-NAT rule — source = RA pool, destination = internal subnets, translate each to itself — placed in NAT Section 1, above the dynamic PAT rule.
Re-run packet-tracer: the flow is now NAT-exempt and routed internally; remote users reach the HR app and the session counters increase.
Whether it is site-to-site or remote access, VPN-interesting traffic needs a NAT exemption so it is not PATed out of the tunnel. Do not assume it works — run packet-tracer from a tunnel source to the destination and confirm the flow is marked NAT-exempt and routed into the tunnel, not translated to the outside IP.
RA VPN users get an IP from the pool and the tunnel is up, but they cannot reach the internal app. packet-tracer shows their traffic being PATed. What is missing?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why might a Cisco Secure Client user authenticate, get an IP, see the tunnel as up, and still not reach the internal app? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- IKEv2 / IPsec
- IKEv2 negotiates and manages keys; IPsec (ESP) encrypts and integrity-protects the data. Together they form the secure site-to-site tunnel.
- Policy-based VPN
- Site-to-site VPN where a crypto ACL selects the interesting traffic to encrypt. Precise but rigid, with no dynamic routing over the tunnel.
- Route-based VPN / VTI
- A Virtual Tunnel Interface you route traffic into; whatever is routed there is encrypted, so dynamic routing (BGP/OSPF) can run over the tunnel.
- IKE SA (phase 1)
- The first phase of an IPsec tunnel: it authenticates the peers (PSK or certificate) and builds the secure, encrypted management channel.
- IPsec SA (phase 2)
- The second phase: over the phase-1 channel it negotiates the keys and parameters (transform/proposal, PFS) that actually protect the data.
- Cisco Secure Client
- The rebranded AnyConnect remote-access client. It connects over SSL/TLS or IKEv2 and carries VPN plus posture and other modules.
- Connection profile / group policy
- The connection profile (tunnel-group) is what a user connects to and how they authenticate; the group policy defines what the session gets (split tunnel, DNS, timeouts).
- AAA (RADIUS/ISE, LDAP, SAML)
- Authentication back-ends for RA VPN: RADIUS to Cisco ISE, LDAP/Active Directory, or SAML for SSO to a cloud identity provider, plus certificate auth.
- NAT exemption for VPN
- An identity NAT (twice NAT) rule that keeps VPN-interesting traffic on its real IP so it is not PATed out of the tunnel. It sits in NAT Section 1, above the PAT rule.
📚 Sources
- Cisco — Cisco Secure Firewall Management Center Device Configuration Guide: Site-to-Site VPNs. cisco.com
- Cisco — Secure Firewall Threat Defense: Route-based (VTI) vs policy-based site-to-site VPN. cisco.com
- Cisco — FMC VPN topologies: point-to-point, hub-and-spoke and full mesh; IKEv2 IKE/IPsec phases. cisco.com
- Cisco — Remote Access VPN with Cisco Secure Client (formerly AnyConnect): connection profiles, group policies, address pools. cisco.com
- Cisco — RA VPN AAA: RADIUS/ISE, LDAP/AD, SAML SSO, certificate authentication and posture/DAP. cisco.com
- Cisco Tech Notes — Configure NAT exemption for site-to-site and remote-access VPN on Threat Defense. cisco.com
What's next?
Got VPN? Pair it with the NAT lesson — Auto vs Manual NAT and the Section 1-2-3 order — so you can place the NAT-exempt rule correctly, and then go deeper on identity (ISE/SAML) and posture for Remote Access.