Sophos Firewall comme relais NTP via NAT

Lorsque des équipements internes doivent utiliser l’adresse IP de la passerelle comme destination NTP, Sophos Firewall peut transmettre leurs requêtes à un serveur de temps via NAT. Le réglage Administration > Time synchronise uniquement l’horloge du pare-feu ; il ne fournit pas de service NTP aux clients.

Sophos documente pour cela un relais NTP via NAT. Les équipements envoient leurs requêtes NTP à l’adresse IP du pare-feu. Sophos Firewall traduit la source et la destination, puis transmet les paquets à un véritable serveur de temps externe ou interne. Il ne devient pas pour autant la source de temps. Séparément, il agit comme client NTP pour synchroniser sa propre horloge.

Ce relais est particulièrement utile lorsque des équipements sont configurés avec une adresse de passerelle fixe comme destination NTP, qu’un ancien environnement UTM a été remplacé ou que l’on souhaite contrôler les destinations NTP de manière centralisée. Pour les nouvelles conceptions DHCP, il est souvent plus simple de distribuer le bon serveur de temps directement via l’option DHCP. Les bases peuvent être trouvées dans Configurer les options DHCP sur Sophos Firewall.

⚠️ Important : Le Sophos Firewall ne doit pas fournir de service NTP ouvert sur Internet. Les zones sources, les réseaux sources, les serveurs cibles et les règles de pare-feu doivent être délibérément restreints. Utiliser WAN comme Source Zone est généralement incorrect pour ce modèle.

Quelle variante convient ?

NTP via NAT est un modèle pragmatique, mais pas toujours la meilleure architecture.

Deux variantes sont importantes pour cet article :

• Variante A : Les appareils internes utilisent l’adresse IP du pare-feu comme serveur NTP, le pare-feu redirige vers un serveur NTP externe.
• Variante B : Les appareils internes utilisent l’adresse IP du pare-feu comme serveur NTP, le pare-feu redirige vers un serveur NTP interne. De plus, le serveur NTP interne doit être autorisé à se synchroniser en externe.

La deuxième variante comporte donc deux chemins de données distincts. Si la synchronisation externe du serveur de temps interne dispose déjà des autorisations et de la traduction appropriées, on vérifie et réutilise la paire de règles existante ; il n’est pas nécessaire de créer des règles identiques supplémentaires.

Prérequis

Avant la configuration, ces points doivent être clairs :

• Quels réseaux internes sont autorisés à utiliser NTP ?

• Quelle adresse IP les clients utilisent-ils comme destination NTP, par exemple l’adresse IP de la passerelle ?

• Quel vrai serveur NTP utiliser ?

• Faut-il utiliser un serveur de temps interne ou un service externe tel que time.google.com ou pool.ntp.org ?

• Le pare-feu peut-il résoudre de manière fiable le DNS pour les cibles FQDN ?

• L’heure système du pare-feu est-elle correctement synchronisée ? Un exemple IPv4 cohérent permet de clarifier les correspondances :

• net_Internet-LAN : 10.10.11.0/24, entrée des clients sur Port2 dans la zone du réseau client interne.

• host_internal-firewall-ip : hôte 10.10.11.1, adresse du pare-feu utilisée par ces clients.

• host_Google-NTP : FQDN time.google.com pour la variante A et, si nécessaire, comme source de temps externe du serveur interne.

• NTP_Server_Internal : hôte 192.168.20.10, accessible via Port3 dans la zone DMZ, pour la variante B.

Ces adresses privées, noms d’objets et interfaces sont des exemples à remplacer par les valeurs réelles. On sélectionne uniquement les réseaux qui ont besoin du relais et leurs interfaces d’entrée réelles ; pour IOT_NET, on ajoute au besoin une règle distincte tout aussi restrictive. On crée les objets réseau et hôte sous Hosts and services > IP host. Avec plusieurs adresses de passerelle, les réseaux sources, les entrées et les destinations correspondantes doivent rester cohérents. Avant toute modification, on relève les règles NAT et de pare-feu existantes, leur ordre et la source de temps des clients ; le véritable serveur de temps doit être accessible et accepter les requêtes provenant de l’adresse du pare-feu utilisée par MASQ.

Une heure correcte est importante pour les fonctions sensibles au temps : MFA, authentification WAF, certificats, journaux, VPN et corrélation SIEM. Si le pare-feu lui-même a une heure incorrecte, l’heure du système doit d’abord être vérifiée avant de rediriger Client-NTP.

Les étapes suivantes se réfèrent à la documentation officielle de Sophos Firewall 22.0 (sources vérifiées le 17.10.2026). Aucun test sur un équipement n’a été effectué pour ce guide. Les paramètres NTP du pare-feu ne peuvent pas être synchronisés depuis Sophos Fusion (anciennement Sophos Central) : on les configure dans WebAdmin, par CLI ou par API. Les étapes NAT et firewall ci-dessous utilisent WebAdmin.

Les exemples utilisent volontairement une configuration IPv4, avec IP version: IPv4 sélectionné lors de la création de l’hôte. Dans les environnements IPv6 ou dual-stack, ce modèle ne doit pas être copié tel quel. Il faut d’abord clarifier si les clients ont vraiment besoin de NTP via IPv6, quelles fonctions firewall et NAT s’appliquent dans la version SFOS utilisée, et si DHCPv6, Router Advertisements ou un serveur de temps interne direct constituent la solution la plus propre.

Référence rapide

Pour les admins expérimentés, la logique courte est simple: les clients envoient UDP 123 vers l’IP du firewall ou de la passerelle. Une règle DNAT réécrit la destination vers le vrai serveur NTP, une règle de pare-feu autorise exactement ce trafic, puis Log Viewer confirme la Firewall Rule ID et la NAT Rule ID.

Serveur NTP externe : une règle DNAT transfère NTP de l’adresse du pare-feu vers l’objet FQDN ou hôte du serveur externe. Une règle de pare-feu autorise NTP depuis les sources internes concernées vers WAN. Dans son exemple générique, Sophos laisse Original destination sur Any. Pour le relais vers l’adresse de passerelle décrit ici, limiter ce champ à l’adresse exacte du pare-feu utilisée par les clients. Les requêtes NTP directes vers d’autres serveurs ne seront ainsi pas redirigées à leur insu.

Serveur NTP interne: deux chemins sont nécessaires. D’abord, le serveur NTP interne doit pouvoir se synchroniser vers l’extérieur via SNAT/MASQ. Ensuite, une règle DNAT transfère les requêtes client de l’IP du firewall vers le serveur NTP interne. Les deux paires de règles doivent être vérifiées séparément dans Log Viewer.

Pour la première mise en œuvre, la position de règle doit être volontairement élevée, typiquement Top ou au-dessus des règles LAN-to-WAN et NAT générales. Ensuite, la position peut être intégrée au concept de règles existant tant que Log Viewer et Packet Capture montrent toujours que la règle attendue s’applique en premier.

host_internal-firewall-ip contient l’adresse IP LAN interne du pare-feu Sophos, ici 10.10.11.1. Les clients utilisent cette adresse comme serveur NTP. Remplacez cette valeur par l’adresse LAN interne du pare-feu de votre réseau client et adaptez net_Internet-LAN (10.10.11.0/24), l’interface d’entrée et la zone source. Ici, l’entrée est Port2 dans la zone du réseau client interne ; Port1 appartient à la DMZ et n’est pas utilisé. Les deux règles utilisent le service prédéfini NTP ; aucun service supplémentaire limité à UDP n’est nécessaire. Cet exemple de configuration ne constitue pas la preuve d’un test réel réussi. Sélectionnez la zone affectée au réseau client dans votre environnement ; « zone LAN interne » est une description, pas un nom de zone imposé.

Dans Hosts and services > IP host > Add, créez les deux objets IPv4 suivants et enregistrez chacun avec Save. Réutilisez les objets existants adaptés, le cas échéant.

Variante A : Utiliser un serveur NTP externe

Cette variante convient si les clients doivent utiliser l’adresse IP du pare-feu comme serveur NTP et qu’il n’y a pas de serveur de temps interne propre. Le pare-feu traduit la requête NTP vers un serveur de temps externe, par exemple time.google.com ou un serveur de temps fournisseur délibérément choisi.

Google Public NTP (time.google.com) utilise le leap smear. Ne le mélangez pas avec des sources sans leap smear.

Créer un hôte FQDN pour le serveur NTP externe

Le chemin du menu est :

Hosts and services > FQDN host

Procédure :

1. Sélectionner Add.
2. Attribuer un Name, par exemple host_Google-NTP.
3. Saisir le serveur NTP externe sous FQDN, par exemple time.google.com.
4. Enregistrer.

Si un serveur de temps interne ou externe avec une adresse IP fixe est utilisé à la place du FQDN, un objet hôte normal peut avoir plus de sens. Il est important que la cible puisse être clairement reconnue ultérieurement dans la règle NAT et de pare-feu.

Créer une règle NAT pour le serveur NTP externe

La règle NAT garantit que les requêtes NTP adressées à l’adresse IP du pare-feu sont réécrites sur le serveur de temps externe. Le chemin du menu est :

Rules and policies > NAT rules

Procédure :

1. Sélectionner Add NAT rule > New NAT rule.
2. Définir Rule name, par exemple DNAT_Client_NTP_to_External.
3. Définir Rule position sur Top ou la placer au-dessus des règles générales NAT.
4. Définir Original source sur le réseau interne concerné, ici net_Internet-LAN (10.10.11.0/24).
5. Définir Original destination sur host_internal-firewall-ip, ici 10.10.11.1.
6. Pour Original service, supprimer Any et sélectionner NTP.
7. Pour Translated source (SNAT), sélectionner MASQ.
8. Pour Translated destination (DNAT), sélectionner l’hôte FQDN ou l’hôte du serveur NTP externe.
9. Pour Inbound interface, supprimer Any et sélectionner l’entrée réelle des clients, ici Port2. Sophos autorise aussi Any, mais une sélection explicite évite les correspondances sur des entrées imprévues.
10. Laisser Translated service (PAT) sur Original pour conserver UDP 123. Outbound interface reste sur Any pour cette règle DNAT ; le routage vers la destination traduite détermine la sortie.
11. Enregistrer.

⚠️ Ne pas laisser Original destination ouverte : si Original destination n’est pas limitée à l’IP du firewall ou de la passerelle, la règle peut agir beaucoup plus largement selon le reste du design NAT. Elle peut alors ne pas seulement transférer le trafic destiné à l’IP du firewall, mais aussi rediriger de manière transparente du trafic NTP du réseau. Pour un relais contrôlé, la règle ne doit s’appliquer que lorsque les clients utilisent réellement l’IP du firewall ou de la passerelle comme destination NTP. Dans la vue détaillée, on doit prêter une attention particulière à quatre points : la destination d’origine doit être réellement l’adresse IP du pare-feu ou de la passerelle, le service doit rester limité à NTP ou UDP 123, la destination traduite doit pointer vers le serveur de temps prévu et SNAT doit correspondre à l’itinéraire de retour.

Si les bases de NAT ou les champs DNAT ne sont pas clairs, Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT apporte des précisions. Cela explique également pourquoi NAT ne remplace pas l’autorisation accordée par une règle de pare-feu.

Autoriser le NTP externe par une règle de pare-feu

Après la règle NAT, une règle de pare-feu appropriée est nécessaire. Cela autorise le trafic NTP depuis les réseaux internes vers le serveur cible. Le chemin du menu est :

Rules and policies > Firewall rules

Procédure :

1. Sélectionner Add firewall rule > New firewall rule.
2. Définir Rule name, par exemple NTP_LAN_to_Google.
3. Définir Rule position sur Top ou la placer au-dessus des règles générales LAN-to-WAN si celles-ci s’appliqueraient sinon en premier.
4. Activer Log firewall traffic.
5. Définir Source zones sur les zones internes, par exemple la zone LAN interne, DMZ ou une zone IoT. WAN et Any sont incorrects pour ce modèle.
6. Définir Source networks and devices sur les réseaux ou appareils concernés. Ce n’est pas un Any général si seuls certains réseaux doivent utiliser NTP.
7. Définir Destination zones sur WAN.
8. Définir Destination networks sur un objet hôte IPv4 représentant l’adresse du pare-feu ou de la passerelle utilisée comme destination NTP par les clients, par exemple host_internal-firewall-ip. S’il n’existe pas, le créer sous Hosts and services > IP host > Add, avec Type: IP et cette adresse IP exacte. Il doit correspondre à Original destination de la règle DNAT des clients, et non à l’hôte NTP externe.
9. Définir Services sur NTP.
10. Définir Action sur Accept.
11. Enregistrer.

Dans des exemples officiels ou simplifiés, Source networks and devices apparaît parfois avec Any. C’est pratique en laboratoire, mais rarement le meilleur choix en production. Un objet réseau concret comme net_Internet-LAN, IOT_NET ou un petit groupe d’hôtes est plus propre, car il reste clair quels appareils peuvent utiliser cette redirection NTP.

Pour un DNAT entrant, Sophos détermine d’abord la destination traduite. Destination zones utilise sa zone, ici WAN ; Destination networks utilise en revanche la destination initiale, ici l’adresse du pare-feu ou de la passerelle. Le véritable serveur de temps reste uniquement dans Translated destination (DNAT). L’exemple NTP générique de Sophos ne précise pas Destination networks ; cette distinction suit ses exemples explicites de DNAT et de loopback. Après une modification, déclencher une nouvelle session NTP depuis le client : les sessions existantes ne sont pas réévaluées avec les règles NAT modifiées. Avant de valider la configuration, contrôler Firewall Rule ID, NAT Rule ID et le chemin des paquets entrants et transmis comme décrit dans la section de test ; la configuration seule ne prouve pas une synchronisation réussie.

En ce qui concerne la règle, on ne doit pas seulement prêter attention à la fonction, mais aussi à la lisibilité. Un nom comme NTP_LAN_to_Google ou IOT_to_NTP_internal est plus facile à comprendre qu’une règle générique avec Any.

La journalisation du trafic de cette règle est utile lors de la mise en service. Après le test, on devrait pouvoir voir dans le Log Viewer de quel réseau client provient la demande, quel Firewall Rule ID a été utilisé et si le NAT Rule ID attendu est également visible. Si aucun ID de règle ou une règle incorrecte n’apparaît, l’ordre ou la correspondance de la règle est plus important que la configuration NTP elle-même.

Pour la structure des règles, la séquence, Services et la journalisation, Comprendre et configurer correctement les règles Sophos Firewall convient également.

Variante B : Utiliser le serveur NTP interne

Cette variante convient si un contrôleur de domaine interne, un serveur de temps Linux ou un autre système interne doit être la source de temps pour les clients, mais que les clients continuent à utiliser l’adresse IP du pare-feu comme serveur NTP.

On vérifie ici deux chemins de données avec leurs paires de règles ; les règles existantes appropriées peuvent être réutilisées :

Créer un hôte pour le serveur NTP interne

Le chemin du menu est :

Hosts and services > IP host

Procédure :

1. Sélectionner Add.
2. Définir Name, par exemple NTP_Server_Internal.
3. Définir IP version sur IPv4 si IPv4 est utilisé.
4. Définir Type sur IP.
5. Saisir IP address du serveur NTP interne, ici 192.168.20.10.
6. Enregistrer.

Paire de règles 1 : le serveur NTP interne se synchronise en externe

Le serveur NTP interne doit d’abord pouvoir accéder lui-même à un serveur de temps externe s’il n’est pas déjà synchronisé autrement. Sa source de temps amont doit être le véritable serveur de temps, et non l’adresse de passerelle utilisée comme relais. Une redirection vers lui-même ne peut se produire que si son trafic correspond également à une règle DNAT de relais dont la destination traduite est ce serveur. Dans l’exemple ci-dessus, le réseau source et l’interface d’entrée empêchent cette correspondance avec la règle DNAT des clients ; l’adresse de passerelle choisie à tort peut alors ne fournir aucune heure exploitable.

Règle NAT :

1. Ouvrir Rules and policies > NAT rules.
2. Sélectionner Add NAT rule > New NAT rule.
3. Définir Rule name, par exemple SNAT_Internal_NTP_to_WAN.
4. Définir Rule position sur Top ou la placer de manière appropriée au-dessus des règles NAT larges.
5. Dans Original source, sélectionner l’objet hôte NTP_Server_Internal.
6. Définir Original destination sur la source de temps externe prévue, ici host_Google-NTP.
7. Pour Original service, supprimer Any et sélectionner NTP.
8. Pour Translated source (SNAT), sélectionner MASQ ; Translated destination (DNAT) et Translated service (PAT) restent sur Original.
9. Définir Inbound interface sur l’entrée du serveur interne, ici Port3 ; limiter Outbound interface à l’interface WAN réellement utilisée. Avec plusieurs connexions WAN, toutes les sorties prévues doivent être prises en compte.
10. Enregistrer.

Règle de pare-feu :

1. Ouvrir Rules and policies > Firewall rules.
2. Sélectionner Add firewall rule > New firewall rule.
3. Définir Rule name, par exemple Internal_NTP_to_WAN.
4. Activer Log firewall traffic.
5. Définir Source zones sur la zone du serveur NTP interne, ici DMZ.
6. Définir Source networks and devices sur NTP_Server_Internal.
7. Définir Destination zones sur WAN.
8. Définir Destination networks sur la même source de temps externe que dans la règle SNAT, ici host_Google-NTP. Il n’y a pas de DNAT ici ; la destination initiale et la destination réelle sont identiques.
9. Définir Services sur NTP et Action sur Accept.
10. Placer la règle au-dessus des règles générales qui s’appliqueraient sinon en premier, puis enregistrer.

Paire de règles 2 : acheminer les clients vers le serveur NTP interne via le pare-feu

Le transfert proprement dit est ensuite construit : les clients envoient NTP à l’adresse IP du pare-feu, le pare-feu transmet au serveur NTP interne.

Règle NAT :

1. Ouvrir Rules and policies > NAT rules.
2. Sélectionner Add NAT rule > New NAT rule.
3. Définir Rule name, par exemple DNAT_Client_NTP_to_Internal.
4. Définir Rule position sur Top ou la placer au-dessus des règles NAT générales.
5. Définir Original source sur les réseaux clients internes concernés, ici net_Internet-LAN.
6. Définir Original destination sur l’adresse du pare-feu ou de la passerelle utilisée comme destination NTP par les clients, ici host_internal-firewall-ip.
7. Pour Original service, supprimer Any et sélectionner NTP.
8. Pour Translated source (SNAT), sélectionner MASQ.
9. Pour Translated destination (DNAT), sélectionner NTP_Server_Internal.
10. Pour Inbound interface, sélectionner les interfaces internes des clients concernés, ici Port2.
11. Laisser Translated service (PAT) sur Original ; Outbound interface reste sur Any pour cette règle DNAT.
12. Enregistrer.

Ici aussi, Original destination est décisif: la règle doit uniquement traduire les requêtes NTP adressées à l’IP du firewall ou de la passerelle. Si ce champ reste trop large, le firewall peut aussi capturer des requêtes NTP que les clients voulaient en réalité envoyer directement à un autre serveur de temps.

Règle de pare-feu :

1. Ouvrir Rules and policies > Firewall rules.
2. Sélectionner Add firewall rule > New firewall rule.
3. Définir Rule name, par exemple LAN_to_Internal_NTP.
4. Activer Log firewall traffic.
5. Définir Source zones sur les zones client internes. Éviter WAN et Any.
6. Définir Source networks and devices sur les réseaux clients concernés.
7. Définir Destination zones sur la zone du serveur NTP interne, par exemple la zone LAN interne ou DMZ.
8. Définir Destination networks sur l’objet hôte IPv4 de l’adresse du pare-feu ou de la passerelle initialement contactée, par exemple host_internal-firewall-ip, comme dans Original destination de la règle DNAT des clients. Ne pas sélectionner NTP_Server_Internal ; cet hôte reste dans Translated destination (DNAT).
9. Définir Services sur NTP.
10. Définir Action sur Accept. Placer la règle au-dessus des règles générales qui s’appliqueraient sinon en premier, puis enregistrer.

Ici encore, Destination zones correspond à la destination interne traduite, tandis que Destination networks contient l’adresse initiale du pare-feu ou de la passerelle. Vérifier séparément une nouvelle session client, les identifiants des règles et le chemin des paquets pour cette paire de règles. MASQ garantit que la réponse repasse par le pare-feu, mais masque l’adresse IP originale du client au serveur NTP interne. Si ce serveur a besoin des adresses clientes pour ses journaux ou son contrôle d’accès, privilégier un accès direct avec une route de retour adaptée.

Si le serveur NTP interne lui-même est un contrôleur de domaine, on doit effectuer une analyse particulièrement minutieuse. Tous les réseaux clients ne doivent pas nécessairement atteindre directement chaque contrôleur de domaine. NTP peut être autorisé sans ouvrir des accès au contrôleur de domaine tout aussi larges.

Exploitation, sécurité et tests

Évaluer l’IPS et les fonctions de sécurité

NTP est techniquement un petit service UDP, mais UDP 123 devient également pertinent en pratique en cas d’abus, de mauvaise configuration ou de cibles externes indésirables. Si une licence Network Protection est disponible, une politique IPS adaptée sur la règle de pare-feu peut avoir du sens.

Pour NTP, une configuration au périmètre précis prime sur l’accumulation de fonctions de sécurité :

• Source Zone interne uniquement : empêche le pare-feu d’agir comme un relais public NTP.
• Réseaux sources précis : limite NTP aux clients, serveurs ou appareils qui ont réellement besoin de ce transfert.
• Serveur de destination défini : limite le trafic correspondant à cette règle de relais au serveur de temps défini et facilite l’analyse des journaux.
• Service uniquement NTP : évite une règle UDP trop large.
• Activer la journalisation : indique dans Log Viewer si Firewall Rule ID et NAT Rule ID fonctionnent comme prévu.

L’IPS doit donc être considéré comme un contrôle supplémentaire et non comme un remplacement d’une règle claire. Si la règle NTP autorise uniquement quelques réseaux internes à un serveur de temps défini, le gain de sécurité le plus important est déjà obtenu grâce à la portée et à la traçabilité. Lorsqu’un grand nombre de réseaux, des appareils peu clairs ou des zones IoT/OT sont impliqués, une politique IPS ciblée devient plus intéressante.

Si IPS est utilisé sur cette règle NTP, la politique IPS affectée doit explicitement inclure des signatures liées à NTP (IPS patterns). Cette protection supplémentaire cible ainsi les attaques contre les services NTP ; qualifier une politique de généralement adaptée ne remplace pas la sélection de ces signatures.

⚠️ IPS nécessite une licence de protection réseau adaptée. Si IPS est activé sur une règle très largement utilisée, les journaux et les performances doivent être surveillés. Pour un simple transfert NTP, une portée claire est plus importante qu’une combinaison inutilement large de fonctionnalités de sécurité.

Si une politique IPS dédiée est utilisée à cette fin, elle ne doit pas être copiée de manière généralisée sur tous les réseaux internes. Il est plus logique d’avoir une petite règle avec une source claire, une cible NTP définie, une journalisation active et un contrôle ultérieur dans Log Viewer.

Les autres fonctionnalités de sécurité doivent être délibérément traitées avec prudence avec NTP. Pour ce simple service UDP, Web Filtering, TLS Inspection, Application Control ou Malware Scan n’aident généralement pas avec la fonction NTP réelle. Si de tels profils sont actifs sur une règle collective, il convient de vérifier si NTP serait mieux placé dans sa propre petite règle.

Distribuer NTP via DHCP

Si les clients reçoivent leur configuration réseau via DHCP, on doit vérifier si un transfert NAT est même nécessaire. Pour de nombreux environnements, il est plus propre de distribuer le serveur NTP souhaité directement via DHCP.

S’il existe un contrôleur de domaine ou un serveur de temps central, l’option DHCP 42 peut pointer directement vers ce serveur, à condition que le client concerné prenne effectivement cette option en charge et l’utilise. Les membres d’un domaine peuvent suivre la hiérarchie temporelle du domaine ; on vérifie donc la source de temps effective sur le client. NAT est particulièrement utile si les appareils utilisent déjà l’adresse IP de la passerelle ou sont difficiles à reconfigurer. Pour les options spéciales DHCP, Configurer les options DHCP sur Sophos Firewall est un meilleur début.

Configurer séparément le pare-feu comme client NTP

Le relais NTP des clients est distinct de la configuration de l’heure système de Sophos Firewall. Sous Administration > Time, SFOS 22.0 propose trois choix :

État actuel inchangé de l’horloge du pare-feu : Use pre-defined NTP server, Europe/Zurich. Cette vue est distincte du relais client et ne prouve pas une synchronisation réussie ; ni Sync now ni Apply n’ont été utilisés.

• Use predefined NTP server est le réglage par défaut. Le pare-feu utilise NTPv3 et 0.sophos.pool.ntp.org.
• Use custom NTP server accepte une adresse IPv4, IPv6 ou un nom de domaine. On peut saisir jusqu’à dix serveurs, vérifiés dans l’ordre affiché.
• Do not use NTP server règle manuellement la date et l’heure ; ce choix n’est pas recommandé en exploitation normale.

Après avoir choisi un serveur, cliquer sur Sync now, puis sur Apply. Après Sync now, Current time ne se met à jour qu’après l’actualisation de WebAdmin. Régler également le fuseau horaire correspondant à l’emplacement du pare-feu.

⚠️ Impact sur les VPN : selon Sophos, toute modification des serveurs NTP entraîne la reconnexion de toutes les connexions IPsec. Prévoir donc une fenêtre de maintenance.

Contrôler séparément les deux chemins :

• Heure système du pare-feu : pertinent pour Log Viewer, les certificats, MFA, VPN, l’authentification WAF, les rapports, Syslog et l’analyse de support.
• Client-NTP via NAT : Les appareils du réseau interne reçoivent l’heure via l’adresse IP de la passerelle ou une adresse NTP redirigée.

Si le pare-feu lui-même a une heure ou un fuseau horaire incorrect, les entrées du journal peuvent être difficiles à corréler, les vérifications des certificats peuvent échouer ou une authentification basée sur l’heure telle que TOTP/MFA peut causer des problèmes. On corrige alors en premier l’heure système du pare-feu et son propre accès NTP. Ce n’est qu’alors qu’il est judicieux de valider le client NTP via NAT.

Pour les environnements SIEM ou Syslog, ce point est particulièrement important : le pare-feu peut acheminer correctement le trafic NTP et quand même envoyer des horodatages incorrects à un SIEM si sa propre heure ou son fuseau horaire est incorrect.

Pour le transfert de journaux, Envoyer Sophos Firewall Syslog à SIEM convient. Pour les problèmes MFA, Activer MFA pour WebAdmin, VPN Portal et Remote Access sur Sophos Firewall doit également être inclus.

Tester NTP et isoler les erreurs

Après l’enregistrement, on ne doit pas seulement vérifier si la règle existe. Ce qui est crucial est de savoir si un client peut réellement synchroniser NTP et si les règles NAT et de pare-feu attendues correspondent au trafic.

Le test commence de la même manière pour les deux variantes : un client du réseau concerné utilise l’adresse IP du pare-feu ou de la passerelle comme serveur NTP. Une synchronisation horaire est alors déclenchée ou une courte attente est effectuée jusqu’à ce que le client envoie NTP.

Ouvrir Log viewer en haut à droite de WebAdmin. Dans le module Firewall, utiliser Add filter pour une règle, une adresse IP ou un port ; la recherche en texte libre permet aussi de chercher 123, une adresse cliente ou un nom de règle. Les journaux de session peuvent ne pas apparaître immédiatement : le pare-feu journalise la session lors de l’événement interne Destroy. Avec UDP, il peut être nécessaire d’attendre la fin de la session ; UDP ne possède pas de fermeture de connexion TCP.

Avec la variante A, il doit être visible :

• Le client est issu du réseau interne attendu.
• La règle de pare-feu NTP pour le trafic NTP externe s’applique.
• La règle DNAT vers la source de temps externe s’applique.
• La cible est le serveur NTP externe prévu.

Deux choses sont à vérifier pour la variante B :

• Le serveur NTP interne est autorisé à envoyer NTP en externe.
• Les clients sont routés via DNAT de l’adresse IP du pare-feu vers le serveur NTP interne. Si Log viewer ne permet pas d’identifier clairement la règle, utiliser Diagnostics > Packet capture. Sous Configure, l’expression BPF port 123 limite la capture à NTP. Après avoir activé Packet capture, le paquet entrant doit afficher l’adresse du client, celle du pare-feu et UDP 123 ; le paquet transmis affiche la destination traduite. NAT ID et Rule ID doivent correspondre aux nouvelles règles. Incoming et Forwarded confirment le chemin, Consumed désigne un paquet destiné au pare-feu lui-même, tandis que Violation et Reason expliquent un rejet.

Une transmission réussie ne confirme pas à elle seule la synchronisation horaire. L’état NTP du client doit également indiquer une réponse valide et un état synchronisé ; pour la variante B, on vérifie aussi l’état de synchronisation du serveur de temps interne. Dans la capture, on attend une réponse du véritable serveur de temps et, sur le chemin de retour vers le client, l’adresse de passerelle contactée comme source. En l’absence de réponse, on vérifie d’abord l’accessibilité, le chemin de retour et le contrôle d’accès du serveur de temps pour l’adresse MASQ.

Pour le test négatif, un client d’un réseau interne non autorisé envoie une nouvelle requête NTP à l’adresse de passerelle. La règle DNAT des clients et l’autorisation associée créées ici ne doivent pas s’appliquer. Si la requête est tout de même transmise, on recherche une règle NAT ou de pare-feu antérieure ou plus large. Une requête d’un client autorisé directement adressée à un autre serveur NTP ne doit pas non plus être redirigée par cette règle DNAT liée à l’adresse de passerelle. Le reste de la politique de pare-feu détermine si le NTP direct est autorisé ou bloqué ; ce relais seul n’impose pas une source de temps centrale à l’ensemble du trafic.

Si aucun journal n’est visible, il est possible que le client n’envoie pas la demande, la règle de pare-feu n’enregistre pas ou le trafic emprunte un chemin différent. Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture convient à la vérification systématique.

Pour les problèmes NTP spécifiques au pare-feu, le journal client NTP est également pertinent. La présentation des journaux se trouve dans Dépannage Sophos Firewall : Services et journaux.

Validation rapide

Avant la mise en production, cinq points doivent être corrects :

1. Les clients utilisent réellement l’adresse IP du pare-feu ou de la passerelle comme serveur NTP.
2. Les règles NTP autorisent uniquement les réseaux sources internes prévus.
3. Les Firewall Rule ID et NAT Rule ID attendus sont visibles dans le Log Viewer.
4. L’heure du système du pare-feu est correcte séparément.
5. Après DHCP, VLAN, NAT ou des modifications de règles, NTP sera à nouveau testé.

Erreurs typiques

• WAN autorisé en tant que Source Zone : Le pare-feu peut involontairement agir comme un relais NTP ouvert. Limiter les zones sources aux zones internes.
• Any pour la source et la destination : La règle est difficile à contrôler. Définir spécifiquement les réseaux sources et les serveurs cibles.
• Règle NAT présente, mais pas de règle de pare-feu : Le trafic est traduit mais n’est pas autorisé. Vérifier Log Viewer pour l’ID de règle et l’ID NAT.
• Règle de pare-feu sans journalisation : L’analyse des erreurs devient inutilement difficile. Activer Log firewall traffic au moins pendant le test.
• La cible FQDN n’est pas résolue : La cible DNAT n’est pas atteinte. Vérifier la résolution DNS du pare-feu.
• Le client utilise un autre serveur NTP : Le trafic ne correspond jamais à la règle. Vérifier la configuration du client ou l’option DHCP.
• Le serveur de temps ne répond pas : Le client reste non synchronisé. Vérifier le serveur de destination, le routage et UDP 123.

Retour arrière

Si le relais pose problème, désactiver d’abord la nouvelle règle DNAT des clients et déclencher un nouveau test NTP. Désactiver ensuite la règle de pare-feu associée. Pour la variante B, ne supprimer les règles SNAT et de pare-feu WAN du serveur interne que s’il n’en a plus besoin pour sa propre synchronisation. Ne supprimer les règles et objets hôtes dédiés qu’après avoir vérifié l’absence de correspondances et de dépendances. Enfin, fournir aux clients un serveur NTP directement accessible, par exemple via l’option DHCP 42, faute de quoi ils perdront leur source de temps.

FAQ