Configurer un tunnel IP Sophos Firewall avec 6in4, 6to4, 6rd ou 4in6

Sous Network > IP tunnels, Sophos Firewall crée des tunnels qui encapsulent un protocole réseau dans un autre. IPv6 peut ainsi traverser une infrastructure IPv4, ou IPv4 une infrastructure IPv6. SFOS propose 6in4, 6to4, 6rd et 4in6 pour ces scénarios.

Cette fonction n’est ni le tunnel GRE de Device Console ni un VPN IPsec. Un tunnel IP encapsule les paquets, mais ne les chiffre pas et ne les authentifie pas automatiquement.

⚠️ Un tunnel IP ne doit traverser une infrastructure non fiable que si le design de sécurité accepte explicitement l’absence de confidentialité et d’authentification du peer. Pour une interconnexion de sites protégée, IPsec site-à-site constitue généralement un meilleur point de départ.

Quel type de tunnel choisir ?

Les quatre types ne répondent pas au même besoin :

• 6in4 relie deux réseaux IPv6 à travers un backbone IPv4. Les endpoints IPv4 local et distant sont configurés manuellement. Sophos recommande ce type pour une liaison point à point.
• 6to4 transporte IPv6 sur IPv4 et vise les designs point à multipoint. La source IPv4 locale est définie manuellement, tandis que l’adresse de destination peut être obtenue automatiquement.
• 6rd étend 6to4 avec un préfixe fourni par l’opérateur. Ce type ne convient que si le FAI fournit les valeurs 6rd nécessaires.
• 4in6 relie deux réseaux IPv4 à travers un backbone IPv6. Les endpoints externes local et distant sont des adresses IPv6, et ce type vise une liaison point à point.

Pour un lien contrôlé avec des endpoints fixes, 6in4 ou 4in6 est plus facile à comprendre. Il ne faut pas choisir 6to4 ou 6rd uniquement parce que SFOS peut créer automatiquement une route. Le plan d’adressage et le design de l’opérateur doivent correspondre exactement à ce mécanisme.

La prise en charge d’IPv6 sur Sophos Firewall résume les limites IPv6 de SFOS. À l’inverse, un tunnel GRE transporte du trafic IP routé via une procédure Device Console distincte et n’est pas interchangeable avec ces quatre types WebAdmin.

Planifier l’exemple et les prérequis

L’exemple utilise un tunnel 6in4 statique entre deux sites :

• Nom affiché : HQ-IPv6-via-IPv4
• Hardware name : v6hq01
• Adresse WAN IPv4 locale : 192.0.2.10
• Endpoint IPv4 distant : 198.51.100.20
• Réseau IPv6 local : 2001:db8:100::/64
• Réseau IPv6 distant : 2001:db8:200::/64
• Serveur de test : 2001:db8:200::20
• Zone de l’interface de tunnel : VPN dans l’exemple

192.0.2.0/24, 198.51.100.0/24 et 2001:db8::/32 sont des plages de documentation. Elles doivent être remplacées, comme les noms, la zone et les préfixes, par les valeurs réelles. La zone VPN est un choix d’exemple compréhensible, pas une exigence du produit. Le modèle de zones, les règles de pare-feu et Device Access doivent surtout correspondre à l’architecture réelle.

Les deux endpoints externes doivent être joignables via l’infrastructure avant la création du tunnel. Chaque côté nécessite un tunnel en miroir, des réseaux internes uniques, un chemin retour et une règle de pare-feu pour le trafic applicatif réel. Des préfixes qui se chevauchent, une valeur opérateur manquante pour 6rd ou une configuration inconnue du peer sont des conditions d’arrêt.

Une sauvegarde, une fenêtre de maintenance et un accès de gestion indépendant font aussi partie du plan de retour. Le tunnel ne doit pas servir d’essai sur l’unique connexion de production.

Créer le tunnel IP dans WebAdmin

Sous Network > IP tunnels > Add, il faut d’abord définir l’identité et le type du tunnel, puis les endpoints et les valeurs IP avancées.

Distinguer Name et Hardware name

Le Name normal peut contenir jusqu’à 58 caractères et être modifié ultérieurement. Il doit identifier l’usage et le peer, par exemple HQ-IPv6-via-IPv4.

Le Hardware name est technique et ne peut plus être modifié après l’enregistrement. Il contient au maximum dix caractères et uniquement A-Z, a-z, 0-9 et _. SFOS bloque aussi de nombreux noms et fragments système, notamment gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN et Halink. La valeur neutre v6hq01 évite ces conflits.

Un Hardware name incorrect ne peut pas être renommé par la suite. Il faut documenter ses dépendances et recréer le tunnel de façon contrôlée. Cette valeur doit donc être contrôlée avec une attention particulière avant Save.

Définir le type, la zone et les endpoints

Pour l’exemple, sélectionner 6in4. Définir la zone de sécurité prévue sous Zone. Saisir 192.0.2.10 sous Local endpoint et 198.51.100.20 sous Remote endpoint.

La famille d’adresses dépend du type. Pour 6in4, 6to4 et 6rd, l’endpoint externe local est en IPv4 ; 6in4 possède aussi un endpoint IPv4 distant fixe. Pour 4in6, les endpoints externes local et distant sont des adresses IPv6. Une route de destination interne ne se place pas dans un champ d’endpoint.

Dans les paramètres avancés, TTL influence la durée de vie des paquets encapsulés dans l’infrastructure. TOS attribue au paquet IP externe une valeur de type de service destinée à la priorité et au comportement de routage. L’aide actuelle ne prescrit aucune valeur optimale universelle. Les deux champs restent donc à leur valeur initiale documentée tant qu’un problème de routage ou de QoS mesuré ne justifie pas un changement.

Après Save, SFOS confirme la création et ouvre la boîte de dialogue des routes. Pour 6to4 et 6rd, le pare-feu crée aussi automatiquement une route unicast IPv6 statique. Important : fermer cette fenêtre ou sélectionner Cancel ne supprime ni le tunnel ni les routes créées automatiquement.

Ajouter les routes et les règles de pare-feu

Un tunnel enregistré ne constitue pas encore un chemin de données fonctionnel. Pour 6in4, ajouter une route IPv6 statique vers le préfixe distant 2001:db8:200::/64 via la nouvelle interface de tunnel. Le peer a besoin du chemin retour en miroir vers 2001:db8:100::/64.

Pour 4in6, la route interne mène à un réseau de destination IPv4. Pour 6to4 et 6rd, lire la route IPv6 créée automatiquement et la comparer au design de l’opérateur avant d’ajouter d’autres routes. Cancel dans la première boîte de dialogue des routes ne constitue pas un rollback.

Les routes supplémentaires se créent sous Routing > Static routes. Les routes statiques sur Sophos Firewall expliquent comment le préfixe de destination, l’interface, la distance, la décision de routage et un test réel s’articulent.

Créer ensuite une règle de pare-feu précise et journalisée entre les zones concernées, avec les véritables valeurs de source, destination et service. Pour une liaison de sites normale, conserver l’adresse source d’origine ; ne pas activer MASQ pour compenser un chemin retour absent. La procédure est décrite dans Configurer les règles Sophos Firewall en toute sécurité.

Valider le tunnel et le trafic applicatif

La validation distingue la configuration enregistrée, l’encapsulation externe et l’application interne :

1. Sous Network > IP tunnels, comparer Name, Hardware name, type, Zone et endpoints avec le peer.
2. Sous Routing > Static routes, vérifier que le préfixe interne distant pointe vers l’interface de tunnel attendue.
3. Exécuter Route Lookup pour le serveur de test interne et confirmer l’interface attendue.
4. Depuis le client de test local, lancer une nouvelle connexion vers 2001:db8:200::20 avec un service explicitement autorisé.
5. Dans Log Viewer, contrôler Source, Destination, Service, Action et Firewall Rule ID.
6. Avec Packet Capture, observer d’abord les endpoints externes, puis l’adresse de test interne.
7. Sur le peer, vérifier l’entrée, la décapsulation, la route retour et l’adresse source réelle.
8. Répéter le test dans le sens opposé uniquement avec une règle prévue pour ce sens.

Une entrée de tunnel verte ou visible ne prouve ni la route ni le fonctionnement du peer. Une route créée automatiquement ne prouve pas non plus que l’opérateur, les équipements intermédiaires et les règles transportent effectivement l’encapsulation. Packet Capture sur Sophos Firewall explique la capture contrôlée.

Rechercher la panne par symptôme

Impossible d’enregistrer le tunnel

Contrôler séparément Name et Hardware name. Hardware name comporte au maximum dix caractères, uniquement les caractères autorisés et aucun terme système bloqué. Vérifier ensuite que le type de tunnel et la famille d’adresses des endpoints local et distant correspondent.

Un nom affiché différent ne corrige pas un Hardware name non valide. Si une autre interface utilise déjà cette valeur, planifier un nom technique unique plutôt que d’essayer plusieurs suffixes aléatoires.

Le tunnel existe, mais aucune route ne mène au réseau de destination

Pour 6in4 et 4in6, ajouter explicitement la route statique nécessaire. Pour 6to4 et 6rd, vérifier que SFOS a créé la route unicast IPv6 attendue et que son préfixe correspond au design. Une fenêtre précédemment fermée avec Cancel ne supprime pas la configuration enregistrée automatiquement.

Route Lookup et la table de routage apportent la preuve suivante. Ne pas modifier Route Precedence globalement sur la base d’un soupçon et ne pas ajouter de route blackhole ou fictive concurrente pour tester.

Les paquets externes sont visibles, mais le trafic interne manque

Le type du peer, les adresses d’endpoint, le préfixe interne ou la route retour sont souvent incohérents. Comparer les deux configurations en miroir, puis vérifier la règle de pare-feu, la Firewall Rule ID attendue et une capture des adresses source et destination internes.

Une encapsulation fonctionnelle ne prouve pas que le trafic applicatif est autorisé. Inversement, l’absence de Rule ID peut signifier que le paquet interne n’a jamais été décapsulé ou qu’une autre route l’a traité.

Les petits paquets passent, mais les applications se bloquent

L’encapsulation IP externe supplémentaire réduit la taille de paquet utilisable par rapport à l’infrastructure. Au lieu de reprendre une valeur MTU étrangère au chemin, mesurer Path MTU, la fragmentation et l’application concernée. La procédure contrôlée de vérification de MTU et MSS pour les problèmes de tunnel convient aussi à cette analyse, sans reprendre des valeurs IPsec fixes pour le tunnel IP.

HA, modifications et rollback

Les deux pages d’aide SFOS 22 ne promettent pas un état HA ininterrompu pour ces tunnels IP. Après un changement de rôle planifié, contrôler à nouveau l’entrée du tunnel, Route Lookup, l’encapsulation externe, Firewall Rule ID et une nouvelle session applicative. Une connexion existante ne prouve pas la continuité.

Avant toute modification, documenter Name, le Hardware name immuable, le type, Zone, les endpoints, les routes créées automatiquement et manuellement, les règles et le dernier test réel. Il devient alors possible de distinguer une modification de configuration d’un changement de chemin de données.

Pour le rollback, arrêter d’abord le trafic de test. Désactiver de façon contrôlée les règles et routes manuelles dépendantes, ou restaurer leur état précédent confirmé. Contrôler explicitement les routes automatiques de 6to4 ou 6rd. Supprimer le tunnel uniquement lorsqu’il ne reste aucune dépendance de production. Enfin, vérifier à nouveau l’ancien chemin de routage et un flux connu.

Liste de contrôle

• Le type choisi correspond aux familles d’adresses interne et externe.
• Les deux endpoints et les préfixes sont convenus avec le peer.
• Le nom affiché et le Hardware name immuable sont documentés.
• Zone, route statique et chemin retour correspondent au design de sécurité.
• Les routes automatiques de 6to4 ou 6rd ont été contrôlées.
• Une règle précise correspond à la Firewall Rule ID attendue.
• L’encapsulation externe et le trafic interne ont été testés séparément.
• MTU, HA et rollback ont été validés sur le chemin réel.

Questions fréquentes