Migrare Legacy Remote Access IPsec prima di SFOS 22 MR1
Con SFOS 22.0 MR1, Sophos ha escluso definitivamente il Legacy Remote Access IPsec VPN dal percorso di upgrade supportato. I firewall su cui questa vecchia configurazione Remote Access IPsec è ancora presente non possono essere aggiornati a SFOS 22.0 MR1 o versioni successive.
Questo articolo descrive come riconoscere la vecchia configurazione prima di un upgrade firmware, documentarla in modo pulito, sostituirla con una soluzione Remote Access attuale e solo dopo rimuoverla. Per il controllo generale dell’upgrade è utile anche Verifica della Sophos Firewall prima dell’aggiornamento a SFOS 22.
Di cosa si tratta con Legacy Remote Access IPsec
Nel corso degli anni Sophos ha supportato diverse modalità di Remote Access. Per questo in molti ambienti non è immediatamente chiaro se si parli di una configurazione IPsec attuale, di una vecchia voce legacy, di SSL VPN o di Sophos Connect.
Per l’upgrade a SFOS 22 MR1 è decisivo soprattutto questo:
- Legacy Remote Access IPsec è il vecchio tipo di configurazione che può bloccare l’upgrade.
- Remote Access IPsec attuale è il percorso di destinazione se si vuole continuare a usare IPsec.
- SSL VPN può essere un’alternativa se IPsec viene regolarmente bloccato in hotel, reti guest o ambienti mobili.
- ZTNA può essere sensato quando non serve più una VPN client completa, ma l’accesso a singole applicazioni.
La differenza è importante dal punto di vista operativo. Uno stato VPN verde o un Sophos Connect Client funzionante non prova automaticamente che sul firewall non sia più presente una configurazione legacy.
Un caso di restore importante viene facilmente trascurato: backup o configurazioni importate possono contenere Legacy Remote Access IPsec, ma questa configurazione legacy non viene migrata automaticamente. Dopo restore, sostituzione hardware o importazione della configurazione, il punto va quindi verificato di nuovo, anche se prima il firewall sembrava già ripulito.
Quando migrare
La migrazione dovrebbe essere completata prima dell’upgrade pianificato a SFOS 22 MR1. Questo passaggio non dovrebbe essere svolto solo nella finestra di manutenzione dell’aggiornamento firmware, perché Remote Access spesso coinvolge utenti, certificati, MFA, DNS, regole firewall e configurazioni client.
Trigger tipici:
- Sophos Firewall deve essere aggiornato a SFOS 22.0 MR1 o versione successiva.
- La pagina firmware o la documentazione Sophos indica Legacy Remote Access IPsec.
- Nell’ambiente sono presenti vecchi profili Sophos Connect che non vengono controllati da anni.
- Gli utenti segnalano problemi ricorrenti di Remote Access dopo cambi di profilo o client.
- Remote Access deve comunque essere rivalutato con MFA, Entra ID SSO, SSL VPN o ZTNA.
Se Remote Access è critico per l’azienda, la migrazione dovrebbe essere trattata come un change project separato. L’upgrade firmware è allora solo il motivo iniziale, non tutto il lavoro.
Documentare prima della migrazione
Per prima cosa si documenta lo stato attuale. Questo passaggio è più importante di quanto sembri, perché molte configurazioni VPN non consistono solo in un profilo tunnel. Spesso vi sono collegati gruppi utenti, pool IP, impostazioni DNS, regole firewall, eccezioni NAT e file client.
Verificare la configurazione legacy in WebAdmin
Prima di pianificare la destinazione bisogna stabilire con precisione se è davvero interessato Legacy Remote Access IPsec. Il controllo non va eseguito solo prima dell’upgrade firmware, ma anche dopo restore, sostituzione hardware o importazione della configurazione.
Procedura pratica:
- Aprire Remote access VPN > IPsec (legacy), se il menu è visibile nella versione SFOS installata.
- Verificare se Legacy Remote Access IPsec è attivo o se sono ancora presenti oggetti di configurazione.
- Aprire Remote access VPN > IPsec e documentare separatamente la configurazione Remote Access IPsec attuale.
- Verificare Authentication > Users e i gruppi utenti se sono stati usati indirizzi IP statici, utenti locali o vecchie assegnazioni di gruppo.
- Cercare in Rules and policies > Firewall rules regole dalla zona
VPNversoLAN,DMZoWAN. - Controllare in Administration > Device access se IPsec, VPN Portal, DNS o Ping sono raggiungibili dalle zone necessarie.
- Riaprire la pagina firmware e controllare se continua a comparire un blocco dell’upgrade.
Se l’area legacy non è più visibile, ma l’upgrade continua a essere bloccato, non bisognerebbe eliminare oggetti a sospetto. In quel caso sono più importanti uno screenshot del messaggio, un backup attuale e un elenco oggetti tracciabile rispetto a una pulizia frettolosa nella finestra di manutenzione.
Occorre documentare almeno:
| Area | Cosa verificare |
|---|---|
| Utenti e gruppi | Quali utenti possono usare Remote Access? Si usano utenti locali, AD, RADIUS o Entra ID? |
| Autenticazione | Password, MFA, certificato, Preshared Key o dipendenze SSO |
| Pool IP | Quali indirizzi ricevono i client VPN? Ci sono conflitti con LAN, WLAN, VLAN o altre VPN? |
| DNS | Quali server DNS e domini vengono distribuiti ai client? |
| Accesso | Quali reti interne, server e servizi devono essere raggiungibili? |
| Regole firewall | Quali regole consentono traffico da VPN verso LAN, DMZ o WAN? |
| Distribuzione client | Dove si trovano i profili Sophos Connect o le configurazioni SSL VPN attuali? |
| Operatività | Chi può informare gli utenti, distribuire profili e ricevere segnalazioni di errore? |
Se esistono già problemi di routing o traffico attraverso il tunnel, non dovrebbero essere trasferiti senza controllo nella nuova configurazione. Per l’analisi aiuta Troubleshooting IPsec VPN su Sophos Firewall.
Scegliere il percorso di destinazione
Non esiste un unico sostituto corretto per Legacy Remote Access IPsec. La scelta dipende da ciò che gli utenti devono davvero fare e da come viene gestito l’ambiente.
Remote Access IPsec attuale
Remote Access IPsec attuale è la scelta più ovvia se si vuole continuare a usare Sophos Connect con IPsec e l’ambiente funziona fondamentalmente bene con questo approccio. IPsec è spesso performante, ma in reti esterne restrittive può creare problemi per porte UDP bloccate o casi NAT particolari.
Questo percorso è adatto quando:
- Sophos Connect è già distribuito
- gli utenti lavorano principalmente con Windows o macOS
- IPsec è stato stabile nell’uso finora
- le reti interne devono essere raggiungibili tramite regole firewall classiche
La guida esistente Configurare il client Sophos Connect sulla Sophos Firewall può servire come base, ma deve essere confrontata con le versioni SFOS attuali e con il proprio design di autenticazione.
SSL VPN
SSL VPN è sensata quando Remote Access deve funzionare nel modo più robusto possibile attraverso reti esterne diverse. A seconda dell’ambiente, SSL VPN può essere più semplice, ma introduce altre questioni di performance e client. Per Windows è disponibile la guida Installare Sophos Connect SSL VPN Client.
Questo percorso è adatto quando:
- gli utenti lavorano spesso da hotel, WLAN guest o reti aziendali esterne
- le connessioni IPsec falliscono ripetutamente a causa di restrizioni di rete
- sono già stabiliti processi SSL VPN esistenti
- piattaforme mobili o client OpenVPN di terze parti hanno un ruolo
ZTNA o Clientless Access
Se gli utenti hanno bisogno solo di singole applicazioni web interne o applicazioni definite, bisogna verificare se una classica VPN full tunnel sia ancora la soluzione giusta. ZTNA non è un sostituto diretto per ogni scenario VPN, ma in casi d’uso ben delimitati può essere l’architettura migliore.
L’articolo esistente Sophos ZTNA Gateway Connector è un buon punto di partenza. Per accessi web semplici può essere rilevante anche Clientless Access, se i requisiti sono compatibili.
Preparare la nuova configurazione Remote Access
La nuova configurazione dovrebbe essere preparata in parallelo prima di rimuovere quella vecchia. L’obiettivo non è spostare tutti gli utenti contemporaneamente in un setup non testato.
Procedura consigliata:
- Definire la variante di destinazione: Remote Access IPsec attuale, SSL VPN, ZTNA o combinazione.
- Scegliere un nuovo pool IP e verificarne le sovrapposizioni.
- Definire fonte di autenticazione e MFA.
- Assegnare gli utenti o i gruppi necessari.
- Definire server DNS e domini interni.
- Creare regole firewall per le nuove sorgenti VPN.
- Generare un profilo di test per pochi utenti.
- Testare la connessione su almeno due accessi di rete diversi.
- Solo dopo pianificare comunicazione agli utenti e rollout.
MFA non dovrebbe essere trattata come un dettaglio opzionale nel Remote Access. Se la VPN è raggiungibile da tutto il mondo, MFA, gruppi utenti puliti, logging e una review delle impostazioni Device Access vanno considerati insieme. L’articolo Configurare MFA su Sophos Firewall copre le basi.
Pianificare coesistenza e percorso di fallback
La nuova soluzione Remote Access dovrebbe prima essere testata accanto alla vecchia configurazione. In questo modo si possono migrare gli utenti gradualmente e, in caso di errore, tornare indietro in modo mirato, senza modificare nella stessa finestra Remote Access, regole firewall, DNS, MFA e distribuzione client.
È però importante pianificare la coesistenza in modo pulito. La nuova configurazione non dovrebbe usare lo stesso pool IP, le stesse regole firewall con nomi poco chiari o gli stessi nomi profilo della vecchia configurazione legacy. Altrimenti nel Log Viewer non sarà più riconoscibile quale accesso ha effettivamente connesso un utente.
Prima del pilot questi punti dovrebbero essere definiti:
| Punto | Raccomandazione |
|---|---|
| Gruppo pilot | pochi utenti tecnicamente raggiungibili con dispositivi e reti diversi |
| Pool IP | area dedicata senza sovrapposizione con LAN, WLAN, Site-to-Site VPN o vecchio Remote Access |
| Regole firewall | regole dedicate e chiaramente nominate per il nuovo pool VPN |
| Profili client | nuovo nome profilo, così gli utenti distinguono vecchia e nuova connessione |
| Criterio di fallback | definire prima quando si torna alla vecchia connessione |
| Finestra supporto | helpdesk o admin deve essere raggiungibile durante il pilot |
Un percorso di fallback non significa mantenere permanentemente la configurazione legacy. Serve solo a interrompere il pilot in modo controllato se login, MFA, DNS, routing o applicazioni centrali non funzionano. Appena la nuova soluzione è stabile, la vecchia configurazione dovrebbe essere rimossa e il blocco dell’upgrade verificato di nuovo.
Test prima di rimuovere la configurazione legacy
La vecchia configurazione dovrebbe essere rimossa solo dopo che il sostituto è stato testato. Altrimenti il problema dell’upgrade è risolto, ma Remote Access può interrompersi in produzione.
Test funzionale
Verificare almeno:
- il login con utente di test funziona
- MFA o SSO viene richiesto come previsto
- il client riceve un IP VPN adatto
- i nomi DNS interni vengono risolti
- i server centrali sono raggiungibili
- il comportamento Internet corrisponde al design: Split Tunnel o Full Tunnel
- logout e nuovo login funzionano
Test firewall e routing
Nel Log Viewer verificare se il traffico dalla zona VPN intercetta le regole attese. Se il traffico viene scartato, non bisogna controllare solo la configurazione VPN, ma anche regola firewall, NAT, Route Precedence e percorso di ritorno. Per singole connessioni è utile l’articolo Testare una regola firewall con Log Viewer, Policy Test e Packet Capture.
Test client
Con Sophos Connect i profili esistenti non dovrebbero essere sovrascritti in silenzio. Meglio un piccolo pilot con feedback chiaro:
- Il client importa la nuova configurazione?
- La vecchia connessione viene sostituita in modo comprensibile per gli utenti?
- La connessione funziona dopo un riavvio?
- Suffissi DNS, route e connessioni salvate sono corretti?
- Ci sono differenze tra Windows e macOS?
Prima di un rollout ampio va controllata anche la versione client in uso. A questo scopo è adatto Controllare e aggiornare in modo sicuro la versione di Sophos Connect Client.
Rimuovere la configurazione legacy
Quando la nuova soluzione è stata testata in produzione, la configurazione legacy può essere rimossa. Prima va creato ancora un backup attuale. Questo è particolarmente importante se nello stesso change vengono adattate anche regole firewall, gruppi utenti o server di autenticazione.
Procedura pratica:
- Creare un backup fresco.
- Informare gli utenti attivi sulla finestra di manutenzione.
- Lasciare attiva la nuova configurazione Remote Access.
- Rimuovere Legacy Remote Access IPsec in WebAdmin.
- Verificare profili, pool IP e regole vecchi non più necessari.
- Riaprire la pagina firmware e controllare se il blocco dell’upgrade è scomparso.
- Documentare il risultato.
Non eliminare subito tutto ciò che sembra vecchio. Vecchie regole firewall, host o gruppi possono essere usati anche per Site-to-Site VPN, SSL VPN o altri scopi. Prima verificare le dipendenze, poi ripulire.
Dopo un restore o un’importazione della configurazione, il controllo dovrebbe essere ripetuto. Un backup può contenere vecchi oggetti legacy senza che da questo nasca automaticamente una configurazione Remote Access IPsec attuale. Per operatività e documentazione è quindi decisivo se la configurazione produttiva di destinazione è stata davvero ricreata, testata e distribuita.
Troubleshooting
L’upgrade resta ancora bloccato
Se l’upgrade continua a essere bloccato anche se la configurazione legacy visibile è stata rimossa, prima ricaricare il firewall o riaprire l’area firmware. Poi verificare se tutti gli oggetti Legacy Remote Access sono stati davvero rimossi. Se non è chiaro quale oggetto blocca, preparare un Sophos Support Case con screenshot del messaggio di upgrade e backup attuale.
Dopo un restore ricompare la domanda sulla configurazione legacy
Dopo restore, sostituzione hardware o import di una vecchia configurazione, Remote Access va verificato di nuovo. Non conta se il change precedente era stato completato una volta, ma cosa è presente nella configurazione attualmente in esecuzione. Vecchi backup possono reintrodurre oggetti Remote Access storici o attivare una nuova verifica del percorso di upgrade.
Gli utenti non riescono ad autenticarsi
In caso di problemi di login, controllare prima autenticazione, MFA, gruppo utenti e VPN policy. Se sono coinvolti RADIUS, AD o Entra ID, la connessione al server va testata separatamente dalla VPN. Un problema VPN non è sempre un problema IPsec.
La connessione è attiva, ma i sistemi interni non sono raggiungibili
La causa è spesso in regole firewall, NAT, DNS o routing. Verificare se il client riceve un IP VPN adatto, se i nomi interni vengono risolti correttamente e se il traffico nel Log Viewer intercetta la regola attesa.
Alcune reti funzionano, altre no
In questo caso sono spesso coinvolte reti Split Tunnel, route IPsec, route statiche o route di ritorno mancanti. Negli scenari IPsec, Route IPsec su Sophos Firewall è un articolo successivo utile.
Checklist
Prima del rollout
- Legacy Remote Access IPsec identificato
- utenti, gruppi, pool IP, DNS e regole firewall documentati
- percorso di destinazione scelto: IPsec attuale, SSL VPN, ZTNA o combinazione
- MFA e autenticazione verificati
- Device Access per IPsec, VPN Portal, DNS e Ping verificato
- coesistenza e criterio di fallback definiti
- utenti di test definiti
- backup creato
Durante il rollout
- nuova configurazione testata con utenti pilot
- profili client distribuiti
- Log Viewer e regole firewall interessate verificati
- percorso di fallback comunicato
- feedback utenti raccolto
Dopo la migrazione
- configurazione legacy rimossa
- blocco dell’upgrade verificato di nuovo
- scenario di restore e import documentato
- vecchi profili e regole verificati per dipendenze
- documentazione aggiornata
- upgrade firmware pianificato solo dopo