Configurer NAT64 sur Sophos Firewall avec Direct Web Proxy

Un client IPv6-only peut accéder, via le Direct Web Proxy de Sophos Firewall, à un site web qui ne possède qu’une adresse IPv4. SFOS résout le nom de destination dans le proxy et établit la connexion suivante en IPv4. Deux règles firewall sont nécessaires : une règle IPv6 du client vers le proxy et une règle IPv4 du proxy vers la destination.

Il ne s’agit pas d’un NAT64 général de couche 3 pour des protocoles quelconques. Ce mécanisme fonctionne uniquement pour les connexions HTTP et HTTPS que les navigateurs ou les applications envoient explicitement au proxy web. Ce déroulement ne crée aucune règle NAT64 normale sous Rules and policies > NAT rules.

La classification complète se trouve dans Prise en charge et limites d’IPv6 sur Sophos Firewall avec SFOS 22. SFOS prend en charge ce chemin NAT64 basé sur le proxy, mais indique que DNS64 n’est pas pris en charge ; cela ne crée aucune transition générale pour d’autres protocoles.

⚠️ Les deux règles remplissent des rôles différents. Pour les endpoints IPv6-only, la Web Policy et l’association des utilisateurs appartiennent à la règle IPv6. Application Control, IPS et les autres fonctions de protection de la connexion IPv4 sortante appartiennent à la règle IPv4. Une seule règle large ne rend pas cette séparation fiable et visible.

NAT64 via le proxy en huit étapes

Choisir un client pilote IPv6-only administré et une destination web A-only contrôlée.
Vérifier l’adresse IPv6, le DNS, le FQDN du proxy et le listener TCP du Direct Web Proxy.
Préparer la configuration de base du Direct Web Proxy, de Device Access et du fichier PAC ou de la politique du navigateur.
Dans la vue IPv6, créer une règle journalisée du réseau pilote vers le port du proxy avec la zone de destination WAN.
Définir la Web Policy et, si nécessaire, Match known users dans cette règle IPv6.
Dans la vue IPv4, créer une seconde règle journalisée du proxy vers la destination IPv4 avec HTTP/HTTPS.
Tester avec une destination sans enregistrement AAAA et contrôler les deux Firewall Rule IDs ainsi que la décision du filtre web.
Ajouter d’autres clients uniquement après des tests positifs et négatifs ; valider séparément le rollback, HA et SD-WAN.

Pourquoi deux règles firewall sont nécessaires

Le chemin de données change de version IP au niveau du proxy :

Le client se connecte en IPv6 au listener proxy du firewall.
La règle IPv6 évalue le client, l’utilisateur, le nom de destination, le port proxy et la Web Policy.
Le proxy résout le nom d’hôte demandé.
Si la destination ne possède qu’un enregistrement A, le proxy crée une nouvelle connexion IPv4.
La règle IPv4 évalue ce second segment et applique, par exemple, Application Control ou IPS.

La seconde connexion n’est plus le paquet IPv6 d’origine du client. La règle IPv4 ne doit donc pas être conçue comme si l’adresse IPv6 du client devait y apparaître comme source. Par ailleurs, une règle IPv6 réussie ne prouve pas à elle seule que le proxy peut réellement atteindre la destination IPv4.

Sophos désigne cette architecture comme un scénario NAT64. Contrairement à une gateway NAT64 classique, aucun préfixe IPv6 n’est cependant routé vers des destinations IPv4 quelconques. Ce déroulement ne traduit pas les applications sans prise en charge d’un proxy explicite, UDP, ICMP ni les autres trafics qui ne passent pas par le proxy.

Configurer Direct Web Proxy avec un fichier PAC explique la configuration générale du listener, du PAC, de Device Access et du rollback. Cet article suppose que le chemin de base du proxy fonctionne et ajoute uniquement la transition d’IPv6 vers IPv4.

Exemple et valeurs à remplacer

Le déroulement utilise un petit pilote :

Client IPv6-only : CLIENT6-PROXY-01
Réseau pilote : 2001:db8:20:30::/64
Adresse IPv6 du firewall dans le réseau client : 2001:db8:20:30::1
FQDN du proxy : fw01.corp.example
Port du proxy : TCP 3128
Destination A-only contrôlée : v4-test.corp.example
Adresse de destination de documentation : 192.0.2.80
Règle IPv6 : LAN6_DirectProxy_to_IPv4
Règle IPv4 : Proxy_IPv4_Egress_Pilot
Web Policy : Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24 et .example sont des plages de documentation. Elles ne fonctionnent pas comme adresses de production et doivent être remplacées par le préfixe IPv6 de l’organisation, l’adresse réelle du firewall et un nom DNS contrôlé. Le client pilote doit réellement utiliser IPv6 uniquement ; un chemin IPv4 actif en parallèle invaliderait le test.

La destination de test doit posséder un enregistrement A, mais aucun enregistrement AAAA. Un petit serveur web interne ou un hôte virtuel de test contrôlé convient le mieux. Un site web public choisi au hasard ne convient pas, car son opérateur peut activer IPv6 ou modifier les réponses DNS à tout moment.

Configurer IPv6 Prefix Delegation explique comment le préfixe WAN, Router Advertisement et DHCPv6 fonctionnent ensemble. NAT64 ne corrige pas une absence d’adressage IPv6 dans le réseau client.

Vérifier les prérequis

Quatre bases distinctes doivent fonctionner avant de créer les règles :

Le client possède une adresse IPv6 valide, une route par défaut et un DNS fonctionnel.
fw01.corp.example renvoie, dans le réseau client, la réponse AAAA prévue pour le firewall.
Direct Web Proxy écoute sur le port documenté sous Web > General settings > Web proxy configuration, 3128 dans cet exemple.
Le firewall dispose d’un chemin WAN IPv4 fonctionnel vers la destination.

Sous Administration > Device access, Web proxy doit être accessible pour la source client précise et l’adresse prévue du firewall. Une autorisation large pour toute la zone LAN ou Wi-Fi n’est pas nécessaire pour un pilote. La limite du proxy reste importante : un client autorisé peut atteindre par ce chemin des services HTTP/HTTPS locaux du firewall. Les destinations d’administration sont donc testées explicitement comme cas négatifs, comme décrit dans l’article de base.

Le client reçoit le FQDN et le port du proxy via une politique de navigateur administrée, un paramètre du système d’exploitation ou un fichier PAC. Le FQDN doit être accessible en IPv6 depuis le client IPv6-only. Un client IPv6-only ne peut pas utiliser comme premier saut une adresse de proxy qui ne possède qu’un enregistrement A.

Documenter les règles firewall, Web Policies, l’authentification, TLS Inspection et les SD-WAN Routes existantes. Positionner les deux règles pilotes suffisamment haut pour qu’elles soient évaluées avant une règle générale correspondante, sans contourner de manière incontrôlée les règles de protection existantes.

Créer la règle IPv6 vers le proxy

Sous Rules and policies > Firewall rules, sélectionner d’abord IPv6, puis créer une règle avec Add firewall rule > New firewall rule :

Rule name: LAN6_DirectProxy_to_IPv4
Action: Accept
Log firewall traffic: activé
Source zones: LAN
Source networks and devices: réseau pilote IPv6 ou client pilote individuel
Destination zones: WAN
Destination networks: destination FQDN contrôlée ou, pour le déploiement ultérieur, ensemble de destinations planifié délibérément
Services: service TCP personnalisé pour 3128
Match known users: uniquement avec une authentification déjà fonctionnelle et les utilisateurs ou groupes prévus
Web filtering > Web policy: Web_Standard_IPv6_Pilot

La zone de destination WAN semble inhabituelle au premier abord, car le client se connecte techniquement à une adresse du firewall. Sophos exige toutefois WAN ou Any pour transmettre le trafic au composant proxy. Selon le fabricant, cela s’applique même lorsque le serveur web final se trouve dans LAN ou DMZ. La zone de destination ne doit donc pas être remplacée au jugé par la zone physique du serveur.

Sophos autorise également Any sous Services. Le port concret du listener est plus lisible pour un pilote et évite une autorisation inutilement large. Si le Web proxy listening port change, le service, le paramètre PAC/du navigateur, Device Access et les tests doivent tous utiliser la même valeur.

Pour les endpoints IPv6-only, configurer les utilisateurs et les groupes dans cette règle IPv6. La Web Policy s’applique également ici. Le guide sur les règles firewall explique l’ordre, la journalisation et l’association des utilisateurs ; les catégories et les actions sont planifiées dans les Web Protection Policies.

Créer la règle IPv4 du proxy vers la destination

Passer ensuite à IPv4 sous Rules and policies > Firewall rules et créer la seconde règle :

Rule name: Proxy_IPv4_Egress_Pilot
Action: Accept
Log firewall traffic: activé
Source zones: Any
Source networks and devices: Any
Destination zones: WAN
Destination networks: d’abord la destination A-only contrôlée, puis uniquement l’ensemble de destinations réellement nécessaire
Services: HTTP et HTTPS, ou les ports de destination réellement nécessaires
Match known users: ne pas l’utiliser comme substitut à l’association des utilisateurs dans la règle IPv6 pour ce déroulement IPv6-only
Other security features: politiques prévues pour Application Control, IPS et, si nécessaire, Traffic Shaping

L’exemple officiel de Sophos utilise Any pour la zone source et le réseau source, car le proxy crée la connexion IPv4. Ces valeurs ne doivent pas être remplacées à tort par le réseau client IPv6. Il faut plutôt restreindre la règle pilote par sa destination et ses services, puis la vérifier grâce à sa Rule ID.

La Web Policy n’est pas déplacée vers cette règle IPv4. Elle appartient au premier segment du proxy, lié à l’utilisateur. Application Control et IPS protègent en revanche le segment entre le proxy et la destination IPv4. Une politique de Traffic Shaping dans la règle IPv4 s’applique à cet egress ; Sophos indique également que Traffic Shaping ne s’applique pas à la connexion directe entre le client et le proxy.

Ne pas créer de règle NAT64 supplémentaire. Le chemin WAN IPv4 normal du firewall doit néanmoins fonctionner. Si une règle IPv4 existante couvre déjà cet egress proxy de manière contrôlée, elle peut continuer à être utilisée après vérification de sa Rule ID et de ses politiques ; une seconde règle Any parallèle serait alors moins bonne qu’une règle existante documentée consciemment.

Tester le chemin IPv6 vers IPv4 réel

Précontrôle DNS et listener

Les contrôles en lecture seule suivants sont utiles sur un client pilote Windows :

Resolve-DnsName fw01.corp.example -Type AAAA
Resolve-DnsName v4-test.corp.example -Type A
Resolve-DnsName v4-test.corp.example -Type AAAA
Test-NetConnection fw01.corp.example -Port 3128

Le FQDN du proxy doit renvoyer l’adresse IPv6 attendue. La destination de test doit posséder un enregistrement A ; aucune adresse de destination n’est attendue pour le test AAAA. Test-NetConnection confirme uniquement le listener TCP, pas la Web Policy, la résolution DNS dans le proxy ni l’egress IPv4.

Valider les deux règles et couches de protection

Ouvrir une nouvelle session de navigation privée sur le pilote IPv6-only.
Vérifier le proxy effectif ou le fichier PAC chargé.
Ouvrir la destination A-only autorisée.
Ouvrir une destination délibérément bloquée par Web_Standard_IPv6_Pilot.
Dans Log viewer, vérifier la règle IPv6, la source, l’utilisateur, la Web Policy, l’action et la Firewall Rule ID.
Pour la connexion suivante, vérifier la règle IPv4, la destination IPv4, le service, Application Control/IPS et la seconde Firewall Rule ID.
Répéter la requête vers la destination sans proxy comme test négatif ; le client IPv6-only ne doit pas atteindre directement la destination A-only en IPv4.
Tester une application sans prise en charge du proxy et confirmer qu’elle n’est pas considérée à tort comme compatible NAT64.

La réussite n’est démontrée que si le nom de destination est réellement A-only, si le client atteint le proxy en IPv6, si les deux règles attendues correspondent et si les tests web autorisé et bloqué montrent les actions prévues. Tester systématiquement les règles firewall explique comment corréler Rule ID, Log Viewer, Policy Tester et Packet Capture.

Délimiter les erreurs systématiquement

Le port du proxy n’est pas accessible en IPv6

Vérifier la réponse AAAA du FQDN du proxy, l’adresse client, la route par défaut, Neighbor Discovery, l’interface du firewall et Web proxy sous Device Access. Un test IPv4 réussi depuis un autre client ne prouve rien concernant le chemin du listener IPv6.

La règle IPv6 correspond, mais la destination ne se charge pas

Confirmer d’abord que le proxy résout le nom de destination en enregistrement A et que le firewall lui-même dispose d’un chemin WAN IPv4 fonctionnel. Vérifier ensuite la règle IPv4, la destination, le service, l’ordre et la Rule ID. La règle IPv6 n’est que la première moitié.

Seuls les sites web dual-stack fonctionnent

Le chemin NAT64 n’est pas encore démontré. Vérifier si la destination de test possède un enregistrement AAAA. Utiliser une destination A-only dédiée pour la validation et exclure un chemin IPv4 actif sur le client.

La Web Policy ou l’utilisateur est incorrect

Vérifier l’association dans la règle IPv6. SFOS évalue Match known users dans les deux règles pour les endpoints IPv6-only, mais Sophos attribue explicitement ces paramètres à la règle IPv6. Une association d’utilisateur dans la règle IPv4 ne doit pas remplacer le contexte utilisateur manquant dans le premier segment.

Application Control ou IPS ne s’applique pas

Vérifier ces fonctions dans la règle IPv4, pas uniquement dans la règle IPv6. Confirmer ensuite, grâce à la Rule ID IPv4, que cette règle traite réellement l’egress du proxy. Une décision réussie du filtre web ne prouve pas Application Control ni IPS.

Les destinations internes ou locales ont un comportement inattendu

Même lorsque la destination finale se trouve dans LAN ou DMZ, la règle IPv6 exige WAN ou Any pour transmettre le trafic au proxy. La zone de destination réelle est représentée dans la règle IPv4. Vérifier également l’exposition des services d’administration locaux due à l’accès au proxy et les réponses DNS internes.

SD-WAN, HA et rollback

Une SD-WAN Route avec les services HTTP et HTTPS ne correspond pas à la connexion du client au port proxy 3128. Pour le premier segment, il faut utiliser le port réel du listener ou choisir consciemment Any. L’egress proxy nécessite également une gateway WAN fonctionnelle ou un chemin de retour statique. Configurer et tester les SD-WAN Routes explique ces cas particuliers.

En HA, il ne faut pas promettre la poursuite sans interruption d’une connexion proxy existante. Après un failover contrôlé, ouvrir une nouvelle session de navigation et vérifier à nouveau l’enregistrement AAAA du proxy, la Rule ID IPv6, la Web Policy, la Rule ID IPv4 et l’accès à la destination. Pour la recherche dans les logs, le nœud qui a traité le trafic concerné est déterminant.

Pour le rollback :

Désactiver les règles pilotes ou les rétablir dans leur état précédent documenté.
Supprimer l’exception Device Access dédiée au pilote si elle a été créée uniquement pour ce test.
Retirer du pilote le paramètre PAC, GPO ou proxy du navigateur.
Restaurer l’ordre précédent des règles IPv4/IPv6 et la configuration SD-WAN.
Vérifier à nouveau l’accès IPv6 direct, le trafic proxy existant et les services d’administration locaux.

Ne pas supprimer les deux règles avant d’avoir documenté le chemin précédent et de disposer d’une session administrateur ouverte ou d’un accès d’administration alternatif.

Checklist de validation

Le client est manifestement IPv6-only.
Le FQDN du proxy renvoie l’adresse AAAA attendue.
La destination de test possède un enregistrement A, mais aucun enregistrement AAAA.
Direct Web Proxy et Device Access sont limités au pilote.
La règle IPv6 utilise la zone de destination WAN, le port réel du listener, la journalisation et la Web Policy.
L’association des utilisateurs, si nécessaire, a réussi les tests positifs et négatifs dans la règle IPv6.
La règle IPv4 traite l’egress proxy avec les ports de destination et les fonctions de protection planifiés.
Les deux Firewall Rule IDs et les deux versions IP sont démontrées lors du test.
L’exposition des services d’administration, le trafic hors proxy, SD-WAN et HA sont délimités consciemment.
Le rollback, le responsable et la date de révision sont documentés.

Questions fréquentes

NAT64 sur Sophos Firewall nécessite-t-il une règle NAT normale ?

Pas pour ce déroulement de proxy web documenté. SFOS fournit l’accès d’IPv6 vers IPv4 dans le chemin du proxy explicite. Une règle firewall IPv6 et une règle IPv4 sont nécessaires, mais aucune règle NAT64 générale sous Rules and policies > NAT rules.

Cette architecture NAT64 fonctionne-t-elle pour toutes les applications ?

Non. Elle s’applique à HTTP/HTTPS pour les clients et les applications qui utilisent explicitement Direct Web Proxy. Le trafic hors proxy, UDP, ICMP ou les applications sans prise en charge du proxy nécessitent une autre transition IPv6/IPv4 ou le maintien d’une connectivité native.

Pourquoi une seule règle firewall ne suffit-elle pas ?

Le proxy termine la connexion IPv6 du client, puis crée une nouvelle connexion IPv4 vers la destination A-only. La Web Policy et l’association des utilisateurs sont évaluées dans le segment IPv6 ; Application Control et IPS pour l’egress le sont dans le segment IPv4. Les deux chemins doivent être autorisés, journalisés et testés séparément.