Migrera Legacy Remote Access IPsec före SFOS 22 MR1

Med SFOS 22.0 MR1 har Sophos slutgiltigt tagit bort Legacy Remote Access IPsec VPN från den stödda uppgraderingsvägen. Brandväggar där denna gamla Remote-Access-IPsec-konfiguration fortfarande finns kan inte uppdateras till SFOS 22.0 MR1 eller nyare versioner.

Artikeln beskriver hur man identifierar den gamla konfigurationen före en firmwareuppgradering, dokumenterar den rent, ersätter den med en aktuell Remote-Access-lösning och först därefter tar bort den. För den allmänna uppgraderingskontrollen passar även kontrollera Sophos Firewall före SFOS 22-uppgradering.

Vad Legacy Remote Access IPsec handlar om

Sophos har under åren stött flera vägar för Remote Access. Därför är det i många miljöer inte direkt tydligt om det handlar om en aktuell IPsec-konfiguration, en gammal legacy-post, SSL VPN eller Sophos Connect.

För uppgraderingen till SFOS 22 MR1 är framför allt detta avgörande:

Legacy Remote Access IPsec är den gamla konfigurationstypen som kan blockera uppgraderingen.
Aktuell Remote Access IPsec är målvägen om IPsec fortsatt ska användas.
SSL VPN kan vara ett alternativ om IPsec regelbundet blockeras på hotell, i gästnät eller i mobilnätsmiljöer.
ZTNA kan vara meningsfullt när det inte längre behövs ett komplett klient-VPN, utan åtkomst till enskilda applikationer.

Skillnaden är viktig i drift. En grön VPN-status eller en fungerande Sophos Connect Client bevisar inte automatiskt att ingen legacy-konfiguration längre finns på brandväggen.

Ett viktigt restore-fall förbises lätt: säkerhetskopior eller importerade konfigurationer kan innehålla Legacy Remote Access IPsec, men denna legacy-konfiguration migreras inte automatiskt. Efter restore, hårdvarubyte eller konfigurationsimport bör man därför kontrollera punkten igen, även om brandväggen tidigare redan verkade rensad.

När man bör migrera

Migreringen bör vara avslutad före den planerade uppgraderingen till SFOS 22 MR1. Denna ändring bör inte göras först under underhållsfönstret för firmwareuppdateringen, eftersom Remote Access ofta berör användare, certifikat, MFA, DNS, firewallregler och klientkonfigurationer.

Typiska utlösare:

Sophos Firewall ska uppdateras till SFOS 22.0 MR1 eller senare.
Firmware-sidan eller Sophos-dokumentationen hänvisar till Legacy Remote Access IPsec.
I miljön finns gamla Sophos Connect-profiler som inte har kontrollerats på flera år.
Användare rapporterar återkommande Remote-Access-problem efter profil- eller klientbyten.
Remote Access ska ändå omvärderas med MFA, Entra ID SSO, SSL VPN eller ZTNA.

Om Remote Access är verksamhetskritiskt bör migreringen behandlas som ett eget change-projekt. En firmwareuppgradering är då bara anledningen, inte hela arbetsomfattningen.

Dokumentera före migreringen

Först dokumenteras nuläget. Detta steg är viktigare än det ser ut, eftersom många VPN-konfigurationer inte bara består av en tunnelprofil. Ofta hänger användargrupper, IP-pooler, DNS-inställningar, firewallregler, NAT-undantag och klientfiler ihop med den.

Kontrollera legacy-konfigurationen i WebAdmin

Före målplaneringen bör man fastställa rent om det verkligen är Legacy Remote Access IPsec som berörs. Kontrollen hör inte bara hemma före firmwareuppgraderingen, utan även efter restore, hårdvarubyte eller konfigurationsimport.

Praktiskt förfarande:

Öppna Remote access VPN > IPsec (legacy) om menypunkten är synlig i den installerade SFOS-versionen.
Kontrollera om Legacy Remote Access IPsec är aktiverat eller om konfigurationsobjekt fortfarande finns.
Öppna Remote access VPN > IPsec och dokumentera den aktuella Remote-Access-IPsec-konfigurationen separat.
Kontrollera Authentication > Users och användargrupper om statiska IP-adresser, lokala användare eller gamla grupptilldelningar har använts.
Sök i Rules and policies > Firewall rules efter regler från zonen VPN till LAN, DMZ eller WAN.
Kontrollera i Administration > Device access om IPsec, VPN Portal, DNS eller Ping kan nås från nödvändiga zoner.
Öppna firmware-sidan igen och kontrollera om en uppgraderingsblockerare fortfarande visas.

Om legacy-området inte längre syns men uppgraderingen fortfarande blockeras bör man inte radera objekt på chans. Då är en skärmbild av meddelandet, en aktuell backup och en spårbar objektlista viktigare än stressad upprensning under underhållsfönstret.

Minst följande bör dokumenteras:

Område	Vad som bör kontrolleras
Användare och grupper	Vilka användare får använda Remote Access? Används lokala användare, AD, RADIUS eller Entra ID?
Autentisering	Lösenord, MFA, certifikat, Preshared Key eller SSO-beroenden
IP-pool	Vilka adresser får VPN-klienter? Finns konflikter med LAN, WLAN, VLAN eller andra VPN?
DNS	Vilka DNS-servrar och domäner distribueras till klienter?
Åtkomst	Vilka interna nät, servrar och tjänster måste kunna nås?
Firewallregler	Vilka regler tillåter trafik från `VPN` till `LAN`, `DMZ` eller `WAN`?
Klientdistribution	Var finns aktuella Sophos Connect-profiler eller SSL-VPN-konfigurationer?
Drift	Vem kan informera användare, distribuera profiler och ta emot fel?

Om det redan finns problem med routing eller trafik genom tunneln bör man inte okontrollerat föra över dem till den nya konfigurationen. För analysen hjälper Sophos Firewall IPsec VPN Troubleshooting.

Välj målväg

Det finns inte en enda rätt ersättning för Legacy Remote Access IPsec. Valet beror på vad användarna verkligen behöver och hur miljön drivs.

Aktuell Remote Access IPsec

Aktuell Remote Access IPsec ligger nära till hands om Sophos Connect med IPsec fortsatt ska användas och miljön i grunden fungerar bra med det. IPsec är ofta prestandastarkt, men kan märkas i restriktiva främmande nät genom blockerade UDP-portar eller särskilda NAT-fall.

Denna väg passar bra när:

Sophos Connect redan är distribuerat
användare främst arbetar med Windows eller macOS
IPsec har varit stabilt i tidigare drift
interna nät ska nås via klassiska firewallregler

Den befintliga guiden konfigurera Sophos Connect Client på Sophos Firewall kan användas som grund, men måste jämföras med aktuella SFOS-versioner och den egna autentiseringsdesignen.

SSL VPN

SSL VPN är meningsfullt när Remote Access ska fungera så robust som möjligt genom olika främmande nät. Beroende på miljö kan SSL VPN vara enklare, men skapar andra frågor kring prestanda och klienter. För Windows finns guiden installera Sophos Connect SSL VPN Client.

Denna väg passar bra när:

användare ofta arbetar på hotell, i gäst-WLAN eller i främmande företagsnät
IPsec-anslutningar återkommande misslyckas på grund av nätverksrestriktioner
befintliga SSL-VPN-processer redan är etablerade
mobila plattformar eller tredjeparts-OpenVPN-klienter spelar en roll

ZTNA eller Clientless Access

Om användare bara behöver enskilda interna webbapplikationer eller definierade applikationer bör man kontrollera om ett klassiskt fulltunnel-VPN över huvud taget fortfarande är rätt lösning. ZTNA är inte en direkt ersättning för varje VPN-scenario, men kan vara den bättre arkitekturen i tydligt avgränsade användningsfall.

Den befintliga artikeln Sophos ZTNA Gateway Connector är en bra startpunkt för detta. För enkel webbåtkomst kan även Clientless Access vara relevant om kraven passar.

Bygg upp ny Remote-Access-konfiguration

Den nya konfigurationen bör förberedas parallellt innan den gamla tas bort. Målet är inte att flytta alla användare samtidigt till en otestad uppsättning.

Rekommenderat förfarande:

Fastställ målvariant: aktuell Remote Access IPsec, SSL VPN, ZTNA eller kombination.
Välj ny IP-pool och kontrollera överlappningar.
Fastställ autentiseringskälla och MFA.
Tilldela nödvändiga användare eller grupper.
Definiera DNS-servrar och interna domäner.
Skapa firewallregler för de nya VPN-källorna.
Skapa testprofil för några få användare.
Testa anslutningen via minst två olika nätanslutningar.
Planera först därefter användarkommunikation och rollout.

MFA bör inte behandlas som en valfri detalj vid Remote Access. Om VPN är nåbart globalt hör MFA, rena användargrupper, logging och en granskning av Device-Access-inställningarna ihop. Artikeln konfigurera Sophos Firewall MFA täcker grunderna.

Planera samexistens och återgång

Den nya Remote-Access-lösningen bör först testas bredvid den gamla konfigurationen. Då kan man migrera användare stegvis och gå tillbaka riktat vid fel, utan att samtidigt ändra Remote Access, firewallregler, DNS, MFA och klientdistribution i samma underhållsfönster.

Det är dock viktigt att samexistensen planeras rent. Den nya konfigurationen bör inte använda samma IP-pool, samma otydligt namngivna firewallregler eller samma profilnamn som den gamla legacy-konfigurationen. Annars går det senare inte längre att se i Log Viewer vilken åtkomst som faktiskt anslöt en användare.

Före piloten bör dessa punkter vara fastställda:

Punkt	Rekommendation
Pilotgrupp	få tekniskt nåbara användare med olika enheter och nät
IP-pool	eget område utan överlappning med LAN, WLAN, Site-to-Site VPN eller gammal Remote Access
Firewallregler	egna, tydligt namngivna regler för den nya VPN-poolen
Klientprofiler	nytt profilnamn så att användare kan skilja på gammal och ny anslutning
Återgångskriterium	definiera i förväg när man går tillbaka till den gamla anslutningen
Supportfönster	helpdesk eller admin måste vara nåbar under piloten

En återgångsväg betyder inte att legacy-konfigurationen ska drivas vidare permanent. Den är bara till för att kunna avbryta piloten kontrollerat om inloggning, MFA, DNS, routing eller centrala applikationer inte fungerar. Så snart den nya lösningen är stabil bör den gamla konfigurationen tas bort och uppgraderingsblockeraren kontrolleras igen.

Tester före borttagning av legacy-konfigurationen

Den gamla konfigurationen bör tas bort först när ersättningen har testats. Annars är uppgraderingsproblemet visserligen löst, men Remote Access kan falla bort i produktion.

Funktionstest

Kontrollera minst:

inloggning med testanvändare fungerar
MFA eller SSO efterfrågas som väntat
klienten får en passande VPN-IP
interna DNS-namn löses upp
centrala servrar kan nås
internetbeteendet motsvarar designen: Split Tunnel eller Full Tunnel
utloggning och ny inloggning fungerar

Firewall- och routingtest

Kontrollera i Log Viewer om trafik från VPN-zonen träffar de förväntade reglerna. Om trafik släpps bör man inte bara kontrollera VPN-konfigurationen, utan även firewallregel, NAT, Route Precedence och returväg. För enskilda anslutningar är artikeln testa firewallregel med Log Viewer, Policy Test och Packet Capture hjälpsam.

Klienttest

Med Sophos Connect bör befintliga profiler inte skrivas över i det tysta. Bättre är en liten pilot med tydlig återkoppling:

Importerar klienten den nya konfigurationen?
Ersätts den gamla anslutningen på ett begripligt sätt för användarna?
Fungerar anslutningsuppbyggnaden efter omstart?
Är DNS-suffix, rutter och sparade anslutningar korrekta?
Finns skillnader mellan Windows och macOS?

Före en bred rollout bör även den klientversion som används kontrolleras. För detta passar kontrollera Sophos Connect Client-version och uppdatera säkert.

Ta bort legacy-konfiguration

När den nya lösningen har testats i produktion kan legacy-konfigurationen tas bort. Före detta bör en aktuell backup skapas igen. Det är särskilt viktigt om firewallregler, användargrupper eller autentiseringsservrar också justeras i samma change.

Praktiskt förfarande:

Skapa färsk backup.
Informera aktiva användare om underhållsfönstret.
Låt den nya Remote-Access-konfigurationen vara aktiv.
Ta bort Legacy Remote Access IPsec i WebAdmin.
Kontrollera gamla profiler, IP-pooler och regler som inte längre behövs.
Öppna firmware-sidan igen och kontrollera om uppgraderingsblockeraren har försvunnit.
Dokumentera resultatet.

Radera inte direkt allt som ser gammalt ut. Gamla firewallregler, hosts eller grupper kan även användas för Site-to-Site-VPN, SSL VPN eller andra ändamål. Kontrollera först beroenden och rensa sedan.

Efter en restore eller konfigurationsimport bör kontrollen upprepas. En backup kan innehålla gamla legacy-objekt utan att det automatiskt skapas en aktuell Remote-Access-IPsec-konfiguration av dem. För drift och dokumentation är det därför avgörande om den produktiva målkonfigurationen verkligen har byggts upp på nytt, testats och distribuerats.

Troubleshooting

Uppgraderingen förblir blockerad

Om uppgraderingen fortsatt blockeras trots att den synliga legacy-konfigurationen har tagits bort, ladda först om brandväggen eller öppna firmwareområdet igen. Kontrollera därefter om verkligen alla legacy-Remote-Access-objekt har tagits bort. Om det fortfarande är oklart vilket objekt som blockerar bör ett Sophos Support Case förberedas med skärmbild av uppgraderingsmeddelandet och aktuell backup.

Efter restore dyker legacy-frågan upp igen

Efter restore, hårdvarubyte eller import av en gammal konfiguration bör man kontrollera Remote Access igen. Avgörande är inte om den tidigare ändringen en gång var avslutad, utan vad som finns i den konfiguration som körs just nu. Gamla säkerhetskopior kan ta tillbaka historiska Remote-Access-objekt eller utlösa en ny kontroll av uppgraderingsvägen.

Användare kan inte logga in

Vid inloggningsproblem kontrolleras först autentisering, MFA, användargrupp och VPN-policy. Om RADIUS, AD eller Entra ID är inblandat bör serveranslutningen testas separat från VPN. Ett VPN-problem är inte alltid ett IPsec-problem.

Anslutningen är uppe, men interna system kan inte nås

Då ligger orsaken ofta i firewallregler, NAT, DNS eller routing. Kontrollera om klienten får en passande VPN-IP, om interna namn löses upp korrekt och om trafiken i Log Viewer träffar den förväntade regeln.

Enskilda nät fungerar, andra inte

I detta fall är ofta Split-Tunnel-nät, IPsec-rutter, statiska rutter eller saknade returrutter inblandade. I IPsec-scenarier är IPsec Route på Sophos Firewall en lämplig uppföljningsartikel.

Checklista

Före rollout

Legacy Remote Access IPsec identifierat
användare, grupper, IP-pool, DNS och firewallregler dokumenterade
målväg vald: aktuell IPsec, SSL VPN, ZTNA eller kombination
MFA och autentisering kontrollerade
Device Access för IPsec, VPN Portal, DNS och Ping kontrollerat
samexistens och återgångskriterium definierade
testanvändare definierade
backup skapad

Under rollout

ny konfiguration testad med pilotanvändare
klientprofiler distribuerade
Log Viewer och berörda firewallregler kontrollerade
återgångsväg kommunicerad
användarfeedback insamlad

Efter migreringen

legacy-konfiguration borttagen
uppgraderingsblockerare kontrollerad igen
restore- och importscenario dokumenterat
gamla profiler och regler kontrollerade för beroenden
dokumentation uppdaterad
firmwareuppgradering planerad först därefter

FAQ

Måste Legacy Remote Access IPsec tas bort före SFOS 22 MR1?

Ja. Om denna legacy-konfiguration fortfarande finns kan brandväggen inte uppdateras till SFOS 22.0 MR1 eller senare.

Berörs även aktuell Remote Access IPsec?

Nej, uppgraderingsblockeraren avser Legacy Remote Access IPsec. Trots det bör man testa och dokumentera den aktuella Remote-Access-konfigurationen före en större uppgradering.

Är SSL VPN den bättre ersättningen?

Inte generellt. SSL VPN är ofta mer tolerant mot restriktiva främmande nät. IPsec kan däremot vara mer prestandastarkt. Avgörande är användarenheter, nätmiljöer, autentisering, MFA och driftprocesser.

Kan man bara radera den gamla konfigurationen?

Tekniskt kan den tas bort, men praktiskt bör en ersättning först testas och en backup skapas. Annars kan Remote Access sluta fungera för användare.

Vad händer efter en restore med gammal legacy-konfiguration?

Efter en restore eller konfigurationsimport bör man kontrollera Legacy Remote Access IPsec igen. Sådana konfigurationer kan finnas med, men migreras inte automatiskt till den aktuella Remote-Access-IPsec-konfigurationen.