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. Erst danach wird ein einzelner Proxy-ARP-Eintrag 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

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.
Ausschliessen, dass die Adresse bereits als Alias, auf einem anderen Gerät oder durch einen vorhandenen Aufbau verwendet wird.
Während einer neuen Verbindung einen ARP-Capture auf dem erwarteten Eingangsinterface erstellen.
Nur fortfahren, wenn die ARP-Anfrage für die Zieladresse ankommt und die benötigte Antwort der Firewall nachweislich fehlt.
In der Device Console einen Eintrag mit set proxy-arp add für genau eine IPv4-Adresse anlegen.
Firewallregel, DNAT oder Route sowie den Rückweg getrennt konfigurieren beziehungsweise kontrollieren.
ARP-Antwort, Firewall Rule ID, NAT Rule ID und den echten Dienst mit einer neuen Verbindung prüfen.
Nach einem HA-Failover beziehungsweise beim Rollback denselben Test wiederholen und den Eintrag mit set proxy-arp del gezielt entfernen.

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. Der CLI-Eintrag ist nur gerechtfertigt, wenn Providerdesign und Capture den fehlenden ARP-Reply wirklich belegen.

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:

Kein ARP-Request erreicht die Firewall: Dann liegen Providerpfad, VLAN, Switchport oder die Annahme über die Zuteilung vor dem Proxy-ARP-Schritt.
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.
Der Request kommt an, aber niemand antwortet: Nur dieser Befund passt zu einem fehlenden Proxy-ARP-Reply auf der Firewall.

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.

Der folgende BPF-Filter ist lesend und zeigt nur ARP-Verkehr zur Beispieladresse:

tcpdump '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.

Einzelnen Proxy-ARP-Eintrag anlegen

Wenn die Vorprüfung eindeutig ist, wird in der Device Console genau die bestätigte Adresse ergänzt:

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, getestetes 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:

Einen frischen ARP-Request für 203.0.113.10 erzeugen.
Im Capture die Anfrage auf Port2 und genau eine Antwort mit der erwarteten Firewall-MAC bestätigen.
Vom Testhost 198.51.100.25 eine neue HTTPS-Verbindung öffnen.
Im Log viewer die erwartete Firewall Rule ID und NAT Rule ID kontrollieren.
Im Built-in Packet Capture Eingang auf Port2 und Ausgang zum Server vergleichen.
Am Server prüfen, ob die Verbindung ankommt und die Antwort über die Firewall zurückläuft.
Einen nicht erlaubten Port und eine nicht autorisierte Quelle negativ testen.
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

Vor dem Entfernen wird dokumentiert, welche veröffentlichte Adresse und welcher Dienst vom Eintrag abhängen. Im Wartungsfenster wird derselbe Einzelwert mit del entfernt:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Anschliessend 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. Abhängige Testregeln und temporäre NAT-Konfiguration werden auf den dokumentierten Vorzustand zurückgesetzt.

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.
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.
Exakter del-Befehl und ursprünglicher Zustand dokumentiert.

FAQ

Braucht jede DNAT-Regel einen manuellen Proxy-ARP-Eintrag?

Nein. DNAT und Proxy ARP sind getrennte Funktionen. Manuelles Proxy ARP wird nur ergänzt, wenn der Upstream für die zusätzliche IPv4-Adresse auf dem direkt angeschlossenen Segment ARP verwendet und die benötigte Firewall-Antwort nachweislich fehlt.

Was ist der Unterschied zwischen Alias-IP und Proxy ARP?

Eine Alias-IP bindet die Adresse an ein physisches Firewall-Interface. Proxy ARP lässt die Firewall nur stellvertretend auf eine IPv4-ARP-Anfrage antworten. Welche Variante passt, entscheidet das Provider-, Routing-, NAT- und Systemtraffic-Design.

Funktioniert der Befehl auch für IPv6?

Nein. Der dokumentierte Befehl betrifft ARP und damit IPv4. IPv6 nutzt Neighbor Discovery. Ohne einen separat dokumentierten und getesteten SFOS-Ablauf darf Proxy ARP nicht auf IPv6 übertragen werden.