Utiliser NAT pour des réseaux IPsec chevauchants sur Sophos Firewall

Si le siège et la succursale utilisent le même sous-réseau réel, aucun pare-feu ne peut déterminer, à partir de la seule adresse de destination, si un paquet doit rester local ou traverser le tunnel IPsec. Le tunnel peut être vert sans qu’un chemin de données univoque existe. La solution est un plan de traduction coordonné des deux côtés : chaque site apparaît au pair sous un réseau traduit unique.

Le type de tunnel détermine la méthode. IPsec policy-based et IPsec route-based avec des traffic selectors précis utilisent les paramètres NAT directement dans la connexion IPsec. Route-based Any-to-Any utilise à la place des règles DNAT et SNAT ainsi qu’une route vers le réseau distant traduit. Configurer un VPN IPsec Site-to-Site explique le choix général du type de tunnel.

Choisir la bonne méthode

Sophos prend en charge les traductions 1:1, 1:n et n:n pour IPsec policy-based. Avec n:n, le réseau original et le réseau traduit doivent avoir la même taille. Un /24 est donc associé à un autre /24, et non à un /25.

Trois questions suffisent pour choisir :

Des Local et Remote subnets précis sont-ils définis dans la connexion IPsec ? Utiliser Network address translation (NAT) dans la connexion.
Les deux sous-réseaux sont-ils définis sur Any dans un tunnel route-based ? Utiliser DNAT avec une règle SNAT réflexive et une route via XFRM.
Les réseaux ne se chevauchent-ils pas du tout ? NAT est normalement inutile et complique les logs, les règles et le dépannage.

⚠️ Ne pas mélanger les deux méthodes. Avant la modification, sauvegarder les deux configurations de tunnel, les règles NAT et de pare-feu, les routes, les réponses DNS et un accès administrateur indépendant. Une règle MASQ étendue ou une adresse traduite improvisée ne constitue pas une solution sûre.

Créer un plan d’adressage pour les deux sites

Dans l’exemple, le siège et la succursale utilisent tous deux le réseau réel 192.0.2.0/24. Chaque côté reçoit son propre réseau virtuel pour le tunnel :

HQ real:            192.0.2.0/24  → visible to branch as 198.51.100.0/24
Branch real:        192.0.2.0/24  → visible to HQ as 203.0.113.0/24

Un client du siège contacte donc un serveur de la succursale via son adresse dans 203.0.113.0/24. Un client de la succursale utilise l’adresse correspondante dans 198.51.100.0/24 pour un serveur du siège. L’adresse réelle 192.0.2.x reste locale sur chaque site.

Ces trois réseaux proviennent des blocs IPv4 réservés aux exemples par la RFC 5737 et doivent être remplacés ensemble par des réseaux libres du plan d’adressage réel. Les deux réseaux traduits doivent être uniques, ne chevaucher aucun LAN, VLAN, VPN, réseau cloud ou domestique et être documentés symétriquement sur les deux pare-feu. Si les applications utilisent des noms, le DNS de chaque site doit renvoyer l’adresse traduite du système distant.

Configurer IPsec policy-based avec NAT

Sous Hosts and services > IP host > Add, IPsec policy-based nécessite trois objets réseau sur chaque pare-feu : le réseau local réel, son propre réseau traduit et le réseau traduit du pair. Dans l’exemple du siège, il s’agit de HO_LAN_REAL_192.0.2.0, HO_LAN_NAT_198.51.100.0 et BO_LAN_NAT_203.0.113.0.

Configurer le siège

Sous Site-to-site VPN > IPsec > Add, créer la connexion en Policy-based avec Gateway type Respond only. Le profil, l’authentification, l’interface WAN et l’adresse du pair doivent correspondre au côté distant. Utiliser ces associations :

Activate on save : activé
Create firewall rule : activé
Local subnet : HO_LAN_NAT_198.51.100.0
Remote subnet : BO_LAN_NAT_203.0.113.0
Network address translation (NAT) : activé
Original subnet : HO_LAN_REAL_192.0.2.0

Le pare-feu traduit son réseau local réel vers son propre réseau traduit avant l’envoi. Le trafic entrant destiné au réseau traduit est réaffecté au réseau réel.

Configurer la succursale en miroir

Cette répartition des rôles est particulièrement utile lorsque la succursale possède une adresse IP dynamique et que le siège ne dispose pas d’une adresse fiable du pair pour lancer la connexion : la succursale initie alors la connexion vers le siège, dont le point de terminaison est accessible de manière stable. Une adresse dynamique n’est toutefois pas un obstacle absolu si l’adresse du pair peut être résolue de manière fiable et si la conception permet au siège d’initier la connexion. À mesure que des succursales sont ajoutées, l’établissement des connexions passe mieux à l’échelle lorsque chaque succursale relance sa propre connexion plutôt que de laisser le siège relancer toutes les connexions des succursales.

Dans la succursale, créer la connexion Policy-based avec Gateway type Initiate the connection. Inverser complètement les associations :

Activate on save : activé
Create firewall rule : activé
Local subnet : BO_LAN_NAT_203.0.113.0
Remote subnet : HO_LAN_NAT_198.51.100.0
Network address translation (NAT) : activé
Original subnet : BO_LAN_REAL_192.0.2.0

Local et Remote subnet contiennent donc les réseaux traduits, tandis qu’Original subnet contient le réseau local réel. Si la taille ou la direction ne correspondent pas, la phase 2 peut tout de même s’établir, mais le trafic est mal traduit ou ne trouve aucun chemin de retour.

Contrôler les règles de pare-feu automatiques

Avec Create firewall rule, SFOS crée des règles VPN entrantes et sortantes. Les contrôler sous Rules and policies > Firewall rules dans le groupe Automatic VPN rules. Elles doivent autoriser les réseaux traduits dans le bon sens et uniquement les services réellement nécessaires. Une règle VPN générale existante peut être adaptée ; une règle étendue séparée n’est pas obligatoire pour chaque tunnel.

Les règles sont évaluées de haut en bas. Placer ces règles VPN au-dessus de toute règle plus générale susceptible d’entrer en conflit, puis contrôler la Rule ID, les zones source et destination, les réseaux source et destination, les services et le logging pendant un test réel. Créer des règles de pare-feu sur Sophos Firewall explique la logique générale.

Établir la connexion si nécessaire

Contrôler l’état du tunnel uniquement après avoir configuré les deux sites et vérifié les règles de pare-feu. Activate on save active l’entrée de configuration, mais ne prouve pas que le tunnel est établi. Si le tunnel n’est pas encore établi et qu’un établissement manuel est nécessaire, ouvrir Site-to-site VPN > IPsec du côté initiateur – la succursale dans cet exemple – et cliquer sur le bouton d’état dans la colonne Connection de la connexion concernée.

Ne pas déconnecter ni rétablir une SA de production déjà établie pour cette étape ; aucun clic de ce type n’est nécessaire au siège qui répond. Un indicateur de connexion vert confirme l’établissement du tunnel, pas le bon fonctionnement du chemin de données : effectuer ensuite dans les deux directions les contrôles de service, de Child SA et de capture décrits plus bas.

Configurer route-based Any-to-Any avec DNAT et SNAT

Cette méthode nécessite un tunnel route-based Any-to-Any fonctionnel. L’interface XFRM possède une adresse de transit unique, les règles LAN-to-VPN et VPN-to-LAN correspondantes existent et une route statique, SD-WAN ou dynamique pointe vers le réseau traduit du pair. NAT n’est ajouté qu’ensuite.

Les connexions route-based avec des traffic selectors précis n’utilisent pas cette procédure. Comme IPsec policy-based, elles utilisent les paramètres NAT de la connexion IPsec. Il s’agit d’une procédure Sophos distincte, à ne pas mélanger avec les règles DNAT/SNAT d’Any-to-Any.

NAT au siège

Créer une règle DNAT sous Rules and policies > NAT rules > Add NAT rule > New NAT rule. Elle traduit les paquets entrants destinés au réseau virtuel du siège vers le réseau local réel :

Original source : réseau traduit de la succursale 203.0.113.0/24
Translated source : Original
Original destination : réseau traduit du siège 198.51.100.0/24
Translated destination : réseau réel du siège 192.0.2.0/24
Original service : Any
Translated service : Original
Inbound interface : Any
Outbound interface : Any
Create reflexive rule : activé
Load balancing method : One-to-one

Utiliser des objets réseau ou IP range de même taille pour l’association. Après l’enregistrement, ouvrir la règle générée Reflexive_NAT#_<DNAT_rule_name>. En sortie, elle doit traduire le réseau réel du siège vers 198.51.100.0/24 et utiliser le réseau traduit de la succursale 203.0.113.0/24 comme Original destination.

NAT dans la succursale

Appliquer le même principe en miroir dans la succursale :

Original source : réseau traduit du siège 198.51.100.0/24
Translated source : Original
Original destination : réseau traduit de la succursale 203.0.113.0/24
Translated destination : réseau réel de la succursale 192.0.2.0/24
Original service : Any
Translated service : Original
Inbound interface : Any
Outbound interface : Any
Create reflexive rule : activé
Load balancing method : One-to-one

La règle réflexive doit traduire en sortie le réseau réel de la succursale vers 203.0.113.0/24. La valeur Any pour les deux interfaces est intentionnelle dans ce modèle documenté ; ne pas la remplacer par WAN au seul motif que le pair IPsec est joignable par le WAN. Les objets d’adresses traduites et les règles de pare-feu assurent le périmètre restreint. Une règle SNAT ou MASQ plus générale placée au-dessus ne doit pas capturer le trafic en premier.

SFOS fait correspondre une règle NAT à la source, à la destination et au service d’origine, avant NAT, ainsi qu’aux interfaces d’entrée et de sortie. NAT ne s’applique qu’au premier paquet d’une connexion : chaque test après une modification NAT doit donc utiliser une nouvelle connexion, avec un nouveau quintuplet. Prouver l’ordre et la correspondance à l’aide de la NAT Rule ID et de Packet Capture au lieu de les déduire uniquement de la liste. Comprendre NAT sur Sophos Firewall explique les règles réflexives et le principe first-match.

Associer précisément les règles firewall Any-to-Any

Une règle NAT n’autorise aucun trafic. Sous Rules and policies > Firewall rules > Add firewall rule > New firewall rule, créer des règles limitées : au siège, la règle sortante utilise LAN, le réseau réel du siège, VPN et le réseau traduit de la succursale ; la règle entrante utilise VPN, le réseau traduit de la succursale, LAN et le réseau réel du siège. Inverser les sites dans la succursale, limiter Services et activer Log firewall traffic pour la recette. Cette différence suit l’ordre de traitement NAT : règle firewall avant SNAT en sortie, DNAT avant règle firewall en entrée.

Contrôler ensemble routage, DNS et applications

Avec route-based Any-to-Any, une route statique, SD-WAN ou dynamique configurée manuellement de chaque côté doit pointer vers le réseau distant traduit via la bonne interface XFRM ou sa gateway surveillée. S’il existe plusieurs routes, contrôler ensemble Route Precedence, Administrative Distance et la sélection SD-WAN. Avec route-based avec des traffic selectors précis, une route statique est en revanche créée automatiquement lors de l’établissement du tunnel ; contrôler cette route et les selectors correspondants. Avec IPsec policy-based, SFOS crée une route VPN dans le backend lors de l’établissement du tunnel et associe le trafic selon la policy VPN ou les Local et Remote subnets ; une route XFRM dédiée ne fait pas partie de cette méthode. Dans les trois variantes, le réseau réel identique doit rester local et ne doit pas être attiré dans le tunnel par une route vers le réseau distant.

L’application doit également utiliser la destination traduite. Les configurations statiques, ACL, réponses DNS, outils de monitoring et logs de serveur ne doivent pas continuer à attendre l’adresse distante réelle. Un test NAT utilisant uniquement ping ne prouve donc pas le fonctionnement du processus métier.

Valider le flux dans les deux directions

Commencer par un hôte connu et un véritable service TCP ou UDP de chaque côté. Contrôler Current activities > IPsec connections et Reports > VPN. Sous Diagnostics > Packet capture > Configure, un filtre BPF tel que host 203.0.113.10 limite la capture au test. Depuis le siège, accéder à l’adresse traduite de la succursale, puis tester l’adresse traduite du siège depuis la succursale. Pour le même horodatage, vérifier :

La connexion IPsec et la Child SA sont actives.
La Firewall Rule ID attendue autorise le flux.
Avec Any-to-Any, les Rule IDs attendues des règles DNAT et SNAT réflexives attestent les traductions source et destination prévues. Avec IPsec policy-based et route-based avec des traffic selectors précis, comparer plutôt les valeurs enregistrées dans Original subnet, Local subnet et Remote subnet des deux côtés, les selectors négociés et les adresses originales et traduites réellement observées dans le flux de test. Aucune NAT Rule ID distincte n’est nécessaire pour ce NAT intégré à la connexion.
Packet Capture montre l’entrée, le transfert et le chemin de retour à l’aide de In interface, Out interface, Rule ID, Status et Reason. Comparer les adresses source et destination avant et après traduction au plan d’adressage ; le filtre doit capturer les adresses originales ou traduites contrôlées dans chaque test. Avec route-based, contrôler l’interface XFRM correspondante ; avec policy-based, contrôler le chemin IPsec via l’interface IPsec commune, et non une interface XFRM dédiée. Avec Any-to-Any, NAT ID permet également d’identifier la règle NAT distincte et ne constitue pas une preuve obligatoire pour le NAT intégré à la connexion.
Le serveur de destination voit l’adresse source prévue et répond par le même chemin.

Comme contrôle négatif, contacter ensuite l’adresse réelle identique 192.0.2.10 : elle doit rester locale et ne doit traverser le VPN dans aucune des trois variantes. Ajouter d’autres hôtes, services et noms DNS uniquement après la réussite des tests positif et négatif dans les deux directions. Packet Capture sur Sophos Firewall aide à comparer les paquets avant et après NAT ; Dépannage IPsec sur Sophos Firewall couvre le contrôle complet du tunnel.

Circonscrire les erreurs selon le symptôme

Le tunnel est vert, mais la destination répond localement

Le client utilise probablement l’adresse réelle, qui existe aussi localement, au lieu du réseau distant traduit. Contrôler la réponse DNS, le fichier hosts, la configuration de l’application et la route de destination. Le défaut se situe alors avant le tunnel.

L’aller fonctionne, mais le retour manque

Les traductions doivent être configurées en miroir sur les deux pare-feu. Avec Any-to-Any, comparer Original source et Translated source ainsi que l’adresse de destination distante inchangée dans la règle SNAT réflexive ; avec IPsec policy-based et route-based avec des traffic selectors précis, comparer les associations entre Original subnet, Local subnet et Remote subnet ainsi que les selectors négociés de la connexion. Contrôler également la gateway du serveur et les règles de pare-feu du sens inverse. Une traduction unilatérale ne peut pas produire un flux bidirectionnel stable.

La mauvaise règle NAT correspond

Avec Any-to-Any, contrôler la NAT Rule ID et l’ordre des règles DNAT/SNAT distinctes. Une règle MASQ étendue, Default-SNAT ou DNAT antérieure peut correspondre avant la règle VPN spécifique. Ne pas désactiver toutes les règles NAT sur une simple hypothèse ; corréler d’abord le flux de test individuel par horodatage, puis corriger uniquement la règle en conflit. Avec IPsec policy-based et route-based avec des traffic selectors précis, circonscrire plutôt une traduction incorrecte à l’aide des champs NAT de la connexion IPsec, des selectors négociés et des adresses réelles avant et après NAT ; l’absence d’une NAT Rule ID distincte n’est pas une erreur dans ce cas.

Certains hôtes fonctionnent, d’autres non

Avec n:n, les plages originale et traduite doivent avoir la même taille et la même position. Contrôler les objets IP range, les masques, les adresses exclues, le pare-feu de l’hôte et l’offset réellement contacté. Le succès pour .10 ne prouve pas l’association de toute la plage.

Rollback et exploitation

Avant la modification, préparer un backup de configuration, des captures ou exports des configurations du tunnel, de NAT, du pare-feu et du routage, ainsi qu’un accès de gestion indépendant. Noter aussi les noms, ID, ordre et état d’activation de toutes les règles et routes concernées, ainsi que les anciennes valeurs DNS et applicatives. Pendant la migration, ne désactiver d’anciennes règles qu’après avoir documenté précisément leur état antérieur.

Si la validation échoue, restaurer d’abord les anciennes valeurs DNS et applicatives. Pour Any-to-Any, désactiver uniquement les nouvelles règles firewall, la paire DNAT/SNAT réflexive et la route du réseau traduit ; pour policy-based, restaurer les champs Local, Remote et Original subnet sauvegardés. Rétablir ensuite l’ordre et l’état d’activation antérieurs des règles et routes, puis tester de nouvelles connexions dans les deux sens. Les sessions établies conservent la traduction fixée par leur premier paquet et ne prouvent pas le rollback : laisser les sessions sans rapport se poursuivre et, si une preuve immédiate est nécessaire, ne terminer que les sessions de test concernées avant de recommencer. Ne pas purger toutes les connexions. Supprimer les adresses XFRM et objets seulement lorsque Object usage ne montre plus de dépendance. Retirer les réseaux traduits du DNS, du monitoring et de la documentation uniquement lorsqu’il ne reste plus aucune dépendance.

En exploitation, gérer les réseaux traduits dans le plan d’adressage IP central. Comparer les nouveaux sites, réseaux cloud, pools de Remote Access et réseaux domestiques aux réseaux originaux et traduits. Sinon, le chevauchement est simplement déplacé ailleurs.

Questions fréquentes

Un seul côté du tunnel peut-il utiliser NAT ?

Uniquement si la conception complète de l’adressage et du retour le prévoit explicitement. Avec des réseaux réels identiques, une traduction en miroir est normalement nécessaire pour que les deux côtés puissent adresser le réseau distant sans ambiguïté et renvoyer correctement les réponses.

Une règle MASQ suffit-elle pour des réseaux chevauchants ?

Non. MASQ ne crée pas un adressage de destination unique et peut, selon le type de tunnel IPsec, utiliser une source inadaptée ou provoquer le rejet du trafic. La conception documentée utilise les champs NAT de la connexion IPsec ou des règles DNAT ciblées avec une règle SNAT réflexive contrôlée.