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.

Kurzablauf: Inneres Zielnetz und äussere Endpunkte getrennt planen, den passenden Typ unter Network > IP tunnels > Add speichern, Route und Rückroute sowie eine enge Regel für den inneren Traffic ergänzen. Anschliessend eine neue Anwendungssitzung testen und äussere Kapselung, Entkapselung und Rule ID getrennt prüfen. Save bestätigt die Konfiguration, nicht einen erfolgreich getesteten Datenpfad.

⚠️ Ü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.

Die SFOS-23-Hilfe erklärt den automatischen Mechanismus genauer: 6to4 leitet das IPv6-Präfix aus der lokalen öffentlichen IPv4-Adresse ab. Ein entfernter Endpoint wird nicht konfiguriert; das Zielgateway wird anhand der IPv6-Zieladresse automatisch bestimmt. 6rd verwendet dagegen vom ISP vorgegebene IPv6-Präfixe und Relay-Gateways. Die Firewall bestimmt das vom ISP bereitgestellte Relay-Gateway automatisch. Dafür muss der ISP einen passenden 6rd-Dienst anbieten; wenn natives IPv6 verfügbar ist, wird dieses bevorzugt. Diese Mechanismen ändern nichts an der folgenden Legacy-Warnung.

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.

Bei 6to4 ist zusätzlich zwischen dem weiterhin definierten Unicast-Verfahren und dem öffentlichen Anycast-Relay-Verfahren zu unterscheiden. Die IETF hat Anycast-6to4 wegen der Betriebsprobleme verworfen und empfiehlt, 6to4 in Routern standardmässig deaktiviert zu lassen (RFC 7526). Deshalb wird 6to4 nicht für eine neue Internetanbindung eingeschaltet. Es kommt höchstens für ein bereits vorhandenes, ausdrücklich abgestimmtes Unicast-Design infrage; native IPv6-Konnektivität, providerverwaltetes 6rd oder ein fester 6in4-Peer sind die besser kontrollierbaren Alternativen.

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 und Firewall-Regeln zur eigenen Architektur passen. Device access steuert Zugriffe auf Dienste der Firewall selbst und ersetzt keine Regel für weitergeleiteten Nutztraffic.

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.

Das Underlay muss statt eines TCP- oder UDP-Ports das gekapselte IP-Protokoll transportieren: 6in4, 6to4 und 6rd verwenden IPv6-in-IPv4 mit IPv4-Protokollnummer 41 (RFC 4213); 4in6 folgt dem IPv6-Tunnelmodell aus RFC 2473 und kennzeichnet das innere IPv4-Paket im äusseren IPv6-Header mit dem von IANA registrierten Next-Header-Wert 4. Provider, vorgeschaltete Firewall und ein mögliches NAT-Gerät werden deshalb vorab auf genau diesen Datenpfad geprüft. Eine Portfreigabe ist kein Ersatz für diese Prüfung.

Ein Backup, ein Wartungsfenster und ein unabhängiger Managementzugang gehören ebenfalls zum Wiederherstellungsplan. 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.

In anderen Einstellungen erscheint dieser anpassbare Interfacename, nicht der unveränderliche Hardware name.

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.

Die vollständige dokumentierte Sperrliste für Hardware name in SFOS 22 und 23 lautet: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. Der Name darf keinen dieser Bestandteile enthalten; es geht nicht nur um identische vollständige Namen. Die Schreibweisen bleiben wie dokumentiert; daraus wird keine Aussage zur Gross-/Kleinschreibungsprüfung abgeleitet.

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.

Diese Feldbezeichnung Remote endpoint folgt der SFOS-22-Hilfe. Die SFOS-23-Hilfe nennt das Feld Remote gateway: Bei 6in4 akzeptiert es eine IPv4-Adresse oder einen FQDN, bei 4in6 eine IPv6-Adresse oder einen FQDN. Ein FQDN ist der vollständige DNS-Name der Gegenstelle, nicht das innere Zielpräfix. Für Local endpoint beschreibt SFOS 23 eine einem Interface zugeordnete Adresse (6in4/6to4), bei 6rd ausdrücklich eine zugeordnete IPv4-Adresse und bei 4in6 ein IPv6-Interface. Die lokale Adressfamilie bleibt wie unten beschrieben. Die unterschiedlichen Hilfetexte belegen keinen genauen Releasebeginn der Laufzeitunterstützung.

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 weder universelle Bestwerte noch auf der Hilfeseite einen Default. Deshalb werden die in der eigenen Maske angezeigten Ausgangswerte dokumentiert und nur geändert, wenn eine konkrete Underlay- oder QoS-Vorgabe dies verlangt.

Diese TTL-/TOS-Grundlagen folgen der SFOS-22-Hilfe. Die SFOS-23-Hilfe erklärt TTL als maximale Anzahl Router, die ein gekapseltes Paket durchlaufen darf, bevor es verworfen wird. Diese Begrenzung hilft, Routing-Schleifen zu verhindern. Auch hier wird kein numerischer TTL- oder ToS-Default angegeben.

Für 4in6 beschreibt SFOS 23 zusätzlich folgende erweiterte Einstellungen:

• Inherit ToS ist optional und übernimmt den ToS-Wert des inneren Pakets.
• MTU ist die grösste Paketgrösse in Bytes, die ohne Fragmentierung durch den Tunnel übertragen werden kann. Der dokumentierte Default ist die MTU des physischen Interfaces minus 48 Bytes; die Reduktion berücksichtigt den 4in6-Kapselungsaufwand.
• Override MSS ist optional und erlaubt die manuelle Angabe der MSS. MSS bezeichnet die grösste TCP-Nutzlast in Bytes innerhalb eines einzelnen TCP-Pakets ohne Fragmentierung. Eine Anpassung dient dazu, Fragmentierung zu vermeiden oder Path-MTU-Grenzen zu berücksichtigen. Der dokumentierte Default ist der MTU-Wert minus 40 Bytes.

Diese beiden Formeln sind dokumentierte Vorgaben, keine aus Protokoll-Overhead selbst berechneten Werte und kein Labortest. Für die optionalen Checkboxen wird kein voreingestellter Aktivierungszustand behauptet. Die konkrete Anpassung bleibt an den tatsächlichen Pfad gebunden.

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.

SFOS-23-API: Schema und Validierung

Dieser Abschnitt behandelt Add IP Tunnel / Edit IP Tunnel; die Objektangaben sind noch kein vollständiger Request und kein WebAdmin-Ablauf. Gegenüber der SFOS-22-Dokumentation enthält die SFOS-23-Parametertabelle zusätzlich vier optionale Felder vom Typ SCALAR:

• MSS: INTEGER, erlaubter Bereich 536–8912, höchstens vier Ziffern.
• MTU: INTEGER, erlaubter Bereich 576–8952, höchstens vier Ziffern.
• LocalInterface: STRING für das lokale Tunnelinterface; die Zelle Default ist leer. Daraus folgt kein bestätigter Laufzeitdefault.
• InheritToS: erlaubte Werte Disable und Enable.

Die Tabelle belegt weder die Anwendbarkeit jedes Feldes auf jeden Tunneltyp noch den Vorrang von LocalInterface gegenüber LocalEndPoint, erforderliche Feldkombinationen oder den Releasebeginn der Laufzeitunterstützung. Die WebAdmin-Angaben zu Endpunkten und FQDN werden nicht als API-Kompatibilitätszusage übernommen.

API-Status 541 bei Add und Edit

Für beide Operationen dokumentiert SFOS 23 den Status 541 mit der Meldung MTU and MSS must not exceed the local interface values. MTU und MSS dürfen demnach die entsprechenden Werte des lokalen Interfaces nicht überschreiten. Vor einer Änderung werden die übermittelten MTU-/MSS-Werte, das zugehörige lokale Interface und dessen protokollierte Konfiguration verglichen. Diese API-Validierung ist keine Messung der Path MTU im Datenpfad und bestätigt keine allgemeine Rechenbeziehung zwischen MTU und MSS.

Widersprüchliche Defaults bleiben ungeklärt

Die API-Tabelle enthält bei MSS wörtlich Default: Enable, obwohl das Feld als INTEGER mit Zahlenbereich beschrieben ist. Bei InheritToS steht wörtlich Default: off, obwohl nur Disable und Enable aufgeführt sind. Diese widersprüchlichen Dokumentationswerte sind keine empfohlenen Payload-Werte und werden weder korrigiert noch in andere Tokens umgedeutet.

Zudem nennt die API für MTU den Default 1500 und beschreibt ToS-Vererbung vom lokalen Interface. Die WebAdmin-Hilfe für 4in6 nennt dagegen die MTU des physischen Interfaces minus 48 Bytes, MSS gleich MTU minus 40 Bytes und ToS-Vererbung vom inneren Paket. Die Zuordnung zwischen diesen Oberflächen bleibt ungeklärt; die korrekten WebAdmin-Formeln und optionalen Steuerelemente oben bleiben davon unberührt.

Ausgeschlossen bleibt eine handlungsleitende Automatisierungsanleitung, die diese Defaults, Vererbungsregeln oder Feldprioritäten voraussetzt. Hier wird deshalb kein ausführbarer API-Payload bereitgestellt. Dafür braucht es eine Klärung durch Sophos oder einen ausdrücklich autorisierten Test auf der passenden SFOS-Version; die dokumentierten Schema- und Statusangaben sind kein Produkttest.

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.

Für zusätzliche IPv6-Routen nach dem Speichern von 6to4 oder 6rd nennt SFOS 23 im Pop-up die Felder Destination IP (IPv6) und Gateway (IPv6). Ziel und Gateway gemäss Netzdesign eintragen und mit Save speichern; ohne weitere Route Cancel wählen. Diese IPv6-Felder gelten nicht für die innere IPv4-Route eines 4in6-Tunnels. Die SFOS-22-Warnung zur gespeicherten Konfiguration bei Cancel bleibt zu beachten.

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

Unter Rules and policies > Firewall rules wird für das 6in4-Beispiel zuerst IPv6 und dann Add firewall rule > New firewall rule gewählt. Die Regel erhält Action: Accept, die tatsächlichen Source zones, Source networks and devices, Destination zones, Destination networks und Services sowie aktiviertes Log firewall traffic. Sie wird so positioniert, dass keine breitere Regel vorher trifft. Antworten einer erlaubten zustandsbehafteten Verbindung brauchen keine zweite Regel. Nur wenn die Gegenstelle selbst neue Verbindungen starten darf, ist dafür eine eigene, ebenso enge Regel nötig.

Für eine normale Standortverbindung bleibt die ursprüngliche Source-Adresse erhalten. Create linked NAT rule bleibt aus; MASQ wird nicht als Ersatz für einen fehlenden Rückweg aktiviert. SFOS lässt erlaubten Traffic ohne passende NAT-Regel unübersetzt passieren. Falls das Design wirklich Adressübersetzung verlangt, wird sie separat mit Original- und übersetztem Datenfluss geplant und getestet. Der Regelaufbau steht unter Sophos Firewall-Regeln sicher konfigurieren.

4in6: IPv4-Nutztraffic über IPv6 transportieren

Bei 4in6 wechselt gegenüber dem 6in4-Beispiel nicht nur der Tunneltyp. Die äusseren Endpunkte sind IPv6, die gerouteten Netze und Firewall-Regeln dagegen IPv4. Ein separates Planungsbeispiel verwendet lokal 10.10.10.0/24, entfernt 10.20.20.0/24 und als Testserver 10.20.20.20. Die äussere lokale Interface-Adresse ist 2001:db8:10::10, die entfernte Gateway-Adresse 2001:db8:20::20. Die privaten IPv4-Netze und IPv6-Dokumentationsadressen werden durch eindeutige, nicht überlappende innere Netze und tatsächlich über das Underlay erreichbare IPv6-Endpunkte ersetzt.

1. Vorab den IPv6-Underlay-Pfad zu 2001:db8:20::20 prüfen. Die Route zum äusseren Peer muss über das Underlay führen, nicht über den Tunnel, den man erst mit diesem Peer aufbauen will. Ein erfolgreicher Ping allein beweist noch nicht den Transport der gekapselten IPv4-Pakete.
2. Unter Network > IP tunnels > Add 4in6 wählen, einen eindeutigen Namen und Hardware name setzen und die geplante Zone zuordnen. In SFOS 23 unter Local endpoint das IPv6-Interface mit der geplanten lokalen Adresse wählen und unter Remote gateway die entfernte IPv6-Adresse eintragen. Auf der Gegenstelle werden lokale und entfernte Endpunkte vertauscht. Die oben beschriebenen SFOS-23-Einstellungen für MTU, Override MSS und Inherit ToS bleiben zu beachten.
3. Nach Save unter Routing > Static routes eine IPv4-Route zu 10.20.20.0/24 über das neue Tunnelinterface anlegen. Die Gegenstelle erhält die Rückroute zu 10.10.10.0/24. Die IPv6-Felder des zusätzlichen 6to4-/6rd-Routendialogs sind hierfür nicht die Vorlage.
4. Unter Rules and policies > Firewall rules IPv4 wählen. Nur die benötigten Verbindungen vom lokalen IPv4-Netz zum entfernten IPv4-Netz erlauben, die tatsächlichen Zonen und Dienste setzen und Log firewall traffic aktivieren. Die IPv6-Underlay-Adressen gehören nicht als Ersatz für die inneren IPv4-Netze in diese Nutztraffic-Regel. Ohne beabsichtigte Adressübersetzung bleibt die Source-Adresse erhalten.
5. Mit Diagnostics > Tools > Route lookup 10.20.20.20 prüfen und anschliessend vom lokalen Testclient eine neue, erlaubte Verbindung zu diesem Server starten. Am Peer werden Entkapselung und Rückweg geprüft. Nach Beenden der Testsitzung müssen im Log Viewer die inneren IPv4-Adressen und die erwartete Firewall Rule ID erscheinen; während der Sitzung dient der Capture zur unmittelbaren Wegprüfung.
6. Für den äusseren Mitschnitt im unten beschriebenen Capture-Ablauf den BPF-Filter host 2001:db8:10::10 and host 2001:db8:20::20 verwenden. Für den getrennten inneren Mitschnitt den BPF-String wieder leeren und unter Display filter Ethernet type: IPv4 sowie Destination IP: 10.20.20.20 wählen. Jeweils nur einen Test mitschneiden und den Capture danach stoppen. Der Rollback erfolgt mit derselben Abhängigkeitsprüfung wie unten, hier jedoch für die eigens angelegten IPv4-Routen und -Regeln.

Tunnel und Nutztraffic abnehmen

Die Abnahme trennt gespeicherte Konfiguration, äussere Kapselung und inneren Nutztraffic:

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. Unter Diagnostics > Tools > Route lookup die innere Adresse 2001:db8:200::20 eingeben und das erwartete Tunnelinterface 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. Unter Diagnostics > Packet capture > Configure für die äussere Prüfung unter Enter BPF string den Filter host 192.0.2.10 and host 198.51.100.20 setzen und speichern. Capture starten, genau einen Test auslösen und wieder stoppen. Für einen getrennten inneren Mitschnitt den BPF-String unter Configure leeren und speichern; anschliessend unter Display filter Ethernet type: IPv6 und Destination IP: 2001:db8:200::20 setzen und speichern. Capture erneut nur für einen Test starten und danach stoppen.
7. Auf der Gegenstelle Eingang, Entkapselung, Rückroute und tatsächliche Source-Adresse prüfen.
8. Eine von der Gegenstelle neu gestartete Verbindung nur dann testen, wenn dafür eine eigene Regel vorgesehen ist; reinen Antworttraffic deckt die zustandsbehaftete Regel ab.

Der äussere Hostfilter erfasst auch anderen Traffic zwischen den Endpunkten. Für das 6in4-Beispiel sind deshalb Pakete mit den erwarteten äusseren IPv4-Adressen und IP-Protokoll 41 zu suchen; ein ICMP-Ping zwischen denselben Hosts ist kein Kapselungsnachweis. Für 4in6 wird entsprechend ein äusseres IPv6-Paket mit innerem IPv4-Paket geprüft. Erst der Vergleich mit dem inneren Mitschnitt und der tatsächlich erfolgreichen Anwendungssitzung belegt den vollständigen Weg. Capture-Daten können Nutzdaten enthalten und werden nur geschützt gespeichert oder vor einer Weitergabe anonymisiert.

Ein vorhandener Tunneleintrag beweist weder die Route noch die Erreichbarkeit der 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.

Im äusseren Mitschnitt fehlt der Testtraffic

Zuerst den aktiven Capture- und Display-Filter mit den tatsächlich verwendeten äusseren Endpunkten vergleichen. Bei einem Remote gateway als FQDN wird geprüft, ob die Firewall den Namen in die zum Tunneltyp passende, erwartete Peer-Adresse auflösen kann: IPv4 bei 6in4, IPv6 bei 4in6. Die FQDN-Option allein belegt weder einen bestimmten DNS-Aktualisierungsrhythmus noch unterbrechungsfreies Failover bei einem Adresswechsel.

Danach prüfen, ob der Testclient überhaupt Traffic zum inneren Ziel sendet und über sein Gateway die Firewall erreicht. Auf der Firewall muss die Routingentscheidung für dieses Ziel das Tunnelinterface auswählen. Ist lokal die passende Kapselung sichtbar, aber am Peer nicht, folgt die Prüfung des Underlay-Pfads und seiner Protokollfreigaben bei Provider und vorgeschalteten Geräten. Regeln werden nicht pauschal auf Any erweitert, und NAT wird nicht versuchsweise als Ersatz für diese Eingrenzung aktiviert. Bleibt die Ursache offen, sind SFOS-Version, beide Endpoint-Konfigurationen, Routen und zeitlich abgestimmte Mitschnitte beider Seiten die Grundlage für die Eskalation.

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

Laut SFOS-23-Hilfe wird beim Löschen eines 6to4- oder 6rd-Tunnels auch dessen automatisch erzeugte statische IPv6-Unicast-Route gelöscht. Diese Erwartung ersetzt weder Abhängigkeitsprüfungen noch den Vorher/Nachher-Vergleich. Sie betrifft nicht alle manuell hinzugefügten Routen und wird nicht allein aufgrund der SFOS-23-Hilfe auf SFOS 22 übertragen.

Für den Rollback wird zuerst der Testtraffic beendet und die neu angelegte Firewallregel deaktiviert. Danach werden ausschliesslich die für diesen Tunnel neu erstellten manuellen Routen gelöscht beziehungsweise geänderte Routen auf den dokumentierten Ausgangsstand zurückgesetzt. Automatisch erzeugte Routen von 6to4 oder 6rd werden anhand des Vorher/Nachher-Protokolls ausdrücklich mitgeprüft. Erst wenn keine produktive Abhängigkeit mehr besteht, wird der Tunnel gelöscht; eine danach verbliebene automatische Route wird einzeln entfernt. Anschliessend müssen Route Lookup über den früheren Pfad 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