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

IPsec VPN typu Site-to-Site zazwyczaj działają bezproblemowo, dopóki nie pojawią się problemy. Gdy tunel nie nawiązuje połączenia, pozostaje niestabilny po ponownym połączeniu lub jest połączony, ale nie przesyła ruchu, konieczne jest systematyczne podejście do analizy. Bez tego łatwo można przeskakiwać między PSK, trasami, regułami zapory i logami, nie dostrzegając rzeczywistej przyczyny.

Artykuł wyjaśnia, jak systematycznie sprawdzać połączenia IPsec na Sophos Firewall: najpierw budowę tunelu, następnie negocjowane sieci, a na końcu rzeczywisty przepływ pakietów. Jeśli nowy tunel lokalizacji jest dopiero planowany lub konfigurowany, najpierw należy skonfigurować IPsec VPN typu Site-to-Site na Sophos Firewall. Dla ogólnych podstaw CLI pomocny jest również artykuł Rozwiązywanie problemów z CLI na Sophos Firewall: ważne polecenia.

Przed rozpoczęciem rozwiązywania problemów

Najpierw warto krótko udokumentować stan początkowy. Choć może to wydawać się banalne, oszczędza to dużo czasu, ponieważ wiele problemów z IPsec wynika z asymetrycznych założeń: jedna strona uważa, że łączy sieć A z siecią B, podczas gdy druga strona oczekuje innych identyfikatorów, innych podsieci lub innej wersji IKE.

Ważne punkty:

• Nazwa tunelu: azure-vpn
• Lokalna brama: Adres WAN lub FQDN Sophos Firewall
• Zdalna brama: Publiczny IP lub FQDN drugiej strony
• Wersja IKE: IKEv1 lub IKEv2
• Uwierzytelnianie: Klucz wstępnie współdzielony lub certyfikat
• Lokalny ID / Zdalny ID: Adres IP, FQDN lub identyfikator przypominający e-mail
• Lokalne sieci: 172.16.10.0/24
• Zdalne sieci: 10.20.30.0/24
• Typ VPN: oparty na politykach lub trasach
• Oczekiwany ruch: Źródło, cel, port i kierunek

W przypadku IPsec opartych na politykach lokalne i zdalne sieci są częścią negocjacji tunelu. W przypadku IPsec opartych na trasach ważne jest również, które trasy wskazują na interfejs tunelu. Jeśli ruch mimo aktywnego tunelu kieruje się w złą stronę, często są zaangażowane trasy IPsec, trasy statyczne, trasy polityki SD-WAN lub priorytet tras na Sophos Firewall.

Jeśli tunel jest aktywny i małe testy działają, ale większe transfery się zawieszają, warto dodatkowo sprawdzić MTU i MSS. Procedura jest opisana w artykule Sprawdzanie MTU i MSS na Sophos Firewall w przypadku problemów z VPN.

⚠️ Logi debugowania i przechwytywanie pakietów mogą zawierać wrażliwe dane, takie jak publiczne adresy IP, wewnętrzne sieci, nazwy hostów lub dane użytkowe. Takie dane powinny być zbierane tylko celowo i na krótki czas oraz sprawdzane przed przekazaniem.

Ścieżka diagnostyczna

W praktyce pomocna jest prosta kolejność:

1. Czy tunel się nawiązuje? Jeśli nie, najpierw sprawdź wersję IKE, profil IPsec, identyfikatory, PSK/certyfikat, NAT-T i dostępność drugiej strony.
2. Czy faza 2 jest nawiązywana? Jeśli nie, sprawdź selektory ruchu, lokalne i zdalne sieci, PFS i propozycje fazy 2.
3. Czy zainstalowano skojarzenie bezpieczeństwa? Jeśli tak, sprawdź ipsec statusall i zwróć uwagę na liczniki bajtów.
4. Czy ruch przechodzi przez tunel? Jeśli nie, sprawdź reguły zapory, NAT, routing, priorytet tras, trasy IPsec i drogę powrotną.
5. Czy widać pakiety? Jeśli nie jest to jasne, połącz Log Viewer i Packet Capture.

Częsty błąd myślowy: zielony status tunelu dowodzi jedynie, że IPsec zostało zasadniczo wynegocjowane. Nie dowodzi to, że reguły zapory są poprawne, że trasy są prawidłowe lub że druga strona zna drogę powrotną.

Która warstwa jest dotknięta?

Przed logami debugowania warto wstępnie określić problem. Dzięki temu szybciej staje się jasne, czy szukać przy IKE, fazie 2, routingu czy przepływie pakietów.

• Tunel pozostaje nieaktywny: IKE, brama, identyfikatory, PSK, certyfikat lub propozycja Sprawdź strongswan.log na żywo i porównaj fazę 1
• Tunel stale przełącza się między aktywnym a nieaktywnym: Rekey, DPD, stabilność WAN lub propozycja Porównaj znaczniki czasu, DPD, czas życia i zdarzenia WAN
• Faza 1 jest aktywna, ale brak Child SA: Selektory ruchu, propozycja fazy 2 lub PFS Sprawdź lokalne i zdalne sieci lustrzanie
• Tunel jest zielony, ale liczniki bajtów pozostają puste: Ruch nie dociera do tunelu Sprawdź regułę zapory, NAT, trasę i bramę klienta
• Tylko wychodzące bajty rosną: Brak drogi powrotnej lub drugiej strony Sprawdź zdalną zaporę, zdalną trasę i system docelowy
• Packet Capture pokazuje pakiety bez pasującej reguły: Kolejność reguł, strefa lub usługa nie pasują Porównaj Log Viewer, Policy Test i Rule ID

To wstępne określenie nie zastępuje analizy szczegółowej. Zapobiega jednak szukaniu błędu fazy 2 w regułach zapory lub niepotrzebnemu resetowaniu klucza wstępnie współdzielonego przy problemie z drogą powrotną.

Zbieranie logów

Sophos Firewall używa StrongSwan do IPsec. Najważniejsze logi znajdują się w /log:

• strongswan.log: najważniejszy plik logu IPsec dla IKE, uwierzytelniania i Child SAs
• charon.log: log demona IKE, pomocny w zależności od wersji i sytuacji
• strongswan-monitor.log: monitorowanie usługi IPsec
• dgd.log: wykrywanie martwej bramy i przełączanie awaryjne VPN

Otwórz za pomocą SSH Advanced Shell i w razie potrzeby przejdź do katalogu logów:

cd /log

Log na żywo można śledzić bezpośrednio:

tail -f /log/strongswan.log

Jeśli aktywnych jest wiele tuneli, warto filtrować. Można to zrobić po nazwie tunelu, adresie IP partnera lub typowym tekście błędu:

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

Dla istniejących plików logów less jest często wygodniejszy:

less /log/strongswan.log

W less można szukać wewnątrz pliku za pomocą /szukany_tekst. Alternatywnie grep filtruje bezpośrednio:

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

Aktywacja debugowania StrongSwan

Jeśli normalny log nie wystarcza, można ustawić usługę StrongSwan w tryb debugowania:

service strongswan:debug -ds nosync

Następnie sprawdź, czy usługa działa w trybie debugowania:

service -S | grep strongswan

Wynik powinien pokazywać stan RUNNING,DEBUG dla strongswan. Następnie ponownie połącz tunel lub celowo odtwórz błąd i obserwuj log:

tail -f /log/strongswan.log

Ten sam polecenie debugowania wyłącza tryb debugowania:

service strongswan:debug -ds nosync

⚠️ Debugowanie należy uruchamiać tylko na czas rzeczywistej potrzeby. Debugowanie IPsec może szybko generować duże pliki logów i niepotrzebnie zajmować miejsce na firewallu.

Faza 1: IKE, identyfikatory i uwierzytelnianie

Jeśli tunel w ogóle się nie nawiązuje, przyczyna leży zazwyczaj przed lub podczas fazy 1. Wtedy bramy negocjują jeszcze nie sieci danych użytkowych, ale najpierw IKE, uwierzytelnianie i identyfikatory obu stron.

Typowe przyczyny:

• Wersja IKE nie pasuje
• Profil IPsec lub propozycja nie pasuje
• Lokalny lub zdalny ID jest inny niż oczekiwano
• Klucz wstępnie współdzielony jest błędny
• Druga strona osiąga niewłaściwy publiczny IP
• NAT-T lub przekierowanie portów na UDP 500 i 4500 nie jest poprawne
• Certyfikaty, CA lub ważność nie pasują przy uwierzytelnianiu certyfikatowym

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 odpowiedniej konfiguracji IKE dla przychodzącego pakietu. Może to wynikać z wersji IKE, bramy, identyfikatorów lub profilu IPsec.

Sprawdź:

• Czy IKEv1 lub IKEv2 jest zgodne po obu stronach?
• Czy druga strona pasuje do skonfigurowanego adresu zdalnej bramy lub FQDN?
• Czy lokalny i zdalny ID są zgodne?
• Czy szyfrowanie, uwierzytelnianie, grupa DH i czas życia są kompatybilne?
• Czy druga strona używa innego publicznego IP niż udokumentowano?

Peer authentication failed

peer authentication failed, AUTH_FAILED lub no matching peer config found często wskazuje na niepasujące identyfikatory lub dane uwierzytelniające. Przy kluczu wstępnie współdzielonym często podejrzewa się najpierw klucz. Często jest to słuszne, ale nie zawsze. Jeśli ID nie pasuje, firewall może w ogóle nie sprawdzać względem oczekiwanej konfiguracji partnera.

Sprawdź:

• Lokalny ID jednej strony odpowiada zdalnemu ID drugiej strony.
• Zdalny ID jednej strony odpowiada lokalnemu ID drugiej strony.
• Pisownia, wielkość liter, FQDN i adresy IP są dokładnie zgodne.
• Klucz wstępnie współdzielony został wprowadzony bez spacji na początku lub końcu.
• Przy wielu tunelach do tej samej strony jest jednoznaczne, które połączenie ma pasować.

Invalid HASH_V1 payload lub decryption failed

Przy IKEv1 komunikaty takie jak invalid HASH_V1 payload length lub decryption failed często wskazują na błędny klucz wstępnie współdzielony. Przy IKEv2 częściej widzi się AUTHENTICATION_FAILED lub AUTH_FAILED.

W praktyce warto ponownie ustawić klucz wstępnie współdzielony po obu stronach, zamiast go tylko wizualnie porównywać. Kopiowanie-wklejanie z menedżerów haseł, niewidoczne spacje lub różne znaki specjalne to klasyczne pożeracze czasu.

Faza 2: Selektory ruchu i skojarzenia bezpieczeństwa

Jeśli faza 1 zakończyła się sukcesem, ale faza 2 nie dochodzi do skutku, chodzi zazwyczaj o sieci i Child SA. Sophos Firewall musi z drugą stroną wynegocjować, które lokalne i zdalne podsieci mogą przechodzić przez tunel.

Typowe wskazówki w logach:

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

Sprawdź:

• Lokalne i zdalne sieci są skonfigurowane lustrzanie po obu stronach.
• Maska sieci i pojedyncze obiekty hostów są dokładnie zgodne.
• Nie ma niechcianych nakładających się z innymi tunelami.
• Wiele sieci fazy 2 jest odwzorowanych identycznie po obu stronach.
• PFS, szyfrowanie ESP, uwierzytelnianie i czas życia są zgodne.

Przykład: Jeśli Sophos Firewall oczekuje lokalnie 172.16.10.0/24 i zdalnie 10.20.30.0/24, druga strona musi dokładnie lustrzanie oferować 10.20.30.0/24 do 172.16.10.0/24. /24 po jednej stronie i pojedynczy host lub większa sieć po drugiej stronie mogą 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 ruch nie przechodzi, IPsec sam w sobie nie jest automatycznie przyczyną. Zazwyczaj chodzi o routing, reguły zapory, NAT lub drogę powrotną.

Najpierw sprawdź status IPsec w Advanced Shell:

ipsec statusall

Interesujące są przede wszystkim:

• Czy IKE SA jest ESTABLISHED?
• Czy Child SA jest INSTALLED?
• Jakie lokalne i zdalne sieci są wyświetlane?
• Czy liczniki bajtów rosną w obu kierunkach?
• Czy widać tylko wychodzące bajty, ale brak przychodzących?
• Czy regularnie następuje ponowne połączenie lub rekey?

Jeśli Child SA jest zainstalowana, ale liczniki bajtów pozostają puste, oczekiwany ruch prawdopodobnie nie dociera do tunelu. Następnie sprawdź drogę przed i po IPsec.

Reguły zapory

Dla ruchu przez tunel potrzebne są odpowiednie reguły zapory. W zależności od modelu strefy może to być na przykład LAN do VPN, VPN do LAN lub własna strefa. Reguła musi poprawnie obejmować źródło, cel, usługę i kierunek.

Ważne:

• W odpowiednich regułach aktywuj Log firewall traffic.
• Sprawdź pozycję reguły, aby żadna bardziej ogólna reguła nie była wcześniej stosowana.
• Wybierz poprawnie strefy źródłowe i docelowe.
• Przy wielu VPN nie używaj zbyt szerokich obiektów, jeśli mogą one pasować do niewłaściwego tunelu.
• Świadomie sprawdź funkcje bezpieczeństwa, takie jak IPS, filtr sieciowy lub kontrola aplikacji, jeśli są aktywne na ruchu.

Ogólny przebieg testu opisuje artykuł Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Routing i trasy IPsec

Jeśli firewall nie wysyła ruchu do tunelu, sprawdź trasy. W przypadku IPsec opartych na politykach dodatkowo może być istotna tabela routingu IPsec:

ip route show table 220

Jeśli konieczne jest ręczne przypisanie, może pomóc trasa IPsec na Sophos Firewall. Jeśli konkurują różne rodzaje routingu, warto dodatkowo sprawdzić priorytet routingu na Sophos Firewall.

Sprawdź:

• Czy istnieje bardziej szczegółowa trasa statyczna, która przechwytuje ruch?
• Czy trasa polityki SD-WAN działa przed trasą VPN?
• Czy brama klienta rzeczywiście wskazuje na Sophos Firewall?
• Czy druga strona ma trasę powrotną do lokalnej sieci?
• Czy istnieją nakładające się lokalne i zdalne sieci?

NAT

NAT nie jest zasadniczo błędny przy IPsec, ale musi być świadomie skonfigurowany. Nieumyślne MASQ lub zbyt szeroka reguła SNAT mogą spowodować, że druga strona nie przypisze ruchu do oczekiwanej sieci.

Sprawdź:

• Czy ogólna reguła MASQ działa przed specyficzną regułą NAT VPN?
• Czy druga strona oczekuje oryginalnych adresów IP czy przetłumaczonych adresów?
• Czy NAT jest udokumentowany po obu stronach?
• Czy reguła NAT pasuje do kierunku ruchu?

Jeśli NAT jest zaangażowany, pomocny jest artykuł Zrozumienie NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

SFOS 22: Świadome sprawdzanie IPsec opartych na politykach i NAT

Przy aktualizacjach do SFOS 22 IPsec opartych na politykach należy szczególnie dokładnie sprawdzić. Sophos wskazuje w notatkach wydania SFOS-22 na zmienione zachowanie przy IPsec VPN opartych na politykach. Dodatkowo w rozwiązanych problemach NC-170917 jest udokumentowane: Ruch IPsec oparty na politykach mógł się nie powieść, jeśli domyślna reguła SNAT była skonfigurowana z adresem IP statycznym zamiast MASQ.

W praktyce oznacza to: Jeśli tunel oparty na politykach po aktualizacji jest zielony, ale ruch nie płynie lub jest jednostronny, NAT nie powinien być traktowany jako temat poboczny. Stara, szeroka lub nietypowo dostosowana domyślna reguła SNAT może zmienić dokładnie ten ruch, który druga strona oczekuje z oryginalnymi sieciami.

Typowe punkty kontrolne po aktualizacji do SFOS-22:

• Czy tunel jest naprawdę oparty na politykach?: W przypadku IPsec opartych na politykach lokalne i zdalne sieci są częścią negocjacji. NAT może złamać to oczekiwanie.
• Czy domyślna reguła SNAT została dostosowana?: Statyczny IP SNAT zamiast MASQ może mieć inne skutki po aktualizacji niż oczekiwano.
• Czy istnieją specyficzne reguły NAT VPN?: Muszą one być powyżej ogólnych reguł SNAT lub MASQ i pasować do kierunku ruchu.
• Czy selektory ruchu i obiekty NAT są zgodne?: Druga strona musi oczekiwać albo oryginalnych sieci, albo przetłumaczonych sieci, nie obu przypadkowo.
• Czy Packet Capture pokazuje oczekiwany adres źródłowy?: W ten sposób można rozpoznać, czy firewall używa innego adresu źródłowego przed tunelem.

Czysty przypadek testowy składa się ze źródła, celu i usługi. Następnie sprawdza się kolejno regułę zapory, regułę NAT, ipsec statusall, ip route show table 220, Packet Capture i drugą stronę. Jeśli test działa tylko z wyłączoną lub przesuniętą regułą NAT, problem nie leży w budowie tunelu, ale w ścieżce do tunelu.

Dla planowania aktualizacji dodatkowo pasuje artykuł Sprawdzenie Sophos Firewall przed aktualizacją do SFOS 22. Dla podstaw NAT i kolejności reguł lepszym wprowadzeniem jest Zrozumienie NAT na Sophos Firewall.

SFOS 22: PPPoE-WAN z Alias-Interface i IPsec Acceleration

Jeśli po aktualizacji do SFOS 22.0 GA lub SFOS 22.0 MR1 tunel IPsec jest połączony, ale nie przekazuje ruchu, w określonych konfiguracjach może wystąpić dodatkowy przypadek szczególny. Sophos wymienia w liście znanych problemów NC-181526: Na sprzęcie XGS tunele IPsec na interfejsach aliasowych portu PPPoE-WAN mogą być zbudowane, ale nie przekazują ruchu użytkowego, gdy IPsec acceleration jest aktywne.

Ten punkt powinien być sprawdzany dopiero, gdy normalne przyczyny nie pasują. Zielony tunel bez ruchu jest zazwyczaj nadal problemem z regułami, routingiem, NAT lub drogą powrotną. Przypadek szczególny SFOS-22 staje się bardziej prawdopodobny, gdy wszystkie poniższe punkty występują razem:

• Sophos Firewall działa na SFOS 22.0 GA lub SFOS 22.0 MR1.
• Jest to sprzęt XGS.
• Dotknięty tunel używa interfejsu aliasowego na porcie PPPoE-WAN.
• Tunel się buduje, ale ruch użytkowy nie przechodzi.
• Reguły zapory, NAT, trasy, droga powrotna i Packet Capture nie wyjaśniają zachowania.
• IPsec acceleration jest aktywne.

Jako obejście dokumentowane jest wyłączenie IPsec acceleration:

system ipsec-acceleration off

Nie należy tego używać jako ogólnego polecenia do tuningu IPsec. Zmiana powinna być przeprowadzona w oknie konserwacyjnym lub w udokumentowanym procesie wsparcia, z testem przed i po oraz jasnym przypisaniem do dotkniętego obrazu błędu. Sophos wymienia SFOS 22.0.2 MR2 jako wersję naprawczą dla tego znanego problemu. Jeśli ta wersja jest zatwierdzona dla dotkniętego środowiska, zaplanowana aktualizacja jest czystsza niż trwałe zapomniane obejście.

Praktyczny przebieg testu:

1. Udokumentuj status tunelu i ipsec statusall.
2. Wykonaj Packet Capture z wąskim filtrem źródła/celu.
3. Sprawdź, czy tunel naprawdę używa interfejsu aliasowego na porcie PPPoE-WAN.
4. Zanotuj aktywną wersję SFOS i model sprzętu.
5. Zmianę w IPsec acceleration testuj tylko celowo i dokumentuj.
6. Po teście porównaj liczniki bajtów, Packet Capture, Log Viewer i test aplikacji.

Łączenie Log Viewer i Packet Capture

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

Dla rozwiązywania problemów z IPsec warto zdefiniować jak najwęższy test:

• Adres źródłowy: 172.16.10.25
• Adres docelowy: 10.20.30.15
• Usługa: ICMP lub TCP 443
• Oczekiwany kierunek: LAN do VPN
• Oczekiwana reguła: LAN_to_VPN_Branch

Następnie:

1. W regule zapory aktywuj logowanie.
2. Filtruj Log Viewer po adresie źródłowym, docelowym i module Firewall.
3. Rozpocznij Packet Capture z wąskim filtrem, na przykład host 172.16.10.25 and host 10.20.30.15.
4. Dokładnie raz odtwórz test.
5. Sprawdź, czy pakiety docierają, są przekazywane i czy odpowiedzi wracają.

Interpretacja:

• Żaden pakiet nie dociera do Sophos Firewall: Sprawdź klienta, bramę, VLAN, przełącznik lub lokalne routowanie
• Pakiet dociera, ale nie jest przekazywany: Sprawdź regułę zapory, NAT, trasę lub funkcję bezpieczeństwa
• Pakiet jest wysyłany do tunelu, brak odpowiedzi: Sprawdź trasę powrotną, drugą stronę, zdalną zaporę lub zdalny host
• Tylko wychodzące bajty w ipsec statusall: Sprawdź drogę powrotną lub zdalną politykę
• Tylko przychodzące bajty: Sprawdź lokalną trasę, lokalną regułę zapory lub system docelowy

Dla dłuższych przechwyceń lub przypadków wsparcia może być sensowne celowe zbieranie logów. Artykuł Zabezpieczanie logów Sophos Firewall dla wsparcia i analizy opisuje czysty eksport.

Typowe scenariusze błędów

• no IKE config found: Wersja IKE, brama, identyfikatory lub profil nie pasują Porównaj wersję IKE, lokalny/zdalny ID i propozycje
• NO_PROPOSAL_CHOSEN: Niepasująca propozycja Sprawdź szyfrowanie, uwierzytelnianie, grupę DH, PFS i czas życia
• peer authentication failed: ID lub uwierzytelnianie nie pasuje Sprawdź lokalny/zdalny ID i PSK/certyfikat
• AUTH_FAILED: Klucz wstępnie współdzielony, certyfikat lub ID nie pasuje Ustaw ponownie PSK, sprawdź łańcuch certyfikatów i identyfikatory
• traffic selectors ... inacceptable: Lokalne i zdalne sieci nie pasują Porównaj lustrzanie podsieci i obiekty hostów
• failed to establish CHILD_SA: Sieci fazy 2 lub propozycje ESP nie pasują Sprawdź selektory ruchu, PFS, profil ESP i czasy życia
• Tunel zielony, brak bajtów: Ruch nie dociera do tunelu Sprawdź regułę zapory, trasę, NAT i bramę klienta
• Wychodzące bajty, brak przychodzących: Brak drugiej strony lub drogi powrotnej Sprawdź zdalne reguły, zdalną trasę i system docelowy
• Duże transfery zawieszają się mimo aktywnego tunelu: MTU/MSS, utrata pakietów lub Path-MTU-Discovery Sprawdź MTU i MSS przy problemach z VPN
• SFOS 22, IPsec oparty na politykach, tunel zielony, brak ruchu: NAT, domyślna SNAT lub selektory ruchu nie pasują po aktualizacji Sprawdź domyślną SNAT, reguły NAT VPN, MASQ, Packet Capture i drugą stronę
• SFOS 22, PPPoE-WAN-Alias, tunel zielony, brak ruchu: możliwy znany problem z IPsec acceleration Sprawdź typ interfejsu, wersję SFOS i system ipsec-acceleration off tylko celowo
• Ponowne połączenia lub częste rekey: Czas życia, DPD, niestabilne połączenie lub temat propozycji Sprawdź czasy rekey, DPD, stabilność WAN i logi

Praktyczna lista kontrolna

Natychmiast sprawdź:

• Zanotuj status tunelu i ostatni komunikat o błędzie w WebAdmin.
• Uruchom tail -f /log/strongswan.log i ponownie połącz tunel.
• Sprawdź wersję IKE, lokalny ID, zdalny ID i klucz wstępnie współdzielony.
• Porównaj lustrzanie selektory ruchu lub lokalne i zdalne sieci.
• Sprawdź ipsec statusall pod kątem ESTABLISHED, INSTALLED i liczników bajtów.

Jeśli tunel jest aktywny:

• Sprawdź reguły zapory w obu kierunkach.
• Aktywuj logowanie na dotkniętych regułach.
• Filtruj Log Viewer po źródle, celu i ID reguły.
• Wykonaj Packet Capture z wąskim filtrem.
• Sprawdź reguły NAT i priorytet tras.
• Przy SFOS 22 z IPsec opartym na politykach sprawdź domyślną SNAT, specyficzne reguły NAT VPN i oczekiwany adres źródłowy.
• Przy SFOS 22 z PPPoE-WAN-Alias sprawdź, czy pasuje znany problem z IPsec acceleration.
• Potwierdź trasę powrotną na drugiej stronie.

Dla wsparcia lub dłuższej analizy:

• Aktywuj debugowanie tylko na krótko i potem je wyłącz.
• Zabezpiecz odpowiednie logi.
• Udokumentuj czas, nazwę tunelu, IP partnera, źródło, cel i przebieg testu.
• Sprawdź wrażliwe dane przed przekazaniem.

FAQ