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 Fusion (dawniej 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. Poza interfejsem Sophos wariant route-based jest często nazywany również tunnel-based. Oba określenia opisują tunel z własnym interfejsem XFRM. Spotykany czasem termin “root-based” nie jest natomiast trybem VPN.

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.

Co naprawdę potwierdza zielony tunel

Stan taki jak Established potwierdza, że peery wynegocjowały IKE i co najmniej jedną Child SA. Nie potwierdza, że wybrano trasę, reguła firewall pasuje, NAT jest poprawny, peer zna drogę powrotną ani że host docelowy odpowiada. Tunel może więc być zielony, a mimo to nie przenosić użytecznego ruchu między lokalizacjami.

Sophos Firewall używa ESP w trybie tunelowym. ESP chroni integralność danych, uwierzytelnia pochodzenie przenoszonych danych i zapewnia ochronę anti-replay przed ponownym odtworzeniem pakietów.

Ścieżkę danych można przedstawić za pomocą następującego modelu:

Policy-based
Źródło -> Reguła firewall -> Selector Local/Remote -> Child SA -> Peer -> Trasa powrotna i reguła -> Cel

Route-based Any-to-Any
Źródło -> Trasa lub SD-WAN Route -> Reguła firewall -> XFRM -> Child SA -> Peer -> Trasa powrotna i reguła -> Cel

Jest to model diagnostyczny, a nie pełne odwzorowanie wewnętrznej kolejności przetwarzania SFOS. Rozróżnienie jest jednak kluczowe podczas odbioru: w trybie policy-based para sieci w połączeniu IPsec określa ruch należący do tunelu. W trybie route-based Any-to-Any wyboru dokonuje routing lub SD-WAN.

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.

Spójny przykład dla obu firewalli

Poniższe wartości dokumentacji ułatwiają realizację kolejnych kroków. Zastąp je wszystkie własnymi adresami WAN, sieciami i nazwami:

Najpierw utworzyć obie sieci LAN jako obiekty sieciowe w Hosts and services > IP host. W centrali 10.10.10.0/24 jest Local subnet, a 10.20.20.0/24 — Remote subnet; w oddziale wartości te należy odwrócić. To samo dotyczy identyfikatorów: Local ID jednej strony musi być oczekiwany jako Remote ID przez drugą. Sieć transferowa 10.255.0.0/30 jest używana tylko dla route-based Any-to-Any i nie może nakładać się na żadną sieć produkcyjną, VPN ani zarządzającą.

⚠️ 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.

⚠️ W IKEv1 firewall używa PSK z ostatnio skonfigurowanego połączenia dla tej samej kombinacji bramy lokalnej i zdalnej. Dotyczy to konfiguracji IPsec site-to-site i zdalnego dostępu. Późniejsze skonfigurowanie połączenia dla tej kombinacji bram z innym PSK może spowodować błąd uwierzytelniania istniejących połączeń podczas kolejnej negocjacji. Przed dodaniem takiego połączenia lub zmianą PSK sprawdzić wszystkie powiązane konfiguracje IKEv1 i uzgodnić PSK z odpowiednimi stronami zdalnymi przed następną negocjacją.

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.

Sophos Firewall nie udostępnia osobnego przełącznika NAT-T: Urządzenia automatycznie wykrywają NAT. Bez NAT negocjacje IKE używają UDP 500, a ruch danych korzysta z ESP przez IP protocol 50. Po wykryciu urządzenia NAT firewall enkapsuluje dalsze negocjacje IKE i fazy 2 oraz pakiety ESP w UDP 4500.

Jeśli na ścieżce IPsec znajduje się urządzenie NAT, a peer jest zaporą innego producenta, NAT-T musi być włączony również na tej zaporze. Ustawienie sprawdza się na podstawie dokumentacji tego peera; w Sophos Firewall nie jest potrzebny dodatkowy przełącznik.

Peery wykrywają urządzenie NAT podczas wymiany IKE fazy 1 i uzgadniają wtedy użycie NAT-T. ESP jest protokołem warstwy 3 bez informacji o portach warstwy 4, natomiast PAT może tłumaczyć również porty. Enkapsulacja UDP przez port 4500 zapewnia więc rozpoznawalną otoczkę UDP na ścieżce NAT; peer usuwa tę otoczkę i przetwarza oryginalny pakiet IPsec.

Jeśli Sophos Firewall znajduje się za routerem, router musi stosować DNAT lub przekierowanie portów z adresu publicznego na prywatny adres Listening interface zapory. Ścieżka NAT-T musi zezwalać na UDP 500 i UDP 4500; natywny ESP przez IP protocol 50 jest potrzebny tylko na ścieżce bez NAT. Jest to odrębne od późniejszego projektu SNAT lub DNAT dla nakładających się sieci albo tłumaczonego ruchu danych.

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.

Po wybraniu Digital certificate sama opcja w formularzu połączenia nie wystarcza. Zaufanie do CA, certyfikaty lokalne, certyfikaty peerów i Certificate IDs muszą być przygotowane wcześniej. Pełną procedurę opisuje Konfiguracja IPsec Site-to-Site z certyfikatami. Jeśli CA unieważnia certyfikaty przed końcem ważności, aktualna lista unieważnień również musi znaleźć się w planie operacyjnym. Osobna procedura opisuje import CRL, kontrolę 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 Branch-Zurich-IKEv2. 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. Przed aktywacją sprawdzić Dead peer detection: Sophos przewiduje Hold lub Disconnect dla peera odpowiadającego oraz Re-initiate dla inicjatora. Grupa failover IPsec zmienia to zachowanie i nie działa według tej samej logiki DPD.

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.

Następnie utworzyć połączenie po stronie zdalnej z ustawieniami lustrzanymi. W tym przykładzie centrala oczekuje na 203.0.113.20 z ustawieniem Respond only; jej sieci Local/Remote to odpowiednio 10.10.10.0/24 i 10.20.20.0/24. Oddział używa Initiate the connection, Gateway address 198.51.100.10 i zamienia miejscami sieci oraz identyfikatory Local/Remote. Profil, uwierzytelnianie i PSK muszą być zgodne. Połączenie należy aktywować dopiero po zapisaniu obu wpisów i sprawdzeniu reguł.

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 od wyboru trasy. Przy Any-to-Any SFOS udostępnia własny, adresowalny interfejs XFRM. W przypadku konkretnych Traffic Selectors aktualna dokumentacja SFOS 22 jest sprzeczna co do tworzenia interfejsu, jak wyjaśniono poniżej.

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

Przy Any-to-Any Sophos pokazuje utworzony interfejs XFRM pod używanym interfejsem fizycznym w:

Network > Interfaces

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

Any-to-Any z IPv4, IPv6 lub Dual

Gdy Local subnet i Remote subnet są ustawione na Any, SFOS automatycznie tworzy interfejs XFRM dla połączenia IPsec route-based. Nie dodaje się osobnego interfejsu XFRM. W Network > Interfaces rozwinąć interfejs fizyczny wybrany jako Listening interface i otworzyć wygenerowany interfejs XFRM. W tym przykładzie przypisać 10.255.0.1/30 centrali, a 10.255.0.2/30 oddziałowi. Przy Dual wymagane są również oddzielne reguły firewall IPv4 i IPv6.

Edytowalne pole Name jest nazwą wyświetlaną. Nie należy go mylić z wartościami przypisywanymi przez SFOS: Hardware to nazwa rekordu, IPsec connection to powiązane połączenie route-based, a Network zone ma zawsze wartość VPN. Skonfigurować wyłącznie pola adresowe wersji IP wybranej w połączeniu IPsec:

• IPv4/netmask: wprowadzić zaplanowany adres transferowy IPv4 i wybrać podsieć.
• IPv6/prefix: wprowadzić zaplanowany adres transferowy IPv6 i prefiks.
• Przy Dual skonfigurować obie rodziny adresów. Jeśli połączenie używa wyłącznie IPv4 lub IPv6, SFOS nie stosuje wartości wprowadzonych dla drugiej wersji.

W Advanced settings > Interface settings zachować domyślną wartość MTU lub wprowadzić wartość sprawdzoną w ukierunkowanych testach. SFOS oblicza wartość domyślną, odejmując maksymalny narzut IPsec od MTU interfejsu fizycznego. Override MSS włączyć i podać wartość tylko wtedy, gdy sieć wymaga wartości innej niż domyślna firewalla; nie zakładać nieudokumentowanej domyślnej wartości liczbowej.

Przed zmianą zapisać bieżącą nazwę, adresy, MTU, stan i wartość Override MSS oraz zależne trasy lub gatewaye. Po zapisaniu ponownie otworzyć interfejs i sprawdzić, czy przypisane wartości Hardware, IPsec connection i strefa VPN pozostały bez zmian. Następnie wykonać Route lookup na obu peerach i przetestować rzeczywisty ruch w obu kierunkach, a po zmianie MTU lub MSS również duży transfer. Aby wycofać zmianę, przywrócić zapisane wartości pól i poprzednie trasy lub gatewaye. Nowe połączenie należy dezaktywować i usunąć tylko jego zależne trasy i reguły; nie wolno oddzielnie usuwać ani odtwarzać wygenerowanego interfejsu XFRM.

Następnie należy utworzyć trasę do zdalnej sieci LAN po obu stronach. W prostej konfiguracji statycznej otworzyć Routing > Static routes > IPv4 unicast route > Add:

• Centrala: Destination 10.20.20.0/24, Interface lokalny interfejs XFRM.
• Oddział: Destination 10.10.10.0/24, Interface lokalny interfejs XFRM.

Alternatywnie użyć SD-WAN Route lub routingu dynamicznego przez BGP lub OSPF. Dla SD-WAN Route zdecydować wyraźnie, czy inna ścieżka jest dopuszczona jako awaryjna. Jeżeli ruch nie może korzystać z innej trasy, gdy tunel jest niedostępny, włączyć Route only through specified gateways i oddzielnie przetestować ten scenariusz awarii.

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.

Sprawdź cztery punkty po zapisaniu:

1. Interfejs XFRM jest widoczny w Network > Interfaces i ma planowany adres IP.
2. Trasa do sieci zdalnej wskazuje bezpośrednio interfejs XFRM lub, w projekcie z gatewayem/SD-WAN, odpowiedni gateway XFRM.
3. Diagnostics > Tools > Route lookup zwraca oczekiwany interfejs XFRM lub gateway XFRM dla rzeczywistego hosta w zdalnej sieci LAN. Ten sam test przeprowadzić po stronie zdalnej.
4. Reguły firewall zezwalają tylko na planowane kierunki i usługi.

Traffic Selectors

Przy konkretnych podsieciach zachowanie SFOS 22 w tym przypadku nie jest jednoznaczne: interfejs XFRM może nie powstać, ale firewall może też utworzyć po jednym dla każdej konfiguracji Traffic Selectors. Rozwiń Listening interface w Network > Interfaces i sprawdź rzeczywisty stan w zainstalowanym buildzie; istniejący interfejs XFRM można również wybrać w Diagnostics > Packet capture. Jeśli interfejs XFRM jest widoczny, nie przypisuj mu adresu IP ani tras. Trasa statyczna powstaje automatycznie, gdy tunel ma stan 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. Jeśli interfejs jest widoczny, użyć go zgodnie z dokumentacją do potwierdzenia ruchu wychodzącego w Diagnostics > Packet capture; sprawdzić również trasę automatyczną, Child SAs, logi i ruch w obu kierunkach. WAF przez IPsec route-based z Traffic Selectors nie jest 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.

Przychodzące pakiety IPsec są najpierw dekapsulowane i odszyfrowywane. Następnie pasująca reguła firewall stosuje swoje polityki bezpieczeństwa do ruchu danych, zanim zostanie on przekazany do celu. Dla ruchu wychodzącego pasująca reguła firewall jest stosowana przed enkapsulacją i szyfrowaniem.

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 zakazany w przypadku IPsec, ale musi mieć jasny powód. Typowymi przypadkami są nakładające się na siebie sieci, wymogi dotyczące chmury lub zewnętrzne systemy, które akceptują tylko określone adresy źródłowe. NAT nie zastępuje trasy i nie zmienia decyzji routingu: niezależnie od translacji SFOS musi być w stanie wybrać odpowiednią trasę VPN, statyczną, SD-WAN lub dynamiczną do miejsca docelowego.

Ś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 route-based IPsec z Traffic Selectors użyć ustawienia NAT w połączeniu IPsec i nie przypisywać adresu IP ani ręcznej trasy do interfejsu XFRM, jeśli zainstalowany build go pokazuje. IPsec z NAT dla nakładających się sieci pokazuje kompletny, lustrzany projekt adresacji, DNS i NAT.

Jeśli ruch VPN route-based z Traffic Selectors pasuje do reguły SNAT z ustawieniem Translated source = MASQ, firewall odrzuca pakiety, ponieważ te interfejsy XFRM nie mają przypisanych adresów IP. Może to wyjaśniać zielony tunel bez użytecznego ruchu. Dla danego przepływu testowego sprawdzić pasującą regułę NAT i jej pozycję, a następnie skorygować tylko regułę powodującą konflikt; nie wyłączać MASQ zbiorczo dla innych połączeń. Następnie ponownie sprawdzić ten sam przepływ w obu kierunkach za pomocą Log Viewer i Packet Capture.

Jeśli ruch użyteczny policy-based IPsec jest translacją objęty przez oddzielną regułę SNAT, jej Outbound interface należy ustawić na Any. Reguła, która wymienia tam tylko konkretne porty WAN — zazwyczaj domyślna reguła SNAT — nie pasuje do tego ruchu VPN. Przy ustawieniu Any firewall używa wartości Translated source skonfigurowanej w pasującej regule SNAT. To zachowanie obowiązuje również wtedy, gdy Override source translation (SNAT) jest włączone dla określonych interfejsów wychodzących.

Od SFOS 22 policy-based IPsec tworzy trasę VPN w backendzie. Ręczna ipsec_route ma znaczenie tylko w niektórych scenariuszach ruchu przekazywanego i nie jest standardowym krokiem; ruch generowany przez system jej nie wymaga. Dalsze podstawy NAT opisano w Zrozumienie reguł NAT w 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.

W Current activities > IPsec connections filtrować faktycznie zestawione połączenia według Connection name, Local subnet lub Remote subnet i odświeżyć widok za pomocą Refresh. Disconnect kończy istniejącą SA w kontrolowany sposób, na przykład gdy obie strony są gotowe do zmiany konfiguracji; nie zastępuje wyłączenia ani wycofania połączenia.

Z góry określić oczekiwaną liczbę: route-based Any-to-Any tworzy jedno połączenie Phase 2 na interfejs XFRM, natomiast Dual tworzy po jednym dla IPv4 i IPv6. Policy-based i route-based z Traffic Selectors tworzą jedno połączenie dla każdej kombinacji Local i Remote subnet.

Przed wysłaniem pierwszego ruchu użytecznego przez route-based Any-to-Any sprawdzić rzeczywisty adres hosta docelowego w Diagnostics > Tools > Route lookup. Na każdym firewallu wynik musi wskazywać planowany interfejs XFRM lub gateway XFRM.

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: sprawdzić, czy faktyczny build pokazuje interfejs XFRM pod Listening interface. Jeśli tak, użyć go w Packet Capture, ale nie przypisywać IP ani trasy. Sprawdzić też 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.

Rollback po nieudanej akceptacji

Nowy tunel należy wycofać w sposób kontrolowany, zamiast usuwać reguły i obiekty na podstawie przypuszczeń:

1. W Current activities > IPsec connections zakończyć odpowiednią SA za pomocą Disconnect i wyłączyć nowe połączenie IPsec.
2. Wyłączyć tylko trasy statyczne lub SD-WAN, reguły NAT i reguły firewall utworzone dla tej zmiany, w tym automatycznie wygenerowane reguły VPN. Nie usuwać oddzielnie wygenerowanego interfejsu XFRM, jeśli build go pokazuje; wyłączenie połączenia zarządza tym interfejsem.
3. Przy migracji ponownie przypisać poprzedni profil do starego połączenia, a następnie aktywować połączenie i starą ścieżkę routingu.
4. Ponownie sprawdzić pierwotny przepływ testowy oraz lokalny ruch internetowy lub ruch między lokalizacjami za pomocą Log Viewer i Packet Capture.
5. Nowe obiekty usuwać dopiero wtedy, gdy Object Usage nie wykazuje dalszych zależności, a działanie starej ścieżki zostało jednoznacznie potwierdzone.

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 zapisano faktyczną widoczność XFRM; niezależnie od tego, czy build pokazuje interfejs, nie zaplanowano IP XFRM ani ręcznych tras.
• 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.
• Macierz odbioru z co najmniej jednym testem dla każdego wymaganego kierunku została wykonana i zaliczona.
• 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