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

NAT fait partie des sujets Sophos Firewall qui deviennent vite confus en pratique. Les termes se ressemblent, l’éditeur de règles utilise Original et Translated, et Log Viewer peut afficher des adresses différentes selon l’endroit où l’on regarde.

Cet article explique les principaux types de NAT, montre des cas pratiques et décrit un exemple DNAT avec la Firewall Rule correspondante.

NAT traduit, il n’autorise pas

Network Address Translation modifie les adresses ou les ports d’un paquet pendant son passage à travers Sophos Firewall. NAT ne décide pas à lui seul si le trafic est autorisé.

⚠️ Une NAT rule n’autorise pas le trafic. Elle traduit uniquement des adresses ou des ports. Le trafic qui traverse la firewall a toujours besoin d’une Firewall Rule correspondante.

Cas typiques:

• Des clients internes accèdent à Internet via l’adresse WAN publique.
• Un serveur interne est publié via une adresse IP publique.
• Un port public est traduit vers un autre port interne.
• Des réseaux qui se chevauchent sont traduits pour des connexions VPN.
• Des clients internes accèdent à un serveur interne via son nom DNS public.

Les principaux types de NAT

NAT ne répond pas à la question « ce trafic est-il autorisé ? », mais à la question « à quoi doivent ressembler l’adresse ou le port pendant le traitement ? ».

Lire Original et Translated correctement

Dans les NAT rules, Original décrit le trafic lorsqu’il arrive sur Sophos Firewall. Translated décrit le trafic après la traduction.

En troubleshooting, il faut d’abord noter l’aspect du paquet avant NAT, puis définir ce que la firewall doit en faire.

Exemples pratiques: quand utiliser quoi?

SNAT: Source NAT

SNAT modifie l’adresse source. Le cas classique est l’accès Internet sortant depuis le LAN. Les clients conservent leurs IP privées en interne, mais apparaissent à l’extérieur avec l’adresse WAN de la firewall ou une autre IP publique définie.

Dans les environnements simples, une règle SNAT générique est souvent plus claire que de nombreuses Linked NAT Rules.

MASQ: Masquerading

MASQ est une variante pratique de SNAT. Par défaut, MASQ traduit l’adresse source vers l’adresse IP de l’interface sortante. Pour l’accès Internet normal, c’est généralement l’IP WAN.

Sophos Firewall contient une règle SNAT par défaut avec MASQ. Si cette règle n’est pas souhaitée, il est souvent préférable de la désactiver plutôt que de la supprimer, car elle peut réapparaître lors de la création ou de la mise à jour d’une interface WAN.

Attention: avec les route-based VPNs, MASQ peut se comporter autrement que prévu. Si les sous-réseaux locaux et distants sont définis sur Any ou si des configurations Dual IP sont utilisées, la firewall peut utiliser l’IP XFRM comme source traduite.

DNAT: Destination NAT

DNAT modifie l’adresse de destination. On l’utilise par exemple pour publier un serveur interne via une IP ou un port public.

Pour les services publics, NAT n’est qu’une partie du design. Il faut aussi vérifier le logging, IPS, les restrictions de source, la logique Geo-IP et l’état de patch du serveur cible. Une procédure détaillée se trouve dans Publier un serveur avec DNAT sur Sophos Firewall.

PAT: Port Address Translation

PAT modifie le service ou le port. Dans Sophos Firewall, le champ correspondant est Translated service (PAT).

Le client externe se connecte à un port public, tandis qu’un autre port est utilisé en interne. Le protocole doit rester cohérent: TCP vers TCP, UDP vers UDP.

Exemple pratique: publier Synology avec DNAT

Dans cet exemple, un service doit être accessible via une IP WAN publique. À l’extérieur, le service Synology_5555 est utilisé. En interne, le serveur écoute sur HTTPS. La règle NAT traduit donc la destination publique vers le serveur interne et le service public vers le service interne.

Les interfaces d’administration comme NAS, RDP, SSH ou WebAdmin ne devraient être exposées directement que si c’est vraiment nécessaire. Dans de nombreux cas, VPN ou ZTNA est préférable.

Règle DNAT champ par champ

Firewall Rule correspondante

Une règle DNAT ne suffit pas. Il faut aussi une Firewall Rule qui autorise le trafic.

Si les utilisateurs sont mondiaux et que la source ne peut pas être restreinte, il faut durcir autrement: n’ouvrir que les ports nécessaires, activer IPS, logging, maintenir le système cible à jour et utiliser MFA, VPN ou ZTNA si possible.

💡 Les services publics sont souvent scannés très rapidement par des bots. Sophos Firewall Threat Feeds aide à bloquer tôt des IP, domaines ou URLs malveillants connus.

Loopback Rule: accès interne via le nom DNS public

Une Loopback Rule est nécessaire lorsque des clients internes doivent atteindre un serveur interne via son IP publique ou son FQDN public. Sans loopback, le trafic part du LAN vers l’IP publique de la firewall et doit revenir vers le serveur interne.

Dans les environnements simples, Split DNS est souvent plus propre: en interne, service.example.com pointe directement vers l’IP interne du serveur. Si Split DNS n’est pas possible, une Loopback Rule peut être utile.

Reflexive Rule: trafic sortant du serveur publié

Une Reflexive Rule est une règle SNAT créée automatiquement pour une règle DNAT. Elle peut être utile si le serveur publié doit apparaître en sortie avec une IP publique précise.

Pour une réponse normale à une connexion DNAT entrante, une Reflexive Rule séparée n’est généralement pas nécessaire. Le stateful firewalling gère les paquets de réponse de la connexion existante.

⚠️ Si une règle DNAT est modifiée plus tard, les Loopback ou Reflexive Rules créées automatiquement ne sont pas toujours adaptées comme prévu. Il faut les contrôler après les changements.

Server Access Assistant ou règle manuelle?

Server Access Assistant peut créer automatiquement des règles DNAT, loopback, reflexive et Firewall Rules. C’est pratique pour publier rapidement un service.

En production, les règles manuelles sont souvent plus faciles à comprendre: source restrictions gérées consciemment, NAT rule plus claire, position et logging définis proprement, modifications ultérieures moins surprenantes.

Linked NAT Rules

Une Linked NAT Rule est créée depuis une Firewall Rule. Elle apparaît dans la table NAT comme règle Source NAT.

Limites importantes:

• La plupart des critères de matching viennent de la Firewall Rule.
• Seuls certains champs NAT peuvent être modifiés.
• Une règle NAT plus générale placée au-dessus peut matcher avant elle.
• Trop de Linked NAT Rules rendent la table difficile à lire.

Pour de nouvelles configurations simples, une règle autonome sous Rules and policies > NAT rules est généralement plus compréhensible.

Load balancing et Health Check avec DNAT

Si plusieurs serveurs internes sont configurés comme Translated destination, la firewall peut distribuer le trafic.

Pour que la firewall détecte la disponibilité d’un serveur, Health check doit être activé.

Ordre des règles NAT

Sophos traite les NAT rules de haut en bas. La première règle correspondante gagne.

Recommandations:

• DNAT spécifiques en haut
• SNAT spécifiques au-dessus des règles MASQ générales
• positionner consciemment la Default SNAT rule
• vérifier régulièrement les Linked NAT Rules
• supprimer ou désactiver les anciennes règles de migration inutiles

Vérifier NAT et Firewall Rule ensemble

Un trafic fonctionnel nécessite routing vers la firewall, NAT rule correspondante, Firewall Rule correspondante, chemin retour correct, Security Profiles adaptés et absence de blocage en amont.

Pour DNAT, point essentiel: les Firewall Rules utilisent la destination zone après NAT, mais le destination network avant NAT. C’est souvent la clé du troubleshooting.

Troubleshooting

1. Ouvrir Log viewer et filtrer par Source IP, Destination IP et service.
2. Vérifier Firewall Rule ID et NAT Rule ID.
3. Vérifier la position de la NAT rule.
4. Vérifier la position de la Firewall Rule.
5. Utiliser Diagnostics > Packet capture pour voir si les paquets arrivent et ressortent.
6. Pour une analyse plus profonde, consulter nat_rule.log, firewall_rule.log et fwlog.log.
7. En contexte VPN ou XFRM, vérifier aussi charon.log, strongswan.log et xfrmi.log.

Si la NAT rule ne correspond toujours pas, La règle firewall ne s’applique pas: vérifier ordre, matching et logs et Utiliser Packet Capture dans WebAdmin aident à isoler la cause. Les services et logs sont expliqués dans Sophos Firewall Troubleshooting: Services et logs. Pour le support, les logs peuvent être exportés avec Sauvegarder les logs Sophos Firewall pour le support et l’analyse.

Informations complémentaires

• Sophos Firewall - Add a NAT rule
• Sophos Firewall - Add a DNAT rule with server access assistant
• Sophos Firewall - Create DNAT and firewall rules for internal servers
• Sophos Firewall - Create an SNAT rule