Route precedence op Sophos Firewall veilig wijzigen

De route precedence bepaalt of Sophos Firewall eerst Static Routes, SD-WAN Policy Routes of VPN-routes beoordeelt. De instelling werkt globaal en kan productie-verkeer en beheerstoegang onmiddellijk beïnvloeden.

Kort antwoord

De standaardvolgorde is:

1. static
2. sdwan_policyroute
3. vpn

Deze volgorde past bij veel omgevingen, omdat direct verbonden netwerken en statische routes daardoor niet door een brede SD-WAN-route worden overschreven. Wijzig de volgorde alleen wanneer in de concrete pakketstroom meerdere routingtypen voor dezelfde bestemming concurreren.

Documenteer vóór elke wijziging de actuele volgorde, zorg voor onafhankelijke beheerstoegang, controleer de betrokken routes en bereid de exacte rollback voor. Een normale SD-WAN-route wordt uitgelegd in Een SD-WAN-route op Sophos Firewall instellen en testen.

Welke volgorde past?

Standaard en versieverschil

De standaardvolgorde is in SFOS 21.5 en 22.0 identiek. De classificatie van ipsec_route is echter gewijzigd:

• SFOS 21.5: static omvat direct verbonden netwerken, ipsec_route, Unicast Routes, Dynamic Routes en SSL VPN. Automatisch gegenereerde policy-based IPsec-routes horen bij vpn.
• SFOS 22.0: static omvat direct verbonden netwerken, Unicast Routes, Dynamic Routes en SSL VPN. vpn omvat automatisch gegenereerde policy-based IPsec-routes en ipsec_route.

Dit is belangrijk bij upgrades: Advies voor ipsec_route onder SFOS 21.5 mag niet ongewijzigd op SFOS 22.0 worden toegepast. Onder SFOS 22.0 verwerkt de firewall policy-based IPsec-routes intern. Automatisch gegenereerde policy-based VPN-routes en routes die met ipsec_route zijn gedefinieerd, zijn niet zichtbaar in de routingtabel. Voor systeemgegenereerd verkeer is ipsec_route niet nodig. Een handmatige IPsec-route is alleen zinvol voor de passende, versieafhankelijke uitzondering.

Bij gemigreerde firewalls telt de werkelijke uitvoer, niet de gedocumenteerde standaard. Een migratie kan bijvoorbeeld sdwan_policyroute vpn static overnemen. Gemigreerde SD-WAN-routes kunnen bovendien gekoppeld blijven aan de ID van hun oorspronkelijke firewallregel en verdwijnen wanneer die regel wordt verwijderd.

Static eerst

static sdwan_policyroute vpn is meestal het juiste uitgangspunt voor LAN, DMZ, VLAN, SSL VPN en normale SD-WAN-internetpaden. Direct verbonden netwerken worden daarbij als statische routes behandeld.

Dit beschermt interne bestemmingen tegen te brede SD-WAN-routes. Als sdwan_policyroute vóór static staat en een SD-WAN-route bijvoorbeeld bestemming Any gebruikt, kan intern of administratief verkeer onverwacht naar de WAN-gateway worden gestuurd.

SD-WAN eerst

sdwan_policyroute static vpn is zinvol wanneer policy routing bewust voorrang moet krijgen op statische routes. Dit moet met concrete bronnen, bestemmingen en diensten worden gepland. Voor reply packets en systeemgegenereerd verkeer gelden SD-WAN-routes alleen als de bijbehorende CLI-opties zijn ingeschakeld.

Sophos Firewall SD-WAN-routing voor reply packets en system traffic controleren legt beide opties in detail uit.

VPN eerst

vpn static sdwan_policyroute is een gerichte uitzondering, bijvoorbeeld voor gedocumenteerde L2TP-scenario’s. De prioriteit van vpn vóór static geldt alleen voor verkeer waarvan de concurrerende route naar de WAN-zone leidt. Dit is geen algemene oplossing voor elke IPsec-tunnel.

SSL VPN-verbindingen behoren tot de categorie static, niet tot vpn. Route-based IPsec via XFRM-interfaces wordt gestuurd door de daarvoor geconfigureerde statische, dynamische of SD-WAN-route. Doorslaggevend zijn daarom XFRM-interface, route, SD-WAN-criteria, NAT, firewallregel en retourpad.

Een globale wijziging is ongeschikt wanneer slechts één bestemmingsnetwerk verkeerd wordt gerouteerd. Een specifiekere statische of SD-WAN-route, de VPN-configuratie of een versiecorrect gebruikte ipsec_route is meestal een preciezer middel.

De wijziging veilig voorbereiden

Voer de opdrachten uit in de Device Console, niet in de Advanced Shell. Als toegang nog niet is geconfigureerd, zie Sophos Firewall via SSH verbinden. Sta SSH alleen toe vanuit vertrouwde netwerken.

Voorbereiding:

1. Zorg vóór de wijziging voor een onafhankelijk pad terug naar de firewall en test dit actief, bijvoorbeeld een lokale console, een speciale managementinterface of een bevestigd, niet-betrokken beheerpad.
2. Noteer bron, bestemming, dienst, zone en betrokken interfaces.
3. Controleer statische routes, SD-WAN Policy Routes, VPN-routes en XFRM-interfaces.
4. Identificeer brede SD-WAN-routes met Any en gemigreerde regels.
5. Controleer NAT, de firewallregel en het retourpad van de tegenpartij.
6. Leg onderhoudsvenster, acceptatietest en rollback vast.

⚠️ Belangrijk: Route precedence werkt globaal. Wijzig routing-, NAT-, firewall- en SD-WAN-regels niet tegelijk, omdat het effect dan niet betrouwbaar kan worden toegewezen.

Toon de actuele volgorde en documenteer deze exact:

system route_precedence show

Leg de volledige uitvoer vast met datum, reden, betrokken netwerken en verwacht gedrag. Bereid vóór de wijziging met alle drie waarden de exacte rollback-opdracht voor.

De actuele volgorde is in WebAdmin ook hier zichtbaar:

Routing > SD-WAN routes

Wijzigen gebeurt via de Device Console. Als SD-WAN betrokken is, leg dan vooraf ook de status van systeemgegenereerd verkeer en reply packets vast:

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

Deze waarden mogen niet worden verward met het effect van route precedence. Een bijzonder kritieke combinatie ontstaat als sdwan_policyroute vóór static staat, een matchende SD-WAN-route bestemming Any gebruikt en SD-WAN voor zowel systeemgegenereerd verkeer als reply packets actief is. WebAdmin en SSH kunnen dan vanuit het betrokken interne subnet onbereikbaar worden, terwijl de firewall vanuit andere subnetten mogelijk nog bereikbaar is.

Route precedence wijzigen

De syntaxis bevat altijd alle drie waarden:

system route_precedence set [sdwan_policyroute] [static] [vpn]

De standaardvolgorde instellen:

system route_precedence set static sdwan_policyroute vpn

Als deze volgorde al actief is, ligt de fout waarschijnlijk bij route lookup, SD-WAN-criteria, VPN-configuratie, NAT, de firewallregel of het retourpad.

⚠️ Vóór SD-WAN-First: Controleer of brede SD-WAN-routes interne netwerken of beheerstoegang omvatten. Voer de opdracht alleen uit met een voorbereid herstelpad.

SD-WAN Policy Routes eerst beoordelen:

system route_precedence set sdwan_policyroute static vpn

⚠️ Vóór VPN-First: Gebruik deze volgorde alleen voor een bevestigde VPN-uitzondering. Ze verhelpt geen ontbrekende route, onjuiste traffic selectors, NAT- of retourpadproblemen.

VPN-routes eerst beoordelen:

system route_precedence set vpn static sdwan_policyroute

De wijziging testen en terugdraaien

Bevestig na de wijziging eerst dat de verwachte volgorde actief is:

system route_precedence show

Test daarna de betrokken pakketstroom:

• Test de applicatie, TCP-verbinding of ping naar de bestemming.
• Filter Log Viewer op bron, bestemming en firewallregel.
• Voer Packet Capture uit op de inkomende en uitgaande interface.
• Controleer route lookup en de betrokken SD-WAN-route.
• Controleer NAT en het vertaalde bron-IP.
• Bevestig het retourpad van de tegenpartij.
• Test WebAdmin en SSH vanuit de relevante beheernetwerken.

Een groene VPN-status of een bestaande route bewijst niet dat de pakketstroom werkt. Praktische stappen staan in Sophos Firewall-regel testen met Log Viewer en Packet Capture en Packet Capture in Sophos Firewall WebAdmin gebruiken.

Als meerdere locaties of routingpaden betrokken zijn, test dan minstens één client per relevant netwerk, één serverbestemming en de betrokken Remote Access- of VPN-paden.

Bij rollback wordt uitsluitend de eerder gedocumenteerde volledige oorspronkelijke volgorde ingesteld. Deze kan niet alleen uit de eerste waarde worden afgeleid, omdat zes combinaties mogelijk zijn. Gebruik de voorbereide opdracht volgens dit patroon:

system route_precedence set <eerste waarde> <tweede waarde> <derde waarde>

Vervang de placeholders door alle drie waarden uit de eerder opgeslagen uitvoer. Controleer daarna opnieuw:

system route_precedence show

Herhaal daarna dezelfde functionele, routing- en beheertests. Als de oorspronkelijke fout na de rollback terugkomt, was route precedence waarschijnlijk betrokken. Verandert er niets, dan ligt de oorzaak elders.

Veelvoorkomende fouten

De SD-WAN-route is te breed

Een SD-WAN-route met grote netwerkbereiken of bestemming Any kan meer verkeer omvatten dan gepland. Als SD-WAN vóór Static staat, kunnen interne bestemmingen en beheerstoegang onverwacht naar de WAN-gateway gaan. Reply packets en systeemgegenereerd verkeer zijn betrokken wanneer de bijbehorende SD-WAN-opties zijn ingeschakeld.

VPN-status wordt met routing verward

Een actieve tunnel bevestigt alleen de onderhandeling. Dit bewijst niet dat routing, traffic selectors, firewallregels, NAT en retourpad kloppen. Controleer bij route-based IPsec eerst de XFRM-interface en route; bij policy-based IPsec ook de versieafhankelijke verwerking van ipsec_route. Sophos Firewall IPsec VPN-troubleshooting doorloopt de analyse systematisch.

NAT wordt over het hoofd gezien

Routing bepaalt het pad van het pakket, NAT verandert het bron- of bestemmingsadres. Als de route klopt maar het retourpad defect is, zijn NAT of de retourroute vaak de oorzaak. Zie NAT op Sophos Firewall begrijpen.

Meerdere wijzigingen worden tegelijk uitgevoerd

Wie route precedence, SD-WAN, NAT, firewallregels en VPN-parameters tegelijk wijzigt, kan oorzaak en gevolg niet meer goed scheiden. Beter is: één wijziging, volledige test, volgende wijziging.

Checklist

• Actuele route precedence gedocumenteerd.
• SFOS-versie en classificatie van ipsec_route meegenomen.
• Betrokken bronnen, bestemmingen, netwerken en diensten genoteerd.
• Static, SD-WAN, VPN en XFRM gecontroleerd.
• Direct verbonden netwerken en managementpaden meegenomen.
• Brede SD-WAN-routes met Any geïdentificeerd.
• Status van System Traffic en reply packets vastgelegd.
• NAT, firewallregels en retourpad gecontroleerd.
• Onafhankelijke beheerstoegang en rollback voorbereid.
• Wijziging afzonderlijk uitgevoerd.
• Applicatie, Log Viewer, Packet Capture en beheerstoegang getest.

Veelgestelde vragen