Migracja Legacy Remote Access IPsec przed SFOS 22 MR1

Wraz z SFOS 22.0 MR1 Sophos wycofał Legacy Remote Access IPsec VPN. Już sama obecność konfiguracji legacy na firewallu blokuje aktualizację do SFOS 22.0 MR1 i nowszych wersji. Przed aktualizacją należy ją usunąć, nawet jeśli obecnie nikt już z niej nie korzysta.

Ten artykuł opisuje, jak przed aktualizacją firmware rozpoznać starą konfigurację, prawidłowo ją udokumentować, zastąpić aktualnym rozwiązaniem Remote Access, a dopiero potem usunąć. Ogólne sprawdzenie przed aktualizacją opisuje również artykuł Sprawdzenie Sophos Firewall przed aktualizacją do SFOS 22.

Czym jest Legacy Remote Access IPsec

Sophos przez lata obsługiwał kilka metod Remote Access. Dlatego w wielu środowiskach nie od razu wiadomo, czy chodzi o aktualną konfigurację IPsec, stary wpis legacy, SSL VPN czy Sophos Connect.

W przypadku aktualizacji do SFOS 22 MR1 najważniejsze jest rozróżnienie:

• Legacy Remote Access IPsec to stary typ konfiguracji, który może blokować aktualizację.
• Aktualny Remote Access IPsec to docelowa ścieżka, jeśli IPsec ma być nadal używany.
• SSL VPN może być alternatywą, jeśli IPsec jest regularnie blokowany w hotelach, sieciach dla gości lub sieciach komórkowych.
• ZTNA może być właściwym rozwiązaniem, jeśli zamiast pełnego Client VPN potrzebny jest tylko dostęp do poszczególnych aplikacji.

Ta różnica jest ważna z punktu widzenia eksploatacji. Zielony status VPN lub działający Sophos Connect Client nie dowodzi automatycznie, że na firewallu nie ma już konfiguracji legacy.

W rozpoznaniu pomagają również pliki klienta:

• W przypadku połączenia legacy plik .tgb był wyodrębniany z pobranego archiwum .tar, a następnie importowany do klienta VPN innej firmy.
• Aktualna konfiguracja Remote Access IPsec może eksportować plik .scx dla Sophos Connect. Zawiera on zarówno ustawienia ogólne, jak i zaawansowane.
• Sam współczesny plik .tgb nie jest jeszcze dowodem na konfigurację legacy, ponieważ aktualna strona IPsec nadal może go eksportować dla klientów innych firm. Decydujący jest wpis w Remote access VPN > IPsec (legacy).

Łatwo przeoczyć ważny przypadek przywracania: kopie zapasowe lub importowane konfiguracje mogą zawierać Legacy Remote Access IPsec. Sophos przywraca lub importuje tę konfigurację, ale nie migruje jej do aktualnego modelu Remote Access IPsec. Dlatego po przywróceniu, wymianie sprzętu lub imporcie konfiguracji należy ponownie sprawdzić blokadę aktualizacji.

Kiedy należy przeprowadzić migrację

Migrację należy zakończyć przed planowaną aktualizacją do SFOS 22 MR1. Nie powinno się wykonywać tej zmiany dopiero w oknie konserwacyjnym przeznaczonym na aktualizację firmware, ponieważ Remote Access często obejmuje użytkowników, certyfikaty, MFA, DNS, reguły firewalla i konfiguracje klientów.

Typowe powody migracji:

• Sophos Firewall ma zostać zaktualizowany do SFOS 22.0 MR1 lub nowszej wersji.
• Strona firmware lub dokumentacja Sophos wskazuje na Legacy Remote Access IPsec.
• W środowisku znajdują się stare profile Sophos Connect, których od lat nie sprawdzano.
• Użytkownicy zgłaszają powtarzające się problemy z Remote Access po zmianie profilu lub klienta.
• Remote Access i tak ma zostać ponownie oceniony pod kątem MFA, Entra ID SSO, SSL VPN lub ZTNA.

Jeśli Remote Access ma znaczenie krytyczne dla działalności firmy, migrację należy traktować jako osobny projekt zmiany. Aktualizacja firmware jest wtedy tylko przyczyną, a nie całym zakresem prac.

Dokumentacja przed migracją

Najpierw należy udokumentować stan bieżący. Ten krok jest ważniejszy, niż może się wydawać, ponieważ wiele konfiguracji VPN nie składa się wyłącznie z profilu tunelu. Często są z nimi powiązane grupy użytkowników, pule IP, ustawienia DNS, reguły firewalla, wyjątki NAT i pliki klientów.

Sprawdzenie konfiguracji legacy w WebAdmin

Przed zaplanowaniem rozwiązania docelowego należy jednoznacznie ustalić, czy rzeczywiście występuje Legacy Remote Access IPsec. Kontrola jest konieczna nie tylko przed aktualizacją firmware, lecz także po przywróceniu, wymianie sprzętu lub imporcie konfiguracji.

Praktyczna procedura:

1. Otwórz Remote access VPN > IPsec (legacy) w nadal obsługiwanej wersji źródłowej.
2. Sprawdź, czy znajduje się tam połączenie legacy. Dla blokady aktualizacji nie ma znaczenia, czy jest ono obecnie aktywnie używane.
3. Otwórz Remote access VPN > IPsec i osobno udokumentuj aktualną konfigurację Remote Access IPsec.
4. Sprawdź Authentication > Users i grupy użytkowników, jeśli używano statycznych adresów IP, lokalnych użytkowników lub starych przypisań do grup.
5. W Rules and policies > Firewall rules wyszukaj reguły prowadzące ze strefy VPN do LAN, DMZ lub WAN.
6. Sprawdź w Administration > Device access, czy IPsec, VPN Portal, DNS lub Ping są dostępne z wymaganych stref.
7. Ponownie otwórz stronę firmware i sprawdź, czy blokada aktualizacji nadal jest wyświetlana.

Jeśli sekcja legacy nie jest już widoczna, ale aktualizacja nadal jest blokowana, nie należy usuwać obiektów na chybił trafił. Zrzut ekranu komunikatu, aktualna kopia zapasowa i czytelna lista obiektów są wtedy ważniejsze niż pospieszne porządki w oknie konserwacyjnym.

Należy udokumentować co najmniej:

• Użytkownicy i grupy: Którzy użytkownicy mogą korzystać z Remote Access? Czy używani są użytkownicy lokalni, AD, RADIUS lub Entra ID?
• Uwierzytelnianie: Hasło, MFA, certyfikat, Preshared Key lub zależności SSO.
• Pula IP: Jakie adresy otrzymują klienci VPN? Czy występują konflikty z LAN, WLAN, VLAN lub innymi VPN?
• DNS: Jakie serwery DNS i domeny są przekazywane klientom?
• Dostęp: Które sieci wewnętrzne, serwery i usługi muszą być dostępne?
• Reguły firewalla: Które reguły zezwalają na ruch z VPN do LAN, DMZ lub WAN?
• Dystrybucja klienta: Gdzie znajdują się stare pliki .tgb, aktualne profile Sophos Connect (.scx lub .pro) albo konfiguracje SSL VPN?
• Eksploatacja: Kto może poinformować użytkowników, rozprowadzić profile i przyjmować zgłoszenia błędów?

Jeśli już występują problemy z routingiem lub ruchem przez tunel, nie należy przenosić ich bez weryfikacji do nowej konfiguracji. W analizie pomaga artykuł Rozwiązywanie problemów z IPsec VPN na Sophos Firewall.

Wybór ścieżki docelowej

Nie ma jednego właściwego zamiennika Legacy Remote Access IPsec. Wybór zależy od rzeczywistych potrzeb użytkowników i sposobu obsługi środowiska.

Aktualny Remote Access IPsec

Aktualny Remote Access IPsec jest naturalnym wyborem, jeśli Sophos Connect z IPsec ma być nadal używany i środowisko zasadniczo działa z nim prawidłowo. IPsec jest często wydajny, ale w restrykcyjnych sieciach zewnętrznych mogą występować problemy z blokowanymi portami UDP lub szczególnymi przypadkami NAT.

Ta ścieżka jest odpowiednia, jeśli:

• Sophos Connect jest już rozprowadzony
• użytkownicy pracują na Windows 10/11 lub macOS 13 i nowszych wersjach
• IPsec działał dotychczas stabilnie
• sieci wewnętrzne mają być dostępne przez klasyczne reguły firewalla

Sam Sophos Connect obsługuje aktualny Remote Access IPsec w tych wersjach Windows i macOS. Linux i inne platformy mobilne wymagają odpowiedniego klienta innej firmy; iOS może zainstalować własny profil IPsec z VPN Portal. Pełną konfigurację opisuje istniejąca instrukcja Konfiguracja Sophos Connect Client na Sophos Firewall.

SSL VPN

SSL VPN jest odpowiednim rozwiązaniem, jeśli Remote Access ma działać możliwie niezawodnie w różnych sieciach zewnętrznych. W zależności od środowiska SSL VPN może być prostszy, ale wiąże się z innymi kwestiami dotyczącymi wydajności i klienta. Dla Windows dostępna jest instrukcja Instalacja Sophos Connect SSL VPN Client.

Ta ścieżka jest odpowiednia, jeśli:

• użytkownicy często pracują w hotelach, sieciach WLAN dla gości lub obcych sieciach firmowych
• połączenia IPsec regularnie zawodzą z powodu ograniczeń sieciowych
• istniejące procesy SSL VPN są już wdrożone
• istotne są platformy mobilne lub klienci OpenVPN innych firm

ZTNA lub Clientless Access

Jeśli użytkownicy potrzebują tylko dostępu do pojedynczych wewnętrznych aplikacji webowych lub zdefiniowanych aplikacji, warto sprawdzić, czy klasyczny pełny tunel VPN nadal jest właściwym rozwiązaniem. ZTNA nie zastępuje bezpośrednio każdego scenariusza VPN, ale w jasno wydzielonych przypadkach użycia może być lepszą architekturą.

W podjęciu decyzji pomoże najpierw artykuł Czym jest Zero Trust Network Access? Podstawy, zalety i ograniczenia. Jeśli ma zostać wdrożony Sophos ZTNA, konkretny komponent opisuje Sophos ZTNA Gateway Connector. Clientless Access jest alternatywą tylko dla odpowiednich usług przeglądarkowych i nie zastępuje ogólnego dostępu do sieci.

Budowa nowej konfiguracji Remote Access

Nową konfigurację należy przygotować równolegle, zanim stara zostanie usunięta. Celem nie jest przeniesienie wszystkich użytkowników jednocześnie do nieprzetestowanej konfiguracji.

W przypadku aktualnego Remote Access IPsec samo utworzenie nowej nazwy profilu nie wystarczy. Proces migracji powinien świadomie przenieść lub na nowo określić kluczowe ustawienia:

1. Wybierz wariant docelowy: aktualny Remote Access IPsec, SSL VPN, ZTNA lub połączenie tych rozwiązań.
2. W Remote access VPN > IPsec włącz Remote Access i wybierz zewnętrzny Interface.
3. Użyj odpowiedniego IPsec profile. Remote Access akceptuje profile IKEv1, w których Dead Peer Detection jest wyłączone lub ustawione na Disconnect.
4. Określ Authentication type, lokalny i zdalny identyfikator oraz Allowed users and groups.
5. W Assign IP from wybierz prywatny zakres z co najmniej jednej podsieci /24. Nie może nakładać się na SSL VPN, L2TP, PPTP, LAN, WLAN ani sieci Site-to-Site.
6. Określ DNS server 1 i opcjonalnie DNS server 2 oraz wymagane zasoby wewnętrzne.
7. Świadomie wybierz Split Tunnel lub Use as default gateway i skonfiguruj Prompt users for 2FA token zgodnie z używaną metodą MFA.
8. W Authentication > Groups sprawdź, czy Remote Access IPsec jest dozwolony dla faktycznie obowiązującej grupy użytkowników. W przypadku importowanych grup AD i grup migrowanych nie jest to automatycznie aktywne.
9. W Administration > Device access zezwól na IPsec ze strefy WAN. VPN Portal jest wymagany tylko wtedy, gdy klienci lub provisioning uzyskują przez niego dostęp; DNS i Ping udostępnia się tylko wtedy, gdy wymaga tego konkretny projekt.
10. Utwórz oddzielne, jednoznacznie nazwane reguły firewalla dla przychodzącego i wychodzącego ruchu VPN oraz włącz logging.
11. Za pomocą Export connection utwórz plik .scx dla Sophos Connect lub zaktualizuj istniejący provisioning .pro.
12. Rozprowadź profil testowy wśród kilku użytkowników pilotażowych, przetestuj go na co najmniej dwóch różnych łączach sieciowych i dopiero potem zaplanuj rollout.

MFA w Remote Access nie należy traktować jako opcjonalnego szczegółu. Jeśli VPN jest dostępny globalnie, MFA, prawidłowo zdefiniowane grupy użytkowników, logging i przegląd ustawień Device Access stanowią jeden pakiet. Podstawy opisuje artykuł Konfiguracja MFA na Sophos Firewall.

Planowanie współistnienia i drogi powrotu

Nowe rozwiązanie Remote Access należy najpierw przetestować obok starej konfiguracji. Pozwala to stopniowo migrować użytkowników i w razie błędów świadomie wrócić do poprzedniego rozwiązania, bez jednoczesnej zmiany Remote Access, reguł firewalla, DNS, MFA i dystrybucji klientów w tym samym oknie konserwacyjnym.

Współistnienie trzeba jednak dokładnie zaplanować. Nowa konfiguracja nie powinna korzystać z tej samej puli IP, tych samych niejednoznacznie nazwanych reguł firewalla ani tych samych nazw profili co stara konfiguracja legacy. W przeciwnym razie w Log Viewer nie będzie można później ustalić, przez który dostęp użytkownik faktycznie się połączył.

Przed pilotażem należy ustalić:

• Grupa pilotażowa: kilku dostępnych technicznie użytkowników z różnymi urządzeniami i sieciami.
• Pula IP: osobny zakres bez nakładania się na LAN, WLAN, Site-to-Site VPN lub stary Remote Access.
• Reguły firewalla: osobne, jednoznacznie nazwane reguły dla nowej puli VPN.
• Profile klientów: nowa nazwa połączenia, aby użytkownicy mogli rozróżnić połączenie legacy od docelowego.
• Kryterium powrotu: wcześniejsze określenie, kiedy należy wrócić do starego połączenia.
• Okno wsparcia: helpdesk lub administrator musi być dostępny podczas pilotażu.

Droga powrotu nie oznacza stałego utrzymywania konfiguracji legacy. Służy jedynie do kontrolowanego przerwania pilotażu, jeśli logowanie, MFA, DNS, routing lub kluczowe aplikacje nie działają. Gdy nowe rozwiązanie jest stabilne, starą konfigurację należy usunąć i ponownie sprawdzić blokadę aktualizacji.

Testy przed usunięciem konfiguracji legacy

Starą konfigurację należy usunąć dopiero po przetestowaniu rozwiązania zastępczego. W przeciwnym razie problem z aktualizacją wprawdzie zniknie, ale Remote Access może przestać działać w środowisku produkcyjnym.

Test funkcjonalny

Należy sprawdzić co najmniej:

• logowanie za pomocą użytkownika testowego działa
• MFA lub SSO jest wywoływane zgodnie z oczekiwaniami
• klient otrzymuje odpowiedni adres VPN-IP
• wewnętrzne nazwy DNS są rozwiązywane
• kluczowe serwery są dostępne
• zachowanie połączenia internetowego jest zgodne z projektem: Split Tunnel lub Full Tunnel
• wylogowanie i ponowne logowanie działają

Test firewalla i routingu

W Log Viewer sprawdź, czy ruch ze strefy VPN trafia do oczekiwanych reguł. Jeśli ruch jest odrzucany, należy sprawdzić nie tylko konfigurację VPN, lecz także regułę firewalla, NAT, Route Precedence i trasę powrotną. W analizie pojedynczych połączeń pomaga artykuł Testowanie reguły firewalla za pomocą Log Viewer, Policy Test i Packet Capture.

Test klienta

W przypadku Sophos Connect nie należy bez ostrzeżenia nadpisywać istniejących profili. Lepszym rozwiązaniem jest mały pilotaż z jednoznaczną informacją zwrotną:

• Czy klient importuje nową konfigurację?
• Czy stare połączenie zostaje zastąpione w sposób zrozumiały dla użytkownika?
• Czy połączenie jest nawiązywane po ponownym uruchomieniu?
• Czy sufiksy DNS, trasy i zapisane połączenia są prawidłowe?
• Czy występują różnice między Windows i macOS?

W przypadku dystrybucji .scx każdą późniejszą zmianę trzeba ponownie wyeksportować i zaimportować. Skonfigurowany wcześniej provisioning .pro może automatycznie pobierać późniejsze zmiany, o ile adres bramy i port VPN Portal są dostępne i pozostają niezmienione.

Przed szerokim rolloutem należy również sprawdzić używaną wersję klienta. Pomaga w tym artykuł Sprawdzenie wersji Sophos Connect Client i bezpieczna aktualizacja.

Usunięcie konfiguracji legacy

Po przetestowaniu nowego rozwiązania w środowisku produkcyjnym można usunąć konfigurację legacy. Wcześniej należy jeszcze raz utworzyć aktualną kopię zapasową. Jest to szczególnie ważne, jeśli w ramach tej samej zmiany dostosowywane są również reguły firewalla, grupy użytkowników lub serwery uwierzytelniania.

Praktyczna procedura:

1. Utwórz świeżą kopię zapasową.
2. Poinformuj aktywnych użytkowników o oknie konserwacyjnym.
3. Pozostaw nową konfigurację Remote Access aktywną.
4. Usuń Legacy Remote Access IPsec w WebAdmin.
5. Sprawdź zależności starych profili, pul IP i reguł, które nie są już potrzebne.
6. Ponownie otwórz stronę firmware i sprawdź, czy blokada aktualizacji zniknęła.
7. Udokumentuj wynik.

Nie należy od razu usuwać wszystkiego, co wygląda na stare. Stare reguły firewalla, hosty lub grupy mogą być używane również przez Site-to-Site VPN, SSL VPN lub do innych celów. Najpierw należy sprawdzić zależności, a dopiero potem przeprowadzić porządki.

Po przywróceniu lub imporcie konfiguracji kontrolę należy powtórzyć. Kopia zapasowa może zawierać stare obiekty legacy, ale nie powoduje to automatycznego utworzenia aktualnej konfiguracji Remote Access IPsec. Dlatego z punktu widzenia eksploatacji i dokumentacji kluczowe jest to, czy docelowa konfiguracja produkcyjna rzeczywiście została utworzona od nowa, przetestowana i rozprowadzona.

Rozwiązywanie problemów

Aktualizacja nadal jest blokowana

Jeśli aktualizacja nadal jest blokowana mimo usunięcia widocznej konfiguracji legacy, najpierw ponownie otwórz sekcję firmware i jeszcze raz sprawdź Remote access VPN > IPsec (legacy). Nie usuwaj na chybił trafił hostów, grup ani aktualnych profili IPsec. Jeśli nadal nie wiadomo, która konfiguracja legacy jest wykrywana, należy przygotować Sophos Support Case ze zrzutem ekranu komunikatu aktualizacji, wersją źródłową i aktualną kopią zapasową.

Po przywróceniu ponownie pojawia się kwestia legacy

Po przywróceniu, wymianie sprzętu lub imporcie starej konfiguracji należy ponownie sprawdzić Remote Access. Decydujące jest nie to, czy wcześniejsza zmiana została kiedyś zakończona, lecz to, co znajduje się w aktualnie działającej konfiguracji. Stare kopie zapasowe mogą przywrócić historyczne obiekty Remote Access lub wywołać ponowne sprawdzenie ścieżki aktualizacji.

Użytkownicy nie mogą się zalogować

W przypadku problemów z logowaniem należy najpierw sprawdzić uwierzytelnianie, MFA, grupę użytkowników i VPN-Policy. Jeśli używane są RADIUS, AD lub Entra ID, połączenie z serwerem trzeba przetestować niezależnie od VPN. Problem z VPN nie zawsze jest problemem z IPsec.

Połączenie działa, ale systemy wewnętrzne są niedostępne

Przyczyną są wtedy często reguły firewalla, NAT, DNS lub routing. Sprawdź, czy klient otrzymuje odpowiedni adres VPN-IP, czy wewnętrzne nazwy są prawidłowo rozwiązywane i czy ruch w Log Viewer trafia do oczekiwanej reguły.

Niektóre sieci działają, a inne nie

W takim przypadku często przyczyną są sieci Split Tunnel, trasy IPsec, trasy statyczne lub brakujące trasy powrotne. W scenariuszach IPsec przydatnym artykułem uzupełniającym jest Trasa IPsec na Sophos Firewall.

Lista kontrolna

Przed rolloutem

• zidentyfikowano Legacy Remote Access IPsec
• udokumentowano użytkowników, grupy, pulę IP, DNS i reguły firewalla
• wybrano ścieżkę docelową: aktualny IPsec, SSL VPN, ZTNA lub połączenie tych rozwiązań
• sprawdzono MFA i uwierzytelnianie
• sprawdzono Device Access zgodnie z potrzebami: IPsec na WAN, VPN Portal do dystrybucji lub provisioningu, DNS i Ping tylko w razie potrzeby
• zdefiniowano współistnienie i kryterium powrotu
• wyznaczono użytkowników testowych
• utworzono kopię zapasową

Podczas rolloutu

• przetestowano nową konfigurację z użytkownikami pilotażowymi
• rozprowadzono profile klientów
• sprawdzono Log Viewer i powiązane reguły firewalla
• przekazano informacje o drodze powrotu
• zebrano opinie użytkowników

Po migracji

• usunięto konfigurację legacy
• ponownie sprawdzono blokadę aktualizacji
• udokumentowano scenariusz przywracania i importu
• sprawdzono zależności starych profili i reguł
• zaktualizowano dokumentację
• dopiero potem zaplanowano aktualizację firmware

FAQ