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.

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.

Points d’attention concernant le SNAT

• 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) reste normalement défini sur Original. Une règle de redirection de port explicite associe un service d’origine précis à un service traduit précis.

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.

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.

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.

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.

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é.

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.

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.

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.

⚠️ 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.

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é

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.

FAQ