Configurer et vérifier Dynamic DNS sur Sophos Firewall

Sous Network > Dynamic DNS > Add, un nom d’hôte du fournisseur DDNS est associé à l’interface WAN correspondante. Si Sophos Firewall porte directement l’adresse IPv4 publique, il faut sélectionner Use port IP. Si son adresse WAN est privée derrière un routeur, il faut sélectionner NATed public IP.

Dynamic DNS met uniquement à jour l’enregistrement DNS. Il n’ouvre aucun port et ne crée aucune règle NAT ou de pare-feu. Pour rendre accessible un serveur interne situé derrière le pare-feu, il faut également appliquer correctement les étapes de publication d’un serveur avec DNAT.

Le même nom d’hôte peut également représenter une adresse WAN IPv4 publique dynamique pour une Sophos DNS Protection Location. La requête A externe décrite ci-dessous doit d’abord renvoyer l’adresse IPv4 WAN actuelle ; il faut ensuite vérifier l’affectation propre à la Location comme indiqué dans Gérer les Sophos DNS Protection Locations en toute sécurité. L’entrée DDNS à elle seule n’affecte aucune Filtering Policy et ne modifie pas le chemin DNS des clients.

Configurer Dynamic DNS

Il faut au préalable disposer d’un nom d’hôte enregistré auprès du fournisseur, tel que vpn.example.net, et d’identifiants de mise à jour valides. Le pare-feu doit pouvoir résoudre les requêtes DNS et accéder à Internet ainsi qu’au fournisseur. Dynamic DNS ne fonctionne donc pas dans un environnement isolé.

Ouvrir Network > Dynamic DNS, puis cliquer sur Add.
Sous Hostname, saisir le nom créé auprès du fournisseur, par exemple vpn.example.net. Respecter la syntaxe de domaine et de sous-domaines exigée par le fournisseur ; le format n’est pas identique chez tous les fournisseurs. Avant d’enregistrer, vérifier également ses exigences concernant le nom de connexion.
Sélectionner l’Interface WAN correspondante, par exemple Port2 - WAN.
Sous IPv4 address, sélectionner Use port IP ou NATed public IP.
Sélectionner le Service provider.
Saisir le Login name et le Password, ou la clé de mise à jour propre au fournisseur.
Enregistrer avec Save, puis vérifier l’état.

La boîte de dialogue SFOS actuelle propose DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS et Cloudflare. L’ancien service Sophos myfirewall.co a été abandonné. Selon le fournisseur, Password ne désigne pas le mot de passe habituel du compte : DynDNS utilise l’Updater Client Key, tandis que ZoneEdit et EasyDNS utilisent un Dynamic Token. DynAccess, No-IP, DNS-O-Matic, Google DDNS et Namecheap utilisent un nom d’utilisateur et un mot de passe. Si un fournisseur n’exige aucun nom d’utilisateur, Sophos indique de saisir le domaine comme Login name. Pour FreeDNS, le mot de passe saisi dans SFOS ne doit pas dépasser 15 caractères ; Cloudflare constitue l’exception avec une adresse e-mail et une Global API Key.

Avant l’étape 6, préparer le nom d’hôte et les identifiants de mise à jour dans le compte du fournisseur :

DynDNS : Dans le compte DynDNS, My Services > DynDNS Pro > Add New Hostname permet de créer un nom d’hôte avec le domaine du fournisseur choisi. La clé de mise à jour se trouve sous Account Settings > Updater Client Key. Si le champ est vide, utiliser Generate Key. Attention : une nouvelle clé remplace les anciens identifiants des clients de mise à jour DDNS existants ; il faut également leur fournir cette nouvelle clé. Dans SFOS, saisir le nom d’utilisateur DynDNS comme Login name et la clé comme Password, et non le mot de passe du compte.
ZoneEdit : Dans le panneau de contrôle ZoneEdit, ouvrir DNS et sélectionner l’icône de clé à molette de DYN RECORDS. Définir HOST et TTL, cliquer sur ENABLE pour DYN AUTHENTICATION TOKEN, poursuivre avec NEXT, puis confirmer les modifications. Dans SFOS, utiliser le nom d’utilisateur ZoneEdit et le jeton dynamique à la place du mot de passe du compte.
EasyDNS : Dans le panneau de contrôle EasyDNS, ouvrir MANAGE > DNS SETTINGS > MODULAR EDITOR pour le domaine et modifier DYNAMIC RECORDS. Définir le nom d’hôte et le TTL, créer le Dynamic Authenticated Token avec ENABLE, sélectionner NEXT, puis confirmer les modifications. Le service souscrit doit prendre en charge Dynamic DNS. Si un enregistrement A existe déjà, ne confirmer sa conversion que s’il doit réellement devenir dynamique. Dans SFOS, utiliser le nom d’utilisateur EasyDNS et le jeton à la place du mot de passe du compte.
FreeDNS : Vérifier les noms d’hôte nécessaires sous sous-domaines FreeDNS. Les identifiants indiqués ci-dessus et la limite de 15 caractères du mot de passe restent applicables dans SFOS.

Les clés de mise à jour et les jetons, tout comme les mots de passe, ne doivent figurer ni dans les captures d’écran ni dans les tickets de support.

Use port IP ou NATed public IP

Use port IP : l’interface WAN sélectionnée porte elle-même l’adresse IPv4 publique.
NATed public IP : l’interface WAN possède une adresse privée et un routeur en amont effectue la traduction NAT. Pour déterminer l’adresse publique, le pare-feu doit également pouvoir joindre checkip.cyberoam.com via TCP 80.

Les interfaces bridge ne prennent pas en charge Dynamic DNS. Si des interfaces WAN sont modifiées ou remplacées, il faut contrôler les dépendances sous Object usage, puis vérifier l’entrée DDNS. Utiliser correctement les zones et les interfaces explique les autres limites des interfaces.

Connecter Cloudflare en toute sécurité

Le fournisseur Cloudflare intégré exige l’adresse e-mail du compte et la Global API Key. La documentation Sophos actuelle ne mentionne pas les jetons API restreints comme identifiants compatibles.

Cloudflare classe la Global API Key comme méthode héritée : elle possède les mêmes autorisations que l’utilisateur et accède à ses ressources. Pour l’intégration SFOS, il faut donc utiliser un utilisateur Cloudflare distinct, limité à la zone requise et au rôle DNS. La clé ne doit apparaître ni dans les captures d’écran ni dans les tickets. Si la politique de sécurité interdit une Global API Key, il faut utiliser à la place un programme de mise à jour externe avec un jeton API restreint ou un autre fournisseur pris en charge.

Pour les VPN et les autres services qui connectent directement les clients à l’adresse IP publique du pare-feu, l’enregistrement Cloudflare doit être réglé sur DNS only. Si le proxy est activé volontairement, la requête DNS renvoie à la place des adresses anycast Cloudflare ; dans ce cas, il faut vérifier l’adresse IP d’origine associée au DDNS dans le tableau de bord Cloudflare.

Vérifier la résolution DDNS et le service

SFOS vérifie toutes les cinq minutes si l’adresse IP publique a changé. Après l’enregistrement, il faut contrôler sous Network > Dynamic DNS les colonnes Last updated IP, Last updated status, Last updated time et, en cas d’échec, Failure reason. Last updated IP correspond à la dernière adresse envoyée au fournisseur ; seule une requête DNS externe indique l’adresse réellement publiée.

Le nom d’hôte est ensuite interrogé à l’aide d’un résolveur extérieur au cache DNS local. Sous Linux et macOS :

dig @1.1.1.1 vpn.example.net A +short

Sous Windows :

nslookup vpn.example.net 1.1.1.1

La réponse doit correspondre à l’adresse IPv4 publique attendue. Juste après un changement, un résolveur peut encore renvoyer l’ancienne adresse en raison du TTL et du cache DNS.

Enfin, il faut tester le service réel depuis un autre réseau, par exemple via une connexion mobile. Une réponse DNS correcte confirme uniquement la résolution du nom, pas l’accessibilité du service.

Annuler une modification

Si l’entrée ne fonctionne pas comme prévu, la modifier sous Network > Dynamic DNS à l’aide de Manage, puis rétablir l’interface, le choix de l’adresse IP, le fournisseur et les identifiants précédents. Si le DDNS n’est plus nécessaire, supprimer l’entrée et rétablir manuellement la valeur DNS voulue chez le fournisseur. La suppression arrête uniquement les futures mises à jour DDNS ; elle ne supprime ni les règles DNAT ni les règles de pare-feu, et ne rétablit pas automatiquement l’enregistrement DNS publié par le fournisseur. Vérifier ensuite de nouveau la réponse DNS externe et le service.

Multi-WAN, HA et CGNAT

Après un basculement WAN ou HA, il faut toujours vérifier l’état DDNS, la réponse DNS externe et le service.

Multi-WAN : chaque entrée DDNS est liée à une interface sélectionnée. Il ne faut pas supposer qu’un nom d’hôte unique suit automatiquement la passerelle active. Pour les services publiés, il faut prévoir un nom d’hôte distinct par WAN.
HA : les journaux de dépannage ne sont pas synchronisés entre les nœuds. Configurer la haute disponibilité de Sophos Firewall explique le test de basculement complet.
CGNAT : NATed public IP peut publier l’adresse partagée du fournisseur, mais ne rend pas le pare-feu accessible depuis Internet. Il faut pour cela, par exemple, une véritable adresse IPv4 publique, un enregistrement AAAA géré séparément avec une configuration IPv6 appropriée du pare-feu et du service, ou un tunnel ou un relais établi depuis l’intérieur. Le DDNS SFOS décrit ici met uniquement à jour IPv4.

Résoudre les problèmes

Dans Log Viewer, sélectionner Events et System, puis rechercher le composant DDNS. Les valeurs techniques des champs sont log_type=Event, log_subtype=System et log_component=DDNS ; les champs déterminants sont Status, Message et Failure reason. L’option 4 Device Console affiche également les dernières entrées :

show logs ddc.log lines 100

Pour une analyse en direct, utiliser la commande suivante sous Device Management > Advanced Shell dans le menu SSH, puis l’arrêter avec Ctrl+C :

tail -f /log/ddc.log

Les commandes et leur association avec ddc.log sont documentées pour SFOS 22, mais n’ont pas été exécutées sur le pare-feu d’un client pour cet article. D’autres fichiers journaux et méthodes d’accès sont répertoriés sous Journaux de service de Sophos Firewall.

Invalid Configuration or bad authorization : vérifier le nom d’hôte, le fournisseur et les identifiants. Cloudflare exige l’adresse e-mail du compte et la Global API Key.
Invalid IP : vérifier l’interface et la sélection Use port IP ou NATed public IP.
DNS Error ou Connect Failed : vérifier le DNS, la Default Route, l’accès à Internet et l’accessibilité du fournisseur. Pour NATed public IP, vérifier également la connectivité au service de contrôle de l’adresse IP décrit ci-dessus.
Invalid Response ou Reported Abuse : vérifier l’état du fournisseur, le compte, les blocages et les limites du fournisseur.
Success, mais adresse IP incorrecte : comparer le tableau de bord du fournisseur, l’interface sélectionnée, l’option IP et la réponse DNS externe.
Le FQDN est correct, mais le service reste inaccessible : vérifier la redirection de port en amont, la règle DNAT, la règle de pare-feu et la configuration du VPN ou du service concerné.

Si Cloudflare DDNS ne fonctionne plus que depuis la mise à niveau vers SFOS 22.0 MR1, il faut installer SFOS 22.0 MR2 Build 546 ou une version ultérieure, puis effectuer un nouveau test. Sophos corrige ainsi NC-180219 ; les détails figurent dans l’article consacré à SFOS 22 MR2.