Sophos Firewall: diagnosticare sistematicamente una VPN IPsec

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.

Le impostazioni avanzate globali, come la pulizia delle sessioni al failover, la finestra anti-replay, la soglia dei cookie IKEv2 o l’uso di indirizzi peer già risolti, non vanno modificate come primo tentativo diagnostico. Usare in sicurezza le impostazioni VPN globali ne descrive effetto, controllo iniziale e rollback.

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.

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.

Prima della diagnosi tramite CLI, Current activities > IPsec connections mostra solo le connessioni IPsec attualmente stabilite. È possibile filtrare l’elenco per Connection name, Local server name, Local subnet, Username, Remote server/host o Remote subnet e ricaricarlo con Refresh. Disconnect interrompe attivamente la connessione selezionata e non è un aggiornamento innocuo: prima si documentano ora e stato, poi si disconnette solo in una finestra di test pianificata. Questa istantanea non sostituisce la verifica di Child SA, log e traffico.

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, /termine-di-ricerca esegue una ricerca nel file.

Debug di StrongSwan

Se il log normale non basta, annotare prima lo stato corrente nell’Advanced Shell:

service -S | grep strongswan

Se l’output indica già uno stato di debug attivo, non eseguire di nuovo il comando di commutazione. Chiarire prima chi lo ha attivato e perché; la sequenza seguente vale solo se il debug era inizialmente inattivo. Il testo esatto può variare in base alla build.

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

Se il debug non è attivo, eseguire il comando una volta e controllare il nuovo stato:

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

Seguire quindi strongswan.log in un secondo terminale, riprodurre il problema una sola volta e terminare tail con Ctrl+C:

tail -f /log/strongswan.log

Infine eseguire una volta lo stesso comando di commutazione. La seconda riga deve confermare il ripristino dello stato normale senza debug annotato in precedenza:

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.

Se un certificato è stato revocato prima della scadenza o l’effetto della revoca rimane incerto, verificare insieme issuer, numero di serie, thisUpdate, nextUpdate e rifiuto specifico del servizio. La procedura sicura è descritta in Importare e testare le Certificate Revocation Lists su Sophos Firewall.

Il Local ID di un lato deve corrispondere al Remote ID dell’altro e viceversa. Confrontare prima ID e PSK memorizzato su entrambi i lati. Se occorre reimpostare il PSK, coordinare la modifica sui due peer in una finestra di manutenzione; spazi invisibili e copia-incolla dai gestori di password sono cause frequenti. Un ID errato può impedire l’associazione del peer prima 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.

Per un confronto completo dei campi General settings, Phase 1, Phase 2 e DPD, consultare Comprendere e configurare in sicurezza i profili IPsec Sophos Firewall.

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 restano a zero o non aumentano, 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.

Packet Capture usa un buffer limitato e si arresta quando è pieno. La vista mostra fra l’altro Rule ID, NAT ID, Status e Reason. Durante una cattura standard, il traffico FastPath accelerato viene normalmente inviato temporaneamente attraverso SlowPath. Prima di considerare una cattura vuota o interrotta come prova dell’assenza di traffico, controllare buffer, filtro e momento del test.

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 crea le rotte VPN nel backend. Non compaiono nella normale vista di routing. Le IPsec Route manuali e la Route Precedence si leggono nella Device Console:

system ipsec_route show
system route_precedence show

L’ordine predefinito è static, sdwan_policyroute, vpn. L’assenza di una voce nella normale vista non dimostra quindi un errore di routing. Per il flusso di test correlare Diagnostics > Tools > Route lookup, log del firewall e Packet Capture.

Con IPsec route-based, il percorso dipende dal tipo di interfaccia XFRM:

Any/Any o Dual: l’interfaccia XFRM dispone di indirizzi IP. Una rotta statica, SD-WAN o dinamica deve indirizzarvi il traffico remoto.
Traffic Selectors specifici: SFOS crea automaticamente la rotta statica. Non è possibile assegnare all’interfaccia XFRM un indirizzo IP o una rotta aggiuntiva.

Controllare l’interfaccia in Network > Interfaces e il percorso in Diagnostics > Tools > Route lookup. La Device Console mostra le rotte statiche configurate:

show static-route

Controllare gli stati XFRM nell’Advanced Shell:

ip xfrm state
ip xfrm policy

Se più connessioni usano le stesse reti locali e remote come percorsi alternativi, selezione e failover devono essere espliciti. Inserire le connessioni policy-based e quelle route-based con Traffic Selectors specifici nello stesso gruppo di failover IPsec. I tunnel XFRM Any/Any possono invece commutare mediante rotte SD-WAN; la procedura collegata spiega ordine, Health Check e test controllato.

Verificare il NAT in base al tipo di tunnel

Il NAT è consentito, ma non sostituisce una rotta. Verificare prima che il percorso della destinazione originale o tradotta scelga il tunnel corretto, quindi che la controparte si aspetti gli indirizzi effettivamente usati.

Se le reti locale e remota sono identiche, una singola indicazione SNAT non basta. Usare NAT per reti IPsec sovrapposte descrive il processo speculare completo per indirizzi, tunnel, regole e routing.

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: l’interfaccia XFRM ha un indirizzo IP e richiede una rotta esplicita. Stabilire se e come avviene la traduzione dalla regola NAT corrispondente e da Packet Capture, senza dedurla dal solo tipo di tunnel.
Route-based con Traffic Selectors specifici: SFOS crea automaticamente la rotta e non assegna un indirizzo IP all’interfaccia XFRM. Presupporre un MASQ verso un ipotetico IP XFRM non è quindi un metodo diagnostico affidabile; controllare invece Source originale, Source tradotta e NAT Rule ID corrispondente.

Documentare Source originale e tradotta, consentirle sulla controparte e predisporre la rotta di ritorno. NAT su Sophos Firewall spiega i principi di base e l’ordine delle regole.

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.
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.

La configurazione normale e la verifica controllata sono illustrate in Routing multicast su Sophos Firewall; il crash descritto qui rimane un caso particolare legato al firmware.

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 Respin Build 411 o MR1 su determinate XGS Appliances: 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 annotato prima del test. Se l’accelerazione era attiva, usare:

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 solo il debug di StrongSwan attivato durante questa procedura. Non modificare uno stato preesistente senza conoscerne responsabile e scopo. 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.