Połączenie Sophos Firewall z Azure VPN Gateway

Azure VPN Gateway łączy lokalną sieć z Azure Virtual Network przez Site-to-Site IPsec. Na Sophos Firewall zwykle buduje się to jako route-based IPsec VPN. W większych lub bardziej dynamicznych środowiskach dochodzi BGP.

Artykuł opisuje praktyczny przepływ z SFOS 22 i aktualnym Azure VPN Gateway: wymagane obiekty Azure, konfigurację po stronie Sophos, świadome dopasowanie parametrów IPsec/IKE i sprawdzenie, czy po zapisie ruch naprawdę działa. Dla ogólnych podstaw IPsec najpierw pasuje konfiguracja Sophos Firewall Site-to-Site IPsec VPN. Jeśli istniejący tunel jest zielony, ale nie przenosi ruchu, pasuje Sophos Firewall IPsec VPN Troubleshooting.

Kiedy ten artykuł pasuje

Artykuł pasuje, gdy lokalna sieć za Sophos Firewall ma zostać połączona z Azure Virtual Network. Chodzi o tunel Site-to-Site między Azure VPN Gateway i lokalnym firewallem, nie o Point-to-Site VPN dla pojedynczych użytkowników ani Sophos Firewall jako appliance w Azure.

Typowe scenariusze:

• lokalna sieć serwerowa do Azure VMs
• oddział lub główna lokalizacja do Azure Virtual Network
• scenariusz hybrydowy z AD, DNS, backupem, monitoringiem lub managementem w Azure
• migracja z policy-based design do route-based IPsec
• opcjonalne BGP dla dynamicznego routingu między siecią lokalną i Azure

Azure i Sophos nie zawsze używają tych samych nazw. W Azure są to Virtual network, Gateway subnet, Virtual network gateway, Local network gateway i Connection. Na Sophos Firewall: połączenie IPsec, interfejs XFRM, trasy, reguły firewall i opcjonalnie BGP.

Zaplanować przed konfiguracją

Tunelu Azure nie należy traktować jak samego kreatora kliknięć. Większość błędów wynika z nakładających się sieci, złej SKU gateway, niezgodnych parametrów IPsec/IKE, brakujących tras albo reguł firewalla bez rejestrowania ruchu.

Sieci i przestrzenie adresowe

Sieci lokalne i Azure address spaces nie mogą się nakładać. Azure kieruje lokalne prefiksy wpisane w Local network gateway do Sophos Firewall. Sophos Firewall kieruje prefiksy Azure przez interfejs XFRM albo BGP.

Wcześniej udokumentować:

• Azure Virtual Network Address Space, na przykład 10.50.0.0/16
• subnety Azure, zwłaszcza workload subnets
• lokalna sieć za Sophos Firewall, na przykład 172.16.10.0/24
• publiczny IP Sophos Firewall lub routera upstream
• Azure Public IP Virtual Network Gateway
• BGP tak lub nie
• wspólny Preshared Key
• planowane systemy testowe po obu stronach

Jeśli sieci lokalne i Azure się nakładają, najpierw poprawić design. NAT over IPsec jest możliwy, ale utrudnia eksploatację i troubleshooting.

Route-based zamiast policy-based

Dla Azure właściwym wyborem jest route-based IPsec. Aktualne SKU VpnGw*AZ są route-based; prawdziwy gateway policy-based istnieje tylko w ograniczonej SKU Basic z IKEv1. Route-based Azure gateway może użyć Use policy based traffic selectors dla lokalnego firewalla policy-based, ale jest to tryb zgodności wymagający selektorów dla każdej kombinacji prefiksów. W SFOS 22 tunel route-based z XFRM jest czytelniejszy i wymagany dla BGP, active-active oraz Azure NAT.

Na Sophos Firewall oznacza to:

• zaplanować połączenie IPsec jako route-based tunnel interface;
• sprawdzić interfejs XFRM po zapisie;
• ustawić trasy lub BGP dla prefiksów Azure;
• utworzyć reguły firewall między lokalnymi strefami i strefą VPN;
• sprawdzić ruch w Log Viewer i status Azure connection.

Zielony status tunelu to tylko część odbioru. Tunel jest naprawdę sprawdzony dopiero, gdy określony klient osiąga określony cel Azure i obie strony pokazują logi lub liczniki.

Nie zgadywać parametrów IPsec/IKE

Azure VPN Gateway obsługuje custom IPsec/IKE policies na VpnGw1–VpnGw5 i VpnGw1AZ–VpnGw5AZ, ale nie na Basic. Microsoft wymaga jednej kompletnej kombinacji na Connection. Przed zmianą profilu zapisać wdrożone wartości z Connection > Configuration i Profiles > IPsec profiles. Kompletna policy obejmuje szyfrowanie/integralność IKE i DH, szyfrowanie/integralność IPsec i PFS, czas życia SA i limit danych. Wybrać kombinację akceptowaną przez oba wdrożone systemy i zachować poprzednią policy do wycofania.

Dla eksploatacji:

• świadomie wybrać wersję IKE, zwykle IKEv2;
• udokumentować encryption, integrity, DH group, PFS i lifetimes;
• porównać Azure Custom Policy i Sophos IPsec Profile;
• nie przenosić bez kontroli defaultów Sophos-to-Sophos na Azure;
• planować okno serwisowe i rollback po każdej zmianie policy.

Bez Custom Policy co najmniej jedna propozycja Sophos musi pasować do wdrożonej domyślnej policy Azure. Profile IPsec w SFOS 22 obsługują grupy DH 1, 2, 5, od 14 do 21 oraz od 25 do 31, ale nie grupę DH 24. Custom Policy może więc używać tylko wartości obsługiwanych przez oba wdrożone systemy. Udokumentowany profil wyjściowy to Microsoft Azure (IKEv2): porównać faktyczne propozycje z policy Connection i sprawdzić zestawienie oraz rekey. Sama nazwa profilu nie dowodzi zgodności.

Azure ustala lifetime IKE SA na 28 800 sekund; route-based Default Policy używa 27 000 sekund i 102 400 000 KB dla Quick Mode SA. Custom Policy określa te limity jawnie, a Microsoft dopuszcza inne lokalne SA lifetimes. SFOS nadal zaleca krótszą Key lifetime po stronie initiatora i lifetime fazy 2 krótszą od fazy 1, aby uniknąć kolizji rekey. Ponieważ tutaj inicjuje Sophos, należy zachować tę kolejność bez wymyślania uniwersalnych wartości i zaobserwować co najmniej jeden rekey.

Przygotować stronę Azure

Konfiguracja Azure składa się z kilku obiektów. Nazwy powinny być jednoznaczne, bo późniejszy troubleshooting szybko robi się nieczytelny.

Virtual Network i Gateway subnet

Azure Virtual Network potrzebuje dedykowanego GatewaySubnet. Ten subnet jest używany przez Azure VPN Gateway i nie może służyć dla normalnych VM.

Sprawdzić:

1. Azure Virtual Network istnieje.
2. Address Space nie nakłada się na sieci lokalne.
3. GatewaySubnet istnieje i ma wystarczający rozmiar. Poza Basic z minimum /29 aktualne SKU wymagają co najmniej /27; Microsoft zaleca więcej niż /27 na rozbudowę.
4. GatewaySubnet nie zawiera VM ani NSG. UDR 0.0.0.0/0 nie jest obsługiwana, a BGP route propagation musi pozostać aktywna.
5. Workload subnets i Network Security Groups pozwalają na wymagany ruch.

Utworzyć Virtual Network Gateway

Virtual network gateway to właściwy Azure VPN Gateway. Ważne:

• Gateway type: VPN
• VPN type: Route-based
• SKU pasująca do przepustowości, SLA, Availability Zone i wymagań BGP
• Public IP dla gateway
• Active-active tylko jeśli strona lokalna może zbudować dwa tunele do dwóch publicznych IP Azure
• BGP tylko jeśli ASN, peer IP i koncepcja routingu są ustalone

Dla nowych gateway używa się SKU VpnGw*AZ: VpnGw1AZ–VpnGw3AZ są dostępne jako Generation 1, a Generation 2 obejmuje VpnGw2AZ–VpnGw5AZ. Microsoft przeznacza VpnGw1–VpnGw5 do migracji i odradza Basic w produkcji. W Virtual network gateways > Create sprawdzić opcje SKU/generacji dla subskrypcji i regionu; przed utworzeniem zapisać wymaganą przepustowość, liczbę tuneli, funkcje BGP/NAT, limity i zgodę na koszty. Wskazane rodziny są ograniczeniami planowania, nie obietnicą wydajności lub dostępności.

W trybie active-active oba tunele IPsec należą do tej samej Azure Connection, ale każda instancja Azure ma własny publiczny IP. Sophos potrzebuje więc osobnego połączenia route-based i interfejsu XFRM dla każdego IP Azure. Routing musi obsługiwać ruch przez oba tunele i utratę każdego z nich; osobno sprawdzić zestawienie, obciążenie i failover każdego tunelu.

Utworzyć Local Network Gateway

Local network gateway opisuje stronę lokalną z perspektywy Azure.

Wpisać:

1. Nazwę, na przykład lng-sophos-hq.
2. Endpoint jako publiczny IP lub FQDN strony Sophos.
3. Local Address spaces: wszystkie lokalne prefiksy bez BGP; z BGP pole może pozostać puste. Prefiksy statyczne dodać tylko wtedy, gdy nie są uczone przez BGP.
4. W Advanced włączyć BGP i podać ASN oraz BGP Peer IP Sophos, jeśli używany jest routing dynamiczny.

Azure zwykle używa prywatnego adresu z GatewaySubnet jako peer BGP. Jeśli Sophos używa APIPA, Azure musi dostać unikalny adres z 169.254.21.0–169.254.22.255; lokalny może pochodzić z 169.254.0.1–169.254.255.254. Adresy nie mogą się nakładać, a Sophos musi inicjować sesję APIPA. Odczytać końcowe wartości w Virtual network gateway > Configuration, zapisać je w planie adresowym i porównać z Local Network Gateway oraz XFRM.

Jeśli Sophos Firewall stoi za NAT, trzeba dokładnie sprawdzić, jaki publiczny IP widzi Azure i jak lokalnie działają NAT-T, port forwarding oraz IDs. Prosty standard to Sophos Firewall z własnym publicznym IP.

Utworzyć Connection

Connection łączy Virtual Network Gateway i Local Network Gateway.

Ważne wartości:

• Connection type: Site-to-site (IPsec)
• Shared key: identyczny z Sophos Preshared Key
• IKE Protocol: zgodny z konfiguracją Sophos
• BGP: tylko jeśli obie strony używają BGP
• Custom IPsec/IKE policy: tylko jeśli wartości zostały świadomie zaplanowane
• Dla udokumentowanego przykładu Sophos-inicjator/Azure-responder: Virtual network gateways > [gateway] > Settings > Connections > [connection] > Configuration albo Add > Settings przy tworzeniu; Connection Mode: ResponderOnly, DPD timeout in seconds: pozostawić wartość domyślną. Zapisać wyświetloną wartość DPD i sprawdzić wdrożoną policy; nie podajemy uniwersalnego timeoutu. Połączyć z Initiate the connection na Sophos. W statycznej recepturze bez BGP Use Azure private IP address i Enable BGP pozostają wyłączone, a Use policy based traffic selector: Disable. Inne projekty sprawdzać osobno.

Po utworzeniu Connection strona Azure jest gotowa, ale nie automatycznie produkcyjna. Strona Sophos musi znać ten sam tunel, te same parametry i drogę powrotną.

Skonfigurować Sophos Firewall

Na Sophos Firewall tunel tworzy się w Site-to-site VPN > IPsec.

Przygotować IPsec profile

W Profiles > IPsec profiles użyć lub utworzyć profil pasujący do Azure. Zależności między polami Sophos i prawidłowe klonowanie własnego profilu wyjaśnia artykuł Zrozumienie i bezpieczna konfiguracja profili IPsec Sophos Firewall. Konkretne wartości nadal muszą dokładnie odpowiadać Azure default policy albo custom IPsec/IKE policy danej Connection.

Udokumentować:

• IKE version
• Phase 1 encryption i authentication
• DH group
• Phase 2 encryption i authentication
• PFS
• Key lifetime

Jeśli Azure używa Custom Policy, nazwa profilu powinna to pokazywać, na przykład Azure_IKEv2_AES256_G14.

Utworzyć route-based IPsec connection

Ścieżka:

Site-to-site VPN > IPsec

Kroki:

1. Otworzyć Add.
2. Wybrać Route-based albo tunnel interface jako typ połączenia.
3. Ustawić nazwę, na przykład azure-vnet-prod.
4. Gateway type po stronie Sophos zwykle ustawić na Initiate the connection.
5. Azure Public IP Virtual Network Gateway wpisać jako Remote Gateway.
6. Ustawić Preshared Key identyczny z Azure Connection.
7. Sprawdzić Local ID i Remote ID, zwłaszcza przy NAT lub wielu tunelach.
8. Wybrać IPsec profile.
9. Zapisać i aktywować połączenie.

Po zapisie sprawdzić interfejs XFRM w Network > Interfaces. Pozostaje przypisany do strefy VPN. Zależnie od designu używa się go ze statyczną trasą, SD-WAN route albo BGP.

Ustawić oba traffic selectors Sophos na Any. Firewall automatycznie tworzy wtedy numerowany interfejs xfrm. Dla Any-to-Any SFOS nie tworzy automatycznych reguł firewall. NAT-T jest zawsze aktywny; za upstream NAT muszą zgadzać się także IDs peerów.

Skonfigurować trasę lub BGP

Bez BGP użyć Download configuration w Azure Connection, aby pobrać parametry ogólne, a następnie przypisać do XFRM w Network > Interfaces wskazany pierwszy tunnel IP, netmask i MSS. W Routing > Static routes > IPv4 unicast route dodać każdy prefiks Azure przez ten interfejs. Gateway może pozostać pusty albo używać adresu peera z pobranej sieci transferowej. Z BGP przypisać do XFRM lokalny BGP peer IP i netmask wpisane w Local Network Gateway; neighbor Sophos to Azure BGP Peer IP z Virtual network gateway > Configuration. Nie wymyślać adresów transferowych.

Przy BGP obie strony muszą być starannie zaplanowane. Artykuł Konfiguracja BGP na Sophos Firewall wyjaśnia konfigurację podstawową, bezpieczne udostępnienie i odbiór; następnie dla Azure stosuje się wartości peerów określone przez Azure:

• lokalny ASN Sophos Firewall
• Azure ASN
• BGP peer IPs
• dozwolone i ogłaszane prefiksy
• route advertisement w Azure
• reguły firewall dla rzeczywistego ruchu

BGP nie zastępuje reguł firewall. Rozsyła tylko trasy. Dostępność serwera w Azure nadal zależy od routingu, NSG, reguł firewall i systemu docelowego.

Udokumentowany projekt Azure BGP używa IPv4. Lokalne ASN musi różnić się od ASN Azure i nie może być zarezerwowanym ASN Azure: 8075, 8076, 12076, 65515, 65517, 65518, 65519 ani 65520. W Administration > Device access zezwolić na Dynamic Routing dla strefy VPN. Następnie sprawdzić na Sophos, czy prefiksy Azure są rzeczywiście uczone, a w Azure w BGP peers, czy dotarły prefiksy lokalne.

Dla ruchu generowanego przez firewall najpierw sprawdzić rzeczywisty source IP, ogłaszane prefiksy i drogę powrotną. Jeśli źródło nie należy do lokalnego prefiksu routowanego przez Azure, może być potrzebne ukierunkowane mapowanie sys-traffic-nat na LAN IP firewalla; nie dodawać go tylko z powodu BGP. Kierowanie ruchu systemowego selektywnie przez IPsec opisuje pre-check, składnię Device Console, walidację i dokładne usunięcie.

NAT tylko jako decyzja projektowa

Azure NAT dla nakładających się sieci jest ograniczony do route-based S2S na VpnGw2–VpnGw5 i VpnGw2AZ–VpnGw5AZ, bez policy-based traffic selectors. Static NAT jest 1:1 i dwukierunkowy; dynamic NAT zachowuje stan i musi być inicjowany od Internal mapping. Z BGP włączyć BGP route translation; APIPA BGP nie działa z Azure NAT. Przed zmianami zapisać Internal/External mappings i przetłumaczone prefiksy, porównać je z efektywnymi trasami i prefiksami ogłaszanymi po obu stronach oraz przetestować dozwolone kierunki inicjowania. To ograniczenia projektowe, nie doraźna naprawa.

Utworzyć reguły firewall

Ruch przez tunel wymaga pasujących reguł, zwykle między strefą wewnętrzną i strefą VPN.

Zalecenia przy wdrożeniu:

• ustawić konkretne sieci lub hosty jako source i destination;
• wybrać konkretne usługi do pierwszego testu, na przykład ICMP, RDP, HTTPS lub DNS;
• aktywować Log firewall traffic;
• po pierwszym teście nie zostawiać reguł na Any;
• osobno sprawdzić kierunek odwrotny, jeśli Azure ma osiągać systemy lokalne.

Jeśli reguła nie pasuje, użyć Sophos Firewall: sprawdzanie, dlaczego reguła nie pasuje.

Sprawdzić połączenie

Odbiór powinien zawsze sprawdzać dwa poziomy: status tunelu i rzeczywisty ruch.

Sprawdzić Azure

W Azure:

1. Otworzyć Connection VPN Gateway.
2. Sprawdzić status połączenia.
3. Obserwować liczniki danych.
4. Sprawdzić effective routes właściwej Azure VM.
5. Sprawdzić Network Security Group docelowych subnetów.

Sam status Azure nie wystarcza. VM może być niedostępna mimo działającej Connection przez NSG, lokalny Windows Firewall, złą trasę lub brak drogi powrotnej.

Sprawdzić Sophos Firewall

Na Sophos Firewall:

1. Sprawdzić status w Site-to-site VPN > IPsec.
2. Skontrolować interfejs XFRM w Network > Interfaces.
3. Sprawdzić trasę do prefiksów Azure.
4. Filtrować Log Viewer według ruchu testowego.
5. W razie potrzeby użyć Packet Capture lub strongswan.log.

Dla logów IPsec i analizy CLI pasuje Sophos Firewall IPsec VPN Troubleshooting.

W Azure użyć VPN Gateway > Diagnostic settings z IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog i GatewayDiagnosticLog. Porównać znaczniki czasu Sophos i Azure dla tego samego testu. Reset bramy rozważać dopiero po tych kontrolach: uruchamia ponownie aktywną instancję i może przerwać istniejące połączenia.

Użyć realistycznego ruchu testowego

ICMP jest dobrym początkiem, ale nie pełnym testem. Następnie testować usługę produkcyjną:

• DNS do Azure DNS lub domain controller
• RDP albo SSH do testowej VM
• HTTPS do aplikacji wewnętrznej
• ruch backup, monitoring lub management

Źródło jest ważne. Ping bezpośrednio z firewalla nie dowodzi tego samego co test z klienta za firewallem.

Typowe błędy

Tunel pozostaje down

Najczęściej nie pasują gateway IP, wersja IKE, Preshared Key, IDs albo parametry IPsec/IKE. Na Sophos Firewall najpierw sprawdzić strongswan.log i porównać Azure Connection Settings z Sophos IPsec Profile. Jeśli kilka połączeń IPsec używa tych samych endpointów, sprawdzić również przypisanie PSK: IKEv2 obsługuje osobny PSK dla każdej kombinacji Local ID i Remote ID. IKEv1 obsługuje tylko jeden PSK dla danej kombinacji lokalnego i zdalnego gateway; SFOS stosuje wtedy PSK z połączenia skonfigurowanego jako ostatnie. Unikalne IDs z IKEv2 zapobiegają tej kolizji.

Tunel jest połączony, ale ruch nie płynie

Często brakuje tras, reguł firewall, reguł Azure NSG albo drogi powrotnej. Po stronie Sophos sprawdzić Log Viewer i trasę. Po stronie Azure Effective Routes i NSG.

Działa tylko jeden kierunek

To często wskazuje na routing asymetryczny, NSG, host firewall albo brak reguły odwrotnej. Testować oba kierunki osobno i dokumentować źródło ruchu testowego.

BGP nie uczy się tras

Sprawdzić ASN, peer IP, aktywację BGP, adres XFRM i konfigurację Azure BGP. Następnie sprawdzić, które prefiksy są naprawdę ogłaszane i uczone. Działający tunel IPsec nie oznacza automatycznie poprawnego routingu BGP.

Po zmianie policy tunel nie wraca

Custom IPsec/IKE Policies muszą być kompletne i kompatybilne. Jeśli Azure i Sophos inaczej interpretują jeden parametr, połączenie może się nie zestawić. Przed zmianami dokumentować aktualny profil, Azure Policy i działający stan.

Azure jest inicjatorem i child SA wygasa

Gdy Azure jest inicjatorem, wykonuje rekey wygasającego child SA tylko przy istniejącym ruchu w tunelu. Bez ruchu Azure usuwa child SA, ale faza 1 pozostaje aktywna. Późniejszy ruch z Azure może utworzyć nowy child SA; ruch rozpoczynający się wyłącznie za Sophos Firewall nie skłoni Azure do jego utworzenia w tym stanie. Dlatego Initiate the connection na Sophos pasuje do tego projektu. Rekey IKE SA w Azure może też spowodować krótką przerwę.

Rollback bez niszczenia stanu

Przed zmianą wyeksportować lub opisać połączenie Sophos, profil, adres XFRM, trasy i reguły oraz SKU/generację Azure, Connection, Shared Key, BGP i NAT. Nie usuwać działającej Connection: sklonować profil Sophos i zapisać policy Azure z Connection > Configuration lub PowerShell.

Po błędzie przypisać poprzedni profil Sophos i przywrócić dokładnie wcześniejszą Custom Policy Azure albo usunąć tylko nową, jeśli wcześniej działały defaults. Aktywować połączenie i powtórzyć testy tunelu, tras i aplikacji. Nie usuwać zapobiegawczo gateway, Local Network Gateway, XFRM, tras ani NAT, bo niszczy to znany stan i może zmienić publiczny IP lub routing.

FAQ