Statische route op Sophos Firewall instellen en testen

Een statische route vertelt Sophos Firewall via welke vaste next hop of tunnelinterface een bepaalde bestemming bereikbaar is. Ze is geschikt wanneer het pad vastligt en geen selectie op basis van source, service, applicatie of verbindingskwaliteit nodig is.

Kort antwoord

U maakt hier een IPv4-route:

Routing > Static routes > IPv4 unicast route > Add

Voor een bestemmingsnetwerk 10.20.0.0/24 dat via router 192.0.2.2 op Port4 bereikbaar is, voert u het volgende in:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

Het bestemmingsnetwerk, de gateway en de interface moeten bij uw omgeving passen. Neem Administrative Distance en Metric pas over nadat u bestaande routes naar dezelfde bestemming hebt gecontroleerd; 1 en 10 zijn alleen voorbeeldwaarden.

Controleer daarna onder Diagnostics > Tools > Route lookup de bestemming 10.20.0.10. Als het resultaat Port4 toont, is de routingbeslissing correct. De wijziging is pas volledig gevalideerd wanneer een echte clientverbinding werkt en het antwoord terugkomt.

Om het verkeer daadwerkelijk te laten werken, zijn ook een passende firewallregel en een retourroute op de tegenpartij nodig. Een statische route staat geen verkeer toe en voert niet automatisch NAT uit.

Het voorbeeld begrijpen

Het voorbeeld gebruikt de volgende opbouw:

Het clientnetwerk achter Sophos Firewall is 10.10.0.0/24.
De testclient in dit netwerk is 10.10.0.10.
Port4 van de firewall heeft het transit-IP 192.0.2.1/30.
De volgende router heeft in dit netwerk het IP-adres 192.0.2.2.
Achter deze router ligt het bestemmingsnetwerk 10.20.0.0/24.
Het testsysteem is 10.20.0.10.

De Destination is altijd de externe bestemming, niet de volgende router. Gateway IP is de direct bereikbare next hop die het pakket doorstuurt. Interface is de poort of tunnelinterface waarmee deze next hop wordt bereikt.

De bestemming kan een netwerk of één host zijn. Als alleen het testsysteem dit pad moet gebruiken, kiest u bijvoorbeeld 10.20.0.10/32 voor IPv4 of 2001:db8:20::10/128 voor IPv6 in plaats van een volledig netwerk. Een breder prefix omvat extra bestemmingsadressen en is alleen geschikt als die ook via deze next hop bereikbaar zijn. De firewalltoestemming blijft daarvan onafhankelijk.

Voer het adres rechtstreeks in bij Gateway IP; daarvoor is geen gateway-object onder Routing > Gateways nodig. Vervang voor de eigen omgeving het bestemmingsnetwerk, de gateway en de interface altijd samen. Als slechts één voorbeeldadres wordt overgenomen, kan de route wel worden opgeslagen, maar naar het verkeerde netwerk of een onbereikbare router wijzen. Het IP-adres van de gateway moet bij het netwerk van de gekozen interface passen.

Als het pad daarentegen een eigen Health Check nodig heeft of in een SD-WAN Route selecteerbaar moet zijn, helpt de afzonderlijke handleiding voor Custom Gateways op Sophos Firewall.

De basis van poort, zone en interface-IP wordt uitgelegd in Sophos Firewall-zones en interfaces configureren.

Wanneer een statische route geschikt is

Dit artikel behandelt Unicast-doelnetwerken. Als een zender een Multicast-groep via meerdere interfaces moet bereiken, volgt u de afzonderlijke handleiding Multicast configureren met een statische Multicast-route.

Multicast verstuurt één datastroom naar een groep in plaats van afzonderlijke kopieën naar elke ontvanger, bijvoorbeeld voor videoconferenties, trainingen of softwaredistributie. Ontvangers moeten zich bij de groep aansluiten; zenders, ontvangers en betrokken routers moeten multicast ondersteunen. IPv4-groepsadressen lopen van 224.0.0.0 tot 239.255.255.255, terwijl het bronadres een unicast-adres blijft. Dit is het algemene adresbereik, niet de toestemming om elke bestemming in een statische multicast-route te gebruiken. Onder Routing > Static routes schakelt Enable multicast forwarding de doorgifte in. Manage multicast route biedt toevoegen, bewerken, verwijderen en filters op bron-IP, multicast-IP, Source Interface of Destination Interface. De gekoppelde multicast-handleiding beschrijft de voorwaarden, het toegestane groepsbereik, veilig testen en rollback.

Een statische route is zinvol wanneer een netwerk permanent via dezelfde next hop bereikbaar is, bijvoorbeeld:

een vestigingsnetwerk achter een interne Core Router
een servernetwerk achter een Layer 3-switch
een netwerk achter een RED-tunnel
een extern netwerk via de XFRM-interface van een route-based IPsec-tunnel

Als de firewall ook op basis van source, service of applicatie moet beslissen of paden op basis van latency, jitter en pakketverlies moet wisselen, is een SD-WAN-route meestal geschikter. In kleine of bestaande routingdomeinen kan RIPv2 eenvoudige netwerken automatisch uitwisselen. In grotere netwerken die vaak wijzigen, verminderen OSPF of BGP het handmatige beheer.

Een IPv4-route instellen

Documenteer vóór de wijziging het bestemmingsnetwerk, de next hop, de uitgaande interface, de verwachte zone, het retourpad en een bereikbare testhost. Ga daarna als volgt te werk:

Open Routing > Static routes.
Klik onder IPv4 unicast route op Add.
Voer bij Destination IP / Netmask 10.20.0.0/24 in.
Voer bij Gateway IP de volgende router 192.0.2.2 in.
Selecteer Port4 als Interface.
Stel Administrative distance in op 1.
Voer bij Metric 10 in.
Voeg een duidelijke Description toe, bijvoorbeeld Branch_10.20_via_Core.
Sla op met Save.

Voor deze route houdt Sophos Firewall eerst rekening met de geselecteerde interface en daarna met de gateway. Als een van beide velden onjuist is, wordt de bedoelde next hop niet bereikt. In de IPv4-lijst kunt u filteren op IP-adres, Gateway IP, Interface of Description en routes bewerken, klonen, verwijderen, inschakelen of uitschakelen. De IPv6-lijst ondersteunt filters op IP-adres, Gateway IP of Interface en het toevoegen, bewerken of verwijderen van routes.

Administrative Distance en Metric

De Administrative Distance beoordeelt concurrerende routingbronnen. Een lagere waarde krijgt voorrang: een route met 1 wordt verkozen boven een route met 5.

Als meerdere statische routes naar dezelfde bestemming dezelfde Administrative Distance hebben, bepaalt de Metric de keuze. Ook hier krijgt de lagere waarde voorrang.

De globale Route Precedence tussen Static, SD-WAN en VPN is een ander niveau dan Administrative Distance en Metric. Wijzig ze niet overhaast voor één nieuwe route.

De voorbeeldwaarden 1 en 10 zijn eenvoudige beginwaarden voor één route, geen algemene productaanbeveling. Vergelijk vóór gebruik de bestaande routes naar dezelfde bestemming. Voor Primary/Backup of ECMP worden Administrative Distance en Metric bewust gekozen volgens de gewenste prioriteit.

Twee routes met een verschillende Administrative Distance kunnen een voorkeurspad en een secundair pad beschrijven. Administrative Distance en Metric bewaken de next hop echter niet zelf. Gebruik voor een beschikbaarheidscontrole een bewaakte gateway in een SD-WAN-route. Voor selectie op basis van latency, jitter of pakketverlies heeft de route daarnaast een SD-WAN Profile met Best quality of Custom SLA nodig.

Route-based IPsec redundant maken met twee internetverbindingen biedt een volledig voorbeeld met twee providers en twee Any-to-Any-XFRM-tunnels. Gateways, gespiegelde routes, Route Precedence, Failover en Failback worden daarin samen getest.

Voor IPv4 ECMP maakt u meerdere routes naar dezelfde bestemming met dezelfde Administrative Distance en Metric, maar met verschillende next hops. Verbindingen kunnen dan over next hops met gelijke kosten worden verdeeld; dit levert geen kwaliteitsgebaseerd Primary/Backup-pad op.

Blackhole bewust gebruiken

Met Blackhole verwerpt de firewall verkeer naar de opgegeven bestemming zonder de source daarvan op de hoogte te stellen. Dit kan nuttig zijn voor bewust geblokkeerde of samengevoegde netwerken, maar vervangt geen normale next hop.

Wie statische routes via RIP, OSPF of BGP distribueert, moet Blackhole-routes daar gericht filteren. Anders kan de firewall deze blokkeerroute ook aan andere routers doorgeven.

IPv6 en bijzondere tunnelsituaties

Onder IPv6 unicast route voert u het bestemmingsadres met prefix, Gateway IP, Interface en Metric in. Sophos documenteert voor het IPv6-formulier geen Administrative Distance, Blackhole-optie, Description, Clone of aan-uitfunctie. Neem IPv4-instellingen daarom niet zonder controle over voor IPv6.

Volg voor een normaal gerouteerd IPv6-netwerk deze stappen:

Klik onder Routing > Static routes > IPv6 unicast route op Add.
Voer een bestemmingsnetwerk in, bijvoorbeeld 2001:db8:20::/64.
Voer 2001:db8:4::2 in bij Gateway IP en selecteer Port4 bij Interface.
Kies na vergelijking met bestaande routes een Metric zoals 10 en sla op met Save.

Het voorbeeld gaat uit van 2001:db8:4::1/64 op Port4 en een rechtstreeks bereikbare router op 2001:db8:4::2. Alle IPv6-adressen zijn documentatiewaarden; vervang ze samen door adressen uit uw eigen plan. Leg vóór de wijziging de eerdere routewaarden vast en zorg voor onafhankelijke beheertoegang. Controleer daarna 2001:db8:20::10 met Route lookup, een echte IPv6-clientverbinding en Packet capture met host 2001:db8:20::10; uitgaand verkeer en antwoorden moeten het geplande pad volgen. Ook een IPv6-firewallregel en een retourroute naar het clientnetwerk zijn nodig. De RED/ARP-uitzondering hieronder bewijst niet dat hetzelfde mechanisme voor IPv6 geldt; bevestig een eventueel IPv6-RED-specifiek geval voor de geïnstalleerde build vóór de wijziging.

Bij een route-based IPsec-tunnel met Any-to-Any-subnets kan de route rechtstreeks naar de XFRM-interface wijzen, zonder dat een afzonderlijke gateway nodig is. Als de tunnel concrete Traffic Selectors gebruikt, maakt SFOS de route automatisch aan; configureer dan geen eigen IP-adressen of aanvullende routes op de XFRM-interface. Een XFRM-route is bovendien niet hetzelfde als de versieafhankelijke CLI-uitzondering ipsec_route; het verschil wordt uitgelegd in IPsec-route op Sophos Firewall maken.

Voor een netwerk achter de peer-interface van een Site-to-Site RED-tunnel tussen Sophos Firewalls geldt nog een uitzondering: voer het IP-adres van de peer-RED-interface als gateway in, maar selecteer geen interface. Zo kan de firewall via ARP bepalen welke interface bereikbaar is. Site-to-Site RED tussen twee Sophos Firewalls configureren legt het volledige server- en clientontwerp uit.

Firewallregel, NAT en retourpad

Routing bepaalt het pad. De firewallregel bepaalt of het pakket mag passeren en NAT wijzigt indien nodig de adressen. Deze drie taken worden afzonderlijk geconfigureerd.

Voor het voorbeeld is een regel nodig van clientnetwerk 10.10.0.0/24 naar bestemmingsnetwerk 10.20.0.0/24. De Destination Zone is de zone van Port4. Beperk de regel tot de werkelijk benodigde services en schakel logging in voor de test.

Bij een normaal gerouteerd locatienetwerk is SNAT meestal niet gewenst, omdat de tegenpartij het echte client-IP moet zien. Router 192.0.2.2 heeft dan deze retourroute nodig:

Bestemmingsnetwerk: 10.10.0.0/24
Next Hop: 192.0.2.1

Als op de tegenpartij geen retourroute kan worden ingesteld, kan SNAT technisch helpen. Het verbergt echter het oorspronkelijke client-IP en moet een bewuste ontwerpbeslissing blijven. De samenhang wordt uitgelegd in NAT op Sophos Firewall begrijpen.

Statische routes via de XML API: velden en bewerkingsgrenzen

Bij het automatiseren van statische routes moet u de XML-velden onder UnicastRoute onderscheiden van de labels in de gebruikersinterface. De API-parametertabellen voor SFOS 22.0 en 23.0 documenteren het volgende:

Distance duidt de Metric aan, niet de Administrative Distance: optioneel, standaardwaarde 0, bereik 0–255.
AdministrativeDistance duidt de Administrative Distance aan: optioneel, standaardwaarde 1, bereik 1–255.

Deze API-standaardwaarden zijn geen aanbeveling voor de hierboven getoonde route en bewijzen niet dat weggelaten velden bij een update ongewijzigd blijven. De gewenste prioriteit moet nog steeds met bestaande routes worden vergeleken.

Het XML-voorbeeld bevat ook OldConfiguration met de eerdere velden voor bestemming, gateway, interface en prioriteit. Een beschrijving van dit blok ontbreekt echter in de parametertabel. Het voorbeeld bewijst daarom niet welke velden de te bewerken route identificeren, welke oude waarden verplicht zijn of dat gelijktijdige wijzigingen worden gedetecteerd of atomair worden vergeleken. Automatisering mag hierop geen gegarandeerde koppeling van updates aan routes of gelijktijdigheidscontrole baseren.

Ook voor de adresvelden zijn het voorbeeld en de tabel niet overal consistent:

IPFamily: het voorbeeld toont IPv4/IPv6, terwijl de tabel het gegevenstype INTEGER en de standaardwaarde IPv4 vermeldt.
DestinationIP: de beschrijving noemt IPv4-/IPv6-adressen, maar het gegevenstype is IPADDRESS6.
Netmask: het voorbeeld toont 0.0.0.0, terwijl de tabel een prefix beschrijft als INTEGER met het bereik 0–128.

Hieruit kan geen universele, uitvoerbare IPv4-/IPv6-request worden afgeleid. Verduidelijk en controleer vóór een API-bewerking in productie het requestschema en de eenduidige koppeling aan de bestaande route voor de geïnstalleerde build in een testomgeving. Leg vooraf de eerdere waarden vast en zorg voor onafhankelijke beheertoegang. Controleer daarna de opgeslagen routewaarden, Route Lookup en een echte clientverbinding inclusief het retourpad; de hieronder beschreven rollback blijft noodzakelijk. Zolang het schema of de koppeling onduidelijk is, gebruikt u voor de wijziging de hierboven beschreven procedure in de gebruikersinterface in plaats van een gegokte XML-request.

Voor verwijderen gelden afzonderlijke documentatiegrenzen. De tabellen voor Delete Unicast Route voor SFOS 22.0 en 23.0 markeren DestinationIP en Netmask als verplichte velden. Dit bewijst echter niet dat deze velden een volledige, eenduidige selector vormen voor de te verwijderen route. Alle tien cellen voor standaardwaarden zijn leeg; daaruit volgt noch de waarde 0, noch ‘ongewijzigd’ of null. Bij IPFamily staat alleen het gegevenstype INTEGER, zonder koppeling van toegestane waarden aan IPv4 of IPv6. Een voorbeeld van een Delete-request ontbreekt.

De hierboven beschreven standaardwaarden voor Add en Update en de aannames over OldConfiguration mogen daarom niet op Delete worden toegepast. Zolang het requestschema en de eenduidige koppeling aan de doelroute voor de geïnstalleerde build onduidelijk zijn, gebruikt u voor het verwijderen de procedure in de gebruikersinterface en de hieronder beschreven rollback, geen gegokte XML-verwijderrequest. Leg vooraf de bestaande routewaarden vast en zorg voor onafhankelijke beheertoegang; controleer daarna de routewaarden, Route Lookup en een echte clientverbinding inclusief het retourpad.

De route controleren

Een opgeslagen route is pas gevalideerd wanneer een echte client de tegenpartij bereikt en het retourpad werkt.

De CLI-controles hieronder horen in 4. Device Console, niet in de Advanced Shell, en lezen alleen de huidige toestand. Controleer vóór uitvoering de volledige syntaxis op de geïnstalleerde build met Tab of ?. Voer geen onvolledige opdrachten uit: daardoor kan de service access_server niet meer reageren.

Voer onder Diagnostics > Tools > Route lookup 10.20.0.10 in. De uitvoer moet Port4 tonen.
Controleer in de Device Console de geconfigureerde IPv4- of IPv6-routes en bij concurrentie met SD-WAN of VPN de Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
Start vanaf client 10.10.0.10 een echte verbinding naar 10.20.0.10, bijvoorbeeld Ping of TCP 443, passend bij de firewallregel.
Controleer in Log viewer source, destination, service, Firewall Rule ID en een eventuele NAT Rule ID.
Controleer onder Diagnostics > Packet capture met host 10.20.0.10 of requests via Port4 uitgaan en antwoorden terugkomen.

Als Route Lookup het juiste pad toont maar er geen verkeer loopt, ligt de oorzaak meestal bij de firewallregel, NAT, de retourroute of het doelsysteem. De volledige pakketstroomtest staat in Een Sophos Firewall-regel testen met Log Viewer en Packet Capture.

Bij diepere routingproblemen helpen in de Device Console de laatste vermeldingen uit het Unicast- en kernellog:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log betreft statische Unicast-routes; zebra.log toont de installatie van statische IPv4-Unicast-routes in de kernel. Sophos Firewall-services en logbestanden koppelt verdere logbestanden aan de verantwoordelijke services.

Na een herstart van een interface of tunnel kan een route die alleen een gateway opgeeft aanvankelijk in de routingtabel ontbreken. Ze verschijnt zodra passend verkeer overeenkomt met bestemming en gateway en de firewall de interface selecteert. Een ontbrekende vermelding direct na de herstart bewijst daarom nog geen defect.

Fouten afbakenen en terugdraaien

Route Lookup toont de verkeerde interface

Controleer bestemmingsadres en prefix; een typefout kan met een ander netwerk overeenkomen.
De gateway moet rechtstreeks via de gekozen interface bereikbaar zijn.
Vergelijk concurrerende statische routes en hun Administrative Distance en Metric.
Controleer bij SD-WAN of VPN de huidige volgorde met system route_precedence show. De globale wijziging wordt uitgelegd in Route Precedence veilig wijzigen.

De request gaat naar buiten, maar er komt geen antwoord

Controleer de retourroute op de volgende router en het doelsysteem.
Controleer de firewallregel voor de initiërende richting en bestaande NAT-regels. Een regel in de tegenovergestelde richting is alleen nodig wanneer de tegenpartij zelf nieuwe verbindingen initieert.
Gebruik Packet Capture om vast te stellen of het antwoord op Port4 terugkomt.
Controleer de lokale firewall en de default gateway van het doelsysteem.

Veilige rollback

Een nieuwe IPv4-route wordt eerst uitgeschakeld in plaats van verwijderd. Controleer daarna Route Lookup, een nieuwe clientverbinding en het eerdere pad opnieuw. Verwijder de route en regels of NAT-objecten die uitsluitend voor deze wijziging zijn gemaakt pas wanneer de oorspronkelijke toestand is bevestigd.

Voor IPv6 documenteert Sophos geen aan-uitfunctie. Leg daarom vooraf de bestaande waarden vast en wijzig of verwijder de nieuwe route bij een rollback. Herhaal in een HA-cluster de end-to-end-test na een failover op de nieuwe Primary.