Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT

NAT est l’un des sujets du Sophos Firewall qui devient rapidement déroutant dans la pratique. Les termes semblent similaires, le masque de règles fonctionne avec Original et Translated, et dans Log Viewer, vous voyez des adresses différentes de celles attendues en fonction de l’emplacement.

Cet article explique les types NAT les plus importants, présente des cas pratiques typiques et décrit un exemple DNAT avec une règle de pare-feu appropriée.

Le point pratique le plus important est le suivant : NAT doit être pris en compte avec la règle de pare-feu, le routage, le chemin de retour et la journalisation. De nombreux problèmes NAT ne proviennent pas de la traduction elle-même, mais d’un ordre incorrect des règles, d’un Original destination mal compris, d’une journalisation manquante ou de tests provenant du mauvais réseau.

Orientation

Avant de créer une règle NAT, il convient de déterminer clairement quel problème est réellement résolu. NAT traduit les adresses ou les ports, mais ne remplace pas la suppression du pare-feu et une conception de routage propre.

Quel article NAT convient ?

NAT chevauche rapidement les règles de pare-feu, le routage, WAF, VPN et Packet Capture. Selon la tâche, cet article de base n’est pas toujours la meilleure façon de commencer :

Comprendre NAT, SNAT, DNAT, MASQ, PAT, Loopback et les règles réflexives : cet article.
Publier un serveur interne par redirection de port : Publier un serveur par DNAT sur Sophos Firewall.
Publier une application HTTP ou HTTPS : Sophos Firewall WAF : publier un serveur Web en sécurité.
Classer ensemble les règles de pare-feu et NAT : Comprendre et configurer les règles Sophos Firewall en sécurité.
Tester une connexion individuelle avec les journaux et Packet Capture : Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.
Vérifier NAT pour IPsec, XFRM, SD-WAN ou des réseaux qui se chevauchent : Dépannage IPsec VPN Sophos Firewall.
Analyser les drops, Violation, Rule ID ou NAT Rule ID : Analyser les paquets rejetés par Sophos Firewall.

Cela rend le dépannage plus précis : clarifiez d’abord s’il s’agit de traduction, de publication, de routage, de protection du serveur Web ou de flux de paquets. Après cela, seul le calque concerné doit être modifié.

NAT est une traduction, pas une version

La Traduction d’adresses réseau modifie les adresses ou les ports d’un paquet lors de son passage via le Sophos Firewall. Cependant, NAT ne décide pas seul si le trafic est autorisé.

⚠️ Une règle NAT n’autorise pas le trafic. La règle traduit uniquement les adresses ou les ports. Une règle de pare-feu appropriée est également toujours requise pour le trafic via le pare-feu.

Cas typiques du NAT :

Les clients internes accèdent à Internet via le public WAN-IP.
Un serveur interne est publié via un IP public.
Un port public est traduit vers un autre port interne.
Les réseaux qui se chevauchent sont traduits pour les connexions VPN.
Les clients internes accèdent à un serveur interne via le nom DNS public.

Décision rapide : NAT ou pas de NAT ?

De nombreuses erreurs NAT surviennent car NAT est utilisé comme solution par défaut, même si un routage ou une règle de pare-feu suffirait. Avant chaque nouvelle règle NAT, vous devez d’abord décider si une adresse ou un port doit réellement être modifié.

Le client du LAN devrait accéder à Internet normalement : Une règle générale SNAT ou MASQ est généralement suffisante.
Le serveur interne doit être accessible depuis Internet : Utilisez DNAT ou pour HTTP/HTTPS, vérifiez d’abord WAF.
Un port différent doit être utilisé en externe qu’en interne : Planifiez DNAT avec PAT et ajoutez la règle de pare-feu appropriée.
Les utilisateurs internes accèdent au même nom de domaine complet public : Vérifiez d’abord le DNS divisé, utilisez le bouclage NAT uniquement si nécessaire.
Les réseaux VPN locaux et distants sont clairs : N’utilisez généralement pas NAT, mais créez proprement des règles de routage et de pare-feu.
Les réseaux VPN se chevauchent ou la station distante nécessite une source spécifique : Utilisez SNAT ou DNAT ciblé avec un réseau de remplacement documenté.
Une seule règle de pare-feu doit être autorisée ou restreinte : Ne créez pas NAT. Ajustez la règle de pare-feu.

Si la réponse à la question « Que faut-il traduire ? » n’est pas clair, une règle NAT ne doit pas être créée. Vérifiez ensuite d’abord le flux de paquets, l’adresse de destination, le chemin de retour et Log Viewer. Surtout pour les VLAN internes, les VPN site à site sans réseaux superposés et les réseaux de serveurs routés, aucun NAT n’est souvent la solution la plus propre.

Comprendre les bases de NAT

Le masque de règles devient beaucoup plus simple si vous faites d’abord la différence entre le trafic d’origine et le trafic traduit. Il sera alors plus clair si la source, la destination ou le service doit être modifié.

Les principales espèces NAT

SNAT : Traduit la source IP. Généralement lorsque les clients ou serveurs internes sont censés accéder à Internet avec un IP public spécifique.
MASQ : Traduit le IP source en IP de l’interface sortante. Il s’agit du cas standard pour LAN à WAN.
DNAT : Traduit la destination IP. Cela rend un serveur interne accessible via un IP public.
PAT : Traduit le port ou le service. Cela signifie qu’un port externe pointe vers un autre port interne.
Loopback NAT : Permet l’accès interne via IP public ou FQDN public. Les clients internes utilisent le même nom DNS que les utilisateurs externes.
Règle réflexive : Crée une règle source réfléchissante NAT. Cela permet à un serveur publié d’apparaître au trafic sortant avec une identité publique appropriée.

En tant que modèle mental, cela aide : NAT ne répond pas à la question « Ce trafic est-il autorisé ? », mais plutôt « À quoi devrait ressembler l’adresse ou le port en cours de route ? »

Lisez l’original et traduit correctement

Dans les règles NAT, Original décrit le trafic tel qu’il arrive au Sophos Firewall. Translated le décrit après traduction.

Original source : Adresse source avant NAT.
Translated source (SNAT) : Adresse source vers NAT.
Original destination : Adresse cible avant NAT.
Translated destination (DNAT) : Adresse cible après NAT.
Original service : Service ou port avant NAT.
Interfaces et VPN : Any est souvent correct pour les interfaces entrantes et sortantes dans les scénarios DNAT ou VPN, car les tunnels VPN ne sont pas toujours traités comme des interfaces physiques normales.
Service traduit (PAT) : Service ou port vers NAT.

S’il y a des erreurs, vous devez d’abord noter à quoi ressemble le package avant NAT. Ensuite, vous définissez ce que le pare-feu doit en faire.

Planifiez NAT avant le changement

Avant d’effectuer une modification NAT, vous ne devez pas seulement examiner la règle NAT elle-même. L’ensemble du flux de paquets est crucial : où arrive le paquet, quelle règle de pare-feu autorise le trafic, quelle règle NAT le traduit, où va la réponse et comment le résultat est-il vérifié ?

Ces points doivent être clairs avant le changement :

Package avant NAT : La source, la destination et le service doivent correspondre au côté Original de la règle NAT.
Package selon NAT : Translated source, Translated destination et Translated service doivent être réglés délibérément.
Règle de pare-feu d’autorisation : NAT n’autorise pas le trafic. Sans règle de pare-feu adaptée, la traduction reste inefficace.
Règles NAT plus générales : La première règle NAT correspondante l’emporte. Une règle SNAT ou MASQ large peut masquer des règles plus spécifiques.
Chemin de retour : De nombreux problèmes NAT sont en fait des problèmes de routage, de chemin de retour ou de système de destination.
Méthode de test : Log Viewer, ID de règle, NAT Rule ID et Packet Capture doivent être préparés avant le test.

Comprendre et configurer en toute sécurité les règles Sophos Firewall vous aide à trouver la bonne règle de pare-feu. S’il n’est pas clair si la règle s’applique, La règle Sophos Firewall ne s’applique pas : vérifier les causes est le meilleur début de dépannage.

Exemples pratiques : Quand utilisez-vous quoi ?

Les clients du LAN doivent accéder à Internet : MASQ ou SNAT. Exemple : 10.10.10.80 sort avec le pare-feu WAN-IP.
Le serveur Web interne doit être accessible depuis l’extérieur : DNAT. Exemple : Le public WAN-IP pointe vers 172.16.16.10.
Un port différent est utilisé en externe et en interne : PAT. Exemple : TCP 5555 externe, TCP 443 interne.
Les utilisateurs internes utilisent le même FQDN que les utilisateurs externes : Loopback NAT. Exemple : service.example.com pointe vers le même service en interne et en externe.
Le serveur publié doit apparaître sortant avec un IP public spécifique : SNAT ou une règle réflexive. Exemple : Un serveur de messagerie envoie avec le public défini IP.
Les réseaux VPN se chevauchent : SNAT ou DNAT. Exemple : le site A voit le site B via un réseau traduit.
Le trafic interne doit rester inchangé : Non NAT. Les règles de routage et de pare-feu sont suffisantes.

Tout le trafic n’a pas besoin de NAT. Entre les VLAN internes, sur les VPN site à site sans chevauchement de réseaux ou vers les réseaux directement routés, NAT est souvent même nuisible car les journaux, les stations distantes et les systèmes cibles perdent la véritable source IP. Une bonne planification NAT décide donc d’abord si une traduction doit être effectuée.

Types en pratique

Les types NAT suivants résolvent différentes tâches. Dans les environnements productifs, il convient de sélectionner consciemment la traduction nécessaire au lieu d’utiliser NAT comme solution générale aux problèmes de routage.

SNAT : source NAT

SNAT modifie l’adresse source. Le cas classique est celui de l’accès Internet sortant depuis le LAN. Les clients conservent en interne leurs adresses IP internes, mais l’adresse publique du pare-feu ou un IP public défini apparaît en externe.

Règle SNAT typique pour LAN à WAN :

Original source : LAN interne ou réseau de serveur.
Translated source (SNAT) : MASQ ou IP public fixe.
Original destination : Any.
Translated destination (DNAT) : Original.
Original service : Any ou Services défini.
Service traduit (PAT) : Original.
Inbound interface : interface interne ou Any.
Interface sortante : Interface WAN. Pour les environnements simples, une règle SNAT générique est souvent plus claire que de nombreuses règles NAT liées individuelles.

MASQ : mascarade

MASQ est une variante pratique du SNAT. Par défaut, MASQ traduit l’adresse source en adresse IP de l’interface sortante. Pour un accès Internet normal, il s’agit généralement du WAN-IP.

Dans la configuration de base, le Sophos Firewall possède une règle SNAT par défaut avec MASQ. Si vous ne souhaitez pas utiliser cette règle, la désactivation est généralement plus simple que la suppression. Dans le cas contraire, la règle par défaut risque de réapparaître lors de la création ou de la mise à jour d’une interface WAN.

Pierre d’achoppement : avec les VPN basés sur les routes, MASQ peut avoir un aspect différent de celui attendu. Si les sous-réseaux locaux et distants sont définis sur Any ou si des configurations doubles IP sont utilisées, le pare-feu peut utiliser XFRM-IP comme source traduite. Dans Packet Capture ou tcpdump, vous pouvez alors voir le WAN-IP dans l’en-tête externe et le XFRM-IP dans le contexte interne. D’autres obstacles s’appliquent au IPsec basé sur des politiques. Si le trafic traduit doit être attribué à un tunnel IPsec spécifique, les routes IPsec et le paramètre Interface sortante dans les règles SNAT peuvent être critiques. Le processus se trouve dans IPsec Créer un itinéraire sur Sophos Firewall.

NAT sur VPN, SD-WAN et réseaux superposés

NAT devient rapidement plus complexe dans les environnements VPN et SD-WAN que le simple trafic LAN vers WAN. Le principe le plus important reste le même : premièrement, le chemin attendu doit être clair. Vous décidez ensuite si NAT est nécessaire.

Scénarios typiques :

VPN de site à site avec des réseaux uniques : Généralement pas de NAT, mais des règles de pare-feu et un routage propres.
VPN de site à site avec réseaux superposés : Règle SNAT ou DNAT ciblée avec réseau de sauvegarde documenté.
VPN basé sur l’itinéraire avec XFRM et SD-WAN : Vérifiez ensemble l’interface XFRM, l’itinéraire, l’itinéraire SD-WAN et NAT.
IPsec basé sur une stratégie avec trafic traduit : Vérifiez l’itinéraire IPsec et la règle SNAT avec Outbound interface correspondant.
Remote Access VPN vers les réseaux internes : Normalement pas de NAT, sauf si un système cible attend une source spécifique.

Pour les réseaux superposés, NAT ne s’improvise pas. Les deux parties doivent savoir quel réseau réel se cache derrière quel réseau traduit. Sinon, les tests individuels fonctionnent, mais les applications, le DNS, la journalisation ou les règles d’accès deviennent difficiles à comprendre par la suite. Si un tunnel VPN est vert mais qu’aucun trafic utile ne passe, NAT n’est qu’une cause possible parmi d’autres. Il faut alors vérifier en parallèle l’état IPsec, Route Lookup, la règle de pare-feu, la route SD-WAN et Packet Capture. Pour une procédure structurée, utilisez Dépannage IPsec VPN Sophos Firewall, routage SD-WAN pour Reply Packets et System Traffic et vérifier MTU et MSS sur Sophos Firewall en cas de problèmes VPN.

DNAT : destination NAT

DNAT modifie l’adresse de destination. Par exemple, vous pouvez publier un serveur interne via un IP public ou un port public. Le trafic entrant vers l’adresse WAN est traduit vers le serveur interne.

Règle DNAT typique :

Original source : Any ou réseaux source définis IP.
Original destination : Objet hôte WAN-IP ou WAN.
Original service : service externe, par exemple HTTPS ou Synology_5555.
Translated destination (DNAT) : serveur interne.
Service traduit (PAT) : Original ou port de destination interne.
Translated source (SNAT) : principalement Original.
Inbound interface : Interface Any ou WAN.
Interface sortante : principalement Any et DNAT.

Pour les services publics, vous devez non seulement créer NAT, mais également vérifier immédiatement la journalisation, l’IPS, les restrictions de source, la logique géo-IP et le niveau de correctif du serveur cible. Des instructions étape par étape plus détaillées sont disponibles dans l’article Publier le serveur sur Sophos Firewall via DNAT. Pour les applications HTTP et HTTPS, vous devez également vérifier si un Sophos Firewall WAF convient mieux qu’un DNAT pur. DNAT est une redirection de port. WAF peut inclure des noms d’hôte, des certificats, des chemins, des profils de protection Web et éventuellement une authentification. Pour les services simples non HTTP, DNAT reste souvent correct ; pour les applications Web accessibles au public, WAF constitue souvent un meilleur point de départ.

PAT : Traduction d’adresse de port

PAT modifie le service ou le port. Sur le Sophos Firewall, le champ Service traduit (PAT) en est responsable.

Exemple :

TCP 5555 externe vers TCP 443 interne.
TCP 20120 externe vers TCP 22 interne.
TCP 8443 externe vers TCP 443 interne.

Le client externe se connecte à un port public, mais en interne, un autre port est adressé. Important : le protocole doit être correct. TCP peut être traduit en TCP, UDP en UDP. Une traduction de TCP vers UDP n’est pas une redirection de port propre.

Exemple DNAT avec règle de pare-feu

L’exemple montre la publication typique d’un service interne. Ce qui est crucial est que la règle NAT et la règle de pare-feu correspondent.

Exemple pratique : publier Synology via DNAT

Dans l’exemple, un service doit être accessible via un WAN-IP public. Le service Synology_5555 est adressé de l’extérieur. En interne, le serveur écoute HTTPS. Ainsi la règle NAT traduit l’adresse publique de destination vers le serveur interne et le service public vers le service interne.

Sophos Firewall Add NAT rule avec DNAT et PAT Exemple de service Synology — Sophos Firewall - DNAT Règle avec service public et port de destination interne

Sophos Firewall Add firewall rule correspondant à la règle DNAT avec les sources WAN et le SERVEUR réseau cible — Sophos Firewall - Règle de pare-feu correspondant à la règle DNAT

L’exemple est volontairement technique. Les interfaces de gestion telles que NAS, RDP, SSH ou WebAdmin ne doivent être publiées directement que si cela est vraiment nécessaire. Dans de nombreux cas, VPN ou ZTNA constituent la meilleure solution.

Règle DNAT champ par champ

Rule name : Nommez clairement, par exemple DNAT_SYNOLOGY_5555.
Description : Documentez pourquoi la règle existe et qui l’a créée. Cela aidera énormément plus tard.
Rule position : Les règles spécifiques doivent être placées au-dessus des règles générales.
Original source : Peut être restreint dans la règle NAT. En pratique, il est souvent plus propre de maintenir la restriction de source dans la règle de pare-feu afin que la même restriction ne doive pas être maintenue deux fois.
Original destination : L’adresse de destination publique avant NAT. Il est préférable d’utiliser un objet hôte pour le WAN-IP plutôt que l’interface WAN directement. Un objet hôte reste généralement plus stable lors des modifications ou des ajustements de l’interface.
Original service : Le service ou le port accessible de l’extérieur, par exemple Synology_5555.
Translated source (SNAT) : Pour les règles DNAT classiques, généralement Original. Ne changez que si le serveur interne doit voir le pare-feu comme source. Mais alors vous perdez le vrai client IP.
Translated destination (DNAT) : Le serveur interne ou une liste de serveurs vers lesquels rediriger.
Service traduit (PAT) : Le service interne ou le port sur lequel être réécrit, par exemple HTTPS. Si aucun changement de port n’est nécessaire, le service reste Original.
Inbound interface : Interface par laquelle le trafic entre. Pour DNAT, souvent Any ou WAN. Any est souvent requis pour les contextes VPN car les VPN ne sont pas traités comme des interfaces normales.
Interface sortante : Pour DNAT, généralement Any, car le pare-feu décide du routage et de la zone cible.

Créer une règle de pare-feu pour la règle DNAT

Une règle DNAT ne suffit pas. De plus, une règle de pare-feu est requise pour autoriser le trafic.

Pour DNAT, c’est important : la règle de pare-feu fait référence au trafic dans le contexte DNAT. Cela semble inhabituel au début, surtout avec les zones cibles et les réseaux cibles.

Source zones : Généralement WAN lorsque l’accès provient d’Internet.
Source networks and devices : Si possible, pas Any si cela peut être évité. Mieux vaut utiliser des pays, des adresses IP individuelles, des réseaux, des hôtes FQDN ou des groupes.
Destination zones : La zone de la cible interne, par exemple SERVER ou DMZ, pas simplement WAN.
Destination networks : L’adresse de destination publique ou l’objet hôte WAN de Original destination.
Services : Le service externe de Original service, c’est-à-dire le port auquel les clients accèdent de l’extérieur.
Log firewall traffic : Activer pour les services publiés. Sans journalisation, le Log Viewer n’est pas utile avec cette règle. Si les utilisateurs globaux ont besoin d’un accès et que Source networks and devices ne peut pas être restreint de manière significative, vous devez quand même renforcer la règle : ouvrez uniquement les ports requis, activez IPS, activez la journalisation, maintenez le système cible à jour et utilisez MFA, VPN ou ZTNA si possible.

💡 Les services accessibles au public sont souvent scannés très rapidement par des robots. Sophos Firewall Threat Feeds aide à bloquer rapidement les adresses IP, domaines ou URL malveillants connus. Cela ne remplace pas une règle claire, mais réduit considérablement le trafic inutile des robots.

Règle de bouclage : accès en interne via le nom DNS public

Une règle de bouclage est requise si les clients internes doivent atteindre un serveur interne via son IP public ou son FQDN public.

Exemple :

En externe, service.example.com pointe vers le public WAN-IP.
En interne, les clients utilisent le même nom service.example.com.
Sans bouclage, le trafic du LAN va vers le IP public du firewall et doit remonter vers le serveur interne.

Dans les environnements simples, le DNS divisé est souvent plus propre : en interne, service.example.com pointe directement vers le serveur interne IP. Dans ce cas, vous n’avez pas besoin de Hairpin-NAT. Si le DNS divisé n’est pas possible, une règle de bouclage peut avoir du sens.

Avec Server Access Assistant, le Sophos Firewall peut créer automatiquement des règles de bouclage. Cependant, cela ne fonctionne que sous certaines conditions, par exemple si l’interface WAN est utilisée comme publique IP et que les sources externes sont généralement définies de manière appropriée. Avec les règles manuelles, le bouclage doit être planifié consciemment puis testé.

Règle réflexive : mettre en miroir le trafic sortant du serveur

Une Règle réflexive est une règle SNAT générée automatiquement pour la règle DNAT. Cette règle peut être utile si vous souhaitez que le serveur publié apparaisse en commençant par un IP public spécifique. Important : Les réponses normales à une connexion DNAT entrante ne nécessitent généralement pas de règle réflexive distincte. Le pare-feu avec état garantit que les paquets de réponse appartiennent à la connexion existante.

Vous ne devez activer les règles réflexives que si vous en comprenez le but. Dans les environnements comportant plusieurs adresses IP WAN, plusieurs règles DNAT ou plusieurs serveurs, une règle SNAT supplémentaire peut autrement entraîner un comportement difficile à comprendre.

⚠️ Les règles Loopback ou Reflexive générées automatiquement restent des règles indépendantes. Si la règle DNAT d’origine est modifiée ou supprimée ultérieurement, ces règles dérivées ne sont pas mises à jour automatiquement de manière logique. Après chaque modification de la règle d’origine, les règles Loopback et Reflexive associées doivent être vérifiées manuellement.

Fonctionnalités avancées du NAT

Ces options ne sont pas nécessaires dans tous les environnements. Ils deviennent importants lorsque les clients internes utilisent le même nom public, que plusieurs serveurs cibles sont impliqués ou que des règles NAT sont créées à partir de règles de pare-feu.

Assistant d’accès au serveur ou règle manuelle NAT ?

Server Access Assistant peut créer automatiquement des règles DNAT, de bouclage, de réflexion et de pare-feu. Ceci est utile si vous souhaitez publier rapidement un service.

Pour les environnements productifs, les règles manuelles sont souvent plus faciles à comprendre :

Vous pouvez voir exactement quelle règle fait quoi.
Les restrictions de sources sont délibérément maintenues dans les règles du pare-feu.
La règle NAT reste plus fine.
La position des règles et la journalisation sont définies proprement.
Les changements ultérieurs sont moins surprenants.

L’Assistant est utile, mais ne remplace pas la compréhension des règles individuelles.

Règles NAT liées

Une Règle NAT liée est créée à partir d’une règle de pare-feu. Il s’agit d’une règle source NAT dans la table des règles NAT.

Cela semble pratique, mais cela a des limites :

La plupart des critères de correspondance proviennent de la règle du pare-feu.
Dans la règle NAT vous ne pouvez ajuster que certains champs NAT.
Une règle NAT plus générale ci-dessus peut toujours correspondre en premier.
De nombreuses règles NAT liées rendent rapidement la table NAT confuse.

Pour les nouvelles configurations simples, une règle NAT indépendante dans Rules and policies > NAT rules est généralement plus compréhensible. Les règles NAT liées sont particulièrement utiles dans des scénarios de migration ou des cas particuliers très ciblés.

Équilibrage de charge et Health Check à DNAT

DNAT peut faire plus qu’une simple redirection de port. Si plusieurs serveurs internes sont stockés sous Translated destination, le pare-feu peut répartir le trafic.

Méthodes possibles :

Round robin : distribution simple sans persistance de session.
Premier vivant : serveur principal avec basculement.
Aléatoire : distribution aléatoire.
Sticky IP : la même combinaison source-destination reste sur le même serveur.
One-to-one : affectation fixe entre la destination originale et la destination traduite. Si vous souhaitez que le pare-feu détecte si un serveur cible est disponible, le Vérification de l’état doit être activé. Sans Health Check, le pare-feu considère les serveurs comme disponibles même s’ils ne répondent pas.

Ordre DNAT

Sophos traite les règles NAT de haut en bas. La première règle correspondante gagne. Après cela, les autres règles NAT ne seront plus vérifiées.

Recommandation :

Règles spécifiques DNAT
Règles spécifiques SNAT au-dessus des règles générales MASQ
Positionner consciemment la règle SNAT par défaut
Vérifiez régulièrement les règles liées NAT
Supprimez ou désactivez les anciennes règles de migration si elles ne sont plus nécessaires

Une commande éprouvée dans de nombreux environnements ressemble à ceci :

Trou noir DNAT ou règles de blocage pour les sources indésirables connues, si de telles règles sont utilisées.
Règles DNAT très spécifiques pour les services publiés.
Règles spéciales SNAT pour serveurs individuels, réseaux partenaires ou cas particuliers VPN.
Des règles de bouclage ou de réflexion lorsqu’elles sont consciemment nécessaires.
Règles générales SNAT ou MASQ pour un accès Internet normal.

Il ne s’agit pas d’une loi stricte, mais c’est un bon cadre de test. Le flux de test spécifique est toujours crucial. Si une règle MASQ large ou une ancienne règle NAT liée est placée au-dessus d’une règle spécifique, la nouvelle règle semble correcte mais n’est jamais atteinte. Lorsque vous apportez des modifications, vous devez non seulement vérifier la règle elle-même, mais également les règles situées directement au-dessus et en dessous d’elle.

Pour les services publics, une règle de trou noir DNAT avant la règle productive DNAT peut être utile si certaines mauvaises listes ou pays IP doivent être interceptés précocement. Le processus est décrit dans Sophos Firewall : Bloquer les pays et les adresses IP malveillantes.

NAT modifiez et vérifiez en toute sécurité

Les modifications NAT modifient le flux des paquets. C’est pourquoi vous devez le traiter comme un changement productif : préparez, testez, enregistrez et annulez proprement si nécessaire.

Déployez les modifications NAT en toute sécurité

Les modifications NAT affectent souvent immédiatement le trafic productif. Ceci est particulièrement critique pour les serveurs publiés, les cas particuliers VPN, plusieurs adresses WAN-IP ou les règles de pare-feu utilisées par des partenaires externes. Par conséquent, NAT ne doit pas être traité comme un pur changement d’objet, mais plutôt comme un petit changement avec un chemin de test et de secours.

Avant d’effectuer un changement productif, vous devez brièvement noter :

NAT Rule ID précédent et nom de la règle : Dans le Log Viewer, vous pouvez ensuite vérifier si la nouvelle règle s’applique réellement.
Flux de test attendu : La source, la destination, le service et la direction doivent être clairs avant d’être enregistrés.
Règle de pare-feu dépendante : NAT et la règle de pare-feu doivent correspondre mais être vérifiées séparément.
Chemin de secours : En cas de problèmes, la nouvelle règle peut être désactivée et l’ancienne règle peut être réactivée.
Fenêtre de test : Les services externes, les sites distants VPN ou les accès partenaires ne doivent pas être interrompus inaperçus.

Lors de modifications majeures, nous vous recommandons de dupliquer d’abord les règles NAT existantes ou de créer une nouvelle règle spécifique au-dessus d’elles au lieu de convertir directement la seule règle qui fonctionne. L’ancienne règle reste initialement désactivée ou reste en dessous à titre de référence. Après un test réussi, il peut être supprimé ou clairement documenté.

La position de la règle est également importante : une nouvelle règle spécifique SNAT ou DNAT n’est d’aucune utilité si une règle plus générale ci-dessus correspond déjà au même trafic. Par conséquent, la modification inclut toujours un test de visionneuse de journaux avec Firewall Rule ID et NAT Rule ID attendus. Pour les services accessibles de l’extérieur, le test ne doit pas être effectué uniquement à partir de votre propre LAN. Un test interne pour le FQDN public vérifie souvent le bouclage ou le DNS divisé, mais pas l’accès réel depuis Internet. L’acceptation du DNAT nécessite au moins un test externe, par exemple via des communications mobiles, un emplacement externe ou un test de port contrôlé.

Vérifiez ensemble NAT et la règle de pare-feu

Une erreur de réflexion courante est la suivante : « La règle NAT est correcte, elle devrait donc fonctionner. » Ce n’est qu’à moitié vrai.

Pour que le trafic fonctionne, vous avez besoin de :

Routage vers le pare-feu
règle NAT appropriée si une traduction est nécessaire
règle de pare-feu appropriée
itinéraire de retour correct
profils de sécurité appropriés
aucun blocage en amont, par exemple le routeur du fournisseur, le groupe de sécurité cloud ou le pare-feu cible Ce qui suit s’applique également à DNAT : Les règles de pare-feu pour le trafic DNAT utilisent la zone cible après NAT, mais l’adresse cible publique avant NAT comme réseau cible. C’est justement ce point qui est crucial dans de nombreux dépannages.

Lisez correctement Firewall Rule ID et NAT Rule ID

Dans le cas des erreurs NAT, vous ne devez pas seulement vérifier si une entrée de journal existe. Ce qui est crucial est de savoir si l’entrée du journal correspond à la règle de pare-feu attendue et à la règle NAT attendue. Pour cette raison, Firewall Rule ID et NAT Rule ID sont plus utiles que le nom de la règle seul, car les noms peuvent être modifiés, choisis de la même manière ou coupés dans les captures d’écran.

Une courte interprétation aide :

Firewall Rule ID attendu et NAT Rule ID attendu visibles : La correspondance des règles est fondamentalement correcte. Vérifiez ensuite le chemin de retour, le système cible, le profil de sécurité et l’application.
Firewall Rule ID attendu visible, mais NAT Rule ID incorrect : La règle de pare-feu correspond, mais l’ordre NAT ou les critères NAT ne correspondent pas. Vérifiez la position de la règle NAT, les champs Original et les règles NAT plus générales.
Autre Firewall Rule ID visible : Une autre règle de pare-feu l’emporte. Vérifiez l’ordre des règles de pare-feu, les zones, la source, la destination et le service.
Aucun NAT Rule ID visible, bien que NAT soit attendu : Aucune règle NAT n’a été appliquée ou le mauvais type de journal ou flux est affiché. Vérifiez les critères NAT, la direction et le flux de test réel.
Aucune entrée de journal visible : La journalisation est manquante ou le trafic n’atteint pas le pare-feu. Vérifiez la journalisation des règles, le routeur du fournisseur, VLAN, Gateway et Packet Capture. Surtout avec DNAT, un seul test réussi ou échoué sans comparaison d’ID ne suffit pas. Vous devez noter quels ID sont attendus, exécuter le test exactement une fois, puis comparer Log Viewer et Packet Capture. Si les ID ne correspondent pas aux attentes, la correspondance et l’ordre sont corrigés en premier, pas le serveur cible.

Erreurs NAT courantes

Lorsque vous traitez des problèmes NAT, il est utile de ne pas reconstruire les règles immédiatement. Tout d’abord, il convient de classer le défaut observé.

Aucune entrée de journal dans Log Viewer : Le trafic n’atteint pas le pare-feu, la journalisation est manquante ou le filtre est incorrect. Vérifiez le routeur du fournisseur, le groupe de sécurité cloud, le client Gateway, la journalisation des règles de pare-feu et les filtres.
Entrée de journal sans NAT Rule ID attendu : La règle NAT ne correspond pas ou une règle supérieure l’emporte. Original source, Original destination, vérifiez le service et la commande NAT.
La règle DNAT correspond, la connexion ne fonctionne toujours pas : Règle de pare-feu, serveur de destination, route de retour ou pare-feu du serveur local bloqué. Comparez Firewall Rule ID, Packet Capture et les journaux du serveur.
L’accès interne au FQDN public ne fonctionne pas : Le DNS divisé ou le bouclage NAT est manquant. Vérifiez la résolution DNS interne et décidez si le DNS divisé ou le bouclage est plus propre.
Le client externe voit une source incorrecte-IP : SNAT ou la règle réflexive change de source de manière inattendue. Vérifiez Translated source (SNAT) et les règles générées automatiquement.
Le trafic VPN utilise une source inattendue IP : L’itinéraire SNAT, XFRM, SD-WAN ou l’itinéraire IPsec ne correspondent pas. Vérifiez la recherche d’itinéraire, l’itinéraire SD-WAN, l’itinéraire IPsec et la position de la règle NAT.
Port public pointant vers un mauvais service interne : PAT ou l’objet de service n’est pas défini correctement. Comparez Original service et Translated service (PAT). Cette vue d’ensemble ne remplace pas l’analyse du flux de paquets, mais il fait gagner du temps : il sépare les problèmes devant le pare-feu, dans la logique NAT, dans la règle du pare-feu et sur le système cible.

Test d’acceptation après les modifications NAT

Après une modification NAT, vous ne devez pas seulement vérifier si un seul ping ou un site Web fonctionne une seule fois. Le test doit correspondre au type de traduction.

Pour SNAT ou MASQ :

Définissez le client de test et le service cible.
Vérifiez la règle de pare-feu avec Log firewall traffic.
Dans Log Viewer, vérifiez quels Firewall Rule ID et NAT Rule ID sont en vigueur.
Sur le système cible ou le service de test externe, vérifiez quelle source IP est visible.
Testez le chemin de retour et le comportement de la session sur plusieurs liens WAN.

Pour DNAT ou PAT :

Effectuez le test depuis l’extérieur de votre propre réseau, et pas uniquement depuis le LAN.
Comparez la cible publique IP, le port externe et le serveur cible interne.
Vérifiez Log Viewer Firewall Rule ID et NAT Rule ID.
Utilisez Packet Capture pour vérifier si les paquets arrivent et continuent vers le serveur interne.
Vérifiez sur le serveur cible si le pare-feu local, le service et la route de retour sont corrects.

Pour VPN-NAT :

Vérifiez l’état du tunnel et les associations de sécurité.
Définissez un flux de test concret avec la source, la destination et le service.
Vérifiez la position de la règle NAT et la recherche d’itinéraire.
Utilisez Packet Capture des deux côtés si le site distant autorise l’accès.
Incluez les journaux de l’application ou du système cible afin que non seulement le côté pare-feu soit évalué.

Surtout dans les sites éloignés, un seul scénario de test doit être modifié par modification. Si la règle de pare-feu NAT, la route SD-WAN et le système cible sont ajustés en même temps, un test réussi peut difficilement être expliqué plus tard.

Dépannage

Cette commande aide à résoudre les problèmes NAT :

Ouvrez Visionneuse de journaux et filtrez par Source IP, Destination IP et Service.
Vérifiez quels Firewall Rule ID et NAT Rule ID sont affichés.
Vérifiez la position de commande du NAT.
Vérifiez la position de la règle de pare-feu.
Utilisez Diagnostics > Packet capture pour vérifier si les paquets arrivent et continuent.
Pour une analyse plus approfondie, vérifiez nat_rule.log, firewall_rule.log et fwlog.log.
Pour le contexte VPN ou XFRM, vérifiez également charon.log, strongswan.log et xfrmi.log. Si la règle NAT ne fonctionne toujours pas, La règle du pare-feu ne fonctionne pas : vérifier l’ordre, la correspondance et les journaux et Utiliser l’outil Packet Capture dans WebAdmin vous aideront à la réduire. Les noms de service et les fichiers journaux pertinents sont disponibles dans Dépannage Sophos Firewall : Services et journaux. Pour les cas de support, vous pouvez exporter les journaux avec Sophos Firewall Enregistrer les journaux pour le support et l’analyse.

Liste de contrôle des règles NAT

La règle NAT a un nom et une description uniques.
Le but, la personne responsable et le dernier examen sont documentés.
Les champs Original et Translated ont été testés par rapport à un flux de test réel.
La règle NAT est supérieure aux règles NAT plus générales.
Des règles de pare-feu appropriées sont en place et la journalisation est active.
Les Firewall Rule ID et NAT Rule ID attendus ont été vérifiés dans Log Viewer.
Pour DNAT, la zone cible est définie correctement après NAT et le réseau cible avant NAT.
DNAT a été testé en externe, pas seulement en interne LAN.
Pour les services publics, les restrictions de source, IPS, l’alternative WAF et le niveau de correctif ont été vérifiés.
Pour VPN-NAT, le routage, l’itinéraire IPsec, SD-WAN et les réseaux superposés sont documentés.
Le bouclage ou le DNS divisé est une décision consciente.
Les règles réflexives ne sont actives que si le trafic sortant du serveur doit réellement être mis en miroir.
Les règles NAT anciennes ou temporaires sont désactivées ou supprimées.

FAQ

Une règle NAT autorise-t-elle automatiquement le trafic ?

Non. NAT traduit uniquement l’adresse ou le port. Une règle de pare-feu appropriée décide également si le trafic est autorisé.

Pourquoi DNAT ne fonctionne-t-il pas même si la règle NAT semble correcte ?

Souvent, la règle de pare-feu appropriée est manquante, la règle utilise le mauvais réseau de destination pour DNAT, une règle plus générale NAT se trouve au-dessus ou le serveur interne ne répond pas correctement.

Quand devez-vous utiliser MASQ au lieu d’un SNAT-IP fixe ?

MASQ convient bien à un accès Internet normal via l’interface sortante. Un SNAT-IP fixe est logique si un serveur ou un emplacement doit toujours apparaître aux systèmes externes avec une adresse publique spécifique.

Avez-vous besoin de NAT pour les connexions VPN ?

Pas fondamentalement. Pour les réseaux uniques, le routage sans NAT est généralement plus propre. NAT est particulièrement pertinent pour les réseaux qui se chevauchent, les exigences particulières des stations distantes ou certains cas particuliers IPsec basés sur des politiques.

Le Split DNS est-il meilleur que le Loopback NAT ?

Souvent oui. Si les clients internes peuvent résoudre le même FQDN directement sur le serveur interne IP, le DNS fractionné est généralement plus simple et plus transparent. Le bouclage NAT est logique si le DNS divisé n’est pas possible ou n’est pas souhaité sur le plan opérationnel.

Devez-vous publier des applications Web publiques via DNAT ?

Pas automatiquement. Pour les applications HTTP et HTTPS, WAF doit être vérifié en premier. DNAT est plus adapté à la simple redirection de port, aux protocoles spéciaux ou aux cas dans lesquels le pare-feu ne doit pas assurer la protection du serveur Web.