Sophos Firewall GRE-Tunnel konfigurieren und testen

Ein GRE-Tunnel verbindet zwei IP-Endpunkte und transportiert darin gerouteten Traffic. Auf Sophos Firewall wird er in der Device Console mit system gre angelegt. Das passt beispielsweise für einen Provider-On-Ramp, einen einfachen Overlay-Pfad oder einen Transport, der ausdrücklich GRE erwartet.

Kurzantwort

Für einen sicheren Aufbau werden zuerst die äusseren WAN-Endpunkte, die inneren Tunnel-IPs und die entfernten Netze dokumentiert. Danach folgen:

1. Underlay-Erreichbarkeit der beiden WAN-Endpunkte und IP-Protokoll 47 prüfen.
2. Auf beiden Firewalls den GRE-Tunnel spiegelbildlich mit system gre tunnel add anlegen.
3. Mit system gre tunnel show Namen, Endpunkte, Tunnel-IPs und Status prüfen.
4. Die entfernten Netze mit system gre route add dem Tunnel zuordnen.
5. Enge, geloggte Firewall-Regeln zwischen LAN und VPN erstellen.
6. GRE auf dem WAN-Pfad, die innere Route, Rule ID, Nutztraffic und Rückweg getrennt testen.

⚠️ GRE bietet selbst keine Verschlüsselung oder Authentisierung. Über ein nicht vertrauenswürdiges Netz wird GRE nur verwendet, wenn unverschlüsselter Transport im Sicherheitsdesign ausdrücklich akzeptiert ist. Wird Vertraulichkeit oder Peer-Authentisierung benötigt, passt in der Regel ein Site-to-Site IPsec VPN besser.

GRE-Endpunkte, Tunnel-IPs und Routen unterscheiden

Ein GRE-Aufbau besteht aus mehreren Ebenen:

• Local gateway: das lokale WAN-Interface der Sophos Firewall, beispielsweise Port2.
• Remote gateway: die äussere IPv4-Adresse der Gegenstelle.
• Local IP und Remote IP: die inneren Punkt-zu-Punkt-Adressen des GRE-Tunnels.
• GRE-Route: ordnet ein entferntes Host- oder Zielnetz dem Tunnel zu.
• Firewall-Regel: erlaubt den konkreten Datenstrom zwischen den Zonen und Netzen.
• Rückweg: bringt die Antwortpakete über den spiegelbildlichen Tunnel zurück.

GRE über IPv4 verwendet IP-Protokoll 47. Das ist weder TCP noch UDP und darf nicht mit Port 47 verwechselt werden. Ein vorgeschalteter Router, Providerfilter oder eine Cloud-Security-List muss deshalb das IP-Protokoll zwischen den beiden äusseren Endpunkten transportieren können.

Ein sichtbarer Tunnelstatus Enabled bestätigt die gespeicherte und aktivierte GRE-Konfiguration. Er beweist noch nicht, dass die Gegenstelle antwortet, die Route stimmt oder eine Anwendung funktioniert.

Wann GRE passt und wann IPsec sinnvoller ist

GRE ist schlank und transportiert gerouteten Traffic zwischen zwei definierten Endpunkten. Es passt, wenn ein Provider oder eine Plattform GRE verlangt, wenn nur Kapselung benötigt wird oder wenn ein vertrauenswürdiger Underlay-Pfad bereits separat geschützt ist.

GRE ist dagegen kein Ersatz für eine verschlüsselte Standortvernetzung. Für normale Verbindungen über das öffentliche Internet ist route-based IPsec meist der passendere Ausgangspunkt. Eine Kombination aus GRE und IPsec benötigt ein eigenes, auf beiden Geräten getestetes Design; dieser Basisablauf legt keinen ungeprüften GRE-over-IPsec-Pfad an.

Dieser Artikel behandelt einen statischen IPv4-Punkt-zu-Punkt-Tunnel. Multicast, PIM-SM, BGP über GRE und providerspezifische Anycast-Tunnel sind mögliche Erweiterungen, werden aber erst nach einem funktionierenden Unicast-Basisweg geplant.

Beispieltopologie planen

Das Beispiel verbindet zwei Sophos Firewalls:

• Standort A WAN: Port2 mit 192.0.2.10
• Standort A LAN: 10.10.10.0/24
• Standort A Tunnel-IP: 10.255.255.1
• Standort B WAN: Port2 mit 198.51.100.20
• Standort B LAN: 10.20.20.0/24
• Standort B Testserver: 10.20.20.10
• Standort B Tunnel-IP: 10.255.255.2
• Tunnelnetz: 10.255.255.0/30
• Testdienst: HTTPS beziehungsweise TCP 443

192.0.2.0/24 und 198.51.100.0/24 sind Dokumentationsnetze und werden nicht produktiv verwendet. Beide WAN-Adressen, Interfaces, Tunnel-IPs, LAN-Netze und der Testserver werden gemeinsam durch die realen Werte ersetzt. Die Tunnel-IPs müssen ein eigenes, auf beiden Seiten identisch geplantes Punkt-zu-Punkt-Netz bilden und dürfen nicht mit bestehenden Netzen überlappen.

Das Beispiel verwendet die Tunnel-Namen gre_branch auf Standort A und gre_hq auf Standort B. Die Namen sind frei wählbar, dürfen laut aktueller SFOS-22-API aber höchstens 15 Zeichen lang sein.

Vor der Änderung gehören ein Konfigurationsbackup, ein Wartungsfenster und ein unabhängiger Managementzugang zum Rückweg. Zusätzlich werden bestehende statische und SD-WAN Routes, NAT-Regeln, Firewall-Regeln und überlappende Netze erfasst.

Voraussetzungen am äusseren Pfad prüfen

Beide WAN-Endpunkte müssen einander über das Underlay erreichen. Der Basisaufbau verwendet auf beiden Seiten statische IPv4-Adressen. Wenn die lokale WAN-Adresse per PPPoE oder DHCP bezogen wird, wird nicht mit diesem Rezept weitergearbeitet: Ältere offizielle Sophos-GRE-Anleitungen schliessen dynamische lokale WAN-Interfaces aus, während die aktuelle SFOS-22-API nur DDNS für das Remote Gateway dokumentiert. Die Unterstützung muss deshalb für den konkreten Build und Anschluss geklärt werden.

Vor der Tunnelkonfiguration werden diese Punkte geprüft:

• Die Remote-WAN-Adresse wird über das erwartete WAN-Gateway geroutet.
• Vorgeschaltete Router, Provider und Cloud-ACLs erlauben IP-Protokoll 47 zwischen den beiden Endpunkten.
• Es besteht kein CGNAT- oder NAT-Aufbau, dessen GRE-Verhalten ungeklärt ist.
• Die inneren Tunnel-IPs und LAN-Netze überlappen weder lokal noch entfernt.
• Die Gegenstelle verwendet dieselben äusseren und inneren Werte spiegelbildlich.
• Ein Rückweg zu beiden LAN-Netzen ist geplant.

Ein Ping auf die öffentliche Gegenstelle kann den Underlay-Pfad stützen, beweist aber keine GRE-Unterstützung. Ebenso hilft eine Freigabe für TCP oder UDP Port 47 nicht, weil GRE kein portbasiertes Transportprotokoll ist.

GRE-Tunnel auf beiden Firewalls anlegen

Die Konfiguration erfolgt über die CLI im Menü 4. Device Console. Die aktuelle Sophos-Hilfeseite enthält fehlerhaft gerenderte Syntaxfragmente. Deshalb wird vor der Änderung auf dem eingesetzten Build mit Tab beziehungsweise ? kontrolliert, ob die folgenden Parameter angeboten werden.

Standort A konfigurieren

Auf Firewall A wird der lokale WAN-Port Port2, die äussere Gegenstelle 198.51.100.20 und das innere Tunnelpaar eingetragen:

system gre tunnel add name gre_branch local-gw Port2 remote-gw 198.51.100.20 local-ip 10.255.255.1 remote-ip 10.255.255.2

Danach wird nur gelesen:

system gre tunnel show

Der Eintrag muss gre_branch, Port2, die Remote-WAN-Adresse und beide Tunnel-IPs korrekt zeigen. Ein Tippfehler wird nicht durch eine zweite ähnlich benannte Konfiguration kaschiert.

Standort B spiegelbildlich konfigurieren

Auf Firewall B werden lokale und entfernte Werte vertauscht:

system gre tunnel add name gre_hq local-gw Port2 remote-gw 192.0.2.10 local-ip 10.255.255.2 remote-ip 10.255.255.1

Auch hier folgt die Lesekontrolle:

system gre tunnel show

Enabled ist zu diesem Zeitpunkt nur ein Zwischencheck. Die Abnahme endet erst mit einem echten LAN-zu-LAN-Datenfluss.

Entfernte Netze über GRE routen

Für den einfachen festen Pfad wird auf jeder Firewall eine GRE-Route angelegt. Standort A sendet das LAN von Standort B über gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

Standort B erhält den spiegelbildlichen Rückweg:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Danach werden die konfigurierten Zuordnungen auf beiden Geräten gelesen:

system gre route show

Die Route darf nicht mit einem gleich langen oder spezifischeren statischen, SD-WAN-, VPN- oder direkt verbundenen Pfad konkurrieren. Die globale Route Precedence wird nicht auf Verdacht geändert. Zuerst werden die tatsächlich gematchte Route und der Paketpfad belegt.

Custom Gateway und SD-WAN als Alternative

Einige Providerdesigns verwenden statt der einfachen GRE-Route ein Custom Gateway auf dem GRE-Pfad und wählen es in einer SD-WAN Route aus. Das passt, wenn Source, Service, Failover oder ein definierter Gateway-Status in die Routingentscheidung einfliessen sollen.

Dabei ist die Remote-Tunnel-IP der Next Hop. Health Check, Zone und Probe Target müssen zum konkreten Providerdesign passen; die in einer Herstelleranleitung deaktivierte Überwachung ist kein universeller Standard. Wie Objekt, Probe und Echttest zusammengehören, erklärt Sophos Firewall Custom Gateway erstellen und prüfen. Die Auswahl des Pfads steht unter Sophos Firewall SD-WAN Route einrichten.

GRE-Route und SD-WAN Route werden nicht unkontrolliert für dieselben Netze parallel aktiviert. Vor dem Wechsel wird dokumentiert, welcher Mechanismus gewinnen soll und wie man zum vorherigen Pfad zurückkehrt.

Firewall-Regeln ohne unnötiges NAT erstellen

Der GRE-Tunnel und seine Route erlauben noch keinen Nutztraffic. Für eine von Standort A gestartete HTTPS-Verbindung braucht es auf beiden Firewalls eine enge, geloggte Regel.

Auf Firewall A gilt:

• Source zone: LAN
• Source network: 10.10.10.0/24
• Destination zone: VPN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: aktiviert

Auf Firewall B wird der eintreffende Tunneltraffic zum Testserver erlaubt:

• Source zone: VPN
• Source network: 10.10.10.0/24
• Destination zone: LAN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: aktiviert

Diese beiden Regeln decken die von Standort A gestartete Verbindung und deren stateful Rücktraffic ab. Wenn Hosts an Standort B selbst neue Verbindungen nach Standort A starten dürfen, wird zusätzlich das spiegelbildliche Regelpaar LAN nach VPN auf Firewall B und VPN nach LAN auf Firewall A mit den tatsächlich benötigten Netzen und Diensten erstellt. Eine breite Any-Regel ist für die Abnahme nicht nötig.

Für eine normale Standortkopplung bleibt die originale Source-IP erhalten. MASQ wird nicht als vermeintlicher Routingfix eingeschaltet. Fehlt der Rückweg, wird die Route auf der Gegenstelle korrigiert. Den allgemeinen Regelaufbau erklärt Sophos Firewall-Regeln erstellen und sicher prüfen.

Tunnel und Nutztraffic gemeinsam abnehmen

Die Prüfung folgt dem Paketpfad und trennt Konfiguration von tatsächlicher Funktion:

1. Auf beiden Firewalls system gre tunnel show ausführen und Endpunkte sowie Tunnel-IPs vergleichen.

2. Mit system gre route show das jeweilige entfernte LAN und den richtigen Tunnel-Namen kontrollieren.

3. Vom Client in 10.10.10.0/24 eine neue HTTPS-Verbindung zu 10.20.20.10 starten.

4. Im Log viewer auf beiden Firewalls Source, Destination, Service, Firewall Rule ID, NAT Rule ID und Zone prüfen.

5. Unter Diagnostics > Packet capture auf Standort A den äusseren GRE-Pfad filtern:

   host 198.51.100.20 and ip proto 47
   

6. Den inneren Testfluss separat filtern:

   host 10.20.20.10 and tcp port 443
   

7. Eingang und Ausgang auf beiden Firewalls vergleichen und am Zielserver die echte Source-IP prüfen.

8. Einen Rücktest nur mit einem dafür erlaubten Dienst starten.

Der äussere Capture zeigt die Kapselung zwischen den WAN-Endpunkten. Der innere Capture und die Rule ID zeigen, ob das Nutzpaket durch die erwartete Regel und Route läuft. Erst die erfolgreiche Anwendung bestätigt den gesamten Pfad. Der kombinierte Ablauf steht ausführlicher unter Firewall-Regeln testen und Packet Capture verwenden.

Fehler nach Symptom eingrenzen

Kein GRE-Paket verlässt das WAN-Interface

• Remote Gateway und lokales local-gw im Tunnel kontrollieren.
• Underlay-Route zur Remote-WAN-Adresse und den gewählten WAN-Gateway prüfen.
• Sicherstellen, dass der Testfluss wirklich die GRE-Route oder die vorgesehene SD-WAN Route matcht.
• Mit system gre tunnel show und system gre route show Namen und Zuordnung vergleichen.
• Keine TCP-/UDP-Portfreigabe als Ersatz für IP-Protokoll 47 erstellen.

GRE verlässt Standort A, erreicht Standort B aber nicht

• Provider, vorgeschaltete Router, Cloud-ACLs und mögliche NAT-Strecken auf IP-Protokoll 47 prüfen.
• Auf Standort B mit dem äusseren WAN-Filter gleichzeitig mitschneiden.
• Äussere Quell- und Zieladresse mit der Gegenstellenkonfiguration vergleichen.
• Bei dynamischem WAN, CGNAT oder ungeklärtem NAT stoppen und den Aufbau nicht durch breite Regeln kaschieren.

GRE ist auf beiden WAN-Seiten sichtbar, aber der innere Traffic fehlt

• Local IP und Remote IP müssen auf beiden Firewalls spiegelbildlich sein.
• GRE-Route, Zielnetz und Tunnel-Name Zeichen für Zeichen vergleichen.
• Firewall-Regel und erwartete Rule ID auf beiden Seiten prüfen.
• Überlappende Netze, NAT und einen fehlenden Rückweg ausschliessen.
• Enabled nicht als Beweis für die innere Route oder Anwendung werten.

Nur eine Richtung funktioniert

• Die GRE-Route für das Rücknetz auf Standort B prüfen.
• Kontrollieren, ob Standort B neue Verbindungen initiieren soll und dafür eine eigene Firewall-Regel benötigt.
• Am Zielserver Default Gateway, lokale Host-Firewall und reale Source-IP prüfen.
• Asymmetrische SD-WAN- oder statische Routen auf beiden Seiten vergleichen.

Kleine Pakete funktionieren, grosse Verbindungen stocken

GRE fügt einen äusseren IP- und GRE-Header hinzu. Dadurch sinkt die nutzbare Paketgrösse gegenüber dem Underlay. Eine feste MTU- oder MSS-Zahl wird nicht ungeprüft übernommen: Zuerst werden Underlay-MTU, Path MTU Discovery, Fragmentierung und die betroffene Anwendung gemessen. Den kontrollierten Ablauf erklärt MTU und MSS bei VPN-Problemen prüfen.

HA und Betrieb vorsichtig testen

Die aktuelle öffentliche Sophos-Dokumentation macht für GRE keine Zusage zu unterbrechungsfreiem HA-Failover oder synchronisiertem Tunnel-State. Ein kontrollierter Rollenwechsel erfolgt deshalb nur im Wartungsfenster mit unabhängigem Managementzugang.

Nach dem Wechsel werden system gre tunnel show, system gre route show, äusserer GRE-Capture, neue Clientverbindung, Rule ID und Rückweg erneut geprüft. Eine bestehende TCP-Verbindung gilt nicht als Kontinuitätsnachweis.

Im Betrieb werden Owner, beide WAN-Endpunkte, Tunnel-IPs, Tunnel-Namen, entfernte Netze, Routingmechanismus, Firewall-Regeln, erwartete MTU-Grenze und letzter Echttest dokumentiert. Nach Änderungen an WAN, Provider, NAT, SD-WAN, Route Precedence oder Gegenstelle wird der komplette Pfad erneut abgenommen.

Sicher zurückrollen

Der Rückbau erfolgt auf beiden Firewalls koordiniert:

1. Testtraffic beenden und den letzten Zustand mit system gre tunnel show sowie system gre route show sichern.

2. Neue Firewall-Regeln und eine gegebenenfalls erstellte SD-WAN Route deaktivieren.

3. Falls verwendet, das Custom Gateway erst nach Prüfung von Object usage aus dem Pfad nehmen.

4. Auf Standort A die konkrete GRE-Route entfernen:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. Auf Standort B die Rückroute entfernen:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Mit system gre route show prüfen, dass nur die beabsichtigten Einträge verschwunden sind.

7. Danach den Tunnel auf Standort A gezielt nach Namen löschen:

   system gre tunnel del name gre_branch
   

8. Auf Standort B nur den dortigen Tunnel löschen:

   system gre tunnel del name gre_hq
   

9. Mit system gre tunnel show und einem Test des vorherigen Routingpfads abschliessen.

del All wird nicht verwendet. Sind Syntax oder Objektname auf dem eingesetzten Build unklar, wird vor dem Löschen mit Tab beziehungsweise ? geprüft und nicht geraten.

Häufige Fragen