Sophos Firewall IP-Tunnel mit 6in4, 6to4, 6rd oder 4in6 einrichten

Unter Network > IP tunnels erstellt Sophos Firewall Tunnel, die ein Netzwerkprotokoll in ein anderes kapseln. Damit kann IPv6 über ein IPv4-Underlay oder IPv4 über ein IPv6-Underlay transportiert werden. SFOS stellt dafür 6in4, 6to4, 6rd und 4in6 bereit.

Diese Funktion ist nicht der GRE-Tunnel aus der Device Console und auch kein IPsec VPN. Ein IP-Tunnel kapselt Pakete, verschlüsselt oder authentisiert sie aber nicht automatisch.

⚠️ Über ein nicht vertrauenswürdiges Underlay wird ein IP-Tunnel nur eingesetzt, wenn die fehlende Vertraulichkeit und Peer-Authentisierung im Sicherheitsdesign ausdrücklich akzeptiert ist. Für geschützte Standortverbindungen ist in der Regel Site-to-Site IPsec der passendere Ausgangspunkt.

Welcher Tunneltyp passt?

Die vier Typen lösen nicht dieselbe Aufgabe:

• 6in4 verbindet zwei IPv6-Netze über ein IPv4-Backbone. Lokaler und entfernter IPv4-Endpoint werden manuell gesetzt. Sophos empfiehlt diesen Typ für Punkt-zu-Punkt-Verbindungen.
• 6to4 transportiert IPv6 über IPv4 und ist für Punkt-zu-Multipunkt gedacht. Die lokale IPv4-Source wird manuell gesetzt; die Zieladresse kann automatisch ermittelt werden.
• 6rd erweitert 6to4 für ein vom Provider vorgegebenes Präfix. Dieser Typ passt nur, wenn der ISP die erforderlichen 6rd-Werte bereitstellt.
• 4in6 verbindet zwei IPv4-Netze über ein IPv6-Backbone. Die äusseren lokalen und entfernten Tunnelendpunkte sind IPv6-Adressen; der Typ ist für Punkt-zu-Punkt-Verbindungen gedacht.

Für einen einzelnen, kontrollierten Link mit festen Endpunkten ist 6in4 beziehungsweise 4in6 leichter nachvollziehbar. 6to4 oder 6rd werden nicht nur gewählt, weil SFOS automatisch eine Route erzeugen kann. Das Adress- und Providerdesign muss zu genau diesem Mechanismus passen.

Die IPv6-Funktionsgrenzen von SFOS fasst IPv6-Support auf Sophos Firewall zusammen. Ein GRE-Tunnel transportiert dagegen gerouteten IP-Traffic über einen eigenen Device-Console-Ablauf und ist nicht mit diesen vier WebAdmin-Typen austauschbar.

Beispiel und Voraussetzungen planen

Das Beispiel verwendet einen statischen 6in4-Tunnel zwischen zwei Standorten:

• Anzeigename: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• lokale IPv4-WAN-Adresse: 192.0.2.10
• entfernter IPv4-Endpoint: 198.51.100.20
• lokales IPv6-Netz: 2001:db8:100::/64
• entferntes IPv6-Netz: 2001:db8:200::/64
• Testserver: 2001:db8:200::20
• Zone des Tunnelinterfaces: im Beispiel VPN

192.0.2.0/24, 198.51.100.0/24 und 2001:db8::/32 sind Dokumentationsbereiche. Sie werden zusammen mit Namen, Zone und Netzpräfixen durch die realen Werte ersetzt. Die Zone VPN ist eine nachvollziehbare Beispielwahl, keine Produktpflicht. Entscheidend ist, dass Zonenmodell, Firewall-Regeln und Device Access zur eigenen Architektur passen.

Vor dem Anlegen müssen beide äusseren Endpunkte über das Underlay erreichbar sein. Auf beiden Seiten braucht es einen spiegelbildlichen Tunnel, eindeutige innere Netze, einen Rückweg und eine Firewallregel für den tatsächlichen Nutztraffic. Überlappende Präfixe, ein fehlender Providerwert für 6rd oder eine unbekannte Gegenstellenkonfiguration sind Stop-Bedingungen.

Ein Backup, ein Wartungsfenster und ein unabhängiger Managementzugang gehören ebenfalls zum Rückweg. Die Tunnelkonfiguration wird nicht als Versuchslösung auf einer einzigen produktiven Verbindung angelegt.

IP-Tunnel im WebAdmin anlegen

Unter Network > IP tunnels > Add werden zuerst Identität und Tunneltyp festgelegt, danach die Endpunkte und erweiterten IP-Werte.

Name und Hardware name unterscheiden

Der normale Name darf höchstens 58 Zeichen haben und kann später geändert werden. Er sollte Zweck und Gegenstelle erkennen lassen, im Beispiel HQ-IPv6-via-IPv4.

Der Hardware name ist technischer und kann nach dem Speichern nicht mehr geändert werden. Er darf höchstens zehn Zeichen enthalten und nur A-Z, a-z, 0-9 sowie _ verwenden. SFOS sperrt ausserdem zahlreiche Systemnamen und -bestandteile, darunter beispielsweise gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN und Halink. Der neutrale Beispielwert v6hq01 vermeidet diese Konflikte.

Wenn der Hardware name falsch gewählt wurde, wird er nicht später umbenannt. Dann müssen Abhängigkeiten dokumentiert und der Tunnel kontrolliert neu erstellt werden. Deshalb wird dieser Wert vor Save besonders sorgfältig geprüft.

Tunneltyp, Zone und Endpunkte setzen

Für das Beispiel wird 6in4 gewählt. Unter Zone wird die vorgesehene Sicherheitszone gesetzt. Local endpoint erhält 192.0.2.10, Remote endpoint 198.51.100.20.

Die Adressfamilie hängt vom Typ ab. Bei 6in4, 6to4 und 6rd ist der lokale äussere Endpoint IPv4; 6in4 besitzt zusätzlich einen festen entfernten IPv4-Endpoint. Bei 4in6 sind lokale und entfernte äussere Endpoints IPv6-Adressen. Eine innere Zielroute wird nicht in ein Endpoint-Feld geschrieben.

Unter den erweiterten Einstellungen beeinflusst TTL die Lebensdauer der gekapselten Pakete über das Underlay. TOS ordnet dem äusseren IP-Paket einen Type-of-Service-Wert für Priorisierung und Routingverhalten zu. Die aktuelle Hilfe nennt keine universellen Bestwerte. Beide Felder bleiben deshalb beim dokumentierten Ausgangswert, solange kein gemessenes Routing- oder QoS-Problem eine Änderung begründet.

Nach Save bestätigt SFOS die Erstellung und öffnet den Routendialog. Bei 6to4 und 6rd erzeugt die Firewall zusätzlich automatisch eine statische IPv6-Unicast-Route. Wichtig: Auch wenn dieses Fenster mit Cancel geschlossen wird, bleiben der Tunnel und bereits automatisch erzeugte Routen gespeichert.

Routen und Firewall-Regeln ergänzen

Ein gespeicherter Tunnel ist noch kein funktionierender Datenpfad. Für 6in4 wird eine statische IPv6-Route zum entfernten Präfix 2001:db8:200::/64 über das neue Tunnelinterface angelegt. Die Gegenstelle benötigt den spiegelbildlichen Rückweg zu 2001:db8:100::/64.

Bei 4in6 führt die innere Route zu einem IPv4-Zielnetz. Bei 6to4 und 6rd wird die automatisch erzeugte IPv6-Route zuerst gelesen und gegen das Providerdesign geprüft, bevor weitere Routen ergänzt werden. Cancel im ersten Routendialog gilt nicht als Rollback.

Weitere Routen werden unter Routing > Static routes angelegt. Wie Zielpräfix, Interface, Distance, Routingentscheidung und Echttest zusammengehören, erklärt Statische Routen auf Sophos Firewall.

Zwischen den beteiligten Zonen wird anschliessend eine enge, geloggte Firewallregel für echte Source-, Destination- und Servicewerte erstellt. Für eine normale Standortverbindung bleibt die originale Source-Adresse erhalten; MASQ wird nicht als Ersatz für einen fehlenden Rückweg aktiviert. Der Regelaufbau steht unter Sophos Firewall-Regeln sicher konfigurieren.

Tunnel und Nutztraffic abnehmen

Die Abnahme trennt gespeicherte Konfiguration, äussere Kapselung und innere Anwendung:

1. Unter Network > IP tunnels Name, Hardware name, Typ, Zone und Endpoints mit der Gegenstelle vergleichen.
2. Unter Routing > Static routes prüfen, ob das entfernte innere Präfix auf das erwartete Tunnelinterface zeigt.
3. Eine Route Lookup für den inneren Testserver ausführen und das erwartete Interface bestätigen.
4. Vom lokalen Testclient eine neue Verbindung zu 2001:db8:200::20 mit einem ausdrücklich erlaubten Dienst starten.
5. Im Log Viewer auf Source, Destination, Service, Action und Firewall Rule ID achten.
6. Mit Packet Capture zuerst die äusseren Endpoints, danach die innere Testadresse beobachten.
7. Auf der Gegenstelle Eingang, Entkapselung, Rückroute und tatsächliche Source-Adresse prüfen.
8. Den Test in Gegenrichtung nur mit einer dafür vorgesehenen Regel wiederholen.

Ein grüner oder vorhandener Tunneleintrag beweist weder die Route noch die Gegenstelle. Ebenso bestätigt eine automatisch erzeugte Route nicht, dass Provider, Upstream-Geräte und Firewall-Regeln die Kapselung tatsächlich transportieren. Packet Capture auf Sophos Firewall erklärt den kontrollierten Mitschnitt.

Fehler nach Symptom eingrenzen

Der Tunnel lässt sich nicht speichern

Zuerst werden Name und Hardware name getrennt geprüft. Der Hardware name darf maximal zehn Zeichen lang sein, nur die erlaubten Zeichen enthalten und keinen gesperrten Systembegriff treffen. Danach müssen Tunneltyp und Adressfamilie der lokalen sowie entfernten Endpoints zusammenpassen.

Ein anderer Anzeigename behebt keinen ungültigen Hardware name. Wenn das Feld bereits durch ein anderes Interface belegt ist, wird ein eindeutiger technischer Name geplant und nicht mit zufälligen Suffixen mehrfach ausprobiert.

Tunnel vorhanden, aber keine Route zum Zielnetz

Bei 6in4 und 4in6 wird die benötigte statische Route ausdrücklich angelegt. Bei 6to4 und 6rd wird geprüft, ob SFOS die erwartete IPv6-Unicast-Route erzeugt hat und ob deren Präfix zum Design passt. Ein zuvor mit Cancel geschlossenes Fenster löscht die automatisch gespeicherte Konfiguration nicht.

Route Lookup und Routingtabelle sind der nächste Beweis. Die globale Route Precedence wird nicht auf Verdacht verändert und es wird keine konkurrierende Blackhole- oder Dummy-Route als Testhilfe angelegt.

Äussere Pakete sichtbar, innerer Traffic fehlt

Dann stimmen häufig Gegenstellentyp, Endpoint-Adressen, inneres Präfix oder Rückroute nicht. Auf beiden Seiten werden die Konfigurationen spiegelbildlich verglichen. Danach folgen Firewallregel, erwartete Firewall Rule ID und ein Capture der inneren Source- und Destination-Adresse.

Eine funktionierende Kapselung ist kein Beweis für erlaubten Nutztraffic. Umgekehrt kann eine fehlende Rule ID bedeuten, dass das innere Paket gar nicht entkapselt oder über eine andere Route verarbeitet wurde.

Kleine Pakete funktionieren, Anwendungen stocken

Die zusätzliche äussere IP-Kapselung reduziert die nutzbare Paketgrösse gegenüber dem Underlay. Statt einen fremden MTU-Wert zu übernehmen, werden Path MTU, Fragmentierung und die betroffene Anwendung gemessen. Der kontrollierte Ablauf unter MTU und MSS bei Tunnelproblemen lässt sich auch für diese Paketgrössenanalyse verwenden; feste IPsec-Werte werden dabei nicht auf den IP-Tunnel übertragen.

HA, Änderungen und Rollback

Die beiden SFOS-22-Hilfeseiten versprechen für diese IP-Tunnel keinen unterbrechungsfreien HA-State. Nach einem geplanten Rollenwechsel werden deshalb Tunneleintrag, Route Lookup, äussere Kapselung, Firewall Rule ID und eine neue Anwendungssitzung erneut geprüft. Eine bestehende Verbindung gilt nicht als Kontinuitätsnachweis.

Vor einer Änderung werden Name, unveränderlicher Hardware name, Typ, Zone, Endpoints, automatisch und manuell angelegte Routen, Regeln sowie letzter Echttest dokumentiert. Danach lassen sich Konfigurations- und Datenpfadänderung voneinander unterscheiden.

Für den Rollback wird zuerst der Testtraffic beendet. Abhängige Firewallregeln und manuelle Routen werden kontrolliert deaktiviert oder auf den bestätigten Ausgangsstand gesetzt. Automatisch erzeugte Routen von 6to4 oder 6rd werden ausdrücklich mitgeprüft. Erst wenn keine produktive Abhängigkeit mehr besteht, wird der Tunnel gelöscht. Anschliessend müssen der frühere Routingpfad und ein bekannter Datenfluss wieder funktionieren.

Checkliste

• Der gewählte Typ passt zu innerer und äusserer Adressfamilie.
• Beide Endpoints und Präfixe sind mit der Gegenstelle abgestimmt.
• Anzeigename und unveränderlicher Hardware name sind dokumentiert.
• Zone, statische Route und Rückweg passen zum Sicherheitsdesign.
• Automatisch erzeugte Routen bei 6to4 oder 6rd wurden geprüft.
• Eine enge Firewallregel trifft mit der erwarteten Firewall Rule ID.
• Äussere Kapselung und innerer Nutztraffic wurden getrennt getestet.
• MTU, HA und Rollback sind für den realen Pfad abgenommen.

Häufige Fragen