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.

Ten artykuł wyjaśnia, jak poprawnie zbudować tunel IPsec Site-to-Site na Sophos Firewall. Skupia się na planowaniu, wdrożeniu i teście odbiorczym. Jeśli istniejący tunel jest już zielony, ale ruch nie przepływa, lepszym artykułem uzupełniającym jest Sophos Firewall IPsec VPN Troubleshooting.

Kiedy ten artykuł pasuje

Artykuł pasuje do klasycznych połączeń między lokalizacjami, na przykład:

• Centrala z oddziałem
• Sophos Firewall z Sophos Firewall
• Sophos Firewall z firewallem innego dostawcy
• Sophos Firewall z cloud gateway, gdy nie jest używany specjalny asystent cloud
• Migracja prostych starych tuneli policy-based do udokumentowanej aktualnej konfiguracji

Dla Microsoft Azure lub AWS istnieją dodatkowo osobne artykuły opisujące pułapki specyficzne dla danego dostawcy: Łączenie Sophos Firewall z Azure VPN Gateway oraz Łączenie Sophos Firewall z AWS Site-to-Site VPN.

Nie chodzi tu o Remote Access dla pojedynczych użytkowników. Do tego pasują artykuły Konfiguracja Sophos Connect na Sophos Firewall, Sophos Connect czy SSL VPN: które rozwiązanie Remote Access pasuje? oraz Migracja legacy Remote Access IPsec przed SFOS 22 MR1.

IPsec policy-based czy route-based

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

• IPsec policy-based: pasuje do prostych połączeń między lokalizacjami z jasnymi sieciami lokalnymi i zdalnymi. Sterowane głównie przez lokalne i zdalne podsieci w połączeniu IPsec oraz przez reguły firewall. Sophos tworzy przy tym osobne tunele Phase 2 dla kombinacji sieci lokalnych i zdalnych.
• IPsec route-based z traffic selectors: również wykorzystuje lokalne i zdalne podsieci, ale tworzy własny interfejs XFRM dla połączenia. Ułatwia to debugowanie i lepiej oddziela tunel od innych połączeń IPsec.
• IPsec route-based Any-to-Any: najbardziej elastyczny wariant dla rosnących sieci, SD-WAN, routingu dynamicznego i projektów dual-stack. To trasy i reguły firewall decydują wtedy, które pakiety trafiają do tunelu, a nie podsieci w połączeniu IPsec.

Dla małych, stabilnych połączeń policy-based IPsec jest często najszybszy do zrozumienia. Dla większych albo dynamicznych sieci lokalizacji route-based IPsec jest zwykle czystszy, ponieważ lepiej rozdziela routing i negocjację VPN. Jeśli uczestniczy wiele sieci, SD-WAN, BGP, OSPF albo sieci cloud, najpierw należy sprawdzić route-based IPsec.

Wymagania

Przed konfiguracją należy udokumentować te informacje:

• Local gateway: WAN-IP albo FQDN lokalnej Sophos Firewall.
• Remote gateway: publiczny IP albo FQDN strony zdalnej.
• Sieci lokalne: 172.16.10.0/24, 172.16.20.0/24.
• Sieci zdalne: 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 dla lokalizacji.
• Listening interface: interfejs WAN lokalnego firewalla. Nie można do tego użyć bridge interface.
• Wersja IKE: IKEv2, jeśli strona zdalna ją obsługuje.
• Uwierzytelnianie: Preshared Key albo certyfikat.
• Profil IPsec: Encryption, authentication, DH group, PFS, key lifetime.
• Reguły firewall: dozwolone źródła, cele i usługi.
• NAT: bez NAT, SNAT/DNAT z powodu nakładających się sieci albo wymagań dostawcy.
• Eksploatacja: owner, okno serwisowe, plan testów, monitoring, ścieżka fallback.
• Gateway type: initiate connection lub respond only, zależnie od tego, która strona otwiera tunel.
• IP version: IPv4, IPv6 lub Dual, jeśli obie strony wyraźnie to obsługują.
• Local ID i Remote ID: potrzebne, jeśli uwierzytelnianie nie ma zależeć tylko od publicznego adresu IP.

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

Planowanie przed konfiguracją

Utrzymać jednoznaczne sieci

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 tłumaczenie go “jakoś” tworzy tunele trudne w utrzymaniu.

Dla nowych lokalizacji warto więc przygotować czystą koncepcję adresacji IP. Jeśli VLANs albo zones nie są jeszcze dobrze zamodelowane, pomaga konfiguracja zones i interfaces w Sophos Firewall.

Uzgodnić profil IPsec

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 zapisać wspólny profil na piśmie, a dopiero potem skonfigurować obie strony.

Jeśli tunel się nie zestawia, typowymi wskazówkami są NO_PROPOSAL_CHOSEN, błędy ID albo błędy uwierzytelniania. Ustrukturyzowana analiza znajduje się w Sophos Firewall IPsec VPN Troubleshooting.

Nie zapomnieć o regułach firewall

Tunel IPsec sam w sobie nie daje jeszcze dostępu produkcyjnego. Ruch przez tunel nadal wymaga odpowiednich reguł firewall. Przy połączeniach policy-based są to najczęściej reguły między LAN i VPN albo między własnymi zones. W projektach route-based interfejs XFRM należy do strefy VPN; potem trasy i reguły firewall decydują, jaki ruch rzeczywiście może przejść przez tunel.

Podczas wdrożenia należy włączyć Log firewall traffic w odpowiednich regułach. W przeciwnym razie później zabraknie dokładnie tej informacji, która reguła dopuściła albo zablokowała test. Ogólny przebieg kontroli opisuje test reguły firewall z Log Viewer, Policy Test i Packet Capture.

Świadomie sprawdzić reguły utworzone automatycznie

Nie. Create firewall rule może podczas tworzenia połączenia utworzyć pierwszy zestaw reguł. Dokładne sprawdzenie kierunku, pozycji, źródeł, celów, usług, logowania i Security Features nadal jest konieczne. Przy route-based IPsec z subnetami Any-to-Any reguły należy planować ręcznie.

Dla eksploatacji ważne jest więc:

• Pozycja reguły: Po zapisaniu przenieść automatycznie utworzone reguły we właściwe miejsce.
• Kierunek: Oddzielnie sprawdzić regułę przychodzącą i wychodzącą, nie tylko nazwę tunelu.
• Źródła i cele: Zawęzić sieci lokalne i zdalne, jeśli asystent utworzył je zbyt szeroko.
• Usługi: Any użyć tylko do pierwszego testu, potem ograniczyć do potrzebnych usług.
• Logging: Włączyć podczas wdrożenia i analizy błędów.
• Security Features: IPS, Web, Application Control albo NDR ustawić świadomie, nie przejmować przypadkowo.

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

Przy route-based IPsec z subnetami Any-to-Any trzeba pracować szczególnie dokładnie. Dla takich projektów route-based nie można tworzyć automatycznych reguł firewall. Przy wersjach dual IP reguły IPv4 i IPv6 należy planować oddzielnie. W tych scenariuszach reguły firewall, interfejs XFRM, trasy i testy powinny być świadomie zbudowane ręcznie.

Konfiguracja IPsec policy-based

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

1. Sprawdzić albo utworzyć profil IPsec

Menu path:

Profiles > IPsec profiles

Najpierw sprawdzić, czy istniejący profil pasuje do strony zdalnej. Jeśli potrzebny jest własny profil, powinien mieć jednoznaczną nazwę, na przykład IPsec_IKEv2_AES256_G14. Nazwa musi pozostać zrozumiała później, 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 lifetime

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

2. Dodać połączenie IPsec

Menu path:

Site-to-site VPN > IPsec

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

• Nazwa tunelu, na przykład branch-zurich
• Local gateway albo Listening interface
• Remote Gateway jako adres IP albo FQDN
• Authentication type: Preshared Key albo certyfikat
• Local ID i Remote ID, jeśli potrzebne
• IPsec profile
• Local subnet
• Remote subnet

NAT Traversal jest w Sophos Firewall zawsze aktywny. Jeśli jedna strona znajduje się za routerem lub NAT-em dostawcy, Local ID i Remote ID stają się jeszcze ważniejsze, ponieważ publiczny adres gatewaya nie wystarcza już do czystej identyfikacji peera. ID typu DNS, IP albo e-mail nie muszą być publicznie rozwiązywalne; muszą tylko pasować po obu stronach i mieć poprawny format.

Dla Preshared Keys należy użyć silnego, unikalnego klucza i bezpiecznie go udokumentować. Współdzielony stary standardowy klucz używany w kilku lokalizacjach to niepotrzebne ryzyko operacyjne.

Zaawansowane ustawienia User authentication mode dotyczą tylko profili IKEv1 z logiką XAuth, na przykład bardzo starych projektów client-server. W normalnych połączeniach site-to-site z IKEv2 nie należy traktować tego jako dodatkowego kroku uwierzytelniania. Przestarzałe ustawienia idle connection również nie powinny być planowane jako nowoczesny model operacyjny.

3. Aktywować tunel

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
• IP version, zwykle IPv4.
• Gateway type, zwykle initiate connection po stronie ze zdefiniowaną bramą zdalną.

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

Konfiguracja IPsec route-based

Route-based IPsec wyraźniej rozdziela negocjację VPN i routing. Sophos Firewall tworzy przy tym interfejs XFRM. Następnie trasy statyczne, SD-WAN Routes albo routing dynamiczny decydują, który ruch przechodzi przez tunel.

1. Utworzyć połączenie jako route-based

Menu path:

Site-to-site VPN > IPsec

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

Sophos pokazuje wygenerowany interfejs XFRM pod użytym interfejsem fizycznym w:

Network > Interfaces

Zależnie od projektu interfejs XFRM potrzebuje adresu IP. Szczególnie przy projektach Any-to-Any, wersji dual IP albo bardziej złożonych scenariuszach routingu adresacja interfejsu powinna być starannie zaplanowana. Interfejs XFRM pozostaje przypisany do strefy VPN; tego przypisania strefy nie wybiera się swobodnie jak przy zwykłych interfejsach fizycznych.

Gdy używa się Any-to-Any, sam Tunnel Selector nie decyduje już, który ruch przechodzi przez tunel. Wtedy trasy i reguły firewall stają się centralnym sterowaniem. To elastyczne, ale też podatne na błędy: zbyt szeroka reguła może dopuścić więcej ruchu niż planowano, a brakująca trasa może pokazywać tunel jako zielony bez przepływu ruchu użytkowego.

2. Ustawić routing

Przy VPN route-based samo połączenie IPsec nie wystarcza. Potrzebna jest trasa do sieci zdalnej:

• trasa statyczna do interfejsu XFRM
• SD-WAN Route z odpowiednim gateway albo profilem
• trasa dynamiczna przez BGP albo OSPF, jeśli projekt jest do tego zbudowany
• Jeśli obie podsieci są ustawione na Any, routing decyduje, jaki ruch trafia do tunelu.
• Jeśli używane są konkretne traffic selectors, muszą dokładnie pasować do peer.

1. Interfejs XFRM istnieje i znajduje się we właściwej strefie.
2. Trasa do sieci zdalnej wskazuje na interfejs XFRM.
3. Reguły firewall dopuszczają wymagany ruch między właściwymi strefami.

Dla prostych konfiguracji trasa statyczna często wystarcza. Jeśli używa się wielu łączy WAN, kontroli SLA albo ścieżek failover, sensowniejsza jest SD-WAN Route. Ogólny kontekst SD-WAN, Reply Packets i ruchu generowanego przez system opisuje sprawdzenie routingu SD-WAN Sophos Firewall dla Reply Packets i System Traffic.

3. Uwzględnić 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 trzeba sprawdzić MTU, MSS, fragmentację i rzeczywistą ścieżkę. Odpowiedni przebieg opisuje sprawdzenie MTU i MSS w Sophos Firewall przy problemach VPN.

Tworzenie reguł firewall

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ć.

Menu path:

Rules and policies > Firewall rules

Typowe reguły:

• Sieć lokalna do sieci zdalnej: LAN do VPN albo zone docelowej.
• Sieć zdalna do lokalnej sieci serwerowej: VPN albo XFRM zone do Server.
• Management albo Monitoring: tylko zdefiniowane systemy admin albo monitoring.
• DNS, AD, RDP, HTTPS: tylko wymagane usługi, nie ogólne Any.

Dobra praktyka:

• Nazwa reguły z tunelem albo lokalizacją, na przykład LAN_to_Branch_Zurich.
• Ustawić Source i Destination możliwie wąsko.
• Konkretnie zdefiniować Services.
• Włączyć logging podczas wdrożenia i troubleshooting.
• Sprawdzić pozycję reguły.
• Funkcje ochronne ustawić świadomie, zamiast przejmować je przypadkowo.

Jeśli ruch internetowy oddziału ma przechodzić przez centralę, potrzebna jest dodatkowo świadoma koncepcja NAT i bezpieczeństwa. To inny projekt niż proste połączenie lokalizacji dla sieci wewnętrznych.

Świadomie zaplanować NAT

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

• Przy nakładających się sieciach NAT często nie jest opcją, lecz elementem projektu tunelu.
• Przy route-based Any-to-Any routing i reguły firewall silniej decydują, jaki ruch trafia do tunelu.
• Przy policy-based IPsec i route-based VPN z traffic selectors NAT zmienia adresy, zanim zostaną porównane z selectors.

Menu path:

Rules and policies > NAT rules

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

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

Dla szczególnych przypadków policy-based z NAT może być istotna ręczna IPsec Route na Sophos Firewall. Nie jest to jednak standardowy krok dla każdego tunelu.

Device Access i dostęp WAN

Dla przychodzących zapytań IPsec firewall musi móc przyjmować ruch IPsec na właściwej zone WAN. Nie rozwiązuje się tego zwykłą regułą LAN-to-WAN, lecz przez lokalne usługi firewalla.

Menu path:

Administration > Device access

Tam IPsec musi być dozwolony dla wymaganej zone. Jednocześnie należy sprawdzić, czy inne lokalne usługi, takie jak WebAdmin, SSH, User Portal albo VPN Portal, nie są osiągalne zbyt szeroko. Do utwardzenia tych lokalnych usług centralnym artykułem jest zabezpieczenie dostępu do Sophos Firewall: poprawna konfiguracja Device Access.

Test tunelu

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

Zdefiniować macierz odbioru

Przed pierwszym testem należy przygotować małą macierz odbioru. Dzięki temu wiadomo, które połączenie ma działać, a które połączenie celowo nie powinno 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ć źródło, 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 albo 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 warto zanotować source IP, destination IP, usługę, oczekiwaną regułę firewall, oczekiwaną regułę NAT i oczekiwany kierunek. Po każdym teście porównuje się Log Viewer, Packet Capture i liczniki bajtów. Jeśli testowany jest tylko ping, tunel nie został jeszcze odebrany.

1. Sprawdzić status

W interfejsie WebAdmin:

Site-to-site VPN > IPsec

Sprawdzić:

• Połączenie jest aktywne.
• Status tunelu jest established.
• Przy wielu sieciach wszystkie oczekiwane Child SAs są zestawione.
• Nie widać powtarzających się reconnects ani błędów.

2. Sprawdzić Log Viewer

Menu path:

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 albo inne moduły wpływają na ruch.

3. Użyć Packet Capture

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

Diagnostics > Tools > 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 albo strony zdalnej.

4. CLI używać tylko celowo

Do głębszej analizy można użyć Advanced Shell przez SSH:

ipsec statusall

Interesujące są między innymi:

• IKE SA established
• Child SA installed
• sieci lokalne i zdalne
• liczniki bajtów w obu kierunkach
• powtarzające się komunikaty rekey albo disconnect

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

Typowe błędy

• Tunel się nie zestawia: wersja IKE, profil, PSK, certyfikat, Local ID albo Remote ID nie pasuje. strongswan.log, profil IPsec, strona zdalna.
• Phase 1 działa, Phase 2 nie: sieci lokalne/zdalne albo Phase 2 proposal nie pasują. Traffic Selectors, subnety, PFS.
• Tunel jest zielony, ale brak dostępu: brakuje reguły firewall, NAT, routingu albo ścieżki powrotnej. Log Viewer, Packet Capture, routing.
• Działa tylko jeden kierunek: strona zdalna nie zna trasy powrotnej albo NAT jest błędny. strona zdalna, reguły NAT, liczniki bajtów.
• Małe pingi działają, aplikacje wiszą: MTU/MSS, fragmentacja albo Security Feature. sprawdzić MTU/MSS, Packet Capture.
• Tunel route-based działa niejasno: interfejs XFRM, trasa albo SD-WAN Route nie pasuje. Network > Interfaces, routing, SD-WAN.
• Kilka tuneli wpływa na siebie: nakładające się sieci albo podobna konfiguracja Selector. obiekty tunelu, failover group, trasy.

Lista kontrolna

Przed zmianą:

• Sieci lokalne i zdalne są jednoznaczne.
• Policy-based albo route-based wybrano świadomie.
• Profil IPsec jest uzgodniony ze stroną zdalną.
• Preshared Key albo certyfikaty są bezpiecznie udokumentowane.
• Reguły firewall są zaplanowane, wraz z kierunkiem, pozycją reguły, logging i usługami.
• Przy Create firewall rule wiadomo, które automatycznie utworzone reguły trzeba poprawić.
• Przy route-based Any-to-Any zaplanowano ręczne reguły firewall i trasy.
• NAT jest wykluczony albo świadomie udokumentowany.
• Device Access dla IPsec został sprawdzony.
• Okno serwisowe, strona zdalna i ścieżka fallback są znane.

Po zmianie:

• Status tunelu jest established.
• 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.
• Macierz odbioru z co najmniej jednym testem dla każdego wymaganego kierunku zdefiniowana.

Częste pytania