VPN IPsec site-to-site tra Cisco e Windows Server (RRAS)

Quando ha senso usare RRAS

Windows Server include il ruolo Accesso remoto, con il servizio Routing e Accesso remoto (RRAS). Oltre a fare da server VPN per gli utenti, RRAS può collegare due sedi con un’interfaccia di connessione su richiesta (demand-dial): un’interfaccia virtuale che apre un tunnel IKEv2 verso l’altra sede e ci instrada le reti remote.

È una soluzione utile in sedi piccole dove c’è già un Windows Server e non c’è un firewall in grado di fare VPN, oppure come collegamento temporaneo durante una migrazione.

Lo scenario

La sede A è la stessa delle altre guide della serie, con il router Cisco. La sede C ha un Windows Server 2022 con due schede di rete: una verso Internet e una verso la LAN, di cui fa da gateway.

Scelta: VTI sul Cisco, non crypto map

L’interfaccia di RRAS è basata sul routing: si comporta come un’interfaccia di rete e le reti remote ci arrivano con delle rotte. Sul Cisco l’equivalente naturale è una VTI (tunnel mode ipsec ipv4), che negozia selettori di traffico “qualsiasi ↔ qualsiasi” e lascia decidere alle rotte. Con una crypto map dovresti far combaciare reti precise su entrambi i lati, cosa che RRAS gestisce male.

Gli algoritmi da allineare

Come in ogni VPN IPsec, i due lati devono proporre gli stessi algoritmi. Su RRAS li fissi con la politica personalizzata (-CustomPolicy); senza, Windows propone una lista ampia che comprende anche algoritmi deboli.

Per IKE uso AES-CBC con SHA-256 perché il cmdlet di RRAS non accetta AES-GCM come cifratura IKE. Per ESP, dove passa il traffico vero, AES-GCM è supportato su entrambi i lati ed è la scelta migliore.

Windows Server: installare RRAS

Prima di tutto rinomina le schede di rete con nomi chiari: ti serviranno nei comandi e nella diagnostica.

Get-NetAdapter
Rename-NetAdapter -Name "Ethernet"   -NewName "WAN"
Rename-NetAdapter -Name "Ethernet 2" -NewName "LAN"

# ruolo Accesso remoto con le funzioni di routing
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Install-WindowsFeature Routing -IncludeManagementTools -IncludeAllSubFeature

# configura RRAS per le VPN site-to-site
Install-RemoteAccess -VpnType VpnS2S

Install-RemoteAccess -VpnType VpnS2S avvia il servizio RRAS e abilita l’instradamento tra le interfacce. La scheda WAN non deve avere un gateway sulla LAN, e la scheda LAN non deve avere un gateway predefinito: il gateway predefinito sta solo sulla WAN.

Windows Server: l’interfaccia verso la sede A

Genera una chiave condivisa lunga e casuale, per esempio con openssl rand -base64 32 su qualunque Linux, e usala identica sui due lati. Quella qui sotto è solo un esempio.

Add-VpnS2SInterface -Name "SedeA" `
    -Destination 198.51.100.1 `
    -Protocol IKEv2 `
    -AuthenticationMethod PSKOnly `
    -SharedSecret "Esempio-Da-Sostituire-Con-Una-Chiave-Lunga" `
    -IPv4Subnet "192.168.10.0/24:100" `
    -Persistent `
    -InitiateConfigPayload $false `
    -CustomPolicy `
    -EncryptionMethod AES256 `
    -IntegrityCheckMethod SHA256 `
    -DHGroup ECP256 `
    -CipherTransformConstants GCMAES256 `
    -AuthenticationTransformConstants GCMAES256 `
    -PfsGroup ECP256 `
    -MMSALifeTimeSeconds 28800 `
    -SALifeTimeSeconds 3600 `
    -PassThru

Connect-VpnS2SInterface -Name "SedeA"

• -IPv4Subnet "192.168.10.0/24:100" crea una rotta verso la LAN A con metrica 100 attraverso questa interfaccia. Per più reti passa un elenco: @("192.168.10.0/24:100","10.10.10.0/24:100");
• -Persistent tiene il tunnel sempre attivo, anche dopo un riavvio del servizio. Senza, RRAS lo aprirebbe solo quando c’è traffico;
• -InitiateConfigPayload $false impedisce a Windows di chiedere al Cisco un indirizzo IP per l’interfaccia, come farebbe verso un altro server RRAS;
• con la chiave condivisa RRAS associa le connessioni in arrivo all’interfaccia il cui -Destination coincide con l’IP del mittente: anche il Cisco può quindi avviare il tunnel.

Per cambiare un parametro in seguito usa Set-VpnS2SInterface con gli stessi nomi, per esempio:

Set-VpnS2SInterface -Name "SedeA" -SharedSecret "Nuova-Chiave-Lunga-E-Casuale"
Disconnect-VpnS2SInterface -Name "SedeA" -Force
Connect-VpnS2SInterface -Name "SedeA"

Il firewall di Windows

IKEv2 usa UDP 500 e, con il NAT, UDP 4500; senza NAT il traffico cifrato è ESP (protocollo IP 50). Autorizza solo il router della sede A, come spiegato nella guida Windows Server: firewall e protezione di base con PowerShell:

New-NetFirewallRule -DisplayName "VPN sede A - IKE" `
    -Direction Inbound -Protocol UDP -LocalPort 500,4500 `
    -RemoteAddress 198.51.100.1 -Action Allow -Profile Any

New-NetFirewallRule -DisplayName "VPN sede A - ESP" `
    -Direction Inbound -Protocol 50 `
    -RemoteAddress 198.51.100.1 -Action Allow -Profile Any

L’installazione di RRAS aggiunge già alcune regole proprie (gruppo “Routing e Accesso remoto”): controllale con Get-NetFirewallRule -DisplayGroup "Routing*" e disattiva quelle che non usi, come PPTP e L2TP. Il traffico instradato tra la LAN C e il tunnel non passa dalle regole del Windows Firewall, che filtrano solo il traffico diretto al server stesso.

Configurazione del router Cisco

configure terminal
!
crypto ikev2 proposal PROP-SEDE-C
 encryption aes-cbc-256
 integrity sha256
 group 19
!
crypto ikev2 policy POL-SEDE-C
 match address local 198.51.100.1
 proposal PROP-SEDE-C
!
crypto ikev2 keyring KR-SEDE-C
 peer SEDE-C
  address 192.0.2.10
  pre-shared-key Esempio-Da-Sostituire-Con-Una-Chiave-Lunga
!
crypto ikev2 profile PROF-SEDE-C
 match identity remote address 192.0.2.10 255.255.255.255
 identity local address 198.51.100.1
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-SEDE-C
 lifetime 28800
 dpd 10 5 on-demand
 no config-exchange request
!
crypto ipsec transform-set TS-SEDE-C esp-gcm 256
 mode tunnel
!
crypto ipsec profile IPSEC-SEDE-C
 set transform-set TS-SEDE-C
 set pfs group19
 set security-association lifetime seconds 3600
 set ikev2-profile PROF-SEDE-C
!
interface Tunnel2
 description VPN IPsec verso sede C (Windows Server RRAS)
 ip unnumbered GigabitEthernet0/1
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 192.0.2.10
 tunnel protection ipsec profile IPSEC-SEDE-C
!
ip route 192.168.30.0 255.255.255.0 Tunnel2
!
end
write memory

• ip unnumbered evita di inventare una rete di transito: RRAS non assegna un indirizzo alla sua interfaccia S2S, quindi una /30 sul tunnel non servirebbe a nulla;
• no config-exchange request è il corrispettivo di -InitiateConfigPayload $false: niente richieste di configurazione tra i due lati;
• ip mtu 1400 e ip tcp adjust-mss 1360 lasciano spazio alle intestazioni ESP e NAT-T. Il Cisco corregge l’MSS dei SYN in entrambe le direzioni, quindi basta farlo qui.

Se sulla WAN hai una access list in ingresso, aggiungi:

ip access-list extended WAN-IN
 permit udp host 192.0.2.10 host 198.51.100.1 eq isakmp
 permit udp host 192.0.2.10 host 198.51.100.1 eq non500-isakmp
 permit esp host 192.0.2.10 host 198.51.100.1

Rotte nelle due LAN

Le due rotte principali sono già a posto: ip route … Tunnel2 sul Cisco e -IPv4Subnet su RRAS. Restano i client:

• nella sede C i PC devono usare Windows Server (192.168.30.1) come gateway. Se il gateway della LAN C è un altro router, aggiungi su quel router una rotta verso 192.168.10.0/24 via 192.168.30.1;
• nella sede A i PC usano già il Cisco come gateway, che conosce la rotta verso il tunnel.

Se la sede A è collegata anche alla sede B (VPN IPsec tra Cisco e Ubuntu) e vuoi far parlare B e C passando per A, ti servono due modifiche:

• su RRAS aggiungi 192.168.20.0/24 all’elenco -IPv4Subnet;
• sul collegamento tra A e B aggiungi la rete 192.168.30.0/24: ai selettori di traffico se quel tunnel usa una crypto map, alle rotte se usa una VTI o GRE.

Il Cisco sa già raggiungere entrambe le sedi, quindi sulla Tunnel2 non serve altro.

Verifiche

Su Windows Server

Get-VpnS2SInterface -Name "SedeA" |
    Format-List Name, Destination, ConnectionState, LastError, IPv4Subnet

Get-NetRoute -DestinationPrefix 192.168.10.0/24
Test-NetConnection 192.168.10.1
Test-NetConnection 192.168.10.10 -Port 445

# eventi del servizio RRAS
Get-WinEvent -LogName System -MaxEvents 30 |
    Where-Object ProviderName -eq "RemoteAccess"

ConnectionState deve essere Connected e LastError pari a 0. Un valore diverso da zero è un codice di errore Windows: lo decodifichi con [ComponentModel.Win32Exception]13868 (sostituisci il numero).

Sul router Cisco

show crypto ikev2 sa detailed          ! stato READY, algoritmi negoziati
show crypto ipsec sa peer 192.0.2.10   ! contatori encaps/decaps in crescita
show interfaces Tunnel2                ! up/up
show ip route 192.168.30.0
ping 192.168.30.1 source GigabitEthernet0/1

Se il tunnel non sale, accendi il debug per pochi minuti e poi spegnilo:

debug crypto ikev2
debug crypto ikev2 error
! ... prova la connessione ...
undebug all

Problemi comuni

Il passo successivo

Con questa guida la sede A è collegata sia alla sede B Linux sia alla sede C Windows. Se le sedi crescono, valuta un protocollo di routing dinamico sopra i tunnel, come visto in GRE su IPsec tra Cisco e Ubuntu: RRAS però non lo gestisce bene sulle interfacce S2S, ed è un’altra buona ragione per sostituirlo con un apparato dedicato quando la sede C diventa importante. Per dare accesso anche agli utenti remoti vedi Accesso remoto IKEv2: client Windows verso Ubuntu con strongSwan.