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.

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

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.

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. Van belang is dat het zonemodel, de firewallregels en Device Access bij de werkelijke architectuur passen.

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.

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.

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.

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 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. Laat beide velden daarom op de gedocumenteerde uitgangswaarde staan zolang een gemeten routing- of QoS-probleem geen wijziging rechtvaardigt.

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.

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.

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.

Maak vervolgens tussen de betrokken zones een beperkte, gelogde firewallregel met de werkelijke source-, destination- en servicewaarden. Bij een normale locatieverbinding blijft het oorspronkelijke source-adres behouden; schakel MASQ niet in als vervanging voor een ontbrekend retourpad. Zie Sophos Firewall-regels veilig configureren voor de regelprocedure.

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 externe interne prefix naar de verwachte tunnelinterface wijst.
3. Voer Route Lookup uit voor de interne testserver en bevestig de verwachte interface.
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. Observeer met Packet Capture eerst de buitenste endpoints en daarna het interne testadres.
7. Controleer bij de peer de ingang, decapsulatie, retourroute en het werkelijke source-adres.
8. Herhaal de test in de andere richting alleen met een daarvoor bedoelde regel.

Een groene of aanwezige tunnelvermelding bewijst noch de route, noch de werking 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.

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.

Stop voor een rollback eerst het testverkeer. Schakel afhankelijke firewallregels en handmatige routes gecontroleerd uit of herstel hun bevestigde vorige toestand. Controleer automatisch gemaakte 6to4- of 6rd-routes expliciet. Verwijder de tunnel pas als er geen productieafhankelijkheid meer is. Verifieer ten slotte het vroegere routeringspad en 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