Perché il remote access VPN è centrale in SCOR
Il remote access VPN (RA VPN) permette a un singolo utente remoto di stabilire un tunnel cifrato verso la rete aziendale, tipicamente terminato su un headend che agisce da gateway. Nel blueprint 350-701 devi saper scegliere fra i due modelli di trasporto (SSL/TLS vs IPsec/IKEv2), fra i due modelli di accesso (clientless vs full client) e fra le due politiche di instradamento (full tunnel vs split tunnel), motivando ogni scelta in base allo scenario.
SSL/TLS vs IPsec/IKEv2
| Aspetto | SSL/TLS (Secure Client) | IPsec/IKEv2 |
|---|---|---|
| Porte tipiche | TCP 443 (TLS) + UDP 443 (DTLS) | UDP 500 / UDP 4500 (NAT-T) |
| Attraversamento firewall/NAT | Ottimo: 443 quasi sempre aperto | Richiede NAT-T e porte dedicate |
| Performance traffico real-time | DTLS su UDP evita l’overhead TCP-in-TCP | Nativamente efficiente |
| Uso tipico | Client mobili/roaming, reti ostili | Site-agnostic, policy IPsec richieste |
Il Cisco Secure Client (ex AnyConnect) negozia prima un canale TLS di controllo, poi tenta di aprire DTLS per il data plane: se un firmware o proxy blocca UDP 443, il client fa fallback su TLS, con impatto su latenza e jitter. Concetto d’esame: DTLS migliora voce/video perché elimina il fenomeno del TCP meltdown (ritrasmissioni TCP annidate). Il Secure Client supporta anche IKEv2 come trasporto alternativo quando la policy aziendale impone IPsec.
Clientless vs full client
- Clientless SSL VPN: l’utente accede via browser a un portale; l’headend funge da reverse proxy per applicazioni web (HTTP/HTTPS), con supporto limitato a smart tunnel, port forwarding e plugin (RDP, VNC via applet). Non installa nulla, ma copre solo applicazioni compatibili. Nota critica: il clientless è supportato solo su ASA, non su FTD.
- Full client (Secure Client): installa un adattatore virtuale che assegna un IP dal pool interno, offrendo accesso a livello di rete (qualsiasi protocollo IP, non solo web). È l’unica modalità RA VPN supportata su Secure Firewall Threat Defense (FTD).
Regola pratica: se servono applicazioni non-web (SSH, thick client, SMB, protocolli custom) o accesso IP completo, serve il full client. Se basta l’accesso occasionale a poche web app da un dispositivo non gestito, il clientless riduce il footprint.
Split tunnel vs full tunnel
- Full tunnel: tutto il traffico dell’endpoint attraversa l’headend, incluso quello verso Internet. Massima ispezione (il traffico passa da firewall, IPS, Umbrella/DNS security, proxy) ma consuma banda dell’headend e aggiunge latenza.
- Split tunnel: solo il traffico verso subnet corporate definite entra nel tunnel; il resto esce direttamente dalla connessione locale dell’utente.
Si configura tramite group policy con split-tunnel-policy (tunnelspecified / excludespecified) e una ACL che elenca le reti protette; sul Secure Client la logica è espressa nel profilo XML.
Per-app VPN
Su dispositivi mobili gestiti (MDM), il per-app VPN tunnella solo il traffico di applicazioni specifiche, lasciando le app personali fuori. È un split tunneling applicativo, non basato su subnet: utile per BYOD dove non si vuole tunnellare l’intero dispositivo.
Deployment dell’headend
- FTD / Secure Firewall: gestito da FMC (o FDM) tramite un wizard RA VPN che lega connection profile, group policy, address pool, autenticazione (Cisco ISE via RADIUS, LDAP/AD, certificati, SAML) e posture con ISE. Solo Secure Client.
- ASA: supporta sia Secure Client sia clientless; usa tunnel-group (connection profile) + group-policy.
Trappole tipiche d’esame
- Scenario: l’utente deve accedere a un’app legacy client-server non-web → risposta giusta: full client (Secure Client), perché il clientless copre solo applicazioni web/proxabili.
- Scenario: si richiede RA VPN su FTD con portale browser senza installare software → risposta giusta: non è possibile: FTD supporta solo Secure Client; il clientless richiede ASA.
- Scenario: lo split tunneling è attivo e il security team teme che il traffico Internet dell’endpoint bypassi l’ispezione → risposta giusta: lo split tunnel esce direttamente evitando firewall/IPS/proxy aziendali; mitigare con full tunnel o con Umbrella roaming sul client per garantire DNS/web security anche fuori tunnel.
- Scenario: voce/video su RA VPN soffrono di latenza e ritrasmissioni → risposta giusta: abilitare DTLS (UDP 443); il tunnel TLS puro su TCP causa TCP-over-TCP meltdown.
- Scenario: BYOD dove solo l’app aziendale deve usare la VPN → risposta giusta: per-app VPN via MDM, non full tunnel.