Prise en charge et limites d'IPv6 sur Sophos Firewall avec SFOS 22
Sophos Firewall prend en charge IPv6 dans SFOS 22 pour les principales fonctions de réseau, de routage, de VPN, de règles, de protection et de diagnostic. Un fonctionnement entièrement IPv6-only n’est toutefois pas réaliste dans tous les environnements. Les règles WAF, la résolution IPv6 dans les objets hôte FQDN, la fonction Let’s Encrypt intégrée, Up2date, RED, l’accès distant IPsec, RIPng et le multicast présentent des limites documentées.
Avant un déploiement, il ne suffit donc pas de vérifier qu’une interface reçoit une adresse IPv6. Il faut déterminer si chaque fonction du chemin réel de bout en bout prend en charge IPv6. Lorsqu’une fonction requise manque, Dual Stack ou un chemin IPv4 délibérément planifié est généralement plus sûr qu’une architecture IPv6-only forcée.
Cet article replace dans son contexte opérationnel la matrice officielle de prise en charge d’IPv6 dans SFOS 22. La configuration détaillée de Prefix Delegation, du routage, des VPN et des règles reste dans les articles spécialisés liés.
Vérifier une conception IPv6 en sept étapes
- Documenter le build SFOS exact, la connexion du fournisseur, le préfixe et tous les services nécessaires.
- Décomposer le chemin complet du client ou de l’émetteur jusqu’à la destination en fonctions distinctes : interface, adressage, DNS, routage, règle, module de protection, VPN, portail et chemin de mise à jour.
- Vérifier chaque fonction par rapport aux limites de SFOS 22 décrites dans cet article.
- Définir un chemin IPv4 ou une solution produit alternative pour les dépendances non prises en charge. Ne pas contourner une fonction absente avec une règle large ou
Any. - Configurer les interfaces IPv6, Router Advertisement, routes, objets et règles de pare-feu séparément d’IPv4.
- Tester successivement l’adresse, Default Route, Neighbor Discovery, DNS, Route Lookup, Rule ID, Packet Capture et le service réel.
- Ne basculer en production qu’après des tests positif et négatif concluants ; conserver jusque-là le fallback IPv4 et l’ordre précédent des règles.
⚠️ Une coche dans la matrice Sophos confirme la prise en charge par le produit, pas une configuration terminée ni une équivalence fonctionnelle avec IPv4. Un ping IPv6 réussi ne prouve ni DNS, ni policy, ni profil de protection, ni VPN, ni application. Inversement, une fonction documentée comme non prise en charge ne le devient pas après un redémarrage de service, l’emploi d’options CLI cachées ou l’élargissement d’une règle de pare-feu.
Ce que signifie réellement la matrice de prise en charge
La page Sophos actuelle a été mise à jour le 8 janvier 2026 et s’applique à l’aide de SFOS 22. Elle distingue les fonctions capables de traiter IPv6 de celles qui ne prennent toujours pas IPv6 en charge. Cette limite est plus stricte que l’affirmation générale selon laquelle le pare-feu prend en charge IPv6.
Quatre niveaux doivent rester distincts :
- Adressage : L’interface possède un préfixe IPv6 et le client une adresse correspondante.
- Routage : Les chemins aller et retour pointent vers les interfaces et gateways attendus.
- Policy : Une règle IPv6 dédiée autorise exactement le trafic prévu et journalise le test.
- Service : Le VPN, WAF, proxy, service de messagerie, portail ou mécanisme de mise à jour prend réellement en charge le chemin IPv6.
Le fonctionnement d’un niveau ne prouve pas celui du suivant. Cette séparation évite de considérer un état d’interface vert comme la preuve d’une fonction WAF ou de mise à jour qui n’est pas encore prise en charge.
Réseau et adressage
Pris en charge
- adresses IPv6 statiques sur les interfaces physiques, bridge, alias, VLAN et LAG ;
- DHCP Prefix Delegation ;
- serveur, client et relais DHCPv6, ainsi que les leases dynamiques et statiques ;
- Neighbor Discovery Protocol (NDP) et Router Advertisement ;
- DNS Lookup et Reverse Name Lookup ;
- tunnels IPv6 6in4, 6to4, 6rd et 4in6.
Non pris en charge ou limité
- IPv6 sur Cellular WAN ;
- IPv6 PPPoE ;
- Dynamic DNS sur IPv6 ;
- DNS64 ;
- Tunnel Broker ;
- matériel RED et tunnels Firewall RED entre deux Sophos Firewalls ;
- DHCP Prefix Delegation sur une interface LAG.
Le guide Prefix Delegation décrit le chemin exécutable depuis le préfixe du fournisseur, via l’interface interne, jusqu’à Router Advertisement et aux règles de pare-feu : Configurer IPv6 Prefix Delegation sur Sophos Firewall. Pour les préfixes statiques, la planification des interfaces, VLAN et zones de Planifier correctement les zones et interfaces de Sophos Firewall reste pertinente.
DNS64 et NAT64 ne doivent pas être confondus. SFOS 22 indique que DNS64 n’est pas pris en charge. En revanche, le chemin NAT64 documenté par Sophos est fourni par Direct Web Proxy, uniquement pour le trafic proxy HTTP/HTTPS explicite. Il ne s’agit pas d’une passerelle générale pour les protocoles.
Routage et multicast
Pris en charge
- routes unicast IPv6 statiques ;
- routes SD-WAN pour IPv6 ;
- BGP IPv6 et OSPFv3 ;
- WAN Load Balancing ;
- Upstream Proxy.
Non pris en charge
- RIPng ;
- multicast IPv6 dynamique avec Multicast Listener Discovery (MLD) ;
- routes multicast IPv6 statiques.
Une route IPv4 ne devient pas automatiquement une route IPv6. La procédure pour les réseaux fixes se trouve sous Configurer des routes IPv4 et IPv6 statiques. OSPFv3 se configure séparément d’OSPFv2, tandis que la Router ID reste en notation IPv4. La procédure sûre et l’absence d’authentification OSPFv3 sont décrites dans Configurer et vérifier OSPF sur Sophos Firewall.
Les articles Avanet existants sur le multicast statique et PIM-SM traitent d’IPv4. Leurs commandes et menus ne permettent pas de déduire une procédure MLD ou multicast IPv6.
VPN
Pris en charge
- SSL VPN site-to-site ;
- SSL VPN d’accès distant ;
- IPsec site-to-site.
Non pris en charge
- IPsec d’accès distant sur IPv6 ;
- L2TP VPN sur IPv6 ;
- PPTP VPN sur IPv6.
Pour IPsec site-to-site, la connexion peut utiliser IPv4, IPv6 ou Dual avec une connexion route-based Any-to-Any. Dual exige des règles de pare-feu IPv4 et IPv6 distinctes et un chemin de routage planifié. Le choix complet du type de tunnel se trouve dans Configurer un VPN IPsec site-to-site sur Sophos Firewall.
L’affirmation le SSL VPN d’accès distant prend en charge IPv6 ne signifie pas que chaque ressource, objet FQDN et chemin full-tunnel fonctionne automatiquement en Dual Stack. Le pool, les ressources autorisées, DNS, les règles IPv6 et le test réel du client restent des contrôles distincts.
Règles, NAT et modules de protection
Pris en charge
- règles de pare-feu IPv6 basées sur les zones ;
- NAT66 et NAT64, NAT64 étant uniquement disponible en Proxy Mode ;
- Server Load Balancing ;
- SSL/TLS Inspection Rules ;
- IPS, DoS Bypass Rules et Spoof Protection ;
- Web Filtering, Application Filter et Malware Scanning ;
- Zero-day Protection.
Non pris en charge
- règles WAF sur IPv6 ;
- Wireless comme chemin de protection IPv6 ;
- la fonction nommée séparément Advanced protection dans la matrice Sophos.
Une règle de pare-feu IPv4 n’autorise pas le trafic IPv6. Dans Rules and policies > Firewall rules, sélectionner consciemment la version IP et valider la règle avec Source, Destination, Service, Logging et Rule ID. Les principes sont décrits dans Comprendre et configurer en toute sécurité les règles de Sophos Firewall.
Pour des clients IPv6-only accédant à une destination web IPv4-only, utiliser la procédure proxy séparée NAT64 avec Direct Web Proxy. Elle ne traduit ni le trafic non-proxy, ni UDP, ni ICMP, ni les applications sans prise en charge explicite du proxy.
Messagerie, portails et administration
Pris en charge
- SMTP MTA et SMTP Proxy ;
- IMAP Proxy et POP Proxy ;
- WebAdmin, User Portal et SSH ;
- NTP et SNMP ;
- Authentication Server.
Non pris en charge
- Quarantine Digest sur IPv6.
La prise en charge d’IPv6 pour WebAdmin ou SSH n’est pas une recommandation d’exposer ces services à Internet. Device Access et Local Service ACL restent strictement limités au réseau d’administration ou à des réseaux sources connus. Le pilote IPv6 doit aussi confirmer par un test négatif que les sources d’administration non prévues n’obtiennent aucun accès.
Diagnostic, objets, mises à jour et certificats
Pris en charge
- Current Activities pour les utilisateurs et les connexions ;
- Ping, Traceroute, Name Lookup, Route Lookup et Packet Capture ;
- Syslog et Reporting ;
- IPv6 IP Hosts ;
- Traffic Shaping et QoS.
Non pris en charge ou limité
- Policy Tester pour IPv6 ;
- Country Hosts pour IPv6 ;
- résolution IPv6 dans les objets hôte FQDN ;
- Up2date Infrastructure sur IPv6 ;
- fonction Let’s Encrypt intégrée sur IPv6.
La limite FQDN concerne l’objet hôte SFOS : le pare-feu ne résout aucune adresse IPv6 pour cet objet. Cela ne signifie pas que les clients DNS ou Name lookup ne reçoivent jamais de réponses AAAA. Toutefois, une destination IPv6 dynamique ne doit pas reposer sur un objet hôte FQDN comme si SFOS maintenait automatiquement ses adresses AAAA.
La limite Let’s Encrypt est également propre au produit. Elle ne signifie pas qu’ACME ou les certificats sont généralement IPv4-only. Elle signifie que la fonction intégrée de SFOS ne doit pas être planifiée comme chemin IPv6. Un chemin IPv4 fonctionnel reste donc nécessaire pour l’émission, le renouvellement et Up2date tant que Sophos documente ces limites.
Exemple de pilote Dual Stack contrôlé
L’exemple sépare les valeurs de production des valeurs à remplacer :
- préfixe du fournisseur :
2001:db8:100::/48 - réseau de test interne :
2001:db8:20:30::/64 - pare-feu dans le réseau de test :
2001:db8:20:30::1 - client pilote :
2001:db8:20:30::50 - destination de test contrôlée :
2001:db8:40:50::20 - le chemin de retour IPv4 pour l’administration, Up2date et Let’s Encrypt reste initialement en place.
2001:db8::/32 est un préfixe de documentation et n’est pas routé sur Internet en production. Remplacer toutes les adresses par le préfixe réel du fournisseur et des systèmes de test contrôlés. Le /64 est le réseau d’exemple prévu pour un segment client normal ; la répartition réelle du préfixe dépend de la délégation du fournisseur et du plan de réseau interne.
Avant le pilote, ces décisions doivent être prises :
- Quelles fonctions le flux concerné utilise-t-il ?
- Sont-elles toutes répertoriées comme prises en charge dans la matrice SFOS ?
- Existe-t-il un fallback IPv4 pour les mises à jour, les certificats et l’administration ?
- Quelle règle IPv6 doit correspondre et quelle Rule ID est attendue ?
- Quelle connexion négative doit rester bloquée ?
- Comment tester DNS, le chemin de retour et le service applicatif réel ?
Valider le chemin IPv6
Une validation fiable progresse de bas en haut :
- Interface : Vérifier l’adresse IPv6 et le préfixe attendus sur les interfaces WAN et interne.
- Client : Contrôler l’adresse IPv6, Prefix Length et Default Route.
- Neighbor Discovery : Sous Network > Neighbors (ARP–NDP), vérifier le voisin IPv6 attendu et l’interface correcte. L’interprétation sûre est expliquée dans Vérifier le cache de voisins ARP et NDP.
- DNS : Vérifier séparément les réponses A et AAAA. Un enregistrement A fonctionnel ne prouve pas le chemin IPv6.
- Routage : Utiliser Diagnostics > Tools > Route lookup avec l’adresse IPv6 réelle de destination et documenter les chemins aller et retour.
- Policy : Dans Log Viewer, confirmer la règle IPv6 attendue, Action et Firewall Rule ID. Comme Policy Tester ne prend pas IPv6 en charge, Log Viewer, Route Lookup, Packet Capture et le flux de test réel sont plus importants.
- Flux de paquets : Packet Capture doit montrer l’entrée et la sortie par l’interface attendue. Un paquet visible à l’entrée sans transfert limite la recherche au routage, à la règle ou à un module de protection.
- Service : Tester positivement HTTPS, VPN, SMTP, DNS ou l’application concernée ; un ping seul ne suffit pas.
- Test négatif : Une source IPv6 non autorisée ou un service non approuvé reste bloqué.
Les commandes Device Console en lecture seule pour un chemin d’exemple contrôlé sont :
ping6 2001:db8:40:50::20
traceroute6 2001:db8:40:50::20
dnslookup6 app.example.com
L’adresse de documentation et .example ne fonctionnent pas en production et doivent être remplacées par une destination contrôlée. Ces commandes testent l’accessibilité, le chemin et la résolution de noms, mais pas une règle de pare-feu précise ni l’application. D’autres commandes de base sûres sont décrites dans Dépanner Sophos Firewall avec des commandes de base.
Diagnostiquer selon le symptôme
Le client ne reçoit aucune adresse IPv6 ni Default Route
Vérifier le préfixe du fournisseur, l’affectation WAN, Delegated Interface, Router Advertisement, le VLAN et le segment client. Ne pas poursuivre les essais de Prefix Delegation sur un LAG, car Sophos exclut explicitement cette combinaison. Le fonctionnement d’IPv4 ne prouve pas que l’adressage IPv6 est correct.
Une adresse IPv6 est présente, mais le service ne fonctionne pas
Vérifier d’abord la réponse DNS, NDP, Route Lookup, la règle IPv6, Rule ID et le chemin de retour. Examiner ensuite le service lui-même. Ne pas créer une règle large Any comme substitut au diagnostic. Si la fonction requise n’est pas prise en charge dans la matrice, déplacer le chemin vers IPv4 ou une autre architecture.
L’objet hôte FQDN ne contient aucune adresse IPv6
Il s’agit de la limite documentée du produit. Les objets hôte FQDN de SFOS ne résolvent pas les adresses IPv6. Un IPv6 IP Host statique peut convenir à une adresse stable maintenue en exploitation ; une destination dynamique nécessite une nouvelle décision de conception. Un objet de destination large n’est pas une solution de remplacement sûre.
WAF, RED ou l’accès distant IPsec doit fonctionner sur IPv6
Ces cas ne sont pas pris en charge dans la matrice actuelle. Arrêter le déploiement avant de reconstruire en production des règles, certificats ou tunnels. Conserver IPv4 pour cette fonction ou choisir un chemin d’accès distinct pris en charge.
Les mises à jour ou Let’s Encrypt échouent dans un réseau IPv6-only
D’après la matrice, Up2date Infrastructure et la fonction Let’s Encrypt intégrée ne sont pas pris en charge sur IPv6. Restaurer d’abord la sortie IPv4 prévue, DNS, le routage et les règles. Les redémarrages de services et les nouvelles demandes de certificat ne corrigent pas une absence de prise en charge par le produit.
Rollback
- Désactiver les nouvelles règles IPv6 ou restaurer l’ordre précédent documenté.
- Retirer Router Advertisement, Delegated Interface ou l’affectation IPv6 statique du pilote uniquement pendant la fenêtre de maintenance planifiée.
- Conserver ou restaurer les routes IPv4, réponses DNS et accès d’administration précédents.
- Supprimer les objets hôte IPv6 et règles de test temporaires uniquement après avoir confirmé le chemin de retour.
- Revérifier l’administration IPv4, Up2date, le renouvellement de certificat et le service d’origine.
- Conserver l’heure de l’erreur, le build, l’interface, Route Lookup, Rule ID et Packet Capture avant d’ouvrir un dossier de support pour un chemin IPv6 toujours pris en charge.
Checklist
- Version et build SFOS documentés.
- Chaque fonction requise vérifiée dans la matrice de prise en charge IPv6 actuelle.
- Les dépendances non prises en charge disposent d’un chemin IPv4 ou alternatif planifié.
- Préfixe, segments
/64, Router Advertisement et DNS planifiés. - Règles IPv4 et IPv6 créées et journalisées séparément.
- Device Access n’a pas été élargi involontairement par IPv6.
- NDP, Route Lookup, Rule ID, Packet Capture et service réel vérifiés.
- Tests positif et négatif réussis.
- Up2date et Let’s Encrypt disposent toujours d’un chemin IPv4 fonctionnel.
- Rollback et accès d’administration indépendant documentés.