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:

1. Het transitnetwerk, de lokale LAN’s, de peer, verwachte prefixen en het retourpad documenteren.
2. Een configuratieback-up en onafhankelijke beheertoegang voorbereiden.
3. De directe IP-bereikbaarheid tussen de transitadressen testen.
4. Onder Administration > Device access Dynamic Routing alleen voor de peerzone of via een beperkte uitzondering toestaan.
5. Onder Routing > RIP RIPv2 selecteren en de globale timers aanvankelijk ongewijzigd laten.
6. Het transitnetwerk en de lokale LAN-netwerken onder RIP Networks toevoegen.
7. De LAN-interfaces via Override interface configuration op Passive mode zetten.
8. Versie en authenticatie op de transitinterface afstemmen op de peer.
9. Onder Routing > Information > RIP de status en geleerde routes controleren.
10. 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 management-, transit-, blackhole- of andere interne routes onverwacht door het volledige RIP-domein 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.

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.

SFOS biedt onder andere deze globale keuzes:

• 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 een gecontroleerde overgang vergemakkelijken, maar verruimt de geaccepteerde invoer. Zodra alle peers RIPv2 spreken, worden zowel verzenden als ontvangen beperkt tot 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 globale Default metric is de beginmetric voor geredistribueerde routes. De standaardwaarde is 1. Administrative distance beslist tussen concurrerende routingbronnen; Sophos gebruikt standaard 120 voor RIP. Deze waarden worden niet zonder gedocumenteerde reden gewijzigd.

De standaardtimers zijn:

• Update: 30 seconden
• Timeout: 180 seconden
• Garbage: 120 seconden

Timers worden op alle peers afgestemd. Agressief verkorte waarden kunnen ertoe leiden dat routes bij pakketverlies of hoge belasting onnodig worden verwijderd en opnieuw geleerd.

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
• Router of 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. In een echte omgeving worden transitadressen, interfaces, zones en LAN-prefixen gezamenlijk vervangen. De twee transit-IP’s moeten direct 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.

Vóór de wijziging worden interface, zone, bestaande routes, Route Precedence, verwachte metric en een bereikbare testhost gedocumenteerd. Een actuele configuratieback-up en een beheerpad dat onafhankelijk is van de nieuwe routing vereenvoudigen het herstel.

Dynamic Routing beperkt toestaan

Onder Administration > Device access is Dynamic Routing standaard voor alle zones uitgeschakeld. Voor het voorbeeld wordt het alleen in de zone van de transitinterface toegestaan.

De Device Access-matrix geldt voor de volledige zone. Als andere, niet-vertrouwde interfaces dezelfde zone delen, is een beperkte Local Service ACL Exception voor het transitnetwerk en de bedoelde peer beter. Device Access en Local Service ACL legt deze scheiding uit.

Deze toestemming betreft RIP-pakketten naar de firewall. De datastroom tussen 10.10.10.0/24 en 10.20.20.0/24 vereist nog steeds normale firewallregels. Dynamic Routing wordt niet in de LAN-zone geactiveerd alleen omdat het LAN als RIP Network wordt aangekondigd.

RIPv2 in WebAdmin configureren

De configuratie wordt op beide peers gespiegeld. Alleen het transit-IP en het lokale LAN verschillen.

1. De globale waarden instellen

Open de globale instellingen onder Routing > RIP:

1. Stel RIP version in op V2.
2. Laat Default metric op de bestaande standaardwaarde 1 staan.
3. Laat Administrative distance op de bestaande standaardwaarde 120 staan.
4. Laat Update, Timeout en Garbage aanvankelijk op 30, 180 en 120 seconden staan.
5. Laat Default information originate uitgeschakeld.
6. Activeer geen redistributie.
7. Sla de wijzigingen op.

Default information originate kondigt een standaardroute in het RIP-domein aan. 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.

2. RIP Networks toevoegen

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

1. 198.51.100.0 met subnetmasker 255.255.255.252
2. 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

Selecteer onder Routing > RIP > Override interface configuration de deelnemende interfaces.

Voor de transitinterface gelden:

• Send version: V2
• Receive version: V2
• Passive mode: uit
• Split horizon: passend bij het peer- en hubontwerp
• Authentication: identiek aan beide zijden wanneer gebruikt

Voor de LAN-interface gelden:

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

RIPv2 ondersteunt authenticatie met plaintext en MD5. Plaintext beschermt het wachtwoord niet. MD5 authenticeert routingupdates, maar versleutelt noch prefixen noch metrics. Transitsegmenten blijven daarom beperkt tot de bedoelde routers. Voor nieuwe, sterker beveiligde of grotere ontwerpen is een moderner routingprotocol via gecontroleerd transport meestal geschikter.

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

Op Router of Firewall B worden dezelfde versie, timers en authenticatie ingesteld. Gebruik 198.51.100.0/30 en 10.20.20.0/24 als Networks en maak de interface naar het ontvanger-LAN 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.

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.

Een geleerde RIP-route wint niet noodzakelijk automatisch. Langere prefixen hebben voorrang; daarna spelen ook routingbron, Administrative Distance en globale Route Precedence een rol. Wanneer een statische, SD-WAN- of VPN-route concurreert, toont Diagnostics > Tools > Route lookup het daadwerkelijk geselecteerde pad. Route Precedence wordt niet globaal gewijzigd voor één RIP-test.

RIP en het echte datapad controleren

De controle scheidt de routinguitwisseling, geselecteerde route en datastroom.

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
• Bad Packets en Bad Routes
• de gebruikte authenticatie of Key Chain

Een zichtbare invoer bevestigt de RIP-uitwisseling, maar nog niet dat deze route wordt geselecteerd of dat dataverkeer passeert.

Route Lookup en verkeer testen

1. Controleer op Firewall A bestemming 10.20.20.10 onder Diagnostics > Tools > Route lookup. Next hop en interface moeten bij het transitpad passen.
2. Controleer op peer B bestemming 10.10.10.10.
3. Start vanaf client 10.10.10.10 een echte toegestane verbinding met server 10.20.20.10.
4. Controleer in Log viewer bron, bestemming, service, Firewall Rule ID, Action en een eventuele NAT Rule ID.
5. 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.

Voor een alleen-lezen controle van de control plane kan in Device Console kort op RIP-pakketten worden gefilterd:

tcpdump 'udp port 520'

Stop de uitvoer met Ctrl+C. Updates worden tussen de twee transitadressen verwacht. RIP-pakketten uit een client-LAN wijzen in dit voorbeeld daarentegen op een onjuiste interface- of Device Access-grens.

In Advanced Shell geven de logs extra context:

cd /log
tail -f ripd.log

ripd.log toont protocolspecifieke gebeurtenissen. zebra.log helpt bepalen of een dynamisch geleerde route in de routingstack is geïnstalleerd. Stop de live-uitvoer met Ctrl+C; daarna kan tail -f zebra.log worden gebruikt. Sophos Firewall service- en logbestanden deelt andere bestanden in.

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.

tcpdump 'udp port 520' onderscheidt ontbrekende pakketten van geweigerde of onbruikbare updates. Als de tellers Bad Packets of Bad Routes onder Status oplopen, vergelijk dan versie, authenticatie, subnet en peerconfiguratie.

De route staat onder RIP, maar wordt niet gebruikt

De protocoluitwisseling werkt dan. Route Lookup toont of een specifiekere prefix, statische route, SD-WAN, VPN of andere Administrative Distance wint. De RIP-metric alleen beslist niet tussen alle routingbronnen.

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

Een onstabiele transitverbinding, pakketverlies, peerrestarts, afwijkende timers of authenticatiefouten kunnen de timeout activeren. Vergelijk Update-, Timeout- en Garbage-waarden aan beide zijden. Verkort timers niet op basis van een vermoeden; bewijs eerst het pakketpad en de peerstatus.

Onverwachte netwerken worden aangekondigd

Controleer RIP Networks, Default information originate en elke redistributieoptie afzonderlijk. Redistribute connected kan meer interfaces omvatten dan alleen het geplande LAN. Redistribute static kan ook blackhole- of managementroutes verspreiden. Laat de functie uitgeschakeld totdat een volledige prefixlijst en filterstrategie beschikbaar zijn.

HA en failover gecontroleerd testen

Controleer in een HA-cluster na een geplande failover opnieuw op de huidige Primary:

• RIP Status en de deelnemende interfaces
• geleerde routes en hun leeftijd
• Route Lookup voor beide LAN’s
• ripd.log en zebra.log op de node die de gebeurtenis heeft verwerkt
• een nieuwe bidirectionele testverbinding

Voer de test in een onderhoudsvenster uit. Dit artikel belooft noch ononderbroken RIP-convergentie noch behoud van bestaande sessies. Logs worden per verwerkende node opgeslagen en daarom zo nodig op beide appliances verzameld.

De wijziging veilig terugdraaien

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

Draai de wijziging in omgekeerde volgorde terug:

1. Schakel nieuw geactiveerde redistributie en Default information originate uit als deze bewust deel van de test waren.
2. Verwijder de lokale RIP Networks.
3. Zet Interface Overrides terug naar de gedocumenteerde vorige toestand.
4. Draai de globale RIP-instellingen terug.
5. Verwijder Dynamic Routing uit de transitzone of de ACL-uitzondering alleen als geen OSPF-, BGP- of PIM-neighbor deze ook nodig heeft.
6. Activeer de alternatieve statische of dynamische route gecontroleerd.
7. Controleer Route Lookup, regels, beheertoegang en echt verkeer opnieuw.

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

Checklist

• Gateway Mode, interfaces, zones en transitadressen zijn gedocumenteerd.
• Een back-up en onafhankelijke beheertoegang zijn beschikbaar.
• Beide transit-IP’s kunnen elkaar direct bereiken.
• Dynamic Routing is alleen voor de peerzone of een beperkte uitzondering toegestaan.
• Beide zijden gebruiken compatibele RIPv2- en authenticatiewaarden.
• RIP Networks komen alleen overeen met de bedoelde lokale interfaces.
• Client-LAN-interfaces gebruiken Passive Mode.
• Default Route Origination en redistributie zijn alleen bewust ingeschakeld.
• Routes en Status tonen de verwachte prefixen, next hops en timers.
• Route Lookup bevestigt de geselecteerde heen- en retourpaden.
• Firewallregels zijn beperkt, gelogd en vrij van onbedoelde SNAT.
• Een echte service werkt bidirectioneel.
• Rollback en HA-test zijn gedocumenteerd.

FAQ