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.

Bei IPv4 fragt ein Gerät mit einer ARP-Anfrage nach der MAC-Adresse zu einer IP-Adresse. Die Antwort liefert die Zuordnung, mit der die Firewall ihren Neighbor-Cache aktualisiert. Bereits gelernte IP-MAC-Zuordnungen werden wiederverwendet, um Broadcast-Verkehr zu reduzieren; für IPv6 erfüllt NDP die entsprechende Nachbarauflösung.

Dynamische Neighbor-Einträge werden gelernt und laufend aktualisiert. Der dokumentierte Standard-Timeout für ARP- und NDP-Anfragen beträgt 600 Sekunden (10 Minuten). Das ist keine Zusicherung, dass jeder einzelne Eintrag exakt nach 600 Sekunden verschwindet: Die Caches bestehen bis zum automatischen oder manuellen Flush. Danach kann die Firewall aktuelle Zuordnungen neu lernen. 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.

Für XML-Automation: Die XML-Referenz für SFOS 22.0 und 23.0 beschreibt unter ARPConfiguration den Parameter ARPCacheEntryTimeOut als Cache-Flush-Intervall: dokumentierter Standard 2 Minuten, Bereich 1–500; das Beispiel nennt Minutes. Das sind Referenzwerte, nicht der Nachweis eines aktuellen Laufzeitwerts oder desselben Reglers wie bei der UI-Hilfe zu 600 Sekunden für ARP-/NDP-Anfragen. Diese IPv4-ARP-Entität belegt auch keine allgemeine Konfiguration aller IPv6-NDP-Eigenschaften. Keinen dieser Dokumentationswerte als automatischen Reset- oder Tuningwert übernehmen: Massgeblich bleibt der vor einer Änderung erfasste aktuelle Wert, der beim Rückbau exakt wiederhergestellt wird; danach wird der ursprüngliche Dienst erneut geprüft.

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.

Grenze zur XML-API: Get Dynamic Neighbour Entries dient zum Lesen und Prüfen; Flush All Dynamic Entries löscht dynamische Cache-Einträge, nicht einen einzelnen statischen Eintrag. Die Referenz für SFOS 22.0 und 23.0 nennt das optionale skalare IPFamily mit IPv4 und IPv6, aber keinen Standardwert. Ob das Weglassen eine der beiden Familien, beide oder einen anderen Umfang auswählt, lässt sich daraus nicht ableiten. Beide Referenzfassungen enthalten keinen Anfrage-Payload; die Parametertabelle liefert deshalb keine ausführbare Operationsanfrage. Für Prüfung und Flush verwendet man den vorhandenen GUI-Ablauf mit ausdrücklich ausgewählter IP-Familie. Dabei bleibt die Warnung bestehen: Flush leert den gesamten ausgewählten Cache.

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 bei einer Anfrage am jeweiligen Port zuerst die statische Neighbor-Tabelle und entfernt beim Speichern dynamische Referenzen für dieselbe IP. Fehlt ein statischer Eintrag, prüft sie die Neighbor-Caches und ergänzt die MAC-Adresse bei Bedarf. Für ein statisch gebundenes IP-MAC-Paar antwortet die Firewall auf keinem anderen Port. 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 fügt die IP-MAC-Zuordnung zur Trusted-MAC-Liste hinzu. Sie 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.

Grenze zur Add/Edit-API

Die Add/Edit-Referenz für statische Neighbor in SFOS 22.0 und 23.0 beschreibt einen eigenen API-Vertrag, nicht die oben erläuterte Timeout-Entität ARPConfiguration. Sie verlangt neighname für die gespeicherte beziehungsweise ausgewählte Neighbor-Identität; neighid ist dagegen optional. Beide sind von IPAddress, MACAddress und Interface zu unterscheiden. Die GUI-Werte für IP, MAC und physischen Port liefern weder diese Identität noch eine ausführbare JSON- oder XML-Anfrage. Die Referenz bezeichnet den Vorgang als JSON, zeigt aber kein Beispiel, das Format oder Identitätszuordnung sicher klärt; deshalb keinen Bezeichner aus den GUI-Werten ableiten.

Auch die Adressangaben sind widersprüchlich: Das erforderliche IPFamily erlaubt IPv4 und IPv6, während IPAddress als IPADDRESS mit höchstens 15 Zeichen und IPv4-geprägten Adressklassen beschränkt wird. Daraus lässt sich keine verlässliche IPv6-Kodierung ableiten; es widerlegt auch nicht die IPv6-Unterstützung des oben beschriebenen GUI-Ablaufs. Beim optionalen AddAsATrustedMACAddress nennt die Referenz nur Enable. Das belegt weder einen Disable-Wert noch die Wirkung eines weggelassenen Parameters. Die Trusted-MAC-Auswahl bleibt eine bewusste Entscheidung, und ein verbleibender Trusted-MAC-Eintrag wird wie oben beschrieben separat bereinigt. Solange Identität, Anfrageformat und IPv6-Adressschema für die konkrete SFOS-Version unklar sind, verwendet man zum Anlegen oder Bearbeiten die vorhandene GUI statt einer geratenen API-Anfrage.

Delete Static ARP Entry ist ein separater Vorgang: Die Referenz für SFOS 22.0 und 23.0 verlangt IPAddress zur Identifikation des Eintrags, nicht den Add/Edit-Vertrag mit neighname und neighid. Die Beschränkung auf IPADDRESS, höchstens 15 Zeichen und IPv4-geprägte Adressklassen belegt keine verlässliche Darstellung für eine IPv6-Löschung. Beide Referenzfassungen enthalten weder ein Löschanfrage-Beispiel noch eine Statustabelle; daraus werden kein Anfrageformat, kein Lösch-Payload und kein Ergebnisvertrag abgeleitet. Statt eine API-Löschanfrage zu erraten, wählt und entfernt man in der vorhandenen GUI nur den beabsichtigten gespeicherten statischen Eintrag. Ein entsprechender verbleibender Trusted-MAC-Eintrag wird weiterhin wie oben beschrieben separat geprüft und entfernt; eine kaskadierende Löschung ist nicht zugesichert.

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.

Eine Bindung pro IP-Adresse bedeutet nicht, dass eine MAC-Adresse nur zu einer IP-Adresse gehören darf. Im IPv4-ARP-Beispiel sind IP1 und IP2 jeweils an MAC1 und Port A gebunden. Erscheint jede dieser IP-Adressen mit MAC1 auf Port A, liegt kein Neighbor-Poisoning-Versuch vor. Entscheidend ist, dass die jeweilige IP-MAC-Port-Kombination ihrer eigenen statischen Bindung entspricht.

Im selben Beispiel wird auch IP3 mit MAC1 ohne statischen ARP-Eintrag für IP3 nicht als Neighbor-Poisoning-Versuch eingestuft. Die gemeinsame MAC-Adresse allein begründet also keinen Konflikt mit den Bindungen von IP1 oder IP2. Diese Beispiele erklären die Prüfung statischer ARP-Bindungen; sie sind keine allgemeine Sicherheitsfreigabe für den Verkehr.

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