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

W diagnostyce IPsec ważna jest kolejność: najpierw należy sprawdzić IKE i Child SA, a następnie reguły zapory, NAT, routing i drogę powrotną. Zielony tunel potwierdza tylko negocjację, a nie działanie ruchu użytkowego.

Przy nowym tunelu należy najpierw skorzystać z instrukcji Konfiguracja połączenia Site-to-Site IPsec VPN na Sophos Firewall. Poniższe kroki dotyczą już skonfigurowanego połączenia.

Ścieżka diagnostyczna

Tunel pozostaje w stanie down: sprawdzić w strongswan.log wersję IKE, profil IPsec, bramę, Local/Remote ID, PSK lub certyfikat.
Faza 1 działa, ale brakuje Child SA: porównać Traffic Selectors, propozycję fazy 2, PFS i podsieci.
Tunel jest zielony: za pomocą ipsec statusall sprawdzić, czy SA ma stan ESTABLISHED, Child SA ma stan INSTALLED, a liczniki bajtów rosną.
Bajty są liczone tylko w jednym kierunku: sprawdzić reguły zapory, NAT, routing, a szczególnie drogę powrotną po drugiej stronie.
Przyczyna pozostaje niejasna: prześledzić pojedynczy przepływ testowy za pomocą Log Viewer i Packet Capture.
Firewall wielokrotnie ulega awarii przy ruchu multicast przez VPN: nie wywoływać problemu kolejnymi testami obciążeniowymi. Zapisać wersję firmware, znaczniki czasu i dostępne dane diagnostyczne; NC-180433 naprawiono w SFOS 22.0 MR2 Build 546.

Wcześniej wystarczy udokumentować kilka wartości: nazwę tunelu, adres IP lub FQDN partnera, wersję IKE, Local/Remote ID, sieci lokalne i zdalne, typ policy-based lub route-based, profil IPsec oraz test ze wskazaniem Source, Destination i Service. Przykład: tunel azure-vpn, sieć lokalna 172.16.10.0/24, sieć zdalna 10.20.30.0/24.

W policy-based IPsec sieci są częścią negocjacji. Route-based IPsec korzysta z interfejsu XFRM oraz tras statycznych, SD-WAN lub dynamicznych. Przy nieprawidłowej ścieżce pomocne są osobne instrukcje dotyczące tras IPsec i Route Precedence.

⚠️ Logi i Packet Capture mogą zawierać 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 sprawdzić.

Sprawdzanie logów i CLI

W sekcji Site-to-site VPN > IPsec opcja Show additional properties wyświetla między innymi Local subnet, Remote subnet, Gateway type i Profile. W sekcji Profiles > IPsec profiles można również bezpośrednio porównać wartości fazy 1 i fazy 2.

Najważniejsze pliki w katalogu /log:

strongswan.log: IKE, uwierzytelnianie i Child SA
charon.log: demon IKE
ipsec_monitor.log: monitorowanie usługi IPsec
/log/ipsec_conn/ipsec_<connectionname>.log: działania Connect, Activate i Deactivate w WebAdmin
xfrmi.log: interfejsy XFRM
dgd.log: Dead Gateway Detection i failover VPN

Aktualna centralna lista logów SFOS 22 podaje ipsec_monitor.log. Starsza strona Sophos dotycząca diagnostyki nadal wskazuje strongswan-monitor.log; w bieżących systemach SFOS 22 obowiązuje nowsza lista logów.

W Advanced Shell można obserwować na żywo lub filtrować główny log. Jeśli dostęp przez SSH i korzystanie z powłoki nie są jeszcze znane, pomocny będzie artykuł Rozwiązywanie problemów z Sophos Firewall za pomocą CLI: najważniejsze polecenia.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Te wiersze są alternatywami, a nie jednym ciągłym przebiegiem. W programie less polecenie /suchbegriff wyszukuje w pliku.

Debugowanie StrongSwan

Jeśli standardowy log nie wystarcza, najpierw należy sprawdzić bieżący stan w Advanced Shell:

service -S | grep strongswan

Jeśli już widoczny jest stan RUNNING,DEBUG, nie należy ponownie wykonywać przełącznika jako rzekomego włączenia debugowania. Należy wykorzystać aktywny tryb debugowania, a następnie wyłączyć go zgodnie z opisem poniżej.

⚠️ Debugowanie należy pozostawić aktywne tylko przez krótki czas. Może szybko tworzyć duże pliki logów i zajmować miejsce.

Jeśli debugowanie nie jest jeszcze aktywne, należy wykonać przełącznik, sprawdzić nowy stan i odtworzyć problem dokładnie jeden raz:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

Przy strongswan powinien być widoczny stan RUNNING,DEBUG. Następnie to samo polecenie ponownie wyłącza tryb debugowania, a drugie polecenie potwierdza powrót do poprzedniego stanu:

service strongswan:debug -ds nosync
service -S | grep strongswan

Sprawdzanie zestawiania tunelu

Faza 1: IKE, identyfikatory i uwierzytelnianie

Jeśli tunel się nie zestawia, zwykle nie zgadza się wersja IKE, brama, identyfikatory, propozycja, PSK lub certyfikat.

no IKE config found lub Remote peer is refusing our Phase 1 proposals: zapora nie znajduje pasującego połączenia albo profil jest niezgodny. Sprawdzić wersję IKE, Listening Interface, adres partnera, Local/Remote ID i profil.
peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found lub Remote peer reports we failed to authenticate: identyfikatory i uwierzytelnianie nie odpowiadają oczekiwanej konfiguracji partnera.
invalid HASH_V1 payload length lub decryption failed: w IKEv1 często oznacza błędny PSK; w IKEv2 częściej pojawia się AUTH_FAILED.
Druga strona łączy się z innym publicznym adresem albo UDP 500/4500 nie jest prawidłowo przekazywany przez NAT, router lub operatora.
Przy certyfikatach nie zgadza się łańcuch certyfikatów, wystawiający urząd certyfikacji (CA), okres ważności lub oczekiwany identyfikator.

Jeśli certyfikat został unieważniony przed końcem ważności albo działanie unieważnienia pozostaje niejasne, należy łącznie sprawdzić issuer, numer seryjny, thisUpdate, nextUpdate i odrzucenie właściwe dla danej usługi. Bezpieczną procedurę opisuje artykuł Importowanie i testowanie Certificate Revocation Lists na Sophos Firewall.

Local ID jednej strony musi odpowiadać Remote ID drugiej strony i odwrotnie. PSK należy ustawić ponownie po obu stronach; niewidoczne spacje i błędy kopiowania z menedżerów haseł są częstymi przyczynami. Nieprawidłowy identyfikator może uniemożliwić dopasowanie partnera, zanim zostanie sprawdzony oczekiwany PSK.

Faza 2: Traffic Selectors i Child SA

Jeśli faza 1 działa, ale brakuje Child SA, zwykle różnią się podsieci lub wartości fazy 2.

traffic selectors ... inacceptable
failed to establish CHILD_SA
received traffic selectors didn't match
Remote peer reports INVALID_ID_INFORMATION
różne wartości TSi i TSr
NO_PROPOSAL_CHOSEN po Phase 1 is up i Initiating establishment of Phase 2 SA

Sam komunikat NO_PROPOSAL_CHOSEN nie wystarcza do klasyfikacji: przed fazą 1 wskazuje wartości IKE/fazy 1, a po udanej fazie 1 — ESP, PFS lub inne wartości fazy 2.

W pełnym porównaniu pól General settings, Phase 1, Phase 2 i DPD pomaga artykuł Zrozumienie i bezpieczna konfiguracja profili IPsec Sophos Firewall.

Sieci muszą być skonfigurowane symetrycznie. Jeśli Sophos oczekuje lokalnie 172.16.10.0/24, a zdalnie 10.20.30.0/24, druga strona musi oferować 10.20.30.0/24 do 172.16.10.0/24. Już sieć /24 po jednej stronie i pojedynczy host lub inaczej zarządzane obiekty hostów po drugiej mogą uniemożliwić utworzenie Child SA.

Tunel jest aktywny, ale ruch nie przechodzi

W Advanced Shell następujące polecenie pokazuje SA, wynegocjowane sieci i liczniki bajtów:

ipsec statusall

Najważniejsze są ESTABLISHED, INSTALLED i liczniki w obu kierunkach. Jeśli oba pozostają puste, ruch testowy prawdopodobnie nie dociera do tunelu. Jeśli rośnie tylko licznik wychodzący, zwykle brakuje drogi powrotnej lub reguły po drugiej stronie; jeśli rosną tylko bajty przychodzące, podejrzane są lokalna trasa, lokalna reguła lub system docelowy.

Śledzenie pojedynczego przepływu testowego

Precyzyjny test dostarcza więcej informacji niż kilka równoległych poleceń ping:

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 należy sprawdzić kolejno:

Włączyć Log firewall traffic w odpowiedniej regule.
Filtrować Log Viewer według Source, Destination i Rule ID.
Uruchomić Packet Capture z filtrem host 172.16.10.25 and host 10.20.30.15.
Wykonać test dokładnie jeden raz.
Porównać regułę, NAT Rule ID, przekazywanie, odpowiedź i liczniki bajtów.
Po drugiej stronie sprawdzić drogę powrotną, zdalną regułę i system docelowy.

Jeśli żaden pakiet nie dociera do Sophos Firewall, przyczyna znajduje się wcześniej, na przykład w bramie klienta, VLAN lub routingu lokalnym. Jeśli pakiet dociera, ale nie jest przekazywany, nie zgadza się reguła, NAT, trasa lub Security Feature. Pełną procedurę opisano w artykule Sprawdzanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Routing i XFRM

W przypadku policy-based IPsec SFOS 22 obsługuje trasy VPN w backendzie. Ręczne trasy IPsec i Route Precedence sprawdza się w Device Console:

system ipsec_route show
system route_precedence show

Polecenie znane ze starszych procedur diagnostycznych nie jest w SFOS 22 wiarygodnym potwierdzeniem tunelu policy-based, gdy jest wykonywane w Advanced Shell:

ip route show table 220

W SFOS 22 trasy VPN policy-based i ręczne wpisy ipsec_route nie są tam widoczne. Brak wpisu nie dowodzi więc ani braku trasy, ani błędu routingu.

W przypadku route-based IPsec musi istnieć trasa statyczna, SD-WAN lub dynamiczna do interfejsu XFRM oraz odpowiednie stany XFRM. Należy sprawdzić interfejs XFRM w Network > Interfaces i ścieżkę w Diagnostics > Tools > Route lookup; skonfigurowane trasy statyczne pokazuje Device Console:

show static-route

Stany XFRM sprawdza się w Advanced Shell:

ip xfrm state
ip xfrm policy

Interfejsy XFRM nie mogą korzystać z nakładających się sieci tranzytowych. Połączenia z identycznymi podsieciami lokalnymi i zdalnymi powinny należeć do wspólnej grupy failover IPsec albo wymagać wyraźnie odmiennej logiki selektorów i routingu. Podlinkowany proces wyjaśnia kolejność w grupie, Health Check i kontrolowany test przełączenia.

Sprawdzanie NAT według typu tunelu

NAT jest dozwolony, ale musi odpowiadać typowi tunelu i adresom oczekiwanym przez drugą stronę.

Policy-based z SNAT: właściwa reguła SNAT wymaga Outbound interface Any. Domyślna reguła SNAT z konkretnymi portami WAN nie pasuje do ruchu policy-based IPsec.
Route-based z Any/Any lub Dual: MASQ tłumaczy Source na adres IP XFRM, który jest widoczny w wewnętrznym nagłówku IP w Packet Capture.
Route-based z konkretnymi Traffic Selectors: jeśli pasuje reguła MASQ, zapora odrzuca ruch, ponieważ takim interfejsom XFRM nie przypisano adresu IP.

Oryginalny i przetłumaczony adres Source należy udokumentować, dopuścić po drugiej stronie i zapewnić dla niego trasę powrotną. Podstawy oraz kolejność reguł opisano w artykule NAT na Sophos Firewall.

Niestabilność i szczególne przypadki w SFOS 22

Jeśli ruch zatrzymuje się dopiero później, należy porównać znaczniki czasu w statusie tunelu, strongswan.log, dgd.log, zdarzeniach WAN i teście aplikacji. Częste przyczyny:

Produkt innego producenta korzysta z traffic-based Rekeying; Sophos Firewall obsługuje time-based Rekeying.
Obie strony wykonują rekey jednocześnie. Należy celowo rozdzielić Key Lifetimes fazy 1 i fazy 2 między Initiator i Responder.
Powiązany interfejs został wyłączony. Tunele inicjowane rozłączają się natychmiast, a tunele typu responder najpóźniej po okresie bezczynności lub przekroczeniu limitu DPD.
Kilka połączeń z tymi samymi podsieciami nie należy do tej samej grupy failover.
Duże transfery nie działają mimo powodzenia małego testu; wtedy należy sprawdzić MTU i MSS.

Powtarzające się awarie firewalla przy ruchu multicast przez VPN

Jeśli awarie występują w tym samym czasie co ruch multicast przesyłany przez tunel VPN, należy najpierw zapisać wersję i build firmware, nazwę tunelu, znaczniki czasu oraz dostępne dane diagnostyczne lub dane z awarii. Sophos potwierdza ten problem jako NC-180433 i naprawił go w SFOS 22.0 MR2 Build 546.

Publiczny opis problemu nie wskazuje konkretnego typu tunelu ani konfiguracji multicast i nie podaje obejścia w CLI. W przypadku starszego buildu SFOS 22 należy sprawdzić ścieżkę aktualizacji, przejść na MR2 Build 546 lub nowszą zatwierdzoną wersję, a następnie powtórzyć ten sam ruch w kontrolowanych warunkach. Nie należy na podstawie przypuszczeń zmieniać parametrów tunelu, IPsec Acceleration ani usług. Jeśli firewall nadal ulega awarii w MR2 lub nowszej wersji, należy przekazać zebrane dane do Sophos Support zamiast automatycznie nadal przypisywać problem do NC-180433.

Standardową konfigurację i kontrolowany test odbiorczy opisano w artykule Multicast Routing na Sophos Firewall; opisana tutaj awaria pozostaje szczególnym przypadkiem zależnym od firmware.

Fragmentacja pakietów IKEv2

W przypadku Known Issue NC-136352 domyślny profil IKEv2 może oferować tak wiele grup DH, że pakiety IKE przekraczają 1'500 bajtów. Jeśli urządzenie pośrednie odrzuca fragmenty lub informacje PMTU, Initiator ponawia wysyłanie, a Responder niczego nie odbiera.

Przy dokładnie takim wzorcu błędu należy sprawdzić partnera w Advanced Shell:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Następnie w profilu IPsec należy oferować tylko rzeczywiście wymaganą grupę DH albo znacznie mniej grup. Ogólne filtry tcpdump i eksport PCAP opisano w artykule tcpdump na Sophos Firewall.

Alias PPPoE i IPsec Acceleration

NC-181526 dotyczy SFOS 22.0 GA Build 411 lub MR1 Build 490 na określonych fizycznych urządzeniach XGS: tunel korzysta z interfejsu aliasowego portu PPPoE-WAN, jest połączony, ale przy aktywnej funkcji IPsec Acceleration nie przesyła danych użytkowych. Problem nie dotyczy modeli XGS 88/88w, 108/108w, 118/118w i 128/128w.

Aktualna Sophos Known Issues List wskazuje SFOS 22.0.2 MR2 Build 546 jako wersję z poprawką, ale w opublikowanej liście poprawek MR2 identyfikator NC-181526 nie jest wymieniony osobno. Po aktualizacji należy więc powtórzyć ten sam przepływ testowy, zamiast zakładać poprawkę wyłącznie na podstawie numeru wersji.

⚠️ Wyłączenie IPsec Acceleration działa globalnie, ponownie uruchamia wszystkie tunele IPsec i powoduje przerwę. Należy testować je w oknie serwisowym wyłącznie przy dokładnie zgodnym zestawieniu wersji, sprzętu, aliasu PPPoE i wzorca błędu.

Poniższe polecenia wykonuje się w Device Console:

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

Jeśli nie ma poprawy, należy przywrócić stan początkowy:

system ipsec-acceleration enable

SFOS 22.0 MR2 rozwiązuje w ramach NC-180520 podobny, ale inny przypadek związany z aliasem IP: przy aktywnej funkcji Acceleration brama XFRM mogła pozostać nieosiągalna, jeśli ESP wchodził przez inny port WAN. Tych identyfikatorów problemów nie należy utożsamiać. Dalsze kontrole przed aktualizacją i po niej zawiera lista kontrolna aktualizacji do SFOS 22.

Weryfikacja i eskalacja

Po każdej zmianie należy powtórzyć ten sam pojedynczy przepływ testowy i udokumentować co najmniej:

czas, nazwę tunelu, adres IP partnera, Source, Destination i Service
status w WebAdmin oraz ipsec statusall przed testem i po nim
przypisaną regułę zapory i NAT
Packet Capture i liczniki w obu kierunkach
trasę powrotną i zdalną regułę po drugiej stronie
zmianę, wynik i przygotowany rollback

Następnie należy wyłączyć debugowanie StrongSwan. Logi istotne dla Sophos Support należy zebrać w sposób ukierunkowany; artykuł Zapisywanie logów Sophos Firewall opisuje eksport. Większe pakiety logów i przechwycenia należy przed przekazaniem sprawdzić pod kątem danych wrażliwych.