Een Sophos Firewall IP-tunnel met 6in4, 6to4, 6rd of 4in6 configureren

Onder Network > IP tunnels maakt Sophos Firewall tunnels die het ene netwerkprotocol in het andere inkapselen. Zo kan IPv6 over een IPv4-underlay of IPv4 over een IPv6-underlay worden vervoerd. SFOS biedt hiervoor 6in4, 6to4, 6rd en 4in6.

Deze functie is niet de GRE-tunnel uit de Device Console en ook geen IPsec VPN. Een IP-tunnel kapselt pakketten in, maar versleutelt of authenticeert ze niet automatisch.

Kort stappenplan: Plan het interne bestemmingsnetwerk en de buitenste endpoints afzonderlijk, sla het passende type op onder Network > IP tunnels > Add en voeg een route, retourroute en beperkte regel voor het interne verkeer toe. Test vervolgens een nieuwe applicatiesessie en controleer de buitenste inkapseling, decapsulatie en Rule ID afzonderlijk. Save bevestigt de configuratie, niet een succesvol getest datapad.

⚠️ Gebruik een IP-tunnel over een niet-vertrouwde underlay alleen als het beveiligingsontwerp het ontbreken van vertrouwelijkheid en peer-authenticatie uitdrukkelijk accepteert. Voor een beveiligde koppeling tussen locaties is site-to-site IPsec doorgaans een beter uitgangspunt.

Welk tunneltype past?

De vier typen lossen niet hetzelfde probleem op:

• 6in4 verbindt twee IPv6-netwerken over een IPv4-backbone. De lokale en externe IPv4-endpoints worden handmatig ingesteld. Sophos adviseert dit type voor point-to-pointverbindingen.
• 6to4 vervoert IPv6 over IPv4 en is bedoeld voor point-to-multipointontwerpen. De lokale IPv4-source wordt handmatig ingesteld; het bestemmingsadres kan automatisch worden verkregen.
• 6rd breidt 6to4 uit met een door de provider geleverd prefix. Dit type past alleen als de ISP de vereiste 6rd-waarden verstrekt.
• 4in6 verbindt twee IPv4-netwerken over een IPv6-backbone. De buitenste lokale en externe tunnelendpoints zijn IPv6-adressen en het type is bedoeld voor point-to-pointverbindingen.

De SFOS 23-help beschrijft het automatische mechanisme nauwkeuriger: 6to4 leidt het IPv6-prefix af van het lokale openbare IPv4-adres. Er wordt geen extern endpoint geconfigureerd; de bestemmingsgateway wordt automatisch bepaald op basis van het IPv6-bestemmingsadres. 6rd gebruikt daarentegen door de ISP geleverde IPv6-prefixes en relaygateways. De firewall bepaalt de door de ISP geleverde relaygateway automatisch. Hiervoor moet de ISP een geschikte 6rd-dienst bieden; geef de voorkeur aan native IPv6 als dat beschikbaar is. Deze mechanismen veranderen niets aan de onderstaande legacywaarschuwing.

Voor één gecontroleerde verbinding met vaste endpoints is 6in4 of 4in6 eenvoudiger te doorgronden. Kies 6to4 of 6rd niet alleen omdat SFOS automatisch een route kan maken. Het adres- en providerontwerp moet precies bij dat mechanisme passen.

Maak bij 6to4 ook onderscheid tussen het nog steeds gedefinieerde unicastmechanisme en het openbare anycast-relaymechanisme. De IETF heeft anycast-6to4 vanwege operationele problemen afgeschaft en adviseert routers om 6to4 standaard uitgeschakeld te laten (RFC 7526). Schakel 6to4 daarom niet in voor een nieuwe internetverbinding. Gebruik het hooguit voor een bestaand, uitdrukkelijk afgestemd unicastontwerp; native IPv6-connectiviteit, door de provider beheerd 6rd of een vaste 6in4-peer zijn beter beheersbaar.

IPv6-ondersteuning op Sophos Firewall vat de IPv6-grenzen van SFOS samen. Een GRE-tunnel vervoert daarentegen gerouteerd IP-verkeer via een afzonderlijke Device Console-procedure en is niet uitwisselbaar met deze vier WebAdmin-typen.

Voorbeeld en vereisten plannen

Het voorbeeld gebruikt een statische 6in4-tunnel tussen twee locaties:

• Weergavenaam: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Lokaal IPv4-WAN-adres: 192.0.2.10
• Extern IPv4-endpoint: 198.51.100.20
• Lokaal IPv6-netwerk: 2001:db8:100::/64
• Extern IPv6-netwerk: 2001:db8:200::/64
• Testserver: 2001:db8:200::20
• Zone van de tunnelinterface: in het voorbeeld VPN

192.0.2.0/24, 198.51.100.0/24 en 2001:db8::/32 zijn documentatiebereiken. Vervang ze, samen met namen, zone en prefixes, door de werkelijke waarden. De zone VPN is een begrijpelijke voorbeeldkeuze, geen productvereiste. Het zonemodel en de firewallregels moeten bij de werkelijke architectuur passen. Device access regelt toegang tot diensten op de firewall zelf en vervangt geen regel voor doorgestuurd applicatieverkeer.

Beide buitenste endpoints moeten via de underlay bereikbaar zijn voordat de tunnel wordt gemaakt. Aan beide kanten zijn een spiegelbeeldige tunnel, unieke interne netwerken, een retourpad en een firewallregel voor het echte applicatieverkeer nodig. Overlappende prefixes, een ontbrekende providerwaarde voor 6rd of een onbekende peerconfiguratie zijn stopvoorwaarden.

De underlay moet een ingekapseld IP-protocol vervoeren, niet een TCP- of UDP-poort. 6in4, 6to4 en 6rd gebruiken IPv6-in-IPv4 met IPv4-protocolnummer 41 (RFC 4213); 4in6 volgt het IPv6-tunnelmodel uit RFC 2473 en duidt het interne IPv4-pakket in de buitenste IPv6-header aan met de door IANA geregistreerde Next Header-waarde 4. Bevestig dit exacte datapad vóór ingebruikname bij de provider, de upstream-firewall en elk NAT-apparaat. Een poort openen vervangt die controle niet.

Een back-up, onderhoudsvenster en onafhankelijke beheerstoegang horen ook bij het herstelplan. Leg de tunnel niet als experiment aan op de enige productieverbinding.

De IP-tunnel in WebAdmin maken

Onder Network > IP tunnels > Add worden eerst de identiteit en het tunneltype ingesteld, daarna de endpoints en geavanceerde IP-waarden.

Name en Hardware name onderscheiden

De gewone Name mag maximaal 58 tekens bevatten en kan later worden gewijzigd. De naam moet doel en peer herkenbaar maken, bijvoorbeeld HQ-IPv6-via-IPv4.

Andere instellingen tonen deze aanpasbare interfacenaam, niet de onveranderlijke Hardware name.

De Hardware name is technisch en kan na het opslaan niet meer worden gewijzigd. De naam mag maximaal tien tekens bevatten en uitsluitend A-Z, a-z, 0-9 en _. SFOS blokkeert bovendien veel systeemnamen en -delen, waaronder gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN en Halink. De neutrale voorbeeldwaarde v6hq01 voorkomt deze conflicten.

Een onjuiste Hardware name wordt later niet hernoemd. Documenteer de afhankelijkheden en maak de tunnel gecontroleerd opnieuw. Controleer deze waarde daarom extra zorgvuldig vóór Save.

De volledige gedocumenteerde beperkingslijst voor Hardware name in SFOS 22 en 23 is: 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. De naam mag geen van deze delen bevatten; het gaat niet alleen om identieke volledige namen. De gedocumenteerde schrijfwijzen blijven behouden, zonder daaruit af te leiden hoe hoofdlettergevoeligheid wordt gecontroleerd.

Tunneltype, zone en endpoints instellen

Selecteer voor het voorbeeld 6in4. Stel onder Zone de bedoelde beveiligingszone in. Vul bij Local endpoint 192.0.2.10 in en bij Remote endpoint 198.51.100.20.

De veldnaam Remote endpoint volgt de SFOS 22-help. De SFOS 23-help noemt dit veld Remote gateway: het accepteert een IPv4-adres of FQDN voor 6in4, en een IPv6-adres of FQDN voor 4in6. Een FQDN is de volledige DNS-naam van de peer, niet het interne bestemmingsprefix. Voor Local endpoint beschrijft SFOS 23 een adres dat aan een interface is gekoppeld (6in4/6to4), expliciet een gekoppeld IPv4-adres voor 6rd, en een IPv6-interface voor 4in6. De lokale adresfamilie blijft zoals hieronder beschreven. Verschillen in de helptekst bewijzen niet in welke exacte release runtimeondersteuning begon.

De adresfamilie hangt van het type af. Bij 6in4, 6to4 en 6rd is het lokale buitenste endpoint IPv4; 6in4 heeft daarnaast een vast extern IPv4-endpoint. Bij 4in6 zijn de lokale en externe buitenste endpoints IPv6-adressen. Vul een interne bestemmingsroute niet in een endpointveld in.

In de geavanceerde instellingen beïnvloedt TTL hoe lang ingekapselde pakketten over de underlay kunnen blijven bestaan. TOS kent aan het buitenste IP-pakket een type-of-servicewaarde toe voor prioriteit en routeringsgedrag. De huidige help noemt geen universele beste waarden en vermeldt op de helppagina geen standaardwaarde. Noteer daarom de uitgangswaarden uit het eigen formulier en wijzig ze alleen wanneer een concrete underlay- of QoS-eis dat verlangt.

Deze TTL/TOS-basis volgt de SFOS 22-help. De SFOS 23-help beschrijft TTL als het maximale aantal routers dat een ingekapseld pakket mag passeren voordat het wordt weggegooid. Deze limiet helpt routeringslussen voorkomen. Ook hier wordt geen numerieke standaardwaarde voor TTL of ToS vermeld.

Voor 4in6 beschrijft SFOS 23 bovendien deze geavanceerde instellingen:

• Inherit ToS is optioneel en neemt de ToS-waarde van het interne pakket over.
• MTU is de grootste pakketgrootte in bytes die zonder fragmentatie door de tunnel kan worden verzonden. De gedocumenteerde standaardwaarde is de MTU van de fysieke interface minus 48 bytes; deze verlaging houdt rekening met de overhead van 4in6-inkapseling.
• Override MSS is optioneel en maakt het mogelijk de MSS handmatig op te geven. MSS is de grootste TCP-payload in bytes in één TCP-pakket zonder fragmentatie. Aanpassing kan fragmentatie voorkomen of rekening houden met Path MTU-limieten. De gedocumenteerde standaardwaarde is de MTU-waarde minus 40 bytes.

Gebruik deze formules niet als berekening van de werkelijke protocoloverhead of prestaties van het eigen pad. Voor de optionele selectievakjes wordt geen standaardactiveringsstatus beweerd. Een aanpassing blijft afhankelijk van het werkelijke pad.

Na Save bevestigt SFOS de creatie en opent het routedialoogvenster. Bij 6to4 en 6rd maakt de firewall bovendien automatisch een statische IPv6-unicastroute. Belangrijk: als dit venster wordt gesloten of Cancel wordt gekozen, blijven de tunnel en automatisch gemaakte routes opgeslagen.

SFOS 23-API: schema en validatie

Dit onderdeel beschrijft Add IP Tunnel / Edit IP Tunnel in de API, niet de WebAdmin-procedure. Vergeleken met de SFOS 22-documentatie voegt de SFOS 23-parametertabel vier optionele velden van het type SCALAR toe:

• MSS: INTEGER, toegestaan bereik 536–8912, maximaal vier cijfers.
• MTU: INTEGER, toegestaan bereik 576–8952, maximaal vier cijfers.
• LocalInterface: STRING voor de lokale tunnelinterface; de cel Default is leeg. Dit bevestigt geen standaardwaarde tijdens uitvoering.
• InheritToS: toegestane waarden Disable en Enable.

De tabel bevestigt niet dat elk veld voor elk tunneltype geldt, welke voorrang LocalInterface en LocalEndPoint hebben, welke veldcombinaties verplicht zijn of in welke release runtimeondersteuning begon. De WebAdmin-informatie over endpoints en FQDN wordt niet overgenomen als belofte van API-compatibiliteit.

API-status 541 bij Add en Edit

Voor beide bewerkingen documenteert SFOS 23 status 541 met de melding MTU and MSS must not exceed the local interface values. MTU en MSS mogen dus niet hoger zijn dan de overeenkomstige waarden van de lokale interface. Vergelijk vóór een wijziging de ingediende MTU/MSS-waarden, de bijbehorende lokale interface en de vastgelegde configuratie daarvan. Deze API-validatie meet niet de MTU van het datapad en bevestigt geen algemene rekenrelatie tussen MTU en MSS.

Tegenstrijdige standaardwaarden blijven onopgelost

De API-tabel vermeldt bij MSS letterlijk Default: Enable, hoewel het veld als INTEGER met een numeriek bereik wordt beschreven. Bij InheritToS staat letterlijk Default: off, terwijl alleen Disable en Enable als toegestane waarden worden genoemd. Deze tegenstrijdige documentatiewaarden zijn geen aanbevolen payloadwaarden en worden niet gecorrigeerd of als andere tokens geïnterpreteerd.

De API noemt bovendien 1500 als MTU-standaardwaarde en beschrijft ToS-overerving van de lokale interface. De WebAdmin-help voor 4in6 noemt daarentegen de MTU van de fysieke interface minus 48 bytes, MSS gelijk aan MTU minus 40 bytes en ToS-overerving van het interne pakket. De koppeling tussen deze interfaces blijft onduidelijk; de correcte WebAdmin-formules en optionele bedieningselementen hierboven blijven ongewijzigd.

Direct toepasbare automatiseringsinstructies die deze standaardwaarden, overervingsregels of veldprioriteiten veronderstellen, blijven uitgesloten. Daarom wordt hier geen uitvoerbare API-payload aangeboden. Hiervoor is verduidelijking door Sophos of een uitdrukkelijk geautoriseerde test op de passende SFOS-versie nodig; de schema- en statusinformatie alleen bevestigt geen correcte verwerking op de geïnstalleerde build.

Routes en firewallregels toevoegen

Een opgeslagen tunnel is nog geen werkend datapad. Voeg voor 6in4 een statische IPv6-route naar het externe prefix 2001:db8:200::/64 via de nieuwe tunnelinterface toe. De peer heeft het spiegelbeeldige retourpad naar 2001:db8:100::/64 nodig.

Bij 4in6 voert de interne route naar een IPv4-bestemmingsnetwerk. Bij 6to4 en 6rd wordt de automatisch gemaakte IPv6-route eerst gelezen en met het providerontwerp vergeleken voordat verdere routes worden toegevoegd. Cancel in het eerste routedialoogvenster is geen rollback.

Voor aanvullende IPv6-routes na het opslaan van 6to4 of 6rd noemt SFOS 23 in de pop-up de velden Destination IP (IPv6) en Gateway (IPv6). Vul bestemming en gateway volgens het netwerkontwerp in en kies Save; kies Cancel als geen extra route nodig is. Deze IPv6-velden gelden niet voor de interne IPv4-route van een 4in6-tunnel. De SFOS 22-waarschuwing over opgeslagen configuratie bij Cancel blijft van belang.

Voeg aanvullende routes toe onder Routing > Static routes. Statische routes op Sophos Firewall legt uit hoe bestemmingsprefix, interface, afstand, routeringsbeslissing en een echte test samenhangen.

Ga voor het 6in4-voorbeeld naar Rules and policies > Firewall rules, selecteer IPv6 en vervolgens Add firewall rule > New firewall rule. Stel Action: Accept, de werkelijke Source zones, Source networks and devices, Destination zones, Destination networks en Services in en schakel Log firewall traffic in. Plaats de regel zo dat een bredere regel niet eerder overeenkomt. Antwoorden die bij een toegestane stateful verbinding horen, hebben geen tweede regel nodig. Maak alleen een eigen, even beperkte regel als de peer nieuwe verbindingen moet kunnen starten.

Bij een normale locatieverbinding blijft het oorspronkelijke source-adres behouden. Laat Create linked NAT rule uitgeschakeld; schakel MASQ niet in als vervanging voor een ontbrekend retourpad. SFOS laat toegestaan verkeer onvertaald door wanneer geen NAT-regel overeenkomt. Als het ontwerp werkelijk vertaling vereist, plan en test die dan afzonderlijk met de oorspronkelijke en vertaalde flows. Zie Sophos Firewall-regels veilig configureren voor de regelprocedure.

4in6: IPv4-applicatieverkeer over IPv6 vervoeren

Bij 4in6 verandert ten opzichte van het 6in4-voorbeeld niet alleen het tunneltype. De buitenste endpoints zijn IPv6, terwijl de gerouteerde netwerken en firewallregels IPv4 zijn. Een afzonderlijk planningsvoorbeeld gebruikt lokaal 10.10.10.0/24, extern 10.20.20.0/24 en als testserver 10.20.20.20. Het buitenste lokale interfaceadres is 2001:db8:10::10, het externe gatewayadres 2001:db8:20::20. Vervang de private IPv4-netwerken en IPv6-documentatieadressen door unieke, niet-overlappende interne netwerken en IPv6-endpoints die daadwerkelijk via de underlay bereikbaar zijn.

1. Controleer vooraf het IPv6-underlaypad naar 2001:db8:20::20. De route naar de buitenste peer moet via de underlay lopen, niet via de tunnel die met deze peer nog moet worden opgezet. Een geslaagde ping alleen bewijst nog niet dat de ingekapselde IPv4-pakketten worden vervoerd.
2. Kies onder Network > IP tunnels > Add 4in6, stel een unieke naam en Hardware name in en wijs de geplande Zone toe. Selecteer in SFOS 23 onder Local endpoint de IPv6-interface met het geplande lokale adres en vul onder Remote gateway het externe IPv6-adres in. Aan de andere kant worden de lokale en externe endpoints omgewisseld. Houd ook rekening met de hierboven beschreven SFOS 23-instellingen voor MTU, Override MSS en Inherit ToS.
3. Maak na Save onder Routing > Static routes een IPv4-route naar 10.20.20.0/24 via de nieuwe tunnelinterface. De peer krijgt de retourroute naar 10.10.10.0/24. De IPv6-velden van het aanvullende 6to4-/6rd-routedialoogvenster zijn hiervoor niet het voorbeeld.
4. Selecteer onder Rules and policies > Firewall rules IPv4. Sta alleen de benodigde verbindingen van het lokale IPv4-netwerk naar het externe IPv4-netwerk toe, stel de werkelijke zones en services in en schakel Log firewall traffic in. De IPv6-underlayadressen horen niet als vervanging voor de interne IPv4-netwerken in deze regel voor applicatieverkeer. Zonder beoogde adresvertaling blijft het source-adres behouden.
5. Controleer met Diagnostics > Tools > Route lookup 10.20.20.20 en start vervolgens vanaf de lokale testclient een nieuwe, toegestane verbinding naar deze server. Controleer bij de peer de decapsulatie en het retourpad. Na het beëindigen van de testsessie moeten de interne IPv4-adressen en de verwachte Firewall Rule ID in Log Viewer verschijnen; tijdens de sessie dient de capture om het pad direct te controleren.
6. Gebruik voor de buitenste capture in de hieronder beschreven captureprocedure het BPF-filter host 2001:db8:10::10 and host 2001:db8:20::20. Wis voor de afzonderlijke interne capture de BPF string weer en selecteer onder Display filter Ethernet type: IPv4 en Destination IP: 10.20.20.20. Leg telkens slechts één test vast en stop de capture daarna. Voer de rollback uit met dezelfde afhankelijkheidscontrole als hieronder, maar hier voor de speciaal aangemaakte IPv4-routes en -regels.

Tunnel en applicatieverkeer valideren

De validatie scheidt opgeslagen configuratie, buitenste inkapseling en de interne applicatie:

1. Vergelijk onder Network > IP tunnels Name, Hardware name, type, Zone en endpoints met de peer.
2. Controleer onder Routing > Static routes of het interne prefix van de externe locatie naar de verwachte tunnelinterface wijst.
3. Voer onder Diagnostics > Tools > Route lookup het interne adres 2001:db8:200::20 in en bevestig de verwachte tunnelinterface.
4. Start vanaf de lokale testclient een nieuwe verbinding naar 2001:db8:200::20 met een uitdrukkelijk toegestane service.
5. Controleer in Log Viewer Source, Destination, Service, Action en Firewall Rule ID.
6. Voer onder Diagnostics > Packet capture > Configure voor de buitenste controle host 192.0.2.10 and host 198.51.100.20 in bij Enter BPF string en sla dit op. Start de capture, genereer precies één test en stop de capture. Wis voor een afzonderlijke interne capture de BPF string onder Configure en sla dit op; stel vervolgens onder Display filter Ethernet type: IPv6 en Destination IP: 2001:db8:200::20 in en sla dit op. Start de capture voor slechts één test en stop hem daarna.
7. Controleer bij de peer de ingang, decapsulatie, retourroute en het werkelijke source-adres.
8. Test een nieuwe verbinding die de peer start alleen als een afzonderlijke regel dit toestaat; de stateful regel dekt antwoordverkeer al af.

Het buitenste hostfilter legt ook ander verkeer tussen de endpoints vast. Zoek voor het 6in4-voorbeeld daarom naar pakketten met de verwachte buitenste IPv4-adressen en IP-protocol 41; een ICMP-ping tussen dezelfde hosts bewijst geen inkapseling. Controleer voor 4in6 op dezelfde manier een buitenste IPv6-pakket met een intern IPv4-pakket. Pas de vergelijking met de interne capture en de daadwerkelijk geslaagde applicatiesessie bewijst het volledige pad. Capturegegevens kunnen payload bevatten en mogen alleen beveiligd worden opgeslagen of moeten vóór het delen worden geanonimiseerd.

Een tunnelvermelding bewijst noch de route, noch de bereikbaarheid van de peer. Een automatisch gemaakte route bewijst evenmin dat provider, tussenliggende apparaten en firewallregels de inkapseling daadwerkelijk vervoeren. Packet Capture op Sophos Firewall legt de gecontroleerde capture uit.

Problemen per symptoom onderzoeken

De tunnel kan niet worden opgeslagen

Controleer Name en Hardware name afzonderlijk. Hardware name mag maximaal tien tekens lang zijn, alleen toegestane tekens gebruiken en geen geblokkeerde systeemterm bevatten. Controleer daarna of het tunneltype en de adresfamilie van de lokale en externe endpoints overeenkomen.

Een andere weergavenaam lost een ongeldige Hardware name niet op. Als een andere interface de waarde al gebruikt, plan dan één unieke technische naam in plaats van steeds willekeurige suffixen te proberen.

De tunnel bestaat, maar er is geen route naar het bestemmingsnetwerk

Voeg bij 6in4 en 4in6 de vereiste statische route expliciet toe. Controleer bij 6to4 en 6rd of SFOS de verwachte IPv6-unicastroute heeft gemaakt en of het prefix bij het ontwerp past. Een eerder met Cancel gesloten venster verwijdert de automatisch opgeslagen configuratie niet.

Route Lookup en de routingtabel vormen het volgende bewijs. Wijzig de globale Route Precedence niet op basis van een vermoeden en voeg geen concurrerende blackhole- of dummyroute toe als testmiddel.

Het testverkeer ontbreekt in de buitenste capture

Vergelijk eerst het actieve capturefilter en weergavefilter met de daadwerkelijk gebruikte buitenste endpoints. Controleer bij een Remote gateway als FQDN of de firewall de naam kan omzetten naar het verwachte peeradres dat bij het tunneltype past: IPv4 bij 6in4, IPv6 bij 4in6. De FQDN-optie alleen bewijst noch een bepaald DNS-verversingsinterval, noch ononderbroken failover bij een adreswijziging.

Controleer daarna of de testclient überhaupt verkeer naar de interne bestemming stuurt en via zijn gateway de firewall bereikt. Op de firewall moet de routeringsbeslissing voor deze bestemming de tunnelinterface selecteren. Als lokaal de juiste inkapseling zichtbaar is, maar niet bij de peer, controleer dan het underlaypad en de toegestane protocollen bij de provider en op upstream-apparaten. Verruim regels niet zonder meer naar Any en schakel NAT niet bij wijze van proef in als vervanging voor deze gerichte analyse. Als de oorzaak onduidelijk blijft, vormen de SFOS-versie, beide endpointconfiguraties, routes en in tijd afgestemde captures van beide kanten de basis voor escalatie.

Buitenste pakketten zijn zichtbaar, maar intern verkeer ontbreekt

Vaak komen het peertype, endpointadressen, interne prefix of de retourroute niet overeen. Vergelijk beide configuraties als spiegelbeeld. Controleer daarna de firewallregel, de verwachte Firewall Rule ID en een capture van de interne source- en destination-adressen.

Werkende inkapseling bewijst niet dat het applicatieverkeer is toegestaan. Omgekeerd kan een ontbrekende Rule ID betekenen dat het interne pakket nooit is gedecapsuleerd of via een andere route is verwerkt.

Kleine pakketten werken, maar applicaties lopen vast

De extra buitenste IP-inkapseling verkleint de bruikbare pakketgrootte ten opzichte van de underlay. Neem geen vreemde MTU-waarde over, maar meet Path MTU, fragmentatie en de betrokken applicatie. De gecontroleerde procedure in MTU en MSS bij tunnelproblemen controleren is ook bruikbaar voor deze analyse; vaste IPsec-waarden worden daarbij niet op de IP-tunnel overgenomen.

HA, wijzigingen en rollback

De twee SFOS 22-helppagina’s beloven geen ononderbroken HA-status voor deze IP-tunnels. Controleer na een geplande rolwisseling opnieuw de tunnelvermelding, Route Lookup, buitenste inkapseling, Firewall Rule ID en een nieuwe applicatiesessie. Een bestaande verbinding bewijst geen continuïteit.

Documenteer vóór een wijziging Name, de onveranderlijke Hardware name, type, Zone, endpoints, automatisch en handmatig gemaakte routes, regels en de laatste echte test. Zo kan een configuratiewijziging van een wijziging in het datapad worden onderscheiden.

Volgens de SFOS 23-help verwijdert het verwijderen van een 6to4- of 6rd-tunnel ook de bijbehorende automatisch gemaakte statische IPv6-unicastroute. Deze verwachting vervangt geen afhankelijkheidscontroles of vergelijking vóór en na de wijziging. Ze betreft niet alle handmatig toegevoegde routes en wordt niet uitsluitend op basis van de SFOS 23-help op SFOS 22 toegepast.

Stop voor een rollback eerst het testverkeer en schakel de nieuw gemaakte firewallregel uit. Verwijder alleen handmatige routes die voor deze tunnel zijn gemaakt of herstel gewijzigde routes naar de vastgelegde uitgangstoestand. Vergelijk automatisch gemaakte 6to4- of 6rd-routes uitdrukkelijk met de voor-en-na-registratie. Verwijder de tunnel pas als er geen productieafhankelijkheid meer is en verwijder daarna afzonderlijk elke automatisch gemaakte route die is blijven staan. Bevestig ten slotte met Route lookup het eerdere pad en test een bekende gegevensstroom opnieuw.

Checklist

• Het geselecteerde type past bij de interne en externe adresfamilies.
• Beide endpoints en prefixes zijn met de peer afgestemd.
• De weergavenaam en onveranderlijke Hardware name zijn gedocumenteerd.
• Zone, statische route en retourpad passen bij het beveiligingsontwerp.
• Automatisch gemaakte 6to4- of 6rd-routes zijn gecontroleerd.
• Een beperkte firewallregel matcht met de verwachte Firewall Rule ID.
• Buitenste inkapseling en intern applicatieverkeer zijn afzonderlijk getest.
• MTU, HA en rollback zijn op het echte pad gevalideerd.

Veelgestelde vragen