Sophos Firewall ARP-Probleme nach Migration beheben

Nach einem Firewall-Wechsel kann die neue Sophos Firewall online sein, während einzelne öffentliche Alias-IP-Adressen nicht erreichbar bleiben. Häufig kennt der vorgeschaltete Router diese Adressen noch mit der WAN-MAC-Adresse der alten Appliance. Dann erreichen die Pakete die neue Firewall gar nicht, obwohl Alias, DNAT und Firewall-Regel korrekt aussehen.

Dieser Leitfaden zeigt, wie man dieses IPv4-Problem mit Interface-Prüfung, Packet Capture und Upstream-ARP eingrenzt. Erst wenn die Layer-2-Ursache belegt ist, wird der ARP-Cache auf dem Gerät aktualisiert, das den alten Eintrag hält. Für die allgemeine Hardwaremigration passt zusätzlich Sophos XG und XGS Appliance vergleichen.

Wann ARP tatsächlich der Verdächtige ist

Das Fehlerbild beginnt typischerweise direkt nach einem Appliance-Tausch, Restore oder Herstellerwechsel. Die öffentliche IP bleibt gleich, die MAC-Adresse des WAN-Interfaces ändert sich.

Starke Hinweise sind:

Die Haupt-IP des WAN-Interfaces funktioniert, eine oder mehrere Alias-IP-Adressen aber nicht.
Ein externer Test erreicht einen veröffentlichten Dienst auf bestimmten öffentlichen IPs nicht.
Im Packet Capture erscheint für die betroffene IP kein eingehendes Paket.
Der Dienst funktioniert nach Ablauf eines Upstream-Caches plötzlich ohne weitere Firewall-Änderung.
Der vorgeschaltete Router zeigt für die öffentliche IP noch die MAC-Adresse der alten Appliance.

ARP ist nicht automatisch die Ursache. Wenn Pakete am WAN-Interface ankommen, liegt der nächste Prüfpunkt bei DNAT, Firewall-Regel, Zone, internem Server oder Rückroute. Für IPv6 gilt dieser Ablauf ebenfalls nicht; dort übernimmt Neighbor Discovery die Nachbarauflösung.

Den lokalen ARP- oder NDP-Cache der Sophos Firewall prüft man dagegen mit ARP- und NDP-Neighbor-Cache prüfen. Dort ist auch beschrieben, wann ein Cache-Flush sinnvoll ist und wann der Fehler weiterhin beim Provider oder Upstream liegt.

Warum Alias-IPs nach einem Austausch ausfallen können

ARP ordnet eine IPv4-Adresse einer MAC-Adresse im lokalen Layer-2-Segment zu. Ein Router speichert diese Zuordnung im ARP-Cache. Nach dem Austausch sollte der Upstream die WAN-MAC-Adresse der neuen Firewall lernen. Geschieht das bei einer Alias-IP nicht, sendet er Pakete weiterhin an die alte Hardware.

Das erklärt, warum die Haupt-IP funktionieren kann, obwohl eine Alias-IP ausfällt: Der Upstream führt pro IP-Adresse einen eigenen Eintrag. Eine Zuordnung kann bereits aktuell sein, während eine andere noch auf die alte MAC-Adresse zeigt.

Zuerst muss aber geklärt sein, wie der Provider die öffentlichen Adressen liefert:

Direkt verbundenes Netz: Der Upstream löst Haupt- und Alias-IPs per ARP auf. Alte Einträge sind nach einem Hardwarewechsel plausibel.
Gerouteter öffentlicher Block: Der Provider routet den Block zur primären WAN-IP. Dann ist nicht zwingend ein eigener ARP-Eintrag pro öffentlicher IP zu erwarten; Provider-Route und lokale Alias-/NAT-Konfiguration sind wichtiger.

Diagnose vor dem Eingriff

Die Diagnose soll zuerst zeigen, an welcher Stelle der Paketfluss endet. Dadurch wird vermieden, gleichzeitig ARP, NAT und Firewall-Regeln zu verändern.

Unter Network > Interfaces das physische WAN-Interface und die betroffenen Adressen prüfen. Eine Alias-IP wird über Add interface > Add alias an das richtige physische Interface gebunden; IP-Version, Adresse und Netzmaske müssen zum Design passen. Sind mehr als drei Aliase vorhanden, zeigt SFOS zunächst nur drei Adressen. Mit dem Mauszeiger über eine sichtbare Adresse fahren und in der eingeblendeten Liste scrollen, bevor man einen vermeintlich fehlenden Alias neu anlegt.
Falls Alias-Adressen aus einem anderen Subnetz stammen, müssen interne Hosts die Sophos Firewall als Default Gateway verwenden und der Upstream benötigt in jedem Alias-Subnetz eine für die Firewall erreichbare Gateway-Adresse. Mehrere getrennte WAN-Interfaces im gleichen Subnetz verursachen laut Sophos ARP-Probleme und unerreichbare Gateways; dafür sind je nach Design Alias- oder LAG-Interfaces vorgesehen.
Von einem wirklich externen Testsystem dieselbe öffentliche IP und denselben Dienst prüfen. Ein Ping allein reicht nicht, weil ICMP blockiert sein kann; besser ist zusätzlich ein bekannter TCP-Porttest.
Unter Diagnostics > Packet capture den Mitschnitt einschalten und Display filter öffnen. Für die Layer-2-Prüfung Interface name und Ethernet type: ARP wählen; für den Dienst anschliessend Ethernet type: IPv4, die betroffene Destination IP und bei Bedarf Destination port verwenden. Ohne Wrap capture buffer once full stoppt der Mitschnitt, wenn der 2048-KB-Puffer voll ist; dann mit Clear leeren und den reproduzierbaren Test erneut starten. Mit aktivierter Option läuft der Mitschnitt am Pufferanfang weiter und überschreibt ältere Pakete.
Erst wenn IP-Pakete ankommen, im Log viewer nach Ziel-IP, Dienst sowie Firewall- und NAT Rule ID suchen. ARP selbst wird mit Packet Capture beurteilt, nicht über einen normalen Firewall-Regel-Log.

Packet Capture auf Sophos Firewall verwenden erklärt die Anzeige genauer. Für die Prüfung von Interface, Zone und Alias-Zuordnung hilft Sophos Firewall Zonen und Interfaces konfigurieren.

Die Beobachtung führt zu einer klaren Richtung:

Kein IPv4-Paket am WAN: Upstream-ARP, Provider-Routing, CPE oder vorgeschalteten Switch prüfen.
Status Incoming oder Violation: Das Paket erreicht die Firewall. Bei Violation liefern Reason, Firewall-Regel, DNAT, Zone und Dienst die nächsten Hinweise.
Status Forwarded, Antwort fehlt: Rückroute, internen Server, SNAT und Server-Firewall prüfen.
Nur Alias-IP betroffen: Alias-Konfiguration und Upstream-Eintrag genau für diese IP vergleichen.

ARP-Zuordnung am Upstream gezielt aktualisieren

Die sauberste Korrektur findet auf dem Gerät statt, das den falschen Eintrag hält. Wenn man den vorgeschalteten Router oder das Provider-CPE verwaltet, wird der ARP-Eintrag gezielt für die betroffene IP gelöscht. Danach muss der Upstream die neue WAN-MAC-Adresse lernen.

Ist kein gezieltes Leeren möglich, nennt Sophos den Neustart des zuständigen Routers als Alternative. Das gehört in ein Wartungsfenster, weil ein Neustart weitere Verbindungen unterbricht und nicht rückgängig gemacht werden kann. Das Löschen eines dynamischen Eintrags benötigt keinen Konfigurations-Rollback: Der Router lernt ihn neu. Wird die Migration zurückgebaut, löscht man den Eintrag nach dem Wiederanschliessen der alten Appliance erneut, damit der Router wieder deren MAC-Adresse lernt. Bei Provider-Geräten sollte der Provider die betroffene IP, alte und neue MAC-Adresse sowie das zuständige CPE kennen.

Ein zusätzlicher Device-Console-Befehl ist für diesen Fix nicht nötig. Die aktuelle SFOS-22-Hilfe nennt für veraltete Alias-ARP-Einträge ausdrücklich das gezielte Leeren des Router-Caches oder den Router-Neustart. Wenn der Provider die Adressen routet und nicht lokal per ARP auflöst, sind beide Massnahmen am Alias-Eintrag wirkungslos; dann müssen Provider-Route und lokale Alias-/NAT-Konfiguration geprüft werden.

Erreichbarkeit nach der Korrektur validieren

Nach genau einer Massnahme wird derselbe Test wiederholt. So bleibt erkennbar, was den Fehler behoben hat.

Im Upstream prüfen, ob die betroffene IP nun zur neuen WAN-MAC-Adresse zeigt.
Den externen Ping- oder TCP-Porttest mit identischer Quelle und identischem Ziel wiederholen.
Im Packet Capture prüfen, ob die Pakete jetzt am WAN-Interface ankommen.
Wenn Pakete ankommen, Firewall Rule ID und NAT Rule ID im Log Viewer kontrollieren.
Den veröffentlichten Dienst bis zum internen Server und über den Rückweg testen.

Ein aktualisierter ARP-Eintrag beweist nur, dass der Upstream die Pakete an die neue Firewall senden kann. Ob der Dienst funktioniert, hängt weiterhin von DNAT, Firewall-Regel, internem Ziel und Rückroute ab. Für die Veröffentlichung eines Servers zeigt Server per DNAT veröffentlichen den vollständigen Regelpfad.

Wenn die Störung bestehen bleibt

Bleibt die IP trotz aktualisiertem ARP-Eintrag unerreichbar, sollte man nicht weitere Shell-Befehle ausprobieren, sondern die Hypothese wechseln.

Typische Alternativen sind:

Die Alias-IP liegt auf dem falschen physischen Interface oder verwendet eine falsche Netzmaske.
Der Provider routet den öffentlichen Block anders als angenommen.
Ein statischer ARP- oder MAC-Eintrag im Upstream überschreibt dynamisches Lernen.
Ein vorgeschalteter Switch hält eine alte MAC-Zuordnung oder verwendet Port Security.
Die DNAT-Regel verweist auf eine andere öffentliche IP.
Die Firewall-Regel erlaubt Quelle, Dienst oder Zone nicht.
Der interne Server antwortet über ein anderes Gateway.
Bei HA antwortet der Primary auf ARP-Anfragen mit der virtuellen MAC-Adresse des Interfaces. Nur virtuelle Appliances mit aktivierter Option Use host or hypervisor-assigned MAC address verwenden stattdessen die vom Host oder Hypervisor vergebene MAC-Adresse.

Auch ein dauerhaft wiederkehrender ARP-Verlust ist kein Fall für einen periodisch gestarteten Eigenbau-Befehl. Dann müssen Provider, CPE, Layer-2-Design und gegebenenfalls Sophos Support die Ursache klären.

Provider oder Upstream gezielt einbeziehen

Wenn der WAN-Mitschnitt keine Pakete für die betroffene IP zeigt, braucht der Provider einen präzisen Befund statt der allgemeinen Meldung, die Firewall sei nicht erreichbar.

Bereithalten sollte man:

betroffene Haupt- oder Alias-IP,
WAN-Interface und neue MAC-Adresse,
Upstream-Gateway oder CPE,
Zeitpunkt des externen Tests und der Cache-Löschung oder des Neustarts,
Packet-Capture-Ergebnis,
erwartete Bereitstellung als direkt verbundenes oder geroutetes Netz,
Ergebnis für Haupt-IP und weitere Alias-IPs.

Der Provider kann damit den konkreten ARP-Eintrag, eine statische Zuordnung oder die Route zum öffentlichen Block prüfen. Sensible Konfigurationsdaten oder vollständige Packet Captures sollten nur über einen vereinbarten Supportkanal übertragen werden.

Kompakte Abnahme

Haupt- und Alias-IPs sowie Bereitstellungsart dokumentiert.
Physisches Interface, IP-Version und Netzmaske geprüft.
Externer TCP-Test und Packet Capture mit identischen Zielen durchgeführt.
ARP- und IP-Verkehr in der Diagnose getrennt betrachtet.
Upstream-Eintrag gezielt gelöscht oder Router im abgestimmten Wartungsfenster neu gestartet.
Neue MAC-Zuordnung am Upstream bestätigt.
DNAT, Firewall Rule ID, NAT Rule ID und Rückweg nachgelagert geprüft.
Ursache und Massnahme im Change oder Migrationsprotokoll dokumentiert.

FAQ

Muss man nach jeder Firewall-Migration den ARP-Cache leeren?

Nein. Normalerweise lernt der Upstream die neue MAC-Adresse automatisch. Eingreifen muss man erst, wenn ein konkreter Eintrag alt bleibt und Packet Capture zeigt, dass die betroffene IP die neue Firewall nicht erreicht.

Warum funktioniert die Haupt-IP, aber eine Alias-IP nicht?

Der Upstream speichert die Zuordnung pro IPv4-Adresse. Der Eintrag der Haupt-IP kann bereits auf die neue WAN-MAC-Adresse zeigen, während eine Alias-IP noch mit der alten MAC-Adresse verbunden ist.

Ist das ein ARP-, NAT- oder Firewall-Regelproblem?

Wenn beim externen Test kein Paket am WAN-Interface ankommt, liegt die Ursache vor der lokalen DNAT- und Firewall-Auswertung. Kommt das Paket an, werden NAT Rule ID, Firewall Rule ID, internes Ziel und Rückroute geprüft.

Kann man einfach das Provider-CPE neu starten?

Ein Neustart kann den ARP-Cache erneuern, unterbricht aber weitere Verbindungen. Besser ist ein gezieltes Löschen des betroffenen Eintrags; andernfalls gehört der Neustart in ein abgestimmtes Wartungsfenster.