Jak naprawić timeout IPsec Remote Access po 4 godzinach w Sophos Firewall

Jeśli Sophos Connect z IPsec Remote Access i OTP rozłącza się po około czterech godzinach, przyczyną może być udokumentowany rekeying IKEv1 profilu domyślnego. Podczas rekeyingu fazy 1 firewall ponownie żąda OTP, a istniejący tunel zostaje przy tym przerwany. Sophos podaje dla profilu domyślnego interwał wynoszący około czterech godzin.

Ten artykuł wyjaśnia, jak rozpoznać to zachowanie, które logi do niego pasują i jak prawidłowo dostosować wartość za pomocą własnego profilu IPsec. W przypadku podstawowej konfiguracji Sophos Connect zacznij od artykułu Konfiguracja Sophos Connect na Sophos Firewall. Przy wyborze między IPsec, SSL VPN, klientami mobilnymi i ZTNA lepszym punktem wyjścia jest Sophos Connect czy SSL VPN: które rozwiązanie Remote Access wybrać?.

⚠️ Ważne: Ta przyczyna dotyczy Remote Access IPsec z IKEv1 i OTP. Wydłużenie czasu życia IKE nie rozwiąże problemu z rozłączaniem SSL VPN, skonfigurowanym Idle Timeout ani niestabilnym połączeniem internetowym.

Najpierw zawęź przyczynę

Problem z rekeyingiem jest prawdopodobny, jeśli jednocześnie występuje kilka przesłanek:

• Sophos Connect regularnie rozłącza się po około czterech godzinach.
• Po rozłączeniu użytkownicy muszą ponownie potwierdzić OTP lub MFA.
• Wcześniej połączenie jest stabilne, a po ponownym zalogowaniu znów działa.
• Inne profile VPN lub połączenia SSL VPN nie wykazują tego zachowania.
• Czas rozłączenia odpowiada rekeyingowi fazy 1 przypisanego profilu IPsec.
• W logu VPN w momencie rozłączenia pojawiają się odpowiednie komunikaty IKE, uwierzytelniania lub rekeyingu.

Najpierw w Remote access VPN > IPsec sprawdź, który IPsec profile jest wybrany i czy aktywowano Disconnect when tunnel is idle. Idle Timeout kończy wyłącznie nieaktywne połączenia po skonfigurowanym Idle session time interval. Jest to inne zachowanie niż powtarzające się rozłączenie z żądaniem OTP podczas aktywnego korzystania z połączenia.

Jeśli połączenie rozłącza się losowo, nie działa tylko w określonych sieciach albo bezpośrednio po zestawieniu nie przesyła ruchu, potrzebne jest raczej ogólne rozwiązywanie problemów z IPsec VPN.

Najpierw wyklucz Legacy Remote Access IPsec

Szczególnie w starszych środowiskach należy najpierw ustalić, który wariant IPsec Remote Access jest faktycznie używany. Ten artykuł dotyczy aktualnej konfiguracji Remote Access IPsec z Sophos Connect i profilami IPsec. Nie jest właściwym punktem wyjścia, jeśli nadal występuje Legacy Remote Access IPsec lub blokowana jest aktualizacja do SFOS 22.0 MR1.

Praktyczne rozróżnienie:

• Połączenie rozłącza się po podobnym czasie, a następnie ponownie się zestawia: ten artykuł jest właściwym kolejnym krokiem.
• Aktualizacja do SFOS 22.0 MR1 lub nowszej jest blokowana z powodu Legacy IPsec: najpierw przeczytaj Migracja Legacy Remote Access IPsec przed SFOS 22 MR1.
• Tunel jest połączony, ale cele wewnętrzne są niedostępne: przejdź do Rozwiązywanie problemów z IPsec VPN w Sophos Firewall.
• Użytkownicy mają przejść z IPsec na SSL VPN, ZTNA lub inny model: odpowiedni jest artykuł Sophos Connect czy SSL VPN: które rozwiązanie Remote Access wybrać?.

To rozróżnienie jest ważne, ponieważ dostosowanie Key life nie zastępuje koncepcji migracji. Jeśli na firewallu nadal znajduje się stara konfiguracja Legacy, przed większą aktualizacją firmware należy ją prawidłowo udokumentować, zastąpić i usunąć.

Dlaczego rekeying IKEv1 z OTP rozłącza tunel

Sophos Connect używa profilu IKEv1 dla Remote Access IPsec. W wielu środowiskach przypisany jest DefaultRemoteAccess. Profil ten określa między innymi czas życia Security Association fazy 1 oraz moment rozpoczęcia ponownej negocjacji.

Dla tego momentu istotne są trzy pola:

• Key life: maksymalny czas życia SA fazy 1 w sekundach.
• Re-key margin: okres przed upływem Key life, w którym rozpoczyna się ponowna negocjacja.
• Randomize re-keying margin by: procentowe zróżnicowanie momentu rekeyingu, aby wszystkie tunele nie rozpoczynały ponownej negocjacji jednocześnie.

Na istniejącym zrzucie ekranu profil DefaultRemoteAccess ma Key life wynoszący 18000 sekund. Nie można jednak wyprowadzać z tego uniwersalnego wzoru na cztery godziny: na moment widocznego przerwania wpływają Re-key margin, randomizacja, zachowanie klienta i uwierzytelnianie. Decydujące są wartości rzeczywiście przypisanego profilu oraz znaczniki czasu w konkretnym przypadku błędu.

Istotna jest decyzja merytoryczna: dłuższa wartość ogranicza liczbę ponownych uwierzytelnień, ale wydłuża także czas życia IKE-SA. Jest to decyzja operacyjna i dotycząca bezpieczeństwa, a nie tylko ustawienie poprawiające wygodę.

Skoreluj logi z czasem trwania połączenia

W Log viewer otwórz obszar VPN i porównaj zestawienie połączenia z późniejszym rozłączeniem tego samego użytkownika. Zanotuj czas rozpoczęcia, użytkownika, publiczny adres IP klienta oraz moment ponownego żądania OTP. Zarejestruj również stan klienta Sophos Connect w tym samym momencie.

Komunikaty takie jak invalid SPI mogą występować po wygaśnięciu lub zastąpieniu Security Associations. Same w sobie nie stanowią jednak dowodu tego problemu. Bardziej miarodajne jest połączenie regularnego czasu trwania, profilu IKEv1, żądania OTP i rekeyingu fazy 1 występującego w tym samym czasie. Przy powtarzających się problemach z VPN pomocne są również artykuły Zabezpieczanie logów Sophos Firewall na potrzeby wsparcia i analizy oraz Rozwiązywanie problemów z Sophos Firewall: usługi i logi.

Dostosuj profil IPsec przez GUI

Lepszą metodą jest niezmienianie bezpośrednio profilu domyślnego, lecz sklonowanie go i świadome użycie nowej wartości dla Remote Access.

Aktualna ścieżka menu to:

Profiles > IPsec profiles

Procedura:

1. Przy DefaultRemoteAccess kliknij Clone.
2. Nadaj nowemu profilowi jednoznaczną nazwę, na przykład RemoteAccess_OTP_12h.
3. Pozostaw Key exchange ustawione na IKEv1, a Re-key connection włączone.
4. W sekcji Phase 1 sprawdź wartości Key life, Re-key margin i Randomize re-keying margin by.
5. Wprowadź żądaną wartość Key life. Sophos dokumentuje dla tego obejścia maksymalnie 24 godziny, czyli nie więcej niż 86400 sekund.
6. W sekcji Phase 2 sprawdź, czy znajdująca się tam wartość Key life pozostaje mniejsza od wartości fazy 1.
7. W sekcji Dead peer detection użyj ustawienia dostępnego dla Remote Access: wyłączonego lub When peer unreachable: Disconnect.
8. Zapisz profil.
9. W Remote access VPN > IPsec wybierz nowy IPsec profile i zapisz konfigurację.
10. Udostępnij zaktualizowaną konfigurację Sophos Connect i najpierw przetestuj ją z użytkownikiem pilotażowym.

Po wprowadzeniu zmiany samo zapisanie konfiguracji firewalla nie wystarczy. W przypadku ręcznie dystrybuowanych plików .scx należy w Remote access VPN > IPsec użyć Export connection, aby wyeksportować aktualny plik i ponownie zaimportować go na klientach. Jeśli używany jest już plik provisioningowy .pro z Sophos Connect 2.1 lub nowszym, klient automatycznie pobiera późniejsze zmiany konfiguracji z VPN Portal. Adres bramy i port VPN Portal nie mogą zostać w międzyczasie zmienione.

Informacje o działaniu i wersjach klienta znajdziesz w artykule Sprawdzenie wersji klienta Sophos Connect i bezpieczna aktualizacja. Dla instalacji w systemie Windows odpowiedni jest artykuł Instalacja klienta Sophos Connect w systemie Windows, a dla macOS Instalacja klienta Sophos Connect w systemie macOS.

Ustal odpowiedni czas życia

Nie istnieje wiarygodny wzór pozwalający na bezpośrednie wyliczenie pojedynczej wartości ikekeylife na podstawie żądanej częstotliwości odpytywania o OTP. Key life oznacza maksymalny czas życia SA; rekeying rozpoczyna się już w okresie Re-key margin i może być dodatkowo randomizowany.

Przykładowo 43200 sekund odpowiada dwunastu godzinom Key life. W zależności od Re-key margin i randomizacji ponowna negocjacja rozpocznie się wcześniej. Dlatego tej wartości nie należy opisywać jako gwarantowanej dwunastogodzinnej sesji użytkownika. Sophos podaje 24 godziny jako górną granicę dla tego obejścia.

Przed wprowadzeniem zmiany należy ustalić:

• Jaki maksymalny czas życia klucza IKE i jaki interwał rekeyingu są akceptowalne z punktu widzenia bezpieczeństwa?
• Czy wartość odpowiada godzinom pracy, pracy zmianowej i procesowi helpdesku?
• Czy używane jest OTP, RADIUS-MFA, Entra ID SSO czy inna metoda uwierzytelniania?
• Czy istnieją wymagania zgodności dotyczące ponownego uwierzytelniania?
• Czy rekeying lub ponowne połączenie działa niezawodnie z aktualnym klientem Sophos Connect?

Podstawy MFA na firewallu opisano w artykule Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access. Jeśli używane jest Microsoft Entra ID SSO, należy uwzględnić również Konfigurację Microsoft Entra ID SSO dla Sophos Connect i VPN Portal.

Dlaczego bezpośrednia zmiana bazy danych nie jest zalecana

Starsze runbooki zawierają czasem bezpośrednie zmiany w Advanced Shell lub polecenia SQL wykonywane na bazie danych firewalla. Nie jest to zalecane w normalnej eksploatacji.

Powody:

• Taka ingerencja omija standardową walidację WebAdmin.
• Nieprawidłowe wartości mogą zakłócić działanie profili VPN lub Remote Access.
• Zmiany są trudniejsze do prześledzenia.
• W przypadku wsparcia prawidłowo wykonana zmiana przez GUI jest łatwiejsza do wyjaśnienia.
• Po aktualizacjach zachowanie wewnętrznych mechanizmów może się zmienić.

Dlatego wartość należy ustawić w WebAdmin za pomocą własnego profilu IPsec. Bezpośrednie zmiany bazy danych mogą być wykonywane co najwyżej w jasno określonym kontekście wsparcia Sophos, a nie w ramach zwykłej instrukcji administracyjnej.

Przetestuj zmianę w oknie rekeyingu

Po dostosowaniu należy przeprowadzić niewielki test z użytkownikami pilotażowymi.

Punkty kontrolne:

1. Nowy profil jest wybrany w Remote Access IPsec.
2. Nowy plik .scx został zaimportowany lub provisioning .pro pobrał zmianę.
3. Połączenie zostaje pomyślnie zestawione.
4. Cele wewnętrzne są dostępne.
5. DNS, routing i reguły firewalla działają.
6. Połączenie pozostaje aktywne do oczekiwanego okna rekeyingu.
7. Podczas rekeyingu nie występuje nieplanowane przerwanie ani niejasna pętla OTP.
8. Logi VPN pokazują oczekiwaną ponowną negocjację bez nowych błędów.

Jeśli połączenie zostaje zestawione, ale nie przepływa ruch, problem dotyczy raczej tras, reguł firewalla, NAT lub DNS. W takim przypadku pomocny jest artykuł Testowanie reguły firewalla za pomocą Log Viewer, Policy Test i Packet Capture.

Typowe błędy

Typowe pułapki:

• Bezpośrednio zmieniono profil domyślny: może to nieumyślnie wpłynąć na inne scenariusze Remote Access. Lepszym rozwiązaniem jest sklonowany profil, który zostanie przypisany celowo.
• Nie zaktualizowano profilu klienta: przy ręcznej dystrybucji .scx użytkownicy nadal korzystają ze starych ustawień. Przy działającym provisioningu .pro późniejsze zmiany są natomiast pobierane automatycznie.
• Zbyt długa wartość Key life: mniej ponownych uwierzytelnień oznacza dłuższy czas życia IKE-SA. Wymagania dotyczące bezpieczeństwa i eksploatacji należy ocenić łącznie.
• Ponownie zainstalowano tylko klienta: profil firewalla pozostaje niezmieniony. Profil firewalla i konfigurację klienta trzeba sprawdzić razem.
• Użyto invalid SPI jako jedynego dowodu: komunikat może być również skutkiem zastąpienia SA. Czas trwania połączenia, rekeying IKE i żądanie OTP muszą się pokrywać w czasie.
• Bezpośrednio zmieniono bazę danych: zwiększa to ryzyko problemów ze wsparciem i konfiguracją. W normalnej eksploatacji należy używać profilu GUI.

Operacyjna lista kontrolna

• Zarejestruj użytkowników, których dotyczy problem, oraz momenty jego wystąpienia.
• Sprawdź, czy używany jest IPsec Remote Access z Sophos Connect.
• Sprawdź logi VPN pod kątem wskazówek dotyczących IKE, SPI i rekeyingu.
• Zidentyfikuj używany profil IPsec.
• Sklonuj DefaultRemoteAccess zamiast zmieniać go bezpośrednio.
• Zarejestruj wartości fazy 1 dla Key life, Re-key margin i randomizacji.
• Merytorycznie ustal wartość docelową wynoszącą maksymalnie 24 godziny.
• Przypisz nowy profil do Remote Access IPsec.
• Ponownie rozprowadź konfigurację klienta.
• Przeprowadź test z użytkownikiem pilotażowym i poinformuj helpdesk.
• Po kilku dniach sprawdź, czy zmniejszyła się liczba przypadków ponownego łączenia z OTP.

FAQ