Maîtriser le NAT sur Sophos Firewall : SNAT, DNAT, MASQ et PAT

Le NAT modifie les adresses ou les ports d’un paquet. En revanche, il ne décide pas si une connexion est autorisée et ne crée aucune route. Pour qu’un flux aboutisse, la règle NAT, la règle de pare-feu, le routage et le chemin de retour doivent tous être cohérents.

La bonne question à se poser en premier n’est donc pas « De quel type de NAT ai-je besoin ? », mais : Quelle adresse ou quel port doit être modifié entre l’entrée et la sortie ? Si la réponse n’est pas évidente, la solution se trouve généralement dans le routage ou la règle de pare-feu, et non dans le NAT.

⚠️ Une règle NAT ne constitue pas une autorisation. Si la règle de pare-feu autorise le trafic alors qu’aucune règle NAT ne correspond, SFOS transmet le paquet sans traduction. Si aucune règle de pare-feu adaptée n’existe, le paquet est rejeté et l’événement est journalisé.

À quels besoins le NAT répond-il ?

• Des clients LAN doivent accéder à Internet : utilisez généralement le SNAT avec MASQ.
• Un service interne doit être publié sur une adresse publique : utilisez le DNAT ; pour HTTP/HTTPS, examinez d’abord la possibilité d’utiliser le WAF.
• Les ports externe et interne sont différents : configurez une traduction de service avec Translated service (PAT).
• Des clients internes utilisent le nom public d’un serveur interne : privilégiez le Split DNS ou mettez en place une Loopback Rule ciblée.
• Des réseaux distincts communiquent au travers d’un VPN site à site : utilisez normalement le routage et les règles de pare-feu, sans NAT.
• Les plans d’adressage se chevauchent : concevez le NAT en fonction du type de VPN ; n’appliquez pas par défaut une règle MASQ générique.
• Il faut uniquement autoriser ou bloquer un accès : modifiez la règle de pare-feu, sans créer de règle NAT.

Pour mettre concrètement un serveur à disposition, l’article Publier un serveur avec DNAT sur Sophos Firewall couvre l’assistant, la création manuelle de la règle, le durcissement, la mise en production et le retour arrière. Le présent article expose le fonctionnement du NAT afin de faciliter la lecture de ces règles et le diagnostic des incidents.

D’autres cas particuliers sont traités dans NAT64 avec Direct Web Proxy, Proxy ARP pour des adresses IPv4 publiques supplémentaires et NAT en cas de problèmes IPsec.

Bien interpréter Original et Translated

Dans Rules and policies > NAT rules > Add NAT rule, Original décrit le paquet à son arrivée sur le pare-feu. Translated indique la transformation appliquée par SFOS.

SFOS sélectionne la règle à partir des champs suivants :

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

Les champs Translated source (SNAT), Translated destination (DNAT) et Translated service (PAT) définissent le résultat de la traduction ; ils ne constituent pas des critères de correspondance supplémentaires. SFOS évalue les règles NAT de haut en bas et applique la première qui correspond au paquet.

Les règles NAT sont disponibles pour IPv4 et IPv6. Sélectionnez la famille d’adresses dans Rules and policies > NAT rules avant de créer une règle ; les adresses IPv4 des exemples ne conviennent pas à une règle IPv6. Add NAT rule > New NAT rule ouvre la configuration manuelle. Les nouvelles règles sont activées par défaut. Rule position propose Top et Bottom ; leur ordre peut ensuite être modifié par glisser-déposer. Avant Save, contrôlez les critères et la position afin de ne pas détourner involontairement du trafic en production.

Deux exemples de flux

Un client 10.10.10.80 se connecte à 198.51.100.20:443 via Port2. Une règle SNAT peut ne modifier que la source en lui appliquant MASQ. La destination et le service restent sur Original.

Dans le cas d’un service publié, un client externe se connecte à 203.0.113.10:5555. Le DNAT remplace la destination par 172.16.16.10 et le PAT remplace le service par 443. La règle se présente alors ainsi :

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

Le PAT n’est donc pas un type de traduction d’adresse à part entière, comparable au SNAT ou au DNAT : il assure la traduction d’un port ou d’un service au sein d’une règle NAT.

SNAT et MASQ pour les flux sortants

Le SNAT modifie l’adresse source. Une règle LAN vers WAN classique définit le réseau interne comme Original source, l’interface WAN comme Outbound interface et MASQ comme Translated source. La destination et le service restent sur Original, sauf s’il est nécessaire de les restreindre à un périmètre précis.

Par défaut, MASQ utilise l’adresse de l’interface de sortie. La configuration d’usine comporte à cet effet la règle Default SNAT IPv4. Si vous n’en avez pas besoin, Sophos recommande de la désactiver plutôt que de la supprimer, car elle peut être recréée lors de l’ajout ou de la mise à jour d’une interface WAN.

Après une migration depuis SFOS 17.5 ou une version antérieure, une règle SNAT par défaut désactivée peut aussi apparaître en bas du tableau. Elle sert à remplacer les anciennes règles Linked MASQ supprimées lors de la migration et ne doit pas être confondue avec une règle d’usine réellement active.

Plusieurs clients ou serveurs internes peuvent partager la même IP source publique : SFOS distingue leurs connexions par des numéros de port différents. Cette association de ports source n’est pas une redirection de service DNAT vers un serveur.

Créer une règle SNAT LAN vers WAN autonome

Une règle SNAT autonome peut servir plusieurs règles de pare-feu. Vérifiez d’abord les règles NAT existantes, la route, l’interface de sortie et le retour ; sauvegardez l’état précédent avec les identifiants et les positions. L’exemple n’autorise que HTTPS du réseau client vers une destination de test précise ; remplacez toutes les adresses et interfaces par vos propres valeurs.

1. Ouvrez Rules and policies > NAT rules, sélectionnez IPv4, puis Add NAT rule > New NAT rule. Définissez Rule name, par exemple LAN-Web-Standalone-MASQ. Dans Rule position, choisissez Top ou Bottom, puis déplacez délibérément la règle au-dessus des règles correspondantes plus générales ; ne la placez pas systématiquement en tête.
2. Réglez Original source sur Clients_LAN (10.10.10.0/24), Original destination sur un objet hôte pour 198.51.100.20 et Original service sur HTTPS. L’adresse de documentation n’est pas un véritable serveur de test. Pour un accès Internet général, la destination peut être élargie volontairement, tout en limitant les services à ceux nécessaires.
3. Réglez Translated source (SNAT) sur MASQ, et Translated destination (DNAT) ainsi que Translated service (PAT) sur Original. Choisissez l’interface LAN réelle dans Inbound interface, ici Port2, et l’interface WAN réelle dans Outbound interface, ici Port1. Cliquez sur Save et notez la NAT Rule ID.
4. Dans Rules and policies > Firewall rules, choisissez IPv4 > Add firewall rule > New firewall rule si aucune autorisation adaptée n’existe. Définissez le nom et la position, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks sur la même destination et Services HTTPS. Configurez la sécurité appropriée et Log firewall traffic, puis Save. Ne créez pas de Linked NAT Rule supplémentaire.
5. Établissez une nouvelle connexion HTTPS vers votre destination de test et fermez-la normalement. Comparez les deux Rule IDs dans Log Viewer ; Packet capture doit montrer l’adresse source WAN attendue en sortie. Si la mauvaise règle NAT s’applique, vérifiez d’abord les règles supérieures ; sans réponse, vérifiez le routage et le retour. Pour revenir en arrière, désactivez uniquement les règles ajoutées et rétablissez les positions modifiées ; ne supprimez pas une autorisation partagée. Validez l’état précédent avec une nouvelle session.

Créer une règle LAN vers WAN avec NAT lié

Pour autoriser un flux IPv4 bien délimité, vous pouvez associer le SNAT lors de la création de la règle de pare-feu. Vérifiez d’abord si une règle SNAT existante traduit déjà le flux comme souhaité ; dans ce cas, aucune Linked NAT Rule supplémentaire n’est nécessaire. La route et le chemin de retour doivent être corrects indépendamment du NAT.

1. Ouvrez Rules and policies > Firewall rules, sélectionnez IPv4, puis créez une règle via Add firewall rule > New firewall rule. Choisissez un nom explicite, comme LAN-Web-Out, et une position adaptée ; réglez Action sur Accept et activez Log firewall traffic.
2. Réglez Source zones sur LAN et limitez Source networks and devices au réseau de clients qui doit accéder au service. Par exemple, utilisez un objet réseau Clients_LAN pour 10.10.10.0/24 ; adaptez le nom et le sous-réseau à votre environnement. Réglez Destination zones sur WAN. Dans Destination networks, sélectionnez les destinations nécessaires et, dans Services, uniquement les services requis, comme HTTPS pour ce flux web. Any n’est pas une exigence générale. Prenez en compte séparément le DNS et les autres services nécessaires.
3. Sélectionnez Create linked NAT rule. Attribuez à la règle NAT son propre nom, comme LAN-Web-MASQ, et une position adaptée. Réglez Translated source (SNAT) sur MASQ : ce flux doit utiliser l’adresse de l’interface de sortie effective, tandis que la règle de pare-feu continue de limiter les sources, les destinations et les services.
4. Sélectionnez d’abord Save dans la configuration du NAT lié, puis cliquez de nouveau sur Save pour enregistrer la règle de pare-feu. Enregistrer uniquement la boîte de dialogue NAT imbriquée ne termine pas la procédure.
5. Contrôlez la règle de pare-feu dans Firewall rules et la règle SNAT liée dans NAT rules ; notez les deux entrées et leurs Rule IDs. Vérifiez séparément l’ordre de chaque table. Une règle NAT correspondante placée plus haut peut être prioritaire ; l’association ne garantit pas la priorité.
6. Depuis un client autorisé, établissez une connexion réellement nouvelle vers la destination et le service permis, puis fermez normalement la connexion de test pour permettre la génération d’un journal de session. Filtrez ce flux dans Log Viewer et comparez Firewall Rule ID et NAT Rule ID aux identifiants notés. Si l’identifiant de pare-feu est incorrect, vérifiez d’abord les critères et l’ordre des règles de pare-feu ; si l’identifiant NAT est incorrect, vérifiez d’abord les règles NAT placées plus haut. La présence des deux entrées ne suffit pas à confirmer un accès Internet fonctionnel.

Points d’attention concernant le SNAT

Outre MASQ, Translated source (SNAT) accepte une IP unique ou une plage IP. La description SFOS 22 cite explicitement toute IP attribuée à une interface comme source possible et Add pour créer un objet IP/plage. La description des types NAT de SFOS 23 mentionne toujours les IP uniques et les plages ; l’absence de ces phrases dans sa description Add ne signifie pas que cette prise en charge a été retirée. L’adresse fixe doit être joignable dans votre environnement et compatible avec le retour attendu.

• Une plage configurée dans Translated source ne crée pas une correspondance individuelle fixe. SFOS choisit la prochaine adresse disponible dans cette plage.
• Une interface publique appartenant à un pont ne peut pas servir d’interface de SNAT. Si une interface déjà utilisée est ensuite ajoutée à un pont, SFOS supprime les règles SNAT qui la concernent.
• Override source translation for specific outbound interfaces permet de définir, dans une seule règle SNAT, une source traduite différente pour chaque interface de sortie. Cliquez sur Expand pour ajouter d’autres associations.
• Avec un VPN basé sur des routes dont les sous-réseaux local et distant sont réglés sur Any, ou avec une configuration dual-IP, MASQ peut utiliser l’adresse XFRM comme source à l’intérieur du tunnel. L’adresse WAN demeure visible dans l’en-tête externe du tunnel.

Avant de modifier un pont ou un pool SNAT en production, consignez les règles concernées, puis validez le résultat au moyen d’un nouveau flux réel.

DNAT, PAT, Loopback Rule et Reflexive Rule

Le DNAT modifie l’adresse de destination. Le PAT modifie en complément le service ou le port visé. Le protocole doit rester identique : un port TCP peut être traduit vers un autre port TCP, et un port UDP vers un autre port UDP, mais une traduction de TCP vers UDP est impossible.

Lorsque plusieurs services d’origine ou Any sont sélectionnés, Translated service (PAT) doit être Original. Une redirection de port explicite associe un service d’origine précis à un service traduit précis. Translated destination (DNAT) peut être une adresse IP ou un FQDN. La traduction de service autorise un seul port de destination ou un nombre égal de ports d’origine et traduits : plusieurs ports d’un même service d’origine vers un port (many-to-one), ou des ensembles de même taille (many-to-many). Many-to-many exige le même nombre de ports ; plusieurs services d’origine sélectionnés séparément ne permettent pas de traduction PAT. Le protocole doit toujours rester identique.

Règle de pare-feu associée au DNAT

Pour un flux entrant, SFOS identifie d’abord la règle DNAT correspondante, puis évalue la règle de pare-feu. Cette séquence impose une correspondance peu intuitive, mais essentielle :

• Destination zone: zone de la destination interne après DNAT, par exemple DMZ.
• Destination networks: adresse de destination publique avant DNAT.
• Services: sans PAT, service auquel le client accède. Avec PAT, l’exemple officiel de Sophos inclut dans la règle de pare-feu le service d’origine et le service traduit.

Dans le sens inverse, SFOS évalue d’abord la règle de pare-feu, puis applique la règle SNAT correspondante.

La règle NAT ne se substitue pas à cette règle de pare-feu. Pour une mise en œuvre complète du DNAT, avec restriction des sources, IPS, journalisation et test de recette depuis l’extérieur, consultez le Runbook DNAT.

Loopback Rule

Une Loopback Rule permet aux clients internes d’accéder au serveur au moyen de son adresse IP publique ou de son FQDN public. Le Split DNS est souvent plus simple : en interne, le même nom renvoie directement l’adresse privée du serveur, ce qui évite le Hairpin NAT.

Le Server Access Assistant ne crée une Loopback Rule que si une interface WAN du pare-feu est sélectionnée comme adresse publique et si External source networks and devices est défini sur Any. La saisie d’une adresse IP publique ou d’une source externe plus restrictive empêche la création automatique de cette règle.

Dans la configuration DNAT manuelle, Create loopback rule est une option distincte. La règle DNAT de départ doit utiliser Original source Any, Translated source (SNAT) MASQ et une Translated destination (DNAT) différente de Original. Ce ne sont pas les champs de l’assistant. Ne supprimez pas une restriction de sources externes uniquement pour obtenir le loopback : examinez d’abord le Split DNS ou une règle interne conçue séparément. Après enregistrement, testez séparément l’accès interne et les restrictions externes.

Reflexive Rule

Une Reflexive Rule génère la règle SNAT inverse d’une règle DNAT. Elle inverse les critères de correspondance et peut présenter les flux sortants du serveur avec l’adresse publique appropriée. Si la destination d’origine n’est pas une adresse IP ou si elle fait elle-même l’objet d’une traduction, la Reflexive Rule utilise MASQ comme source traduite.

Lors de la création manuelle d’un DNAT, Create reflexive rule génère cette règle miroir ; Create loopback rule est indépendante. Les règles générées utilisent l’identifiant et le nom de la règle initiale, mais restent distinctes. Pour le retour arrière, identifiez et désactivez chaque entrée générée séparément, puis vérifiez avec de nouvelles connexions internes et externes.

Les Loopback Rules et Reflexive Rules demeurent indépendantes. La modification ou la suppression de la règle DNAT d’origine ne les met pas à jour et ne les supprime pas automatiquement. Après tout changement de l’adresse publique, de la destination interne ou du service, contrôlez séparément les règles dérivées.

Lorsqu’une règle DNAT répartit le trafic entre plusieurs destinations internes, SFOS les considère toutes comme disponibles en l’absence de Health check. Ce contrôle est imposé avec First alive ; pour les autres méthodes de répartition, activez-le explicitement et configurez-le en ICMP ou en TCP selon le service, afin que SFOS ne dirige pas de nouvelles connexions vers un serveur indisponible.

Choisir la répartition entre plusieurs destinations DNAT

Choisissez Load balancing method selon le comportement attendu, pas seulement le nombre de serveurs :

• Round robin : les connexions sont distribuées dans l’ordre. Avec 10.10.10.1 à 10.10.10.3, la quatrième requête revient à .1. Cette méthode répartit les connexions sans persistance de session.
• First alive : toutes les requêtes vont au premier serveur disponible ; les autres sont des secours. Le Health Check détermine le basculement.
• Random : la sélection est aléatoire, sans association fixe d’un client.
• Sticky IP : un hash de la source et de la destination d’origine associe cette paire à un serveur. Avec Health Check activé, une destination disponible prend le relais en cas de panne. Au retour du serveur initial, seules les nouvelles connexions y reviennent ; les sessions existantes sont maintenues.
• One-to-one : première destination d’origine vers première destination traduite, deuxième vers deuxième, etc. Les deux listes doivent contenir autant d’adresses IP. C’est une association DNAT fixe, pas une allocation depuis un pool SNAT.

Pour Health check, choisissez Probe method ICMP ou TCP et, pour TCP, le port réellement à vérifier. Probe interval définit l’intervalle des contrôles, Response time-out le délai de réponse et Deactivate host after le nombre de tentatives infructueuses. Un ping confirme la joignabilité de l’hôte, pas le fonctionnement du service web. Adaptez ces délais au service : des valeurs trop sensibles peuvent exclure inutilement une destination lente. Avant la mise en production, vérifiez la répartition avec de nouvelles connexions, puis une panne et un retour planifiés. Sauvegardez la méthode et les valeurs précédentes pour le retour arrière.

Vérifier les conflits de ports avant publication

Avant de rediriger HTTPS, relevez les ports réellement configurés pour WebAdmin, User Portal et VPN Portal dans Administration > Admin and user settings. Ne déduisez pas le service occupant 443 d’un ancien guide NAT. WebAdmin et User Portal exigent chacun un port unique. Résolvez d’abord les conflits avec une autre IP publiée ou un autre port externe ; ne changez pas les ports d’administration sans préparation. Si nécessaire, assurez un accès d’administration indépendant, puis testez séparément les portails, les clients VPN et l’accès DNAT externe. Le guide DNAT accompagne la publication.

Linked NAT Rules et Server Access Assistant

Une Linked NAT Rule est toujours une règle SNAT associée à une règle de pare-feu. Tous les critères de correspondance de cette dernière continuent de s’appliquer, notamment les utilisateurs et les plages horaires. Dans la règle NAT, seules les sources traduites, y compris celles propres à une interface, peuvent être modifiées.

Cette association ne déroge pas à l’ordre normal d’évaluation du NAT : une règle NAT autonome placée plus haut dans la table peut s’appliquer en premier. Si une règle SNAT générique couvre déjà le même trafic, Sophos déconseille d’ajouter une Linked NAT Rule. En mode MTA, SFOS en crée toutefois une automatiquement.

Le Server access assistant (DNAT) crée une règle DNAT, une Reflexive Rule et une règle de pare-feu. Il n’ajoute une Loopback Rule que pour la combinaison décrite plus haut : une interface WAN et la source externe Any. L’assistant active les règles et les place en tête des tables. Contrôlez ensuite les sources, l’ordre des règles, les règles complémentaires générées et l’emploi éventuel d’une adresse IP alias. Dans ce dernier cas, l’assistant choisit d’abord l’interface physique comme source traduite des Reflexive Rules ou Loopback Rules ; pour utiliser l’adresse alias, sélectionnez manuellement l’objet IP Host correspondant.

Nettoyer prudemment les règles Linked MASQ migrées

Après migration, un avis peut apparaître sous le filtre. Delete linked NAT rules (only MASQ; Destination: WAN) supprime uniquement les règles liées dont la source traduite est MASQ et dont la règle de pare-feu utilise exclusivement la zone de destination WAN. Ce nettoyage n’est pas sans risque : utilisateurs, horaires et ordre précédent peuvent participer au comportement voulu.

Sauvegardez d’abord la configuration, les ID et les flux concernés. La règle désactivée Default SNAT IPv4 ou Default SNAT IPv6, ou une règle SNAT autonome conçue à cet effet, doit remplacer la traduction nécessaire à la bonne position. Contrôlez le remplacement et les restrictions de pare-feu, activez-le et comparez de nouveaux flux autorisés et interdits avant de supprimer les anciennes règles. En cas de différence, restaurez les règles et l’ordre sauvegardés. Understood. Don’t delete rules conserve les règles et masque définitivement l’avis ; X le masque temporairement. Dans le doute, documentez avant de supprimer.

Bien distinguer NAT, VPN et SD-WAN

Le NAT ne modifie pas la décision de routage. Même après traduction, SFOS doit disposer d’une route vers la destination. Pour un flux VPN, l’emplacement où configurer la traduction dépend également du type de tunnel :

• VPN IPsec basé sur des politiques : utilisez les paramètres NAT de la connexion IPsec pour traduire les sous-réseaux locaux et distants, en particulier lorsqu’ils se chevauchent. Si une règle SNAT supplémentaire doit traiter ce trafic, définissez son Outbound interface sur Any ; elle ne s’applique pas si des interfaces WAN précises sont sélectionnées.
• VPN IPsec basé sur des routes avec des sous-réseaux locaux et distants sélectionnés : utilisez les paramètres NAT de la connexion IPsec pour traduire ces sous-réseaux.
• VPN IPsec basé sur des routes avec Any/Any : utilisez les règles NAT pour traduire le trafic transféré.

Pour le trafic VPN dans les règles NAT, réglez Inbound interface sur Any. Pour les VPN et le DNAT d’IP publiques vers des IP privées, Outbound interface doit également être Any. Il s’agit d’une exigence de correspondance d’interface, pas d’une autorisation pour toutes les sources ou tous les services ; les critères Original et les règles de pare-feu les limitent toujours.

En règle générale, des réseaux qui ne se chevauchent pas n’ont pas besoin de NAT. En cas de chevauchement, documentez les réseaux réels et traduits de chaque côté ; à défaut, les enregistrements DNS, les règles et les journaux deviendront rapidement ambigus.

Pour appliquer un DNAT vers un serveur situé derrière un tunnel VPN IPsec basé sur des routes, Sophos décrit une configuration SD-WAN spécifique : la règle DNAT utilise MASQ comme Translated source afin que les réponses reviennent au pare-feu. La route SD-WAN utilise comme destination l’adresse WAN d’origine ou l’interface WAN et, si le PAT est activé, le port externe. L’objet de passerelle pointe vers l’interface XFRM. Ce cas particulier ne doit pas servir de modèle DNAT générique pour les serveurs locaux.

Atteindre un serveur distant avec DNAT et une route SD-WAN

Cette procédure IPv4 concerne uniquement un serveur derrière le pare-feu distant. Vérifiez d’abord les connexions IPsec basées sur des routes sur les deux pare-feu, l’état du tunnel, la connectivité distante, les sources autorisées, le service, le retour et l’ordre NAT/SD-WAN existant. Sauvegardez la configuration et les positions concernées. L’exemple utilise TCP 5555 à l’extérieur et TCP 443 à l’intérieur, pas du RDP public ; remplacez les adresses de documentation par vos valeurs. Une autorisation de pare-feu distincte et le durcissement restent nécessaires.

1. Dans Hosts and services > IP host > Add, créez Remote_Web : IP version IPv4, Type IP, IP address l’adresse du serveur distant, par exemple 172.16.16.10 ; Save.
2. Dans Routing > Gateways, IPv4 gateway > Add, choisissez un nom explicite. Réglez Gateway IP sur l’adresse de la passerelle distante, par exemple 10.12.13.2, et Interface sur son interface XFRM, par exemple xfrm1-10.12.13.1. Dans Monitoring condition, saisissez l’adresse IP d’un hôte réellement joignable derrière la passerelle ; contrôlez l’état de la passerelle et du tunnel avant publication.
3. Dans Rules and policies > NAT rules > Add NAT rule > New NAT rule, créez une règle IPv4 nommée. Limitez Original source aux sources externes autorisées. Réglez Original destination sur l’interface WAN publiée, par exemple #Port1, Translated source (SNAT) sur MASQ, Translated destination (DNAT) sur Remote_Web, Original service sur un objet TCP 5555 et Translated service (PAT) sur TCP 443. Dans ce cas VPN-DNAT, les deux champs d’interface doivent être Any. Vérifiez la position et sélectionnez Save. Dans ce cas particulier, MASQ assure le retour vers le pare-feu.
4. Dans Routing > SD-WAN routes, choisissez IPv4 > Add et un nom. Dans Destination networks, retirez Any et sélectionnez la même interface WAN d’origine #Port1, pas Remote_Web. Dans Services, retirez Any et sélectionnez le service externe TCP 5555, pas TCP 443. Dans Link selection settings, choisissez Primary and Backup gateways et réglez Primary gateway sur la passerelle distante ; ne choisissez une passerelle de secours que si son chemin distant existe réellement et a été contrôlé. Sélectionnez Save.
5. Établissez une nouvelle connexion depuis une source externe autorisée. Contrôlez les ID NAT/pare-feu, la destination et le service traduits, la sortie XFRM et les réponses dans la capture. Si la sortie est incorrecte, vérifiez les critères SD-WAN, l’ordre et la surveillance de la passerelle ; sans réponse, le service distant et le retour. Pour d’autres serveurs utilisant la même passerelle, étendez la même route SD-WAN avec leurs ports externes/adresses WAN ; utilisez des routes distinctes pour des passerelles différentes. Les combinaisons ajoutées doivent rester limitées par NAT et le pare-feu.

En cas d’échec, désactivez la nouvelle règle DNAT distante, supprimez la nouvelle route SD-WAN ou restaurez sa configuration précédente, puis rétablissez les positions. Ne supprimez pas les objets passerelle/hôte partagés. Annulez séparément les règles NAT dérivées et vérifiez le flux précédent avec une nouvelle connexion.

Traduire les flux générés par le pare-feu avec sys-traffic-nat

Les règles NAT de WebAdmin s’appliquent aux flux transférés. Pour traduire les flux émis par le pare-feu lui-même, ainsi que les adresses de ses interfaces, utilisez sys-traffic-nat dans la Device Console.

Les principaux cas d’usage de la traduction source par CLI sont :

• Envoyer les requêtes DHCP et d’authentification du pare-feu par IPsec site à site ; la traduction peut aussi faciliter les requêtes vers les services du pare-feu à travers les tunnels VPN. Elle ne remplace pas la configuration des services et du VPN.
• Utiliser des adresses alias lorsque les liens WAN sont plus nombreux que les interfaces WAN physiques, en traduisant l’interface physique vers l’alias approprié.
• Envoyer le trafic mail avec l’adresse source alias requise par le relais en amont ou l’enregistrement MX.
• Masquer les adresses internes aux destinations WAN, par exemple pour les requêtes DHCP d’une interface LAN ; utiliser une identité source précise vers des destinations MPLS internes ou certains serveurs web.

Notez au préalable la destination, l’identité source attendue, la route et les exigences du correspondant. Ensuite, déclenchez à nouveau le service réel et contrôlez l’adresse source et la réponse dans la capture. Une entrée CLI ne prouve pas à elle seule le fonctionnement du DHCP, de l’authentification ou du courrier.

⚠️ Cette commande de la Device Console modifie les flux générés par le système. Sauvegardez au préalable la sortie complète de show advanced-firewall. Les entrées NAT de la CLI sont traitées dans l’ordre où elles apparaissent.

Connectez-vous à la Command-line console et sélectionnez 4 – Device Console, pas Advanced Shell. L’exemple suivant utilise l’adresse IP alias 203.0.113.10 comme source des flux destinés à l’hôte 192.0.2.10 et sortant par Port1 :

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

La destination, le masque réseau, l’interface et l’adresse SNAT doivent correspondre à votre environnement. Pour un hôte unique, utilisez le masque 255.255.255.255 ; un masque moins restrictif couvre l’ensemble du réseau de destination correspondant. Si interface est omis, l’entrée s’applique aux flux dirigés vers la destination indiquée, quelle que soit l’interface du pare-feu qu’ils empruntent.

Pour annuler la configuration, reprenez l’ensemble des paramètres à l’identique avec delete :

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Par défaut, les flux générés par le système utilisent WAN Link Load Balancing. Avec une adresse IP alias, l’interface principale continue de déterminer la décision de routage ; sys-traffic-nat garantit uniquement que l’adresse alias voulue est présentée comme source. La présence de l’entrée confirme donc la configuration, mais ni la route, ni le chemin de retour, ni la disponibilité du service.

Modifier et valider les règles NAT en toute sécurité

Utiliser la table et les compteurs à bon escient

Dans Rules and policies > NAT rules, IPv4 ou IPv6 sélectionne la famille de règles. Disable filter masque le filtre, Enable filter l’affiche et Reset filter le réinitialise. Masquer le filtre ne désactive pas une règle NAT. Vérifiez que les bonnes entrées sont visibles avant toute modification.

Les règles sélectionnées peuvent être désactivées ensemble avec Disable ou supprimées avec Delete. Déplacez une règle à l’aide du Rule handle ; les règles précises doivent précéder les générales. More options propose l’interrupteur d’activation, la modification, la suppression et l’insertion d’une règle voisine. Unlink rule supprime le lien avec la règle de pare-feu : documentez d’abord cette dépendance et ne l’utilisez pas comme raccourci de diagnostic.

Reset usage count dans More options remet le compteur d’utilisation à zéro. Notez d’abord sa valeur et l’heure, puis générez un nouveau flux de test et vérifiez l’augmentation avec les Rule IDs ; un compteur seul n’identifie pas le flux testé. L’ancienne valeur n’est pas restaurée. Avant de modifier les règles, sauvegardez ID, critères, états et ordre, privilégiez la désactivation à la suppression et ne modifiez que les entrées sélectionnées. En cas de problème, restaurez états et positions, puis testez avec une nouvelle session ; une règle supprimée doit être recréée depuis la configuration sauvegardée.

SFOS n’évalue le NAT que sur le premier paquet d’une connexion. Lorsqu’une règle est modifiée ou déplacée, les sessions établies conservent leur traduction antérieure. Toute validation après changement doit donc établir une nouvelle connexion ; dans le cas contraire, le test risque de porter sur l’ancienne configuration.

Une validation fiable commence par la description précise du flux : source, destination, service, interfaces d’entrée et de sortie, ainsi que les valeurs attendues de Firewall Rule ID et de NAT Rule ID. Procédez ensuite comme suit :

1. Établissez une nouvelle connexion, puis filtrez les événements par source, destination et service dans Log Viewer.
2. Comparez les valeurs de Firewall Rule ID et de NAT Rule ID aux valeurs attendues.
3. Si la valeur de NAT Rule ID est incorrecte, contrôlez les règles placées plus haut, tous les champs Original et les interfaces.
4. Dans Diagnostics > Packet capture, vérifiez que le paquet arrive, puis repart avec les adresses attendues.
5. Contrôlez la route, le chemin de retour, le système de destination et le pare-feu local de ce dernier.

Pour le DNAT, effectuez au moins un test depuis un réseau externe. Un accès interne au nom public ne valide que le Split DNS ou la Loopback Rule, et non la publication effective depuis Internet.

Interpréter correctement les résultats

• Firewall Rule ID et NAT Rule ID correspondent aux valeurs attendues : les bonnes règles s’appliquent ; poursuivez l’analyse en examinant le système de destination, le chemin de retour et les Security Profiles.
• Firewall Rule ID est correct, mais NAT Rule ID ne l’est pas : une autre règle NAT est prioritaire ou les critères Original ne correspondent pas au paquet.
• Aucune NAT Rule ID alors qu’une traduction est attendue : aucune règle NAT ne correspond ; si la règle de pare-feu autorise le flux, celui-ci est transmis sans traduction.
• Firewall Rule ID est différent de la valeur attendue : contrôlez les zones, les réseaux, le service et l’ordre des règles de pare-feu.
• Aucune entrée dans le journal : la journalisation est désactivée ou le trafic n’atteint pas le pare-feu. Lancez une capture sur l’interface WAN ou l’interface d’entrée, puis vérifiez les routeurs en amont ou les règles de sécurité du cloud.
• La règle DNAT s’applique, mais le serveur ne répond pas : vérifiez le service sur le serveur, son pare-feu local, sa passerelle par défaut et l’éventuelle asymétrie du chemin de retour.

Pour approfondir le diagnostic, consultez Tester une règle de pare-feu, Analyser la correspondance des règles, Qualifier les paquets rejetés et Packet Capture dans WebAdmin.

Situer NATRule dans l’API XML

Pour les automatisations, NATRule représente le même modèle Original/Translated. La description de l’objet Add NAT policy / Edit NAT policy est identique dans les références SFOS 22 et SFOS 23 comparées. Cela atteste l’état de la documentation, et non la réussite de l’exécution sur un build donné. Avant toute tâche d’écriture, appliquez les règles centrales de sécurité de l’API XML : accès d’administration restreint, vérification TLS, compte de service distinct, secrets protégés, sauvegarde, requête de lecture et opération explicite sur Set, confirmée pour l’objet et le build installé. La description de l’objet ne constitue pas à elle seule une requête exécutable complète.

Critères de correspondance, traduction et identité de la règle

• OriginalSourceNetworks contient des entrées Network répétables pour les sources d’origine ; OriginalDestinationNetworks contient des entrées Network pour les destinations d’origine. OriginalServices contient des entrées Service répétables. Il s’agit de références à des objets pour la correspondance avant NAT, et non d’une autorisation de pare-feu. La référence indique une limite de 60 caractères pour chacun de ces noms de réseaux et de services.
• TranslatedSource, TranslatedDestination et TranslatedService sont chacun une valeur unique définissant la traduction. Pour un champ inchangé, l’exemple utilise Original ; pour le masquage de la source, MASQ. Les indications telles que IPAddress, IPRange, IPList, FQDN ou TCPUDP_Service décrivent dans l’exemple le type d’objet approprié, et non une valeur littérale quelconque à envoyer. Vérifiez les objets hôte, plage, liste, FQDN et service réellement présents, ainsi que leur prise en charge dans le build. Les limites du PAT décrites précédemment restent applicables. Pour la valeur ou le nom de l’objet de service dans TranslatedService, la table des paramètres indique explicitement un maximum de 60 caractères ; pour TranslatedSource et TranslatedDestination, cette table n’indique aucun maximum correspondant.
• InboundInterfaces et OutboundInterfaces contiennent chacun des entrées Interface répétables. Ils limitent la correspondance des interfaces, mais ne créent aucune route. Les conditions VPN/DNAT expliquées plus haut s’appliquent aussi aux automatisations : l’entrée et la sortie VPN utilisent Any ; pour le DNAT d’adresses publiques vers des adresses privées, la sortie est également Any. Cela ne supprime pas les restrictions imposées par les critères Original et les règles de pare-feu.
• Name, directement sous NATRule, est le nom obligatoire de la règle : 60 caractères au maximum, UTF-8 autorisé, aucune virgule. Description est facultatif et limité à 255 caractères. IPFamily accepte IPv4 ou IPv6 ; la référence indique IPv4 comme valeur par défaut. Status accepte Enable ou Disable ; l’état par défaut documenté est activé. Définissez explicitement la famille et l’état dans la charge utile d’écriture approuvée, plutôt que de vous fier aux valeurs par défaut sans les vérifier.
• Dans l’exemple, LinkedFirewallrule est prévu uniquement pour créer une Linked NAT Rule dans une requête Set. Identifiez précisément la règle de pare-feu existante à cet effet. Une association ne transforme pas la règle SNAT en règle DNAT et ne lui garantit aucune priorité ; les restrictions du Linked NAT restent applicables.

Planifier séparément la position et la substitution par interface

Position présente dans l’exemple XML les valeurs top, bottom, after et before avec cette casse. Pour un placement relatif, After ou Before contient son propre Name, qui indique le nom de la règle de référence. Ce nom n’est pas le nom obligatoire de la règle créée ou modifiée. L’exemple précise explicitement que les deux blocs ne s’appliquent qu’aux requêtes Set. Utilisez uniquement la référence adaptée au placement souhaité ; ne copiez pas aveuglément les deux blocs du modèle. Vérifiez au préalable l’existence et la position actuelle de la règle d’ancrage, puis contrôlez l’ordre réellement enregistré. Un statut d’objet indiquant une réussite ne prouve pas encore que le trafic prévu rencontre cette règle en premier.

OverrideInterfaceNATPolicy est un commutateur distinct acceptant Enable ou Disable, avec la valeur par défaut documentée Disable, et concerne la traduction de source SNAT propre à une interface. La liste InterfaceNATPolicyList correspondante ne fait partie du cas prévu que si la substitution est activée. Elle contient des blocs Override répétables avec specific_interface pour l’interface de sortie et specific_translatedsourceid pour la source traduite souhaitée sur cette interface. L’interface spécifique décrite comme obligatoire constitue donc une exigence dans ce cas conditionnel de substitution, et non une obligation pour chaque règle NAT.

Les commentaires du modèle mentionnent à un endroit le nom divergent OverrideInterfaceDefaultNATPolicy, alors que l’élément et la table des paramètres utilisent OverrideInterfaceNATPolicy. N’en déduisez pas une balise XML supplémentaire. La table décrit la liste comme facultative, avec la valeur par défaut NULL ; cela ne signifie pas qu’il faut envoyer le texte NULL. Le modèle ne fournit pas non plus d’emplacement d’insertion clair pour monitorindex, également mentionné à cet endroit. Si une automatisation dépend de ces détails non résolus, clarifiez-les avant toute écriture dans API help du build installé ou auprès du support ; ne devinez aucune syntaxe ni aucun effet supplémentaire.

Load Balancing et Health Checks : des champs conditionnels

NATMethod concerne le cas de répartition DNAT ; ce n’est pas un choix obligatoire pour une règle SNAT ordinaire. La référence API décrit son applicabilité avec la zone source WAN du Hosted Server et un Protected Server de type IP Range ou IP List. Ne reprenez pas ces anciennes désignations comme des champs XML supplémentaires absents du modèle. Les valeurs documentées sont Round-robin, First_alive, Random, StickyIP et OnetoOne ; la valeur par défaut de la référence est Sticky IP. L’aide au choix des cinq méthodes et l’exigence d’un nombre égal d’adresses pour One-to-one figurent plus haut.

HealthCheck accepte Enable ou Disable et est décrit dans la table API comme facultatif, avec la valeur par défaut OFF, et applicable uniquement au Load Balancing. Cela ne signifie pas que toute requête NAT nécessite des champs de Health Check. Cela ne garantit pas non plus que First_alive doive fonctionner sans contrôle : les guides NAT spécifiques imposent le Health Check pour First alive. Dans ce cas, planifiez explicitement le contrôle et ses valeurs, puis vérifiez-les dans l’état enregistré, plutôt que de vous fier à la valeur par défaut générale OFF.

Lorsque le Health Check est activé, les valeurs de contrôle figurent dans le bloc LoadBalance :

• ProbeMethod : ICMP ou TCP. L’indication de caractère obligatoire s’applique ici au cas où le contrôle est actif.
• Port : uniquement pour TCP, plage 1–65535 ; n’en déduisez pas une obligation générale de port pour ICMP.
• ProbeInterval : intervalle de contrôle en secondes, plage 5–65535, valeur par défaut documentée 60. La plage provient de la table des paramètres ; l’élément vide du modèle n’impose aucune valeur numérique propre.
• ResponseTimeOut : délai de réponse en secondes, plage 1–10, valeur par défaut documentée 2.
• DeactivateHostAfter : nombre de tentatives de contrôle infructueuses avant désactivation, facultatif, plage 1–10, valeur par défaut documentée 3.

Ne dissociez pas les indications de caractère obligatoire de la méthode, de l’intervalle et du délai de réponse de leur contexte de Health Check activé. Ces indications ne confirment elles aussi que le contrat API décrit. Le fonctionnement de la sonde, du service et du basculement souhaité doit être vérifié avec le nouveau flux décrit plus haut et un test planifié de panne et de retour.

Évaluer les réponses NATRule selon l’objet

Les correspondances suivantes proviennent de Status Message Information pour cet objet. Ce sont des codes de statut d’objet XML, et non des codes de statut HTTP. Les valeurs Message.* sont des clés de message non résolues de la référence, et non des textes de message vérifiés sur un pare-feu. Évaluez donc ensemble l’opération, le code, la réponse réelle et l’état enregistré ; ne déduisez pas du nom de la clé une limite ou la possibilité d’une nouvelle tentative sans risque.

• Add NAT policy : 200 est associé à Message.NATPolicyAddSuccess, 500 à Message.NATPolicyAddFail et 502 à Message.NATPolicyRecordExists.
• Edit NAT policy : 200 est associé à Message.NATPolicyUpdateSuccess, 500 à Message.NATPolicyUpdateFail et 502 à Message.NATRuleUpdateRecordExist. La clé 502 diffère notamment de celle de la création.

Les mêmes correspondances supplémentaires sont documentées pour les deux opérations Add NAT policy et Edit NAT policy :

En particulier, 504 ne doit donc pas être interprété ici comme un échec de suppression dû à une référence sur la seule base de la table API générale : ces lignes NATRule concernent Add/Edit et indiquent la clé de conflit de port. De même, les deux codes 548 et 549 ne prouvent aucun nombre maximal précis de serveurs, malgré leur clé identique.

Avant chaque nouvelle tentative d’écriture, même après un timeout ou une réussite supposée, lisez l’entrée NAT réellement enregistrée et vérifiez-la dans Rules and policies > NAT rules : nom, famille, état, valeurs Original/Translated, interfaces, associations de substitution, valeurs de contrôle conditionnelles et position. Comparez la réponse à l’état préalablement sauvegardé ; en cas de conflit, ne contournez pas le problème en renommant l’objet, en élargissant les critères ou en répétant aveuglément la requête. Toute différence non résolue doit interrompre la tâche. Ce n’est qu’après cette vérification de l’état que vous devez contrôler les deux Rule IDs et la traduction réelle avec une nouvelle session. Pour le retour arrière, restaurez l’état sauvegardé et l’ordre des règles, et prenez en compte séparément les règles dérivées ; la mise en œuvre pratique de la publication d’un serveur reste décrite dans le Runbook DNAT.

FAQ