Sophos Firewall Proxy ARP konfigurieren und prüfen

Proxy ARP wird auf einer Sophos Firewall nur dann benötigt, wenn ein Gerät im direkt angeschlossenen IPv4-Segment nach einer zusätzlichen Zieladresse fragt und die Firewall stellvertretend mit ihrer MAC-Adresse antworten soll. Das kann beispielsweise bei einer weiteren öffentlichen IP vorkommen, die anschliessend per DNAT zu einem internen Server weitergeleitet wird.

Der entscheidende Punkt: Proxy ARP löst nur die Nachbarauflösung vor dem eigentlichen IP-Datenpfad. Es erstellt keine Firewallregel, keine NAT-Regel und keine Rückroute. Deshalb wird zuerst mit einem ARP-Capture bestätigt, dass genau diese Antwort fehlt. Zusätzlich muss vor jeder Änderung der konfigurierte Ausgangszustand für die genaue Kombination aus Interface und Zieladresse feststehen: Eine fehlende ARP-Antwort beweist nicht, dass kein manueller Eintrag existiert. Nur wenn dieser Eintrag nachweislich noch nicht konfiguriert ist, wird er angelegt und zusammen mit dem echten Dienst geprüft.

⚠️ Proxy ARP nicht vorsorglich für einen ganzen öffentlichen Adressbereich aktivieren. Vor der Änderung Providerzuteilung, Interface, ursprünglichen ARP-Zustand, Backup, unabhängigen Managementzugang und Rollback dokumentieren. Eine falsche oder doppelt verwendete Zieladresse kann Traffic auf die falsche Firewall ziehen.

Proxy ARP in acht Schritten

1. Beim Provider oder Upstream-Team klären, ob die zusätzliche IPv4-Adresse auf dem WAN-Segment per ARP gesucht oder als Präfix zur Firewall geroutet wird.
2. Ausschliessen, dass die Adresse bereits als Alias, auf einem anderen Gerät oder durch einen vorhandenen Aufbau verwendet wird. Den konfigurierten Ausgangszustand des manuellen Proxy-ARP-Eintrags für genau dieses Interface und diese Zieladresse mit einem für den installierten Build bestätigten Leseverfahren, einem aktuellen verlässlichen Konfigurationsnachweis oder Sophos Support feststellen und dokumentieren. Ist der Zustand unbekannt, stoppen; besteht der Eintrag bereits, dessen Funktion diagnostizieren statt ihn erneut anzulegen oder zu überschreiben.
3. Während einer neuen Verbindung einen ARP-Capture auf dem erwarteten Eingangsinterface erstellen.
4. Nur fortfahren, wenn die ARP-Anfrage für die Zieladresse ankommt, die benötigte Antwort der Firewall nachweislich fehlt und unabhängig vom Capture bestätigt ist, dass der genaue manuelle Eintrag noch nicht konfiguriert ist.
5. In der Device Console einen Eintrag mit set proxy-arp add für genau eine IPv4-Adresse anlegen und protokollieren, dass er zuvor nachweislich fehlte und durch dieses Verfahren hinzugefügt wurde.
6. Firewallregel, DNAT oder Route sowie den Rückweg getrennt konfigurieren beziehungsweise kontrollieren.
7. ARP-Antwort, Firewall Rule ID, NAT Rule ID und den echten Dienst mit einer neuen Verbindung prüfen.
8. Nach einem HA-Failover denselben Test wiederholen. Beim Rollback nur den zuvor nachweislich nicht konfigurierten und durch dieses Verfahren hinzugefügten Eintrag mit set proxy-arp del gezielt entfernen; vorhandene Einträge bleiben unangetastet.

Proxy ARP, Alias und Routing unterscheiden

Was Proxy ARP wirklich macht

Bevor ein IPv4-Gerät ein Paket an einen Nachbarn im gleichen Layer-2-Segment senden kann, benötigt es dessen MAC-Adresse. Dafür sendet es eine ARP-Anfrage. Mit Proxy ARP beantwortet die Sophos Firewall eine solche Anfrage für eine andere Ziel-IP mit der MAC-Adresse ihres ausgewählten Interfaces.

Der Upstream sendet die folgenden Ethernet-Frames dadurch an die Firewall. Erst danach entscheiden Routing, NAT und Firewallregeln, was mit dem IP-Paket geschieht. Ein erfolgreicher ARP-Reply beweist deshalb noch keinen funktionierenden veröffentlichten Dienst.

Der von Sophos dokumentierte Device-Console-Befehl gilt für ARP und damit IPv4. Für IPv6 übernimmt Neighbor Discovery die Nachbarauflösung. Aus dem Befehl lässt sich kein Proxy-NDP-Ablauf ableiten.

Welche Variante zur Providerzuteilung passt

• Alias-IP: Die zusätzliche Adresse wird lokal an ein physisches Firewall-Interface gebunden. Das passt, wenn die Firewall die Adresse selbst besitzen oder gezielt für NAT beziehungsweise Systemtraffic verwenden soll. Den vollständigen Ablauf zeigt Alias-IP auf Sophos Firewall einrichten.
• Proxy ARP: Die Firewall antwortet stellvertretend auf die ARP-Anfrage für eine weitergeleitete oder übersetzte IPv4-Adresse. Die Adresse wird durch diesen Befehl nicht als normale Interface-Adresse angelegt.
• Geroutetes Präfix: Der Upstream routet ein ganzes Netz zur WAN-Adresse oder zu einem vereinbarten Next Hop. Dann fragt er normalerweise nicht für jede Zieladresse dieses Präfixes auf dem WAN-Segment per ARP. Ein manueller Proxy-ARP-Eintrag wäre dafür die falsche Reparatur.
• Statischer Neighbor: Dieser ordnet einem direkt erreichbaren Nachbarn eine feste MAC-Adresse zu. Das ist die umgekehrte Blickrichtung und kein Ersatz für Proxy ARP. Die Abgrenzung steht unter ARP- und NDP-Neighbor-Cache prüfen.

Auch eine DNAT-Regel bedeutet nicht automatisch, dass man zusätzlich manuelles Proxy ARP benötigt. Zuerst wird der vorhandene Datenpfad getestet. Ein neuer CLI-Eintrag ist nur gerechtfertigt, wenn Providerdesign und Capture den fehlenden ARP-Reply wirklich belegen und der genaue Eintrag im dokumentierten Konfigurations-Ausgangszustand nachweislich nicht vorhanden ist.

Beispiel und austauschbare Werte

Das Beispiel verwendet eine direkt angeschlossene öffentliche IPv4-Zuteilung. Ein HTTPS-Dienst soll über die zusätzliche Adresse 203.0.113.10 erreichbar sein:

• WAN-Interface: Port2
• WAN-Adresse der Firewall: 203.0.113.9/29
• Provider-Gateway: 203.0.113.14
• zusätzliche öffentliche Ziel-IP: 203.0.113.10
• externer Testhost: 198.51.100.25
• interner Server: 10.20.40.20
• Dienst: HTTPS

203.0.113.0/24 und 198.51.100.0/24 sind Dokumentationsnetze. Sie funktionieren nicht als produktive Adressen und werden vollständig durch die echte Providerzuteilung und einen autorisierten externen Testhost ersetzt. Port2 ist ebenfalls nur ein Beispiel; verwendet wird genau das Interface, auf dem die ARP-Anfrage nachweislich eintrifft.

Die /29-Maske wird nicht in den Proxy-ARP-Befehl übernommen. Sie erklärt nur das Beispielnetz. Der Eintrag selbst gilt bewusst nur für 203.0.113.10. Einen ganzen Bereich beantwortet man erst, wenn Eigentum, Nutzung und Syntax für jede Adresse eindeutig dokumentiert und auf dem eingesetzten Build geprüft sind.

Providerpfad und ARP vor der Änderung prüfen

Vor dem CLI-Eingriff werden drei mögliche Ursachen getrennt:

1. Kein ARP-Request erreicht die Firewall: Dann liegen Providerpfad, VLAN, Switchport oder die Annahme über die Zuteilung vor dem Proxy-ARP-Schritt.
2. Der Request kommt an und bereits ein Gerät antwortet: Dann darf kein zweiter Reply erzeugt werden. Zuerst den Eigentümer der sichtbaren MAC-Adresse klären.
3. Der Request kommt an, aber niemand antwortet: Dieser Befund zeigt die fehlende ARP-Antwort, nicht das Fehlen eines konfigurierten manuellen Proxy-ARP-Eintrags. Die Konfiguration muss unabhängig davon geprüft werden.

Für die Aufnahme per SSH oder lokaler Konsole Option 4: Device Console öffnen. Den Zugang und die Trennung zwischen Device Console und Advanced Shell erklärt Sophos Firewall per SSH verbinden.

Sowohl tcpdump als auch set proxy-arp werden hier in Option 4: Device Console ausgeführt, nicht in der Advanced Shell. Sophos warnt in der Dokumentation zur Device Console, dass ein unvollständiger Befehl den access_server-Daemon blockieren kann. Deshalb die vollständige Zeile vorbereiten, Interface und Ziel-IP nochmals mit dem Capture-Plan vergleichen und keine Parameter durch Ausprobieren ergänzen. Weicht die integrierte Hilfe per Tabulatortaste auf dem installierten Build von der dokumentierten Syntax ab, wird die Änderung gestoppt und zuerst mit Sophos Support geklärt.

Der folgende BPF-Filter ist lesend und begrenzt die Aufnahme auf das Beispielinterface und die Beispieladresse:

tcpdump interface Port2 'arp and host 203.0.113.10'

Danach vom autorisierten externen Testpfad eine neue Verbindung zu 203.0.113.10 starten. Falls der Upstream noch einen Cache-Eintrag hält, nur diesen Eintrag nach dem dokumentierten Verfahren des Routers oder Providers aktualisieren beziehungsweise ablaufen lassen. Ein pauschales Leeren aller ARP-Caches oder ein Routerneustart ist für die Erstdiagnose unverhältnismässig.

Im Capture müssen Interface, Ziel-IP und Zeitpunkt zum Test passen. Eine ARP-Anfrage auf einem anderen VLAN oder Interface wird nicht durch einen Eintrag auf Port2 gelöst.

Konfigurierten Ausgangszustand unabhängig vom Capture feststellen

Vor add wird für die genaue Kombination aus Interface und Zieladresse – im Beispiel Port2 und 203.0.113.10 – festgestellt und dokumentiert, ob bereits ein manueller Proxy-ARP-Eintrag konfiguriert ist. Dafür nur ein für den installierten Build bestätigtes, lesendes Verfahren, einen aktuellen und verlässlichen Nachweis der tatsächlichen Konfiguration oder eine Klärung mit Sophos Support verwenden. Firmwarebuild, Interface, Zieladresse, Ergebnis, Zeitpunkt und verwendeten Nachweis festhalten. Ein alter Änderungsvermerk ohne Abgleich mit der aktuellen Konfiguration genügt nicht. Die dokumentierte Proxy-ARP-Syntax beschreibt add und del, aber keinen Getter; deshalb wird hier kein Lesebefehl erfunden oder durch Ausprobieren abgeleitet.

Ist der konfigurierte Ausgangszustand nicht zuverlässig feststellbar, wird vor jeder Änderung gestoppt. Besteht der Eintrag bereits, wird er weder erneut angelegt noch überschrieben oder im Rahmen dieses Verfahrens gelöscht. Stattdessen Interfacezuordnung, Zieladresse, Capture und bestehenden Datenpfad diagnostizieren; bei Bedarf Sophos Support hinzuziehen. Auch ein konfigurierter Eintrag kann ohne sichtbare ARP-Antwort bleiben. Weder eine fehlende Antwort noch ein leerer Neighbor-Cache oder fehlender ARP-Traffic belegt daher seine Abwesenheit.

Nur ein für dieses Interface und diese Zieladresse nachweislich noch nicht konfigurierter Eintrag darf mit dem folgenden Schritt ergänzt werden. Sein dokumentierter Ausgangszustand und die protokollierte Einführung durch dieses Verfahren sind zugleich die Voraussetzung für die spätere gezielte Bereinigung.

Einzelnen Proxy-ARP-Eintrag anlegen

Nur wenn die Vorprüfung eindeutig ist und der genaue manuelle Eintrag für Interface und Zieladresse im dokumentierten Ausgangszustand nachweislich nicht konfiguriert war, wird in der Device Console genau die bestätigte Adresse ergänzt. Bei bestehendem Eintrag oder unbekanntem Ausgangszustand diesen Befehl nicht ausführen:

set proxy-arp add interface Port2 dest_ip 203.0.113.10

Die festen Teile sind set proxy-arp add interface und dest_ip. Port2 und 203.0.113.10 werden durch das reale Interface und die einzeln bestätigte IPv4-Adresse ersetzt.

Sophos dokumentiert zusätzlich dst_iprange, veröffentlicht auf der aktuellen Hilfeseite aber kein vollständiges Bereichsbeispiel. Deshalb wird hier kein Format geraten. Für öffentliche Bereiche ist eine Einzeladresse ausserdem der sicherere Pilot: Sie begrenzt die Auswirkung und lässt sich eindeutig positiv und negativ testen.

Nach dem Befehl wird sofort erneut ein frischer ARP-Request erzeugt und der Capture wiederholt. Erwartet wird eine Antwort mit der MAC-Adresse des vorgesehenen Firewall-Interfaces. Antwortet eine andere MAC-Adresse oder erscheinen mehrere Antworten, wird der Rollout gestoppt und der Adresskonflikt zuerst geklärt.

Firewallregel, NAT und Rückweg getrennt umsetzen

Proxy ARP zieht das Ethernet-Frame zur Firewall. Der folgende IP-Datenpfad benötigt weiterhin eine eigene, fachlich passende Konfiguration.

Für das Beispiel mit dem internen HTTPS-Server gehören dazu:

• eine enge DNAT-Regel von 203.0.113.10:443 zu 10.20.40.20:443;
• eine passende Firewallregel von der autorisierten WAN-Quelle zur Serverzone;
• Logging während der Abnahme;
• ein Rückweg des Servers über die Sophos Firewall;
• gegebenenfalls Loopback nur als separat geplanter interner Anwendungsfall.

Server per DNAT veröffentlichen führt durch Regelposition, Original Destination, Zielzone, Loopback und Schutzfunktionen. Die Begriffe SNAT, DNAT, MASQ und PAT erklärt NAT auf Sophos Firewall.

Soll die zusätzliche öffentliche Adresse ohne DNAT zu einem nachgelagerten System geroutet werden, benötigt die Firewall stattdessen eine eindeutige Route und passende Regeln. Ein überlappendes Netz darf nicht mit einer geratenen statischen Route oder einem Proxy-ARP-Bereich kaschiert werden. Providerpräfix, interne Adressierung und Rückweg müssen zuerst als zusammenhängendes Routingdesign feststehen.

ARP und echten Dienst abnehmen

Die Abnahme besteht aus einer Layer-2- und einer IP-/Anwendungsprüfung:

1. Einen frischen ARP-Request für 203.0.113.10 erzeugen.
2. Im Capture die Anfrage auf Port2 und genau eine Antwort mit der erwarteten Firewall-MAC bestätigen.
3. Vom Testhost 198.51.100.25 eine neue HTTPS-Verbindung öffnen.
4. Im Log viewer die erwartete Firewall Rule ID und NAT Rule ID kontrollieren.
5. Im Built-in Packet Capture Eingang auf Port2 und Ausgang zum Server vergleichen.
6. Am Server prüfen, ob die Verbindung ankommt und die Antwort über die Firewall zurückläuft.
7. Einen nicht erlaubten Port und eine nicht autorisierte Quelle negativ testen.
8. Falls HA verwendet wird, nach einem kontrollierten Failover eine neue Verbindung und einen neuen ARP-Lauf prüfen.

Erfolg ist erst belegt, wenn ARP-Antwort und echter Dienst stimmen. Ein Ping reicht nicht: ICMP kann unter Device Access oder in der Firewallregel absichtlich anders behandelt werden als HTTPS. Filter, Status, Reason, Rule ID und Interfacevergleich erklärt Packet Capture auf Sophos Firewall; die vollständige Regelabnahme steht unter Firewallregeln systematisch testen.

Fehler systematisch eingrenzen

Keine ARP-Anfrage kommt an

Providerzuteilung, Upstream-Routing, VLAN, Switchport und tatsächliches Eingangsinterface prüfen. Ein lokaler Proxy-ARP-Eintrag kann keine Anfrage beantworten, die das Interface nie erreicht. Bei einem gerouteten Präfix ist eine fehlende ARP-Anfrage für die einzelne Ziel-IP sogar erwartbar; dann sind Route und Next Hop statt Proxy ARP zu prüfen.

ARP-Anfrage kommt an, aber keine Antwort geht heraus

Ziel-IP und Interface im Befehl mit dem Capture vergleichen. Danach ausschliessen, dass das Interface gewechselt, die Adresse falsch geschrieben oder der Test aus einem anderen Layer-2-Segment ausgeführt wurde. Keine breitere IP-Range hinzufügen, um einen unklaren Einzeltest scheinbar zu reparieren.

Bleibt der dokumentierte Eintrag auf dem bestätigten Interface ohne Antwort, Firmwarestand, kurzen Capture und genaue Topologie für Sophos Support sichern. Undokumentierte Advanced-Shell-Eingriffe in ARP- oder Kernelparameter sind kein sicherer Standardschritt.

Mehrere MAC-Adressen antworten

Der Test wird gestoppt. Häufige Ursachen sind eine doppelte IP-Adresse, ein noch aktives Altgerät, ein Alias auf einer zweiten Firewall oder ein weiterer Proxy-ARP-Eintrag. Erst den Eigentümer jeder MAC-Adresse bestimmen und den Adresskonflikt lösen. Eine Firewallregel kann konkurrierende ARP-Antworten nicht korrigieren.

ARP stimmt, aber der Dienst bleibt unerreichbar

Dann hat Proxy ARP seine Aufgabe bereits erfüllt. Als Nächstes werden Firewall Rule ID, NAT Rule ID, Regelreihenfolge, Zielzone, Service, Server-Gateway und Rückweg geprüft. Für eine neue Verbindung darf keine alte Session wiederverwendet werden.

Nach Ersatz oder HA-Failover ist die Adresse kurz unerreichbar

Am zum Ereigniszeitpunkt aktiven Node erneut ARP und den echten Dienst prüfen. Der Upstream kann noch eine alte MAC-Zuordnung halten. Zuerst nur den betroffenen Eintrag kontrolliert aktualisieren; den vollständigen Ablauf für alte Provider- oder Router-Caches zeigt ARP-Probleme nach einer Firewall-Migration beheben.

Es wird keine unterbrechungsfreie Fortsetzung bestehender Verbindungen versprochen. Entscheidend sind ein frischer ARP-Request, eine neue Anwendungssitzung und die Logs des Nodes, der den Traffic tatsächlich verarbeitet.

Rollback und Betrieb

Die folgende Bereinigung gilt ausschliesslich für den genauen Eintrag, der laut dokumentiertem Konfigurations-Ausgangszustand vorher nicht vorhanden war und nachweislich durch dieses Verfahren hinzugefügt wurde. Ein bereits vorhandener Eintrag darf damit nicht entfernt werden; bei unbekanntem Ausgangszustand oder unklarer Zuordnung wird gestoppt und mit Sophos Support geklärt. Vor dem Entfernen wird dokumentiert, welche veröffentlichte Adresse und welcher Dienst vom neu hinzugefügten Eintrag abhängen. Nur unter diesen Voraussetzungen wird im Wartungsfenster derselbe Einzelwert mit del entfernt:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Anschliessend mit dem zuvor bestätigten Verfahren beziehungsweise Konfigurationsnachweis oder Sophos Support prüfen und dokumentieren, dass genau der durch dieses Verfahren eingeführte Eintrag wieder nicht konfiguriert ist. Zusätzlich einen frischen ARP-Request erzeugen. Die Firewall darf für diesen manuellen Eintrag nicht mehr antworten, sofern weder Alias, HA-Peer noch ein anderer legitimer Mechanismus dieselbe Adresse bedient. Eine fehlende Antwort ist nur die Funktionskontrolle und kein Nachweis der gelöschten Konfiguration. Abhängige Testregeln und temporäre NAT-Konfiguration werden auf den dokumentierten Vorzustand zurückgesetzt; nicht durch dieses Verfahren geänderte Konfiguration bleibt unangetastet.

Der Eintrag gehört in die Betriebsdokumentation, weil er nicht als normale Interface-Adresse erklärt, warum die Firewall für die zusätzliche IP antwortet. Nach Interfaceumbau, Ersatzgerät, Restore, Firmwarewechsel oder HA-Test werden Zieladresse, Interface, ARP-Reply und echter Dienst erneut kontrolliert.

Checkliste

• Providerzuteilung und ARP- statt Routingmodell bestätigt.
• Ziel-IP gehört nachweislich zur eigenen Umgebung und ist nicht doppelt belegt.
• ARP-Anfrage trifft auf dem dokumentierten Interface ein.
• Fehlende Antwort vor der Änderung per Capture belegt und davon unabhängig die Abwesenheit des genauen konfigurierten Eintrags für Interface und Zieladresse zuverlässig festgestellt; bei bestehendem oder unbekanntem Eintrag kein add.
• Nur eine einzelne Pilotadresse mit dest_ip eingetragen.
• Firewallregel, NAT oder Route und Rückweg separat geprüft.
• Erwartete MAC-Adresse, Firewall Rule ID und NAT Rule ID bestätigt.
• Nicht erlaubte Quelle und nicht erlaubter Port negativ getestet.
• HA-Failover beziehungsweise Ersatzpfad mit einer neuen Verbindung geprüft.
• Konfigurierter Ausgangszustand samt Nachweis und Einführung protokolliert; exakter del-Befehl nur zur Bereinigung des zuvor nachweislich fehlenden, selbst hinzugefügten Eintrags vorgesehen. Konfiguration und Funktion nach der Bereinigung getrennt geprüft.

FAQ