Migrera Legacy Remote Access IPsec före SFOS 22 MR1

Med SFOS 22.0 MR1 har Sophos tagit Legacy Remote Access IPsec VPN ur bruk. Redan en legacy-konfiguration som finns på brandväggen blockerar uppgraderingen till SFOS 22.0 MR1 och senare versioner. Den måste tas bort före uppgraderingen, även om ingen längre ansluter via den.

Artikeln beskriver hur man identifierar den gamla konfigurationen före en firmwareuppgradering, dokumenterar den ordentligt, 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 uppgradering till SFOS 22.

Vad Legacy Remote Access IPsec innebär

Sophos har genom åren haft stöd för flera olika Remote Access-lösningar. Därför är det i många miljöer inte omedelbart 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 följande avgörande:

• Legacy Remote Access IPsec är den gamla konfigurationstypen som kan blockera uppgraderingen.
• Aktuell Remote Access IPsec är målvägen om IPsec ska fortsätta 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 lämpligt när ett fullständigt klient-VPN inte längre behövs, utan endast åtkomst till enskilda applikationer.

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

Även klientfilerna hjälper till att skilja konfigurationerna åt:

• För en legacy-anslutning extraherades en .tgb-fil ur ett hämtat .tar-arkiv och importerades till en VPN-klient från tredje part.
• Den aktuella Remote Access IPsec-konfigurationen kan exportera en .scx-fil för Sophos Connect. Den innehåller både de allmänna och de avancerade inställningarna.
• En modern .tgb-fil är i sig inget bevis på en legacy-konfiguration, eftersom den aktuella IPsec-sidan fortfarande kan exportera den för klienter från tredje part. Det som är avgörande är posten under Remote access VPN > IPsec (legacy).

Ett viktigt restore-fall förbises lätt: säkerhetskopior eller importerade konfigurationer kan innehålla Legacy Remote Access IPsec. Sophos återställer eller importerar visserligen konfigurationen, men migrerar den inte till den aktuella Remote Access IPsec-modellen. Efter restore, hårdvarubyte eller konfigurationsimport måste uppgraderingsblockeringen därför kontrolleras på nytt.

När man bör migrera

Migreringen bör vara avslutad före den planerade uppgraderingen till SFOS 22 MR1. Den här ändringen 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, brandväggsregler 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.
• Det finns gamla Sophos Connect-profiler i miljön 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 separat 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 verkar, eftersom många VPN-konfigurationer inte enbart består av en tunnelprofil. Ofta är även användargrupper, IP-pooler, DNS-inställningar, brandväggsregler, NAT-undantag och klientfiler kopplade till den.

Kontrollera legacy-konfigurationen i WebAdmin

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

Praktiskt tillvägagångssätt:

1. Öppna Remote access VPN > IPsec (legacy) på den utgångsversion som fortfarande stöds.
2. Kontrollera om det finns en legacy-anslutning där. För uppgraderingsblockeringen spelar det ingen roll om den används aktivt just nu.
3. Öppna Remote access VPN > IPsec och dokumentera den aktuella Remote Access IPsec-konfigurationen separat.
4. Kontrollera Authentication > Users och användargrupper om statiska IP-adresser, lokala användare eller gamla grupptilldelningar har använts.
5. Sök i Rules and policies > Firewall rules efter regler från zonen VPN till LAN, DMZ eller WAN.
6. Kontrollera under Administration > Device access om IPsec, VPN Portal, DNS eller Ping kan nås från de zoner där detta behövs.
7. Öppna firmware-sidan igen och kontrollera om en uppgraderingsblockering fortfarande visas.

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

Minst följande ska dokumenteras:

• 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-klienterna? Finns det konflikter med LAN, WLAN, VLAN eller andra VPN?
• DNS: Vilka DNS-servrar och domäner distribueras till klienterna?
• Åtkomst: Vilka interna nät, servrar och tjänster måste kunna nås?
• Brandväggsregler: Vilka regler tillåter trafik från VPN till LAN, DMZ eller WAN?
• Klientdistribution: Var finns gamla .tgb-filer, aktuella Sophos Connect-profiler (.scx eller .pro) eller SSL VPN-konfigurationer?
• Drift: Vem kan informera användare, distribuera profiler och ta emot felanmälningar?

Om det redan finns problem med routing eller trafik genom tunneln bör de inte föras över okontrollerat 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 faktiskt 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 ska fortsätta användas och miljön i grunden fungerar bra med det. IPsec har ofta hög prestanda, men kan orsaka problem i restriktiva externa nät på grund av blockerade UDP-portar eller särskilda NAT-fall.

Denna väg passar bra när:

• Sophos Connect redan är distribuerat
• användarna arbetar med Windows 10/11 eller macOS 13 och senare
• IPsec har varit stabilt i den tidigare driften
• interna nät ska kunna nås via klassiska brandväggsregler

Sophos Connect stöder aktuell Remote Access IPsec på dessa Windows- och macOS-versioner. För Linux och andra mobila plattformar krävs en lämplig klient från tredje part. iOS kan installera en egen IPsec-profil från VPN Portal. Den befintliga guiden konfigurera Sophos Connect Client på Sophos Firewall beskriver hela konfigurationen.

SSL VPN

SSL VPN är lämpligt när Remote Access ska fungera så robust som möjligt genom olika externa nät. Beroende på miljön kan SSL VPN vara enklare, men medför andra frågor om 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 andra företagsnät
• IPsec-anslutningar återkommande misslyckas på grund av nätverksrestriktioner
• befintliga SSL VPN-processer redan är etablerade
• mobila plattformar eller OpenVPN-klienter från tredje part spelar en roll

ZTNA eller Clientless Access

Om användarna endast behöver enskilda interna webbapplikationer eller definierade applikationer bör man kontrollera om ett klassiskt full tunnel-VPN fortfarande är rätt lösning. ZTNA är inte en direkt ersättning för alla VPN-scenarier, men kan vara den bättre arkitekturen i tydligt avgränsade användningsfall.

Som beslutsunderlag passar först Vad är Zero Trust Network Access? Grunder, fördelar och begränsningar. Om Sophos ZTNA ska användas beskriver Sophos ZTNA Gateway Connector den konkreta komponenten. Clientless Access är endast ett alternativ för lämpliga webbläsarbaserade tjänster och ersätter inte allmän nätverksåtkomst.

Bygg upp en 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 lösning.

För aktuell Remote Access IPsec räcker det inte att bara skapa ett nytt profilnamn. Migrationsförloppet bör medvetet överföra eller definiera om de avgörande inställningarna:

1. Fastställ målvariant: aktuell Remote Access IPsec, SSL VPN, ZTNA eller en kombination.
2. Aktivera Remote Access under Remote access VPN > IPsec och välj externt Interface.
3. Använd en lämplig IPsec profile. Remote Access accepterar IKEv1-profiler där Dead Peer Detection är inaktiverat eller inställt på Disconnect.
4. Fastställ Authentication type, lokal och fjärransluten ID samt Allowed users and groups.
5. Välj under Assign IP from ett privat adressintervall från minst ett /24-subnät. Det får inte överlappa SSL VPN, L2TP, PPTP, LAN, WLAN eller Site-to-Site-nät.
6. Ange DNS server 1 och vid behov DNS server 2 samt de interna resurser som behövs.
7. Välj medvetet Split Tunnel eller Use as default gateway och konfigurera Prompt users for 2FA token så att det passar MFA-metoden.
8. Kontrollera under Authentication > Groups att Remote Access IPsec är tillåtet för den användargrupp som faktiskt gäller. För importerade AD-grupper och migrerade grupper aktiveras detta inte automatiskt.
9. Tillåt IPsec från WAN-zonen under Administration > Device access. VPN Portal behövs endast om klienterna eller provisioneringen ska nå den. DNS och Ping aktiveras endast när den konkreta utformningen kräver det.
10. Skapa separata och tydligt namngivna brandväggsregler för inkommande och utgående VPN-trafik och aktivera logging.
11. Skapa en .scx-fil för Sophos Connect med Export connection eller uppdatera en befintlig .pro-provisionering.
12. Distribuera testprofilen till ett fåtal pilotanvändare, testa via minst två olika nätanslutningar och planera först därefter utrullningen.

MFA bör inte behandlas som en valfri detalj för Remote Access. Om VPN är nåbart globalt hör MFA, tydliga 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 parallellt med den gamla konfigurationen. Då kan man migrera användarna stegvis och gå tillbaka kontrollerat vid fel, utan att samtidigt ändra Remote Access, brandväggsregler, DNS, MFA och klientdistribution under samma underhållsfönster.

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

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

• Pilotgrupp: ett fåtal tekniskt nåbara användare med olika enheter och nät.
• IP-pool: eget intervall utan överlappning med LAN, WLAN, Site-to-Site VPN eller gammal Remote Access.
• Brandväggsregler: egna, tydligt namngivna regler för den nya VPN-poolen.
• Klientprofiler: nytt anslutningsnamn så att användarna kan skilja mellan legacy- och målanslutningen.
• Återgångskriterium: definiera i förväg när man ska gå tillbaka till den gamla anslutningen.
• Supportfönster: helpdesk eller administratör måste vara nåbar under piloten.

En återgångsväg innebär inte att legacy-konfigurationen ska fortsätta användas permanent. Den finns bara för att piloten ska kunna avbrytas 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 uppgraderingsblockeringen 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 sluta fungera i produktionen.

Funktionstest

Kontrollera minst följande:

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

Brandväggs- och routingtest

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

Klienttest

Med Sophos Connect bör befintliga profiler inte skrivas över utan information. 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 anslutningen efter en omstart?
• Är DNS-suffix, rutter och sparade anslutningar korrekta?
• Finns det skillnader mellan Windows och macOS?

Vid distribution av .scx måste en senare ändring exporteras och importeras på nytt. En redan konfigurerad .pro-provisionering kan hämta senare ändringar automatiskt så länge gateway-adressen och VPN Portal-porten är nåbara och oförändrade.

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

Ta bort legacy-konfigurationen

När den nya lösningen har testats i produktionen kan legacy-konfigurationen tas bort. Innan dess bör en aktuell backup skapas igen. Det är särskilt viktigt om brandväggsregler, användargrupper eller autentiseringsservrar också justeras inom samma change.

Praktiskt tillvägagångssätt:

1. Skapa en ny backup.
2. Informera aktiva användare om underhållsfönstret.
3. Låt den nya Remote Access-konfigurationen vara aktiv.
4. Ta bort Legacy Remote Access IPsec i WebAdmin.
5. Kontrollera beroenden för gamla profiler, IP-pooler och regler som inte längre behövs.
6. Öppna firmware-sidan igen och kontrollera om uppgraderingsblockeringen har försvunnit.
7. Dokumentera resultatet.

Radera inte omedelbart allt som ser gammalt ut. Gamla brandväggsregler, hosts eller grupper kan även användas för Site-to-Site VPN, SSL VPN eller andra ändamål. Kontrollera först beroendena och rensa därefter.

Efter 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 är fortfarande blockerad

Om uppgraderingen fortfarande blockeras trots att den synliga legacy-konfigurationen har tagits bort ska firmwareområdet först öppnas på nytt och Remote access VPN > IPsec (legacy) kontrolleras igen. Radera inte hosts, grupper eller aktuella IPsec-profiler på måfå. Om det fortfarande är oklart vilken legacy-konfiguration som identifieras bör ett Sophos Support Case förberedas med en skärmbild av uppgraderingsmeddelandet, utgångsversionen och en aktuell backup.

Efter restore dyker legacy-frågan upp igen

Efter restore, hårdvarubyte eller import av en gammal konfiguration bör Remote Access kontrolleras igen. Det avgörande är inte om den tidigare ändringen en gång slutfördes, utan vad som finns i den konfiguration som körs nu. Gamla säkerhetskopior kan återinföra historiska Remote Access-objekt eller utlösa en ny kontroll av uppgraderingsvägen.

Användare kan inte logga in

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

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

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

Vissa 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 utrullningen

• Legacy Remote Access IPsec identifierat
• användare, grupper, IP-pool, DNS och brandväggsregler dokumenterade
• målväg vald: aktuell IPsec, SSL VPN, ZTNA eller en kombination
• MFA och autentisering kontrollerade
• Device Access kontrollerat efter behov: IPsec på WAN, VPN Portal för distribution eller provisionering, DNS och Ping endast vid behov
• samexistens och återgångskriterium definierade
• testanvändare definierade
• backup skapad

Under utrullningen

• den nya konfigurationen testad med pilotanvändare
• klientprofiler distribuerade
• Log Viewer och berörda brandväggsregler kontrollerade
• återgångsväg kommunicerad
• användarfeedback insamlad

Efter migreringen

• legacy-konfiguration borttagen
• uppgraderingsblockering kontrollerad igen
• restore- och importscenario dokumenterat
• gamla profiler och regler kontrollerade med avseende på beroenden
• dokumentation uppdaterad
• firmwareuppgradering planerad först därefter

FAQ