Filial-Internet über eine IPsec-Zentrale leiten

Soll der Internettraffic einer Filiale zentral geprüft und über die WAN-Verbindung des Hauptstandorts ausgegeben werden, kann Sophos Firewall dafür einen policy-based Site-to-Site-IPsec-Tunnel verwenden. Die Filialclients senden dann nicht direkt ins lokale WAN, sondern über den Tunnel zur Zentrale. Dort greifen die zentralen Firewall-, NAT- und Security-Regeln.

Filial-LAN → Filial-Firewall → policy-based IPsec → Zentrale → MASQ → Internet

Der Aufbau ist bewusst mehr als ein grüner VPN-Tunnel. Route Precedence, Traffic Selectors, Regelreihenfolge und Rückweg müssen zusammenpassen. Fällt der Tunnel oder die Zentrale aus, besitzt die Filiale in diesem Design normalerweise keinen automatischen lokalen Internet-Breakout.

⚠️ Dieser Ablauf gilt ausschliesslich für policy-based IPsec. Die Gegenstelle darf nicht route-based konfiguriert sein. Für neue oder wachsende Designs empfiehlt sich route-based Any-to-Any: Dort setzen beide Seiten die Selektoren auf Any, erhalten je ein XFRM-Interface und benötigen explizite Static-, SD-WAN- oder dynamische Routen. Diese Schritte sind nicht mit dem folgenden policy-based Ablauf kombinierbar. Die Typentscheidung erklärt Site-to-Site IPsec VPN einrichten.

Beispiel und Voraussetzungen

Im Beispiel verwendet die Filiale 10.20.0.0/24. Die Zentrale besitzt eine funktionierende WAN-Verbindung und einen bereits geplanten policy-based Tunnel. 10.20.0.0/24 ist ein Dokumentationswert und wird durch das echte Filialnetz ersetzt.

Für diesen Aufbau muss die globale Route Precedence VPN, Static, SD-WAN lauten. Vor einer Änderung wird der Istwert gesichert und geprüft, welche anderen statischen, VPN- und SD-WAN-Pfade davon betroffen sind. Der kontrollierte Ablauf steht unter Route Precedence sicher ändern.

SFOS 22 verwendet standardmässig Static, SD-WAN, VPN. Die Abweichung ist hier nötig, weil die Filiale mit Remote subnet: Any eine automatisch erzeugte policy-based VPN-Route für alle Ziele erhält. Die bestehende statische Default Route 0.0.0.0/0 zum lokalen WAN wird nicht gelöscht: Sie bleibt für Firewall-Systemtraffic mit deaktivierter VPN-Nutzung und für einen kontrollierten Rollback erhalten. Der Istwert wird in der Device Console mit system route_precedence show gelesen; der Artikel zur Route Precedence enthält Set-Befehl, Auswirkungsanalyse und Rückweg.

Vor dem Change müssen ausserdem stehen:

• ein funktionierender policy-based IPsec-Tunnel zwischen beiden Firewalls;
• ein getesteter Administrationszugang zu beiden Standorten;
• genügend Internet- und Firewall-Kapazität an der Zentrale;
• DNS, Web Policies, IPS, Application Control und gewünschte Ausnahmen;
• ein aktuelles Konfigurationsbackup und ein Change-Protokoll mit ursprünglichen Selektoren, Route Precedence, System-Traffic-Option sowie Firewall- und NAT-IDs;
• ein dokumentierter Rückweg und ein Wartungsfenster.

Bei HA wird vorab pro Standort festgehalten, welcher Node aktiv ist, ob der Cluster fehlerfrei ist und ob Managementzugang zum Peer besteht. HA ersetzt weder ein zweites Zentral-WAN noch einen zweiten Standort. Ein Failover wird deshalb als eigener Testfall behandelt und nicht aus einem grünen Tunnel abgeleitet.

IPsec-Selektoren setzen

Auf der Zentrale wird Local subnet auf Any und Remote subnet auf das Filial-LAN gesetzt. In der Filiale ist es umgekehrt: lokales Filialnetz und entfernt Any.

Der Tunnel wird danach mit einem internen Testziel in der Zentrale geprüft. Erst wenn Standorttraffic in beide Richtungen funktioniert, wird der Internetpfad aktiviert. So bleibt ein IPsec-Fehler von einem NAT- oder Regelproblem unterscheidbar.

Firewall- und NAT-Regeln erstellen

Die Regeln werden unter Rules and policies > Firewall rules angelegt. Automatisch erzeugte VPN-Regeln reichen für diesen Internetpfad nicht als fertiges Design.

Zentrale: VPN nach WAN

Eine Regel Branch_VPN_to_WAN erlaubt den Verkehr aus der Filiale ins Internet:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: nur die tatsächlich benötigten Dienste
• Log firewall traffic: aktiviert
• Create linked NAT rule > Translated source (SNAT): MASQ

Web Policy, IPS, Application Control und TLS Inspection werden bewusst gewählt. Die verknüpfte MASQ-Regel übersetzt die Filialclients auf die öffentliche Adresse der Zentrale. Da SFOS ausgehenden Traffic zuerst gegen die Firewallregel und danach gegen SNAT prüft, muss auch die NAT-Reihenfolge kontrolliert werden: Eine frühere passende NAT-Regel gewinnt vor der verknüpften Regel. NAT erzeugt zudem keine Route, und geänderte NAT-Regeln erfassen nur neue Verbindungen.

Der Rückweg besteht aus zwei getrennten Teilen: Internetantworten kehren dank MASQ zur WAN-Adresse der Zentrale zurück; für das danach zurückübersetzte Ziel 10.20.0.0/24 verwendet die Zentrale ihre automatisch erzeugte policy-based VPN-Route. Liegt das Filialnetz hinter einem weiteren Router, muss dessen Hin- und Rückweg zusätzlich dokumentiert und getestet werden. Ohne diese Pfade kann der Tunnel grün sein, während Internetverbindungen keine Antwort erhalten.

Filiale: LAN nach VPN erlauben

Die Regel Branch_LAN_to_VPN steht oberhalb einer lokalen LAN-to-WAN-Freigabe:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: nur die tatsächlich benötigten Dienste
• Log firewall traffic: aktiviert

Danach folgt eine gezielte Drop-Regel Branch_LAN_to_WAN_drop für dasselbe Filialnetz von LAN nach WAN. Sie verhindert, dass ein zu breiter lokaler Internetzugang den geplanten Tunnelpfad umgeht. Andere Netze oder ausdrücklich geplante lokale Dienste werden nicht versehentlich mit erfasst.

Die Reihenfolge ist Teil der Sicherheitswirkung: spezifische Ausnahmen, Branch_LAN_to_VPN, danach Branch_LAN_to_WAN_drop, erst anschliessend breitere Regeln. Vorhandene Sessions werden nach Änderungen nicht als alleiniger Test verwendet; für die Abnahme werden neue Clientverbindungen aufgebaut.

Wie Regelposition, Rule ID und verknüpfte NAT-Regel zusammen geprüft werden, erklärt Firewall-Regeln sicher erstellen.

Systemgenerierten Traffic bewusst entscheiden

Die Regeln oben steuern weitergeleiteten Clienttraffic. DNS, NTP, Updates, Central oder andere Verbindungen, welche die Filial-Firewall selbst erzeugt, sind systemgenerierter Traffic.

Auch DNS wird nach seinem Ursprung getrennt: Nutzt ein Client einen öffentlichen Resolver, folgt seine Anfrage dem Clientpfad durch den Tunnel. Nutzt er einen internen Resolver in der Zentrale, müssen Selektor, Firewallregel und Rückroute dieses Ziel erlauben. Nur DNS-Anfragen der Filial-Firewall selbst folgen der nachstehenden System-Traffic-Option. Deshalb werden eine öffentliche IP und ein FQDN getrennt getestet.

Die Standardeinstellung ist enable. Da ein bestehendes System davon abweichen kann, zeigt dieser lesende Befehl in der Device Console zuerst den aktuellen Status:

show routing policy-based-ipsec-vpn system-generate-traffic

Soll nur der Clienttraffic über die Zentrale laufen, kann systemgenerierter Firewall-Traffic lokal über das Filial-WAN ausgegeben werden:

set routing policy-based-ipsec-vpn system-generate-traffic disable

⚠️ Diese Änderung startet alle IPsec-Tunnel der Firewall neu. Vorher Status, Wartungsfenster und Rückweg sichern. Der Befehl wird nicht nur zum Testen oder auf Verdacht ausgeführt.

Für den Rollback wird der dokumentierte Vorzustand wiederhergestellt. War die Option vorher aktiv, lautet der Gegenbefehl:

set routing policy-based-ipsec-vpn system-generate-traffic enable

Nach jeder Änderung werden alle IPsec-Verbindungen und die benötigten Firewall-Dienste erneut geprüft.

Datenpfad abnehmen

Ein Client aus 10.20.0.0/24 ruft zuerst eine öffentliche IP und danach einen FQDN über HTTPS auf. Die Abnahme belegt mehrere Ebenen:

1. In der Filiale trifft Branch_LAN_to_VPN; die lokale LAN-to-WAN-Drop-Regel bleibt für diesen erfolgreichen Flow ohne Treffer.
2. In der Zentrale trifft Branch_VPN_to_WAN und die verknüpfte MASQ-Regel.
3. Die öffentlich sichtbare Quell-IP gehört zur Zentrale.
4. DNS, HTTPS und ein bewusst gesperrtes Ziel verhalten sich gemäss der zentralen Policy.
5. Unter Diagnostics > Packet capture zeigen In interface, Out interface, Rule ID, NAT ID, Status und Reason Hin- und Rückpakete über Tunnel und Zentral-WAN.
6. Systemgenerierter Traffic verwendet den vorher festgelegten lokalen oder zentralen Pfad.
7. Current activities > IPsec connections bleibt während des Tests aufgebaut; im Log viewer sind keine unerwarteten Drops zu sehen.
8. Bei HA wird ein freigegebener Node-Failover separat durchgeführt und derselbe komplette Test danach wiederholt. Ohne diesen Test wird keine HA-Redundanz behauptet.

Ein Speedtest allein ist kein vollständiger Nachweis. Zusätzlich sollten reale Anwendungen, DNS, Security-Logs und ein längerer Download geprüft werden. Bei Leistungsproblemen helfen die getrennten Abläufe zu Internet-Speedtests sowie MTU und MSS im VPN.

Typische Fehler und Rollback

• Filialclient nutzt weiterhin das lokale WAN: Regelreihenfolge, Source Network, LAN-to-VPN-Regel und Drop-Regel prüfen. Keine breite Ausnahme als Schnellfix ergänzen.
• Tunnel ist grün, aber Internet fehlt: In der Zentrale VPN-to-WAN-Regel, Rule ID, MASQ, WAN-Gateway, DNS und Rückweg prüfen.
• Nur die Firewall selbst nimmt den falschen Pfad: Status von policy-based-ipsec-vpn system-generate-traffic prüfen. Client- und Systemtraffic nicht verwechseln.
• Nach der CLI-Änderung fallen weitere Tunnel aus: Der Neustart aller IPsec-Tunnel ist dokumentiertes Verhalten. Den Vorzustand wiederherstellen und sämtliche Tunnel einzeln abnehmen.
• Tunnel oder Zentrale fällt aus: Das Standarddesign bietet keinen lokalen Internet-Breakout. Ein solcher Fallback benötigt einen bewusst geplanten separaten Sicherheits- und Routingpfad.
• Öffentliche IP funktioniert, FQDN nicht: Client-DNS-Adresse, DNS-Regel, zentralen Resolverpfad und Antwortpakete prüfen. Die System-Traffic-Option ist nur relevant, wenn die Firewall selbst die Anfrage erzeugt.

Für den Rollback wird zuerst oberhalb von Branch_LAN_to_WAN_drop eine temporäre LAN-to-WAN-Freigabe nur für einen Testclient vorbereitet. Danach wird die Route Precedence auf den dokumentierten Vorwert zurückgesetzt und mit einer neuen Session dieses Clients geprüft, ob das lokale WAN wieder trägt. Schlägt der Test fehl, werden Route Precedence und Regelzustand über den unabhängigen Managementzugang sofort auf den Full-Tunnel-Stand zurückgesetzt. Erst nach erfolgreichem Test werden die frühere reguläre LAN-to-WAN-Regel aktiviert, Branch_LAN_to_WAN_drop deaktiviert und die temporäre Freigabe entfernt.

Anschliessend wird die System-Traffic-Option auf ihren Vorwert gesetzt; wegen des Tunnelneustarts werden danach alle IPsec-Verbindungen geprüft. Branch_LAN_to_VPN, VPN-to-WAN und MASQ werden nur deaktiviert oder entfernt, wenn Rule ID, NAT ID und Nutzung zeigen, dass kein anderer Flow sie benötigt. Zuletzt werden die ursprünglichen IPsec-Selektoren wiederhergestellt oder der nur für diesen Pfad angelegte Tunnel entfernt. Bis neue DNS-, HTTPS- und Anwendungssessions an beiden Standorten erfolgreich sind, bleiben Konfigurationsbackup und unabhängiger Managementzugang verfügbar.

FAQ