Rozwiązywanie problemów z IPsec VPN na Sophos Firewall

Sieci VPN IPsec Site-to-Site zazwyczaj nie wymagają uwagi, dopóki działają. Jeśli jednak tunel nie nawiązuje połączenia, po ponownym połączeniu działa niestabilnie albo ma status połączonego, ale nie przesyła ruchu, analizę należy prowadzić w określonej kolejności. W przeciwnym razie łatwo przechodzić między PSK, trasami, regułami zapory i logami, nie znajdując właściwej przyczyny.

W tym artykule pokazano, jak systematycznie sprawdzać połączenia IPsec na Sophos Firewall: najpierw zestawianie tunelu, następnie wynegocjowane sieci, a na końcu rzeczywisty przepływ pakietów. Jeśli nowy tunel między lokalizacjami dopiero jest planowany lub konfigurowany, warto zacząć od artykułu Konfiguracja połączenia Site-to-Site IPsec VPN na Sophos Firewall. Podstawowe informacje o wierszu poleceń opisano także w artykule Rozwiązywanie problemów z Sophos Firewall za pomocą CLI: najważniejsze polecenia.

Przed rozpoczęciem diagnostyki

Najpierw należy krótko udokumentować stan wyjściowy. Pozornie jest to oczywiste, ale oszczędza dużo czasu, ponieważ wiele problemów z IPsec wynika z niesymetrycznych założeń: jedna strona uważa, że łączy sieć A z siecią B, natomiast druga oczekuje innych identyfikatorów, podsieci lub wersji IKE.

Należy zanotować:

• Nazwa tunelu: na przykład azure-vpn
• Lokalna brama: adres WAN lub FQDN Sophos Firewall
• Zdalna brama: publiczny adres IP lub FQDN drugiej strony
• Wersja IKE: IKEv1 lub IKEv2
• Uwierzytelnianie: Preshared Key lub certyfikat
• Local ID / Remote ID: adres IP, FQDN albo identyfikator przypominający adres e-mail
• Sieci lokalne: na przykład 172.16.10.0/24
• Sieci zdalne: na przykład 10.20.30.0/24
• Typ VPN: policy-based lub route-based
• Gateway type: Initiate the connection, Respond only albo grupa failover
• Profil IPsec: faza 1, faza 2, grupy DH, PFS i czasy życia
• Oczekiwany ruch: źródło, cel, port i kierunek

W przypadku policy-based IPsec sieci lokalne i zdalne są częścią negocjacji tunelu. W przypadku route-based IPsec istotne jest również to, które trasy wskazują interfejs tunelowy. Jeśli mimo aktywnego tunelu ruch jest kierowany niewłaściwą drogą, przyczyną często są trasy IPsec, trasy statyczne, SD-WAN Policy Routes lub Route Precedence na Sophos Firewall.

Jeśli tunel jest aktywny i małe testy działają, ale większe transfery zatrzymują się, należy dodatkowo sprawdzić MTU i MSS. Procedurę opisano w artykule Sprawdzanie MTU i MSS przy problemach z VPN na Sophos Firewall.

⚠️ Logi debugowania i Packet Capture mogą zawierać dane wrażliwe, takie jak publiczne adresy IP, sieci wewnętrzne, nazwy hostów lub dane użytkowe. Należy je zbierać wyłącznie w konkretnym celu i przez ograniczony czas, a przed przekazaniem dokładnie sprawdzić.

Ścieżka diagnostyczna

W praktyce sprawdza się następująca kolejność:

1. Czy tunel się zestawia? Jeśli nie, najpierw sprawdzić wersję IKE, profil IPsec, identyfikatory, PSK lub certyfikat, NAT-T oraz dostępność drugiej strony.
2. Czy zostaje zestawiona faza 2? Jeśli nie, sprawdzić Traffic Selectors, sieci lokalne i zdalne, PFS oraz propozycje fazy 2.
3. Czy zainstalowano Security Association? Jeśli tak, sprawdzić ipsec statusall i obserwować liczniki bajtów.
4. Czy ruch przechodzi przez tunel? Jeśli nie, sprawdzić reguły zapory, NAT, routing, Route Precedence, trasy IPsec i drogę powrotną.
5. Czy pakiety są widoczne? Jeśli nie jest to jasne, połączyć Log Viewer z Packet Capture.

Częsty błąd polega na uznaniu zielonego statusu tunelu za dowód poprawnego działania połączenia. Taki status potwierdza jedynie, że IPsec został zasadniczo wynegocjowany. Nie dowodzi, że reguły zapory i trasy są prawidłowe ani że druga strona zna drogę powrotną.

Przed przejściem do Advanced Shell warto sprawdzić listy w WebAdmin:

• W sekcji Site-to-site VPN > IPsec opcja Show additional properties wyświetla dodatkowe kolumny, takie jak Local subnet, Remote subnet, Gateway type i Profile.
• W sekcji Profiles > IPsec profiles również można wyświetlić dodatkowe właściwości, aby szybciej porównać parametry fazy 1 i fazy 2.

Nie zapewnia to tak szczegółowych informacji jak logi, ale pozwala uniknąć prostych błędów: niewłaściwego profilu lub Gateway type, użycia tych samych podsieci w kilku tunelach albo braku tunelu w oczekiwanej grupie failover.

Którego etapu dotyczy problem?

Przed włączeniem logów debugowania należy wstępnie sklasyfikować problem. Dzięki temu szybciej wiadomo, czy szukać przyczyny w IKE, fazie 2, routingu czy przepływie pakietów.

• Tunel pozostaje w stanie down: problem prawdopodobnie dotyczy IKE, bramy, identyfikatorów, PSK, certyfikatu lub propozycji. Sprawdzić na żywo strongswan.log i porównać parametry fazy 1.
• Tunel stale przechodzi między stanem up i down: skoncentrować się na rekey, DPD, stabilności WAN lub propozycji. Porównać znaczniki czasu, DPD, czas życia i zdarzenia WAN.
• Faza 1 działa, ale brakuje Child SA: skoncentrować się na Traffic Selectors, propozycji fazy 2 lub PFS. Porównać symetrycznie sieci lokalne i zdalne.
• Tunel jest zielony, ale liczniki bajtów pozostają puste: ruch prawdopodobnie nie dociera do tunelu. Sprawdzić regułę zapory, NAT, trasę i bramę klienta.
• Rosną wyłącznie liczniki bajtów wychodzących: brakuje drogi powrotnej albo odpowiedzi drugiej strony. Sprawdzić zdalną zaporę, zdalną trasę i system docelowy.
• Packet Capture pokazuje pakiety bez pasującej reguły: nie zgadza się kolejność reguł, strefa lub usługa. Porównać Log Viewer, Policy Test i Rule ID.

Taka klasyfikacja nie zastępuje dokładnej analizy. Zapobiega jednak szukaniu błędu fazy 2 w regułach zapory albo niepotrzebnemu ustawianiu nowego Preshared Key przy problemie z drogą powrotną.

Zbieranie logów

Sophos Firewall korzysta ze StrongSwan do obsługi IPsec. Najważniejsze logi znajdują się w katalogu /log:

• strongswan.log: najważniejszy log IPsec dotyczący IKE, uwierzytelniania i Child SA.
• charon.log: log demona IKE, przydatny zależnie od wersji i sytuacji.
• strongswan-monitor.log: monitorowanie usługi IPsec.
• dgd.log: Dead Gateway Detection i failover VPN.

Należy połączyć się przez SSH, otworzyć Advanced Shell i w razie potrzeby przejść do katalogu logów:

cd /log

Log można obserwować na żywo:

tail -f /log/strongswan.log

Jeśli aktywnych jest kilka tuneli, wyniki należy filtrować według nazwy tunelu, adresu IP partnera lub typowego komunikatu o błędzie:

tail -f /log/strongswan.log | grep -i azure-vpn

Do przeglądania istniejących logów często wygodniejszy jest less:

less /log/strongswan.log

W programie less można wyszukiwać w pliku za pomocą /szukany_tekst. Alternatywnie wyniki można filtrować bezpośrednio przez grep:

grep -i "no proposal" /log/strongswan.log

Włączanie debugowania StrongSwan

Jeśli standardowy log nie zawiera wystarczających informacji, usługę StrongSwan można przełączyć w tryb debugowania:

service strongswan:debug -ds nosync

Następnie należy sprawdzić, czy usługa działa w trybie debugowania:

service -S | grep strongswan

Przy strongswan powinien być widoczny stan RUNNING,DEBUG. Następnie należy ponownie połączyć tunel lub celowo odtworzyć problem i obserwować log:

tail -f /log/strongswan.log

To samo polecenie debugowania ponownie wyłącza ten tryb:

service strongswan:debug -ds nosync

⚠️ Debugowanie należy pozostawić włączone tylko tak długo, jak jest rzeczywiście potrzebne. Debugowanie IPsec może bardzo szybko tworzyć duże pliki logów i niepotrzebnie zajmować miejsce na zaporze.

Faza 1: IKE, identyfikatory i uwierzytelnianie

Jeśli tunel w ogóle się nie zestawia, przyczyna najczęściej występuje przed fazą 1 lub w jej trakcie. Bramy nie negocjują jeszcze sieci przesyłających dane użytkowe, lecz IKE, uwierzytelnianie i tożsamości obu stron.

Typowe przyczyny:

• niezgodne wersje IKE
• niezgodny profil IPsec lub propozycja
• inny niż oczekiwany Local ID lub Remote ID
• błędny Preshared Key
• druga strona łączy się z niewłaściwym publicznym adresem IP
• nieprawidłowe NAT-T lub przekierowanie portów UDP 500 i 4500
• niezgodne certyfikaty, urząd CA albo okres ważności przy uwierzytelnianiu opartym na certyfikatach

No IKE config found

Wpis w logu, taki jak no IKE config found lub NO_PROPOSAL_CHOSEN, często oznacza, że Sophos Firewall nie znajduje konfiguracji IKE pasującej do przychodzącego pakietu. Przyczyną może być wersja IKE, brama, identyfikatory albo profil IPsec.

Należy sprawdzić:

• Czy obie strony używają tej samej wersji IKEv1 lub IKEv2?
• Czy druga strona odpowiada skonfigurowanemu adresowi Remote Gateway lub nazwie FQDN?
• Czy Local ID i Remote ID są prawidłowe?
• Czy Encryption, Authentication, DH Group i Lifetime są zgodne?
• Czy druga strona używa innego publicznego adresu IP niż udokumentowany?

Peer authentication failed

Komunikaty peer authentication failed, AUTH_FAILED lub no matching peer config found często wskazują na niezgodne identyfikatory lub dane uwierzytelniające. W przypadku Preshared Key zwykle najpierw podejrzewa się klucz. Często słusznie, ale nie zawsze. Jeśli identyfikator jest nieprawidłowy, zapora może nawet nie sprawdzić oczekiwanej konfiguracji partnera.

Należy sprawdzić:

• Local ID jednej strony odpowiada Remote ID drugiej strony.
• Remote ID jednej strony odpowiada Local ID drugiej strony.
• Pisownia, wielkość liter, nazwy FQDN i adresy IP są dokładnie zgodne.
• Preshared Key wprowadzono bez spacji na początku i końcu.
• Jeśli istnieje kilka tuneli do tej samej lokalizacji, konfiguracja jednoznacznie wskazuje, które połączenie ma zostać dopasowane.

Invalid HASH_V1 payload lub decryption failed

W przypadku IKEv1 komunikaty takie jak invalid HASH_V1 payload length lub decryption failed często wskazują na niewłaściwy Preshared Key. W IKEv2 częściej pojawia się AUTHENTICATION_FAILED lub AUTH_FAILED.

W praktyce Preshared Key należy ustawić ponownie po obu stronach zamiast porównywać go tylko wzrokowo. Kopiowanie z menedżera haseł, niewidoczne spacje i różnie interpretowane znaki specjalne to częste źródła niepotrzebnie długiej diagnostyki.

Faza 2: Traffic Selectors i Security Associations

Jeśli faza 1 zakończy się powodzeniem, ale faza 2 nie zostanie zestawiona, problem najczęściej dotyczy sieci i Child SA. Sophos Firewall musi uzgodnić z drugą stroną, które podsieci lokalne i zdalne mogą komunikować się przez tunel.

Typowe wpisy w logu:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi i TSr pokazują inne sieci niż oczekiwane

Należy sprawdzić:

• Sieci lokalne i zdalne są skonfigurowane symetrycznie po obu stronach.
• Maska sieci i poszczególne obiekty hostów są dokładnie zgodne.
• Nie występują niezamierzone nakładania z innymi tunelami.
• Kilka sieci fazy 2 jest odwzorowanych identycznie po obu stronach.
• PFS, ESP Encryption, Authentication i Lifetime są zgodne.

Przykład: jeśli Sophos Firewall oczekuje lokalnie 172.16.10.0/24, a zdalnie 10.20.30.0/24, druga strona musi oferować dokładnie odwrotną relację: 10.20.30.0/24 do 172.16.10.0/24. Sieć /24 po jednej stronie i pojedynczy host lub większa sieć po drugiej mogą już wystarczyć, aby Child SA nie została zainstalowana.

Tunel jest aktywny, ale ruch nie przechodzi

Jeśli tunel jest wyświetlany jako połączony, ale nie przesyła ruchu, przyczyna nie musi leżeć w samym IPsec. Najczęściej problem dotyczy routingu, reguł zapory, NAT albo drogi powrotnej.

Najpierw należy sprawdzić stan IPsec w Advanced Shell:

ipsec statusall

Najważniejsze pytania:

• Czy IKE SA ma stan ESTABLISHED?
• Czy Child SA ma stan INSTALLED?
• Jakie sieci lokalne i zdalne są wyświetlane?
• Czy liczniki bajtów rosną w obu kierunkach?
• Czy widać tylko bajty wychodzące, ale nie przychodzące?
• Czy połączenie jest regularnie odnawiane lub ponownie zestawiane przez rekey?

W przypadku route-based IPsec można dodatkowo sprawdzić, czy stan i polityka XFRM są zainstalowane:

ip xfrm state
ip xfrm policy

Jeśli ipsec statusall pokazuje zestawioną SA, ale ip xfrm state lub ip xfrm policy nie pasują do oczekiwanego tunelu, problem zwykle nie dotyczy już PSK ani propozycji, lecz Traffic Selectors, konfiguracji XFRM, tras lub konkurujących tuneli.

Jeśli Child SA jest zainstalowana, ale liczniki bajtów pozostają puste, oczekiwany ruch prawdopodobnie nie dociera do tunelu. Wtedy należy sprawdzić ścieżkę przed i za IPsec.

Reguły zapory

Ruch przez tunel wymaga odpowiednich reguł zapory. W zależności od modelu stref może to być na przykład LAN do VPN, VPN do LAN albo osobna strefa. Reguła musi prawidłowo obejmować źródło, cel, usługę i kierunek.

Ważne:

• W odpowiednich regułach włączyć Log firewall traffic.
• Sprawdzić pozycję reguły, aby wcześniej nie została zastosowana bardziej ogólna reguła.
• Wybrać prawidłowe strefy źródłową i docelową.
• Przy kilku sieciach VPN unikać zbyt szerokich obiektów, jeśli mogłyby wskazywać niewłaściwy tunel.
• Świadomie sprawdzić funkcje zabezpieczeń, takie jak IPS, web filtering i Application Control, jeśli są aktywne dla tego ruchu.

Ogólną procedurę opisano w artykule Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Routing i trasy IPsec

Jeśli zapora nie wysyła ruchu do tunelu, należy sprawdzić trasy. W przypadku policy-based IPsec istotna może być również tablica routingu IPsec:

ip route show table 220

Jeśli potrzebne jest ręczne przypisanie, może pomóc trasa IPsec na Sophos Firewall. Jeśli konkuruje ze sobą kilka metod routingu, należy także sprawdzić priorytet routingu na Sophos Firewall.

Należy sprawdzić:

• Czy bardziej szczegółowa trasa statyczna przechwytuje ruch?
• Czy SD-WAN Policy Route jest stosowana przed trasą VPN?
• Czy brama klienta rzeczywiście wskazuje Sophos Firewall?
• Czy druga strona ma trasę powrotną do sieci lokalnej?
• Czy sieci lokalne i zdalne nakładają się na siebie?

W przypadku route-based VPN należy również sprawdzić interfejsy XFRM. Dwa interfejsy XFRM nie mogą korzystać z nakładających się ani identycznych sieci interfejsowych. Jeśli xfrm1 i xfrm2 znajdują się w tej samej sieci tranzytowej, tunel może być prawidłowo zestawiony, a mimo to ruch będzie niewłaściwie kierowany. W takim przypadku należy sprawdzić adresację XFRM w sekcji Network > Interfaces i zastosować unikatowe sieci.

Jeśli kilka połączeń IPsec używa tych samych podsieci lokalnych i zdalnych, nie powinny działać niezależnie bez jednoznacznego projektu. Takie połączenia powinny należeć do świadomie zaprojektowanej grupy failover albo korzystać z odmiennej logiki selektorów i routingu. W przeciwnym razie zapora nie będzie w przewidywalny sposób używać właściwego tunelu.

NAT

NAT nie jest z zasady błędny przy IPsec, ale musi być skonfigurowany świadomie. Niezamierzone MASQ lub zbyt szeroka reguła SNAT może sprawić, że druga strona nie przypisze ruchu do oczekiwanej sieci.

Należy sprawdzić:

• Czy ogólna reguła MASQ jest stosowana przed konkretną regułą VPN NAT?
• Czy druga strona oczekuje oryginalnych czy przetłumaczonych adresów IP?
• Czy NAT jest udokumentowany po obu stronach?
• Czy reguła NAT odpowiada kierunkowi ruchu?

Jeśli używany jest NAT, pomocny będzie artykuł NAT na Sophos Firewall: SNAT, DNAT, MASQ i PAT.

SFOS 22: świadome sprawdzanie policy-based IPsec i NAT

Po aktualizacji do SFOS 22 policy-based IPsec wymaga szczególnie starannej kontroli. W informacjach o wydaniu SFOS 22 Sophos wskazuje zmianę zachowania policy-based IPsec VPN. Wśród rozwiązanych problemów udokumentowano również NC-170917: ruch policy-based IPsec mógł nie działać, jeśli domyślna reguła SNAT korzystała ze statycznego adresu IP zamiast MASQ.

W praktyce oznacza to, że jeśli po aktualizacji tunel policy-based jest zielony, ale ruch nie przechodzi lub działa tylko w jednym kierunku, NAT nie można traktować jako pobocznej kwestii. Stara, szeroka albo nietypowo zmodyfikowana domyślna reguła SNAT może zmieniać dokładnie ten ruch, którego druga strona oczekuje z oryginalnych sieci.

Typowe punkty kontroli po aktualizacji do SFOS 22:

• Czy tunel rzeczywiście jest typu policy-based? W takim tunelu sieci lokalne i zdalne są częścią negocjacji. NAT może naruszyć to założenie.
• Czy zmodyfikowano domyślną regułę SNAT? Statyczny adres SNAT zamiast MASQ może po aktualizacji działać inaczej niż oczekiwano.
• Czy istnieją konkretne reguły VPN NAT? Muszą znajdować się powyżej ogólnych reguł SNAT lub MASQ i odpowiadać kierunkowi ruchu.
• Czy Traffic Selectors i obiekty NAT są zgodne? Druga strona musi oczekiwać albo sieci oryginalnych, albo przetłumaczonych, a nie przypadkowo obu wariantów.
• Czy Packet Capture pokazuje oczekiwany źródłowy adres IP? Pozwala to ustalić, czy przed wysłaniem do tunelu zapora używa innego adresu źródłowego.

Precyzyjny przypadek testowy składa się z jednego źródła, jednego celu i jednej usługi. Następnie należy kolejno sprawdzić regułę zapory, regułę NAT, ipsec statusall, ip route show table 220, Packet Capture i drugą stronę. Jeśli test działa tylko po wyłączeniu lub przesunięciu reguły NAT, problem nie dotyczy zestawiania tunelu, lecz ścieżki prowadzącej do tunelu.

W planowaniu aktualizacji pomoże również artykuł Sprawdzanie Sophos Firewall przed aktualizacją do SFOS 22. Podstawy NAT i kolejności reguł opisano dokładniej w artykule NAT na Sophos Firewall.

Rekey, failover i stan interfejsu

Jeśli tunel początkowo działa, a później przestaje, konfiguracja początkowa nie zawsze jest błędna. Należy wtedy przeanalizować przebieg zdarzeń w czasie:

• Traffic-based rekeying u innych producentów: Sophos Firewall oczekuje mechanizmu rekey opartego na czasie. Jeśli druga strona wymusza rekey na podstawie ruchu, tunel może po pewnym czasie się zawiesić lub rozpocząć ponowne negocjacje.
• Key exchange collisions: jeśli obie strony wykonują rekey jednocześnie, mogą pojawić się okresy niestabilności. W takiej sytuacji czasy życia fazy 1 i fazy 2 należy celowo skoordynować między inicjatorem a responderem.
• Wyłączony interfejs: po wyłączeniu powiązanego interfejsu inicjowany tunel Site-to-Site zostaje natychmiast rozłączony. W połączeniach typu Responder i Remote Access utrata łączności staje się widoczna najpóźniej po okresie bezczynności lub przekroczeniu limitu DPD.
• DGD i grupa failover: w scenariuszach failover należy dodatkowo sprawdzić dgd.log, stan bramy, połączenie podstawowe i zapasowe oraz identyczne pary podsieci.

Takie błędy łatwiej rozpoznać na osi czasu niż na pojedynczym zrzucie stanu. Dlatego przy problemach okresowych należy zestawić czasowo status tunelu, wpisy w strongswan.log i dgd.log, zdarzenia WAN oraz test aplikacji.

SFOS 22: PPPoE-WAN z interfejsem aliasowym i IPsec Acceleration

Na liście Known Issues Sophos opisuje NC-181526: na określonych fizycznych urządzeniach XGS z SFOS 22.0 GA Build 411 lub MR1 Build 490 tunel IPsec może zostać zestawiony przez interfejs aliasowy portu PPPoE-WAN, ale przy aktywnej funkcji IPsec acceleration nie przekazuje ruchu użytkowego. Problem nie dotyczy modeli XGS 88/88w, 108/108w, 118/118w i 128/128w.

Ten przypadek należy sprawdzać dopiero po wykluczeniu typowych przyczyn. Zielony tunel bez ruchu zwykle nadal oznacza problem z regułą, routingiem, NAT albo drogą powrotną. Specjalny przypadek SFOS 22 staje się bardziej prawdopodobny, jeśli jednocześnie są spełnione wszystkie poniższe warunki:

• Sophos Firewall działa z SFOS 22.0 GA Build 411 lub MR1 Build 490.
• Jest to fizyczne urządzenie XGS objęte problemem, a nie jeden z wyłączonych modeli.
• Tunel korzysta z interfejsu aliasowego portu PPPoE-WAN.
• Tunel się zestawia, ale nie przesyła ruchu użytkowego.
• Reguły zapory, NAT, trasy, droga powrotna i Packet Capture nie wyjaśniają zachowania.
• IPsec acceleration jest aktywna.

⚠️ Obejście zmienia ustawienie globalne i może wpłynąć na inne tunele IPsec. Należy udokumentować bieżący stan, wykonać zmianę w oknie serwisowym i testować ją wyłącznie wtedy, gdy wzorzec błędu jest dokładnie zgodny z opisem.

Lista Known Issues firmy Sophos podaje parametr off. Bieżąca dokumentacja CLI dla SFOS 22 opisuje w tym miejscu parametr disable, dlatego niniejsza instrukcja korzysta z aktualnej składni oraz sprawdza stan przed zmianą i po niej:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

Jeśli test nie przyniesie poprawy albo zmianę trzeba wycofać:

system ipsec-acceleration enable

Na liście Known Issues Sophos wskazuje SFOS 22.0.2 MR2 Build 546 jako wersję rozwiązującą NC-181526. MR2 jest już wydane, dlatego planowana aktualizacja stanowi trwałe rozwiązanie. W opublikowanej liście poprawek MR2 identyfikator tego problemu nie jest wymieniony osobno; przypisanie poprawki opiera się więc wyraźnie na liście Known Issues.

Praktyczna procedura kontrolna:

1. Udokumentować status tunelu i wynik ipsec statusall.
2. Wykonać Packet Capture z precyzyjnym filtrem Source i Destination.
3. Sprawdzić, czy tunel rzeczywiście korzysta z interfejsu aliasowego portu PPPoE-WAN.
4. Potwierdzić SFOS 22.0 GA Build 411 lub MR1 Build 490 oraz model sprzętowy objęty problemem.
5. Udokumentować stan za pomocą system ipsec-acceleration show i testować zmianę wyłącznie w sposób ukierunkowany.
6. Następnie porównać stan, liczniki bajtów, Packet Capture, Log Viewer i test aplikacji.
7. Jeśli nie ma poprawy, przywrócić stan początkowy poleceniem system ipsec-acceleration enable.

Łączenie Log Viewer i Packet Capture

Log Viewer pokazuje, która reguła lub który moduł ocenił połączenie. Packet Capture w WebAdmin pokazuje natomiast, czy pakiety rzeczywiście docierają, są przekazywane, odrzucane albo przetwarzane przez samą zaporę.

Podczas diagnostyki IPsec należy zdefiniować możliwie precyzyjny test:

• Source IP: 172.16.10.25
• Destination IP: 10.20.30.15
• Service: ICMP lub TCP 443
• Oczekiwany kierunek: LAN do VPN
• Oczekiwana reguła: LAN_to_VPN_Branch

Następnie:

1. Włączyć logging w regule zapory.
2. W Log Viewer ustawić filtr Source IP, Destination IP i moduł Firewall.
3. Uruchomić Packet Capture z precyzyjnym filtrem, na przykład host 172.16.10.25 and host 10.20.30.15.
4. Odtworzyć test dokładnie jeden raz.
5. Sprawdzić, czy pakiety docierają, są przekazywane i czy wracają odpowiedzi.

Interpretacja:

• Żaden pakiet nie dociera do Sophos Firewall: sprawdzić klienta, bramę, VLAN, przełącznik lub routing lokalny.
• Pakiet dociera, ale nie jest przekazywany: sprawdzić regułę zapory, NAT, trasę lub funkcję zabezpieczeń.
• Pakiet jest wysyłany do tunelu, ale nie wraca odpowiedź: sprawdzić trasę powrotną, drugą stronę, zdalną zaporę lub zdalny host.
• Tylko bajty wychodzące w ipsec statusall: sprawdzić drogę powrotną lub zdalną politykę.
• Tylko bajty przychodzące: sprawdzić trasę lokalną, lokalną regułę zapory lub system docelowy.

Przy dłuższych przechwyceniach lub zgłoszeniach do pomocy technicznej warto zebrać odpowiednie logi. Artykuł Zabezpieczanie logów Sophos Firewall na potrzeby wsparcia i analizy opisuje prawidłowy eksport.

Typowe wzorce błędów

Poniższe wzorce odnoszą się do surowych komunikatów StrongSwan/Charon z pliku strongswan.log. W WebAdmin te same przyczyny często pojawiają się jako przetłumaczone komunikaty, na przykład no IKE config found jako „Remote peer is refusing our Phase 1 proposals”, peer authentication failed jako „Remote peer reports we failed to authenticate”, a traffic selectors ... inacceptable jako „Remote peer reports INVALID_ID_INFORMATION”. Dzięki temu przypisaniu można znaleźć właściwy przypadek nawet wtedy, gdy diagnostyka rozpoczyna się w WebAdmin, a nie w surowym logu.

• no IKE config found: nie zgadza się wersja IKE, brama, identyfikator lub profil. Porównać wersję IKE, Local ID, Remote ID i propozycje.
• NO_PROPOSAL_CHOSEN: niezgodne propozycje. Sprawdzić Encryption, Authentication, DH Group, PFS i Lifetime.
• peer authentication failed: niezgodny identyfikator lub sposób uwierzytelniania. Sprawdzić Local ID, Remote ID oraz PSK lub certyfikat.
• AUTH_FAILED: niezgodny Preshared Key, certyfikat lub identyfikator. Ustawić PSK ponownie oraz sprawdzić łańcuch certyfikatów i identyfikatory.
• traffic selectors ... inacceptable: sieci lokalne i zdalne nie są zgodne. Porównać symetrycznie podsieci i obiekty hostów.
• failed to establish CHILD_SA: niezgodne sieci fazy 2 lub propozycje ESP. Sprawdzić Traffic Selectors, PFS, profil ESP i czasy życia.
• Tunel jest zielony, ale brak bajtów: ruch nie dociera do tunelu. Sprawdzić regułę zapory, trasę, NAT i bramę klienta.
• Bajty wychodzące rosną, przychodzące nie: brakuje odpowiedzi drugiej strony lub drogi powrotnej. Sprawdzić zdalne reguły, zdalną trasę i system docelowy.
• ipsec statusall pokazuje SA, ale ruch route-based zatrzymuje się później: sprawdzić stan XFRM, politykę XFRM, nakładające się sieci XFRM, grupę failover i zachowanie rekey.
• Kilka tuneli korzysta z tych samych podsieci: tunele powinny należeć do grupy failover albo otrzymać jednoznacznie odmienną logikę selektorów i routingu.
• Duże transfery zatrzymują się mimo aktywnego tunelu: skoncentrować się na MTU/MSS, utracie pakietów lub Path MTU Discovery. Zobacz Sprawdzanie MTU i MSS przy problemach z VPN.
• SFOS 22, policy-based IPsec, zielony tunel, brak ruchu: po aktualizacji NAT, domyślna reguła SNAT lub Traffic Selectors nie są prawidłowo zgodne. Sprawdzić domyślny SNAT, reguły VPN NAT, MASQ, Packet Capture i drugą stronę.
• SFOS 22.0 GA Build 411 lub MR1 Build 490, alias PPPoE-WAN, zielony tunel, brak ruchu: możliwy Known Issue NC-181526 na objętych problemem fizycznych urządzeniach XGS. Potwierdzić model i typ interfejsu; dopiero potem sprawdzić stan i celowo przetestować system ipsec-acceleration disable.
• Ponowne połączenia lub częste rekey: skoncentrować się na Lifetime, DPD, niestabilnym łączu lub propozycjach. Sprawdzić czasy rekey, DPD, stabilność WAN i logi.

Praktyczna lista kontrolna

Sprawdzić od razu:

• Zanotować status tunelu i ostatni komunikat o błędzie w WebAdmin.
• Uruchomić tail -f /log/strongswan.log i ponownie połączyć tunel.
• Sprawdzić wersję IKE, Local ID, Remote ID i Preshared Key.
• Porównać symetrycznie Traffic Selectors oraz sieci lokalne i zdalne.
• W wyniku ipsec statusall sprawdzić ESTABLISHED, INSTALLED i liczniki bajtów.

Jeśli tunel jest aktywny:

• Sprawdzić reguły zapory w obu kierunkach.
• Włączyć logging w odpowiednich regułach.
• Filtrować Log Viewer według Source, Destination i Rule ID.
• Uruchomić Packet Capture z precyzyjnym filtrem.
• Sprawdzić reguły NAT i Route Precedence.
• Przy route-based VPN sprawdzić ip xfrm state, ip xfrm policy oraz sieci interfejsów XFRM.
• Przy kilku podobnych tunelach wyświetlić kolumny grupy failover oraz Local subnet i Remote subnet.
• W SFOS 22 z policy-based IPsec sprawdzić domyślną regułę SNAT, konkretne reguły VPN NAT i oczekiwany Source IP.
• W SFOS 22.0 GA Build 411 lub MR1 Build 490 z aliasem PPPoE-WAN sprawdzić, czy model sprzętu i wzorzec błędu dokładnie odpowiadają NC-181526.
• Potwierdzić trasę powrotną po drugiej stronie.

Na potrzeby wsparcia lub dłuższej analizy:

• Włączyć debugowanie tylko na krótko, a następnie ponownie je wyłączyć.
• Zabezpieczyć odpowiednie logi.
• Udokumentować czas, nazwę tunelu, adres IP partnera, Source, Destination i przebieg testu.
• Przed przekazaniem sprawdzić dane wrażliwe.

FAQ