Perché route-based invece di policy-based

Quando si collega un edge Cisco IOS-XE al VPN gateway di un provider cloud, la scelta architetturale di partenza è tra VPN policy-based e route-based. La policy-based lega la cifratura a una crypto ACL (i cosiddetti proxy ID o traffic selector): ogni subnet da proteggere va elencata esplicitamente, e ogni aggiunta richiede di ritoccare la ACL su entrambi i lati. La route-based invece incapsula tutto ciò che viene instradato dentro una Virtual Tunnel Interface (VTI): il traffic selector diventa 0.0.0.0/0 ↔ 0.0.0.0/0 e a decidere cosa passa nel tunnel è la routing table, non una ACL.

Nel contesto cloud questa è quasi sempre la scelta corretta, per tre ragioni:

  • Scalabilità delle subnet: le VPC/VNet cloud crescono nel tempo; con la VTI non serve rinegoziare i proxy ID a ogni nuova subnet.
  • Routing dinamico: la VTI è un’interfaccia IP a tutti gli effetti, quindi ci si può far girare sopra BGP o un IGP.
  • Interoperabilità: la maggior parte dei cloud gateway pubblica VPN route-based con BGP come modello di riferimento.

Il ruolo della VTI

La VTI (tunnel mode ipsec ipv4) è un’interfaccia logica stateful che rappresenta il tunnel IPsec. Il traffico che viene instradato verso la Tunnel interface viene cifrato e incapsulato in ESP; ciò che arriva cifrato viene decifrato e consegnato al routing. A differenza di GRE-over-IPsec, la VTI IPsec non aggiunge un header GRe: incapsula direttamente in ESP, riducendo overhead. Il profilo crittografico (IKEv2 proposal/policy, keyring, IPsec transform-set e IPsec profile) viene agganciato alla Tunnel con tunnel protection ipsec profile.

interface Tunnel1
 ip address 169.254.1.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination <cloud-gw-public-ip>
 tunnel protection ipsec profile CLOUD-PROFILE

Gli IP 169.254.x.x sull’interfaccia sono tipici: il cloud gateway assegna una APIPA /30 come link di transito su cui stabilire il peering BGP.

BGP sopra la VTI

Con la VTI attiva, il tunnel diventa un semplice link punto-punto e ci si costruisce sopra una sessione eBGP (il cloud usa un proprio ASN, spesso privato tipo 64512 o un valore assegnato dal provider). Il peer BGP è l’indirizzo 169.254.x.x del gateway remoto, non il suo IP pubblico:

router bgp 65001
 neighbor 169.254.1.2 remote-as 64512
 address-family ipv4
  neighbor 169.254.1.2 activate
  network 10.0.0.0 mask 255.255.0.0

BGP annuncia le subnet on-prem verso il cloud e riceve i prefissi della VPC/VNet. Su topologie ridondate (due tunnel verso lo stesso gateway o verso due gateway) BGP fornisce automaticamente il failover: si influenzano i percorsi con AS-path prepend, local-preference o MED senza toccare la cifratura.

La trappola dell’MTU/MSS

Il problema operativo più insidioso — e ricorrente all’esame — è la frammentazione. L’incapsulamento ESP (più eventuale UDP/4500 per il NAT-T) riduce l’MTU effettiva del payload a circa 1400 byte o meno. Se un host interno invia un pacchetto da 1500 byte con DF-bit settato, l’edge non può frammentare e lo scarta, generando i sintomi classici: il ping piccolo passa, i trasferimenti grandi (HTTPS, file, database) si bloccano o vanno a scatti.

La soluzione è duplice:

Meccanismo Comando (sull’interfaccia Tunnel) Cosa fa
MTU del tunnel ip mtu 1400 Limita la dimensione IP dei pacchetti incapsulati
TCP MSS clamping ip tcp adjust-mss 1360 Riscrive l’MSS nei SYN TCP così gli host negoziano segmenti più piccoli

L’adjust-mss è la difesa più robusta perché agisce sull’handshake TCP e non dipende dal corretto funzionamento del Path MTU Discovery (spesso rotto da firewall che bloccano l’ICMP fragmentation needed). Valore tipico: 1360 (1400 − 40 di header TCP/IP).

Trappole tipiche d’esame

  • Scenario: nuova subnet nella VPC non raggiungibile ma il tunnel è UP → risposta: con VTI route-based non si toccano i proxy ID; verifica che BGP annunci/riceva il prefisso (probabilmente manca la network o un filtro lo blocca).
  • Scenario: SSH/ping funzionano ma download e sessioni HTTPS si interrompono → risposta: MTU/MSS. Applica ip tcp adjust-mss 1360 (e ip mtu 1400) sulla Tunnel.
  • Scenario: la sessione BGP non sale pur avendo il tunnel attivo → risposta: il neighbor BGP è l’IP APIPA /30 interno al tunnel, non l’IP pubblico del gateway.
  • Scenario: richiesta di aggiungere decine di subnet senza rinegoziare IKE → risposta: VPN route-based/VTI, mai policy-based.
  • Scenario: tunnel su GRE-over-IPsec con overhead extra e MTU ancora più bassa → risposta: preferire VTI IPsec puro (tunnel mode ipsec ipv4), che non aggiunge l’header GRE.