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 für policy-based IPsec. Für neue oder wachsende Designs ist route-based Any-to-Any mit XFRM und explizitem Routing oft flexibler. 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.

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 dokumentierter Rückweg und ein Wartungsfenster.

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. Ohne passenden Rückweg und NAT kann der Tunnel grün sein, während Internetverbindungen nicht antworten.

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
• 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.

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.

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. Packet Capture zeigt Hin- und Rückpakete über Tunnel und Zentral-WAN.
6. Systemgenerierter Traffic verwendet den vorher festgelegten lokalen oder zentralen Pfad.

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.

Beim Rollback werden zuerst die Filialregel Branch_LAN_to_WAN_drop deaktiviert und der zuvor erlaubte lokale Internetpfad kontrolliert wiederhergestellt. Danach werden VPN-to-WAN-Regel und MASQ nur entfernt, wenn kein anderer Flow sie benötigt. Route Precedence und System-Traffic-Option werden exakt auf die dokumentierten Vorwerte gesetzt; anschliessend folgen neue Tests an beiden Standorten.

FAQ