Risoluzione dei problemi IPsec VPN su Sophos Firewall

Nella risoluzione dei problemi IPsec, l’ordine è fondamentale: verificare prima IKE e la Child SA, poi le regole firewall, NAT, routing e il percorso di ritorno. Un tunnel verde conferma solo la negoziazione, non che il traffico utente funzioni.

Per un nuovo tunnel, consultare prima Configurare una VPN IPsec Site-to-Site su Sophos Firewall. I passaggi seguenti si applicano a una connessione già configurata.

Percorso diagnostico

Il tunnel rimane down: verificare in strongswan.log la versione IKE, il profilo IPsec, il gateway, Local/Remote ID, il PSK o il certificato.
La Fase 1 è attiva, ma non c’è una Child SA: confrontare Traffic Selectors, proposta di Fase 2, PFS e subnet.
Il tunnel è verde: con ipsec statusall verificare che la SA sia ESTABLISHED, che la Child SA sia INSTALLED e che i contatori di byte aumentino.
Solo una direzione conta byte: verificare regole firewall, NAT, routing e in particolare il percorso di ritorno sulla controparte.
La causa rimane incerta: seguire un singolo flusso di test con Log Viewer e Packet Capture.
Il firewall va ripetutamente in crash con traffico multicast su VPN: non provocare il problema con ulteriori test di carico. Registrare versione del firmware, orari e dati diagnostici disponibili; NC-180433 è risolto in SFOS 22.0 MR2 Build 546.

Prima sono sufficienti pochi valori documentati: nome del tunnel, IP o FQDN del peer, versione IKE, Local/Remote ID, reti locali e remote, policy-based o route-based, profilo IPsec e un test con Source, Destination e Service. Esempio: tunnel azure-vpn, rete locale 172.16.10.0/24, rete remota 10.20.30.0/24.

Con IPsec policy-based, le reti fanno parte della negoziazione. IPsec route-based utilizza un’interfaccia XFRM e rotte statiche, SD-WAN o dinamiche. Se il percorso è errato, sono utili le guide separate sulle rotte IPsec e sulla Route Precedence.

⚠️ I log e i Packet Capture possono contenere indirizzi IP pubblici, reti interne, nomi host o dati utente. Raccoglierli solo in modo mirato e per un periodo limitato, e controllarli prima di condividerli.

Verificare log e CLI

In Site-to-site VPN > IPsec, Show additional properties mostra tra l’altro Local subnet, Remote subnet, Gateway type e Profile. Anche in Profiles > IPsec profiles è possibile confrontare direttamente i valori di Fase 1 e Fase 2.

I file più importanti in /log sono:

strongswan.log: IKE, autenticazione e Child SA
charon.log: demone IKE
ipsec_monitor.log: monitoraggio del servizio IPsec
/log/ipsec_conn/ipsec_<connectionname>.log: azioni Connect, Activate e Deactivate nel WebAdmin
xfrmi.log: interfacce XFRM
dgd.log: Dead Gateway Detection e failover VPN

L’elenco centrale aggiornato dei log di SFOS 22 indica ipsec_monitor.log. Una pagina Sophos meno recente dedicata alla risoluzione dei problemi riporta ancora strongswan-monitor.log; per i sistemi SFOS 22 attuali fa fede l’elenco più recente.

Nella Advanced Shell è possibile seguire o filtrare il log principale. Se l’accesso SSH e alla shell non è ancora familiare, consultare Risoluzione dei problemi CLI su Sophos Firewall: comandi importanti.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Le righe sono alternative, non una sequenza unica. In less, /suchbegriff esegue una ricerca nel file.

Debug di StrongSwan

Se il log normale non è sufficiente, controllare prima lo stato attuale nella Advanced Shell:

service -S | grep strongswan

Se è già presente RUNNING,DEBUG, non eseguire nuovamente il toggle credendo di attivare il debug. Utilizzare il debug già attivo e poi disattivarlo come descritto di seguito.

⚠️ Lasciare il debug attivo solo per breve tempo. Può generare rapidamente file di log di grandi dimensioni e occupare spazio di archiviazione.

Se il debug non è ancora attivo, eseguire il toggle, controllare il nuovo stato e riprodurre il problema esattamente una volta:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

Per strongswan dovrebbe apparire RUNNING,DEBUG. In seguito lo stesso comando disattiva nuovamente la modalità debug; il secondo comando conferma il ripristino:

service strongswan:debug -ds nosync
service -S | grep strongswan

Verificare l’instaurazione del tunnel

Fase 1: IKE, ID e autenticazione

Se il tunnel non viene instaurato, in genere non corrispondono la versione IKE, il gateway, gli ID, la proposta, il PSK o il certificato.

no IKE config found o Remote peer is refusing our Phase 1 proposals: il firewall non trova una connessione adatta oppure il profilo non corrisponde. Verificare versione IKE, Listening Interface, indirizzo peer, Local/Remote ID e profilo.
peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found o Remote peer reports we failed to authenticate: gli ID e l’autenticazione non corrispondono alla configurazione peer prevista.
invalid HASH_V1 payload length o decryption failed: con IKEv1 spesso indica un PSK errato; con IKEv2 appare più comunemente AUTH_FAILED.
La controparte raggiunge un altro indirizzo pubblico oppure UDP 500/4500 non viene inoltrato correttamente da NAT, router o provider.
Per i certificati non corrispondono la catena di certificati, la CA emittente, la validità o l’ID previsto.

Il Local ID di una parte deve corrispondere al Remote ID dell’altra e viceversa. È consigliabile reimpostare il PSK su entrambe le parti; spazi invisibili o errori di copia e incolla dai gestori di password sono cause frequenti. Un ID errato può impedire l’associazione al peer prima ancora che venga controllato il PSK previsto.

Fase 2: Traffic Selectors e Child SA

Se la Fase 1 è attiva ma manca una Child SA, in genere le subnet o i valori di Fase 2 sono diversi.

traffic selectors ... inacceptable
failed to establish CHILD_SA
received traffic selectors didn't match
Remote peer reports INVALID_ID_INFORMATION
valori diversi per TSi e TSr
NO_PROPOSAL_CHOSEN dopo Phase 1 is up e Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN da solo non basta per classificare il problema: prima della Fase 1 indica valori IKE/Fase 1; dopo una Fase 1 riuscita indica ESP, PFS o altri valori di Fase 2.

Le reti devono essere speculari. Se Sophos prevede localmente 172.16.10.0/24 e remotamente 10.20.30.0/24, la controparte deve offrire 10.20.30.0/24 verso 172.16.10.0/24. Anche un /24 da una parte e un singolo host o oggetti host gestiti diversamente dall’altra possono impedire la Child SA.

Il tunnel è attivo, ma non passa traffico

Nella Advanced Shell, questo comando mostra le SA, le reti negoziate e i contatori di byte:

ipsec statusall

Sono importanti ESTABLISHED, INSTALLED e i contatori in entrambe le direzioni. Se entrambi rimangono vuoti, il traffico di test probabilmente non raggiunge il tunnel. Se aumenta solo il lato in uscita, in genere manca il percorso di ritorno o una regola sulla controparte; se aumentano solo i byte in entrata, sono sospetti la rotta locale, la regola locale o il sistema di destinazione.

Seguire un flusso di test

Un test preciso è più indicativo di più ping paralleli:

Source IP: 172.16.10.25
Destination IP: 10.20.30.15
Service: ICMP o TCP 443
direzione prevista: da LAN a VPN
regola prevista: LAN_to_VPN_Branch

Procedere quindi in questo ordine:

Attivare Log firewall traffic nella regola interessata.
Filtrare Log Viewer per Source, Destination e Rule ID.
Avviare Packet Capture con host 172.16.10.25 and host 10.20.30.15.
Eseguire il test esattamente una volta.
Confrontare regola, NAT Rule ID, inoltro, risposta e contatori di byte.
Sulla controparte verificare rotta di ritorno, regola remota e sistema di destinazione.

Se nessun pacchetto raggiunge Sophos Firewall, la causa si trova prima del firewall, ad esempio nel gateway del client, nella VLAN o nel routing locale. Se arriva ma non viene inoltrato, non corrispondono regola, NAT, rotta o una Security Feature. La procedura completa è descritta in Verificare una regola firewall con Log Viewer, Policy Test e Packet Capture.

Routing e XFRM

Con IPsec policy-based, SFOS 22 gestisce le rotte VPN nel backend. Le rotte IPsec manuali e la Route Precedence si verificano nella Device Console:

system ipsec_route show
system route_precedence show

Il comando noto dalle procedure di troubleshooting precedenti non è una prova affidabile di un tunnel policy-based in SFOS 22 quando viene eseguito nella Advanced Shell:

ip route show table 220

In SFOS 22, le rotte VPN policy-based e le voci manuali ipsec_route non sono visibili in questa tabella. L’assenza di una voce non dimostra quindi né la mancanza di una rotta né un errore di routing.

Con IPsec route-based devono essere presenti una rotta statica, SD-WAN o dinamica verso l’interfaccia XFRM e stati XFRM corrispondenti. Verificare l’interfaccia XFRM in Network > Interfaces e il percorso in Diagnostics > Tools > Route lookup; la Device Console mostra le rotte statiche configurate:

show static-route

Gli stati XFRM si verificano nella Advanced Shell:

ip xfrm state
ip xfrm policy

Le interfacce XFRM non devono utilizzare reti di transito sovrapposte. Le connessioni con subnet locali e remote identiche devono appartenere a un gruppo failover comune o richiedono una logica di selezione e routing chiaramente diversa.

Verificare NAT in base al tipo di tunnel

NAT è consentito, ma deve corrispondere al tipo di tunnel e agli indirizzi previsti dalla controparte.

Policy-based con SNAT: la regola SNAT prevista richiede Outbound interface Any. La regola SNAT predefinita con porte WAN specifiche non intercetta il traffico IPsec policy-based.
Route-based con Any/Any o Dual: MASQ traduce la Source nell’IP XFRM, visibile nell’header IP interno di Packet Capture.
Route-based con Traffic Selectors specifici: se una regola MASQ corrisponde, il firewall scarta il traffico perché a tali interfacce XFRM non è assegnato un indirizzo IP.

La Source originale e quella tradotta devono essere documentate, consentite sulla controparte e dotate di una rotta di ritorno. I principi di base e l’ordine delle regole sono descritti in NAT su Sophos Firewall.

Instabilità e casi particolari di SFOS 22

Se il traffico si interrompe solo in seguito, confrontare i timestamp nello stato del tunnel, in strongswan.log, in dgd.log, negli eventi WAN e nel test dell’applicazione. Cause frequenti:

Il prodotto di terze parti utilizza traffic-based Rekeying; Sophos Firewall supporta time-based Rekeying.
Entrambe le parti eseguono il rekey contemporaneamente. Scaglionare intenzionalmente le Key Lifetime di Fase 1 e Fase 2 di Initiator e Responder.
L’interfaccia assegnata è stata disattivata. I tunnel initiator si disconnettono immediatamente, quelli responder al più tardi dopo inattività o timeout DPD.
Più connessioni con le stesse subnet non appartengono allo stesso gruppo failover.
I trasferimenti di grandi dimensioni non riescono nonostante un piccolo test funzioni; in tal caso verificare MTU e MSS.

Crash ripetuti del firewall con traffico multicast su VPN

Se i crash coincidono con traffico multicast che attraversa un tunnel VPN, registrare prima versione e build del firmware, tunnel interessato, orari e dati diagnostici o di crash disponibili. Sophos conferma il problema con l’ID NC-180433 e lo ha risolto in SFOS 22.0 MR2 Build 546.

La descrizione pubblica del problema non indica un tipo di tunnel o una configurazione multicast specifici, né un workaround CLI. Su una build precedente di SFOS 22, verificare il percorso di aggiornamento, passare a MR2 Build 546 o a una versione approvata più recente e quindi ripetere lo stesso traffico in modo controllato. Non modificare per ipotesi parametri del tunnel, IPsec Acceleration o servizi. Se il firewall continua ad andare in crash con MR2 o versioni successive, fornire i dati raccolti a Sophos Support invece di continuare ad attribuire automaticamente il problema a NC-180433.

I pacchetti IKEv2 vengono frammentati

Nel Known Issue NC-136352, il profilo IKEv2 predefinito può offrire così tanti gruppi DH che i pacchetti IKE superano 1'500 byte. Se un componente intermedio scarta i frammenti o le informazioni PMTU, l’Initiator continua a trasmettere mentre il Responder non riceve nulla.

Per questo specifico comportamento, verificare il peer nella Advanced Shell:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Nel profilo IPsec offrire poi solo il gruppo DH effettivamente necessario o un numero significativamente inferiore di gruppi. I filtri tcpdump generali e l’esportazione PCAP sono descritti in tcpdump su Sophos Firewall.

Alias PPPoE e IPsec Acceleration

NC-181526 interessa SFOS 22.0 GA Build 411 o MR1 Build 490 su determinati dispositivi XGS fisici: il tunnel utilizza un’interfaccia alias di una porta PPPoE-WAN, è connesso, ma con IPsec Acceleration attiva non trasporta dati utente. Sono esclusi XGS 88/88w, 108/108w, 118/118w e 128/128w.

L’attuale Sophos Known Issues List indica SFOS 22.0.2 MR2 Build 546 come versione corretta; tuttavia, la lista delle correzioni MR2 pubblicata non riporta separatamente NC-181526. Dopo l’aggiornamento, ripetere quindi lo stesso flusso di test invece di dedurre la correzione dalla sola versione.

⚠️ La disattivazione di IPsec Acceleration è globale, riavvia tutti i tunnel IPsec e causa un’interruzione. Eseguire il test in una finestra di manutenzione solo se build, hardware, alias PPPoE e comportamento corrispondono esattamente.

I seguenti comandi vengono eseguiti nella Device Console:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

Se non si osserva alcun miglioramento, ripristinare lo stato iniziale:

system ipsec-acceleration enable

SFOS 22.0 MR2 corregge con NC-180520 un caso simile ma diverso relativo all’IP alias: il gateway XFRM poteva rimanere irraggiungibile con Acceleration attiva se ESP entrava da un’altra porta WAN. I due Issue ID non devono essere confusi. Ulteriori verifiche prima e dopo l’aggiornamento sono raccolte nel controllo per l’upgrade a SFOS 22.

Verifica finale ed escalation

Dopo ogni modifica, ripetere lo stesso singolo flusso di test e documentare almeno questi punti:

Ora, nome del tunnel, IP del peer, Source, Destination e Service
Stato WebAdmin e ipsec statusall prima e dopo il test
Regola firewall e NAT associata
Packet Capture e contatori in entrambe le direzioni
Rotta di ritorno e regola remota sulla controparte
Modifica, risultato e rollback preparato

Disattivare poi il debug di StrongSwan. Raccogliere in modo mirato i log rilevanti per Sophos Support; Salvare i log di Sophos Firewall descrive l’esportazione. Prima di condividere pacchetti di log e acquisizioni più grandi, controllare che non contengano dati sensibili.