Konfiguracja VPN IPsec Site-to-Site Sophos Firewall

VPN IPsec Site-to-Site łączy dwie lokalizacje albo Sophos Firewall z firewallem innego dostawcy przez szyfrowany tunel. W praktyce taki tunel rzadko przestaje działać z powodu jednego ustawienia w interfejsie. Częściej przyczyną są niejasne sieci, różne profile IPsec, brakujące reguły firewall, szczególne przypadki NAT albo zapomniana ścieżka powrotna po jednej stronie.

Skrócony przebieg: wybrać typ tunelu, uzgodnić profil i identyfikatory, utworzyć połączenie, dla route-based Any-to-Any skonfigurować routing interfejsu XFRM, ustawić reguły firewall i NAT, a następnie odebrać tunel przy użyciu rzeczywistego ruchu, logów i Packet Capture.

Procedura pasuje do połączeń Sophos-to-Sophos oraz z rozwiązaniami innych dostawców między centralą, oddziałem lub cloud gateway. Dla Microsoft Azure i AWS obowiązują dodatkowe szczegóły dostawcy: łączenie Sophos Firewall z Azure VPN Gateway oraz łączenie Sophos Firewall z AWS Site-to-Site VPN. Dla Remote Access pojedynczych użytkowników właściwy jest wybór między Sophos Connect i SSL VPN. Jeśli istniejący tunel jest już zielony, ale ruch nie przepływa, należy skorzystać z Sophos Firewall IPsec VPN Troubleshooting.

Jeśli łączone są wyłącznie dwie Sophos Firewall, a oddział ma zestawiać tunel jako klient do centrali dostępnej pod stałym adresem, prostszą alternatywą jest SSL Site-to-Site VPN. W przypadku innych producentów, redundancji, routingu dynamicznego lub rosnących sieci route-based IPsec pozostaje bardziej elastycznym wyborem.

Dla wielu firewalli zarządzanych przez Sophos Central grupa połączeń SD-WAN może automatycznie generować tunele oparte na trasach, interfejsy XFRM, trasy i opcjonalne reguły. Nie zastępuje to planowania topologii ani lokalnej weryfikacji ruchu.

Wybór policy-based lub route-based

Przed konfiguracją trzeba zdecydować, czy tunel będzie zbudowany jako policy-based, czy route-based. W aktualnych wersjach SFOS terminy te są rozdzielone wyraźniej niż w starszych instrukcjach, które częściowo nadal mówią o Site-to-Site lub Tunnel Interface.

• IPsec policy-based: pasuje do prostych połączeń między lokalizacjami z jasnymi sieciami lokalnymi i zdalnymi. Sterowanie odbywa się głównie przez lokalne i zdalne podsieci w połączeniu IPsec oraz reguły firewall. Sophos tworzy osobne tunele Phase 2 dla kombinacji podsieci lokalnych i zdalnych.
• IPsec route-based z Traffic Selectors: również używa podsieci lokalnych i zdalnych, ale tworzy własny interfejs XFRM. Sophos generuje trasę automatycznie; interfejsowi XFRM nie wolno przypisywać ani adresu IP, ani własnych tras. WAF nie jest obsługiwany w tym wariancie.
• IPsec route-based Any-to-Any: to najbardziej elastyczny wariant dla rosnących sieci, SD-WAN, routingu dynamicznego i projektów dual-stack. O tym, które pakiety trafiają do tunelu, decydują wtedy trasy i reguły firewall, a nie podsieci w połączeniu IPsec.

Sophos zaleca VPN route-based dla nowych projektów. Any-to-Any jest szczególnie elastyczny w rosnących sieciach, ponieważ zmiany tras nie rozłączają tunelu. Zmiany podsieci lub Traffic Selectors przerywają natomiast istniejące połączenia. Oba końce tunelu muszą używać tego samego typu: policy-based po jednej stronie i route-based po drugiej nie jest obsługiwane.

Dla OSPF lub BGP przez tunel przejrzystym rozwiązaniem jest route-based Any-to-Any z zaadresowanymi interfejsami XFRM. Przed aktualizacją starszego projektu policy-based należy sprawdzić, czy sieci VPN są rozgłaszane przez redistribute kernel; artykuł SFOS 22: trasy IPsec i redistribute kernel wyjaśnia zmianę wersji i bezpieczne ramy migracji.

Wymagania i dane planistyczne

Przed konfiguracją należy udokumentować co najmniej te dane:

• Lokalny endpoint: interfejs WAN Sophos Firewall oraz adres, pod którym strona zdalna osiąga ten interfejs.
• Remote Gateway: publiczny adres IP lub hostname DNS strony zdalnej.
• Gateway type: w centrali najczęściej Respond only, w oddziale najczęściej Initiate the connection.
• IP version: IPv4, IPv6 lub Dual. Dual jest dostępny tylko dla interfejsów tunelowych route-based z Any-to-Any jako lokalne i zdalne podsieci. Przy Dual reguły firewall IPv4 i IPv6 trzeba planować oddzielnie.
• Sieci lokalne: na przykład 172.16.10.0/24 i 172.16.20.0/24.
• Sieci zdalne: na przykład 10.20.30.0/24.
• Typ VPN: policy-based lub route-based. Connection type Host-to-host również istnieje, ale nie jest zakresem tej instrukcji połączeń między lokalizacjami.
• Listening interface: interfejs WAN lokalnego firewalla. Nie można do tego użyć bridge interface.
• Wersja IKE: preferowana IKEv2, jeśli strona zdalna ją obsługuje.
• Authentication type: Preshared key, Digital certificate lub RSA key.
• Local ID i Remote ID: szczególnie ważne przy FQDN, dynamicznych stronach zdalnych, NAT-T lub Wildcard Gateway.
• Profil IPsec: Encryption, Authentication, DH Group, PFS i Key life.
• Reguły firewall: dozwolone źródła, cele i usługi.
• NAT: bez NAT albo SNAT/DNAT z powodu nakładających się sieci lub wymagań dostawcy.
• Eksploatacja: owner, okno serwisowe, plan testów, monitoring i ścieżka awaryjna.

⚠️ VPN Site-to-Site nie powinien być wdrażany bez udokumentowanej ścieżki powrotnej. Jeśli lokalny firewall wysyła ruch do tunelu, ale strona zdalna nie zna trasy powrotnej albo inaczej oczekuje NAT, tunel często wygląda zdrowo, mimo że aplikacje nie działają.

Sieci, profil, identyfikatory i certyfikaty

Sieci lokalne i zdalne nie mogą przypadkowo się nakładać. Szczególnie problematyczne są częste sieci domyślne, takie jak 192.168.0.0/24, 192.168.1.0/24 albo wielokrotnie używane sieci oddziałów. Jeśli sieci się nakładają, potrzebny jest świadomy projekt NAT. Użycie tego samego zakresu adresów po obu stronach i późniejsze przetłumaczenie go “w jakiś sposób” tworzy tunele trudne w utrzymaniu.

Dla nowych lokalizacji warto więc przygotować spójną koncepcję adresacji IP. Jeśli VLAN lub strefy nie są jeszcze poprawnie zamodelowane, pomaga konfiguracja stref i interfejsów w Sophos Firewall.

Obie strony muszą używać zgodnych parametrów w Phase 1 i Phase 2. Należą do nich szyfrowanie, uwierzytelnianie, DH Group, PFS i czas życia. Przy połączeniach z firewallami innych dostawców najłatwiej często najpierw uzgodnić wspólny profil na piśmie, a dopiero potem skonfigurować obie strony.

W IKEv2 Sophos może używać unikalnych Preshared Key dla każdej kombinacji Local ID i Remote ID. W IKEv1 jest to bardziej ograniczone, ponieważ dla każdej kombinacji gateway obowiązuje tylko jeden PSK. W środowiskach z wieloma tunelami do tej samej strony zdalnej należy więc preferować IKEv2 z jednoznacznymi identyfikatorami.

NAT Traversal jest na Sophos Firewall zawsze aktywny. Jeśli jedna strona znajduje się za routerem lub NAT-em dostawcy, identyfikatory stają się ważniejsze, ponieważ publiczny adres gateway nie opisuje jednoznacznie peer. Local ID jednej strony musi odpowiadać Remote ID oczekiwanemu przez stronę zdalną. Identyfikatory DNS, IP lub e-mail nie muszą być publicznie rozwiązywalne, ale ich format i wartość muszą pasować krzyżowo.

Przy Digital certificate formaty i role certyfikatów po obu stronach muszą dokładnie do siebie pasować. Sophos nie obsługuje certyfikatów ECDSA dla połączeń IPsec; wymagane są certyfikaty RSA. Publicznego CA nie należy używać ogólnie jako Remote CA Certificate, ponieważ spowodowałoby to zbyt szerokie zaufanie do obcych certyfikatów. RSA key jest osobnym Authentication type: oba firewalle wymieniają klucze publiczne i muszą używać tego samego formatu PKCS1 lub DNS.

Zmiana lokalnego CA Default na Sophos Firewall jest zmianą trust anchor, a nie kosmetyczną edycją certyfikatu. Peery z zaimportowanym Default.pem i lokalnie podpisane certyfikaty muszą zostać zmigrowane w sposób kontrolowany. Kontrolowane odnawianie Default CA na Sophos Firewall opisuje inwentaryzację, okno serwisowe, testy i odzyskiwanie.

Jeśli urząd certyfikacji unieważnia certyfikaty przed końcem ich ważności, aktualna lista unieważnień również musi znaleźć się w planie operacyjnym. Oddzielna procedura opisuje import CRL, nextUpdate i kontrolowany test negatywny na Sophos Firewall.

Jeśli tunel się nie zestawia, typowymi wskazówkami są NO_PROPOSAL_CHOSEN, błędy identyfikatorów lub uwierzytelniania. Sekcja Testowanie tunelu i rozwiązywanie problemów zaczyna się od odpowiedniego zawężenia przyczyny.

Konfiguracja IPsec policy-based

IPsec policy-based to klasyczny wariant dla prostych połączeń Site-to-Site. Sieci lokalne i zdalne są definiowane bezpośrednio w połączeniu IPsec.

1. Sprawdzenie lub utworzenie profilu IPsec

Ścieżka menu:

Profiles > IPsec profiles

Najpierw sprawdzić, czy istniejący profil pasuje do strony zdalnej. Jeśli potrzebny jest własny profil, powinien mieć jednoznaczną nazwę, na przykład IPsec_IKEv2_AES256_G14. Nazwa musi pozostać zrozumiała, gdy istnieje wiele tuneli i stron zdalnych.

Udokumentować co najmniej:

• Wersja IKE
• Phase 1 Encryption i Authentication
• DH Group
• Phase 2 Encryption i Authentication
• PFS
• Key life

Przy firewallach innych dostawców strona zdalna powinna potwierdzić te same wartości na piśmie. Sam zrzut ekranu często nie wystarcza, ponieważ poszczególne pola mogą mieć inne nazwy zależnie od producenta.

Zależności między Phase 1, Phase 2, PFS, lifetimes, rekeyingiem i DPD wyjaśnia artykuł Zrozumienie i bezpieczna konfiguracja profili IPsec Sophos Firewall.

2. Dodanie połączenia IPsec

Ścieżka menu:

Site-to-site VPN > IPsec

Utworzyć nowe połączenie IPsec i wybrać Policy-based jako Connection type. Następnie ustawić dane podstawowe:

• Nazwa tunelu, na przykład branch-zurich
• IP version, zwykle IPv4
• Gateway type, na przykład Respond only w centrali lub Initiate the connection w oddziale
• Listening interface jako lokalny interfejs WAN
• Gateway address strony zdalnej jako adres IP lub hostname DNS
• Authentication type: Preshared key, Digital certificate lub RSA key
• Local ID i Remote ID, jeśli potrzebne
• IPsec profile
• Local subnet
• Remote subnet

Przy IPsec policy-based najwyżej jedna strona Traffic Selectors może mieć wartość Any. Przy wielu konkretnych sieciach lokalnych i zdalnych Sophos tworzy Phase 2 SA dla każdej kombinacji.

Przy Respond only adres wildcard * może być przydatny, gdy wiele oddziałów lub dynamicznych stron zdalnych łączy się z centralą. Wtedy trzeba ustawić co najmniej Local ID lub Remote ID; dla jednoznacznego przypisania zwykle warto użyć obu. Local ID jednej strony odpowiada Remote ID oczekiwanemu przez drugą. Initiate the connection nie obsługuje adresu wildcard, dlatego stronę zdalną definiuje się jako adres IP lub hostname DNS.

Dla Preshared Key należy użyć silnego, unikalnego klucza i bezpiecznie go udokumentować. Stary standardowy klucz współdzielony przez wiele lokalizacji stanowi niepotrzebne ryzyko operacyjne.

Zaawansowane ustawienia User authentication mode dotyczą tylko profili IKEv1 z logiką XAuth, na przykład bardzo starych projektów client-server. W normalnych połączeniach Site-to-Site z IKEv2 nie należy traktować tego jako dodatkowego kroku uwierzytelniania. Przestarzałych ustawień Idle Connection również nie należy planować jako nowoczesnego modelu eksploatacji.

3. Aktywacja tunelu

Podczas zapisu można ustawić Activate on save. W środowiskach produkcyjnych powinno to nastąpić w zdefiniowanym oknie serwisowym, gdy strona zdalna jest osiągalna i obie strony mogą sprawdzać logi.

Po zapisaniu lista pokazuje dwa istotne stany:

• czy połączenie jest aktywne
• czy tunel faktycznie jest established

Aktywny wpis nie oznacza automatycznie zestawionego tunelu. Przy wielu sieciach lokalnych lub zdalnych może też istnieć wiele Security Associations.

Konfiguracja IPsec route-based

IPsec route-based rozdziela negocjację VPN i ścieżkę danych przez własny interfejs XFRM. To, czy interfejs otrzymuje adres i własny routing, zależy od wybranego wariantu.

1. Utworzenie połączenia jako route-based

Ścieżka menu:

Site-to-site VPN > IPsec

W połączeniu wybrać Route-based (Tunnel interface). Parametry gateway, uwierzytelniania, identyfikatorów i profilu IPsec nadal muszą pasować do strony zdalnej. Dodatkowo trzeba rozumieć, jaki interfejs XFRM powstanie i jak będzie routowany.

2. Implementacja Any-to-Any lub Traffic Selectors

Sophos pokazuje utworzony interfejs XFRM pod używanym interfejsem fizycznym w:

Network > Interfaces

Interfejs XFRM zawsze pozostaje przypisany do strefy VPN. Oba warianty konfiguruje się inaczej.

Any-to-Any i Dual

Jeśli obie podsieci mają wartość Any albo używane jest Dual, interfejs XFRM otrzymuje adres transferowy IP. Następnie potrzebna jest trasa statyczna, SD-WAN Route lub trasa dynamiczna przez BGP albo OSPF. Przy Dual wymagane są oddzielne reguły firewall IPv4 i IPv6.

Trasy i reguły firewall decydują, jaki ruch trafia do tunelu. Prosta trasa statyczna może wskazywać bezpośrednio interfejs XFRM. Przy wielu łączach, kontrolach SLA lub określonych projektach failover tworzy się dodatkowo Custom Gateway z adresem IP XFRM strony zdalnej i wykorzystuje go w SD-WAN Route.

Tunele Any-to-Any mogą sterować wieloma gatewayami XFRM bezpośrednio przez SD-WAN i kontrole SLA; nie wymagają do tego dodatkowej grupy VPN failover. Natomiast tunele policy-based i route-based z Traffic Selectors używają grupy failover IPsec do obsługi połączeń redundantnych. Podlinkowany proces wyjaśnia kolejność, Health Check, Automatic failback i kontrolowany test awarii. Grupa wyłącza DPD dla przypisanych połączeń i ustawia Key negotiation tries na 3.

Po zapisaniu sprawdzić trzy punkty:

1. Interfejs XFRM jest widoczny w Network > Interfaces i ma zaplanowany adres transferowy IP.
2. Trasa do sieci zdalnej wskazuje bezpośrednio interfejs XFRM albo, w projekcie z gatewayem lub SD-WAN, właściwy gateway XFRM.
3. Reguły firewall zezwalają tylko na zaplanowane kierunki i usługi.

Traffic Selectors

Przy konkretnych Local subnet i Remote subnet Sophos również tworzy interfejs XFRM, ale nie wolno przypisywać mu ani adresu IP, ani własnych tras. Trasa statyczna powstaje automatycznie, gdy tunel ma status established. Any tylko po jednej stronie i konkretny Selector po drugiej nie są obsługiwane.

Ten wariant nadaje się do małych, jasno zdefiniowanych sieci i ułatwia diagnostykę XFRM. WAF przez IPsec route-based z Traffic Selectors nie jest jednak obsługiwany.

Tunelu Any-to-Any nie można bezpośrednio zmienić na konkretne Traffic Selectors. Połączenie trzeba sklonować lub utworzyć ponownie, a następnie przełączyć w kontrolowany sposób.

3. Uwzględnienie XFRM i MTU

VPN route-based są bardziej podatne na nieporozumienia związane z routingiem, MTU i MSS. Jeśli małe testy działają, ale większe transfery się zawieszają, nie należy od razu zmieniać profilu IPsec. Najpierw sprawdzić MTU, MSS, fragmentację i rzeczywistą ścieżkę. Odpowiednią procedurę opisuje sprawdzenie MTU i MSS w Sophos Firewall przy problemach VPN.

Reguły firewall, NAT i Device Access

Reguły firewall i reguły automatyczne

Po konfiguracji IPsec potrzebne są reguły dla ruchu produkcyjnego. Bez odpowiednich reguł tunel może być zielony, ale aplikacje nie będą działać.

Ścieżka menu:

Rules and policies > Firewall rules

Typowe reguły:

• Sieć lokalna do sieci zdalnej: na przykład LAN do VPN.
• Sieć zdalna do lokalnej sieci serwerowej: na przykład VPN do Server.
• Management lub Monitoring: zezwalać tylko zdefiniowanym systemom administracyjnym lub monitorującym.
• DNS, AD, RDP, HTTPS: udostępniać tylko potrzebne usługi, nie ogólne Any.

Interfejsy XFRM zawsze należą do strefy VPN. Jeśli używane są oba kierunki, potrzebne są odpowiednie reguły inbound i outbound. Oddzielne reguły z loggingiem wyraźniej pokazują podczas odbioru, która strona może osiągać konkretne usługi. Ogólną konfigurację opisuje tworzenie i bezpieczne sprawdzanie reguł Sophos Firewall.

Opcja Create firewall rule tworzy osobne reguły z prefiksami Incoming i Outgoing na początku listy reguł. Następnie:

• Sprawdzić pozycję reguł.
• Zawęzić Source i Destination.
• Ograniczyć Any do wymaganych Services.
• Włączyć Log firewall traffic na czas wdrożenia i analizy błędów.
• Świadomie wybrać IPS, Web, Application Control i inne Security Features.
• Nadać regule zrozumiałą nazwę, na przykład LAN_to_Branch_Zurich.

⚠️ Automatycznie utworzone reguły firewall są punktem startowym, a nie gotowym projektem bezpieczeństwa. Szczególnie przy tunelach między lokalizacjami do sieci serwerowych po pierwszym teście należy ograniczyć usługi, źródła i cele.

Dla route-based Any-to-Any Sophos nie może automatycznie tworzyć reguł. Przy Dual reguły IPv4 i IPv6 są tworzone oddzielnie. Jeśli ruch internetowy oddziału ma przechodzić przez centralę, potrzebny jest dodatkowo własny projekt NAT i bezpieczeństwa.

Planowanie NAT według typu tunelu

NAT nie jest zabroniony przy IPsec, ale musi być jasno uzasadniony. Typowe przypadki to nakładające się sieci, wymagania chmury lub strony trzecie akceptujące tylko określone adresy źródłowe.

Ścieżka menu:

Rules and policies > NAT rules

Przed regułą NAT należy odpowiedzieć na te pytania:

• Czy strona zdalna oczekuje oryginalnych, czy przetłumaczonych adresów IP?
• Czy istnieją nakładające się sieci?
• Czy NAT jest konfigurowany w połączeniu IPsec, czy przez osobne reguły NAT?
• Czy kierunek powrotny jest udokumentowany?
• Czy po NAT Log Viewer pokazuje oczekiwane Source i Destination?

Logika NAT różni się zależnie od typu VPN:

• Przy IPsec policy-based i VPN route-based z Traffic Selectors NAT dla nakładających się sieci można skonfigurować bezpośrednio w połączeniu IPsec.
• Przy route-based Any-to-Any reguły SNAT i DNAT są używane w Rules and policies > NAT rules.
• Przy nakładających się sieciach obie strony muszą rozumieć ten sam plan translacji. Jednostronny NAT bez planowania powrotu często tworzy zielone tunele bez użytecznego ruchu.

⚠️ Przy IPsec route-based z Traffic Selectors interfejs XFRM nie ma adresu IP. Jeśli ten ruch dopasuje się do reguły MASQ-SNAT, firewall odrzuci pakiety. Dlatego dla nakładających się sieci należy użyć ustawienia NAT w połączeniu IPsec i upewnić się, że żadna reguła MASQ-SNAT nie obejmuje tego ruchu.

Od SFOS 22 IPsec policy-based tworzy trasę VPN w backendzie. Ręczna ipsec_route ma znaczenie tylko dla określonego przetłumaczonego, przekazywanego ruchu i nie jest standardowym krokiem; ruch generowany przez system jej nie wymaga. Więcej podstaw NAT opisuje zrozumienie reguł NAT Sophos Firewall.

Device Access dla przychodzącego IPsec

Dla przychodzących żądań IPsec firewall musi móc przyjmować ruch IPsec w odpowiedniej strefie WAN. Nie realizuje się tego zwykłą regułą LAN-do-WAN, lecz przez lokalne usługi firewalla.

Ścieżka menu:

Administration > Device access

IPsec musi być dozwolony dla WAN, jeśli firewall przyjmuje żądania przychodzące, na przykład z Respond only. Nie zastępuje to reguł dla ruchu użytkowego przez tunel. Jednocześnie należy sprawdzić, czy WebAdmin, SSH, User Portal lub VPN Portal nie są niepotrzebnie szeroko dostępne. Centralnym artykułem dotyczącym zabezpieczania tych lokalnych usług jest zabezpieczenie dostępu do Sophos Firewall: poprawna konfiguracja Device Access.

Testowanie tunelu i rozwiązywanie problemów

Dobry test odbiorczy sprawdza nie tylko zielony status, ale rzeczywisty przepływ danych.

Definiowanie macierzy odbioru

Przed pierwszym testem należy przygotować małą macierz odbioru. Dzięki temu wiadomo, które połączenia naprawdę muszą działać, a które celowo nie powinny być dozwolone.

Przydatne przypadki testowe:

• Lokalna sieć klientów do zdalnej sieci serwerów: typowy test aplikacyjny, na przykład HTTPS, RDP, SMB, SQL albo ICMP tylko jako test podstawowy.
• Zdalna sieć klientów do lokalnej sieci serwerów: sprawdzić kierunek przeciwny, jeśli połączenie jest używane dwukierunkowo.
• DNS lub AD przez tunel: testować tylko wtedy, gdy te usługi naprawdę mają działać przez tunel. Dokładnie określić Source, serwer docelowy i port.
• Monitoring lub backup: sprawdzić, czy zaplanowane systemy łączą się z właściwego kierunku i nie wymagają przypadkowo reguł Any.
• Test niedozwolony: celowo niedozwolony port lub sieć powinny być blokowane. W przeciwnym razie baza reguł jest zbyt szeroka.
• Duży transfer: przy transferze plików, RDP, VoIP lub problemach aplikacyjnych dodatkowo obserwować MTU/MSS i fragmentację.

Dla każdego przypadku testowego zanotować Source IP, Destination IP, Service, oczekiwaną regułę firewall, oczekiwaną regułę NAT i oczekiwany kierunek. Po każdym teście porównać Log Viewer, Packet Capture i liczniki bajtów. Jeśli testowany jest tylko ping, tunel nie został jeszcze odebrany.

1. Sprawdzenie statusu

W interfejsie WebAdmin:

Site-to-site VPN > IPsec

Sprawdzić:

• Połączenie jest aktywne.
• Status tunelu jest established.
• Przy wielu sieciach wszystkie oczekiwane Child SA są zestawione.

2. Sprawdzenie Log Viewer

Ścieżka menu:

Log viewer

Wygenerować ruch testowy z jasnym Source, Destination i Service. Następnie w Log Viewer sprawdzić, która reguła firewall pasuje i czy NAT, Webfilter, IPS lub inne moduły wpływają na ruch. Procedurę opisuje testowanie reguły firewall za pomocą Log Viewer, Policy Test i Packet Capture. Powtarzające się rekey, rozłączenia i błędy połączeń należy sprawdzać w logach IPsec, a nie wyprowadzać z bieżącego statusu SA.

3. Packet Capture i Advanced Shell

Jeśli Log Viewer nie wystarcza, należy użyć Packet Capture z wąskim filtrem:

Diagnostics > Packet capture

Przykład filtra:

host 172.16.10.25 and host 10.20.30.15

Przy VPN troubleshooting ważne jest sprawdzenie obu kierunków. Tylko wychodzące pakiety bez odpowiedzi wskazują najczęściej na problem ścieżki powrotnej, NAT lub strony zdalnej.

Advanced Shell

Do głębszej analizy przez SSH otworzyć 5. Device Management > 3. Advanced Shell i sprawdzić bieżący status SA:

ipsec statusall

Istotne są między innymi:

• IKE SA established
• Child SA installed
• lokalne i zdalne Traffic Selectors
• liczniki bajtów w obu kierunkach

Jeśli SSH nie jest jeszcze przygotowany, pomaga połączenie z Sophos Firewall przez SSH.

Aktualne logi IPsec

Aktualny przegląd logów SFOS 22 rozdziela zadania:

• strongswan.log: usługa IPsec i połączenia.
• charon.log: usługa IPsec oraz NAT w połączeniach IPsec.
• ipsec_monitor.log: monitoring usługi IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log: aktywacja, dezaktywacja i łączenie przez WebAdmin.
• xfrmi.log: interfejsy XFRM przy IPsec route-based.
• dgd.log: tylko dodatkowo przy VPN failover, SD-WAN, DGD lub Link Load Balancing, nie jako ogólny log IPsec.

Pełną diagnostykę logów i XFRM opisuje Sophos Firewall IPsec VPN Troubleshooting.

Typowe błędy

• Tunel się nie zestawia: prawdopodobnie nie pasuje wersja IKE, profil, PSK, certyfikat, Local ID lub Remote ID. Sprawdzić strongswan.log, profil IPsec i stronę zdalną.
• Phase 1 działa, Phase 2 nie: prawdopodobnie nie pasują sieci lokalne lub zdalne albo Phase 2 proposal. Sprawdzić Traffic Selectors, podsieci i PFS.
• Tunel jest zielony, ale brak dostępu: prawdopodobnie brakuje reguły firewall, NAT, routingu lub ścieżki powrotnej. Sprawdzić Log Viewer, Packet Capture i routing.
• Działa tylko jeden kierunek: strona zdalna nie zna trasy powrotnej albo NAT jest błędny. Sprawdzić stronę zdalną, reguły NAT i liczniki bajtów.
• Małe pingi działają, aplikacje wiszą: prawdopodobnie uczestniczą MTU/MSS, fragmentacja lub Security Feature. Sprawdzić MTU/MSS i Packet Capture.
• Route-based Any-to-Any nie działa: prawdopodobnie nie pasuje IP XFRM, gateway, trasa lub reguła firewall. Sprawdzić Network > Interfaces, routing i reguły strefy VPN.
• Route-based z Traffic Selectors nie działa: nie konfigurować adresu IP ani ręcznej trasy na XFRM. Sprawdzić trasę automatyczną, Selectors, reguły strefy VPN i ewentualną regułę MASQ.
• Kilka tuneli wpływa na siebie: prawdopodobnie istnieją nakładające się sieci lub podobne konfiguracje Selector. Sprawdzić obiekty tuneli, Failover Group i trasy.

Lista kontrolna

Przed zmianą:

• Sieci lokalne i zdalne są jednoznaczne.
• Policy-based lub route-based wybrano świadomie.
• Profil IPsec jest uzgodniony ze stroną zdalną.
• Preshared Key, certyfikaty lub klucze RSA są bezpiecznie udokumentowane.
• Reguły firewall są zaplanowane, wraz z kierunkiem, pozycją, loggingiem i usługami.
• Przy Create firewall rule wiadomo, które automatycznie utworzone reguły trzeba poprawić.
• Dla route-based Any-to-Any zaplanowano adres IP XFRM, gateway, ręczne reguły firewall i trasy.
• Dla route-based Traffic Selectors nie zaplanowano adresu IP ani ręcznych tras na XFRM.
• NAT jest wykluczony albo świadomie udokumentowany.
• Device Access dla przychodzącego IPsec został sprawdzony.
• Okno serwisowe, strona zdalna i ścieżka awaryjna są znane.

Po zmianie:

• Status tunelu jest established.
• Zdefiniowano macierz odbioru z co najmniej jednym testem dla każdego wymaganego kierunku.
• Log Viewer pokazuje oczekiwaną regułę firewall.
• Packet Capture pokazuje kierunek wychodzący i powrotny.
• Przetestowano wewnętrzne DNS i dostęp do aplikacji.
• Liczniki bajtów rosną w obu kierunkach.
• NAT i ścieżka powrotna są uzgodnione ze stroną zdalną.
• Zmiana została ujęta w dokumentacji sieciowej.

Częste pytania