Sophos Firewall - Troubleshooting IPsec VPN

Le VPN IPsec site-to-site sono spesso invisibili finché funzionano. Quando però un tunnel non si stabilisce, resta instabile dopo una riconnessione o risulta connesso ma non trasporta traffico, serve un ordine chiaro per il troubleshooting. Altrimenti si passa rapidamente tra PSK, route, firewall rules e log senza vedere la causa reale.

Questa guida mostra come controllare le connessioni IPsec su Sophos Firewall in modo sistematico: prima l’instaurazione del tunnel, poi le reti negoziate e infine il flusso reale dei pacchetti. Per le basi CLI generali è utile Sophos Firewall Troubleshooting: consigli e trucchi per la CLI.

Prima del troubleshooting

Per prima cosa conviene documentare la situazione iniziale. Sembra banale, ma fa risparmiare molto tempo, perché molti problemi IPsec nascono da presupposti asimmetrici: un lato pensa di collegare la rete A alla rete B, mentre l’altro si aspetta ID diversi, subnet diverse o una versione IKE diversa.

Punti importanti:

Con IPsec policy-based, le reti locali e remote fanno parte della negoziazione del tunnel. Con IPsec route-based è importante anche quali route puntano all’interfaccia del tunnel. Se il traffico prende la direzione sbagliata nonostante il tunnel attivo, spesso sono coinvolte IPsec routes, route statiche, SD-WAN Policy Routes o la Route Precedence della Sophos Firewall.

⚠️ Debug log e Packet Capture possono contenere dati sensibili, per esempio IP pubblici, reti interne, hostname o dati applicativi. Questi dati dovrebbero essere raccolti solo in modo mirato, per un tempo limitato, e controllati prima della condivisione.

Percorso diagnostico

Nella pratica aiuta una sequenza semplice:

1. Il tunnel si stabilisce? Se no, controllare prima versione IKE, profilo IPsec, ID, PSK/certificato, NAT-T e raggiungibilità del peer.
2. La fase 2 viene stabilita? Se no, controllare traffic selectors, reti locali e remote, PFS e proposal di fase 2.
3. È installata una Security Association? Se sì, controllare ipsec statusall e osservare i contatori byte.
4. Il traffico passa nel tunnel? Se no, controllare firewall rules, NAT, routing, Route Precedence, IPsec routes e percorso di ritorno.
5. Si vedono pacchetti? Se non è chiaro, combinare Log Viewer e Packet Capture.

Errore frequente: uno stato del tunnel verde dimostra solo che IPsec è stato negoziato. Non dimostra che le firewall rules siano corrette, che le route siano giuste o che il peer conosca il percorso di ritorno.

Raccogliere i log

Sophos Firewall usa StrongSwan per IPsec. I log più importanti sono in /log:

Aprire la Advanced Shell via SSH e, se necessario, passare alla directory dei log:

cd /log

Seguire il log live:

tail -f /log/strongswan.log

Se sono attivi più tunnel, conviene filtrare. Si può filtrare per nome tunnel, IP del peer o testo di errore tipico:

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

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

less /log/strongswan.log

Dentro less si cerca con /termine. In alternativa si filtra direttamente con grep:

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

Attivare il debug di StrongSwan

Se il log normale non basta, si può mettere il servizio StrongSwan in modalità debug:

service strongswan:debug -ds nosync

Poi verificare se il servizio è in debug:

service -S | grep strongswan

L’output dovrebbe mostrare RUNNING,DEBUG per strongswan. Poi riconnettere il tunnel o riprodurre l’errore in modo mirato e osservare il log:

tail -f /log/strongswan.log

Lo stesso comando disattiva di nuovo il debug:

service strongswan:debug -ds nosync

⚠️ Il debug deve restare attivo solo per il tempo necessario. IPsec debug può generare molto rapidamente file log grandi e consumare spazio inutile sulla firewall.

Fase 1: IKE, ID e autenticazione

Se il tunnel non si stabilisce affatto, la causa è di solito prima o durante la fase 1. In questa fase i gateway non negoziano ancora le reti dati, ma IKE, autenticazione e identità dei due lati.

Cause tipiche:

• la versione IKE non corrisponde
• il profilo IPsec o la proposal non corrisponde
• Local ID o Remote ID è diverso da quanto previsto
• Preshared Key errata
• il peer raggiunge l’IP pubblico sbagliato
• NAT-T o port forwarding su UDP 500 e 4500 non è corretto
• certificati, CA o validità non corrispondono con autenticazione basata su certificato

No IKE config found

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

Controllare:

• IKEv1 o IKEv2 coincide su entrambi i lati?
• Il peer corrisponde all’indirizzo Remote Gateway o al FQDN configurato?
• Local ID e Remote ID coincidono?
• Encryption, Authentication, DH Group e Lifetime sono compatibili?
• Il peer usa un IP pubblico diverso da quello documentato?

Peer authentication failed

peer authentication failed, AUTH_FAILED o no matching peer config found indica spesso ID o dati di autenticazione non corrispondenti. Con Preshared Key si sospetta spesso prima la chiave. Spesso è corretto, ma non sempre. Se l’ID non corrisponde, la firewall potrebbe non arrivare nemmeno alla configurazione peer attesa.

Controllare:

• Local ID di un lato corrisponde al Remote ID dell’altro lato.
• Remote ID di un lato corrisponde al Local ID dell’altro lato.
• Ortografia, maiuscole/minuscole, FQDN e indirizzi IP coincidono esattamente.
• Il Preshared Key è stato inserito senza spazi all’inizio o alla fine.
• Con più tunnel verso lo stesso peer è chiaro quale connessione deve fare match.

Invalid HASH_V1 payload o decryption failed

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

In pratica conviene impostare nuovamente il Preshared Key su entrambi i lati invece di confrontarlo solo visivamente. Copia-incolla da password manager, spazi invisibili o caratteri speciali diversi sono perdite di tempo classiche.

Fase 2: Traffic selectors e Security Associations

Se la fase 1 riesce ma la fase 2 non viene stabilita, il problema riguarda spesso le reti e la Child SA. Sophos Firewall deve negoziare con il peer quali subnet locali e remote possono passare nel tunnel.

Indizi tipici nei log:

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

Controllare:

• Le reti locali e remote sono configurate a specchio su entrambi i lati.
• Netmask e singoli oggetti host coincidono esattamente.
• Non ci sono sovrapposizioni indesiderate con altri tunnel.
• Più reti di fase 2 sono rappresentate allo stesso modo su entrambi i lati.
• PFS, ESP Encryption, Authentication e Lifetime coincidono.

Esempio: se Sophos Firewall si aspetta localmente 172.16.10.0/24 e remotamente 10.20.30.0/24, il peer deve offrire esattamente lo specchio 10.20.30.0/24 verso 172.16.10.0/24. Un /24 da un lato e un singolo host o una rete più grande dall’altro possono già bastare per impedire l’installazione della Child SA.

Il tunnel è attivo, ma il traffico non passa

Se il tunnel risulta connesso ma il traffico non passa, IPsec in sé non è automaticamente la causa. Di solito si tratta di routing, firewall rules, NAT o percorso di ritorno.

Prima controllare lo stato IPsec nella Advanced Shell:

ipsec statusall

I punti più interessanti:

• La IKE SA è ESTABLISHED?
• La Child SA è INSTALLED?
• Quali reti locali e remote vengono mostrate?
• I contatori byte aumentano in entrambe le direzioni?
• Si vedono solo byte in uscita, ma nessun byte in ingresso?
• Il tunnel si riconnette o fa rekey regolarmente?

Se la Child SA è installata ma i contatori byte restano vuoti, probabilmente il traffico atteso non raggiunge il tunnel. A quel punto si controlla il percorso prima e dopo IPsec.

Firewall rules

Il traffico attraverso il tunnel richiede firewall rules adeguate. A seconda del modello di zone, può essere per esempio LAN verso VPN, VPN verso LAN o una zona dedicata. La regola deve coprire correttamente source, destination, service e direzione.

Importante:

• Attivare Log firewall traffic nelle regole rilevanti.
• Controllare la posizione della regola, così una regola più generale non fa match prima.
• Scegliere correttamente source zone e destination zone.
• Con più VPN, evitare oggetti troppo ampi se possono fare match con il tunnel sbagliato.
• Controllare consapevolmente Security Features come IPS, Web Filter o Application Control se sono attive sul traffico.

Un flusso generale è descritto in Testare Firewall Rules con Log Viewer, Policy Test e Packet Capture.

Routing e IPsec routes

Se la firewall non invia il traffico nel tunnel, controllare le route. Con IPsec policy-based può essere rilevante anche la tabella di routing IPsec:

ip route show table 220

Se serve un’assegnazione manuale, può aiutare una IPsec route su Sophos Firewall. Se più tipi di routing competono, controllare anche la Route Precedence della Sophos Firewall.

Controllare:

• Esiste una route statica più specifica che intercetta il traffico?
• Una SD-WAN Policy Route ha priorità rispetto alla VPN route?
• Il gateway del client punta davvero alla Sophos Firewall?
• Il peer ha una route di ritorno verso la rete locale?
• Ci sono reti locali e remote sovrapposte?

NAT

NAT non è fondamentalmente sbagliato con IPsec, ma deve essere configurato consapevolmente. Un MASQ involontario o una regola SNAT troppo ampia può fare in modo che il peer non associ più il traffico alla rete attesa.

Controllare:

• Una regola MASQ generica fa match prima di una regola VPN NAT specifica?
• Il peer si aspetta indirizzi IP originali o tradotti?
• NAT è documentato su entrambi i lati?
• La regola NAT corrisponde alla direzione del traffico?

Se è coinvolto NAT, vedere Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Combinare Log Viewer e Packet Capture

Log Viewer mostra quale regola o modulo ha valutato una connessione. Packet Capture in WebAdmin mostra invece se i pacchetti arrivano davvero, vengono inoltrati, scartati o processati dalla firewall stessa.

Per il troubleshooting IPsec conviene definire un test il più preciso possibile:

Poi:

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

Interpretazione:

Per capture più lunghe o casi di supporto può essere utile raccogliere i log in modo mirato. Salvare i log Sophos Firewall per supporto e analisi descrive l’export pulito.

Errori tipici

Checklist pratica

Controllare subito:

• Annotare stato tunnel e ultimo messaggio di errore in WebAdmin.
• Avviare tail -f /log/strongswan.log e riconnettere il tunnel.
• Controllare versione IKE, Local ID, Remote ID e Preshared Key.
• Confrontare traffic selectors o reti locali/remoti a specchio.
• Controllare ipsec statusall per ESTABLISHED, INSTALLED e contatori byte.

Se il tunnel è attivo:

• Controllare firewall rules in entrambe le direzioni.
• Attivare logging sulle regole coinvolte.
• Filtrare Log Viewer con source, destination e Rule ID.
• Eseguire Packet Capture con filtro stretto.
• Controllare regole NAT e Route Precedence.
• Confermare la route di ritorno sul peer.

Per supporto o analisi più lunga:

• Attivare debug solo brevemente e poi disattivarlo.
• Salvare i log rilevanti.
• Documentare ora, nome tunnel, peer IP, source, destination e passaggi del test.
• Controllare dati sensibili prima della condivisione.

FAQ

Perché il tunnel IPsec è verde, ma non passa traffico?

Uno stato del tunnel verde significa solo che IPsec è stato negoziato. Firewall rules, NAT, routing, Route Precedence, IPsec routes e percorso di ritorno del peer possono comunque essere errati.

Quale log è più importante per IPsec su Sophos Firewall?

In pratica, strongswan.log è il file più importante. A seconda del problema possono aiutare anche charon.log, strongswan-monitor.log e dgd.log.

Quando attivare il debug StrongSwan?

Il debug è utile quando il log normale non fornisce abbastanza informazioni. Dovrebbe essere attivato solo in modo mirato e breve, perché genera molti più dati di log.

Cosa significa traffic selectors inacceptable?

Le reti che i due lati vogliono negoziare per la fase 2 non corrispondono. Bisogna confrontare esattamente subnet locali e remote, oggetti host e più entry di fase 2.

Cosa significa AUTH_FAILED?

AUTH_FAILED indica un problema di autenticazione. Cause frequenti sono Preshared Key, Local ID, Remote ID o certificati non corrispondenti alle aspettative del peer.

Fonti

• Sophos Community: Troubleshooting site-to-site IPsec VPN issues
• Sophos Support: KBA-000006520
• Sophos Docs: Packet capture