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 gezielt aktualisiert oder ein ARP-Ping über die Device Console ausgelöst. Für die allgemeine Hardwaremigration passt zusätzlich Sophos XG und XGS 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.

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.
Falls Alias-Adressen aus einem anderen Subnetz stammen, prüfen, ob der Upstream in diesem Subnetz als Gateway für die Firewall erreichbar ist. Mehrere getrennte WAN-Interfaces im gleichen Subnetz sind keine saubere Lösung und können selbst ARP-Probleme erzeugen; 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 auf dem WAN-Interface mitschneiden. Für die Layer-2-Prüfung nach Interface und Ethernet type: ARP filtern; für den Dienst anschliessend nach betroffener Ziel-IP und Protokoll filtern.
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:

Keine Pakete am WAN: Upstream-ARP, Provider-Routing, CPE oder vorgeschalteten Switch prüfen.
Pakete kommen an und werden verworfen: Firewall-Regel, DNAT, Zone und Dienst prüfen.
Pakete werden intern weitergeleitet, 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 gezielt aktualisieren

Upstream-Cache leeren

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, kann ein Neustart des zuständigen Routers den Cache ebenfalls erneuern. Das gehört in ein Wartungsfenster, weil ein Neustart weitere Verbindungen unterbricht. Bei Provider-Geräten sollte der Provider die betroffene IP, alte und neue MAC-Adresse sowie das zuständige CPE kennen, statt pauschal die ganze Strecke neu zu starten.

ARP-Ping über die Device Console auslösen

Sophos Firewall stellt in der Device Console eine ARP-Diagnose bereit. Der ARP-Ping kann mit der betroffenen Source-IP und dem WAN-Interface eine Aktualisierung am direkt verbundenen Upstream anstossen.

Nach einer Konsolen- oder SSH-Anmeldung Option 4: Device Console öffnen und den Befehl mit den realen Werten ausführen:

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Beispiel mit Dokumentationsadressen:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

198.51.100.21 ist hier die betroffene Alias-IP auf Port2; 198.51.100.1 ist der direkt erreichbare Upstream im gleichen Layer-2-Segment. Source-IP, Interface und Ziel müssen zusammenpassen. Bei mehreren betroffenen Alias-IPs wird jede Adresse einzeln getestet, damit die Wirkung nachvollziehbar bleibt.

Der Befehl ersetzt weder eine falsche Alias-Konfiguration noch die Korrektur eines statischen ARP-Eintrags beim Provider. Wenn der Provider die Adressen routet und nicht lokal per ARP auflöst, ist der ARP-Ping ebenfalls nicht die passende Lösung. Den sicheren Zugang zur Device Console beschreibt Sophos Firewall per SSH verbinden.

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 wird die falsche virtuelle oder physische MAC-Adresse erwartet.

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 des ARP-Pings,
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 ARP-Ping mit korrekten Parametern ausgeführt.
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.

Braucht der ARP-Ping die Advanced Shell?

Nein. system diagnostics utilities arp ping wird in der Device Console ausgeführt. Die Advanced Shell ist dafür nicht erforderlich.