Sophos Firewall Alias-IP einrichten und testen

Eine Alias-IP bindet eine zusätzliche IPv4- oder IPv6-Adresse an ein bestehendes physisches Interface der Sophos Firewall. Sie ist praktisch, wenn ein Provider mehrere öffentliche Adressen über denselben WAN-Anschluss liefert oder ein internes Interface während einer Migration ein zweites Subnetz bedienen muss.

Der wichtige Unterschied: Ein Alias ist keine zweite Internetleitung, keine eigene Zone und kein separater Gatewaypfad. Die Adresse verwendet dasselbe physische Parent Interface. Routing, Firewallregeln, NAT und Device Access müssen deshalb weiterhin zum bestehenden Interface-Design passen.

⚠️ Vor einer öffentlichen Alias-IP ein aktuelles Backup, eine unabhängige Adminverbindung, die Providerzuteilung, den ursprünglichen ARP-Zustand sowie geplante Firewall- und NAT-Regeln dokumentieren. Eine zusätzliche Adresse veröffentlicht noch keinen Server, kann aber lokale Firewall-Dienste unter den Device-Access-Regeln der Parent-Zone erreichbar machen.

Das Beispiel verwendet IPv4 auf einem WAN-Interface. SFOS unterstützt auch IPv6-Aliase, wenn die IP-Version zum Parent Interface passt. IPv6-Nachbarschaft und NAT66 sind jedoch nicht Gegenstand des konkreten Beispiels.

Alias-IP in acht Schritten

1. Bestätigen, dass der Provider oder das interne Netz die zusätzliche Adresse wirklich über dasselbe physische Interface liefert.
2. Parent Interface, IP-Version, Adresse, Netzmaske und Einsatzzweck dokumentieren.
3. Device Access, bestehende Regeln und einen unabhängigen Managementzugang prüfen.
4. Unter Network > Interfaces > Add interface > Add alias die Adresse an das Parent Interface binden.
5. Für Regeln und NAT bei Bedarf einen sprechenden IP Host mit genau dieser Adresse anlegen.
6. DNAT oder SNAT nur für den vorgesehenen Datenfluss konfigurieren; Systemtraffic getrennt behandeln.
7. Providerpfad, ARP, Firewall Rule ID, NAT Rule ID und Hin- sowie Rückweg mit einer neuen Verbindung prüfen.
8. Ersatzgerät, HA-Failover und Rollback im Wartungsfenster mit dem gleichen Testfluss abnehmen.

Wann eine Alias-IP passt

Eine Alias-IP passt, wenn mehrere Adressen denselben physischen Layer-2- und Gatewaypfad verwenden sollen. Typische Fälle sind:

• mehrere öffentliche IPv4-Adressen auf einem statischen WAN-Anschluss;
• eine eigene öffentliche Adresse für DNAT, WAF oder einen Maildienst;
• eine feste Absenderadresse für ausgewählten weitergeleiteten Traffic;
• ein zweites internes Subnetz auf demselben physischen Segment während einer kontrollierten Migration;
• mehrere Provideradressen im selben Subnetz, für die getrennte WAN-Interfaces ARP-Probleme verursachen würden.

Mehrere WAN-Interfaces im gleichen Subnetz sind keine saubere Ersatzlösung. Sophos warnt, dass dadurch Gateways wegen ARP-Problemen unerreichbar werden können, und nennt Alias oder LAG als passende Interfaceformen. Die grundlegende Auswahl zwischen physischen Ports, VLAN, LAG, Bridge und XFRM erklärt Zonen und Interfaces auf Sophos Firewall.

Ein Alias passt nicht, wenn eine zweite Leitung, ein eigenes Gateway, ein unabhängiger Linkstatus, eine andere Sicherheitszone oder echtes Failover benötigt wird. Dafür braucht es ein eigenes Interface-, VLAN-, LAG-, WAN- oder Routingdesign.

Soll die Firewall eine zusätzliche IPv4-Adresse nicht lokal besitzen, sondern auf einem direkt angeschlossenen Segment nur stellvertretend auf deren ARP-Anfrage antworten, ist das ein anderer Aufbau. Die Entscheidung und den engen CLI-/Testablauf erklärt Proxy ARP auf Sophos Firewall konfigurieren.

Beispiel und austauschbare Werte

Das Beispiel veröffentlicht einen internen HTTPS-Dienst über eine zweite öffentliche Adresse:

• Parent Interface: Port2
• Parent-Zone: WAN
• Hauptadresse: 203.0.113.9/29
• Provider-Gateway: 203.0.113.14
• Alias-IP: 203.0.113.10/29
• Alias-Hostobjekt: WAN_ALIAS_APP_203.0.113.10
• interner Server: APP-DMZ_10.20.40.20
• Server-IP: 10.20.40.20
• Dienst: HTTPS
• externer Testhost: 198.51.100.25

203.0.113.0/24 und 198.51.100.0/24 sind für Dokumentation reserviert. In der produktiven Konfiguration werden sie durch die vom Provider zugeteilten Adressen und einen autorisierten externen Testhost ersetzt.

Die /29-Maske ist nur ein realistisches Beispiel. Sie darf nicht aus dieser Anleitung übernommen werden, wenn der Provider einen gerouteten Block, eine einzelne /32-Adresse oder eine andere Netzgrösse liefert. Entscheidend sind Providerdokumentation, ARP- beziehungsweise Routingmodell und die auf dem Parent Interface verwendete IP-Version.

Alias am physischen Interface anlegen

Unter Network > Interfaces wird die Adresse direkt an das vorhandene Interface gebunden:

1. Add interface > Add alias wählen.
2. Unter Physical interface Port2 oder das tatsächliche Parent Interface auswählen.
3. IP version auf IPv4 setzen.
4. Unter IPv4/Netmask 203.0.113.10 und die vom Provider bestätigte Maske eintragen.
5. Mit Save speichern.

Für einen IPv6-Alias wird IP version passend zum ausgewählten Parent Interface auf IPv6 gesetzt. Unter IPv6/Prefix werden die für die eigene Umgebung zugeteilte IPv6-Adresse und das zugehörige Präfix statt der IPv4-Beispielwerte eingetragen. Anschliessend mit Save speichern.

Danach erscheint die zusätzliche Adresse beim Parent Interface. Sind mehr als drei Aliase vorhanden, zeigt SFOS zunächst nur die ersten drei. Den Mauszeiger über eine der sichtbaren IP-Adressen bewegen, damit die Scrollleiste erscheint. Über den sichtbaren Adressbereich lässt sich zu den weiteren Einträgen scrollen.

Ein Alias lässt sich nicht unabhängig ein- oder ausschalten. Wird das physische Parent Interface deaktiviert oder verliert seinen Link, sind auch seine Alias-Adressen nicht mehr erreichbar. In Add alias wird kein unabhängiges Gateway und keine eigene Default Route konfiguriert. Das schliesst direkt angeschlossene oder lokale Routen für die Adresse beziehungsweise ihr Subnetz nicht aus. Besonders bei einem Alias aus einem anderen Subnetz die Routingtabelle vor und nach dem Speichern vergleichen; der Providerpfad und die unten genannten Mehrsubnetz-Voraussetzungen bleiben entscheidend.

Die Maske Add alias besitzt kein eigenes Zonenfeld. Für lokale Firewall-Dienste bleibt deshalb die Zone des Parent Interface relevant. Vor einer öffentlichen Alias-IP unter Administration > Device access prüfen, welche Dienste aus WAN erreichbar sind, und bei festen Managementquellen eine enge Local Service ACL Exception verwenden. SSO oder MFA rechtfertigen keine breite WebAdmin-Freigabe.

Alias in Regeln und NAT verwenden

Das gebundene Alias und ein IP Host erfüllen unterschiedliche Aufgaben:

• Das Alias macht die Adresse auf dem physischen Interface lokal vorhanden.
• Der IP Host macht dieselbe Adresse in Regeln und NAT-Feldern verständlich auswählbar.

Ein Hostobjekt allein bindet keine Adresse an das Interface. Umgekehrt veröffentlicht ein Alias allein keinen Server und erlaubt keinen weitergeleiteten Traffic. IP-Hosts und Services richtig verwenden erklärt die Objektgrenzen im Detail.

Eingehenden Dienst per DNAT veröffentlichen

Für das Beispiel wird unter Hosts and services > IP host das Objekt WAN_ALIAS_APP_203.0.113.10 vom Typ IP mit 203.0.113.10 erstellt. Danach werden eine enge DNAT-Regel und eine passende Firewallregel angelegt:

• Original source: autorisierte externe Netze oder bewusst Any
• Original destination: WAN_ALIAS_APP_203.0.113.10
• Original service: HTTPS
• Translated destination (DNAT): APP-DMZ_10.20.40.20
• Translated service (PAT): Original
• Inbound interface: Port2 oder der tatsächlich bestätigte Eingang
• Translated source (SNAT): normalerweise Original
• Log firewall traffic: aktiviert

Die Firewallregel erlaubt denselben externen Dienst von WAN zur Zone des internen Servers und verwendet als Destination network die öffentliche Alias-Adresse aus Original destination. Source, Dienst und Schutzfunktionen werden so eng wie möglich gehalten. Der vollständige Aufbau mit Regelposition, Loopback und Härtung steht unter Server per DNAT veröffentlichen.

Weitergeleiteten Traffic über die Alias-IP senden

Soll nur ein bestimmter interner Server ausgehend mit 203.0.113.10 erscheinen, wird eine eigene SNAT-Regel für genau diesen Flow erstellt. Translated source (SNAT) verwendet dann den IP Host der Alias-Adresse. Source, Destination, Service und Interfaces bleiben so eng, wie der Anwendungsfall es erlaubt.

Die NAT-Regel ersetzt keine Firewallregel. Ausserdem werden NAT-Regeln nur für den ersten Paketfluss einer neuen Verbindung ausgewertet. Nach einer Änderung muss deshalb eine neue Verbindung geöffnet werden; eine bereits bestehende Session beweist den neuen NAT-Pfad nicht. Die Verarbeitung von SNAT, DNAT und PAT erklärt NAT auf Sophos Firewall.

Systemtraffic der Firewall getrennt behandeln

DNS-, Authentisierungs-, Mail- oder anderer Traffic, den die Firewall selbst erzeugt, folgt nicht automatisch einer SNAT-Regel für weitergeleitete Clients. Sophos dokumentiert ausdrücklich, dass Routingkonfigurationen das Hauptinterface verwenden. Soll ein einzelner, begründeter Systemtraffic-Flow die Alias-IP als Source verwenden, ist dafür eine separate CLI-Konfiguration nötig.

Vor der Änderung in der Device Console den Ausgangszustand sichern:

show advanced-firewall

Das folgende optionale Beispiel verwendet Port2, das Ziel 198.51.100.25 und die Alias-IP 203.0.113.10. Es bleibt als Vorlage erhalten, darf aber erst nach Bestätigung der Syntax und des tatsächlichen Match-Geltungsbereichs für das installierte Build ausgeführt werden:

⚠️ Dieser Befehl verändert die Source-Adresse von Firewall-Traffic. Er erstellt keine Route und ist kein allgemeiner Ersatz für eine NAT-Regel. In der dokumentierten Syntax sind destination und snatip Pflichtparameter; netmask und interface sind optional. Die öffentlichen SFOS-22/23-Beschreibungen erklären jedoch nicht, welches Adressfeld netmask abgrenzt oder wie interface den Match begrenzt. Vor Verwendung dieser optionalen Parameter Syntax und Abgrenzung anhand build-spezifischer Dokumentation oder durch Sophos Support bestätigen lassen. Ohne diese Bestätigung das Beispiel nicht ausführen; aus der Parameterliste keine garantierte Interface- oder Zielnetzbegrenzung ableiten. Ist der geplante Eintrag bereits vorhanden oder überschneidet er sich mit einer ungeklärten bestehenden Konfiguration, den Test ohne Hinzufügen oder Löschen abbrechen. Nach der Änderung genau den betroffenen Dienst und dessen tatsächlichen Paketfluss testen und den Eintrag erneut mit show advanced-firewall kontrollieren.

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Für den Rollback wird exakt derselbe Eintrag mit delete entfernt:

⚠️ Das Entfernen ändert die Source-Adresse des betroffenen Systemtraffics zurück. Vorher den Eintrag mit show advanced-firewall mit dem gesicherten Ausgangszustand vergleichen und Abhängigkeiten prüfen. Nur den für diesen Test hinzugefügten Eintrag entfernen; danach den betroffenen Dienst und den Zustand erneut kontrollieren.

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Die /32-Maske 255.255.255.255 ist im Beispiel bewusst für den beabsichtigten einzelnen Zielhost gewählt, aber keine Syntaxpflicht und ohne bestätigte Match-Semantik kein Beweis für diesen Geltungsbereich. Auch bei einer breiteren Maske nicht pauschal eine Übersetzung des gesamten Zielnetzes annehmen. Zuerst das tatsächlich betroffene Adressfeld und den resultierenden Umfang für das installierte Build bestätigen lassen; nur einen beabsichtigten, dokumentierten Umfang verwenden und den betroffenen Dienst sowie nicht betroffene Flows kontrollieren.

IPsec über ein Alias bei mehreren WAN-Interfaces

Wenn mehrere WAN-Interfaces vorhanden sind und eine IPsec-Verbindung eine Alias-Adresse als lokale Adresse verwendet, verlangt Sophos die Source-Based Route für Aliase. Die Option ist kein allgemeiner Alias-Schalter und wird nicht nur wegen DNAT, SNAT oder eines zweiten Subnetzes aktiviert.

Aktivieren für den beschriebenen IPsec-Fall: Vor der Änderung den bisherigen Optionszustand, WAN-Interfaces, Alias, lokale Tunneladresse, Routingtabelle, aktive SAs und einen Rückweg dokumentieren.

Die offiziellen Routingbeschreibungen für SFOS 22 und 23 dokumentieren für diese Option den Setter, aber keinen Getter und keinen Default. Vor dem Setzen müssen eine für das installierte Build dokumentierte oder durch Sophos Support bestätigte Lesemethode, der damit erhobene tatsächliche Ausgangswert und ein bestätigter Weg zu dessen exakter Wiederherstellung vorliegen. Fehlt eine dieser Voraussetzungen, die Option nicht ändern; keinen Lese- oder Reset-Befehl erraten. Routingtabelle, aktive SAs und Verbindungstests sind zusätzliche Betriebsprüfungen, kein Readback des Schalters. War die Option bereits aktiviert, sie unverändert lassen und beim Rollback nicht deaktivieren.

⚠️ Diese Option verändert die source-basierte Routingbehandlung für Alias-Adressen. Nur für den bestätigten Bedarf in der Device Console aktivieren und einen unabhängigen Managementzugang sichern:

set routing source-base-route-for-alias enable

enable erzeugt die benötigte source-basierte Routingbehandlung für Alias-Adressen, aber weder einen IPsec-Tunnel noch eine Firewallregel oder eine XFRM-, statische beziehungsweise SD-WAN-Route. Bei route-based IPsec bleibt deshalb die Route zur XFRM-Schnittstelle separat erforderlich; bei policy-based IPsec gelten weiterhin die konfigurierten lokalen und entfernten Netze.

Nach dem Aktivieren den tatsächlichen Optionswert mit derselben bestätigten Lesemethode erneut erheben und mit dem beabsichtigten Zustand vergleichen. Zusätzlich eine neue Verbindung in beiden Richtungen prüfen und Routingtabelle sowie aktive SAs mit dem Ausgangszustand vergleichen.

Bedingter Rollback – nicht als nächster Konfigurationsschritt: disable ist nur dann der Rückweg, wenn die Option vorher deaktiviert war und keine andere IPsec-Verbindung über ein Alias davon abhängt. Vorher diese beiden Bedingungen anhand der dokumentierten Konfiguration prüfen.

⚠️ Das Deaktivieren nimmt die source-basierte Routingbehandlung zurück und kann davon abhängige IPsec-Verbindungen beeinträchtigen. Nur nach bestätigtem vorherigem Zustand und geprüften Abhängigkeiten in der Device Console ausführen:

set routing source-base-route-for-alias disable

Nach der Rücknahme den tatsächlichen Optionswert mit derselben bestätigten Lesemethode erneut erheben und die exakte Übereinstimmung mit dem aufgezeichneten Ausgangswert bestätigen. Danach Routingtabelle, aktive SAs und eine neue Verbindung in beiden Richtungen erneut prüfen. Die Tunnel- und Routentypen erklärt Site-to-Site IPsec VPN einrichten; die XFRM-Route steht unter IPsec Route auf Sophos Firewall.

Aliase aus verschiedenen Subnetzen planen

Sophos erlaubt mehrere Alias-Adressen aus unterschiedlichen Subnetzen auf demselben physischen Interface, stellt dafür aber zwei Bedingungen:

• Für interne Hosts muss Sophos Firewall das Default Gateway sein.
• Upstream-Geräte, die als Gateway für Firewall-Traffic dienen, müssen in jedem verwendeten Alias-Subnetz eine passende Adresse besitzen.

Ein zweites Subnetz wird durch das Alias also nicht automatisch Ende-zu-Ende funktionsfähig. Host-Gateway, Gegenstellen, Rückroute, ARP beziehungsweise Neighbor Discovery, Firewallregeln und NAT müssen für dieses Subnetz ebenfalls stimmen.

Für eine dauerhafte Segmentierung ist ein eigenes VLAN oder physisches Interface meist verständlicher. Ein Mehrsubnetz-Alias eignet sich eher für einen bewusst geplanten Übergang oder eine Providerarchitektur, bei der beide Netze tatsächlich auf demselben Layer-2-Pfad liegen.

DHCP-Server und DHCP Relay können nicht auf einem Interface Alias konfiguriert werden. Ein Alias ist ausserdem kein zulässiger Dedicated HA link. Solche Anforderungen gehören auf ein unterstütztes physisches oder virtuelles Interface.

Datenpfad und ARP kontrolliert abnehmen

Die Abnahme folgt der tatsächlichen Aufgabe und nicht nur einem Ping:

1. Unter Network > Interfaces Parent Interface, Alias-Adresse, Maske und Linkstatus prüfen.
2. Am Provider- oder Upstream-Gerät kontrollieren, ob die Alias-IP über die erwartete MAC-Adresse beziehungsweise den erwarteten Nachbarn erreichbar ist.
3. Von 198.51.100.25 eine neue HTTPS-Verbindung zur Alias-IP öffnen.
4. Im Log Viewer die erwartete Firewall Rule ID, NAT Rule ID, Source, Original destination und übersetzte Destination prüfen.
5. Im Built-in Packet Capture Eingang auf Port2 und Ausgang zum Server vergleichen.
6. Auf dem internen Server bestätigen, dass die Verbindung ankommt und die Antwort über Sophos Firewall zurückläuft.
7. Einen bewusst nicht erlaubten Port sowie eine nicht erlaubte Quelle negativ testen.
8. Bei HA einen kontrollierten Failover mit einer neuen Verbindung wiederholen, ohne unterbrechungsfreie Fortsetzung einer bestehenden Session vorauszusetzen.

Ein Ping auf die Alias-IP ist nur aussagekräftig, wenn Ping für die Parent-Zone unter Device Access bewusst erlaubt ist. Für einen veröffentlichten HTTPS-Dienst ist der echte TCP- und Applikationstest der bessere Erfolgsnachweis. Filter, Interfacevergleich und Export erklärt Packet Capture auf Sophos Firewall.

Fehler systematisch eingrenzen

Alias ist sichtbar, aber von aussen nicht erreichbar

• Bestätigen, dass der Provider die konkrete Adresse wirklich über Port2 liefert.
• IP, Maske und Parent Interface mit der Providerzuteilung vergleichen.
• ARP- beziehungsweise Neighbor-Eintrag auf dem Upstream-Gerät prüfen.
• Device Access nur für Zugriffe auf die Firewall selbst untersuchen.
• Für weitergeleitete Dienste Firewall Rule ID, NAT Rule ID und Server-Rückweg prüfen.

Für das IPv4-Beispiel die ARP-Einträge der Hauptadresse 203.0.113.9 und der Alias-IP 203.0.113.10 getrennt mit der aktuellen WAN-MAC-Adresse vergleichen. Funktioniert die Hauptadresse, während das Alias noch auf die alte MAC-Adresse zeigt und beim externen Test keine Pakete auf Port2 ankommen, ist ein veralteter Upstream-Eintrag ein konkreter Ansatzpunkt. Kommen Pakete bereits an, zuerst den Firewall-/NAT-Pfad und die Serverantwort untersuchen statt den Router auf Verdacht neu zu starten. Ein fehlender Eintrag allein beweist die Ursache nicht; bei einem gerouteten Providerblock zusätzlich die bestätigte Route und deren nächsten Hop prüfen. IPv6 verwendet Neighbor Discovery statt ARP.

⚠️ Cache-Leeren und Routerneustart sind keine garantiert unterbrechungsfreien Reparaturen. Vorher den Geräte- beziehungsweise Providerverantwortlichen einbeziehen, das dokumentierte Verfahren und den Eingriffsumfang bestätigen sowie Konsolen- oder einen unabhängigen Managementzugang sichern. Auch der Fernzugriff zur Firewall kann über diesen Router laufen und dabei abbrechen. Ohne Kontrolle über das Upstream-Gerät den Provider mit betroffener IP, alter/neuer MAC-Adresse und Testergebnis beauftragen. Nach der Änderung den neuen Eintrag, denselben externen HTTPS-Test und einen nicht betroffenen Dienst prüfen; bleibt der Fehler bestehen, die Befunde eskalieren statt wiederholt den gesamten Cache zu leeren.

Nach einem Firewall-Ersatz kann der Upstream-Router für die Alias-IP noch die alte MAC-Adresse gespeichert haben. Sophos nennt in diesem Fall das Leeren des Routercaches oder einen Routerneustart. In der Praxis zuerst nur den betroffenen ARP- beziehungsweise Neighbor-Eintrag mit dem dokumentierten Verfahren des Upstream-Geräts aktualisieren; ein vollständiger Neustart gehört ins Wartungsfenster.

Ausgehender Traffic verwendet weiter die Hauptadresse

Bei weitergeleitetem Traffic prüfen, ob die erwartete SNAT-Regel eine neue Verbindung trifft. Source, Destination, Service, Inbound Interface, Outbound Interface und NAT Rule ID müssen übereinstimmen.

Bei Firewall-Systemtraffic ist eine normale SNAT-Regel nicht der richtige Beweis. Dann den konkreten sys-traffic-nat-Eintrag, Route, Ziel und tatsächlichen Paketfluss prüfen. Keine breite Übersetzung auf Verdacht hinzufügen.

Nur das zweite interne Subnetz funktioniert nicht

Kontrollieren, ob Sophos Firewall wirklich Default Gateway der betroffenen Hosts ist und ob das Upstream-Gerät eine passende Adresse in diesem Subnetz besitzt. Danach Rückroute, Hostmaske, ARP, Firewallregel und NAT getrennt prüfen. Ein sichtbares Alias beweist diese Abhängigkeiten nicht.

IPsec-Tunnel über ein Alias ist grün, aber transportiert keinen Traffic

Zuerst SFOS-Version, Build, Appliance-Modell, PPPoE-Nutzung, Aliasbindung, IPsec Acceleration und tatsächlichen Paketpfad sichern. SFOS 22 besitzt versionsgebundene Alias-/Acceleration-Sonderfälle, die nicht auf jede Alias-Störung übertragen werden dürfen. Der abgegrenzte Diagnoseweg steht im IPsec-Troubleshooting für Alias-Interfaces.

Betrieb, Ersatzgerät und Rollback

Alias-Adressen gehören zusammen mit Providerzuteilung, DNS, Zertifikaten, NAT, Firewallregeln und verantwortlichem Dienst dokumentiert. Vor einem Firewall-Ersatz müssen besonders die öffentlichen Aliase und der erwartete ARP- beziehungsweise Neighbor-Wechsel Teil der Abnahme sein.

Für einen Rollback:

1. Aktive Verwendungen des Alias und des zugehörigen IP Hosts dokumentieren.
2. Veröffentlichte Dienste kontrolliert aus DNS, Monitoring oder Load Balancing nehmen.
3. Zugehörige Firewall- und NAT-Regeln erst deaktivieren und den Ausfall des geplanten Flows bestätigen.
4. Mit dem exakten delete-Befehl nur sys-traffic-nat-Einträge entfernen, die während dieser Änderung hinzugefügt wurden und im gesicherten Ausgangszustand fehlten. Bestehende Einträge erhalten; wurde ein bestehender Eintrag geändert, seine dokumentierte vorherige Konfiguration exakt wiederherstellen und mit show advanced-firewall sowie einem Diensttest prüfen. Die Stilllegung bereits produktiver Einträge erfordert nach der Abhängigkeitsprüfung eine separat autorisierte Entfernung.
5. Alias und Hostobjekt erst löschen, wenn keine produktive Abhängigkeit mehr besteht.
6. Parent Interface, Hauptadresse, Gateway und nicht betroffene Dienste erneut prüfen.
7. In HA dieselbe Abnahme nach einem geplanten Failover wiederholen.

Ein Alias darf nicht als Dedicated HA link verwendet werden. Welche Interfaces, Peer-Admin-Adressen und Failovertests ein Cluster benötigt, erklärt HA auf Sophos Firewall.

Checkliste

• Providerzuteilung, Parent Interface, IP-Version, Adresse und Maske sind bestätigt.
• Backup und unabhängige Adminverbindung sind vorhanden.
• Device Access und Local Service ACL der Parent-Zone sind geprüft.
• Alias und gleichnamiges IP Hostobjekt werden nicht miteinander verwechselt.
• Firewall- und NAT-Regel sind auf den vorgesehenen Flow begrenzt.
• Systemtraffic wird nur bei begründetem Bedarf separat übersetzt.
• Firewall Rule ID, NAT Rule ID, ARP und Hin- sowie Rückweg sind bestätigt.
• Nicht erlaubte Quelle und nicht erlaubter Dienst wurden negativ getestet.
• Ersatzgerät, HA-Failover und Rollback sind dokumentiert.

Häufige Fragen