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.

In caso di Remote peer is refusing our Phase 1 proposals, confrontare i valori della Fase 1, oltre a Gateway address e Listening interface, su entrambi i lati. Se corrispondono, l’amministratore del peer deve verificare la configurazione e i log dello stesso momento sulla controparte che rifiuta la connessione. Per Remote peer reports we failed to authenticate, chiedergli anche di confermare se il tipo di ID previsto è diverso, ad esempio un indirizzo IP anziché un nome DNS. Local ID e Remote ID devono corrispondere in modo incrociato per tipo e valore; correggere solo la discrepanza confermata e verificare nuovamente l’instaurazione del tunnel. Prima di modificare qualsiasi valore, registrare quelli precedenti e coordinare l’intervento con l’amministratore del peer in una finestra di manutenzione; in assenza di miglioramenti, ripristinare lo stato documentato. Non condividere PSK nei log o nei pacchetti di supporto.

I messaggi Error on decryption of the exchange o Information field of the IKE request is malformed or not readable indicano inizialmente chiavi precondivise diverse. Solo se il PSK è confermato identico su entrambi i lati e l’errore persiste si deve indagare la causa più rara indicata da Sophos: pacchetti corrotti dall’ISP o da un router o firewall a monte. Con il provider o l’amministratore responsabile, verificare il percorso interessato mediante catture simultanee e con filtri mirati, e confrontare i valori WAN di MTU/MSS con le specifiche del provider. Una singola cattura non dimostra la corruzione dei pacchetti. La guida a MTU e MSS descrive il controllo iniziale, il test sicuro e il rollback; non ridurre i valori globalmente sulla base di supposizioni. TCP MSS non è un rimedio ai problemi di negoziazione IKE. Verificare le catture per individuare dati sensibili prima di condividerle.

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.

Se NO_PROPOSAL_CHOSEN o Remote peer reports INVALID_ID_INFORMATION persiste dopo una Fase 1 riuscita, nonostante siano stati confrontati Encryption, Authentication, il gruppo PFS/DH della Fase 2 e le subnet speculari, chiedere all’amministratore del peer di verificare i log di negoziazione sulla controparte relativi allo stesso momento. Fornire nome del tunnel, orario, valori dei selector proposti e stato INSTALLED della Child SA o del selector interessato da ipsec statusall; specificare esplicitamente se manca quella SA, senza dedurre dall’errore che manchino tutte le SA. ip xfrm policy integra la verifica delle policy, ma non dimostra che le SA siano installate. Prima di intervenire, documentare i valori precedenti e la procedura di rollback e concordare una finestra di manutenzione. Poi modificare in modo coordinato solo la discrepanza dimostrata e ricontrollare l’instaurazione e lo stesso flusso di test; in assenza di miglioramenti, ripristinare lo stato precedente.

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

Con più interfacce XFRM dotate di indirizzo IP, confrontare anche le reti di transito: ogni interfaccia deve avere una propria rete senza sovrapposizioni. Indirizzi IP individuali diversi non bastano. xfrm1 con 192.168.0.1/24 e xfrm2 con 192.168.0.6/24 appartengono entrambe a 192.168.0.0/24; anche 192.168.0.1/16 su xfrm1 si sovrappone a 192.168.0.6/24 su xfrm2, perché la rete /16 comprende la /24. Questi esempi illustrano un errore, non indirizzi consigliati. Si tratta delle reti di transito delle interfacce, non delle reti LAN protette nei Traffic Selectors.

⚠️ Modificare l’indirizzamento XFRM può interrompere il percorso del tunnel e l’accesso di gestione. Annotare prima indirizzi IP, prefissi e rotte dipendenti su entrambi i lati, quindi predisporre un accesso di gestione indipendente e una finestra di manutenzione. In Network > Interfaces, modificare solo le interfacce interessate dotate di indirizzo IP, usando reti di transito disponibili e non sovrapposte, e coordinare le modifiche all’indirizzamento del peer e alle rotte dipendenti. Verificare poi Route lookup, lo stesso flusso di test e i contatori di byte in entrambe le direzioni. Senza miglioramenti, ripristinare indirizzi, prefissi e rotte annotati su entrambi i lati. Con Traffic Selectors specifici resta valida la limitazione: non assegnare un indirizzo IP XFRM né una rotta aggiuntiva.

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.
Con IPsec policy-based, un timeout di inattività sul firewall remoto termina la connessione dopo un periodo senza traffico. Confrontare con l’amministratore del peer il timeout della connessione VPN interessata e l’ora della disconnessione. Prima di modificarlo, annotare il valore precedente e l’ambito di applicazione; se la causa è confermata, disattivare il timeout di inattività di quella connessione sulla controparte durante una finestra di test concordata. La connessione può così rimanere stabilita durante l’inattività. Attendere poi il periodo di inattività che causava il problema e verificare lo stesso flusso di test, lo stato del tunnel e i contatori di byte. Senza miglioramenti, ripristinare l’impostazione precedente del peer. Non si tratta di modificare i timeout globali SFOS, le Key Lifetime o DPD.
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.