Hoppa till innehållet
Avanet

Konfigurera och testa SD-WAN-rutter i Sophos Firewall

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.

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.

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

  1. Ange namn och beskrivning och välj First available gateway eller Load balancing under Routing strategy.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Anpassa Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after och Sample size for SLA till tjänsten. Korta värden reagerar snabbare men kan växla i onödan vid tillfällig paketförlust; större värden är stabilare men upptäcker ett verkligt avbrott senare.
  7. 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.

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:

  1. Skapa ett exakt IP-objekt för fjärrservern under Hosts and services > IP host.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. Välj en testklient med känd IP-adress och ett entydigt mål.
  2. Aktivera logging i rätt firewall-regel.
  3. Starta en verklig anslutning.
  4. Kontrollera source, destination, service, rule ID, NAT ID och gateway i Log viewer.
  5. Kontrollera SD-WAN-ruttens traffic count: OUT räknar requests och IN replies endast om source och destination matchar i respektive riktning.
  6. 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.
  7. 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. Dessa dokumenterade kommandon och denna rollback har inte testats här på en brandvägg; 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.

Separata switches och matchningsregler gäller för reply packets och system-generated traffic. 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.

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