RIP op Sophos Firewall configureren en controleren

RIP verdeelt automatisch IPv4-routes tussen routers. Op Sophos Firewall is het protocol vooral geschikt voor kleine of bestaande routingdomeinen waarin enkele routers netwerken moeten uitwisselen zonder complexe padselectie.

De veilige korte procedure is:

Het transitnetwerk, de lokale LAN’s, de peer, verwachte prefixen en het retourpad documenteren.
Een configuratieback-up en onafhankelijke beheertoegang voorbereiden.
De directe IP-bereikbaarheid tussen de transitadressen testen.
Onder Administration > Device access Dynamic Routing alleen voor de peerzone of via een beperkte uitzondering toestaan.
Onder Routing > RIP RIPv2 selecteren en de globale timers aanvankelijk ongewijzigd laten.
Het transitnetwerk en de lokale LAN-netwerken onder RIP Networks toevoegen.
De LAN-interfaces via Override interface configuration op Passive mode zetten.
Versie en authenticatie op de transitinterface afstemmen op de peer.
Onder Routing > Information > RIP de status en geleerde routes controleren.
Route Lookup, Firewall Rule ID en een echte bidirectionele service testen.

⚠️ Default information originate en de redistributie van Connected, Static, OSPF of BGP blijven uitgeschakeld totdat elke aangekondigde prefix en het bijbehorende retourpad bekend zijn. Brede redistributie kan onbedoeld Connected- of Static-routes door het hele RIP-routingdomein verspreiden.

Deze procedure behandelt RIPv2 voor IPv4 in Gateway Mode. RIPv1 wordt alleen als legacy-interoperabiliteitsgeval besproken. Sophos Firewall ondersteunt RIP niet in Transparent Mode.

Wanneer RIP past en wanneer niet

RIP is een distance-vectorprotocol. Het beoordeelt een pad op basis van het aantal routerhops. Een route met een lagere metric krijgt de voorkeur. Maximaal 15 hops zijn bereikbaar; metric 16 betekent onbereikbaar.

Routers wisselen regelmatig routingupdates uit. De ontvangende router verwerkt de wijzigingen in zijn routingtabel, verhoogt de padmetric met 1 en gebruikt de afzender als next hop.

Dit eenvoudige model is voordelig wanneer:

slechts enkele routers deelnemen,
de topologie klein en grotendeels stabiel is,
een bestaande peer alleen RIP ondersteunt,
automatisch routebeheer belangrijker is dan snelle convergentie en complexe policy.

Voor één vast pad is een statische route vaak eenvoudiger. Bij meerdere redundante paden, snelle convergentie of grotere interne netwerken is OSPF meestal het geschiktere protocol. BGP hoort bij ontwerpen met autonome systemen, providers of bewust routingbeleid.

RIP vervangt geen firewallregel en bewaakt geen applicatiekwaliteit. Een SD-WAN-route is de juiste laag voor selectie op basis van bron, service, applicatie, latency, jitter of pakketverlies.

RIPv1 en RIPv2 onderscheiden

Voor nieuwe configuraties wordt RIPv2 gebruikt. Het verstuurt subnetmaskers en ondersteunt authenticatie. RIPv1 is classful, verstuurt geen subnetmaskers en ondersteunt op Sophos Firewall geen authenticatie.

Onder RIP version biedt SFOS deze drie instellingen:

Send V2 and receive both: RIPv2 verzenden en RIPv1 en RIPv2 ontvangen
V1: RIPv1 verzenden en ontvangen
V2: RIPv2 verzenden en ontvangen

In het voorbeeld gebruiken beide peers RIPv2. Send V2 and receive both kan nuttig zijn tijdens een gecontroleerde overgang, maar blijft RIPv1-updates accepteren. Zodra alle peers RIPv2 gebruiken, stelt u zowel de verzend- als de ontvangstversie in op V2.

RIP Networks en Passive Mode begrijpen

Een RIP Network is niet het externe doelnetwerk. De invoer activeert RIP op lokale interfaces waarvan het IP-adres overeenkomt met het opgegeven netwerk. Daardoor wordt het direct verbonden netwerk onderdeel van het RIP-proces en kan het worden aangekondigd.

Voor het voorbeeld worden op Firewall A zowel het transitnetwerk 198.51.100.0/30 als het lokale LAN 10.10.10.0/24 ingevoerd:

Het transitnetwerk activeert RIP op de peergerichte interface.
Het LAN wordt als bereikbaar lokaal netwerk aangekondigd.
Passive mode op de LAN-interface voorkomt dat de firewall daar RIP-updates verzendt.

Passive Mode verwijdert het LAN niet uit het routingproces. Het voorkomt alleen dat via deze interface RIP-aankondigingen worden verzonden. Bovendien blijft Dynamic Routing in de clientzone uitgeschakeld, zodat clients geen routingupdates naar de firewall kunnen sturen.

De voorbeeldtopologie plannen

Het doorlopende voorbeeld verbindt twee LAN’s:

Firewall A: Transit-IP 198.51.100.1/30, lokaal LAN 10.10.10.0/24
Firewall B: transit-IP 198.51.100.2/30, lokaal LAN 10.20.20.0/24
Transitnetwerk: 198.51.100.0/30
Testclient A: 10.10.10.10
Testserver B: 10.20.20.10

198.51.100.0/24 is gereserveerd voor documentatie. Vervang het transitnetwerk, de transit-IP-adressen, LAN-prefixen en testhosts consequent door waarden uit uw eigen omgeving. Neem de documentatieadressen niet ongewijzigd over in een productieconfiguratie. De twee transit-IP-adressen moeten rechtstreeks bereikbaar zijn.

Firewall A moet 10.20.20.0/24 via 198.51.100.2 leren. De peer moet 10.10.10.0/24 via 198.51.100.1 leren. Alleen dit heen- en retourpad maakt gerouteerd verkeer zonder source NAT mogelijk.

Voor de verandering documenteert u de interface, zone, bestaande routes, Route Precedence, verwachte metriek en een bereikbare testhost. Een actuele configuratieback-up en een beheerpad onafhankelijk van de nieuwe routering zorgen voor een gecontroleerde terugrol.

Dynamic Routing beperkt toestaan

Controleer onder Administration > Device access eerst de zones waarvoor Dynamic Routing momenteel is toegestaan. Sta in het voorbeeld Dynamic Routing uitsluitend toe voor de specifieke transitzone of via een ACL-uitzondering voor de peer.

De Device Access matrix is van toepassing op de gehele zone. Voor een toegewijde, vertrouwde transitzone kunt u Dynamic Routing daar inschakelen. Als de toegang tot een specifieke peer of een specifiek transitnetwerk moet worden beperkt, laat u het selectievakje voor de zone uit en maakt u onder Local service ACL exception rule een strikt beperkte Allow-uitzondering voor de bron en service. Gelijktijdige toegang voor de hele zone zou die beperking tenietdoen. Device Access en Local Service ACL verklaart het onderscheid.

Deze toestemming betreft RIP-pakketten naar de firewall en kan niet door een normale firewallregel worden vervangen. De gegevensstroom tussen 10.10.10.0/24 en 10.20.20.0/24 daarentegen vereist nog steeds normale firewallregels. Dynamic Routing is niet ingeschakeld in de LAN-zone alleen omdat het LAN wordt geadverteerd als een RIP Network. Documenteer vóór de wijziging de effectieve Device Access-status en ga niet uit van een algemene standaardtoestemming.

Als beide firewalls RIP-updates via de transitinterface verzenden, maar alleen Firewall A inkomende updates toestaat, worden routes slechts aan één kant geleerd: A ontvangt de updates van B en leert 10.20.20.0/24 via 198.51.100.2. B blijft zijn updates verzenden, maar verwerpt de inkomende updates van A omdat op B de toestemming voor Dynamic Routing ontbreekt. B leert daardoor de door A aangekondigde route naar 10.10.10.0/24 niet via RIP.

Dit is een asymmetrie in de uitwisseling van routinginformatie (het control plane), geen bewijs van een specifiek probleem met dataverkeer. Controleer beide zijden onder Routing > Information > RIP > Routes en controleer de effectieve ontvangsttoestemming op de firewall die geen routes leert. Een noodzakelijke correctie blijft beperkt tot de werkelijke peerzone of een strikt beperkte ACL-uitzondering; geef WAN niet algemeen vrij. Controleer daarna Route Lookup, firewallregels, NAT en de werkelijke heen- en retourpaden afzonderlijk.

RIPv2 in WebAdmin configureren

In het voorbeeld is de peer aan zijde B een tweede Sophos Firewall. Bij twee Sophos Firewalls wordt de configuratie op de peer gespiegeld; alleen het transit-IP en het lokale LAN verschillen. Is de peer een router van een andere leverancier, configureer dan RIPv2, het transitnetwerk, het lokale LAN, Passive mode en eventuele authenticatie met de overeenkomstige functies van dat apparaat.

1. De globale waarden instellen

Open de globale instellingen onder Routing > RIP:

Stel RIP version in op V2.
Laat Default metric op de bestaande standaardwaarde 1 staan.
Laat Administrative distance op de bestaande standaardwaarde 120 staan.
Laat Update, Timeout en Garbage aanvankelijk op 30, 180 en 120 seconden staan.
Laat Default information originate uitgeschakeld.
Activeer geen redistributie.
Selecteer Apply om de wijzigingen op te slaan.

Default information originate genereert en kondigt een standaardroute in het RIP-domein aan en is standaard uitgeschakeld. Dit is alleen passend wanneer deze firewall bewust de uitgang voor alle onbekende bestemmingen moet zijn en zowel het retourpad als de uitvalsituatie zijn gepland.

De Default metric voor herverdeelde routes is standaard 1; het toegestane bereik is 1 tot 16. Administrative distance is standaard 120 en staat waarden toe van 1 tot 255. Laat beide waarden ongewijzigd tenzij het routeringsontwerp een reden heeft om ze te wijzigen.

Administrative distance helpt de router de betere route tussen concurrerende routingbronnen te kiezen; de RIP-metric vergelijkt daarentegen paden binnen RIP.

De standaardwaarden voor Update, Timeout en Garbage zijn 30, 180 en 120 seconden. Update bepaalt het interval tussen twee periodieke routingupdates. De officiële documentatie voor SFOS 22.0 vermeldt voor elk van deze drie timers 5 tot 2147483647 seconden; de documentatie voor SFOS 23.0 vermeldt telkens 1 tot 32767 seconden en noemt Timeout Time-out. Dit zijn versiegebonden documentatiewaarden, geen garantie over invoervalidatie op een geteste build. Dit voorbeeld behoudt de standaardwaarden; kies afwijkende waarden alleen wanneer beide peers een gedocumenteerd plan voor timers en uitvalafhandeling delen.

Als redistributie bewust nodig is, activeer dan onder Routing > RIP alleen de geplande bronnen: Redistribute connected voor direct verbonden routes, Redistribute static voor statische routes, Redistribute OSPF voor OSPF-routes en Redistribute BGP voor BGP-routes. Stel voor elke geactiveerde bron de bijbehorende metric voor geredistribueerde routes in; alle vier velden staan 0 tot 16 toe, anders dan de globale Default metric. Kies waarden op basis van het gedocumenteerde routingontwerp, niet door een algemene waarde over te nemen. Sla op met Apply en controleer daarna de verwachte en onverwachte prefixen en het retourpad zoals hieronder beschreven. In het voorbeeld blijven alle vier bronnen uitgeschakeld.

2. RIP Networks toevoegen

Voer onder Routing > RIP > RIP Networks > Add deze lokale netwerken in op Firewall A:

198.51.100.0 met subnetmasker 255.255.255.252
10.10.10.0 met subnetmasker 255.255.255.0

Voer op peer B hetzelfde transitnetwerk en 10.20.20.0/24 in.

Controleer vóór het opslaan welke lokale interface door elk Network wordt getroffen. Een te breed Network kan RIP op extra interfaces activeren en meer direct verbonden netwerken in het proces opnemen.

3. Interface Overrides instellen

Onder Routing > RIP > Override interface configuration, gebruik Select interface om de deelnemende interface te kiezen.

Send en Receive staan onafhankelijk van elkaar V1, V2 of beide versies toe. De selectie per interface overschrijft de globale RIP version. Send staat standaard op V2; de hieronder gekozen ontvangstversie V2 is een bewuste voorbeeldinstelling, geen uitspraak over de Receive-standaardwaarde. Passive mode is standaard uitgeschakeld en wordt bewust ingeschakeld voor het LAN.

Schakel voor een bewust geauthenticeerde RIPv2-verbinding Authentication in en voer een wachtwoord in; de configuratie moet op beide peers overeenkomen. Als authenticatie voor een RIPv1-interface wordt geselecteerd, verstuurt deze routingupdates maar accepteert deze geen routes. Als beide versies worden geselecteerd, blijft RIPv2 met authenticatie werken. Sophos raadt aan RIPv1 op een andere interface te configureren dan geauthenticeerd RIPv2.

Voor de transitinterface gelden:

Send version: V2
Receive version: V2
Passive mode: uit
Split horizon: behoudt de gedocumenteerde vorige toestand; SFOS schakelt deze optie standaard uit
Poisoned reverse: alleen beschikbaar wanneer Split Horizon is ingeschakeld en standaard uitgeschakeld
Authentication: controleer de effectieve vorige toestand en stel doelbewust beide zijden identiek in

Voor de LAN-interface gelden:

Send version: V2
Receive version: V2
Passive mode: aan

Sla de selectie op met Save. RIPv2 ondersteunt platte tekst en MD5 authenticatie. Plaintext beschermt het wachtwoord niet. MD5 authenticeert routing updates, maar versleutelt noch prefixes noch metrics. Transitsegmenten blijven daarom beperkt tot de beoogde routers. De openbare CLI-help voor SFOS 22 en de WebAdmin-help spreken elkaar tegen over de standaardstatus van authenticatie. Deze handleiding veronderstelt daarom geen standaard: controleer beide transit interfaces en configureer ze vervolgens bewust en identiek.

Split horizon voorkomt normaal dat een via een interface geleerde route opnieuw via dezelfde interface wordt aangekondigd. Poisoned reverse kan deze daar expliciet met metric 16 als onbereikbaar melden. Wijzig deze opties alleen wanneer de hub-, spoke- of multi-access-topologie dit vereist en test ze samen met de peer.

4. De peer spiegelen

Stel op Firewall B dezelfde versie, timers en authenticatie in. Gebruik 198.51.100.0/30 en 10.20.20.0/24 als Networks, en maak de local-LAN interface passief.

Een eenzijdige configuratie is niet voldoende. Zonder aankondiging van het retournetwerk kan Firewall A het externe LAN leren, maar vinden antwoorden geen weg terug.

Waarom deze gids WebAdmin gebruikt voor wijzigingen

De gedocumenteerde toegang tot de CLI verschilt per versie: de help voor SFOS 22.0 noemt 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, de prompt rip> en daarna enable. De help voor SFOS 23.0 noemt daarentegen 3. Route Configuration > 1. Configure Unicast Routing, de prompt router# en daarna router#configure terminal. De tabelvermelding router rip is een CLI-commando, geen extra menukeuze. Dit is een vergelijking van de gedocumenteerde toegangspunten, geen uitvoerbare configuratiereeks.

De openbare CLI-help voor SFOS 22 bevat onjuist samengevoegde authenticatiecommando’s en documenteert niet alle commando’s die nodig zijn voor opslaan en valideren. Ook de help voor SFOS 23.0 blijft onduidelijk over de CLI-contexten voor authenticatie en het MD5-voorbeeld. Gecorrigeerde plaintextvoorbeelden maken de overige commando’s niet automatisch tot een betrouwbare reeks. Deze handleiding leidt uit dat materiaal geen onbevestigde syntaxis of stappen voor contextwisselingen of opslaan af.

Configuratie en terugrol verlopen daarom via de gedocumenteerde WebAdmin-velden. Gebruik de CLI alleen voor gedocumenteerde, alleen-lezen supportdiagnostiek voor de geïnstalleerde SFOS-versie.

Firewallregels, NAT en Route Precedence

Voor de test hebben beide firewalls beperkte, gelogde regels nodig voor de werkelijk benodigde services tussen 10.10.10.0/24 en 10.20.20.0/24. Firewallregels correct maken legt de regelmechaniek uit.

In een normaal gerouteerd locatienetwerk blijft source NAT uitgeschakeld. Beide zijden moeten het echte bronadres zien en het retourpad via RIP kennen. SNAT kan ontbrekende retourroutes verbergen en latere analyse en toegangscontrole bemoeilijken.

Binnen RIP behoudt SFOS de route met de laagste hop metriek voor een bestemming. Dat alleen bewijst niet dat dit pad ook de actieve systeembrede route is. Wanneer een statische, SD-WAN, of VPN-route strijdt, gebruik Diagnostics > Tools > Route lookup om het pad te controleren dat daadwerkelijk is geselecteerd. Verander Route Precedence wereldwijd niet voor een enkele RIP-test.

RIP en het echte datapad controleren

Validatie behandelt drie vragen afzonderlijk: Worden routes uitgewisseld, is de juiste route geselecteerd en werkt dataverkeer?

Routes en Status controleren

Onder Routing > Information > RIP > Routes moet Firewall A netwerk 10.20.20.0/24 met next hop 198.51.100.2 en een plausibele metric tonen. Peer B moet 10.10.10.0/24 via 198.51.100.1 kennen.

Vergelijk onder Routing > Information > RIP > Status:

de deelnemende interfaces
verzonden en ontvangen RIP-versies
Update-, Timeout- en Garbage-timers
routingbronnen en redistributie
route From, Tag, en Time
inkomende en uitgaande updatefilters, indien ingesteld
Key-chain naam, indien geconfigureerd
Bad Packets en Bad Routes

Een zichtbare RIP-route bevestigt de route-uitwisseling, maar niet dat SFOS deze selecteert of dataverkeer via die route stuurt. De statusweergave bewijst niet welk geheim wordt gebruikt; beheer en controleer dat geheim volgens gecontroleerde procedures op beide peers.

Route Lookup en verkeer testen

Controleer op Firewall A bestemming 10.20.20.10 onder Diagnostics > Tools > Route lookup. Next hop en interface moeten bij het transitpad passen.
Controleer op peer B bestemming 10.10.10.10.
Start vanaf client 10.10.10.10 een echte toegestane verbinding met server 10.20.20.10.
Controleer in Log viewer bron, bestemming, service, Firewall Rule ID, Action en een eventuele NAT Rule ID.
Bevestig onder Diagnostics > Packet capture dat verzoek en antwoord via de verwachte interfaces lopen.

De volledige procedure staat in Een firewallregel testen met Log Viewer en Packet Capture.

Fouten systematisch afbakenen

Er verschijnt geen RIP-route

Test eerst de directe bereikbaarheid tussen de transitadressen. Vervolgens moet Dynamic Routing in de juiste peerzone actief zijn, moet een RIP Network bij de lokale interface passen en moeten compatibele verzend- en ontvangstversies aanwezig zijn. Bij authenticatie moeten methode en geheim overeenkomen.

Als de Bad Packets of Bad Routes tellers stijgen onder Status, vergelijk de versie, authenticatie, subnet en peer configuratie. Als de counters ongewijzigd blijven en de diagnoseweergaven geen RIP verkeer van de peer tonen, controleer dan eerst de interface-toewijzing en Local Service ACL. Wijzig globale RIP waarden alleen na die controles.

De route staat onder RIP, maar wordt niet gebruikt

De protocol uitwisseling werkt dan. Route Lookup toont welk pad daadwerkelijk actief is. De RIP metriek vergelijkt RIP paden; op zichzelf beslist het niet tussen alle routeringsbronnen.

Verwijder geen globale Route Precedence of bestaande productieroute voordat het effect op andere netwerken is gedocumenteerd.

Het verkeer werkt maar in één richting

De peer heeft de retourroute nodig en beide firewalls hebben passende regels nodig. Controleer daarnaast NAT, asymmetrische paden en de hostgateway. Een bestaand heenpad bewijst het retourpad niet.

De route verdwijnt en verschijnt opnieuw

Als er geen updates arriveren voordat de geconfigureerde Timeout verloopt, wordt de route ongeldig; tijdens de Garbage periode adverteert SFOS deze met metric 16 en verwijdert het dan. Vergelijk bereikbaarheid, peer state, en de Update, Timeout en Garbage waarden aan beide kanten voordat u een timer verandert.

Onverwachte netwerken worden aangekondigd

Controleer RIP Networks, Default information originate en elke herverdelingsoptie afzonderlijk. Herdistributie kan meer Connected of Static routes omvatten dan de LAN’s die voor dit voorbeeld bedoeld zijn. Laat het uitgeschakeld totdat elke prefix die daadwerkelijk moet worden gedistribueerd bekend is.

De wijziging veilig terugdraaien

Voordat RIP wordt verwijderd, moet voor elk geleerd doelnetwerk een alternatief pad of gepland onderhoudsvenster bestaan.

Terugrollen begint met het vervangende pad, niet met het verwijderen van de actieve RIP-routes:

Schakel de alternatieve statische of dynamische route in en valideer deze met Route Lookup, beheertoegang en echt bidirectioneel verkeer.
Schakel nieuw ingeschakelde redistributie en Default information originate uit als ze bewust deel van de test waren; controleer daarna opnieuw de verwachte prefixen.
Verwijder lokale RIP Networks een voor een, controleer de voor- en terugweg na elke stap.
Herstel de interface-overrides en globale RIP-instellingen naar de gedocumenteerde vorige toestand.
Verwijder Dynamic Routing uit de transitzone of de ACL uitzondering als laatste, en alleen als geen OSPF, BGP of PIM buurman het ook nodig heeft.
Tot slot, controleer Route Lookup, regels, management toegang, en echt verkeer.

Verwijder RIP en het vervangende pad niet gelijktijdig. Houd een bestaande beheerderssessie open totdat het retourpad is bevestigd.

Goedkeuringscontrole

Beide firewalls tonen de verwachte RIP routes met de juiste volgende hop en een plausibele metriek.
Route Lookup bevestigt de beoogde voor- en retourpaden.
Er verschijnen geen onverwachte prefixen of onbedoelde redistributie.
Beperkte, gelogde firewallregels worden toegepast zonder onbedoelde SNAT.
Een echte service werkt bidirectioneel.
Het vervangende pad en de terugrolprocedure zijn gedocumenteerd en uitvoerbaar.