Konfigurera och testa SD-WAN-rutter i Sophos Firewall

29. OKTOBER 2026 Sophos Firewall

Med en SD-WAN-rutt styr du via vilken gateway ett definierat trafikflöde går i Sophos Firewall. Det är användbart med flera internetanslutningar, MPLS, route-based IPsec VPN, VoIP eller molntjänster. Rutten måste avgränsas noggrant och testas med verklig trafik, annars kan den omfatta interna nät eller använda fel publik IP-adress vid failover.

Om Sophos Fusion (tidigare Sophos Central) ska generera route-based tunnlar och vägar mellan platser för flera hanterade brandväggar passar Konfigurera och verifiera en SD-WAN-anslutningsgrupp i Sophos Fusion bättre. Den här artikeln förklarar den lokala SD-WAN-rutten, som också är viktig vid verifiering av centralt distribuerade vägar.

Kort svar

En SD-WAN-rutt skapas här:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Fyra punkter måste vara klara i förväg:

vilken trafik som ska matcha baserat på incoming interface, source, destination och service
vilken primary/backup gateway eller SD-WAN profile som ska användas
om endast dessa gateways är tillåtna och vilken NAT som passar
hur rutt, gateway och returväg verifieras med Log Viewer och Packet Capture

För publika IPv4-mål bör du inte generellt använda Any, utan om möjligt Internet IPv4 group eller specifika mål. Om SD-WAN ligger före Static i route precedence kan en bred Any-rutt annars även skicka intern trafik till WAN-gatewayen.

Videon kompletterar guiden för planering, konfiguration och verifiering av SD-WAN-rutter i Sophos Firewall.

Användning och planering

När SD-WAN passar bättre än en statisk rutt

En statisk rutt räcker när ett målnät alltid kan nås via en fast next hop. SD-WAN-rutter lägger till kriterier som source, service, användare eller applikation och kan välja gateways efter tillgänglighet eller kvalitet.

Typiska fall är:

styra vissa klienter eller tjänster via WAN2 och växla till WAN1 vid fel
skicka VoIP eller molnapplikationer via en väg med låg latens och liten paketförlust
använda MPLS, LTE/5G eller en route-based IPsec-tunnel som primär väg eller backup
binda trafik till en operatör vars publika IP-adress är tillåten hos en motpart

Planeringsexempel och förutsättningar

Beskriv ett konkret trafikflöde innan rutten skapas. För Microsoft 365-trafik kan planeringen se ut så här:

Incoming interface: internt LAN-interface
Source network: Client_Net_10.20.0.0_24
Destination: egen underhållen Microsoft 365-målgrupp eller Internet IPv4 group
Services: HTTPS och vid behov en servicegrupp för UDP 3478-3481
Primary gateway: WAN2
Backup gateway: WAN1
Fallback: tillåt default route eller aktivera Route only through specified gateways
NAT: MASQ eller fast SNAT-IP som passar vald gateway
Test: definierad klient-IP, mål, förväntad gateway och förväntad loggpost

Det krävs också lämpliga firewall-regler, NAT-regler för trafik som ska översättas, aktiverad firewall-logging samt åtkomst till Log viewer och Diagnostics > Packet capture. WAN-gateways finns under Network > WAN link manager; custom gateways för MPLS, RED eller XFRM skapas under Routing > Gateways.

Det allmänna Active/Backup-beteendet för den normala WAN-vägen beskrivs i Konfigurera WAN-failover i Sophos Firewall. Grunderna för gränssnitt och gateways finns i Konfigurera zoner och gränssnitt i Sophos Firewall.

Vid route-based IPsec är riktningen viktig: Ett XFRM-interface som Incoming interface matchar trafik som kommer in från tunneln. För LAN-till-VPN-trafik väljer du i stället gatewayen för XFRM-interfacet som primary gateway eller i en SD-WAN profile. Grunderna finns i Skapa IPsec-route på Sophos Firewall.

För ett mer avgränsat Teams-exempel lägger du till den fiktiva gruppen Sales_Team under Users or groups och Teams_VoIP under Application objects. Ersätt båda namnen med den egna användargruppen och de applikationer som faktiskt behövs. Tillsammans med LAN-gränssnittet, Client_Net_10.20.0.0_24, avsedda mål och tjänster styr kriterierna endast det matchande flödet via WAN2/WAN1. Kontrollera separat en snäv tillåtelseregel från LAN till WAN för denna källa, dessa mål och tjänster, avsedd användarbehörighet och NAT på båda vägarna. SD-WAN-rutten ger ingen åtkomstbehörighet; testet måste bekräfta planerad användare, applikation, Firewall Rule ID och NAT ID.

Två WAN med motsatta prioriteringar

För LAN 10.20.0.0/24 ska utvalda publika mål i första hand gå via WAN1 och övriga publika IPv4-mål via WAN2. Båda förbindelserna fungerar som reserv för varandra. Detta planeringsexempel kompletterar SFOS-22-proceduren; SFOS-23-EAP-dokumentationen bekräftar profilmekanismen men godkänner inte godtyckliga byggen.

⚠️ Nya rutter och deras ordning ändrar datavägen. Dokumentera först ruttpositioner, On/Off-status, profilvärden, NAT och aktuell Route Precedence samt kontrollera en oberoende hanteringsåtkomst. Utför feltester endast under ett godkänt underhållsfönster; ta inte bort eller ändra delade gateways eller profiler för att simulera fel.

Skapa två separata profiler under Routing > SD-WAN profiles > Add med Routing strategy: First available gateway: Ziele_WAN1_WAN2 i ordningen WAN1, WAN2, och Internet_WAN2_WAN1 med WAN2, WAN1. Namn, LAN och gateways är anpassningsbara exempelvärden. Aktivera Health check i båda; låt SLA vara av för detta val baserat enbart på tillgänglighet. Välj sondmål, protokoll och räknare enligt hälsokontrollproceduren nedan, inte genom att blint acceptera standardvärden. Målen måste även kunna upptäcka fel bortom operatörens gateway, inte bara dess lokala nåbarhet.
Skapa den specifika rutten LAN_Ziele_WAN1 under Routing > SD-WAN routes > IPv4 > Add: Incoming interface är det verkliga LAN-gränssnittet, Source networks objektet för 10.20.0.0/24, Destination networks den underhållna gruppen utvalda publika mål och Services endast nödvändiga tjänster. Välj Ziele_WAN1_WAN2. Beakta först begränsningarna för FQDN-värdar och FQDN-grupper vid domäner; ett domännamn garanterar inget exklusivt IP-målområde.
Skapa LAN_Internet_WAN2 nedanför med samma LAN-gränssnitt och källnät, Destination networks: Internet IPv4 group, godkända internettjänster och Internet_WAN2_WAN1. Den specifika rutten måste ligga ovanför den allmänna internetrutten. Använd ingen global Any-rutt; interna mål och VPN-mål hör inte till denna internetväg.
Ställ medvetet in Route only through specified gateways för båda rutterna: alternativet är på här så att ingen annan väg tar över om båda avsedda vägar fallerar. Kontrollera separat för båda WAN-förbindelserna att lämpliga brandväggsregler tillåter trafiken och att MASQ/SNAT är korrekt konfigurerat. Om motparten kräver en fast publik IP måste även reserv-IP:n vara tillåten där.

Skapa vid verifieringen en ny anslutning till ett specifikt och ett övrigt publikt mål: inledningsvis förväntas WAN1 respektive WAN2. Testa sedan båda uppströmsfelen separat i en godkänd testmiljö, även med fortsatt aktivt fysiskt gränssnitt: fallerar WAN1 ska nya anslutningar för båda målklasserna fungera via WAN2; fallerar endast WAN2, via WAN1. Jämför efter varje återställning nya anslutningar med avsedd prioritet och observera befintliga sessioner separat. Belägg rutt, gateway och SNAT/publik IP i loggar eller Packet Capture och kontrollera DNS, HTTPS och intern hanteringsåtkomst igen. Detta innebär ingen fast omkopplingstid eller avbrottsfri övergång för befintliga sessioner.

Bredda inte kriterierna om vägen är oväntad: jämför först ruttmatchningar, ordning, hälsostatus och NAT. Inaktivera de nya rutterna eller återställ tidigare dokumenterade rutt-, profil- och NAT-värden inklusive ordningen för återgång; kontrollera sedan status och båda testflödena igen. Utan en isolerbar felsimulering förblir denna del av verifieringen öppen. Detaljerade sessions- och SNAT-gränser finns nedan i avsnittet om Testa failover och failback säkert.

MPLS mellan filial och huvudkontor

Ett avgränsat exempel ansluter 10.20.0.0/24 i filialen till webbservrar i huvudkontorets nät 10.30.0.0/24: inkommande gränssnitt är filialens LAN, primary gateway är MPLS-1, backup är MPLS-2 och tjänsterna begränsas till nödvändiga TCP 80/TCP 443. Huvudkontorets brandvägg behöver motsvarande returrutt från 10.30.0.0/24 till 10.20.0.0/24 via sina egna MPLS-gateways. Nät, gränssnitt, gateways och tjänster är exempelvärden som anpassas till den verkliga topologin. Filialens separata brandväggsregel tillåter LAN till den faktiska MPLS-zonen, här MPLS_DMZ, endast för dessa nät och tjänster; huvudkontorets regler måste också tillåta det avsedda flödet. Den här routade designen behåller de ursprungliga privata adresserna utan SNAT. Det är ingen generell NAT-regel för alla MPLS-installationer. Kontrollera båda riktningarna och oförändrad käll-IP med verklig trafik på båda brandväggarna.

Konfigurera SD-WAN-rutten

Definiera matchningskriterier

Välj specifika mål-IP-värdar för IPv6 i stället för ett generellt mål Any. Om en generell Any-rutt måste finnas kvar skapar du ovanför den en rutt för de specifika mål-IP-värdarna och deras avsedda gateway; håll även incoming interface, source och services snäva. Dokumentera före en ändring den installerade ordningen med system route_precedence show, ruttens position och inställningar, kontrollera oberoende administrationsåtkomst och planera hur värdena ska återställas. En mer specifik rutt är inget skäl att återställa global route precedence blint.

Öppna Routing > SD-WAN routes.
Välj IPv4 eller IPv6 och klicka på Add.
Ange ett tydligt namn, till exempel Clients_M365_WAN2.
Välj det Incoming interface där trafiken som ska styras kommer in.
Välj vid behov ett DSCP-värde om inkommande paket är tillförlitligt märkta.
Definiera Source networks och lägg vid behov till Users or groups.
Begränsa Destination networks så mycket som möjligt.
Begränsa Services till nödvändiga protokoll och portar.
Välj vid behov Application objects.
Välj en SD-WAN profile eller primary/backup gateways under Link selection settings.
Aktivera eller inaktivera Route only through specified gateways medvetet.
Spara rutten och flytta den till rätt position; den första matchande SD-WAN-rutten vinner.
Testa med en definierad klient och ett definierat mål.

Application Objects kräver en aktiv Web Protection License. Den första anslutningen dirigeras utifrån destination IP, port, protokoll och incoming interface via en annan matchande SD-WAN-rutt eller annars via default route. Först efter applikationsidentifieringen gäller Application Object för efterföljande anslutningar. Klassificeringsdata har en TTL på 3600 sekunder från sessionsstart. För Micro Apps stöder endast DPI Engine Mode alla applikationer; Web Proxy Mode stöder bara Pattern Applications och Synchronized Security Applications.

I ett HA-kluster synkroniserar SFOS denna Application Routing-cache via den dedikerade HA-länken med multicast 226.1.1.1 på port 4455. En omstart av brandväggen rensar klassificeringsdata. Efter en omstart eller ett HA-problem kontrolleras därför inte bara tunnel- eller gatewaystatus; en första och en efterföljande applikationsanslutning skapas på nytt.

Skapa ett Application Object

DPI-motorn kan omklassificera en applikation inom samma anslutning, exempelvis vid byte från en webbplats till dess chatt. Det nya beslutet gäller efterföljande anslutningar och garanterar inte omdirigering av den pågående anslutningen. Om ingen ytterligare session startar inom TTL på 3600 sekunder från sessionsstart rensas de lagrade sessionsuppgifterna.

Application Objects kan innehålla webbapplikationer, micro apps, Synchronized Security Applications som upptäckts på endpoints, anpassade applikationer och applikationskategorier. Välj typ efter den identifiering som behövs och följ licens- och DPI/proxy-begränsningarna ovan; en hel kategori är bredare än en enskild applikation som behövs.

Ett Application Object grupperar endast de applikationer som ska använda samma SD-WAN-väg. Öppna Applications > Application object, välj Add, ange ett namn och begränsa resultaten med Category, Risk, Characteristics, Technology, Classification eller namnsökningen. Markera sedan de applikationer som faktiskt behövs och spara objektet. Sophos uppdaterar den tillgängliga applikationslistan dynamiskt genom IPS-uppdateringar och Synchronized Application Control; kontrollera därför urvalet igen efter ändringar av patterns eller applikationer.

Filtret Technology skiljer mellan browser-based, client-server, network protocol, P2P och synchronized application control. Under Classification finns new, sanctioned, unsanctioned och tolerated. Dessa kriterier gör urvalet enklare, men bevisar inte att den efterföljande rutten fungerar. För det krävs först klassificeringsanslutningen och därefter en ny testanslutning.

För Microsoft 365 är ett enda samlingsobjekt ofta för brett. Ett objekt som Teams_VoIP kan till exempel endast innehålla de Teams-applikationer som är avsedda för realtidskommunikation, medan OneDrive eller SharePoint använder en annan väg. Välj sedan det sparade objektet i fältet Application objects i SD-WAN-rutten.

Välj gateway eller SD-WAN profile

Primary/backup gateways räcker för en föredragen väg och en fallback. En SD-WAN profile skiljer mellan två val: Routing strategy väljer väg med First available gateway eller Load balancing, medan ett valfritt Service Level Agreement (SLA) lägger till kvalitetsmätningar. Best quality och Custom SLA är därför inte ytterligare två routingstrategier.

Konfigurera en SD-WAN profile under Routing > SD-WAN profiles > Add så här:

Ange namn och beskrivning och välj First available gateway eller Load balancing under Routing strategy.
Tilldela två till åtta gateways och ordna dem i önskad ordning genom att dra dem. Gateway weights visas bara vid load balancing; olika vikter kan motsvara olika länkkapacitet.
Välj Round-robin eller en lämplig Session persistence type för load balancing. Bindningen kan baseras på source IP, destination IP, source och destination eller en enskild anslutning.
Aktivera SLA endast om latens, jitter eller paketförlust ska påverka valet. Best quality jämför ett enda kriterium. Custom SLA kontrollerar latens, jitter och paketförlust mot de angivna gränsvärdena.
Aktivera Health check, välj Ping eller TCP under Protocol och ange upp till två Probe targets. För TCP anger du även en port där målet svarar tillförlitligt. SFOS tvingar Health Check att vara aktivt när SLA är aktiverat.
Anpassa Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after och Sample size for SLA till tjänsten. Inställningarna har olika uppgifter: Interval between checks och Response time-out styr proberna; Deactivate gateway after räknar misslyckade försök och Activate gateway after lyckade svar. Sample size for SLA anger antalet mätningar för gatewayens genomsnittliga prestanda. Anpassa avbrottsdetektering och återaktivering separat; de fem värdena är inte en gemensam failovertimer.
Spara profilen, välj den i SD-WAN-rutten och verifiera vägen med verklig trafik.

De två Probe Targets bildar ett gemensamt tillgänglighetstest: SFOS betraktar gatewayen som aktiv om minst ett mål svarar. Om det första slutar svara byter systemet till det andra och fortsätter använda det så länge det svarar. Att det första återkommer utlöser inte ensamt ett omedelbart byte tillbaka. Målen bör därför ligga bakom gatewayen och representera den relevanta vägen; en lyckad ping bevisar inte att DNS, TLS eller hela applikationen fungerar.

Med Best quality sker failback först när den ursprungliga gatewayen är 10 ms bättre i latens eller 5 ms bättre i jitter; för paketförlust finns ingen motsvarande marginal. Under Routing > SD-WAN profiles betyder en aktiv profile att minst en gateway är tillgänglig. Link status sammanfattar konfigurationen, Historical performance öppnar mätvärdena och Object usage visar vilka rutter som använder profilen. Kontrollera var profilen används innan du redigerar eller tar bort den.

Om Route only through specified gateways är aktivt kasserar brandväggen trafiken när de angivna vägarna inte är tillgängliga. Utan alternativet kontrollerar den andra SD-WAN-rutter och därefter default route. Om en backup gateway tas bort ställer Sophos Firewall den på None; om primary gateway eller SD-WAN profile tas bort raderas rutten och default route kan ta över.

Vid Load balancing med Best quality fördelas trafiken endast om minst två gateways delar bästa prestanda för det valda kriteriet; inte alla nåbara gateways kvalificerar sig. Med Custom SLA fördelas trafiken mellan gateways som uppfyller de angivna SLA-gränserna. En nåbar väg som inte uppfyller SLA är inte samma sak som en onåbar gateway; detta fastställer ingen generell fallbackregel när ingen gateway uppfyller SLA.

Gateway weights beskriver ett förhållande mellan förfrågningar: i det dokumenterade exemplet innebär 3:1 tre av fyra förfrågningar via den första gatewayen och en via den andra. Välj vikter efter länkkapacitet och resurser; de garanterar varken samma byteandel, en viss genomströmning eller sammanslagning av länkar.

För Custom SLA anges Maximum latency och Maximum jitter i millisekunder och Maximum packet loss i procentenheter. Interval between checks anger intervallet mellan prober och Response time-out tillåten svarstid. Deactivate gateway after räknar misslyckade probförsök i följd; Activate gateway after räknar lyckade svar i följd. Sample size for SLA anger antalet probmätningar som används för att bestämma gatewayens genomsnittliga prestanda. Välj värdena för den egna tjänsten och behandla inte ett enstaka tidsexempel som ett generellt standardvärde.

Round-robin fördelar förfrågningar i ordning mellan de gateways som kvalificerar sig. Med tre tillgängliga gateways med lika vikter och utan SLA-begränsning använder exemplet den första, andra, tredje och sedan första gatewayen igen. Session persistence type håller sammanhängande sessioner på samma gateway enligt vald nyckel, exempelvis för banktjänster eller kundvagnar. Ett enda testflöde visar därför inte fördelningen av många oberoende sessioner.

När ingen gateway uppfyller Custom SLA

Kassering vid onåbara gateways bevisar ingen hård SLA-spärr för vägar som fortfarande är nåbara. Utan buildspecifikt underlag ska i detta fall varken fortsatt Load balancing eller enbart First available gateway utlovas.

Dokumentera SFOS-build, profile, Routing strategy, gatewayordning, vikter, session persistence, SLA-gränser, probe targets och Route only through specified gateways.
Använd Link status, Historical performance och SD-WAN-loggar för att skilja nåbara vägar utanför SLA från verkligt onåbara vägar.
Testa endast med ett godkänt, isolerat testflöde i ett underhållsfönster och med oberoende administrationsåtkomst. Ändra inte delade produktionsprofiler för att simulera fel och radera inte gateways eller profiler. Skapa nya anslutningar och verifiera gateway, SNAT-IP och applikationsresultat med Log Viewer och Packet Capture; bedöm befintliga sessioner separat.
Återställ ändrade testvärden till dokumenterat ursprungsläge och upprepa statuskontroller och test med verklig trafik. Utan godkänt test förblir valet olöst; buildspecifikt klargörande kräver konfiguration, mätvärden, tidsstämplar och loggar tillsammans med builden.

Ett resultat för en build och profile är ingen generell failovergaranti.

Samordna route precedence och NAT

Den dokumenterade standardordningen är Static → SD-WAN → VPN. Det behöver inte vara tillståndet i en befintlig installation: kontrollera fortfarande system route_precedence show före beslut och tillämpa inte standarden automatiskt.

Route precedence bestämmer ordningen mellan Static, SD-WAN och VPN. Direktanslutna nät och SSL VPN tillhör kategorin Static. Den aktuella ordningen visas under Routing > SD-WAN routes eller i Device Console; ändringar och rollback beskrivs i Ändra route precedence säkert i Sophos Firewall.

Routing väljer vägen, medan NAT ändrar adresser. Internettrafik via WAN2 kan därför behöva MASQ eller ett fast SNAT-IP på den vägen. För interna nät och VPN är NAT däremot ofta oönskat. Sambanden beskrivs i Förstå NAT i Sophos Firewall: SNAT, DNAT, MASQ, PAT.

DNAT till en server bakom route-based IPsec

En publik DNAT-publicering kan peka på en intern server som inte är lokalt ansluten, utan finns bakom en fjärrbrandvägg via route-based IPsec. I detta specialfall måste DNAT och SD-WAN-rutten identifiera samma inkommande flöde före översättningen, och returvägen måste åter gå via brandväggen som publicerar tjänsten.

Det tillförlitliga SFOS 22-flödet består av fem sammanhängande delar:

Skapa ett exakt IP-objekt för fjärrservern under Hosts and services > IP host.
Skapa under Routing > Gateways en gateway med fjärrgatewayens IP-adress och motsvarande XFRM-gränssnitt. Använd en stabilt nåbar värd bakom denna gateway som övervakningsmål.
Låt DNAT-regeln matcha det publika WAN-gränssnittet och den externt erbjudna tjänsten, och välj fjärrservern som Translated destination. Sophos-exemplet använder MASQ så att svaren återgår till brandväggen som publicerar tjänsten; servern ser då inte längre klientens ursprungliga IP-adress.
Ange samma publika WAN-gränssnitt under Destination networks i SD-WAN-rutten och den externt anropade porten under Services. Vid PAT är detta uttryckligen den externa porten, inte den översatta interna målporten. Välj XFRM-gränssnittets gateway som primary gateway.
Kontrollera en snäv brandväggsregel för publiceringen och testa flödet från ett externt nät. NAT Rule ID, Firewall Rule ID, SD-WAN-rutten, vald XFRM-gateway, fram- och returväg samt den käll-IP som syns på servern måste stämma med designen.

MASQ är inte ett kosmetiskt alternativ här. I det dokumenterade exemplet löser det returvägen, men döljer klientens verkliga IP-adress för målservern. Om fjärrplatsen har en verifierad returväg till de ursprungliga klientnäten och originaladressen ska bevaras krävs en medvetet planerad och separat testad routingdesign. Den allmänna publiceringen och säkerheten beskrivs i Publicera en server via DNAT på Sophos Firewall.

Flera fjärrservrar kan använda samma SD-WAN-rutt om de kan nås via samma gateway och matchas entydigt efter WAN-adress eller extern TCP-port. Om de använder olika gateways ska separata SD-WAN-rutter konfigureras. Om fel port, WAN-objekt eller gateway matchar ska rutten inte breddas till Any; verifiera först flödet före DNAT med Log Viewer och Packet Capture.

Testa och godkänn rutten

Kontrollera ruttlistan och gatewaystatus

Under Routing > SD-WAN routes kan du söka efter ruttnamn, objekt eller objektvärde; 443 hittar till exempel rutter som använder HTTPS-tjänsten. Dra och släpp ändrar ordningen. Det påverkar trafiken eftersom SFOS utvärderar uppifrån och ned och stannar vid den första matchningen.

Under More options kan du aktivera eller inaktivera en rutt, redigera eller klona den, nollställa dataräknaren eller ta bort rutten. Notera räknarvärde och tid före en återställning. En klonad rutt är självständig: kontrollera namn, matchningskriterier, position, gateway och NAT innan du sparar eller aktiverar den och verifiera sedan den faktiska On/Off-statusen.

Verktygstipset vid ikonen i kolumnen Active visar tillstånd som In use, Available, Unavailable, In use, but SLA isn't met eller Available and SLA isn't met. En tillgänglig gateway- eller profilstatus bevisar varken att rutten matchade eller att returvägen fungerar.

Vid direkt primary/backup-val skiljer ikonen Active mellan tre tillstånd: minst en gateway är nåbar och rutten är aktiv; rutten är inte aktiv och Route only through specified gateways är av; eller rutten är inte aktiv och alternativet är på. I det sista fallet fortsätter trafiken att kasseras om de angivna vägarna är onåbara, i stället för att använda andra gateways. Läs verktygstipset tillsammans med kryssrutan och likställ dem inte med en profils SLA-status.

Standardtest med verklig trafik

Välj en testklient med känd IP-adress och ett entydigt mål.
Aktivera logging i rätt firewall-regel.
Starta en verklig anslutning.
Kontrollera source, destination, service, rule ID, NAT ID och gateway i Log viewer.
Kontrollera SD-WAN-ruttens traffic count: OUT räknar requests och IN replies endast om source och destination matchar i respektive riktning.
Aktivera typen SD-WAN under System services > Log settings och kontrollera modulen SD-WAN i Log Viewer för profile-, SLA- och route-händelser.
Ange vid oklarheter ett snävt filter för klient, mål och port under Diagnostics > Packet capture.

Policy tester tar inte hänsyn till SD-WAN-rutter. Den kan kontrollera policymatchningar, men bekräftar varken vald SD-WAN-rutt eller faktisk gateway. För en fullständig analys, se Testa Sophos Firewall-regler med Log Viewer, Policy Test och Packet Capture.

För profil- och ruttloggar i brandväggsvyn väljer du modulen Firewall i Log viewer, öppnar det utökade urvalet med expanderingsknappen bredvid modullistan, markerar önskade SD-WAN-loggar och klickar på Apply. Detta kompletterar den separata SD-WAN-modulvyn.

Utvärdera SD-WAN performance

Kvalitetsgrafernas x-axel visar tid; y-axeln visar latens och jitter i millisekunder och paketförlust i procentenheter. Assigned weights for load balancing öppnar tilldelade gatewayvikter. Mätvärden och vikter utgör inte ett godkännande av applikationen.

Under Diagnostics > SD-WAN performance väljs den SD-WAN profile som används. Alternativt öppnas Routing > SD-WAN profiles, aktuell profile väljs och under Status klickar man på Historical performance. För varje gateway visar vyn totalt antal anslutningar, överförd datamängd, tilldelade load-balancing-vikter samt latens, jitter och paketförlust för Live, 24h, 48h, Week eller Month.

Enligt Sophos betyder No data to display att ingen rutt ännu använder den valda profilen eller att ingen trafik passerar genom en sådan rutt. Meddelandet bevisar därför inget mätfel. Generera först ett kontrollerat trafikflöde över den förväntade rutten och bekräfta det med Log Viewer eller Packet Capture.

Reset data transfer and connection count ändrar räknarna. Dokumentera värden och tidpunkt före en återställning. Även en graf utan avvikelser bevisar inte att brandväggsregel, NAT, applikation och returväg fungerar; dessa lager ingår fortfarande i det verkliga testet.

Testa failover och failback säkert

Notera före en ändring ruttens aktuella position och On/Off-status, dess primary/backup gateways eller använda profile, profilens gatewayordning, SLA- och Health Check-värden samt förväntad NAT-översättning. Rollback innebär att exakt dessa värden återställs och att status, loggar och verklig trafik därefter kontrolleras igen.

Ett kontrollerat avbrottstest utförs i ett underhållsfönster, med dokumenterad rollback och en oberoende administrationsväg till brandväggen. Kontrollera först de aktuella skrivskyddade statusvärdena i Device Console:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Starta sedan verklig applikationstrafik, gör primary gateway otillgänglig under kontrollerade former och kontrollera väg, sessioner, Public Source IP och returväg. Ta inte bort primary gateway eller SD-WAN profile för testet, eftersom det raderar rutten och endast testar fallback till default route. Även redigering av route eller profile samt en ändring av Route Precedence kan dirigera om befintliga anslutningar och hör inte hemma i samma baslinjetest. Vid direkt primary/backup-val går nya anslutningar åter via primary när den kommer tillbaka; befintliga anslutningar ligger i regel kvar på backup gateway.

reroute-connection är aktiverat som standard och gäller anslutningar utan SNAT. SNAT-anslutningar dirigeras inte om som standard; även med separat aktiverat reroute-snat-connection fungerar det bara om båda vägarna använder samma översatta Source IP. Med MASQ eller olika Override Source Translation-adresser dirigeras SNAT-anslutningen inte om och den befintliga sessionen bryts när vägen fallerar.

Ändra rerouting medvetet

Dessa inställningar ändrar trafikhanteringen och är inte förutsättningar för baslinjetestet. Ändra dem endast under ett underhållsfönster med verifierad oberoende administrationsåtkomst och dokumenterad rollback: spara först båda reroutingstatusarna ovan och kontrollera att båda vägarna använder samma översatta käll-IP för SNAT. Följande alternativ finns i Device Console; kör endast kommandot för den avsedda ändringen, inte alla kommandon i följd:

Aktivera utan SNAT: set routing reroute-connection enable; inaktivera: set routing reroute-connection disable.
Aktivera för SNAT: set routing reroute-snat-connection enable; inaktivera: set routing reroute-snat-connection disable.

Kontrollera därefter med show routing reroute-connection och show routing reroute-snat-connection och testa separat sessioner, käll-IP och båda trafikriktningarna. För rollback återställs varje ändrad inställning till sitt dokumenterade enable/disable-tillstånd, varefter statuskontroll och test med verklig trafik upprepas. Aktivering av SNAT-rerouting tar inte bort MASQ/IP-begränsningarna.

Avgränsa problem systematiskt

Rutten matchar inte

Jämför incoming interface, source network, destination och service med det verkliga flödet.
Kontrollera ruttordningen; den första matchande SD-WAN-rutten vinner.
Kontrollera licens, DPI-identifiering och en andra anslutning efter klassificeringen för Application Objects.
Använd inte traffic count som enda bevis, eftersom requests och replies bara räknas när source- och destinationkriterierna matchar.
Vid Direct Web Proxy räcker inte HTTP/HTTPS som service: använd Any eller en service för porten under Web > General settings > Web proxy listening port. I det här specialfallet matchar source network och incoming interface inte för reply packets; proxyns returväg kräver dessutom en WAN default gateway eller en lämplig statisk rutt.
För en SD-WAN-rutt som migrerats från SFOS 17.5 eller tidigare kontrollerar man om den ursprungliga brandväggsregeln har raderats. Sådana migrerade rutter förblir kopplade till den gamla regeln och tas också bort när regeln raderas.
För IPv6 övervakar Dead Gateway Detection i SD-WAN-rutter inte nätverkstrafik från tredje part, till exempel SNMP. En utebliven extern mätning är därför inget tillförlitligt bevis på DGD-status.

Konfigurera Direct Web Proxy med en PAC-fil beskriver listener, klientdistribution, skyddsregel och test med verklig trafik.

För svarspaket och systemgenererad trafik gäller separata inställningar för aktivering och inaktivering samt separata matchningsregler. Dessa fall förklaras i Kontrollera Sophos Firewall SD-WAN-routing för reply packets och system traffic.

Web Admin och SSH blir onåbara efter en ny rutt

Ett dokumenterat scenario kombinerar fyra inställningar: SD-WAN ligger före Static, en ny rutt för ett specifikt internt källnät har destination Any, SD-WAN-routing för systemgenererad trafik är aktiverad och routing för reply packets är också aktiverad. Administrationsåtkomsten från det berörda interna nätet kan då försvinna medan den fortfarande fungerar från andra subnät. Detta är inte nödvändiga villkor för alla administrationsavbrott.

Via tidigare verifierad alternativ åtkomst kontrollerar du ruttens källa, mål och precedence samt dessa skrivskyddade värden i Device Console:

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

Kontrollera först att administration från ett opåverkat subnät verkligen är tillåten och nåbar. Begränsa därefter målet medvetet eller återställ en av de tidigare ändrade inställningarna till dess dokumenterade ursprungsvärde. Gör ingen blind global återställning: spara först position, inställningar och precedence, planera rollback och kontrollera sedan Web Admin, SSH och berörd trafik igen. Fortsätt inte ändringen på distans utan säker alternativ åtkomst.

Trafiken tar fel väg

Ersätt Any med Internet IPv4 group eller specifika mål för publika IPv4-destinationer.
Kontrollera route precedence, särskilt om interna nät, SSL VPN eller policy-based IPsec berörs.
Kontrollera gateway- och SLA-status samt Health Check Targets.
Jämför NAT-regeln och översatt Source IP med den gateway som faktiskt används.
Kontrollera om primary gateway eller SD-WAN profile har tagits bort och därmed även rutten.

Applikationen eller svaret fallerar efter failover

Kontrollera först med Packet Capture om paketet lämnar via förväntad gateway och om svaret kommer tillbaka. Kontrollera därefter NAT, allowlists för publika IP-adresser, Session Persistence, MTU/MSS och status för VPN- eller MPLS-vägen. Särskilt SIP/RTP, bankportaler och API:er med fast Source IP måste testas med verklig applikationstrafik.

Om problemet började direkt efter uppgraderingen till SFOS 22.0 GA ska du först kontrollera installerad build. SFOS 22.0 MR1 Build 490 åtgärdar NC-173667, där en SD-WAN-rutt kopplades från slumpmässigt, och NC-177603, där VoIP-ljud via en route-based VPN endast fungerade i en riktning efter uppgraderingen till 22.0 GA. Om MR1 eller en senare build redan är installerad ska felet inte tillskrivas enbart firmwareversionen; upprepa testet med verklig trafik ovan och kontrollera rutten, sessionerna, NAT och båda trafikriktningarna.

XML-API: klargör objektgränser före automatisering

XML-API-dokumentationen för SFOS 22.0 och 23.0 beskriver separata namngivna objekt. UI-konfigurationen som beskrivs ovan är fortfarande det praktiska arbetsflödet, men det går inte att härleda ett entydigt XML-kontrakt från den. Motsägelserna nedan måste klarläggas innan en begäran byggs. Automatisering kräver ett versionsspecifikt klargörande från Sophos av de berörda fälten; här gissas varken någon numerisk mappning eller anges någon körbar XML-begäran.

Namngivet HealthCheckProfile: livscykel och probräknare

HealthCheckProfile är ett självständigt Health Check-objekt, inte SDWANProfile och inte det inbyggda alternativet för gatewayens Health Check. Vid skapande och uppdatering identifierar det obligatoriska skalära strängfältet Name Health Check-profilen; båda fälttabellerna anger högst 125 tecken. Tabellen för 22.0 förbjuder dessutom kommatecken och tillåter uttryckligen UTF-8-tecken, medan dessa båda uppgifter saknas i tabellen för 23.0. Att uppgifterna saknas bevisar inte att namnvalideringen har ändrats.

ProbeTargets beskrivs som en array av monitorDetails-objekt, medan exemplet innehåller ProbeTarget-element. För monitormethod anges TCP eller PING; för monitorip anges datatyperna IPADDRESS, IPADDRESS6 och DOMAINNAMELOOKUP. För operator anges literalerna & och |, med standardvärdet |. Detta används varken för att härleda en annan XML-struktur eller för att likställa den med UI-beteendet för de två Probe Targets som beskrivs ovan. Även IPFamily är motsägelsefullt: båda tabellerna anger IPv4 och IPv6, med standardvärdet IPv4, men samtidigt högst 1 tecken.

De två raderna för räknarna verkar vara omkastade i förhållande till sina namn: ProbesResponseFailure beskriver ordagrant svar i följd för att aktivera objektet, med standardvärdet 1; ProbeResponseSuccess beskriver prober i följd utan svar före inaktivering av objektet, med standardvärdet 3. Båda tabellerna anger intervallet 1 till 10 för respektive räknare. Denna koppling i dokumentationen korrigeras inte i tysthet och bekräftar inte beteendet vid körning. Framför allt överförs inte de tillförlitliga UI-förklaringarna av Deactivate gateway after och Activate gateway after automatiskt till dessa API-taggar.

Den separata borttagningsoperationen adresserar också Health Check-profilen via Name, inte en rutt eller en SD-WAN profile. Före en avsedd borttagning kontrollerar du de SD-WAN profiles som refererar till objektet och dokumenterar deras befintliga Health Check-koppling. Källorna belägger varken ett säkert kaskadförlopp eller beteendet när ett Health Check-objekt som fortfarande refereras tas bort. Detta ska inte likställas med borttagningen av en SD-WAN profile som beskrivs ovan; en sådan borttagning är inte heller ett avbrottstest.

HealthCheckProfileStatus: Health Check-objektets administrativa tillstånd

HealthCheckProfileStatus aktiverar eller inaktiverar den namngivna Health Check-profilen administrativt. Selektorn är det obligatoriska skalära strängfältet Name; platshållaren HealthCheckProfileStatusName i exemplet ändrar inte denna fältidentitet. I båda versionerna anges ON/OFF för Status i exemplet, medan den obligatoriska fältraden anger INTEGER utan numerisk mappning. Därmed finns inget belägg för en numerisk form för på eller av. Denna administration är inte gatewayens uppmätta tillgänglighet, det aktiva tillståndet för en SD-WAN profile eller aktivering/inaktivering av en rutt. Ett dokumenterat framgångsmeddelande bevisar inte ensamt att tillståndet faktiskt har ändrats; det administrativa tillståndet för exakt detta namngivna objekt skulle behöva kontrolleras separat från tillgänglighetsindikatorerna.

SDWANPolicyRouteStatus: kontrollera rätt rutt och rätt tillstånd

SDWANPolicyRouteStatus använder SDWANPolicyRouteName som obligatorisk skalär strängselektor, inte Name för en Health Check-profil. Exemplen för båda versionerna visar återigen ON/OFF för Status, medan den obligatoriska fältraden anger INTEGER utan någon numerisk mappning. Den dokumenterade resultatkoden 200 är ingen oberoende bekräftelse på att den avsedda rutten har ändrat sitt administrativa tillstånd. För detta skulle ruttens faktiska On/Off-tillstånd behöva kontrolleras. Verktygstipset för Active, gatewayens nåbarhet och beslutet att kassera trafik eller använda fallback genom Route only through specified gateways besvarar andra frågor och löser inte motsägelserna i XML-kontraktet för status.

SDWANProfile: familj, strategi och separat Health Check-referens

För SDWANProfile betecknar Name själva SD-WAN-profilen, med högst 60 tecken. Det obligatoriska skalära strängfältet HealthCheckProfileName är däremot referensen till den separata Health Check-profilen, med högst 85 tecken. Det är inte samma identitet och inte heller samma dokumenterade namnlängd som dess Name med 125 tecken. Därför gäller objekt- och räknargränserna för HealthCheckProfile även när denna referens förbereds; inbyggda Health Check-inställningar ersätter inte den obligatoriska namngivna referensen.

Båda profile-exemplen och fältbeskrivningarna anger IPv4/IPv6 för IPFamily, men valideringsraden tillåter endast IPv4 och anger samtidigt högst 1 tecken. IPv6-rutterna i UI bevisar därför inte IPv6-stöd i detta XML-kontrakt för profiler. För SLAStrategy anges BestQuality i exemplet och beskrivningen, men BestQualityv i listan över tillåtna värden; CustomSLA finns i båda. För LBMethod anger exemplet WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, medan tabellen anger INTEGER i intervallet 0 till 5 utan koppling till dessa textvärden. För IsLatency står standardvärdet 1 mot de tillåtna literalerna OFF och ON. Ingen av dessa skillnader löses genom en förmodad stavningskorrigering, numerisk form eller härledd boolesk mappning. UI-strategierna och kontrollprocedurerna som beskrivs ovan kan fortfarande användas, men är inget bevis för en körbar begäran för en profil.

Drift och dokumentation

Dokumentera syfte, incoming interface, source/destination, services, gateway eller profile, fallback, NAT-förväntning, testklient, testmål, owner och granskningsdatum för varje produktiv SD-WAN-rutt. Efter ändringar av operatör, VPN, interface eller molntjänst bör matchning, loggar och failover kontrolleras igen.

En rutt är godkänd först när:

matchningskriterierna endast omfattar den planerade trafiken
firewall-regel, NAT och route precedence stämmer med designen
Log Viewer och Packet Capture bekräftar den förväntade vägen
failover, failback och Public Source IP reagerar enligt dokumentationen
en ansvarig och nästa granskningsdatum är registrerade