Sophos Firewall: routing SD-WAN dla Reply Packets i System Traffic

Trasy SD-WAN w Sophos Firewall mają znaczenie nie tylko dla klasycznego ruchu klient-internet. W zależności od środowiska mogą obejmować także Reply Packets i ruch generowany przez system. To właśnie w tych przypadkach często pojawiają się trudne do wykrycia problemy z routingiem: reguła wygląda poprawnie, Gateway jest aktywny, ale odpowiedzi wracają niewłaściwą ścieżką albo sama zapora nie dociera do usługi przez oczekiwane łącze.

Ten przewodnik wyjaśnia dwie opcje CLI, reply-packet i system-generate-traffic, wskazuje, kiedy należy je sprawdzić, oraz pokazuje, jak bezpiecznie testować zmiany. Przy standardowej konfiguracji trasy SD-WAN warto zacząć od artykułu Konfiguracja i testowanie trasy SD-WAN w Sophos Firewall. Ogólną kolejność tras statycznych, SD-WAN Policy Routes i tras VPN opisuje także artykuł Bezpieczna zmiana Route Precedence w Sophos Firewall.

⚠️ Te ustawienia mogą natychmiast wpłynąć na routing produkcyjny. Przed zmianą należy udokumentować bieżący stan, wybrać okno serwisowe i przygotować jednoznaczną drogę powrotu. Szczególnie ryzykowne są szerokie trasy SD-WAN z Any, Route Precedence ustawione przed Static Routes oraz aktywny routing SD-WAN dla System Traffic lub Reply Packets.

Podstawy i ograniczenia

Do czego służą obie opcje

W przypadku tras SD-WAN trzeba rozróżnić zwykły ruch przekazywany, pakiety odpowiedzi oraz ruch generowany przez samą zaporę. Obie opcje nie określają, czy konkretna trasa SD-WAN jest skonfigurowana poprawnie. Rozszerzają natomiast zakres typów ruchu, które mogą zostać uwzględnione przez SD-WAN Policy Routing.

Opcje pełnią różne funkcje:

• reply-packet: Dotyczy pakietów odpowiedzi należących do istniejącego ruchu. Pozwala wpływać przez SD-WAN na drogę powrotną w określonych scenariuszach poza WAN.
• system-generate-traffic: Dotyczy ruchu generowanego przez samą zaporę. Umożliwia kierowanie połączeń zapory przez zdefiniowane trasy SD-WAN.

Nie należy włączać obu opcji bez analizy tylko dlatego, że „SD-WAN nie działa”. Najpierw trzeba ustalić, czy problem rzeczywiście dotyczy Reply Packets lub ruchu generowanego przez system. W przypadku zwykłych połączeń faktyczną przyczyną często jest Firewall Rule, NAT, Route Precedence, status Gateway albo zbyt szeroka trasa SD-WAN.

Reply Packets

Reply Packets to pakiety odpowiedzi należące do istniejącego ruchu. Sophos Firewall zasadniczo wymusza dla takich odpowiedzi routing symetryczny na interfejsach WAN: pakiety odpowiedzi powinny wracać przez ten sam interfejs WAN, przez który nadeszło pierwotne połączenie.

Opcja reply-packet ma znaczenie przede wszystkim wtedy, gdy pakiety odpowiedzi w określonych scenariuszach mają być uwzględniane przez SD-WAN Policy Routing. Typowym przykładem jest routing asymetryczny na interfejsach innych niż WAN, na przykład między LAN i DMZ.

Istotne ograniczenie: jeśli pierwotny ruch przechodzi przez Default Route lub WAN Link Load Balancing, trasy SD-WAN nie mają zastosowania do tych Reply Packets. Zapora nadal korzysta wtedy z właściwej drogi powrotnej przez interfejs pierwotnego połączenia.

Typowe pytania kontrolne:

• Czy jest to rzeczywiście ruch odpowiedzi, a nie nowe połączenie?
• Czy ruch przechodzi przez WAN, LAN, DMZ, XFRM lub inną strefę?
• Czy istnieje trasa SD-WAN, która ma celowo wpływać na drogę powrotną?
• Czy trasa jest zbyt szeroka, na przykład ma Destination Any?
• Czy Route Precedence powoduje dopasowanie przed trasą statyczną lub trasą VPN?

Ruch generowany przez system

Ruch generowany przez system to ruch tworzony przez samą Sophos Firewall. W zależności od środowiska może obejmować zapytania DNS, pobieranie sygnatur, zapytania uwierzytelniające, DHCP, NTP, Syslog lub połączenia z Sophos Central. Domyślnie ruch ten korzysta z aktywnych bram WAN skonfigurowanych w Network > WAN link manager.

Dla tego ruchu wartości Incoming interface i Source networks nie są znane, dlatego nie są odpowiednimi selektorami. W trasie SD-WAN przeznaczonej dla ruchu zapory należy więc precyzyjnie ograniczać wyłącznie Destination networks i Services, a pozostałe kryteria pozostawić szerokie. Trasa z Destination Any może w przeciwnym razie nieoczekiwanie skierować ruch systemowy i administracyjny na niewłaściwą ścieżkę.

Zwykła reguła zapory nie jest tu wymagana. Dlatego w Current activities > Live connections ruch generowany przez system ma Firewall Rule ID 0. Jeśli potrzebny jest określony Source IP, zwykła reguła SNAT również nie wystarczy: reguły NAT tłumaczą ruch przekazywany, natomiast dla ruchu zapory, zależnie od scenariusza, wymagane jest sys-traffic-nat w Device Console.

Obowiązują również dwa praktyczne ograniczenia:

• Jeśli wszystkie skonfigurowane Gateway w Network > WAN link manager są oznaczone tylko jako Backup, zapora nie przekazuje przez nie ruchu generowanego przez system. Co najmniej jeden Gateway musi mieć status Active.
• Generowany przez system ruch RED na UDP 3410 jest ruchem warstwy 2. Trasy SD-WAN nie mają do niego zastosowania.

Przygotowanie

Kiedy należy sprawdzić te ustawienia

Obie opcje mają znaczenie przede wszystkim w bardziej złożonych projektach routingu. W prostych środowiskach z jednym WAN rzadko powinny być pierwszym elementem do zmiany.

Uzasadnione powody do weryfikacji:

• Ruch generowany przez zaporę nie korzysta z oczekiwanej ścieżki WAN lub VPN.
• Syslog, Central, DNS, NTP lub Monitoring ma przechodzić przez określone łącze.
• Route-based IPsec VPN z interfejsami XFRM jest używany razem z trasami SD-WAN.
• VoIP lub inny wrażliwy ruch przez SD-WAN/VPN działa tylko w jednym kierunku.
• Packet Capture pokazuje odpowiedzi na innym interfejsie niż oczekiwany.
• Po aktualizacji SD-WAN, IPsec lub NAT zachowuje się inaczej niż wcześniej.
• Szeroka trasa SD-WAN nagle wpływa na sieci wewnętrzne lub dostęp administracyjny.

W scenariuszach IPsec warto dodatkowo skorzystać z artykułu Rozwiązywanie problemów z IPsec VPN w Sophos Firewall. W przypadku pojedynczego połączenia lepszym punktem wyjścia jest często Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Wyświetlanie bieżącego stanu

Polecenia wykonuje się w Device Console, a nie w Advanced Shell. Jeśli sposób dostępu do konsoli nie jest jeszcze znany, pomocny będzie artykuł Łączenie z Sophos Firewall przez SSH.

Sprawdzenie statusu dla Reply Packets:

show routing sd-wan-policy-route reply-packet

Sprawdzenie statusu dla ruchu generowanego przez system:

show routing sd-wan-policy-route system-generate-traffic

Dodatkowo WebAdmin w Routing > SD-WAN routes, w podpowiedzi dotyczącej informacji o routingu, pokazuje, czy routing SD-WAN jest aktywny dla ruchu generowanego przez system i Reply Packets.

Należy także udokumentować bieżące Route Precedence:

system route_precedence show

Przed każdą zmianą należy zapisać aktualne wyniki poleceń. Jest to ważne, ponieważ późniejszy rollback można przeprowadzić poprawnie tylko wtedy, gdy znany jest wcześniejszy stan.

Zmiana konfiguracji

Włączanie i wyłączanie opcji

Włączenie routingu SD-WAN dla Reply Packets:

set routing sd-wan-policy-route reply-packet enable

Włączenie routingu SD-WAN dla ruchu generowanego przez system:

set routing sd-wan-policy-route system-generate-traffic enable

Następnie należy ponownie wykonać polecenia sprawdzające status i udokumentować ich wynik.

Do selektywnego wyłączenia służą polecenia odwrotne:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ Nie należy wykonywać kilku zmian routingu jednocześnie. Jeśli Route Precedence, trasa SD-WAN, reguła NAT i te opcje CLI zostaną zmienione równocześnie, późniejsze jednoznaczne ustalenie przyczyny błędu będzie bardzo trudne.

Bezpieczny przebieg zmiany

Pragmatyczna procedura ogranicza ryzyko:

1. Dokładnie zdefiniuj analizowany ruch: Source, Destination, Service, Zone i oczekiwany Gateway.
2. Udokumentuj istniejące trasy SD-WAN, Gateway oraz Route Precedence.
3. Sprawdź, czy Destination Any jest rzeczywiście potrzebne.
4. Udokumentuj bieżący stan reply-packet i system-generate-traffic.
5. Zmień tylko jedną opcję.
6. Przeprowadź test na jednoznacznym przykładzie ruchu.
7. Sprawdź Log Viewer, Packet Capture i liczniki Gateway.
8. Udokumentuj wynik i dopiero potem wprowadzaj kolejne zmiany.

Jeśli zmiana może wpłynąć na dostęp administracyjny, należy przygotować drugą możliwość dostępu: lokalną konsolę, inną wewnętrzną ścieżkę dostępu lub połączenie z nieobjętej zmianą sieci administracyjnej.

Walidacja po zmianie

Po włączeniu opcji zielony status Gateway nie wystarcza. Trzeba sprawdzić, czy oczekiwany ruch rzeczywiście korzysta z właściwej ścieżki.

Live Connections, Log Viewer i liczniki SD-WAN

Dla ruchu przekazywanego należy sprawdzić w Log viewer zdarzenia związane z Firewall i SD-WAN. W odpowiednich Firewall Rules musi być aktywne Log firewall traffic. Ruch generowany przez system nie jest natomiast sterowany przez regułę zapory. Można go rozpoznać w Current activities > Live connections po Firewall Rule ID 0 oraz interfejsach Inbound i Outbound.

Należy sprawdzić:

• Czy jest to ruch przekazywany z Firewall Rule ID, czy System Traffic z ID 0?
• Jaki NAT Rule ID jest używany dla ruchu przekazywanego?
• Jaki Gateway lub interfejs pojawia się w logu?
• Czy występują Drops, naruszenia Policy lub nieoczekiwane decyzje Security Feature?
• Czy trasa SD-WAN pokazuje tylko OUT dla Requests, czy również IN dla Replies? Liczniki pojawiają się tylko wtedy, gdy kryteria Source i Destination pasują do danego kierunku.

Packet Capture

Rzeczywisty przepływ pakietów można sprawdzić w Diagnostics > Packet capture. Przy analizie routingu filtr powinien być precyzyjny: Source IP, Destination IP, Port i Protocol.

Istotne jest porównanie:

• Czy pakiet dociera przez oczekiwany interfejs?
• Czy opuszcza zaporę przez oczekiwany interfejs?
• Czy odpowiedź wraca?
• Czy stosowany jest NAT?
• Czy droga powrotna dla Reply Packets jest logiczna?

Obsługę i interpretację opisuje artykuł Korzystanie z Packet Capture w WebAdmin Sophos Firewall.

Sprawdzanie usług systemowych

W przypadku ruchu generowanego przez system należy przetestować konkretną usługę:

• DNS: Wykonaj DNS lookup na zaporze i sprawdź ścieżkę do celu.
• NTP: Sprawdź status czasu i dostępność serwera NTP.
• Syslog: Zweryfikuj wiadomość testową lub aktualny log na Collector.
• Sophos Central: Sprawdź połączenie z Central i Reporting.
• Monitoring: Sprawdź SNMP, sFlow lub zewnętrzne kontrole po stronie Collector.

Jeśli ruch generowany przez system nie jest widoczny, należy sprawdzić, czy trasa nie wymaga niepotrzebnie kryteriów Source networks, Incoming interface, User lub Application. Dla ruchu generowanego przez zaporę decydujące powinny być przede wszystkim Destination networks i Services. Jeśli system docelowy oczekuje określonego adresu źródłowego, należy dodatkowo sprawdzić Source IP i ewentualną konfigurację sys-traffic-nat.

Błędy i zależności

Typowe błędy

• Trasa SD-WAN z Destination Any dla ścieżek wewnętrznych: Ruch wewnętrzny lub dostęp administracyjny może zostać skierowany przez WAN. Lepsze są grupy celów internetowych lub konkretne sieci docelowe.
• Route Precedence ustawia SD-WAN przed Static: Bezpośrednio podłączone lub statyczne sieci mogą zostać nieoczekiwanie dopasowane przez SD-WAN. Należy sprawdzić Route Precedence i w razie potrzeby ustawić Static przed SD-WAN.
• Aktywne system-generate-traffic bez ograniczenia celu: Usługi zapory mogą korzystać z niewłaściwej ścieżki. Należy więc precyzyjnie określić Destination networks i Services.
• Reply Packets pomylone ze zwykłymi nowymi połączeniami: Analizowana jest wtedy niewłaściwa przyczyna. Należy sprawdzić Packet Capture i kierunek Flow.
• Poszukiwanie Firewall Rule dla ruchu generowanego przez system: Ten ruch ma Firewall Rule ID 0; zwykłe reguły zapory nim nie sterują. Należy sprawdzić Route, Service, Live Connection i w razie potrzeby sys-traffic-nat.
• Traktowanie Direct Web Proxy jak zwykłego ruchu HTTP/HTTPS: W przypadku bezpośredniego Proxy trasa SD-WAN musi obejmować port skonfigurowany w Web > General settings > Web proxy listening port. Alternatywnie Services może mieć wartość Any. Source Network i Incoming Interface nie dopasowują Reply Packets ruchu Proxy; dla drogi powrotnej potrzebny jest co najmniej jeden WAN-Gateway lub odpowiednia trasa statyczna.
• Kilka zmian routingu jednocześnie: Przyczyna błędu pozostaje niejasna. Zmiany należy wprowadzać etapami i dokumentować każdy test.
• Brak alternatywnego dostępu administracyjnego: Dostęp do WebAdmin lub SSH z objętej zmianą sieci może zostać utracony. Należy przygotować okno serwisowe i inną ścieżkę dostępu.

Szczególnie duże ryzyko powstaje przy połączeniu kilku warunków: Route Precedence ustawia SD-WAN przed Static, szeroka trasa SD-WAN korzysta z Any, a routing SD-WAN dla ruchu generowanego przez system lub Reply Packets jest aktywny. W takim przypadku można utracić dostęp do WebAdmin lub SSH z określonych podsieci wewnętrznych.

Współdziałanie z NAT, IPsec i VoIP

SD-WAN rzadko jest jedynym elementem problemu. W wielu awariach znaczenie mają również NAT, IPsec lub ruch specyficzny dla aplikacji.

W przypadku SNAT istotne jest, czy ten sam Source IP zostaje zachowany przy różnych Gateway. Jeśli używany jest MASQ lub różne przetłumaczone adresy źródłowe, Failover lub Rerouting może prowadzić do problemów z komunikacją. Podstawy opisuje artykuł Jak działa NAT w Sophos Firewall.

W przypadku route-based IPsec VPN interfejsy XFRM mogą być używane w SD-WAN Routes lub SD-WAN Profiles. Należy wtedy łącznie sprawdzić status IPsec, trasę SD-WAN, Route Precedence i reguły zapory. Podstawy route-based VPN przedstawia artykuł Trasa IPsec w Sophos Firewall.

Przy problemach z VoIP warto dodatkowo przeanalizować SIP, RTP, NAT i SD-WAN. Release Notes dla SFOS 22.0 MR1 dokumentują naprawiony problem, w którym po aktualizacji do SFOS 22.0 GA dźwięk VoIP przez route-based VPN z routingiem SD-WAN działał tylko w jednym kierunku. Praktyczną procedurę zawiera artykuł Rozwiązywanie problemów VoIP z SIP i RTP w Sophos Firewall.

Rollback i zakończenie

Rollback

Przed zmianą należy udokumentować wcześniejszy stan. Jeśli po zmianie problem dotyczy dostępu administracyjnego, usług systemowych lub ruchu produkcyjnego, nie należy dalej improwizować. Najpierw trzeba przywrócić poprzedni stan.

W praktyce oznacza to:

1. Przywróć udokumentowane wcześniejsze wartości reply-packet i system-generate-traffic za pomocą odpowiednich poleceń enable lub disable.
2. Przywróć wcześniejszą kolejność Route Precedence, jeśli została zmieniona.
3. Tymczasowo wyłącz zbyt szerokie trasy SD-WAN lub ogranicz je do konkretnych celów.
4. Przetestuj dostęp administracyjny z sieci nieobjętej problemem.
5. Dopiero potem kontynuuj zawężanie właściwej przyczyny.

Jeśli dostęp do WebAdmin i SSH z jednej podsieci wewnętrznej zostanie utracony, ale z innej nadal działa, należy z niej najpierw sprawdzić szeroką trasę SD-WAN, Route Precedence i obie opcje CLI.

Lista kontrolna

• Udokumentowano bieżący stan obu opcji CLI.
• Udokumentowano Route Precedence za pomocą system route_precedence show.
• Dokładnie zdefiniowano analizowany ruch.
• Dla System Traffic użyto tylko Destination i Service jako decydujących kryteriów dopasowania.
• Trasa SD-WAN nie została niepotrzebnie rozszerzona za pomocą Any.
• Sprawdzono Route Precedence.
• Co najmniej jeden WAN-Gateway dla System Traffic ma status Active.
• Przygotowano alternatywne połączenie administracyjne.
• W każdym teście wprowadzano tylko jedną zmianę.
• Do walidacji użyto Log Viewer i Packet Capture.
• Sprawdzono również NAT, IPsec i reguły zapory.
• Wynik i rollback udokumentowano w dzienniku operacyjnym.

FAQ