VPN site-to-site IPsec: collegare due sedi aziendali

Una VPN site-to-site unisce due reti locali su Internet in modo che i dispositivi si vedano come se fossero sullo stesso cablaggio. A differenza della VPN client, non richiede software sui PC: il tunnel vive fra i due router perimetrali ed è trasparente per gli utenti.

Quando serve davvero

Il caso tipico è la sede secondaria che deve raggiungere risorse centralizzate: gestionale, file server, centralino, NAS di backup, telecamere. Altri scenari frequenti:

• Interni VoIP registrati sul PBX della sede principale senza esporre il SIP su Internet
• Replica notturna di backup fra due NAS
• Accesso amministrativo a apparati di rete su management VLAN non esposta

Se il traffico è solo web o SaaS, una VPN site-to-site non serve. Ha senso quando esiste traffico applicativo verso IP privati.

Le due fasi di IKE

IPsec negozia il tunnel in due passaggi distinti. Confonderli è la prima causa di configurazioni che "sembrano giuste" ma non salgono.

Fase 1 (IKE SA) autentica i due peer e crea un canale sicuro per la negoziazione successiva. Si concordano:

• Metodo di autenticazione: pre-shared key o certificati
• Algoritmo di cifratura (AES-256-CBC o AES-256-GCM)
• Hash di integrità (SHA-256 o superiore)
• Gruppo Diffie-Hellman (14, 19, 20 — evitare 1, 2 e 5)
• Lifetime, tipicamente 8 ore

Fase 2 (Child SA / IPsec SA) definisce quale traffico entra nel tunnel e come viene cifrato. Qui si concordano proposal, PFS group e soprattutto i selettori: le coppie di subnet locale e remota. Se i selettori non combaciano esattamente sui due lati, la fase 2 non si stabilisce anche con la fase 1 perfettamente up.

Usate IKEv2 salvo vincoli di compatibilità: gestisce meglio il riaggancio, supporta MOBIKE e ha una negoziazione più snella di IKEv1.

Il piano di indirizzamento viene prima della configurazione

Il tunnel non può funzionare se le due sedi usano la stessa subnet. 192.168.1.0/24 su entrambi i lati è lo scenario più comune e il più fastidioso da risolvere a posteriori, perché richiede NAT 1:1 dentro il tunnel.

Assegnate subnet distinte fin dall'inizio, per esempio:

• Sede A: 10.10.0.0/24
• Sede B: 10.20.0.0/24
• Terza sede futura: 10.30.0.0/24

Uno schema 10.X.0.0/24 per sede lascia spazio a crescita e rende leggibili le regole di firewall.

Esempio su MikroTik (RouterOS 7)

Configurazione route-based con interfaccia virtuale, più pulita da gestire rispetto alla policy-based classica.

# --- Sede A (WAN 203.0.113.10, LAN 10.10.0.0/24) ---

# Profilo fase 1: parametri IKE
/ip ipsec profile
add name=vpn-b dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=8h

# Proposal fase 2: cifratura del traffico dati
/ip ipsec proposal
add name=vpn-b auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048

# Peer remoto
/ip ipsec peer
add name=sede-b address=198.51.100.20/32 exchange-mode=ike2 profile=vpn-b

# Autenticazione con PSK (usare una chiave lunga e casuale)
/ip ipsec identity
add peer=sede-b auth-method=pre-shared-key secret="CHIAVE_LUNGA_CASUALE"

# Policy: definisce i selettori, cioe' quale traffico entra nel tunnel
/ip ipsec policy
add peer=sede-b src-address=10.10.0.0/24 dst-address=10.20.0.0/24 \
    tunnel=yes proposal=vpn-b

# ESCLUDERE il traffico VPN dal NAT: senza questa regola i pacchetti
# escono mascherati e non matchano mai la policy IPsec
/ip firewall nat
add chain=srcnat place-before=0 src-address=10.10.0.0/24 \
    dst-address=10.20.0.0/24 action=accept

# Aprire le porte necessarie in input
/ip firewall filter
add chain=input protocol=udp dst-port=500,4500 src-address=198.51.100.20 action=accept
add chain=input protocol=ipsec-esp src-address=198.51.100.20 action=accept

Sulla sede B si replica invertendo src-address e dst-address e puntando il peer a 203.0.113.10.

I due problemi che si presentano sempre

MTU. L'incapsulamento IPsec aggiunge overhead: su una PPPoE a 1492 byte, dentro il tunnel restano circa 1400 byte utili. Il sintomo è caratteristico: il ping funziona, la navigazione HTTP verso la sede remota si blocca a metà pagina, le condivisioni SMB si piantano su file grandi. La soluzione è il clamping:

/ip firewall mangle
add chain=forward action=change-mss new-mss=1360 passthrough=yes \
    protocol=tcp tcp-flags=syn src-address=10.10.0.0/24 dst-address=10.20.0.0/24

NAT sul percorso. Se una delle due sedi è dietro CGNAT o non ha IP pubblico statico, il tunnel non può essere iniziato da entrambi i lati. Con NAT-T (UDP 4500) il lato dietro NAT può comunque avviare la connessione verso il peer con IP pubblico, ma servono un IP fisso su almeno un lato e dpd-interval configurato per rilevare la caduta.

Alternative da valutare

WireGuard è più semplice da configurare e più veloce su hardware modesto, ma non ha negoziazione dinamica dei selettori né interoperabilità con firewall enterprise legacy. GRE over IPsec resta utile quando serve far passare protocolli di routing dinamico o traffico multicast, che IPsec puro non trasporta.

Checklist di verifica

• Fase 1 established ma nessun traffico → selettori fase 2 disallineati
• Tunnel up, ping ok, applicazioni lente o bloccate → MSS clamping mancante
• Tunnel che cade e non risale da solo → DPD assente su uno dei due lati
• Traffico che esce in chiaro → regola di bypass NAT posizionata dopo il masquerade