Sophos Firewall RIP konfigurieren und prüfen

RIP verteilt IPv4-Routen automatisch zwischen Routern. Auf Sophos Firewall passt das Protokoll vor allem zu kleinen oder bestehenden Routing-Domains, in denen wenige Router ohne komplexe Pfadauswahl Netze austauschen sollen.

Der sichere Kurzweg ist:

1. Transitnetz, lokale LANs, Peer, erwartete Prefixe und Rückweg dokumentieren.
2. Konfigurationsbackup und unabhängigen Managementzugang vorbereiten.
3. Direkte IP-Erreichbarkeit der Transit-Adressen prüfen.
4. Unter Administration > Device access Dynamic Routing nur für die Peer-Zone oder eine enge Ausnahme erlauben.
5. Unter Routing > RIP RIPv2 wählen und globale Timer zunächst unverändert lassen.
6. Transit- und lokale LAN-Netze unter RIP Networks hinzufügen.
7. LAN-Interfaces per Override interface configuration auf Passive mode setzen.
8. Version und Authentifizierung auf dem Transitinterface mit der Gegenstelle abgleichen.
9. Unter Routing > Information > RIP Status und gelernte Routen prüfen.
10. Route Lookup, Firewall Rule ID und einen echten bidirektionalen Dienst testen.

⚠️ Default information originate und die Redistribution von Connected, Static, OSPF oder BGP bleiben aus, solange nicht jedes angekündigte Prefix und sein Rückweg bekannt sind. Eine breite Redistribution kann Management-, Transit-, Blackhole- oder andere interne Routen unerwartet im ganzen RIP-Domain verteilen.

Dieser Ablauf behandelt RIPv2 für IPv4 im Gateway Mode. RIPv1 wird nur als Legacy-Interopfall eingeordnet. Sophos Firewall unterstützt RIP nicht im Transparent Mode.

Wann RIP passt und wann nicht

RIP ist ein Distanzvektorprotokoll. Es bewertet einen Pfad nach der Zahl der Router-Hops. Eine Route mit kleinerer Metrik wird bevorzugt. Maximal 15 Hops sind erreichbar; Metrik 16 bedeutet unerreichbar.

Das einfache Modell ist ein Vorteil, wenn:

• nur wenige Router beteiligt sind,
• die Topologie klein und weitgehend stabil ist,
• eine bestehende Gegenstelle nur RIP unterstützt,
• automatische Routenpflege wichtiger als schnelle Konvergenz und komplexe Policy ist.

Für einen einzelnen festen Pfad bleibt eine statische Route oft einfacher. Bei mehreren redundanten Wegen, schneller Konvergenz oder grösseren internen Netzen ist OSPF meist das passendere Protokoll. BGP gehört zu Designs mit autonomen Systemen, Providern oder bewusster Routing-Policy.

RIP ersetzt keine Firewall-Regel und überwacht keine Anwendungsqualität. Für eine Auswahl nach Quelle, Dienst, Anwendung, Latenz, Jitter oder Paketverlust ist eine SD-WAN Route die passende Ebene.

RIPv1 und RIPv2 unterscheiden

Für neue Konfigurationen wird RIPv2 verwendet. Es überträgt Subnetzmasken und unterstützt Authentifizierung. RIPv1 ist classful, überträgt keine Subnetzmasken und unterstützt auf Sophos Firewall keine Authentifizierung.

SFOS bietet global unter anderem diese Wahlmöglichkeiten:

• Send V2 and receive both: RIPv2 senden, RIPv1 und RIPv2 empfangen
• V1: RIPv1 senden und empfangen
• V2: RIPv2 senden und empfangen

Im Beispiel verwenden beide Peers RIPv2. Send V2 and receive both kann eine kontrollierte Übergangsphase erleichtern, erweitert aber die akzeptierten Eingaben. Sobald alle Gegenstellen RIPv2 sprechen, wird auf Senden und Empfangen von V2 begrenzt.

RIP Networks und Passive Mode verstehen

Ein RIP Network ist nicht das entfernte Zielnetz. Der Eintrag aktiviert RIP auf lokalen Interfaces, deren IP-Adresse zum angegebenen Netz gehört. Das direkt verbundene Netz wird dadurch im RIP-Prozess berücksichtigt und kann angekündigt werden.

Für das Beispiel wird auf Firewall A sowohl das Transitnetz 198.51.100.0/30 als auch das lokale LAN 10.10.10.0/24 eingetragen:

• Das Transitnetz aktiviert RIP am Interface zum Peer.
• Das LAN wird als erreichbares lokales Netz angekündigt.
• Passive mode am LAN-Interface verhindert, dass die Firewall dort RIP-Updates sendet.

Passive Mode entfernt das LAN nicht aus dem Routingprozess. Es verhindert nur das Senden von RIP-Ankündigungen über dieses Interface. Zusätzlich bleibt Dynamic Routing in der Clientzone deaktiviert, damit Clients keine Routingupdates an die Firewall liefern können.

Die globale Default metric ist die Ausgangsmetrik für redistribuierte Routen. Der Standardwert ist 1. Die Administrative distance entscheidet bei konkurrierenden Routingquellen; Sophos verwendet für RIP standardmässig 120. Diese Werte werden nicht ohne dokumentierten Grund verändert.

Die Standardtimer sind:

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

Timer werden auf allen Peers abgestimmt. Aggressiv verkürzte Werte können bei Paketverlust oder hoher Last Routen unnötig verwerfen und erneut lernen lassen.

Beispieltopologie planen

Das durchgängige Beispiel verbindet zwei LANs:

• Firewall A: Transit-IP 198.51.100.1/30, lokales LAN 10.10.10.0/24
• Router oder Firewall B: Transit-IP 198.51.100.2/30, lokales LAN 10.20.20.0/24
• Transitnetz: 198.51.100.0/30
• Testclient A: 10.10.10.10
• Testserver B: 10.20.20.10

198.51.100.0/24 ist für Dokumentation reserviert. In der eigenen Umgebung werden Transitadressen, Interfaces, Zonen und LAN-Prefixe gemeinsam ersetzt. Die beiden Transit-IPs müssen direkt erreichbar sein.

Firewall A soll 10.20.20.0/24 über 198.51.100.2 lernen. Die Gegenstelle soll 10.10.10.0/24 über 198.51.100.1 lernen. Erst dieser Hin- und Rückweg ermöglicht gerouteten Traffic ohne Source NAT.

Vor der Änderung werden Interface, Zone, vorhandene Routen, Route Precedence, erwartete Metrik und ein erreichbarer Testhost dokumentiert. Ein aktuelles Konfigurationsbackup und ein Managementpfad ausserhalb des neuen Routings erleichtern den Rückweg.

Dynamic Routing gezielt freigeben

Unter Administration > Device access ist Dynamic Routing standardmässig für alle Zonen deaktiviert. Für das Beispiel wird es nur in der Zone des Transitinterfaces erlaubt.

Die Device-Access-Matrix gilt für die ganze Zone. Liegen weitere, nicht vertrauenswürdige Interfaces in derselben Zone, ist eine enge Local Service ACL Exception für das Transitnetz und die vorgesehene Gegenstelle besser. Die Trennung erklärt Device Access und Local Service ACL.

Diese Freigabe betrifft RIP-Pakete zur Firewall. Der Nutzdatenstrom zwischen 10.10.10.0/24 und 10.20.20.0/24 benötigt weiterhin normale Firewall-Regeln. Dynamic Routing wird nicht in der LAN-Zone aktiviert, nur weil das LAN als RIP Network angekündigt wird.

RIPv2 im WebAdmin konfigurieren

Die Konfiguration wird auf beiden Peers gespiegelt. Nur Transit-IP und lokales LAN unterscheiden sich.

1. Globale Werte setzen

Unter Routing > RIP werden die globalen Einstellungen geöffnet:

1. RIP version auf V2 setzen.
2. Default metric auf dem vorhandenen Standard 1 belassen.
3. Administrative distance auf dem vorhandenen Standard 120 belassen.
4. Update, Timeout und Garbage zunächst auf 30, 180 und 120 Sekunden belassen.
5. Default information originate deaktiviert lassen.
6. Keine Redistribution aktivieren.
7. Änderungen speichern.

Default information originate kündigt eine Standardroute in das RIP-Domain an. Das ist nur sinnvoll, wenn diese Firewall bewusst der Ausgang für alle unbekannten Ziele sein soll und der Rückweg sowie der Ausfallfall geplant sind.

2. RIP Networks hinzufügen

Unter Routing > RIP > RIP Networks > Add werden auf Firewall A diese lokalen Netze eingetragen:

1. 198.51.100.0 mit der Subnetzmaske 255.255.255.252
2. 10.10.10.0 mit der Subnetzmaske 255.255.255.0

Auf Gegenstelle B werden das gleiche Transitnetz und 10.20.20.0/24 eingetragen.

Vor dem Speichern wird geprüft, welches lokale Interface jeweils von einem Network getroffen wird. Ein zu breites Network kann RIP auf weiteren Interfaces aktivieren und zusätzliche direkt verbundene Netze in den Prozess einbeziehen.

3. Interface Overrides setzen

Unter Routing > RIP > Override interface configuration werden die beteiligten Interfaces ausgewählt.

Für das Transitinterface gelten:

• Send version: V2
• Receive version: V2
• Passive mode: aus
• Split horizon: passend zum Peer- und Hubdesign
• Authentication: auf beiden Seiten identisch, wenn eingesetzt

Für das LAN-Interface gelten:

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

RIPv2 unterstützt Plaintext- und MD5-Authentifizierung. Plaintext schützt das Kennwort nicht. MD5 authentisiert Routingupdates, verschlüsselt aber weder Prefixe noch Metriken. Transitsegmente bleiben deshalb auf vorgesehene Router begrenzt. Für neue, stärker geschützte oder grössere Designs ist ein moderneres Routingprotokoll über einen kontrollierten Transport meist geeigneter.

Split horizon verhindert normalerweise, dass eine über ein Interface gelernte Route über dasselbe Interface wieder angekündigt wird. Poisoned reverse kann sie dort ausdrücklich mit Metrik 16 als unerreichbar melden. Diese Optionen werden nur geändert, wenn die Hub-, Spoke- oder Mehrfachzugangstopologie es verlangt und die Gegenstelle gemeinsam getestet wird.

4. Gegenstelle spiegeln

Auf Router oder Firewall B werden Version, Timer und Authentifizierung identisch gesetzt. Als Networks dienen 198.51.100.0/30 und 10.20.20.0/24; das Interface zum Receiver-LAN wird passiv.

Eine einseitige Konfiguration reicht nicht. Ohne Ankündigung des Rücknetzes kann Firewall A zwar das entfernte LAN lernen, Antworten finden aber nicht zurück.

Firewall-Regeln, NAT und Route Precedence

Für den Test braucht es auf beiden Firewalls enge, geloggte Regeln für die wirklich benötigten Dienste zwischen 10.10.10.0/24 und 10.20.20.0/24. Die Regelmechanik erklärt Firewall-Regeln richtig erstellen.

Bei einem normal gerouteten Standortnetz bleibt Source NAT aus. Beide Seiten sollen die echte Quelladresse sehen und kennen den Rückweg über RIP. SNAT kann fehlende Rückrouten verdecken und erschwert spätere Auswertung sowie Zugriffskontrolle.

Eine gelernte RIP-Route muss nicht automatisch gewinnen. Längere Prefixe haben Vorrang; danach spielen Routingquelle, Administrative Distance und die globale Route Precedence eine Rolle. Bei einer konkurrierenden statischen, SD-WAN- oder VPN-Route wird unter Diagnostics > Tools > Route lookup der tatsächlich gewählte Pfad geprüft. Route Precedence wird nicht für einen einzelnen RIP-Test global umgestellt.

RIP und den echten Datenpfad abnehmen

Die Abnahme trennt Routing-Austausch, ausgewählte Route und Nutzdatenfluss.

Routes und Status prüfen

Unter Routing > Information > RIP > Routes muss Firewall A das Netz 10.20.20.0/24 mit Next Hop 198.51.100.2 und plausibler Metrik zeigen. Gegenstelle B muss 10.10.10.0/24 über 198.51.100.1 kennen.

Unter Routing > Information > RIP > Status werden verglichen:

• beteiligte Interfaces
• gesendete und empfangene RIP-Versionen
• Update-, Timeout- und Garbage-Timer
• Routingquellen und Redistribution
• Bad Packets und Bad Routes
• verwendete Authentifizierung beziehungsweise Key Chain

Ein sichtbarer Eintrag bestätigt den RIP-Austausch, aber noch nicht, dass diese Route ausgewählt wird oder Nutzdaten passieren.

Route Lookup und Traffic testen

1. Auf Firewall A unter Diagnostics > Tools > Route lookup das Ziel 10.20.20.10 prüfen. Next Hop und Interface müssen zum Transitpfad passen.
2. Auf Gegenstelle B das Ziel 10.10.10.10 prüfen.
3. Vom Client 10.10.10.10 eine echte, erlaubte Verbindung zum Server 10.20.20.10 starten.
4. Im Log viewer Quelle, Ziel, Dienst, Firewall Rule ID, Action und eine mögliche NAT Rule ID prüfen.
5. Unter Diagnostics > Packet capture bestätigen, dass Request und Antwort über die erwarteten Interfaces laufen.

Der vollständige Ablauf steht unter Firewall-Regel mit Log Viewer und Packet Capture testen.

Für einen lesenden Control-Plane-Test kann in der Device Console kurz nach RIP-Paketen gefiltert werden:

tcpdump 'udp port 520'

Die Ausgabe wird mit Ctrl+C beendet. Erwartet werden Updates zwischen den beiden Transitadressen. RIP-Pakete aus einem Client-LAN sind im Beispiel dagegen ein Hinweis auf eine falsche Interface- oder Device-Access-Grenze.

In der Advanced Shell liefern die Logs zusätzlichen Kontext:

cd /log
tail -f ripd.log

ripd.log zeigt protokollspezifische Ereignisse. zebra.log hilft zu prüfen, ob eine dynamisch gelernte Route im Routingstack installiert wurde. Die laufende Ausgabe wird mit Ctrl+C beendet; anschliessend kann tail -f zebra.log verwendet werden. Weitere Dateien ordnet Sophos Firewall Service- und Logdateien ein.

Fehler systematisch eingrenzen

Keine RIP-Route erscheint

Zuerst die direkte Erreichbarkeit der Transitadressen prüfen. Danach müssen Dynamic Routing in der richtigen Peer-Zone, ein zum lokalen Interface passendes RIP Network sowie kompatible Send-/Receive-Versionen vorhanden sein. Bei Authentifizierung müssen Verfahren und Geheimnis übereinstimmen.

tcpdump 'udp port 520' trennt fehlende Pakete von abgelehnten oder unbrauchbaren Updates. Steigen unter Status die Zähler Bad Packets oder Bad Routes, werden Version, Authentifizierung, Subnetz und Gegenstellenkonfiguration verglichen.

Die Route steht unter RIP, wird aber nicht verwendet

Dann funktioniert der Protokollaustausch. Route Lookup zeigt, ob ein spezifischeres Prefix, eine statische Route, SD-WAN, VPN oder eine andere Administrative Distance den Pfad gewinnt. Die RIP-Metrik allein entscheidet nicht zwischen allen Routingquellen.

Keine globale Route Precedence und keine vorhandene produktive Route werden entfernt, bevor ihr Einfluss auf weitere Netze dokumentiert ist.

Der Traffic funktioniert nur in eine Richtung

Die Gegenstelle benötigt die Rückroute, und beide Firewalls benötigen passende Regeln. Zusätzlich werden NAT, asymmetrische Pfade und der Host-Gateway geprüft. Ein vorhandener Hinweg ist kein Beweis für den Rückweg.

Die Route verschwindet und erscheint wieder

Instabile Transitverbindung, Paketverlust, Peer-Neustarts, abweichende Timer oder Authentifizierungsfehler können den Timeout auslösen. Update-, Timeout- und Garbage-Werte werden auf beiden Seiten verglichen. Timer nicht auf Verdacht verkürzen; zuerst Paketpfad und Peerzustand belegen.

Unerwartete Netze werden angekündigt

RIP Networks, Default information originate und jede Redistribution einzeln prüfen. Redistribute connected kann mehr Interfaces erfassen als nur das geplante LAN. Redistribute static kann auch Blackhole- oder Managementrouten verteilen. Die Funktion bleibt deaktiviert, bis eine vollständige Prefixliste und Filterstrategie vorliegt.

HA und Failover kontrolliert testen

In einem HA-Cluster wird nach einem geplanten Failover auf dem aktuellen Primary erneut geprüft:

• RIP Status und beteiligte Interfaces
• gelernte Routen und Alter
• Route Lookup für beide LANs
• ripd.log und zebra.log auf dem Node, der das Ereignis verarbeitet hat
• neue bidirektionale Testverbindung

Der Test erfolgt im Wartungsfenster. Der Artikel verspricht weder eine unterbrechungsfreie RIP-Konvergenz noch den Fortbestand bestehender Sitzungen. Logs liegen pro verarbeitendem Node und werden deshalb bei Bedarf auf beiden Appliances gesichert.

Änderung sicher zurücknehmen

Vor dem Entfernen von RIP muss für jedes gelernte Zielnetz ein alternativer Pfad oder ein geplantes Wartungsfenster vorhanden sein.

Die Rücknahme erfolgt in umgekehrter Reihenfolge:

1. Neu aktivierte Redistribution und Default information originate deaktivieren, falls sie bewusst Teil des Tests waren.
2. Lokale RIP Networks entfernen.
3. Interface Overrides auf den dokumentierten Vorzustand setzen.
4. Globale RIP-Einstellungen zurücknehmen.
5. Dynamic Routing in der Transit-Zone oder die ACL-Ausnahme nur entfernen, wenn kein OSPF-, BGP- oder PIM-Nachbar sie ebenfalls benötigt.
6. Alternative statische oder dynamische Route kontrolliert aktivieren.
7. Route Lookup, Regeln, Managementzugang und echten Traffic erneut prüfen.

Nicht gleichzeitig RIP und den Ersatzpfad entfernen. Eine bestehende Administratorsitzung bleibt offen, bis der Rückweg bestätigt ist.

Checkliste

• Gateway Mode, Interfaces, Zonen und Transitadressen sind dokumentiert.
• Backup und unabhängiger Managementzugang sind vorhanden.
• Beide Transit-IPs erreichen sich direkt.
• Dynamic Routing ist nur für die Peer-Zone oder enge Ausnahme erlaubt.
• Beide Seiten verwenden kompatible RIPv2- und Authentifizierungswerte.
• RIP Networks treffen nur die vorgesehenen lokalen Interfaces.
• Client-LAN-Interfaces verwenden Passive Mode.
• Default Route Origination und Redistribution sind nur bewusst aktiv.
• Routes und Status zeigen die erwarteten Prefixe, Next Hops und Timer.
• Route Lookup bestätigt den gewählten Hin- und Rückweg.
• Firewall-Regeln sind eng, geloggt und ohne unbeabsichtigtes SNAT.
• Ein echter Dienst funktioniert bidirektional.
• Rollback und HA-Test sind dokumentiert.

FAQ