Een GRE-tunnel op Sophos Firewall configureren en testen

Een GRE-tunnel verbindt twee IP-eindpunten en transporteert daartussen gerouteerd verkeer. Op Sophos Firewall wordt de tunnel in de Device Console met system gre aangemaakt. Dit past bijvoorbeeld bij een provider-on-ramp, een eenvoudig overlaypad of een transportverbinding waarvoor GRE uitdrukkelijk vereist is.

Kort antwoord

Voor een veilige implementatie worden eerst de buitenste WAN-eindpunten, de binnenste tunnel-IP’s en de externe netwerken gedocumenteerd. Daarna volgen deze stappen:

1. Controleer de underlay-bereikbaarheid van beide WAN-eindpunten en IP-protocol 47.
2. Maak op beide firewalls de GRE-tunnel spiegelbeeldig aan met system gre tunnel add.
3. Controleer met system gre tunnel show de namen, eindpunten, tunnel-IP’s en status.
4. Wijs de externe netwerken met system gre route add aan de tunnel toe.
5. Maak beperkte, gelogde firewallregels tussen LAN en VPN.
6. Test GRE op het WAN-pad, de interne route, Rule ID, het gebruiksverkeer en het retourpad afzonderlijk.

⚠️ GRE biedt zelf geen versleuteling of authenticatie. Via een niet-vertrouwd netwerk wordt GRE alleen gebruikt als onversleuteld transport uitdrukkelijk in het beveiligingsontwerp is geaccepteerd. Als vertrouwelijkheid of peer-authenticatie nodig is, past meestal een site-to-site IPsec VPN beter.

GRE-eindpunten, tunnel-IP’s en routes onderscheiden

Een GRE-opzet bestaat uit meerdere lagen:

• Local gateway: de lokale WAN-interface van Sophos Firewall, bijvoorbeeld Port2.
• Remote gateway: het externe IPv4-adres van de andere kant.
• Local IP en Remote IP: de interne point-to-point-adressen van de GRE-tunnel.
• GRE-route: wijst een externe host of een extern doelnetwerk aan de tunnel toe.
• Firewallregel: staat de concrete datastroom tussen de zones en netwerken toe.
• Retourpad: stuurt de antwoordpakketten via de spiegelbeeldige tunnel terug.

GRE over IPv4 gebruikt IP-protocol 47. Dat is noch TCP noch UDP en mag niet worden verward met poort 47. Een upstream router, providerfilter of cloud-security-list moet daarom het IP-protocol tussen de twee buitenste eindpunten kunnen doorlaten.

Een zichtbare tunnelstatus Enabled bevestigt dat de GRE-configuratie opgeslagen en ingeschakeld is. Dit bewijst nog niet dat de peer antwoordt, de route klopt of een toepassing werkt.

Wanneer GRE past en wanneer IPsec verstandiger is

GRE is lichtgewicht en transporteert gerouteerd verkeer tussen twee gedefinieerde eindpunten. Het past als een provider of platform GRE vereist, als alleen inkapseling nodig is of als een vertrouwd underlaypad al afzonderlijk is beschermd.

GRE is daarentegen geen vervanging voor een versleutelde site-to-siteverbinding. Voor normale verbindingen via het openbare internet is route-based IPsec meestal het geschiktere uitgangspunt. Een combinatie van GRE en IPsec vereist een afzonderlijk ontwerp dat op beide apparaten is getest; deze basisprocedure maakt geen onbeproefd GRE-over-IPsec-pad aan.

Dit artikel behandelt een statische IPv4-point-to-point-tunnel. Multicast, PIM-SM, BGP over GRE en providerspecifieke Anycast-tunnels zijn mogelijke uitbreidingen, maar worden pas gepland nadat het basispad voor unicast goed werkt.

Voorbeeldtopologie plannen

Het voorbeeld verbindt twee Sophos Firewalls:

• Locatie A WAN: Port2 met 192.0.2.10
• Locatie A LAN: 10.10.10.0/24
• Locatie A tunnel-IP: 10.255.255.1
• Locatie B WAN: Port2 met 198.51.100.20
• Locatie B LAN: 10.20.20.0/24
• Locatie B testserver: 10.20.20.10
• Locatie B tunnel-IP: 10.255.255.2
• Tunnelnetwerk: 10.255.255.0/30
• Testservice: HTTPS oftewel TCP 443

192.0.2.0/24 en 198.51.100.0/24 zijn documentatienetwerken en worden niet in productie gebruikt. Beide WAN-adressen, interfaces, tunnel-IP’s, LAN-netwerken en de testserver worden samen door de werkelijke waarden vervangen. De tunnel-IP’s moeten een eigen, aan beide kanten identiek gepland point-to-point-netwerk vormen en mogen niet met bestaande netwerken overlappen.

In het voorbeeld worden de tunnelnamen gre_branch op locatie A en gre_hq op locatie B gebruikt. De namen zijn vrij te kiezen, maar mogen volgens de huidige SFOS 22-API maximaal 15 tekens lang zijn.

Voor de wijziging zijn een configuratieback-up, een onderhoudsvenster en onafhankelijke beheerstoegang nodig als terugweg. Daarnaast worden bestaande statische en SD-WAN Routes, NAT-regels, firewallregels en overlappende netwerken vastgelegd.

Vereisten op het buitenste pad controleren

Beide WAN-eindpunten moeten elkaar via de underlay kunnen bereiken. De basisopzet gebruikt aan beide kanten statische IPv4-adressen. Als het lokale WAN-adres via PPPoE of DHCP wordt verkregen, wordt niet verdergegaan met deze procedure: oudere officiële Sophos GRE-handleidingen sluiten dynamische lokale WAN-interfaces uit, terwijl de huidige SFOS 22-API alleen DDNS voor de Remote Gateway documenteert. De ondersteuning moet daarom voor de concrete build en verbinding worden opgehelderd.

Voor de tunnelconfiguratie worden deze punten gecontroleerd:

• Het externe WAN-adres wordt via de verwachte WAN-gateway gerouteerd.
• Upstream routers, providers en cloud-ACL’s staan IP-protocol 47 tussen beide eindpunten toe.
• Er is geen CGNAT- of NAT-opzet waarvan het GRE-gedrag onduidelijk is.
• De interne tunnel-IP’s en LAN-netwerken overlappen noch lokaal, noch op afstand.
• De peer gebruikt spiegelbeeldig dezelfde buitenste en binnenste waarden.
• Een retourpad naar beide LAN-netwerken is gepland.

Een ping naar de publieke peer kan het underlaypad ondersteunen, maar bewijst geen GRE-ondersteuning. Ook een vrijgave voor TCP- of UDP-poort 47 helpt niet, omdat GRE geen poortgebaseerd transportprotocol is.

De GRE-tunnel op beide firewalls aanmaken

De configuratie gebeurt via de CLI in menu 4. Device Console. De huidige Sophos-helppagina bevat onjuist weergegeven syntaxfragmenten. Daarom wordt vóór de wijziging op de gebruikte build met Tab of ? gecontroleerd of de volgende parameters beschikbaar zijn.

Locatie A configureren

Op firewall A worden de lokale WAN-poort Port2, de externe peer 198.51.100.20 en het interne tunnelpaar ingevoerd:

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

Daarna wordt alleen gelezen:

system gre tunnel show

De vermelding moet gre_branch, Port2, het externe WAN-adres en beide tunnel-IP’s correct tonen. Een typefout wordt niet verborgen met een tweede, bijna gelijknamige configuratie.

Locatie B spiegelbeeldig configureren

Op firewall B worden de lokale en externe waarden omgewisseld:

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

Ook hier volgt de leescontrole:

system gre tunnel show

Enabled is op dit moment slechts een tussencontrole. De acceptatietest eindigt pas met een echte LAN-naar-LAN-datastroom.

Externe netwerken via GRE routeren

Voor het eenvoudige vaste pad wordt op elke firewall een GRE-route aangemaakt. Locatie A stuurt het LAN van locatie B via gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

Locatie B krijgt het spiegelbeeldige retourpad:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Daarna worden de geconfigureerde toewijzingen op beide apparaten gelezen:

system gre route show

De route mag niet concurreren met een even lange of specifiekere statische, SD-WAN-, VPN- of direct verbonden route. De globale Route Precedence wordt niet op goed geluk gewijzigd. Eerst worden de daadwerkelijk gematchte route en het pakketpad aangetoond.

Custom Gateway en SD-WAN als alternatief

Sommige providerontwerpen gebruiken in plaats van de eenvoudige GRE-route een Custom Gateway op het GRE-pad en selecteren die in een SD-WAN Route. Dit past als Source, Service, Failover of een gedefinieerde gatewaystatus deel van de routeringsbeslissing moeten uitmaken.

De externe tunnel-IP is daarbij de Next Hop. Health Check, Zone en Probe Target moeten bij het concrete providerontwerp passen; monitoring die in een handleiding van een fabrikant is uitgeschakeld, is geen universele standaard. Hoe object, probe en echte test samenhangen, wordt uitgelegd in Een Sophos Firewall Custom Gateway maken en controleren. De selectie van het pad staat onder Een Sophos Firewall SD-WAN Route instellen.

GRE-route en SD-WAN Route worden niet ongecontroleerd parallel voor dezelfde netwerken geactiveerd. Voor de omschakeling wordt vastgelegd welk mechanisme moet winnen en hoe naar het eerdere pad kan worden teruggekeerd.

Firewallregels zonder onnodige NAT maken

De GRE-tunnel en de route staan nog geen gebruiksverkeer toe. Voor een vanaf locatie A gestarte HTTPS-verbinding is op beide firewalls een beperkte, gelogde regel nodig.

Op firewall A geldt:

• 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: ingeschakeld

Op firewall B wordt het binnenkomende tunnelverkeer naar de testserver toegestaan:

• 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: ingeschakeld

Deze twee regels dekken de door locatie A gestarte verbinding en het stateful retourverkeer. Als hosts op locatie B zelf nieuwe verbindingen naar locatie A mogen starten, wordt daarnaast het spiegelbeeldige regelpaar LAN naar VPN op firewall B en VPN naar LAN op firewall A gemaakt met de werkelijk benodigde netwerken en services. Een brede Any-regel is voor de acceptatietest niet nodig.

Bij een normale site-to-sitekoppeling blijft het oorspronkelijke bron-IP behouden. MASQ wordt niet ingeschakeld als vermeende oplossing voor een routeringsprobleem. Als het retourpad ontbreekt, wordt de route aan de andere kant gecorrigeerd. De algemene regelopbouw wordt uitgelegd in Sophos Firewall-regels maken en veilig controleren.

Tunnel en gebruiksverkeer samen testen

De controle volgt het pakketpad en scheidt de configuratie van de werkelijke werking:

1. Voer op beide firewalls system gre tunnel show uit en vergelijk de eindpunten en tunnel-IP’s.

2. Controleer met system gre route show het betreffende externe LAN en de juiste tunnelnaam.

3. Start vanaf de client in 10.10.10.0/24 een nieuwe HTTPS-verbinding naar 10.20.20.10.

4. Controleer in Log viewer op beide firewalls Source, Destination, Service, Firewall Rule ID, NAT Rule ID en Zone.

5. Filter onder Diagnostics > Packet capture op locatie A het buitenste GRE-pad:

   host 198.51.100.20 and ip proto 47
   

6. Filter de interne teststroom afzonderlijk:

   host 10.20.20.10 and tcp port 443
   

7. Vergelijk ingang en uitgang op beide firewalls en controleer op de doelserver het werkelijke bron-IP.

8. Start alleen een retourtest met een service die daarvoor is toegestaan.

De buitenste capture toont de inkapseling tussen de WAN-eindpunten. De interne capture en de Rule ID laten zien of het gebruikspakket via de verwachte regel en route loopt. Pas de succesvolle toepassing bevestigt het volledige pad. De gecombineerde procedure staat uitgebreider beschreven onder Firewallregels testen en Packet Capture gebruiken.

Fouten per symptoom afbakenen

Geen GRE-pakket verlaat de WAN-interface

• Controleer Remote Gateway en het lokale local-gw in de tunnel.
• Controleer de underlayroute naar het externe WAN-adres en de gekozen WAN-gateway.
• Zorg dat de teststroom werkelijk de GRE-route of de bedoelde SD-WAN Route matcht.
• Vergelijk met system gre tunnel show en system gre route show de namen en toewijzing.
• Maak geen TCP-/UDP-poortvrijgave ter vervanging van IP-protocol 47.

GRE verlaat locatie A, maar bereikt locatie B niet

• Controleer providers, upstream routers, cloud-ACL’s en mogelijke NAT-trajecten op IP-protocol 47.
• Maak op locatie B tegelijk een capture met het buitenste WAN-filter.
• Vergelijk de buitenste bron- en doeladressen met de peerconfiguratie.
• Stop bij een dynamisch WAN, CGNAT of onduidelijke NAT en maskeer de opzet niet met brede regels.

GRE is aan beide WAN-zijden zichtbaar, maar intern verkeer ontbreekt

• Local IP en Remote IP moeten op beide firewalls spiegelbeeldig zijn.
• Vergelijk GRE-route, doelnetwerk en tunnelnaam teken voor teken.
• Controleer op beide kanten de firewallregel en de verwachte Rule ID.
• Sluit overlappende netwerken, NAT en een ontbrekend retourpad uit.
• Gebruik Enabled niet als bewijs voor de interne route of toepassing.

Slechts één richting werkt

• Controleer op locatie B de GRE-route voor het retournetwerk.
• Controleer of locatie B nieuwe verbindingen moet initiëren en daarvoor een eigen firewallregel nodig heeft.
• Controleer op de doelserver Default Gateway, lokale hostfirewall en het werkelijke bron-IP.
• Vergelijk asymmetrische SD-WAN- of statische routes aan beide kanten.

Kleine pakketten werken, grote verbindingen haperen

GRE voegt een buitenste IP- en GRE-header toe. Daardoor is de bruikbare pakketgrootte kleiner dan bij de underlay. Een vaste MTU- of MSS-waarde wordt niet ongecontroleerd overgenomen: eerst worden de underlay-MTU, Path MTU Discovery, fragmentatie en de betrokken toepassing gemeten. De gecontroleerde procedure wordt uitgelegd in MTU en MSS bij VPN-problemen controleren.

HA en werking voorzichtig testen

De huidige openbare Sophos-documentatie doet voor GRE geen toezegging over ononderbroken HA-failover of gesynchroniseerde tunnel-state. Een gecontroleerde rolwisseling vindt daarom alleen plaats in een onderhoudsvenster met onafhankelijke beheerstoegang.

Na de wisseling worden system gre tunnel show, system gre route show, een buitenste GRE-capture, een nieuwe clientverbinding, Rule ID en retourpad opnieuw gecontroleerd. Een bestaande TCP-verbinding geldt niet als bewijs van continuïteit.

Tijdens de werking worden eigenaar, beide WAN-eindpunten, tunnel-IP’s, tunnelnamen, externe netwerken, routeringsmechanisme, firewallregels, verwachte MTU-grens en laatste echte test gedocumenteerd. Na wijzigingen aan WAN, provider, NAT, SD-WAN, Route Precedence of peer wordt het hele pad opnieuw getest.

Veilig terugdraaien

De afbouw gebeurt gecoördineerd op beide firewalls:

1. Stop het testverkeer en leg de laatste status vast met system gre tunnel show en system gre route show.

2. Schakel nieuwe firewallregels en een eventueel gemaakte SD-WAN Route uit.

3. Haal een eventueel gebruikte Custom Gateway pas uit het pad nadat Object usage is gecontroleerd.

4. Verwijder op locatie A de concrete GRE-route:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. Verwijder op locatie B de retourroute:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Controleer met system gre route show dat alleen de bedoelde vermeldingen verdwenen zijn.

7. Verwijder daarna op locatie A de tunnel gericht op naam:

   system gre tunnel del name gre_branch
   

8. Verwijder op locatie B alleen de tunnel van die locatie:

   system gre tunnel del name gre_hq
   

9. Sluit af met system gre tunnel show en een test van het eerdere routeringspad.

del All wordt niet gebruikt. Als syntax of objectnaam op de gebruikte build onduidelijk is, wordt vóór het verwijderen met Tab of ? gecontroleerd en niet gegokt.

Veelgestelde vragen