Configurer et tester un tunnel GRE sur Sophos Firewall

Un tunnel GRE relie deux endpoints IP et transporte du trafic routé dans le tunnel. Sur Sophos Firewall, il se crée dans la Device Console avec system gre. Il convient par exemple à un on-ramp de fournisseur, un chemin overlay simple ou un transport qui exige explicitement GRE.

Réponse rapide

Pour une mise en place sûre, documenter d’abord les endpoints WAN externes, les IP internes du tunnel et les réseaux distants. Ensuite :

1. Vérifier l’accessibilité underlay entre les deux endpoints WAN et le protocole IP 47.
2. Créer le tunnel GRE de manière symétrique sur les deux pare-feu avec system gre tunnel add.
3. Vérifier les noms, les endpoints, les IP de tunnel et l’état avec system gre tunnel show.
4. Affecter les réseaux distants au tunnel avec system gre route add.
5. Créer des règles de pare-feu restrictives et journalisées entre LAN et VPN.
6. Tester séparément GRE sur le chemin WAN, la route interne, la Rule ID, le trafic applicatif et le chemin de retour.

⚠️ GRE ne fournit lui-même ni chiffrement ni authentification. Sur un réseau non fiable, GRE n’est utilisé que si le transport non chiffré est explicitement accepté dans la conception de sécurité. Si la confidentialité ou l’authentification du peer est requise, un VPN IPsec site-to-site est généralement plus approprié.

Distinguer endpoints GRE, IP de tunnel et routes

Une conception GRE se compose de plusieurs couches :

• Local gateway : l’interface WAN locale de Sophos Firewall, par exemple Port2.
• Remote gateway : l’adresse IPv4 externe du peer.
• Local IP et Remote IP : les adresses point à point internes du tunnel GRE.
• Route GRE : affecte un hôte ou un réseau de destination distant au tunnel.
• Règle de pare-feu : autorise le flux de données précis entre les zones et les réseaux.
• Chemin de retour : ramène les paquets de réponse par le tunnel symétrique.

GRE sur IPv4 utilise le protocole IP 47. Il ne s’agit ni de TCP ni d’UDP et il ne faut pas le confondre avec le port 47. Un routeur en amont, un filtre de fournisseur ou une liste de sécurité cloud doit donc pouvoir transporter ce protocole IP entre les deux endpoints externes.

L’état visible Enabled confirme que la configuration GRE est enregistrée et activée. Il ne prouve pas encore que le peer répond, que la route est correcte ou qu’une application fonctionne.

Quand GRE convient et quand IPsec est préférable

GRE est léger et transporte du trafic routé entre deux endpoints définis. Il convient lorsqu’un fournisseur ou une plateforme exige GRE, lorsque seule l’encapsulation est nécessaire ou lorsqu’un chemin underlay fiable est déjà protégé séparément.

GRE ne remplace pas une interconnexion de sites chiffrée. Pour des connexions ordinaires sur Internet public, IPsec route-based constitue généralement un meilleur point de départ. La combinaison de GRE et d’IPsec nécessite une conception distincte testée sur les deux équipements ; cette procédure de base ne crée pas un chemin GRE-over-IPsec non vérifié.

Cet article traite d’un tunnel IPv4 point à point statique. Multicast, PIM-SM, BGP sur GRE et les tunnels anycast propres à un fournisseur sont des extensions possibles, mais ils ne sont planifiés qu’après le fonctionnement du chemin unicast de base.

Planifier la topologie d’exemple

L’exemple relie deux Sophos Firewalls :

• WAN du site A : Port2 avec 192.0.2.10
• LAN du site A : 10.10.10.0/24
• IP de tunnel du site A : 10.255.255.1
• WAN du site B : Port2 avec 198.51.100.20
• LAN du site B : 10.20.20.0/24
• Serveur de test du site B : 10.20.20.10
• IP de tunnel du site B : 10.255.255.2
• Réseau de tunnel : 10.255.255.0/30
• Service de test : HTTPS ou TCP 443

192.0.2.0/24 et 198.51.100.0/24 sont des réseaux de documentation et ne sont pas utilisés en production. Remplacer ensemble les deux adresses WAN, les interfaces, les IP de tunnel, les réseaux LAN et le serveur de test par les valeurs réelles. Les IP de tunnel doivent former un réseau point à point dédié, planifié de manière identique des deux côtés, et ne doivent pas chevaucher des réseaux existants.

L’exemple utilise les noms de tunnel gre_branch sur le site A et gre_hq sur le site B. Les noms sont libres, mais l’API SFOS 22 actuelle les limite à 15 caractères.

Avant la modification, préparer une sauvegarde de configuration, une fenêtre de maintenance et un accès de gestion indépendant pour le rétablissement. Recenser également les routes statiques et SD-WAN, les règles NAT, les règles de pare-feu et les réseaux qui se chevauchent.

Vérifier les prérequis du chemin externe

Les deux endpoints WAN doivent pouvoir se joindre via l’underlay. La conception de base utilise des adresses IPv4 statiques des deux côtés. Si l’adresse WAN locale est attribuée par PPPoE ou DHCP, ne pas poursuivre cette procédure : les anciennes instructions GRE officielles de Sophos excluent les interfaces WAN locales dynamiques, tandis que l’API SFOS 22 actuelle ne documente DDNS que pour Remote Gateway. La prise en charge doit donc être clarifiée pour le build et la connexion concernés.

Avant de configurer le tunnel, vérifier les points suivants :

• L’adresse WAN distante est routée via la passerelle WAN attendue.
• Les routeurs en amont, les fournisseurs et les ACL cloud autorisent le protocole IP 47 entre les deux endpoints.
• Aucun dispositif CGNAT ou NAT dont le comportement GRE n’est pas clarifié n’est présent.
• Les IP internes du tunnel et les réseaux LAN ne se chevauchent ni localement ni à distance.
• Le peer utilise les mêmes valeurs externes et internes en sens inverse.
• Un chemin de retour vers les deux réseaux LAN est planifié.

Un ping vers le peer public peut étayer le test de l’underlay, mais ne prouve pas la prise en charge de GRE. De même, autoriser le port TCP ou UDP 47 ne sert à rien, car GRE n’est pas un protocole de transport basé sur des ports.

Créer le tunnel GRE sur les deux pare-feu

La configuration s’effectue dans le menu CLI 4. Device Console. La page d’aide Sophos actuelle contient des fragments de syntaxe mal affichés. Avant la modification, utiliser Tab ou ? sur le build installé pour confirmer que les paramètres suivants sont proposés.

Configurer le site A

Sur le pare-feu A, saisir le port WAN local Port2, le peer externe 198.51.100.20 et la paire interne du tunnel :

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

Effectuer ensuite ce contrôle en lecture seule :

system gre tunnel show

L’entrée doit afficher correctement gre_branch, Port2, l’adresse WAN distante et les deux IP de tunnel. Ne pas masquer une faute de frappe en créant une seconde configuration portant un nom similaire.

Configurer le site B de manière symétrique

Sur le pare-feu B, inverser les valeurs locales et distantes :

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

Effectuer également le contrôle en lecture seule :

system gre tunnel show

À ce stade, Enabled n’est qu’un contrôle intermédiaire. La validation ne se termine qu’avec un flux de données LAN à LAN réel.

Router les réseaux distants via GRE

Pour le chemin fixe simple, ajouter une route GRE sur chaque pare-feu. Le site A envoie le LAN du site B via gre_branch :

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

Le site B reçoit le chemin de retour symétrique :

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Lire ensuite les affectations configurées sur les deux appareils :

system gre route show

La route ne doit pas entrer en concurrence avec un chemin statique, SD-WAN, VPN ou directement connecté de même longueur ou plus spécifique. Ne pas modifier la Route Precedence globale sur une simple suspicion. Identifier d’abord la route réellement sélectionnée et le chemin des paquets.

Custom Gateway et SD-WAN comme alternative

Certaines conceptions de fournisseur utilisent un Custom Gateway sur le chemin GRE à la place de la route GRE simple et le sélectionnent dans une route SD-WAN. Ce choix convient lorsque Source, Service, le failover ou un état de passerelle défini doivent influencer la décision de routage.

L’IP distante du tunnel est le next hop. Health Check, Zone et Probe Target doivent correspondre à la conception du fournisseur ; une surveillance désactivée dans une documentation constructeur n’est pas une règle universelle. Créer et vérifier un Custom Gateway sur Sophos Firewall explique l’articulation entre l’objet, la sonde et le test de trafic réel. La sélection du chemin est décrite dans Configurer une route SD-WAN sur Sophos Firewall.

Ne pas activer sans contrôle une route GRE et une route SD-WAN pour les mêmes réseaux. Avant le changement, documenter le mécanisme qui doit l’emporter et la procédure de retour au chemin précédent.

Créer des règles de pare-feu sans NAT inutile

Le tunnel GRE et sa route n’autorisent pas encore le trafic applicatif. Une connexion HTTPS initiée depuis le site A nécessite une règle restrictive et journalisée sur les deux pare-feu.

Sur le pare-feu A :

• 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 : activé

Sur le pare-feu B, autoriser le trafic entrant du tunnel vers le serveur de test :

• 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 : activé

Ces deux règles couvrent la connexion initiée depuis le site A et son trafic de retour stateful. Si des hôtes du site B doivent initier de nouvelles connexions vers le site A, créer en plus la paire de règles symétrique de LAN vers VPN sur le pare-feu B et de VPN vers LAN sur le pare-feu A, uniquement avec les réseaux et services réellement nécessaires. Une règle large Any n’est pas nécessaire pour la validation.

Dans une interconnexion de sites normale, l’adresse IP source d’origine est conservée. Ne pas activer MASQ comme correction apparente du routage. Si le chemin de retour manque, corriger la route sur le peer. Créer et vérifier les règles Sophos Firewall en toute sécurité explique la conception générale des règles.

Valider ensemble le tunnel et le trafic applicatif

Le contrôle suit le chemin des paquets et sépare la configuration du fonctionnement réel :

1. Exécuter system gre tunnel show sur les deux pare-feu et comparer les endpoints ainsi que les IP de tunnel.

2. Utiliser system gre route show pour vérifier le LAN distant correspondant et le bon nom de tunnel.

3. Depuis un client de 10.10.10.0/24, lancer une nouvelle connexion HTTPS vers 10.20.20.10.

4. Dans Log viewer sur les deux pare-feu, vérifier Source, Destination, Service, Firewall Rule ID, NAT Rule ID et Zone.

5. Sous Diagnostics > Packet capture sur le site A, filtrer le chemin GRE externe :

   host 198.51.100.20 and ip proto 47
   

6. Filtrer séparément le flux de test interne :

   host 10.20.20.10 and tcp port 443
   

7. Comparer l’entrée et la sortie sur les deux pare-feu et vérifier l’adresse IP source réelle sur le serveur de destination.

8. Effectuer un test de retour uniquement avec un service autorisé à cet effet.

La capture externe montre l’encapsulation entre les endpoints WAN. La capture interne et la Rule ID montrent si le paquet utile suit la règle et la route attendues. Seule l’application fonctionnelle confirme le chemin complet. La procédure combinée est détaillée dans Tester les règles de pare-feu et Utiliser Packet Capture.

Délimiter les erreurs par symptôme

Aucun paquet GRE ne quitte l’interface WAN

• Vérifier Remote Gateway et le local-gw local dans le tunnel.
• Vérifier la route underlay vers l’adresse WAN distante et la passerelle WAN sélectionnée.
• S’assurer que le flux de test correspond réellement à la route GRE ou à la route SD-WAN prévue.
• Comparer les noms et les affectations avec system gre tunnel show et system gre route show.
• Ne pas créer de règle de port TCP ou UDP pour remplacer le protocole IP 47.

GRE quitte le site A mais n’atteint pas le site B

• Vérifier le protocole IP 47 auprès des fournisseurs, des routeurs en amont, des ACL cloud et des éventuels chemins NAT.
• Effectuer simultanément une capture sur le site B avec le filtre WAN externe.
• Comparer les adresses source et destination externes à la configuration du peer.
• Avec un WAN dynamique, CGNAT ou une conception NAT non clarifiée, s’arrêter au lieu de masquer le problème avec des règles larges.

GRE est visible sur les deux côtés WAN, mais le trafic interne manque

• Local IP et Remote IP doivent être inversées symétriquement sur les deux pare-feu.
• Comparer caractère par caractère la route GRE, le réseau de destination et le nom du tunnel.
• Vérifier la règle de pare-feu et la Rule ID attendue des deux côtés.
• Exclure les chevauchements de réseaux, NAT et l’absence de chemin de retour.
• Ne pas considérer Enabled comme une preuve de la route interne ou de l’application.

Une seule direction fonctionne

• Vérifier la route GRE du réseau de retour sur le site B.
• Déterminer si le site B doit initier de nouvelles connexions et nécessite donc sa propre règle de pare-feu.
• Vérifier la passerelle par défaut, le pare-feu local de l’hôte et l’adresse IP source réelle sur le serveur de destination.
• Comparer les routes SD-WAN ou statiques asymétriques des deux côtés.

Les petits paquets fonctionnent, mais les grandes connexions se bloquent

GRE ajoute un en-tête IP externe et un en-tête GRE. Cela réduit la taille de paquet utilisable par rapport à l’underlay. Ne pas adopter une valeur MTU ou MSS fixe sans vérification : mesurer d’abord la MTU underlay, Path MTU Discovery, la fragmentation et l’application concernée. Vérifier MTU et MSS lors de problèmes VPN explique la procédure contrôlée.

Tester HA et l’exploitation avec prudence

La documentation publique actuelle de Sophos ne promet ni failover HA sans interruption ni synchronisation de l’état du tunnel pour GRE. Un changement de rôle contrôlé s’effectue donc uniquement dans une fenêtre de maintenance avec un accès de gestion indépendant.

Après le changement, vérifier à nouveau system gre tunnel show, system gre route show, la capture GRE externe, une nouvelle connexion client, la Rule ID et le chemin de retour. Une connexion TCP existante ne constitue pas une preuve de continuité.

Pour l’exploitation, documenter le responsable, les deux endpoints WAN, les IP de tunnel, les noms des tunnels, les réseaux distants, le mécanisme de routage, les règles de pare-feu, la limite MTU attendue et le dernier test de trafic réel. Après des modifications du WAN, du fournisseur, de NAT, de SD-WAN, de Route Precedence ou du peer, valider à nouveau le chemin complet.

Revenir en arrière en toute sécurité

Coordonner le retour arrière sur les deux pare-feu :

1. Arrêter le trafic de test et enregistrer le dernier état avec system gre tunnel show et system gre route show.

2. Désactiver les nouvelles règles de pare-feu et toute route SD-WAN créée pour le test.

3. Le cas échéant, retirer le Custom Gateway du chemin uniquement après avoir vérifié Object usage.

4. Sur le site A, supprimer la route GRE précise :

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. Sur le site B, supprimer la route de retour :

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Utiliser system gre route show pour vérifier que seules les entrées prévues ont disparu.

7. Supprimer ensuite le tunnel du site A par son nom exact :

   system gre tunnel del name gre_branch
   

8. Sur le site B, supprimer uniquement le tunnel configuré sur ce site :

   system gre tunnel del name gre_hq
   

9. Terminer par system gre tunnel show et un test de l’ancien chemin de routage.

Ne pas utiliser del All. Si la syntaxe ou le nom d’un objet n’est pas clair sur le build installé, le vérifier avec Tab ou ? avant toute suppression et ne pas deviner.

Questions fréquentes