Risoluzione dei problemi IPsec VPN su Sophos Firewall

Le VPN IPsec Site-to-Site sono spesso silenziose finché funzionano. Tuttavia, se un tunnel non si avvia, rimane instabile dopo una riconnessione o viene visualizzato come connesso ma non trasporta traffico, è necessaria una sequenza chiara per l’analisi. Altrimenti, si rischia di saltare tra PSK, rotte, regole firewall e log senza vedere la causa reale.

L’articolo spiega come verificare sistematicamente le connessioni IPsec su Sophos Firewall: prima l’instaurazione del tunnel, poi le reti negoziate e infine il flusso effettivo dei pacchetti. Se un nuovo tunnel di sito è appena pianificato o configurato, prima si adatta Configurare VPN IPsec Site-to-Site su Sophos Firewall. Per le basi generali della CLI, aiuta anche Risoluzione dei problemi CLI su Sophos Firewall: comandi importanti.

Prima della risoluzione dei problemi

Innanzitutto, è consigliabile documentare brevemente la situazione di partenza. Questo sembra banale, ma risparmia molto tempo, poiché molti problemi IPsec derivano da assunzioni asimmetriche: una parte crede di connettere la rete A con la rete B, mentre l’altra parte si aspetta ID diversi, subnet diverse o una versione IKE diversa.

Punti importanti:

• Nome del tunnel: azure-vpn
• Gateway locale: Indirizzo WAN o FQDN di Sophos Firewall
• Gateway remoto: IP pubblico o FQDN della controparte
• Versione IKE: IKEv1 o IKEv2
• Gateway type: Initiate the connection, Respond only o gruppo failover
• Profilo IPsec: Phase 1, Phase 2, DH groups, PFS e lifetimes
• Autenticazione: Preshared Key o certificato
• ID locale / ID remoto: Indirizzo IP, FQDN o identificatore simile a un’email
• Reti locali: 172.16.10.0/24
• Reti remote: 10.20.30.0/24
• Tipo di VPN: basato su policy o basato su route
• Traffico previsto: Sorgente, Destinazione, Porta e Direzione

Nel caso di IPsec basato su policy, le reti locali e remote fanno parte della negoziazione del tunnel. Nel caso di IPsec basato su route, è inoltre importante quali rotte puntano all’interfaccia del tunnel. Se il traffico, nonostante il tunnel attivo, va nella direzione sbagliata, spesso sono coinvolte Rotte IPsec, rotte statiche, rotte di policy SD-WAN o la Precedenza delle rotte su Sophos Firewall.

Se il tunnel è attivo e i piccoli test funzionano, ma i trasferimenti più grandi si bloccano, è consigliabile controllare MTU e MSS. La procedura è descritta in Controllare MTU e MSS su Sophos Firewall per problemi VPN.

⚠️ I log di debug e le acquisizioni di pacchetti possono contenere dati sensibili, come indirizzi IP pubblici, reti interne, nomi host o dati utente. Tali dati dovrebbero essere raccolti solo in modo mirato e per un periodo limitato, e controllati prima di essere condivisi.

Percorso diagnostico

Per la pratica, aiuta una semplice sequenza:

1. Il tunnel si avvia? Se no, controllare prima la versione IKE, il profilo IPsec, gli ID, PSK/certificato, NAT-T e la raggiungibilità della controparte.
2. La Fase 2 viene instaurata? Se no, controllare i selettori di traffico, le reti locali e remote, PFS e le proposte di Fase 2.
3. È installata una Security Association? Se sì, controllare ipsec statusall e prestare attenzione ai contatori di byte.
4. Il traffico passa attraverso il tunnel? Se no, controllare regole firewall, NAT, routing, precedenza delle rotte, rotte IPsec e percorso di ritorno.
5. Si vedono pacchetti? Se non chiaro, combinare Log Viewer e Packet Capture.

Un errore comune: uno stato del tunnel verde prova solo che IPsec è stato negoziato in linea di principio. Non prova che le regole firewall siano corrette, che le rotte siano giuste o che la controparte conosca il percorso di ritorno.

Prima di passare alla Advanced Shell vale la pena guardare le liste nel WebAdmin:

• In Site-to-site VPN > IPsec, tramite Show additional properties si possono mostrare colonne aggiuntive come Local subnet, Remote subnet, Gateway type o Profile.
• In Profiles > IPsec profiles si possono visualizzare proprietà aggiuntive per confrontare più rapidamente valori Phase-1 e Phase-2.

Non è profondo quanto un log, ma evita errori banali: profilo sbagliato, Gateway type errato, subnet uguali in più tunnel o un tunnel che non fa parte del gruppo failover atteso.

Quale livello è interessato?

Prima dei log di debug, è utile classificare grossolanamente il problema. Questo rende più chiaro se cercare in IKE, Fase 2, routing o flusso dei pacchetti.

• Il tunnel rimane inattivo: IKE, Gateway, ID, PSK, certificato o proposta Controllare strongswan.log in tempo reale e confrontare la Fase 1
• Il tunnel cambia costantemente tra attivo e inattivo: Rekey, DPD, stabilità WAN o proposta Confrontare timestamp, DPD, durata e eventi WAN
• La Fase 1 è attiva, ma nessuna Child SA: Selettori di traffico, proposta di Fase 2 o PFS Controllare reti locali e remote in modo speculare
• Il tunnel è verde, ma i contatori di byte rimangono vuoti: Il traffico non raggiunge il tunnel Controllare regola firewall, NAT, rotta e gateway client
• Solo i byte in uscita aumentano: Mancanza di percorso di ritorno o controparte Controllare firewall remoto, rotta remota e sistema di destinazione
• Packet Capture mostra pacchetti senza regola corrispondente: Ordine delle regole, zona o servizio non corrispondono Confrontare Log Viewer, Policy Test e ID regola

Questa classificazione non sostituisce un’analisi dettagliata. Tuttavia, impedisce di cercare un errore di Fase 2 nelle regole firewall o di reimpostare inutilmente il Preshared Key in caso di problema di percorso di ritorno.

Raccogliere i log

Sophos Firewall utilizza StrongSwan per IPsec. I log più importanti si trovano in /log:

• strongswan.log: principale file di log IPsec per IKE, autenticazione e Child SAs
• charon.log: log del demone IKE, utile a seconda della versione e della situazione
• strongswan-monitor.log: monitoraggio del servizio IPsec
• dgd.log: rilevamento del gateway morto e failover VPN

Si accede alla Advanced Shell tramite SSH e, se necessario, si passa alla directory dei log:

cd /log

Il log in tempo reale può essere seguito direttamente:

tail -f /log/strongswan.log

Se sono attivi più tunnel, è consigliabile filtrare. Questo può essere fatto tramite il nome del tunnel, un IP peer o un testo di errore tipico:

tail -f /log/strongswan.log | grep -i azure-vpn

Per i file di log esistenti, less è spesso più comodo:

less /log/strongswan.log

In less si può cercare all’interno del file con /termine_di_ricerca. In alternativa, grep filtra direttamente:

grep -i "no proposal" /log/strongswan.log

Attivare il debug di StrongSwan

Se il log normale non è sufficiente, è possibile impostare il servizio StrongSwan in modalità debug:

service strongswan:debug -ds nosync

Successivamente, verificare se il servizio è in modalità debug:

service -S | grep strongswan

L’output dovrebbe mostrare lo stato RUNNING,DEBUG per strongswan. Quindi ricollegare il tunnel o riprodurre l’errore e osservare il log:

tail -f /log/strongswan.log

Lo stesso comando di debug disattiva nuovamente la modalità debug:

service strongswan:debug -ds nosync

⚠️ Lasciare il debug attivo solo per il tempo strettamente necessario. Il debug IPsec può generare rapidamente file di log di grandi dimensioni e occupare inutilmente spazio sulla firewall.

Fase 1: IKE, ID e autenticazione

Se il tunnel non viene affatto instaurato, la causa si trova spesso prima o durante la Fase 1. In questo caso, i gateway non negoziano ancora le reti di dati, ma prima IKE, autenticazione e le identità delle due parti.

Cause tipiche:

• La versione IKE non corrisponde
• Il profilo IPsec o la proposta non corrisponde
• L’ID locale o remoto è diverso da quanto previsto
• Il Preshared Key è errato
• La controparte raggiunge l’IP pubblico sbagliato
• NAT-T o inoltro porta su UDP 500 e 4500 non è corretto
• Certificati, CA o validità non corrispondono nell’autenticazione basata su certificato

No IKE config found

Una voce di log come no IKE config found o NO_PROPOSAL_CHOSEN spesso significa che Sophos Firewall non trova una configurazione IKE adatta per il pacchetto in arrivo. Questo può dipendere dalla versione IKE, dal gateway, dagli ID o dal profilo IPsec.

Controllare:

• IKEv1 o IKEv2 corrisponde su entrambe le parti?
• La controparte corrisponde all’indirizzo del gateway remoto configurato o al FQDN?
• Gli ID locali e remoti corrispondono?
• Crittografia, autenticazione, gruppo DH e durata sono compatibili?
• La controparte utilizza un IP pubblico diverso da quello documentato?

Peer authentication failed

peer authentication failed, AUTH_FAILED o no matching peer config found spesso indicano ID o dati di autenticazione non corrispondenti. Con Preshared Key, spesso si sospetta prima la chiave. Questo è spesso corretto, ma non sempre. Se l’ID non corrisponde, il firewall potrebbe non controllare affatto la configurazione peer prevista.

Controllare:

• L’ID locale di una parte corrisponde all’ID remoto dell’altra parte.
• L’ID remoto di una parte corrisponde all’ID locale dell’altra parte.
• La scrittura, maiuscole e minuscole, FQDN e indirizzi IP corrispondono esattamente.
• Il Preshared Key è stato inserito senza spazi all’inizio o alla fine.
• Con più tunnel verso la stessa controparte, è chiaro quale connessione dovrebbe corrispondere.

Invalid HASH_V1 payload o decryption failed

Con IKEv1, messaggi come invalid HASH_V1 payload length o decryption failed spesso indicano un Preshared Key errato. Con IKEv2, si vedono più spesso AUTHENTICATION_FAILED o AUTH_FAILED.

In pratica, è consigliabile reimpostare il Preshared Key su entrambe le parti, invece di confrontarlo solo visivamente. Copia-incolla da gestori di password, spazi invisibili o caratteri speciali diversi sono classici perditempo.

Fase 2: Selettori di traffico e Security Associations

Se la Fase 1 ha successo, ma la Fase 2 non si instaura, si tratta spesso delle reti e della Child SA. Sophos Firewall deve negoziare con la controparte quali subnet locali e remote possono passare attraverso il tunnel.

Indicazioni tipiche nei log:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi e TSr mostrano reti diverse da quelle previste

Controllare:

• Le reti locali e remote sono configurate in modo speculare su entrambe le parti.
• La maschera di rete e gli oggetti host singoli corrispondono esattamente.
• Non ci sono sovrapposizioni indesiderate con altri tunnel.
• Più reti di Fase 2 sono rappresentate allo stesso modo su entrambe le parti.
• PFS, crittografia ESP, autenticazione e durata corrispondono.

Esempio: se Sophos Firewall si aspetta localmente 172.16.10.0/24 e remotamente 10.20.30.0/24, la controparte deve offrire esattamente in modo speculare 10.20.30.0/24 verso 172.16.10.0/24. Un /24 da una parte e un singolo host o una rete più grande dall’altra parte può già bastare per impedire l’installazione della Child SA.

Il tunnel è attivo, ma non passa traffico

Se il tunnel viene visualizzato come connesso, ma non passa traffico, IPsec stesso non è automaticamente la causa. Si tratta spesso di routing, regole firewall, NAT o del percorso di ritorno.

Prima controllare lo stato IPsec nella Advanced Shell:

ipsec statusall

Sono particolarmente interessanti:

• La IKE SA è ESTABLISHED?
• La Child SA è INSTALLED?
• Quali reti locali e remote vengono visualizzate?
• I contatori di byte aumentano in entrambe le direzioni?
• Si vedono solo byte in uscita, ma non in entrata?
• Viene regolarmente riconnesso o rinegoziato?

Se la Child SA è installata, ma i contatori di byte rimangono vuoti, il traffico previsto probabilmente non raggiunge il tunnel. Quindi si controlla il percorso prima e dopo IPsec.

Con IPsec route-based si può inoltre verificare se XFRM-State e Policy sono installati:

ip xfrm state
ip xfrm policy

Se ipsec statusall mostra una SA stabilita, ma ip xfrm state o ip xfrm policy non corrispondono al tunnel atteso, il problema spesso non riguarda più PSK o proposal, ma Traffic Selectors, configurazione XFRM, route o tunnel concorrenti.

Regole firewall

Per il traffico attraverso il tunnel sono necessarie regole firewall appropriate. A seconda del modello di zone, ad esempio LAN verso VPN, VPN verso LAN o una zona propria. La regola deve coprire correttamente sorgente, destinazione, servizio e direzione.

Importante:

• Attivare Log firewall traffic nelle regole rilevanti.
• Controllare la posizione della regola, in modo che nessuna regola più generale venga applicata prima.
• Scegliere correttamente le zone di origine e destinazione.
• Con più VPN, non utilizzare oggetti troppo ampi se potrebbero corrispondere al tunnel sbagliato.
• Controllare consapevolmente le funzionalità di sicurezza come IPS, filtro web o controllo delle applicazioni, se sono attive sul traffico.

Un flusso di controllo generale è descritto in Testare le regole firewall con Log Viewer, Policy Test e Packet Capture.

Routing e rotte IPsec

Se il firewall non invia il traffico nel tunnel, si controllano le rotte. Con IPsec basato su policy, può essere rilevante anche la tabella di routing IPsec:

ip route show table 220

Se è necessaria un’assegnazione manuale, può aiutare una Rotta IPsec su Sophos Firewall. Se più tipi di routing competono, è consigliabile controllare anche la Priorità di routing su Sophos Firewall.

Con VPN route-based bisogna controllare anche le XFRM Interfaces. Due XFRM Interfaces non devono essere configurate con reti interfaccia sovrapposte o identiche. Se xfrm1 e xfrm2 si trovano nella stessa rete di trasferimento, il tunnel può essere established e comunque instradare in modo errato. In questo caso verificare l’indirizzamento XFRM in Network > Interfaces e usare reti univoche.

Se più connessioni IPsec usano le stesse subnet locali e remote, non dovrebbero restare liberamente affiancate. Queste connessioni appartengono a un design failover consapevole o devono ricevere logica Selector/Routing distinta. Altrimenti il firewall non può usare in modo affidabile il tunnel previsto.

Controllare:

• C’è una rotta statica più specifica che intercetta il traffico?
• Una rotta di policy SD-WAN si applica prima della rotta VPN?
• Il gateway client punta davvero a Sophos Firewall?
• La controparte ha una rotta di ritorno verso la rete locale?
• Ci sono reti locali e remote sovrapposte?

NAT

Il NAT non è intrinsecamente sbagliato con IPsec, ma deve essere configurato consapevolmente. Un MASQ involontario o una regola SNAT troppo ampia può far sì che la controparte non associ più il traffico alla rete prevista.

Controllare:

• Una regola MASQ generica si applica prima di una regola VPN-NAT specifica?
• La controparte si aspetta indirizzi IP originali o indirizzi tradotti?
• Il NAT è documentato su entrambe le parti?
• La regola NAT corrisponde alla direzione del traffico?

Se il NAT è coinvolto, l’articolo Comprendere il NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT è utile.

SFOS 22: Controllare consapevolmente IPsec basato su policy e NAT

Con gli aggiornamenti a SFOS 22, l’IPsec basato su policy dovrebbe essere controllato con particolare attenzione. Sophos segnala nelle note di rilascio di SFOS 22 un comportamento modificato per le VPN IPsec basate su policy. Inoltre, nei problemi risolti è documentato NC-170917: il traffico IPsec basato su policy poteva fallire se la regola SNAT predefinita era configurata con un indirizzo IP statico anziché MASQ.

In pratica, ciò significa che se un tunnel basato su policy è verde dopo l’aggiornamento, ma il traffico non fluisce o fluisce solo in una direzione, il NAT non dovrebbe essere trattato come un argomento secondario. Una vecchia regola SNAT predefinita ampia o adattata in modo insolito può modificare esattamente il traffico che la controparte si aspetta con le reti originali.

Punti di controllo tipici dopo un aggiornamento a SFOS 22:

• Il tunnel è davvero basato su policy?: Con IPsec basato su policy, le reti locali e remote fanno parte della negoziazione. Il NAT può rompere questa aspettativa.
• La regola SNAT predefinita è stata modificata?: Un IP SNAT statico anziché MASQ può avere effetti diversi dopo un aggiornamento rispetto a quanto previsto.
• Ci sono regole VPN-NAT specifiche?: Queste devono essere posizionate sopra le regole SNAT o MASQ generali e corrispondere alla direzione del traffico.
• I selettori di traffico e gli oggetti NAT corrispondono?: La controparte deve aspettarsi o le reti originali o le reti tradotte, non entrambe casualmente.
• Packet Capture mostra l’IP di origine previsto?: Così si riconosce se il firewall utilizza un altro indirizzo di origine prima del tunnel.

Un test pulito consiste in una sorgente, una destinazione e un servizio. Successivamente, si controllano in sequenza regola firewall, regola NAT, ipsec statusall, ip route show table 220, Packet Capture e controparte. Se il test funziona solo con la regola NAT disattivata o spostata, il problema non è nell’instaurazione del tunnel, ma nel percorso verso il tunnel.

Per la pianificazione dell’aggiornamento, si adatta anche Controllare Sophos Firewall prima dell’aggiornamento a SFOS 22. Per le basi del NAT e l’ordine delle regole, Comprendere il NAT su Sophos Firewall è il miglior punto di partenza.

SFOS 22: PPPoE-WAN con interfaccia alias e accelerazione IPsec

Se dopo un aggiornamento a SFOS 22.0 GA o SFOS 22.0 MR1 un tunnel IPsec è connesso ma non inoltra traffico, in determinati setup può esserci un caso speciale aggiuntivo. Sophos elenca nella lista dei problemi noti NC-181526: su hardware XGS, i tunnel IPsec su interfacce alias di porte PPPoE-WAN possono essere instaurati, ma non inoltrano traffico utente se l’accelerazione IPsec è attiva.

Questo punto dovrebbe essere controllato solo se le cause normali non si applicano. Un tunnel verde senza traffico è ancora più spesso un problema di regole, routing, NAT o percorso di ritorno. Il caso speciale di SFOS 22 diventa più probabile se tutti i seguenti punti si verificano insieme:

• Sophos Firewall esegue SFOS 22.0 GA o SFOS 22.0 MR1.
• Si tratta di hardware XGS.
• Il tunnel interessato utilizza un’interfaccia alias su una porta PPPoE-WAN.
• Il tunnel si instaura, ma il traffico utente manca.
• Regole firewall, NAT, rotte, percorso di ritorno e Packet Capture non spiegano il comportamento.
• L’accelerazione IPsec è attiva.

Come soluzione temporanea, è documentato disattivare l’accelerazione IPsec:

system ipsec-acceleration off

Non dovrebbe essere utilizzato come comando generico di tuning IPsec. La modifica dovrebbe essere eseguita in una finestra di manutenzione o in un processo di supporto documentato, con test prima/dopo e chiara associazione al problema rilevato. Sophos elenca SFOS 22.0.2 MR2 come versione di correzione per questo problema noto. Se questa versione è approvata per l’ambiente interessato, un aggiornamento pianificato è più pulito di una soluzione temporanea dimenticata.

Rekey, failover e stato interfaccia

Se un tunnel prima funziona e poi cade, non è sempre sbagliata la configurazione iniziale. In quel caso bisogna controllare l’andamento nel tempo:

• Traffic-based Rekeying presso terze parti: Sophos Firewall si aspetta una logica rekey basata sul tempo. Se la controparte forza traffic-based Rekeying, il tunnel può bloccarsi o negoziare di nuovo dopo un po'.
• Key exchange collisions: Se entrambe le parti eseguono rekey contemporaneamente, possono nascere fasi instabili. In questi casi, Phase-1 e Phase-2 lifetimes dovrebbero essere coordinati consapevolmente tra Initiator e Responder.
• Interfaccia disattivata: Se l’interfaccia associata viene spenta, un tunnel Site-to-Site initiator si separa subito. Connessioni Responder e Remote Access emergono al più tardi tramite inattività o DPD timeout.
• DGD e gruppo failover: Negli scenari failover controllare anche dgd.log, stato gateway, connessione primaria/secondaria e coppie subnet identiche.

Questi errori si riconoscono meglio tramite timestamp che con un singolo snapshot. Per problemi intermittenti bisogna quindi correlare nel tempo stato tunnel, strongswan.log, dgd.log, eventi WAN e test applicativo.

Flusso di controllo pratico:

1. Documentare lo stato del tunnel e ipsec statusall.
2. Eseguire Packet Capture con filtro stretto su sorgente/destinazione.
3. Verificare se il tunnel utilizza davvero un’interfaccia alias su una porta PPPoE-WAN.
4. Annotare la versione SFOS attiva e il modello hardware.
5. Testare la modifica all’accelerazione IPsec solo in modo mirato e documentato.
6. Dopo il test, confrontare contatori di byte, Packet Capture, Log Viewer e test applicativo.

Combinare Log Viewer e Packet Capture

Il Log Viewer mostra quale regola o modulo ha valutato una connessione. Packet Capture nel WebAdmin mostra invece se i pacchetti arrivano davvero, vengono inoltrati, scartati o elaborati dal firewall stesso.

Per la risoluzione dei problemi IPsec, è consigliabile definire un test il più stretto possibile:

• IP sorgente: 172.16.10.25
• IP destinazione: 10.20.30.15
• Servizio: ICMP o TCP 443
• Direzione prevista: LAN verso VPN
• Regola prevista: LAN_to_VPN_Branch

Successivamente:

1. Attivare il logging nella regola firewall.
2. Filtrare Log Viewer con IP sorgente, IP destinazione e modulo Firewall.
3. Avviare Packet Capture con filtro stretto, ad esempio host 172.16.10.25 and host 10.20.30.15.
4. Riprodurre il test esattamente una volta.
5. Verificare se i pacchetti arrivano, vengono inoltrati e se le risposte tornano.

Interpretazione:

• Nessun pacchetto arriva su Sophos Firewall: Controllare client, gateway, VLAN, switch o routing locale
• Il pacchetto arriva, ma non viene inoltrato: Controllare regola firewall, NAT, rotta o funzionalità di sicurezza
• Il pacchetto viene inviato nel tunnel, manca la risposta: Controllare rotta di ritorno, controparte, firewall remoto o host remoto
• Solo byte in uscita in ipsec statusall: Controllare percorso di ritorno o policy remota
• Solo byte in entrata: Controllare rotta locale, regola firewall locale o sistema di destinazione

Per acquisizioni più lunghe o casi di supporto, può essere utile raccogliere log in modo mirato. L’articolo Salvare i log di Sophos Firewall per supporto e analisi descrive l’esportazione pulita.

Errori tipici

I seguenti errori si riferiscono alle stringhe di log grezze StrongSwan/Charon in strongswan.log. In WebAdmin le stesse cause appaiono spesso come messaggio tradotto, ad esempio no IKE config found diventa “Remote peer is refusing our Phase 1 proposals”, peer authentication failed diventa “Remote peer reports we failed to authenticate” oppure traffic selectors ... inacceptable diventa “Remote peer reports INVALID_ID_INFORMATION”. Chi controlla prima WebAdmin invece del log grezzo trova il caso corrispondente tramite questa corrispondenza.

• no IKE config found: Versione IKE, gateway, ID o profilo non corrispondono Confrontare versione IKE, ID locale/remoto e proposte
• NO_PROPOSAL_CHOSEN: Mismatch delle proposte Controllare crittografia, autenticazione, gruppo DH, PFS e durata
• peer authentication failed: ID o autenticazione non corrispondono Controllare ID locale/remoto e PSK/certificato
• AUTH_FAILED: Preshared Key, certificato o ID non corrispondono Reimpostare PSK, controllare catena di certificati e ID
• traffic selectors ... inacceptable: Le reti locali e remote non corrispondono Confrontare subnet e oggetti host in modo speculare
• failed to establish CHILD_SA: Le reti di Fase 2 o le proposte ESP non corrispondono Controllare selettori di traffico, PFS, profilo ESP e durate
• Tunnel verde, nessun byte: Il traffico non raggiunge il tunnel Controllare regola firewall, rotta, NAT e gateway client
• Byte in uscita, nessun byte in entrata: Mancanza di controparte o percorso di ritorno Controllare regole remote, rotta remota e sistema di destinazione
• Trasferimenti grandi si bloccano nonostante il tunnel attivo: MTU/MSS, perdita di pacchetti o Path-MTU-Discovery Controllare MTU e MSS per problemi VPN
• SFOS 22, IPsec basato su policy, tunnel verde, traffico mancante: NAT, SNAT predefinito o selettori di traffico non corrispondono correttamente dopo l’aggiornamento Controllare SNAT predefinito, regole VPN-NAT, MASQ, Packet Capture e controparte
• SFOS 22, PPPoE-WAN-Alias, tunnel verde, nessun traffico: possibile problema noto con accelerazione IPsec Testare solo in modo mirato tipo di interfaccia, versione SFOS e system ipsec-acceleration off
• ipsec statusall mostra SAs, ma il traffico route-based si ferma più tardi: Controllare XFRM-State, XFRM-Policy, reti XFRM sovrapposte, gruppo failover e comportamento rekey.
• Più tunnel con le stesse subnet: I tunnel appartengono a un gruppo failover o devono ricevere logica Selector/Routing chiaramente diversa.
• Riconnessioni o frequenti rinegoziazioni: Durata, DPD, linea instabile o problema di proposta Controllare tempi di rinegoziazione, DPD, stabilità WAN e log

Lista di controllo pratica

Controllare immediatamente:

• Annotare lo stato del tunnel e l’ultimo messaggio di errore nel WebAdmin.
• Avviare tail -f /log/strongswan.log e ricollegare il tunnel.
• Controllare versione IKE, ID locale, ID remoto e Preshared Key.
• Confrontare selettori di traffico o reti locali e remote in modo speculare.
• Controllare ipsec statusall per ESTABLISHED, INSTALLED e contatori di byte.

Se il tunnel è attivo:

• Controllare le regole firewall in entrambe le direzioni.
• Attivare il logging sulle regole interessate.
• Filtrare Log Viewer con sorgente, destinazione e ID regola.
• Eseguire Packet Capture con filtro stretto.
• Controllare regole NAT e precedenza delle rotte.
• Con SFOS 22 e IPsec basato su policy, controllare SNAT predefinito, regole VPN-NAT specifiche e IP di origine previsto.
• Con VPN route-based controllare ip xfrm state, ip xfrm policy e reti delle XFRM Interfaces.
• Con più tunnel simili mostrare gruppo failover e colonne Local-/Remote-Subnet.
• Con SFOS 22 e PPPoE-WAN-Alias, controllare se il problema noto di accelerazione IPsec si applica.
• Confermare la rotta di ritorno sulla controparte.

Per supporto o analisi più lunga:

• Attivare il debug solo brevemente e poi disattivarlo.
• Salvare i log rilevanti.
• Documentare ora, nome del tunnel, IP peer, sorgente, destinazione e flusso di test.
• Controllare i dati sensibili prima di condividerli.

FAQ