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
Anydans 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.168.2.0/24. Chaque côté reçoit son propre réseau virtuel pour le tunnel :
HQ real: 192.168.2.0/24 → visible to branch as 192.168.1.0/24
Branch real: 192.168.2.0/24 → visible to HQ as 192.168.3.0/24
Un client du siège contacte donc un serveur de la succursale via son adresse dans 192.168.3.0/24. Un client de la succursale utilise l’adresse correspondante dans 192.168.1.0/24 pour un serveur du siège. L’adresse réelle 192.168.2.x reste locale sur chaque site.
Ces trois réseaux sont des valeurs de documentation 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
IPsec policy-based nécessite trois objets IP host 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.168.2.0, HO_LAN_NAT_192.168.1.0 et BO_LAN_NAT_192.168.3.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 :
- Local subnet :
HO_LAN_NAT_192.168.1.0 - Remote subnet :
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT) : activé
- Original subnet :
HO_LAN_REAL_192.168.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
Dans la succursale, créer la connexion Policy-based avec Gateway type Initiate the connection. Inverser complètement les associations :
- Local subnet :
BO_LAN_NAT_192.168.3.0 - Remote subnet :
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT) : activé
- Original subnet :
BO_LAN_REAL_192.168.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. 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.
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. Si leur trafic correspond à la place à une règle MASQ, SFOS peut le rejeter, car aucune adresse IP n’est attribuée à ces interfaces XFRM.
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
192.168.3.0/24 - Translated source :
Original - Original destination : réseau traduit du siège
192.168.1.0/24 - Translated destination : réseau réel du siège
192.168.2.0/24 - 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 192.168.1.0/24 et utiliser le réseau traduit de la succursale 192.168.3.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
192.168.1.0/24 - Translated source :
Original - Original destination : réseau traduit de la succursale
192.168.3.0/24 - Translated destination : réseau réel de la succursale
192.168.2.0/24 - 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 192.168.3.0/24. Une règle SNAT ou MASQ plus générale placée au-dessus ne doit pas capturer le trafic en premier. 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.
Contrôler ensemble routage, DNS et applications
Sur chaque côté, la route vers le réseau distant traduit doit utiliser la bonne interface XFRM ou sa gateway surveillée. Une route vers le réseau réel identique serait ambiguë et pourrait attirer le trafic local dans le tunnel. S’il existe plusieurs routes, contrôler ensemble Route Precedence, Administrative Distance et la sélection SD-WAN.
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é. 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.
- La NAT Rule ID attendue traduit correctement les adresses originale et de destination.
- Packet Capture montre l’entrée, la traduction, la sortie XFRM et le retour.
- Le serveur de destination voit l’adresse source prévue et répond par le même chemin.
Ajouter d’autres hôtes, services et noms DNS uniquement après le fonctionnement des 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 se refléter sur les deux pare-feu. Comparer Original et Translated source dans la règle réflexive, Remote subnet dans la connexion IPsec, la gateway du serveur et les règles du sens inverse. Une traduction unilatérale ne peut pas produire un flux bidirectionnel stable.
La mauvaise règle NAT correspond
Contrôler la NAT Rule ID et l’ordre. 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.
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. Pendant la migration, ne désactiver d’anciennes règles que si une restauration sans ambiguïté est documentée.
Si la validation échoue, désactiver les nouvelles règles NAT et routes, restaurer la configuration précédente du tunnel et retester le trafic local initial. 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.