Sophos Firewall ARP-Probleme nach Migration beheben

Nach einer Firewall-Migration kann es passieren, dass die neue Sophos Firewall grundsätzlich online ist, einzelne öffentliche IP-Adressen oder Alias-IP-Adressen aber trotzdem nicht erreichbar sind. Besonders typisch ist das nach einem Wechsel von einem anderen Hersteller zu Sophos Firewall oder nach einer Migration von XG auf XGS Hardware. Die IP-Adressen bleiben gleich, die MAC-Adresse am WAN-Interface ändert sich aber.

Wenn ein vorgeschalteter Router, ein Provider-CPE oder ein Switch noch alte ARP-Einträge im Cache hat, sendet er Pakete weiterhin an die frühere MAC-Adresse. Das wirkt dann so, als ob nur bestimmte Alias-IP-Adressen, DNAT-Ziele oder Ping-Tests nicht funktionieren. Für die allgemeine Migrationsplanung passt zusätzlich der Artikel Was ist der Unterschied zwischen einer XG und XGS Firewall?.

Typische Symptome

ARP-Probleme nach einer Umstellung zeigen sich meistens direkt nach dem Wechsel oder nach einem Restore auf neuer Hardware.

Typische Hinweise:

Das WAN-Interface der Sophos Firewall ist online.
Die Haupt-IP-Adresse funktioniert, einzelne Alias-IP-Adressen aber nicht.
Ping auf bestimmte öffentliche IPs schlägt fehl, andere IPs auf demselben Interface reagieren.
DNAT oder WAF-Regeln wirken korrekt konfiguriert, erreichen den internen Server aber nicht.
Ein Dienst ist von intern erreichbar, von extern aber nur auf bestimmten öffentlichen IPs gestört.
Nach einiger Zeit funktioniert es plötzlich, weil ein ARP-Cache automatisch abläuft.

Wichtig ist die Abgrenzung: Nicht jedes Erreichbarkeitsproblem nach einer Migration ist ein ARP-Problem. Firewall-Regeln, NAT-Regeln, Zonen, Alias-Konfiguration, Provider-Routing und Rückrouten müssen ebenfalls geprüft werden.

Warum ARP nach einer Migration stören kann

ARP löst IPv4-Adressen in MAC-Adressen auf. In einem lokalen Layer-2-Segment fragt ein Gerät: Welche MAC-Adresse gehört zu dieser IP-Adresse? Die Antwort wird im ARP-Cache gespeichert, damit nicht jedes Paket eine neue ARP-Anfrage auslösen muss.

Bei einer Firewall-Migration bleibt die IP-Adresse häufig gleich, die MAC-Adresse ändert sich aber. Genau das kann problematisch sein:

Der Provider-Router kennt die öffentliche IP noch mit der alten MAC-Adresse.
Ein vorgeschalteter Switch oder Router hält veraltete ARP-Einträge.
Eine Alias-IP wurde auf der neuen Firewall korrekt angelegt, aber der Nachbar sendet weiter an die alte Hardware.
Nur ein Teil der IPs wurde bereits neu gelernt, deshalb funktionieren manche Adressen und andere nicht.

Bei einzelnen Alias-IP-Adressen ist das besonders irritierend, weil die Grundverbindung scheinbar funktioniert. Man sieht dann schnell in NAT, Firewall-Regeln oder Routing nach, obwohl der Fehler schon davor auf Layer 2 entsteht.

Vor dem CLI-Befehl prüfen

Bevor man ARP aktiv anstösst, sollte die Grundkonfiguration stimmen. Sonst wird ein ARP-Ping nur ein anderes Problem überdecken.

Prüfen:

Unter Network > Interfaces kontrollieren, ob die betroffene IP-Adresse oder Alias-IP-Adresse auf dem richtigen Interface liegt.
Zone des Interfaces prüfen, zum Beispiel WAN.
Gateway, Subnetzmaske und Alias-Netzlogik prüfen.
Unter Rules and policies > NAT rules kontrollieren, ob die DNAT-Regel auf die richtige öffentliche IP zeigt.
Unter Rules and policies > Firewall rules prüfen, ob eine passende Regel für den Verkehr existiert.
Im Log Viewer nachsehen, ob Pakete überhaupt auf der Firewall ankommen.
Bei Bedarf mit Sophos Firewall Packet Capture im WebAdmin prüfen, ob eingehende Pakete am WAN-Interface sichtbar sind.

Wenn im Packet Capture gar keine Pakete für die betroffene öffentliche IP ankommen, liegt das Problem wahrscheinlich vor der Firewall: Provider-Router, vorgeschalteter Switch, ARP-Cache oder Routing beim Provider. Wenn Pakete ankommen, aber verworfen werden, sollte man zuerst NAT, Firewall-Regeln und Zonen prüfen. Für Interface- und Zonenlogik hilft Sophos Firewall Zonen und Interfaces konfigurieren.

ARP-Ping über die Device Console ausführen

Sophos Firewall kann über die Device Console einen ARP-Ping mit definierter Source-IP und Interface auslösen. Das ist hilfreich, wenn eine Alias-IP nach der Migration aktiv im Netz bekannt gemacht werden soll.

Wichtig: Der Befehl sollte nur ausgeführt werden, wenn klar ist, welche Source-IP, welches Interface und welches Ziel im lokalen Segment verwendet werden. Falsche Werte helfen nicht und können die Analyse verfälschen. Vor Änderungen an einer produktiven Migration sollte ein aktuelles Sophos Firewall Backup vorhanden sein.

Der Befehl wird in der Device Console ausgeführt, nicht in der Advanced Shell:

system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>

Beispiel:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

In diesem Beispiel ist 198.51.100.21 die betroffene Alias-IP auf Port2. 198.51.100.1 ist ein erreichbares Ziel im gleichen Layer-2-Segment, typischerweise der Upstream-Gateway oder das Provider-CPE. Dadurch erzeugt die Firewall ARP-Verkehr mit der richtigen Source-IP über das richtige Interface.

Wenn SSH noch nicht eingerichtet ist, beschreibt Sophos Firewall per SSH verbinden, wie man die Device Console erreicht. Bei Migrationen sollte SSH nicht dauerhaft breit aus dem WAN erlaubt werden. Besser ist ein temporärer, eingeschränkter Administrationszugriff aus einem vertrauenswürdigen Netz.

Empfohlener Ablauf

1. Betroffene IP-Adressen sammeln

Zuerst wird dokumentiert, welche IP-Adressen funktionieren und welche nicht. Bei Alias-IP-Adressen sollte man die Liste direkt mit der Interface-Konfiguration vergleichen.

Notieren:

Interface, zum Beispiel Port2
Haupt-IP und Alias-IP-Adressen
Upstream-Gateway oder Provider-CPE
betroffene NAT- oder WAF-Regeln
Ergebnis von Ping, Porttest und Packet Capture

2. ARP-Problem eingrenzen

Von einem externen Testsystem aus die betroffene öffentliche IP prüfen. Parallel auf der Sophos Firewall Packet Capture auf dem WAN-Interface starten.

Interpretation:

Keine Pakete kommen am WAN-Interface an: Upstream, ARP, Provider-Routing oder vorgeschaltetes Gerät prüfen.
Pakete kommen an, werden aber verworfen: Firewall-Regel, NAT, Zone oder Dienst prüfen.
Pakete kommen an und gehen intern weiter, Antwort fehlt: Rückroute, interner Server, SNAT oder Server-Firewall prüfen.
Nur Alias-IP betroffen, Haupt-IP funktioniert: ARP-Cache oder Alias-Konfiguration gezielt prüfen.

3. ARP-Ping pro betroffener Alias-IP ausführen

Für jede betroffene Alias-IP wird der ARP-Ping mit der passenden Source-IP und dem richtigen Interface ausgeführt. Danach sollte man nicht sofort mehrere andere Dinge ändern, sondern zuerst testen, ob sich das Verhalten ändert.

Beispiel mit Platzhaltern:

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

Wenn mehrere Alias-IP-Adressen betroffen sind, wird der Befehl einzeln pro Adresse ausgeführt. Das macht die Prüfung nachvollziehbar und verhindert, dass man am Ende nicht mehr weiss, welche Massnahme geholfen hat.

4. Erreichbarkeit validieren

Nach dem ARP-Ping sollte man denselben Test wiederholen:

Ping oder TCP-Porttest von extern.
Packet Capture auf dem WAN-Interface.
Log Viewer auf die betroffene Ziel-IP filtern.
NAT- und Firewall-Regel prüfen, wenn Pakete nun ankommen.

Wenn der Upstream die ARP-Information korrekt neu lernt, sollten Pakete für die Alias-IP nun an der neuen Firewall ankommen. Ob der veröffentlichte Dienst danach funktioniert, hängt zusätzlich von NAT, Firewall-Regeln, internem Server und Rückweg ab.

Wenn der ARP-Ping nicht hilft

Wenn der ARP-Ping keine Verbesserung bringt, sollte man nicht beliebig weitere Befehle ausprobieren. Dann ist eine strukturierte Eingrenzung sinnvoll.

Weitere Prüfungen:

Upstream-Gerät kann veraltete ARP-Einträge noch halten.
Provider muss ARP-Cache oder CPE neu laden.
Alias-IP liegt auf dem falschen Interface oder in einem falschen Netz.
Öffentliche IP wird vom Provider geroutet statt direkt im lokalen Segment per ARP gelernt.
DNAT-Regel zeigt auf die falsche öffentliche Adresse.
Firewall-Regel erlaubt den Verkehr nicht.
Interner Server antwortet über einen anderen Gateway zurück.
Bei HA oder Hardwarewechsel wurde die falsche MAC-Adresse erwartet.

Ein Neustart des Provider-CPE oder eines vorgeschalteten Routers kann ARP-Caches leeren, sollte aber nicht die erste Massnahme sein. In produktiven Umgebungen ist es sauberer, zuerst Beweise mit Packet Capture und Log Viewer zu sammeln.

Provider oder Upstream gezielt einbeziehen

Wenn am WAN-Interface keine Pakete für die betroffene öffentliche IP ankommen, sollte die Anfrage an Provider oder Upstream-Verantwortliche möglichst konkret sein. Eine allgemeine Meldung wie “die Firewall ist nicht erreichbar” führt oft zu unnötigen Schleifen. Besser ist ein kurzer technischer Nachweis, der zeigt, welche IP betroffen ist und was auf der Sophos Firewall geprüft wurde.

Hilfreiche Angaben:

Betroffene öffentliche IP oder Alias-IP: Der Provider kann gezielt den ARP- oder Routing-Eintrag prüfen.
WAN-Interface und neue MAC-Adresse: Diese Angabe zeigt, welche Zuordnung nach der Migration erwartet wird.
Upstream-Gateway oder CPE-Adresse: Damit lässt sich eingrenzen, welches Nachbargerät die Adresse lernen muss.
Zeitpunkt des ARP-Ping-Tests: Das erleichtert den Abgleich mit Provider-Logs oder CPE-Status.
Packet-Capture-Ergebnis: Es belegt, ob Pakete die Sophos Firewall überhaupt erreichen.
Geprüfte DNAT- und Firewall-Regel: Das verhindert, dass der Fall vorschnell als lokales Regelproblem eingeordnet wird.

Die MAC-Adresse des WAN-Interfaces kann in der WebAdmin-Oberfläche unter Network > Interfaces dokumentiert werden. Wenn der Provider einen ARP-Cache leeren oder ein CPE neu laden muss, sollte das auf die konkrete IP beziehungsweise das betroffene Interface bezogen sein. Ein pauschaler Neustart aller beteiligten Geräte ist nur sinnvoll, wenn Zuständigkeit, Wartungsfenster und Auswirkung klar sind.

Checkliste

Betroffene Haupt- und Alias-IP-Adressen dokumentiert.
Interface, Zone, Gateway und Alias-Konfiguration geprüft.
NAT- und Firewall-Regeln zur betroffenen IP geprüft.
Packet Capture zeigt, ob Pakete am WAN-Interface ankommen.
ARP-Ping nur mit korrekter Source-IP, Interface und Ziel-IP ausgeführt.
Externe Erreichbarkeit nach jeder Änderung erneut getestet.
Falls nötig Provider oder Upstream-Verantwortliche mit konkreter IP, MAC-Adresse, Testzeitpunkt und Packet-Capture-Beobachtung kontaktiert.

FAQ

Muss man nach jeder Firewall-Migration ARP manuell aktualisieren?

Nein. In vielen Umgebungen lernen Nachbargeräte die neue MAC-Adresse automatisch. Manuelle ARP-Massnahmen sind vor allem dann relevant, wenn einzelne IP-Adressen nach dem Wechsel nicht erreichbar sind, obwohl die Firewall-Konfiguration korrekt aussieht.

Ist das ein NAT-Problem oder ein ARP-Problem?

Wenn Pakete im Packet Capture gar nicht am WAN-Interface ankommen, ist NAT auf der Sophos Firewall noch nicht der erste Verdächtige. Wenn Pakete ankommen, aber nicht weitergeleitet werden, muss man NAT, Firewall-Regeln, Zonen und interne Rückwege prüfen.

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

Der Upstream kann pro IP-Adresse unterschiedliche ARP-Einträge gelernt haben. Deshalb kann eine IP bereits korrekt zur neuen MAC-Adresse zeigen, während eine andere noch auf die alte Firewall verweist.

Soll man Router oder Switches einfach neu starten?

Nur wenn der Eingriff betrieblich vertretbar ist und die Zuständigkeit klar ist. Besser ist zuerst eine gezielte Prüfung: Packet Capture auf der Sophos Firewall, ARP-Status auf dem Upstream-Gerät und, falls möglich, gezieltes Leeren des ARP-Caches auf dem betroffenen Gerät.

Braucht man dafür die Advanced Shell?

Nein. Der gezeigte ARP-Ping wird in der Sophos Firewall Device Console ausgeführt. Advanced Shell ist dafür nicht nötig und sollte für einfache Migrationsprüfungen vermieden werden.