Sophos Firewall ARP- und NDP-Neighbor-Cache prüfen

Wenn ein Gerät trotz korrekter IP-Adresse nicht erreichbar ist, muss nicht sofort eine Firewall-Regel oder Route falsch sein. Im lokalen Netzwerk benötigt die Sophos Firewall zusätzlich die passende MAC-Adresse des Ziels. Diese Zuordnung speichert sie im Neighbor-Cache.

Unter Network > Neighbors (ARP–NDP) lässt sich prüfen, welche IP-Adresse aktuell zu welcher MAC-Adresse und welchem Interface gehört. Erst wird der bestehende Eintrag dokumentiert und mit der tatsächlichen Netzsituation verglichen. Nur wenn die Zuordnung veraltet ist, wird der betroffene Cache geleert und neu gelernt.

Die Bezeichnungen und Befehle in diesem Ablauf entsprechen SFOS 22.0. Die Diagnose beginnt im WebAdmin; die Device Console kommt nur für die unten ausdrücklich dokumentierten Zusatzprüfungen zum Einsatz.

⚠️ Flush leert den ausgewählten IPv4- oder IPv6-Cache, nicht nur eine einzelne Zeile. Auf einer produktiven Firewall sollte man den aktuellen Eintrag deshalb zuerst sichern, den Test eingrenzen und den Cache nicht während einer Lastspitze leeren.

Was ARP, NDP und der Neighbor-Cache leisten

ARP ordnet im lokalen Layer-2-Segment eine IPv4-Adresse einer MAC-Adresse zu. Gemeint ist damit ein direkt erreichbares Gerät, typischerweise im selben VLAN. Für IPv6 übernimmt Neighbor Discovery Protocol (NDP) diese Aufgabe mit ICMPv6. Die Firewall benötigt diese Information, bevor sie ein Paket über ein direkt verbundenes Interface an den nächsten Nachbarn senden kann.

Die dynamisch gelernten Zuordnungen bleiben standardmässig 600 Sekunden im Cache. Danach werden sie bei Bedarf neu gelernt. Ein veralteter Eintrag kann beispielsweise nach einem Geräte-, Netzwerkkarten- oder VM-Wechsel entstehen. Eine doppelt vergebene IP-Adresse kann dagegen dazu führen, dass sich die sichtbare MAC-Adresse wiederholt ändert.

Unter Neighbor cache entry timeout lässt sich das automatische Flush-Intervall ändern und mit Apply übernehmen. Ein kürzerer Wert erzwingt häufigeres Neulernen und ist keine Reparatur für doppelte IP-Adressen, falsche VLANs oder veraltete statische Bindungen. Vor einer Änderung wird deshalb der Ausgangswert dokumentiert. Bringt der Test keinen Nutzen, trägt man genau diesen Wert wieder ein, klickt Apply und prüft den realen Datenpfad erneut.

Der Neighbor-Cache betrifft nur direkt erreichbare Nachbarn im jeweiligen Layer-2-Segment. Für ein entferntes Ziel speichert die Firewall nicht die MAC-Adresse des Zielservers, sondern jene des nächsten Routers.

Das ist nicht dasselbe wie Proxy ARP: Dabei beantwortet die Firewall auf einem Interface die IPv4-ARP-Anfrage für eine andere Zieladresse stellvertretend. Dieser Sonderfall wird unter Proxy ARP auf Sophos Firewall konfigurieren und prüfen getrennt behandelt.

ARP Flux bei mehreren Interfaces erkennen

ARP Flux kann auftreten, wenn mehrere physische Ethernet-Interfaces der Sophos Firewall mit demselben Layer-2-Medium oder derselben Broadcast-Domain verbunden sind. Dann kann die Firewall eine ARP-Anfrage über beide Interfaces beantworten. Das anfragende Gerät sieht dadurch wechselnde oder unerwartete MAC-Zuordnungen. Zwei getrennte VLANs, eine falsch konfigurierte LAG oder eine gewöhnliche doppelte IP-Adresse sind dagegen nicht automatisch ARP Flux.

Ein kurzer Packet Capture dient ausschliesslich zur Prüfung des ARP-Verhaltens: Man kontrolliert, ob dieselbe Anfrage beide physischen Ports erreicht und beide Firewall-Interfaces antworten. Den konfigurierten Wert von arp-flux zeigt ein Capture nicht an.

Die Device Console erreicht man über die lokale Konsole oder per SSH. Voraussetzungen und SSH-Zugang erklärt Sophos Firewall per SSH verbinden. Nach der Anmeldung wird Option 4: Device Console gewählt. Vor jeder Änderung führt man den massgeblichen Precheck für SFOS 22.0 aus:

show arp-flux

Der exakt ausgegebene Wert on oder off wird dokumentiert. Die Einstellung gilt global und nicht nur für ein einzelnes Interface. Man ändert sie nur vorübergehend, wenn beide Interfaces absichtlich dieselbe Broadcast-Domain teilen, der Capture das problematische Verhalten bestätigt und der aktuelle Wert eine Änderung erfordert. Wurde on erfasst, testet man den interfacebezogenen Antwortmodus in einem Wartungsfenster mit:

set arp-flux off

Mit off beantwortet die Firewall ARP-Anfragen über das jeweils zugehörige Ethernet-Interface. Danach werden Erreichbarkeit, Neighbor-Einträge, der ursprüngliche Dienst und das ARP-Verhalten in einem neuen Capture über beide Pfade geprüft.

Nach dem Test wird unabhängig vom Ergebnis exakt der mit show arp-flux erfasste Wert wiederhergestellt. War der Ausgangswert on, führt man aus:

set arp-flux on

War der Ausgangswert off, führt man stattdessen aus:

set arp-flux off

Mit show arp-flux wird der wiederhergestellte Wert bestätigt. Danach folgen erneut die Pfadtests; ein Packet Capture prüft nur das daraus resultierende Verhalten.

Fehlt der Nachweis derselben Broadcast-Domain oder bleibt der Fehler mit off unverändert, sollte man keine weiteren ARP-Einstellungen auf Verdacht ändern. Dann gehören VLAN, Bridge, LAG, Switch-MAC-Tabelle, Verkabelung und doppelte IP-Adressen zurück in die Ursachenanalyse.

Neighbor-Cache zuerst prüfen

1. Network > Neighbors (ARP–NDP) öffnen.
2. Unter Show den IPv4 neighbor cache oder IPv6 neighbor cache auswählen.
3. Nach der betroffenen IP-Adresse suchen.
4. IP-Adresse, MAC-Adresse und Interface notieren.
5. Unter Static neighbor table ausschliessen, dass für dieselbe IP-Adresse eine feste, aber falsche Bindung besteht.
6. Die MAC-Adresse mit dem Endgerät, Hypervisor, Switch oder nächsten Router vergleichen.

Das Interface ist genauso wichtig wie die MAC-Adresse. Eine korrekte IP-MAC-Zuordnung auf dem falschen Port deutet häufig auf ein VLAN-, Bridge-, LAG- oder Verkabelungsproblem hin. Die erwartete MAC-Adresse findet man beispielsweise in den Netzwerkinformationen des Endgeräts, in der MAC-Tabelle des Switches oder beim direkt verbundenen Router. Fehlt der Eintrag vollständig, erzeugt man von der Firewall einen gezielten Ping zur betroffenen IP-Adresse und prüft die Ansicht danach erneut.

Für IPv4 und IPv6 sind die beiden Cache-Ansichten im WebAdmin der dokumentierte Prüfpunkt. Sie zeigen nicht nur die Adresse, sondern auch das Interface und verhindern, dass ein IPv4-Befund versehentlich auf ein IPv6-Problem übertragen wird.

Veraltete Zuordnung kontrolliert neu lernen

Ein Cache-Flush ist ein Diagnoseschritt, keine dauerhafte Reparatur. Er entfernt auch keine falsche statische Bindung. Für gelöschte dynamische Einträge gibt es keinen direkten Rückbau; die Firewall lernt sie durch neuen Verkehr wieder. Wenn dieselbe falsche Zuordnung zurückkehrt, liegt die Ursache weiterhin im Netzwerk.

1. Aktuelle IP-Adresse, MAC-Adresse und Interface dokumentieren.
2. Den Fehler mit einem einzelnen Ping oder Verbindungsversuch reproduzieren.
3. Bei Verdacht auf eine doppelte IP-Adresse oder Manipulation zuerst den aktuellen Zustand und einen kurzen Capture sichern. Ein sofortiger Flush würde diesen Hinweis entfernen.
4. Unter Show den betroffenen IPv4- oder IPv6-Cache auswählen.
5. Flush anklicken. Dadurch wird der ausgewählte Cache geleert.
6. Vom betroffenen Gerät erneut gezielt Verkehr erzeugen.
7. Prüfen, welche MAC-Adresse und welches Interface neu gelernt wurden.
8. Den ursprünglichen Dienst mit identischer Quelle und identischem Ziel erneut testen.

Für einen kontrollierten Test aus der Device Console können beispielsweise vier Pakete an eine dokumentierte Zieladresse gesendet werden:

ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4

Die Adressen sind Beispiele und werden durch das tatsächliche IPv4- oder IPv6-Ziel ersetzt. Ein erfolgreicher Ping bestätigt nur die grundsätzliche Erreichbarkeit; danach muss weiterhin der ursprünglich gestörte Dienst getestet werden.

Während des Neulernens kann es kurz zu Verzögerungen kommen. Den Timeout pauschal stark zu verkürzen ist selten die beste Lösung: Die Firewall muss Nachbarn dann häufiger neu auflösen, ohne dass damit eine doppelte IP-Adresse oder ein falscher Switch-Port behoben wäre.

Wechselt nach dem Flush nur eine öffentliche IP-Adresse weiterhin nicht auf die neue Firewall-MAC, befindet sich der veraltete Eintrag wahrscheinlich beim Provider oder vorgeschalteten Router. Dafür gibt es den eigenen Ablauf ARP-Probleme nach einer Firewall-Migration beheben.

Statischen Neighbor nur für feste Zuordnungen anlegen

Ein statischer Neighbor bindet eine IP-Adresse dauerhaft an eine MAC-Adresse und ein physisches Interface. Pro IP-Adresse kann nur eine solche Bindung bestehen. Die Firewall prüft statische Einträge vor dem dynamischen Cache und entfernt beim Speichern dynamische Referenzen für dieselbe IP. Stimmt IP, MAC oder Port später nicht mehr, kann die Verbindung ausfallen, obwohl das Endgerät korrekt konfiguriert ist.

Statische Einträge passen deshalb zu stabilen Systemen wie einem fest verkabelten Infrastrukturgerät mit fester IP-Adresse. Für DHCP-Clients, mobile Geräte, HA- oder VM-Wechsel und wechselnde Switch-Ports sind sie meist ungeeignet.

Unter Network > Neighbors (ARP–NDP) die Static neighbor table anzeigen und Add wählen. Danach werden folgende Werte gesetzt:

• IP version: IPv4 oder IPv6 auswählen.
• IPv4/IPv6 address: feste Adresse des Geräts eintragen.
• MAC address: tatsächliche MAC-Adresse dieses Geräts eintragen.
• Interface: das physische Interface auswählen, über das der Nachbar erreichbar ist.

Ein dokumentiertes Beispiel könnte 192.0.2.10, 02:00:00:00:00:10 und Port1 verwenden. Diese Werte sind Platzhalter und müssen vollständig durch die reale IP-Adresse, MAC-Adresse und den realen Port ersetzt werden.

Vor dem Speichern wird dokumentiert, ob Add as a trusted MAC address to prevent a spoofing attempt ausgewählt ist. Die Option sollte nur aktiviert werden, wenn diese Schutzstrategie bewusst eingesetzt wird, denn ein späterer VM-, NIC- oder Portwechsel kann dann als legitimer Konflikt erscheinen. Wie Trusted-MAC-Einträge mit dynamischen Netzen, DHCP und Virtualisierung zusammenspielen, erklärt Sophos Firewall Spoof Protection und DoS Settings prüfen.

Mit Save wird die Bindung angelegt. Danach wird genau das gebundene Gerät getestet. Beim Rückbau des Tests entfernt man den neu angelegten Eintrag aus der Static neighbor table, erzeugt gezielt Verkehr und kontrolliert die dynamisch gelernte Zuordnung. Anschliessend wird Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC geöffnet. Bleibt dort ein zu diesem Test gehörender Trusted-MAC-Eintrag bestehen, wird er separat entfernt; man darf nicht voraussetzen, dass das Löschen des statischen Neighbors ihn ebenfalls löscht. Zusätzlich sollte dokumentiert werden, wer einen beibehaltenen Eintrag bei einem Hardware-, IP- oder Port-Wechsel anpasst. Eine statische Bindung ohne diese Zuständigkeit wird später leicht zur unsichtbaren Fehlerursache.

Mögliche Neighbor-Poisoning-Versuche prüfen

Eine statische Bindung definiert die erwartete Kombination aus IP-Adresse, MAC-Adresse und Interface. Erscheint dieselbe IP mit einer anderen MAC-Adresse oder dieselbe IP-MAC-Kombination auf einem anderen gebundenen Port, behandelt die Firewall dies als mögliche Manipulation und aktualisiert den Cache nicht mit der abweichenden Zuordnung.

Unter Network > Neighbors (ARP–NDP) kann Log possible neighbor poisoning attempts aktiviert und mit Apply gespeichert werden. Vor einem zeitlich begrenzten Test notiert man, ob das Kontrollkästchen markiert ist, und stellt diesen sichtbaren Zustand danach wieder her. Die Option hilft bei der Diagnose, sollte aber nicht dazu verleiten, jede Abweichung sofort als Angriff zu bewerten. Auch eine doppelte IP-Adresse, ein ersetzter Netzwerkadapter, eine verschobene VM oder ein Portwechsel erzeugen einen Konflikt.

Verworfene IPv4-ARP-Pakete lassen sich in der Device Console während eines kurzen Tests anzeigen:

drop-packet-capture 'arp'

Bei vielen Interfaces kann die Ausgabe auf einen physischen Port eingeschränkt werden:

drop-packet-capture interface Port1 'arp'

Port1 ist ein Beispiel und wird durch das betroffene Interface ersetzt. Danach den Fehler einmal reproduzieren und die laufende Ausgabe mit Ctrl+C beenden. Der Filter zeigt nur verworfene ARP-Pakete und ist kein dauerhaftes Logarchiv. Für IPv6-NDP oder eine allgemeine Paketanalyse verwendet man Packet Capture im WebAdmin und grenzt Quelle, Ziel, Protokoll und Interface gezielt ein.

Typische Fehlerbilder einordnen

• Nach einem Geräte- oder NIC-Wechsel bleibt das Ziel unerreichbar: alten und neu gelernten MAC-Wert vergleichen, Cache kontrolliert leeren und erneut testen.
• Die MAC-Adresse wechselt wiederholt: doppelte IP-Adresse, DHCP-Lease, VM-Klon oder HA-Verhalten prüfen. Ein statischer Eintrag würde den eigentlichen Konflikt nur verdecken.
• Die Zuordnung erscheint auf dem falschen Interface: VLAN, Bridge, LAG, Switch-Port und Verkabelung prüfen.
• Ein statisch gebundenes Gerät fällt nach einem Umbau aus: IP, MAC und physischen Port mit der Bindung vergleichen und den Eintrag bewusst anpassen oder entfernen.
• Nur IPv6 ist betroffen: IPv6 neighbor cache, Router Advertisements, VLAN und ICMPv6-Pfad prüfen. Ein IPv4-ARP-Befehl liefert dafür keinen Beleg.
• Pakete erreichen die Firewall, der Dienst funktioniert trotzdem nicht: Firewall-Regel, NAT, Routing und Rückweg getrennt prüfen. Der Neighbor-Cache beweist nur die lokale Layer-2-Zustellung.

Abnahme

• Betroffene IP-Adresse, erwartete MAC-Adresse und Interface dokumentiert.
• IPv4- oder IPv6-Cache vor einer Änderung geprüft.
• Falls nötig genau den ausgewählten Cache geleert und gezielten Verkehr erzeugt.
• Neu gelernte Zuordnung mit Endgerät, Switch, Hypervisor oder Router verglichen.
• Statische Bindung nur bei dauerhaft stabiler IP-MAC-Port-Zuordnung verwendet.
• Poisoning-Hinweis gegen doppelte IP, Gerätewechsel und Netzänderungen abgegrenzt.
• Ursprünglichen Dienst nach der Layer-2-Prüfung erneut getestet.

FAQ