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.

Danach erscheint die zusätzliche Adresse beim Parent Interface. Sind mehr als drei Aliase vorhanden, zeigt SFOS zunächst nur die ersten drei. Ü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. Umgekehrt erzeugt das Speichern des Alias keinen neuen Gatewayeintrag und keine eigene Route.

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 Beispiel übersetzt nur Systemtraffic über Port2 zum einzelnen Ziel 198.51.100.25 auf die Alias-IP 203.0.113.10:

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

⚠️ Dieser Befehl verändert die Source-Adresse von Firewall-Traffic. Er erstellt keine Route und ist kein allgemeiner Ersatz für eine NAT-Regel. Ziel, /32-Netzmaske, Interface und Alias-IP müssen zur realen Anwendung passen. Nach der Änderung genau den betroffenen Dienst testen und den Eintrag erneut mit show advanced-firewall kontrollieren.

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

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

Breitere Netzmasken übersetzen den Traffic zu einem ganzen Zielnetz. Das sollte nur verwendet werden, wenn dieser grössere Geltungsbereich fachlich beabsichtigt, dokumentiert und getestet ist.

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.

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. Einen vorhandenen sys-traffic-nat-Eintrag mit dem exakten delete-Befehl entfernen.
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