Mental model
Site-to-site VPN connects two networks. Remote-access VPN connects one user’s device to a network.
Workflow: employee at home opens VPN client → authenticates with corporate credentials + MFA → gets a virtual IP on the corporate subnet → traffic to internal apps (SharePoint, file shares, internal web apps) flows through the encrypted tunnel.
Cisco’s client used to be called AnyConnect. In 2023 Cisco renamed it to Cisco Secure Client as part of unifying their endpoint products. Same software underneath — most people still call it AnyConnect.
The corporate-side device that terminates the tunnel is typically a Cisco ASA (older) or Firepower FTD (newer), or for cloud-first orgs, Cisco Secure Access / Umbrella.
SSL/TLS VPN vs IKEv2
Two underlying transport options:
| SSL/TLS VPN | IKEv2 (IPsec) | |
|---|---|---|
| Port | TCP 443 (looks like HTTPS) | UDP 500 + 4500 |
| Firewall friendliness | Excellent (TLS over 443 works through almost anything) | Sometimes blocked |
| Performance | Slightly higher overhead | Lighter on CPU |
| Re-connection on roaming | Slower | Faster (mobile-friendly) |
| Default in AnyConnect | Yes — SSL/TLS by default | Configurable alternative |
Default choice for AnyConnect: SSL/TLS — because it works through almost every firewall (looks like a regular HTTPS connection on TCP 443). IKEv2 is the better choice on mobile devices that roam frequently between Wi-Fi and cellular.
Full tunnel vs split tunnel
When the VPN is connected, which traffic goes through it?
| Full tunnel | Split tunnel | |
|---|---|---|
| Corp traffic | Through VPN | Through VPN |
| Internet traffic (Google, YouTube, Netflix) | Through VPN (out the corp’s internet pipe) | Direct (out the user’s home internet) |
| Pro | All traffic inspected by corp security; clean compliance posture | Better performance for non-corp traffic; less load on corp WAN |
| Con | Bandwidth cost (everything routes through HQ); user’s Netflix slows down | Direct internet path = no corp inspection; if user’s home network is hostile, that’s a problem |
Modern preference is shifting toward split tunnel + cloud-based security (Cisco Umbrella, Zscaler, etc.) — direct internet traffic goes through a cloud security layer rather than being backhauled to corporate.
For high-compliance environments (finance, healthcare, classified), full tunnel often stays. The all-traffic-via-VPN approach makes auditing easier.
Authentication options
| Method | What it is | Common |
|---|---|---|
| AD password | LDAP / RADIUS against Active Directory | Very common |
| AD + MFA | Password + Duo / Microsoft Authenticator / hardware token | Standard in 2026 |
| Certificate-based | User has a machine cert; no password | High-security environments |
| SAML / SSO | Cisco Secure Client redirects to a corporate IdP (Okta, Azure AD) | Modern preferred for cloud-integrated environments |
For CCNA: know that AnyConnect authenticates via RADIUS (likely talking to AD via Network Policy Server or similar) and that MFA is the modern standard.
Configuration — Cisco ASA side (minimal)
! Tunnel group for AnyConnect users
ASA(config)# tunnel-group VPN-USERS type remote-access
ASA(config)# tunnel-group VPN-USERS general-attributes
ASA(config-tunnel-general)# address-pool VPN-POOL
ASA(config-tunnel-general)# authentication-server-group CORP-RADIUS
! Group policy — what these users can do
ASA(config)# group-policy GP-VPN internal
ASA(config)# group-policy GP-VPN attributes
ASA(config-group-policy)# vpn-tunnel-protocol ssl-client
ASA(config-group-policy)# split-tunnel-policy tunnelspecified
ASA(config-group-policy)# split-tunnel-network-list SPLIT-ACL
! ACL defining what traffic the split tunnel covers
ASA(config)# access-list SPLIT-ACL extended permit ip 10.0.0.0 255.255.0.0 any
! Address pool for VPN clients
ASA(config)# ip local pool VPN-POOL 10.99.99.10-10.99.99.250 mask 255.255.255.0
! Enable AnyConnect on the outside interface
ASA(config)# webvpn
ASA(config-webvpn)# enable outside
ASA(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.10.05085-webdeploy-k9.pkg
ASA(config-webvpn)# anyconnect enable
User opens AnyConnect, connects to the ASA’s public IP, authenticates, gets an IP in the 10.99.99.0/24 pool, can reach the 10.0.0.0/16 corporate networks (per SPLIT-ACL).
ZTNA — the trend replacing traditional VPN
Traditional VPNs grant broad network access — once you’re in, you can probe every IP on the subnet. ZTNA (Zero Trust Network Access) is the modern alternative: grant access only to specific applications, on a per-session basis, after continuous verification.
Cisco’s ZTNA play: Cisco Secure Access (the rebranded / unified successor product to AnyConnect + Umbrella + various other pieces). Users access apps through a cloud broker — no broad network footprint exposed.
For CCNA: know ZTNA exists as the modern alternative to VPN. AnyConnect and traditional VPN are still everywhere — won’t disappear quickly.
Common mistakes
-
No MFA. Username + password VPN access in 2026 is irresponsible. Phishing + credential stuffing → attacker on your VPN with full network access. Always require MFA.
-
Default address pool exposed to all VLANs. A VPN user gets an IP from a pool that has unrestricted access to the entire LAN → if their laptop is compromised, the attacker is now inside. Restrict VPN-pool access with ACLs.
-
Split tunnel without DNS security. User on split tunnel resolves DNS via their home ISP — including malicious sites. Pair split-tunnel deployments with Cisco Umbrella or similar DNS-layer security.
-
Full tunnel with insufficient HQ bandwidth. All employees backhaul their Netflix → corp WAN saturated. Plan for it or switch to split tunnel.
-
Long session timeouts. A 30-day VPN session = lost laptop = 30 days of attacker access. Set reasonable session limits + idle timeouts (8-12 hours typical).
-
No client-posture check. Allowing any laptop to connect — out-of-date OS, no antivirus, jailbroken. AnyConnect supports posture checking (Cisco ISE integration) — use it for high-security envs.
-
Skipping certificate validation. Client must validate the VPN server’s TLS cert against a trusted CA. Without that, attacker can MITM the connection. Always deploy proper certs.
Lab to try tonight
If you have access to a Cisco ASA or FTD:
- Configure a basic remote-access VPN per the config above. Use a local user database for testing.
- Download Cisco Secure Client (free trial from Cisco’s site or via DevNet sandbox).
- Connect from your laptop to the ASA’s public IP. Verify authentication.
- Verify you got an IP in the pool. Ping internal resources.
- Test split tunnel: ping an internal IP (goes via VPN) and
traceroute google.com(should go via your local internet). - Switch to full tunnel and observe
traceroute google.comnow goes via the ASA’s internet. - Bonus: integrate with RADIUS (FreeRADIUS works for lab) and add MFA via Duo or similar.
Cheat strip
| Concept | Plain English |
|---|---|
| AnyConnect / Cisco Secure Client | The end-user VPN client |
| ASA / FTD | The corporate-side VPN concentrator |
| SSL/TLS VPN | TCP 443 — works through most firewalls. Default. |
| IKEv2 | UDP 500/4500 — lighter, mobile-friendly |
| Full tunnel | All user traffic via VPN |
| Split tunnel | Only corp traffic via VPN |
| MFA | Mandatory in 2026 — password alone is unacceptable |
| Address pool | The IP range VPN clients pull from |
| Group policy | Defines what each VPN-group can do |
| ZTNA | Modern alternative — per-app access, not network-wide |