Configurer Sophos Firewall comme serveur DHCP

Sophos Firewall peut distribuer directement aux clients des adresses IPv4, une passerelle, des serveurs DNS et d’autres paramètres réseau. Pour cela, il faut créer sous Network > DHCP un serveur associé à l’interface des clients, définir la plage d’adresses, puis vérifier que le client obtient un bail approprié.

Procédure rapide : ouvrir Network > DHCP > Server > Add, sélectionner l’interface et la plage d’adresses, activer Use interface IP as gateway, définir soigneusement les paramètres DNS et enregistrer. Vérifier ensuite sous System services > Services le service DHCP server, puis contrôler l’adresse attribuée sous IPv4 lease.

Ce guide traite d’un serveur DHCPv4 destiné aux clients d’un réseau directement connecté. Si un serveur DHCP central doit desservir un autre sous-réseau, consulter Configurer et tester DHCP Relay sur Sophos Firewall. Les paramètres PXE, VoIP et spécifiques aux fabricants sont décrits dans Configurer les options DHCP sur Sophos Firewall.

Avec IPv6, l’attribution des adresses et la passerelle relèvent de rôles différents. La procédure complète est décrite dans Configurer et tester un serveur DHCPv6 sur Sophos Firewall.

Exemple et planification des adresses

L’exemple utilise un VLAN client avec les valeurs suivantes :

Interface : VLAN20 - 10.20.0.1/24
Plage dynamique : 10.20.0.100 à 10.20.0.199
Passerelle : 10.20.0.1
Attribution statique pour une imprimante : 10.20.0.20
Serveurs DNS internes : 10.10.0.10 et 10.10.0.11
Domain Name : corp.example

La plage dynamique se trouve dans le réseau de l’interface, mais ne contient ni l’adresse réseau, ni l’adresse de broadcast, ni la passerelle. Dans cet exemple, les adresses inférieures à 10.20.0.100 restent réservées à l’infrastructure et aux attributions statiques. La plage DHCP ne distribue donc pas également ces adresses réservées de manière dynamique. Cette séparation ne protège toutefois pas contre un autre appareil sur lequel la même adresse IP aurait été configurée manuellement.

Avant l’activation, il faut vérifier quelles adresses sont déjà utilisées par des commutateurs, des points d’accès, des imprimantes ou des serveurs. Si un autre serveur DHCP fonctionne encore dans le même VLAN, il faut d’abord déterminer quel serveur sera désormais responsable. Deux serveurs non coordonnés peuvent distribuer des passerelles ou des serveurs DNS différents et provoquer des erreurs intermittentes.

L’interface elle-même doit déjà disposer de la bonne adresse IP statique. L’interaction entre l’interface, la zone et le VLAN est expliquée dans Configurer une interface VLAN sur Sophos Firewall.

Configurer le serveur DHCP

Ouvrir Network > DHCP.
Sous Server, cliquer sur Add.
Saisir un nom explicite, par exemple dhcp-vlan20-clients.
Sous Interface, sélectionner l’interface client VLAN20 - 10.20.0.1.
Sous Dynamic IP lease, ajouter la plage de 10.20.0.100 à 10.20.0.199.
Saisir 255.255.255.0 comme Subnet mask pour le réseau /24 de l’exemple.
Activer Use interface IP as gateway. Les clients reçoivent alors 10.20.0.1 comme Gateway.
Définir les serveurs DNS, le Domain name et les durées de bail en fonction du réseau.
Ajouter si nécessaire des attributions MAC-IP statiques.
Enregistrer avec Save.

Pour les clients directement connectés, l’interface sélectionnée détermine le réseau sur lequel le pare-feu répond aux requêtes DHCP. La plage dynamique doit donc appartenir au sous-réseau de cette interface. Les serveurs DHCP peuvent être configurés sur des interfaces physiques ainsi que sur des interfaces VLAN, Wireless et Bridge, mais pas sur une interface de type Interface Alias. Il n’est pas possible de configurer simultanément un serveur DHCPv4 sur une interface déjà utilisée comme DHCP Relay.

Pour les clients directement connectés, laisser Accept client request via relay désactivé. Cette option n’est nécessaire que si cette configuration de serveur doit accepter, via un agent relais, les requêtes d’un sous-réseau client distant. Chaque réseau client distant exige une configuration de serveur adaptée avec sa propre passerelle ; la procédure complète figure dans le guide DHCP Relay.

Ces configurations de serveur peuvent partager la même interface DHCP sur laquelle le serveur reçoit les requêtes relayées. Il faut distinguer l’interface d’écoute du sous-réseau client distant : la plage d’adresses, le masque de sous-réseau et la passerelle de chaque configuration appartiennent à son réseau client. Le serveur attribue des adresses du sous-réseau de l’adresse source de l’agent relais ; partager une interface d’écoute ne remplace donc pas une configuration distincte pour chaque réseau client.

Choisir correctement la passerelle et le DNS

Dans un réseau client standard, l’adresse IP de Sophos Firewall sur cette interface sert de passerelle. Dans l’exemple, les clients reçoivent donc 10.20.0.1.

Avec Use device’s DNS settings, le pare-feu distribue aux clients ses serveurs DNS configurés. Ce choix convient si ces serveurs peuvent résoudre aussi bien les noms publics que les noms internes requis. Dans un environnement AD, il faut généralement saisir les serveurs DNS internes afin que les contrôleurs de domaine, les services internes et les domaines de recherche fonctionnent de manière fiable. Des résolveurs publics seuls ne suffisent généralement pas.

Domain name fournit un suffixe DNS à la carte réseau. Avec corp.example, le client peut par exemple compléter le nom d’hôte fileserver en fileserver.corp.example. Cela ne remplace ni un enregistrement DNS ni un serveur DNS joignable ; les deux doivent être vérifiés séparément.

Si les clients reçoivent l’adresse IP du pare-feu comme serveur DNS, Sophos Firewall peut transférer les requêtes concernant certaines zones internes vers les serveurs responsables. Ce cas est décrit dans Configurer les DNS Request Routes sur Sophos Firewall. En revanche, si DHCP distribue directement les adresses d’autres serveurs DNS, les requêtes des clients ne passent pas par les Request Routes du pare-feu.

Les champs WINS server 1 et WINS server 2 sont réservés aux anciens environnements NetBIOS. Ils restent vides tant qu’aucun client ni aucune application n’a besoin d’un service WINS. Si WINS est encore utilisé, il faut saisir les adresses réelles des serveurs et tester la résolution de noms avec un client concerné.

Définir des durées de bail adaptées

Default lease time correspond à la durée de bail normalement attribuée au client. Max lease time constitue la limite supérieure ; à son expiration, le client doit envoyer une nouvelle requête au serveur DHCP. Les deux valeurs sont exprimées en minutes.

Des baux plus longs conviennent aux réseaux de bureaux ou d’équipements stables, car le parc y change rarement. Dans les réseaux Wi-Fi pour invités, les environnements de formation ou les réseaux où les clients changent fréquemment, un bail plus court évite que des appareils déconnectés occupent longtemps la plage.

Des baux très courts génèrent en revanche un nombre inutilement élevé de renouvellements. Le critère déterminant n’est donc pas une valeur idéale universelle, mais la taille de la plage et la fréquence de rotation des clients.

Conflict detection vérifie une adresse avant de l’attribuer et aide à détecter les adresses IP déjà utilisées. Cette fonction est particulièrement utile lorsqu’il existe encore des appareils configurés manuellement ou un ancien plan d’adressage qui n’est pas entièrement documenté.

Créer une attribution IP-MAC statique

Une attribution statique garantit qu’un appareil donné reçoit toujours la même adresse par DHCP. Elle convient aux imprimantes, aux points d’accès ou à d’autres équipements qui doivent rester joignables tout en continuant à recevoir de manière centralisée des paramètres comme la passerelle et le DNS.

Sous Static IP MAC mapping, saisir le nom d’hôte, l’adresse MAC et l’adresse IP souhaitée. Dans l’exemple, l’imprimante associée à son adresse MAC réelle reçoit toujours 10.20.0.20. Cette adresse se trouve volontairement en dehors de la plage dynamique.

Une attribution DHCP n’est pas identique à une adresse IP configurée manuellement sur l’appareil : l’appareil reste un client DHCP, mais le pare-feu lui réserve le bail correspondant. Si un ordinateur portable ou un smartphone utilise une adresse MAC Wi-Fi privée ou aléatoire, l’attribution doit correspondre à l’adresse MAC réellement utilisée par l’appareil sur ce réseau Wi-Fi.

Une même adresse MAC peut recevoir au maximum cinq adresses IP statiques, à condition qu’elles appartiennent à des sous-réseaux différents. Une attribution normale dans un seul réseau ne nécessite pas le réglage global.

Dans SFOS 23, lorsque la même adresse MAC est liée dans plusieurs configurations de serveur DHCP, définir Lease scope for static binding sur Global sous Network > DHCP > Advanced server settings. Les clients peuvent alors obtenir une adresse auprès de tout serveur DHCP configuré sur le pare-feu, quel que soit le serveur contenant la liaison IP-MAC statique. Network limite cette attribution au serveur contenant la liaison. Relever d’abord la valeur précédente, puis tester chaque étendue concernée avec un nouveau bail client. Pour le retour arrière, rétablir exactement la valeur relevée.

SFOS 22 : liaison globale dans la Device Console

Avant de modifier l’attribution globale, se connecter par SSH, puis consulter dans la Device Console l’aide locale propre aux commandes conf-generation-method et static-entry-scope sur la version SFOS installée. Déterminer et consigner la méthode et l’étendue actuelles au moyen d’une requête en lecture prise en charge par cette version ou d’un affichage disponible dans l’interface utilisateur ; vérifier également au préalable la syntaxe de retour arrière correspondante. Aucune forme de show n’est confirmée ici comme valable pour toutes les versions. Si l’état initial ou la procédure de retour arrière ne peuvent pas être déterminés de manière fiable, ne procéder à aucune modification et clarifier d’abord l’état avec le support.

Modifier ensuite uniquement les valeurs qui diffèrent de l’état cible requis :

system dhcp conf-generation-method new
system dhcp static-entry-scope global

Ce réglage s’applique à toutes les configurations de serveur DHCP. Il n’est pas nécessaire pour les attributions ordinaires et uniques ; il ne doit donc être modifié que dans ce cas impliquant plusieurs étendues DHCP.

Lorsque des adresses MAC sont liées plusieurs fois, l’état cible présenté ci-dessus est important pour que les clients reçoivent les paramètres DHCP corrects, tels que les serveurs DNS et la passerelle. Ne pas écraser un état déjà approprié et ne pas supposer que les valeurs par défaut constituent l’état initial. Pour le retour arrière, restaurer exactement les valeurs consignées auparavant avec la syntaxe confirmée pour la version installée. Si les valeurs initiales étaient effectivement network et old, les commandes system dhcp static-entry-scope network et system dhcp conf-generation-method old peuvent convenir, à condition que l’aide locale confirme ces formes. Vérifier ensuite chaque étendue concernée avec un nouveau bail client. La modification et le retour arrière n’ont pas été testés ici sur un pare-feu.

Vérifier le service et tester le bail

Après l’enregistrement, vérifier sous System services > Services que DHCP server est en cours d’exécution. Si le service est arrêté, le démarrer à cet emplacement.

⚠️ Dans un cluster HA, Sophos prend en charge le service DHCP en mode Active-passive, mais pas en mode Active-active. Vérifier cette limite avant la mise en service ; changer de mode HA n’est pas une étape de dépannage pour un scope isolé.

Connecter ensuite un client de test contrôlé au bon VLAN. Sous Windows, les commandes suivantes permettent de demander et de vérifier un nouveau bail :

⚠️ ipconfig /release interrompt la connexion IPv4 en cours. Ne pas exécuter cette commande via cette même connexion distante si aucun autre accès n’est disponible.

ipconfig /release
ipconfig /renew
ipconfig /all

Le client doit recevoir une adresse comprise entre 10.20.0.100 et 10.20.0.199, la passerelle 10.20.0.1 et les serveurs DNS prévus. Sous Network > DHCP > IPv4 lease, le pare-feu affiche l’adresse attribuée avec les heures de début et de fin, l’adresse MAC et le nom d’hôte.

La vérification fonctionnelle doit au moins confirmer les points suivants :

Le client reçoit une adresse de la bonne plage.
La passerelle et les serveurs DNS correspondent à la planification.
La passerelle est joignable.
Les noms internes et externes sont résolus.
Le client n’accède qu’aux réseaux et services autorisés par sa règle de pare-feu.

Aucune adresse ou une adresse incorrecte

Si le client ne reçoit aucun bail, vérifier d’abord l’interface, le VLAN et l’état du service. Les erreurs suivantes sont ensuite particulièrement fréquentes :

Interface incorrecte : le serveur DHCP n’est pas associé à l’interface du réseau client.
Le VLAN n’atteint pas le pare-feu : le VLAN n’est pas autorisé en mode tagged sur l’uplink du commutateur, ou le port du client est affecté de manière incorrecte.
La plage d’adresses ne correspond pas : l’adresse de début ou de fin se trouve en dehors du sous-réseau de l’interface.
La plage est épuisée : comparer le nombre et la durée des baux occupés à la taille de la plage configurée. La liste des baux affiche les adresses attribuées, mais ne fournit pas de liste séparée des adresses libres.
Un autre serveur DHCP répond : le client reçoit une adresse, mais une passerelle ou des serveurs DNS incorrects.
Policy rule denied pour la source 0.0.0.0 : si aucun serveur DHCP ni aucun relais n’est configuré sur l’interface, une requête client peut être rejetée avec cette entrée. Le message ne prouve donc pas qu’une règle de pare-feu normale est en cause. Vérifier d’abord le serveur DHCP, le relais et l’affectation de l’interface.
DHCP Relay serait nécessaire : le client ne se trouve pas dans le réseau directement connecté au serveur.
L’attribution statique ne fonctionne pas : l’adresse MAC saisie ne correspond pas à celle que le client utilise réellement.

Une capture de paquets avec le filtre port 67 or port 68 permet de voir si les messages Discover, Offer, Request et ACK sont échangés et quel serveur répond. Son utilisation est décrite dans Utiliser Packet Capture dans le WebAdmin de Sophos Firewall.

Si un message Discover atteint le pare-feu, mais qu’aucun Offer ne suit, vérifier également l’état de dhcpd et le journal dhcpd.log. Les commandes et chemins de journaux correspondants sont disponibles dans Vérifier les services et les journaux de Sophos Firewall via la CLI.

Si le client reçoit une adresse IP correcte, mais ne peut résoudre aucun nom, vérifier d’abord les adresses DNS distribuées par DHCP. Si elles sont incorrectes ou absentes, l’erreur se trouve toujours dans la configuration DHCP. Si elles sont correctes, poursuivre avec la résolution des noms internes et l’accès réseau au serveur DNS.

Une interface RED présente un cas particulier supplémentaire : si son adresse est remplacée par une adresse située hors de la plage de baux dynamiques existante, SFOS désactive le serveur DHCP RED associé. Adapter alors Dynamic IP lease, les attributions statiques et les valeurs DNS au sous-réseau résultant de l’interface, ou créer une nouvelle configuration de serveur. L’étendue DHCP ne doit être remise en service et testée avec un client qu’ensuite.

Remplacer un serveur DHCP existant

Lors d’une migration, il ne faut pas simplement activer le nouveau serveur DHCP en parallèle. Les clients actifs conservent leur bail existant ; le nouveau serveur ne connaît pas ces attributions et pourrait proposer à nouveau une adresse encore utilisée.

Pour effectuer une transition contrôlée :

Documenter la plage, les options, les attributions statiques et les baux actifs du serveur existant.
Réduire suffisamment tôt la durée de bail sur l’ancien serveur et attendre que les clients actifs aient renouvelé leur bail avec la valeur plus courte.
Arrêter l’ancien serveur et activer le nouveau serveur avec une plage de transition qui ne chevauche pas la précédente.
Renouveler le bail de plusieurs clients différents et vérifier la passerelle, le DNS et l’accessibilité.
Une fois les anciens baux expirés, activer la plage définitive et rétablir la durée de bail normale.

Conflict detection est utile lors d’une migration, mais ne remplace pas cette planification. La fonction vérifie une adresse avant de l’attribuer, mais ne partage aucune base de données de baux avec l’ancien serveur.

Pour le retour arrière, conserver un relevé complet de l’ancienne configuration. Si le nouveau scope distribue des valeurs incorrectes, désactiver ou supprimer uniquement cette nouvelle configuration de serveur, puis remettre l’ancien serveur en service de manière contrôlée. En revanche, System services > Services > DHCP server > Stop arrête le service DHCP global et donc tous les scopes locaux ; cette action ne convient que si cet effet global est voulu. Renouveler ensuite les baux sur plusieurs clients de test.

Les valeurs spéciales comme les serveurs de démarrage PXE, les contrôleurs VoIP ou les options propres aux fabricants doivent être comparées séparément avant la transition. Elles ne font pas automatiquement partie de la distribution normale de l’adresse, de la passerelle et du DNS.

Automatisation : état d’une configuration DHCP nommée

La documentation de l’API XML pour SFOS 22 et 23 décrit DHCPServerStatus avec les champs obligatoires DHCPServerNamedhcpname et Status. DHCPServerNamedhcpname est l’orthographe littérale documentée, et non un nom de champ corrigé ici. Le nom désigne la configuration de serveur DHCP sélectionnée, par exemple dhcp-vlan20-clients, et non le service DHCP global. Un changement d’état de cette étendue nommée ne doit pas être confondu avec le Stop global décrit ci-dessus.

Pour Status, l’exemple indique ON/OFF, tandis que le tableau des paramètres précise INTEGER. Aucune correspondance numérique ni valeur par défaut n’est indiquée ; les deux champs sont obligatoires. Cela ne permet de déduire ni un encodage sûr ni le comportement en cas d’omission de champs. Ne pas automatiser de changement d’état XML à partir de cet exemple. Tant que le schéma des champs et l’encodage de l’état ne sont pas clarifiés pour la version installée, utiliser la procédure GUI existante sous Network > DHCP pour la configuration de serveur sélectionnée ; gérer séparément le service global sous System services > Services.

Avant une modification, relever le nom, l’interface, la plage d’adresses et l’état précédent de l’étendue cible. Ensuite, vérifier cette configuration exacte et que les autres étendues restent inchangées, puis effectuer avec des clients contrôlés les vérifications de bail, de passerelle, de DNS et de connectivité décrites ci-dessus. Lors de la désactivation, vérifier que cette étendue n’attribue plus de nouveaux baux ; un bail client encore présent ne le prouve pas. Les résultats API documentés 200 (Operation Successful) et 500 (Operation Fail) ne sont pas des tests fonctionnels ; HTTP 200 seul ne confirme pas non plus la bonne cible ni l’état du client. Pour le retour arrière, restaurer exactement l’état relevé et répéter les vérifications des clients.

Modifier les paramètres DHCP globaux uniquement si nécessaire

Dans SFOS 23, Network > DHCP > Advanced server settings contient ces deux champs de l’interface :

Allow only one lease per client limite chaque client à un seul bail DHCP. Lorsque l’option est activée, chaque client ne reçoit qu’une seule adresse IP louée.
Negative acknowledgement active les réponses DHCPNAK lorsqu’un client demande une adresse hors du sous-réseau configuré du serveur ou une adresse déjà attribuée. Conflict detection est, en revanche, une vérification distincte de l’adresse avant son attribution.

Avant une modification dans l’interface, relever la valeur précédente. Ensuite, renouveler un bail client, vérifier IPv4 lease et, si nécessaire, une capture de paquets UDP 67/68. Pour le retour arrière, restaurer exactement la valeur relevée. Les indications CLI ci-dessous sur l’impact global, l’identité du client et les risques liés aux NAK restent applicables.

Deux autres commutateurs de la Device Console s’appliquent à l’ensemble du service DHCP. Avant toute modification, consulter l’aide locale propre aux commandes one-lease-per-client et send-dhcp-nak sur la version installée. Consigner l’état actuel des deux commutateurs au moyen d’une requête en lecture prise en charge par cette version ou d’un affichage disponible dans l’interface utilisateur, et confirmer la syntaxe de modification et de retour arrière. Ni une forme particulière de show ni une valeur par défaut ne sont supposées ici valables pour toutes les versions. Si l’état initial ou la procédure de retour arrière ne peuvent pas être déterminés de manière fiable, ne procéder à aucune modification et faire d’abord appel au support.

one-lease-per-client limite l’attribution des baux par client lorsqu’il est activé. La manière dont la version installée identifie le client dans les cas particuliers doit être déterminée sur place. L’activation s’applique à toutes les configurations de serveur DHCP de ce pare-feu ; limiter donc d’abord uniquement le test à un client contrôlé, puis vérifier la table des baux, le renouvellement ainsi que les appareils dotés de plusieurs interfaces ou d’une adresse MAC changeante.

Lorsque send-dhcp-nak est activé, il permet les réponses DHCPNAK. Un DHCPNAK rejette une adresse que le serveur n’accepte pas et oblige le client à reprendre la négociation DHCP. La désactivation peut prolonger des états client non valides et ne constitue pas une correction générale des échecs de bail.

Modifier les commutateurs comme suit uniquement si l’aide locale confirme cette syntaxe pour la version installée et si l’état initial ainsi que la procédure de retour arrière ont été consignés :

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

Les crochets sont des marqueurs de substitution ; n’exécuter que la valeur requise. Après la modification, vérifier de nouveau la valeur au moyen de la même requête en lecture prise en charge ou du même affichage dans l’interface utilisateur, renouveler un bail, contrôler IPv4 lease et, si nécessaire, effectuer une capture de paquets sur UDP 67/68. Pour le retour arrière, restaurer exactement les valeurs consignées avant la modification avec la syntaxe confirmée au préalable, puis vérifier de nouveau les deux commutateurs. Les commandes system dhcp one-lease-per-client disable et system dhcp send-dhcp-nak enable ne conviennent pour le retour arrière que si le premier commutateur était auparavant désactivé et le second auparavant activé, respectivement, et si l’aide locale confirme cette syntaxe. La modification et le retour arrière n’ont pas été testés ici sur un pare-feu.