Konfiguracja Sophos Connect na Sophos Firewall

Sophos Connect jest w wielu środowiskach standardowym klientem dla Remote Access z Sophos Firewall. Rzeczywista jakość rozwiązania nie zależy jednak dopiero od Windows czy macOS, lecz od firewall: uprawnienia użytkowników, pula IP, DNS, uwierzytelnianie, MFA, reguły firewall i późniejsza dystrybucja profili muszą do siebie pasować.

Ten artykuł opisuje planowanie i konfigurację po stronie firewall dla Sophos Connect, przede wszystkim dla IPsec Remote Access oraz dystrybucji profili. Dla SSL VPN właściwa Remote Access policy jest opisana w artykule Konfiguracja Sophos Firewall SSL VPN Remote Access. Przy podstawowym wyborze między IPsec, SSL VPN, klientami mobilnymi i ZTNA warto najpierw przeczytać Sophos Connect czy SSL VPN: które rozwiązanie Remote Access pasuje?.

Który artykuł pasuje?

W zależności od zadania sensowny jest inny punkt startowy:

• Planowanie Sophos Connect po stronie firewall dla IPsec: Ten artykuł
• Konfiguracja SSL VPN Remote Access na firewall: Konfiguracja Sophos Firewall SSL VPN Remote Access
• Użycie Microsoft Entra ID SSO dla Sophos Connect: Konfiguracja Microsoft Entra ID SSO dla Sophos Connect i VPN Portal
• Instalacja Sophos Connect na Windows lub macOS: Windows albo macOS
• Kontrola wersji klienta i zmian profilu w eksploatacji: Sprawdzenie i bezpieczna aktualizacja wersji Sophos Connect Client
• Analiza problemów z połączeniem w tunelu: Troubleshooting Sophos Firewall IPsec VPN

To rozdzielenie jest ważne, ponieważ Sophos Connect dotyka wielu obszarów: konfiguracji IPsec, konfiguracji SSL VPN, VPN Portal, provisioningu, uwierzytelniania, wersji klienta i reguł firewall.

Wymagania

• Sophos Firewall z obsługiwaną wersją SFOS
• dostęp administratora do interfejsu WebAdmin
• zdefiniowani użytkownicy lub grupy dla Remote Access
• wolny zakres adresów IP dla klientów VPN
• wewnętrzne serwery DNS, jeśli trzeba rozwiązywać nazwy wewnętrzne
• koncepcja MFA dla Remote Access
• ustalone sieci docelowe i usługi, które mają być dostępne przez VPN
• jasna procedura dystrybucji profili, zmian profili i aktualizacji klientów

Jeśli firewall ma zostać zaktualizowany do SFOS 22.0 MR1 lub nowszego, trzeba wcześniej sprawdzić, czy nadal istnieje Legacy Remote Access IPsec. Ta stara konfiguracja może zablokować upgrade. Procedura jest opisana w Migracja Legacy Remote Access IPsec przed SFOS 22 MR1.

W aktualnych wersjach SFOS konfiguracja IPsec Remote Access znajduje się pod Remote access VPN > IPsec. W starszych interfejsach lub starszych instrukcjach można jeszcze znaleźć ścieżki takie jak VPN > Sophos Connect Client. Dlatego na istniejących zrzutach ekranu i w starszych środowiskach klientów nazewnictwo może się różnić.

Planowanie przed konfiguracją

Przed włączeniem warto krótko udokumentować, jak Remote Access będzie później obsługiwany. Zapobiega to typowym błędom, takim jak nakładające się pule IP, zbyt szerokie reguły firewall albo profile, które po zmianie nie zostały ponownie rozesłane.

Ważne pytania planistyczne:

• Użytkownicy: Użytkownicy lokalni, grupa AD, RADIUS lub inne uwierzytelnianie
• MFA: OTP/MFA aktywne, przetestowane i udokumentowane dla procesów helpdesk
• Pula IP: osobna pula bez nakładania się z LAN, WLAN, VLAN, Site-to-Site VPN lub sieciami domowymi
• DNS: wewnętrzne serwery DNS i domeny wyszukiwania, jeśli używane są wewnętrzne FQDN
• Dostęp: udostępniać tylko wymagane serwery, sieci i usługi
• Dystrybucja klienta: .scx, .tgb, .ovpn, .pro, dystrybucja oprogramowania, stan wersji i ścieżka awaryjna
• Eksploatacja: Log Viewer, proces wsparcia, zmiany profili i odejścia użytkowników

Dla podstaw MFA pasuje Konfiguracja Sophos Firewall MFA. Jeśli Remote Access ma później działać przez Microsoft Entra ID SSO, RADIUS lub AD, należy dodatkowo osobno przetestować ścieżkę uwierzytelniania.

Typy profili i dystrybucja

Przed konfiguracją powinno być jasne, który plik trafi później na którego klienta. To zapobiega wielu zgłoszeniom supportowym.

• .scx: Sophos Connect dla IPsec Remote Access zawiera także zaawansowane ustawienia Sophos Connect
• .tgb: konfiguracja IPsec dla starszych lub zewnętrznych klientów nie zawiera zaawansowanych ustawień Sophos Connect
• .ovpn: SSL VPN dla Sophos Connect lub klientów zgodnych z OpenVPN pochodzi z konfiguracji SSL VPN albo VPN Portal
• .pro: plik provisioningu do automatycznego importu ładuje konfiguracje przez VPN Portal po udanym logowaniu

Dla nowych wdrożeń Sophos Connect IPsec .scx jest zwykle lepszym standardem, ponieważ zawiera zaawansowane ustawienia z firewall. .tgb należy używać świadomie tylko wtedy, gdy wymaga tego klient zewnętrzny albo stary proces.

Provisioning może uprościć dystrybucję, ale zwiększa zależność od VPN Portal. Jeśli użytkownicy mają korzystać z pliku provisioningu z Internetu, VPN Portal musi być dostępny z wymaganej strefy. Należy to świadomie utwardzić w Administration > Device access oraz Local Service ACL, ponieważ portal dostępny z WAN tworzy dodatkową powierzchnię ataku. Do utwardzania pasuje Device Access i Local Service ACL na Sophos Firewall.

Aktywacja Sophos Connect

W interfejsie WebAdmin otworzyć Remote access VPN > IPsec. W starszych interfejsach ścieżka może nadal brzmieć VPN > Sophos Connect Client. Dokładny wygląd może się nieco różnić w zależności od wersji SFOS, ale podstawowe decyzje pozostają podobne.

1. Włączyć Connect Client

Włączyć IPsec Remote Access. Dopiero potem ustawić pozostałe opcje i nie wdrażać od razu produkcyjnie.

2. Wybrać zewnętrzny interface

Jako interface zwykle wybiera się interfejs WAN, przez który połączenia Remote Access docierają do firewall. Przy kilku łączach WAN trzeba świadomie zdecydować, które łącze jest stabilne dla VPN, udokumentowane i dostępne z Internetu.

Do sprawdzenia:

• publiczny adres IP albo poprawny DynDNS/FQDN jest dostępny
• przekierowania portów i routery przed firewall pasują
• znane jest zachowanie WAN failover
• Device Access i lokalne ACL usług dopuszczają tylko wymagane usługi
• VPN Portal jest dostępny tylko tam, gdzie rzeczywiście jest potrzebny do pobierania lub provisioningu

Remote Access jest publicznie dostępnym punktem wejścia. Sama funkcjonalność nie wystarcza; dostęp, MFA i logging muszą być uwzględnione.

Do utwardzania dostępnych usług firewall pasuje Device Access i Local Service ACL na Sophos Firewall.

3. Wybrać uwierzytelnianie

Dla IPsec Remote Access dostępne są różne modele uwierzytelniania zależnie od wersji SFOS i konfiguracji. Często istotne są Preshared Key i certyfikat.

Praktyczna klasyfikacja:

• Preshared Key jest szybki do skonfigurowania, ale musi być silny, chroniony i rotowany w razie podejrzenia.
• Certyfikat jest czystszy dla kontrolowanych środowisk, ale wymaga zarządzania certyfikatami i jasnych procesów.
• MFA nie zastępuje ani PSK, ani certyfikatu, lecz dodatkowo chroni logowanie użytkownika.

Jeśli Preshared Key został rozesłany w kilku profilach, jego zmiana jest operacyjnie bardziej złożona. Dlatego klucza nie należy traktować jako wartości jednorazowej.

Przy certyfikatach trzeba dodatkowo sprawdzić, czy typ certyfikatu, ważność, klucze prywatne i klient docelowy pasują do siebie. Dla IPsec Remote Access szczególnie istotne są certyfikaty RSA. Zmiany certyfikatów są zawsze także tematem profilu i rollout.

4. Sprawdzić Local ID i Remote ID

Local ID i Remote ID są opcjonalne, ale mogą być ważne przy wielu tunelach lub specjalnych peerach. Jeśli są ustawione, muszą pasować do używanego profilu i konfiguracji klienta.

Typowe wartości:

• nazwa DNS
• adres IP
• email
• certyfikat

W prostych konfiguracjach pola te często pozostają puste. Jeśli później wystąpią błędy typu no IKE config found albo problemy proposal/ID, ten obszar należy uwzględnić w kontroli. Do głębszej analizy lepszym artykułem kontynuującym jest Troubleshooting Sophos Firewall IPsec VPN.

5. Przypisać użytkowników i grupy

Wybrać tylko tych użytkowników lub grupy, którzy rzeczywiście potrzebują Remote Access. W środowiskach produkcyjnych dedykowana grupa VPN jest zwykle lepsza niż szeroka grupa standardowa.

Do sprawdzenia:

• Grupa zawiera tylko uprawnionych użytkowników.
• Użytkownicy, którzy odeszli, są usuwani.
• MFA jest dla tych użytkowników aktywne i przetestowane.
• Helpdesk wie, jak blokować, odblokowywać lub ponownie provisionować użytkowników.

Guest users nie należą do Remote Access. W środowiskach produkcyjnych dedykowana grupa VPN jest lepsza niż szeroka grupa standardowa z usługi katalogowej.

Konfiguracja danych klienta

6. Nadać nazwy

Nazwa połączenia powinna być zrozumiała dla użytkowników i supportu. Nazwy takie jak homeoffice, remote-access-ipsec albo nazwa lokalizacji są pomocniejsze niż wewnętrzne skróty.

Jeśli rozsyłanych jest kilka profili, nazewnictwo powinno pozostać spójne. Zmniejsza to pomyłki w Sophos Connect Client.

7. Ustalić pulę IP

Firewall przydziela klientom VPN adres z określonej puli. Zakres ten nie może nakładać się z sieciami wewnętrznymi, innymi pulami VPN, sieciami Site-to-Site ani typowymi zakresami domowymi.

Dobra praktyka:

• osobny zakres adresów tylko dla Remote Access
• wystarczający rozmiar dla jednoczesnych użytkowników
• brak nakładania się z 192.168.0.0/24, 192.168.1.0/24 lub częstymi zakresami domowymi, jeśli da się tego uniknąć
• jasna dokumentacja w IPAM albo dokumentacji sieciowej

Jeśli pula zostanie później zmieniona, profile i testy trzeba ponownie sprawdzić.

Dla IPsec Remote Access pula powinna być co najmniej czysto zaplanowana jako osobna podsieć. Dodatkowo nie może nakładać się z innymi pulami Remote Access, takimi jak SSL VPN, L2TP lub PPTP.

8. Wpisać serwery DNS

Jeśli użytkownicy mają docierać do systemów wewnętrznych po nazwie, trzeba rozesłać właściwe serwery DNS i ewentualnie domeny wyszukiwania. W wielu środowiskach jest to wewnętrzny Domain Controller albo dedykowany serwer DNS.

Zewnętrzne resolvery, takie jak Cloudflare, Google, Quad9 czy OpenDNS, nie rozwiązują stref wewnętrznych. Mają sens tylko wtedy, gdy przez tunel VPN nie są potrzebne nazwy wewnętrzne albo DNS celowo rozwiązano inaczej.

Przykłady zewnętrznych resolverów:

• Cloudflare: 1.1.1.1 i 1.0.0.1
• Google: 8.8.8.8 i 8.8.4.4
• Quad9: 9.9.9.9 i 149.112.112.112
• OpenDNS: 208.67.222.222 i 208.67.220.220

Dla produkcyjnego Remote Access zwykle ważniejsze jest, aby wewnętrzne FQDN działały niezawodnie. Jeśli DNS nie jest dobrze zaplanowany, tunel wygląda dla użytkowników na “połączony”, choć aplikacje nie działają.

Sprawdzić ustawienia zaawansowane

9. Ustawić Session Timeout

Session Timeout zapobiega temu, aby nieużywane połączenia VPN pozostawały otwarte bez ograniczeń. Zbyt agresywne wartości mogą jednak tworzyć zgłoszenia supportowe, ponieważ użytkownicy muszą ponownie łączyć się po krótkich przerwach.

Sensowna jest wartość pasująca do modelu pracy:

• krótkie timeouty dla sporadycznych dostępów administracyjnych
• dłuższe timeouty dla stabilnych sesji roboczych
• jasna komunikacja, jeśli użytkownicy po bezczynności muszą połączyć się ponownie

Jeśli używane jest OTP/MFA, należy także przetestować wpływ na reconnects.

Jeśli firewall rozłącza idle client, Sophos Connect Client może odtworzyć połączenie w tle. Jeśli to się nie uda, użytkownik musi świadomie rozłączyć połączenie w kliencie i połączyć ponownie. To zachowanie powinno być znane w procesie helpdesk.

10. Świadomie ustawić Advanced settings

Ustawienia zaawansowane decydują, jak klient zachowuje się na co dzień. Przy IPsec Remote Access są przenoszone do pliku .scx, a nie do pliku .tgb.

Ważne punkty:

• Use as default gateway: Czy cały ruch internetowy ma przechodzić przez firewall, czy tylko zasoby wewnętrzne?
• Permitted network resources: Które sieci wewnętrzne mogą w ogóle być osiągane przez tunel?
• Send Security Heartbeat through tunnel: Czy używane jest Sophos Endpoint/Synchronized Security i czy Heartbeat ma iść przez VPN?
• Allow users to save username and password: Czy zapisane logowanie pasuje do koncepcji MFA i bezpieczeństwa?
• Prompt users for 2FA token: Czy OTP ma pojawiać się jako osobne pole, czy być łączone w polu hasła?
• Run AD logon script after connecting: Czy logon scripts, takie jak mapowanie dysków, są naprawdę potrzebne i przetestowane?
• Connect tunnel automatically: Czy tunel ma być zestawiany automatycznie przy logowaniu użytkownika?

Przy Full Tunnel przez Use as default gateway potrzebna jest dodatkowa reguła firewall z VPN do WAN oraz świadomy projekt NAT/Security Policy. Przy Split Tunnel dozwolone zasoby wewnętrzne muszą być jasno udokumentowane.

Jeśli Prompt users for 2FA token jest aktywne, obsługa jest dla użytkowników często czytelniejsza. Jednocześnie trzeba sprawdzić, czy używane narzędzia lub automatyzacje działają z tym ustawieniem.

11. Zapisać i wyeksportować konfigurację

Po zapisaniu eksportowana jest konfiguracja połączenia. Zależnie od klienta i wersji SFOS istotne mogą być pliki .scx, .tgb albo pliki provisioningu. Plik nie powinien być otwarcie przechowywany ani przekazywany osobom nieuprawnionym.

Po zmianach grupy użytkowników, puli, DNS, profilu, gateway, portu, certyfikatu lub Advanced Settings odpowiedni klienci muszą otrzymać zaktualizowaną konfigurację. Stare profile są częstą przyczyną trudnych do zrozumienia problemów VPN.

Jeśli używany jest provisioning, trzeba dodatkowo sprawdzić, czy klient automatycznie pobiera zmiany, czy użytkownicy muszą zaktualizować policy w Sophos Connect Client albo zalogować się ponownie. Zmiany portu SSL VPN, gateway, certyfikatu serwera lub protokołu to typowe przypadki, w których może być potrzebne ponowne logowanie lub świadomy krok aktualizacji.

Konfiguracja reguł firewall

Sophos Connect tylko zestawia tunel. Dostęp do systemów wewnętrznych nadal jest kontrolowany przez reguły firewall. Bez odpowiednich reguł połączenie może być zielone, ale dostęp produkcyjny nie działa.

Dla dostępu klientów VPN do systemów wewnętrznych typowo tworzy się regułę z VPN do LAN albo do konkretnej strefy docelowej.

• Source Zone: VPN
• Destination Zone: LAN

Lepsza od szerokiego dostępu do całej LAN jest zwykle reguła na rzeczywiście wymagane sieci lub usługi. Logging powinien być włączony w fazie wdrożenia, aby błędy były widoczne w Log Viewer.

Jeśli klient działa jako Full Tunnel i ruch internetowy także ma przechodzić przez firewall, potrzebna jest dodatkowa reguła z VPN do WAN oraz świadomy projekt NAT/Security Policy.

• Source Zone: VPN
• Destination Zone: WAN

Przy wyszukiwaniu błędów w regułach pomocne jest Testowanie reguł firewall z Log Viewer, Policy Test i Packet Capture.

Reguły firewall nie powinny tylko “działać”, lecz być sprawdzalne. W fazie wdrożenia przydatny jest logging na regułach Remote Access. Później można zdecydować, które reguły będą logowane stale i które zdarzenia mają dodatkowo trafiać do Sophos Central lub Syslog.

Testy po wdrożeniu

Zielony status Sophos Connect nie wystarcza jako test odbiorczy. Co najmniej te punkty należy sprawdzić z użytkownikiem testowym:

• Klient importuje konfigurację bez błędów.
• Logowanie działa z hasłem i MFA.
• Klient otrzymuje adres z oczekiwanej puli VPN.
• Wewnętrzne nazwy DNS są poprawnie rozwiązywane.
• Centralne systemy wewnętrzne są osiągalne.
• Log Viewer pokazuje oczekiwaną regułę firewall.
• Split Tunnel albo Full Tunnel zachowuje się zgodnie z planem.
• Reconnect po zmianie sieci działa.
• Stare profile nie zostały użyte ponownie.
• Przy Full Tunnel działa dostęp do Internetu przez firewall zgodnie z planem.
• Przy Split Tunnel niedozwolone cele pozostają zablokowane.
• Log Viewer pokazuje trafienia na oczekiwane reguły.
• Przy provisioningu zmiany profili są aktualizowane w sposób możliwy do prześledzenia.

Następnie można użyć instrukcji instalacji dla Windows i macOS.

Lista kontrolna eksploatacji

Po technicznym wdrożeniu eksploatacja nie powinna pozostać nieokreślona:

• Odpowiedzialna grupa VPN udokumentowana.
• Proces odejścia usuwa użytkowników z grup Remote Access.
• Proces resetu MFA jest znany.
• Wersja profilu lub data zmiany jest dokumentowana.
• Helpdesk wie, które profile są aktualne.
• Log Viewer i odpowiednie logi usług są znane.
• Zmiany puli IP, DNS, gateway, certyfikatu i Advanced Settings wyzwalają kontrolę profilu.
• Przed upgrade SFOS sprawdzane są Legacy Remote Access IPsec i profile klientów.

Troubleshooting

Połączenie zostaje zestawione, ale nie płynie traffic

Przyczyna często nie leży w tunelu, lecz w regułach firewall, NAT, routingu, DNS albo ścieżce powrotnej. Najpierw w Log Viewer sprawdzić, czy traffic ze strefy VPN trafia w oczekiwaną regułę. Następnie zawęzić analizę za pomocą Packet Capture albo Policy Test.

Użytkownik nie może się zalogować

Sprawdzić grupę użytkownika, serwer uwierzytelniania, MFA, zablokowanego użytkownika i status hasła. Jeśli uczestniczy AD, RADIUS lub Microsoft Entra ID SSO, uwierzytelnianie należy przetestować oddzielnie od VPN.

Klient używa starej konfiguracji

Po zmianach puli IP, DNS, grupy użytkowników, profilu, gateway, certyfikatu lub Advanced Settings konfiguracja musi zostać ponownie rozesłana albo zaimportowana. Stare pliki .tgb, .scx, .ovpn lub provisioningowe nie powinny równolegle pozostawać w obiegu.

Provisioning nie działa

Najpierw sprawdzić, czy VPN Portal jest dostępny z wymaganej strefy i czy Device Access ustawiono świadomie. Następnie sprawdzić wartość gateway, port portalu, certyfikat, logowanie użytkownika, MFA oraz przy Entra SSO przypisanie w Authentication > Services.

SSO działa tylko częściowo

Przy Microsoft Entra ID SSO, VPN Portal, IPsec i SSL VPN muszą zależnie od workflow pasować do właściwego serwera Entra ID. Przy provisioningu wartość gateway musi pasować do Redirect URI konfiguracji Entra. Jeśli problem dotyczy tylko pojedynczych użytkowników, dodatkowo sprawdzić UPN, adres email, mapowanie grup i zaimportowane grupy użytkowników.

Połączenie stoi, ale duże transfery się zawieszają

Jeśli login, DNS i małe dostępy działają, ale większe transfery plików lub konkretne aplikacje się zawieszają, należy sprawdzić MTU/MSS. Objaw często pasuje do fragmentacji, PPPoE, tunelowanych połączeń albo asymetrycznej ścieżki. Procedura znajduje się w Sprawdzanie MTU i MSS na Sophos Firewall przy problemach VPN.

IPsec zrywa się w obcych sieciach

IPsec może być blokowany w hotelach, sieciach gościnnych Wi-Fi, sieciach komórkowych lub ściśle filtrowanych sieciach firmowych. W takich przypadkach należy sprawdzić, czy SSL VPN Remote Access, ZTNA albo inny projekt Remote Access nie pasuje lepiej.

Full Tunnel nie ma dostępu do Internetu

Jeśli Use as default gateway jest aktywne, traffic z VPN do WAN musi być dozwolony i odpowiednio obsłużony przez NAT. Dodatkowo Web Protection, Application Control, DNS i logging powinny być świadomie zaplanowane jak w innych sieciach klienckich.

FAQ