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.

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

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 d’abord contrôler sous Network > Dynamic DNS si l’état et l’adresse IP mise à jour sont plausibles.

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.

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.