Options DHCP de Sophos Firewall (SFOS)

Les options DHCP sont nécessaires sur la Sophos Firewall lorsque les clients doivent recevoir plus qu’une simple adresse IP, une passerelle et un DNS au démarrage. Les cas typiques incluent PXE, WDS, clients légers, téléphones VoIP ou environnements RED plus anciens, où un code d’option et un type de données spécifiques doivent correspondre exactement.

Les versions actuelles de Sophos Firewall prennent en charge les options DHCP directement dans WebAdmin. Pour la plupart des environnements, une configuration SSH ou CLI n’est donc plus nécessaire. Les exemples CLI restent néanmoins importants, car les anciens runbooks, les cas particuliers et le dépannage utilisent souvent encore cette syntaxe.

Ce que sont les options DHCP

Le DHCP ne distribue pas seulement une adresse IP. Avec le bail, le serveur DHCP peut transmettre des informations supplémentaires au client. C’est précisément pour cela que les options DHCP existent. Des exemples typiques incluent les serveurs DNS, la passerelle, le serveur TFTP, le nom de fichier de démarrage, les paramètres spécifiques au fournisseur ou les valeurs pour les clients légers et les téléphones.

Sur la Sophos Firewall, les options DHCP appartiennent toujours au serveur DHCP ou au scope qui délivre le bail. C’est important : si un client reçoit son adresse d’un autre serveur DHCP, l’option doit être configurée là-bas. Si la Sophos Firewall ne fonctionne que comme relais DHCP, elle transmet les requêtes DHCP, mais ce n’est pas l’endroit où l’option pour ce scope est maintenue.

Pour IPv6, le DHCP n’est pas toujours traité de la même manière que pour IPv4. Si un fournisseur délègue un préfixe IPv6, les annonces de routeur, les paramètres DHCPv6 et les règles de pare-feu vont ensemble. Le processus est décrit dans Configurer la délégation de préfixe IPv6 sur Sophos Firewall.

En pratique, avant de configurer, il faut clarifier trois choses :

• Quel serveur DHCP distribue réellement le bail ?
• Dans quel scope ou sur quelle interface se trouve le client ?
• Quels codes d’option, types de données et valeurs le fabricant du système cible exige-t-il ?

Prérequis

• Sophos Firewall avec serveur DHCPv4 activé
• Accès à Network > DHCP
• Un scope DHCP sur l’interface appropriée
• Les codes d’option DHCP et les valeurs nécessaires du fabricant ou du système cible
• Pour les solutions de repli CLI : accès SSH autorisé à la Sophos Firewall

Avant de modifier, il est conseillé de vérifier brièvement le scope concerné. Les options DHCP ne fonctionnent de manière fiable que si elles sont définies sur le bon serveur DHCP, dans le bon réseau et avec le bon type de données.

• Serveur DHCP : La Sophos Firewall doit émettre elle-même le bail. Avec DHCP Relay, les options se configurent généralement sur le serveur DHCP central.
• Scope et interface : Un client dans le mauvais VLAN ou sur une autre interface ne voit pas l’option, même si elle est correctement enregistrée.
• Code d’option et type de données : Beaucoup d’erreurs viennent du fait qu’un client attend string, ipaddress, array-of ou une valeur fournisseur autrement que ce qui a été saisi.
• Client de test : Un appareil connu dans le réseau concerné permet de vérifier si l’option arrive réellement dans le DHCP offer ou ACK.
• Fenêtre de changement : PXE, téléphones et clients légers peuvent être touchés dès le renouvellement du bail. Les changements doivent donc être testés de manière contrôlée.

Si l’option est pertinente pour les appareils en production, il doit être clair à l’avance comment la supprimer ou la rétablir à sa valeur précédente. Cela est particulièrement vrai pour les options de démarrage, les serveurs de provisioning et les options spécifiques aux fournisseurs.

1. Créer ou vérifier un serveur DHCP

Pour que les options DHCP soient distribuées, un serveur DHCPv4 est d’abord nécessaire sur Sophos Firewall. La configuration de base complète avec la plage, la passerelle, le DNS, la durée du bail et le test est décrite dans Configurer Sophos Firewall comme serveur DHCP. Le serveur est ensuite modifié sous Network > DHCP.

Il est surtout important que :

• Le serveur DHCP soit associé à une interface.
• Le scope corresponde au réseau dans lequel se trouvent les clients.
• Les serveurs DNS, la passerelle et la durée du bail soient correctement définis.
• Le nom DHCP ne contienne pas d’espaces ou de caractères spéciaux inutiles.
• Les cas particuliers PXE, VoIP, clients légers ou RED soient documentés à l’avance.

Le nom DHCP est particulièrement pertinent pour les commandes CLI. Si le nom contient des espaces ou des caractères spéciaux, les commandes et runbooks ultérieurs deviennent inutilement sujets aux erreurs. Des noms compréhensibles comme DHCP_Server_Avanet_LAN, Home_Scope ou DHCP_VoIP sont plus simples en pratique.

2. Configurer les options DHCP dans WebAdmin

Dans SFOS 22, le chemin complet pour créer une étendue est Network > DHCP > Server > Add. Pour une étendue existante, ouvrez son action de modification. La section DHCP options se trouve dans le formulaire du serveur.

1. Ouvrez Network > DHCP et modifiez le serveur DHCPv4 concerné sous Server.
2. Relevez chaque ligne existante sous DHCP options, avec l’option, le code, le type et la valeur. Ce relevé servira de référence pour le retour arrière.
3. Sélectionnez une option prédéfinie dans la liste ou ajoutez une option personnalisée.
4. Pour une option personnalisée, renseignez Code, Type et Value.
5. Sélectionnez Save.
6. Renouvelez le bail d’un client de test contrôlé et vérifiez l’option reçue.

SFOS 22 distingue :

• Options prédéfinies : Liste d’options DHCP proposées par SFOS avec leurs valeurs par défaut. La correspondance officielle comprend notamment les types String, IP address, Boolean, One-byte numeric value, Two-byte numeric value, Four-byte numeric value et plusieurs types de tableaux.
• Code : Numéro de l’option personnalisée ou constructeur. Il doit provenir de la documentation actuelle du client ou du registre IANA.
• Type : Type de données qui encode Value, par exemple IP address, String, Boolean ou l’un des types numériques et tableaux proposés dans la liste.
• Value : Valeur concrète que le client doit recevoir, par exemple une adresse IP, un nom d’hôte, un chemin ou un port.

Les valeurs correctes sont généralement fournies par le fabricant du système cible. Le fait que SFOS enregistre une valeur sans erreur ne prouve pas que le client interprète son code, son type et son contenu comme prévu.

Pour vérifier les références, l’aide de SFOS 23 distingue les options DHCPv4 dans Appendix A des options DHCPv6 dans Appendix B. Les deux tableaux séparent Data type, Data format et Data value (example) et indiquent la RFC correspondante. Le type de données ne suffit donc pas : le format de la valeur doit lui aussi correspondre à l’option. Les valeurs d’exemple ne sont pas des paramètres imposés pour le réseau concerné. Les codes et valeurs des options DHCPv4 ne doivent pas être repris tels quels pour DHCPv6 ; il faut vérifier la correspondance propre à DHCPv6. L’enrichissement des tableaux de référence ne prouve pas qu’une option a été introduite pour la première fois dans SFOS 23.

Préparer la modification et le retour arrière

Avant Save, consigner chaque ligne concernée avec son option, son code, son type et son ancienne valeur. Tester d’abord sur un seul scope contrôlé. En cas d’échec, modifier le même serveur DHCPv4, supprimer uniquement la nouvelle ligne ou rétablir l’ancienne valeur consignée, puis enregistrer. Renouveler à nouveau le bail du client de test et vérifier dans le DHCP Offer ou ACK que l’état initial est distribué. Ne pas supprimer précipitamment une définition globale via la CLI : un autre serveur DHCP peut encore l’utiliser.

3. Cas d’utilisation typiques

Les options DHCP sont généralement nécessaires lorsque le client a besoin d’informations supplémentaires au démarrage. Les cas fréquents incluent PXE, WDS, clients légers, téléphones VoIP, points d’accès ou certains scénarios hérités.

PXE et WDS

Pour les environnements PXE ou WDS, les options 66 et 67 sont souvent utilisées :

• 66 fait référence au serveur TFTP ou de déploiement.
• 67 contient le nom du fichier de démarrage.

Si le client atteint le serveur mais ne démarre pas, le problème ne vient souvent pas du pare-feu, mais d’un chemin de fichier incorrect, d’un type de données inapproprié ou d’un fichier d’architecture inadapté. Les clients UEFI et BIOS nécessitent souvent des fichiers de démarrage différents.

Important avec les versions SFOS actuelles : Next-server et Boot file sont des champs de boot options distincts dans le serveur DHCPv4. Depuis SFOS 20.0 MR1, ils ne sont plus automatiquement traités uniquement comme les options DHCP 66 et 67. Si un équipement attend explicitement l’option 66 ou 67, ces valeurs doivent être configurées volontairement sous DHCP options et pas seulement dans les champs de boot options.

Lors d’une mise à niveau vers SFOS 20.0 MR1 ou une version plus récente, les valeurs existantes de Next-server et Boot file sont conservées comme boot options et aussi comme options DHCP 66 et 67. Après une migration, il faut donc vérifier si les valeurs existent en double et si le client évalue la variante attendue.

SFOS accepte une adresse IP ou un FQDN dans Next-server, mais pas une URL. Boot file exige le chemin complet avec le nom du fichier. Les deux valeurs doivent correspondre au serveur de démarrage réellement utilisé et à l’architecture du client.

Clients légers

Les clients légers nécessitent, selon le fabricant, des options pour le serveur de gestion, le serveur d’image ou les paramètres de connexion. Dans les anciens runbooks, on trouve par exemple :

• 161 pour le serveur
• 192 pour un port ou des paramètres supplémentaires

Que ces codes soient corrects dépend du fabricant et du modèle de client léger utilisé. Il ne faut donc pas adopter ces codes aveuglément, mais toujours les vérifier par rapport à la documentation du fabricant.

Téléphones IP Avaya comme exemple concret de fabricant

L’aide de SFOS 22 présente les options 176 et 252 sous forme de valeurs String pour les téléphones Avaya. Les adresses IP et le port indiqués sont uniquement des valeurs de documentation et doivent être remplacés par les véritables serveurs de communication, TFTP et HTTP de l’environnement :

Option 176, String: MCIPADD=192.168.30.99,MCPORT=1719,TFTPSRVR=192.168.30.201
Option 252, String: ConfigHttpSrvr=192.168.30.102

Après le renouvellement du bail, il faut vérifier dans le DHCP Offer ou ACK que le client reçoit exactement ces chaînes. Les journaux du téléphone et des serveurs doivent ensuite confirmer que l’appareil utilise réellement les services prévus. Cet exemple ne constitue pas une configuration Avaya universelle.

Cas particuliers RED plus anciens

Dans les environnements plus anciens, il y avait des cas où un Sophos RED 15w ne reconnaissait pas correctement le point d’accès intégré. Pour cela, une option DHCP spécifique au fabricant était parfois utilisée, par exemple avec le code d’option 234 et une valeur comme 10.10.10.12.

Ce n’est pas une norme générale pour les installations SD-RED modernes. En tant qu’exemple hérité, c’est néanmoins utile car cela montre comment définir des codes d’option personnalisés et les lier à un serveur DHCP.

Pour les conceptions RED actuelles, l’article Configurer et dépanner Sophos SD-RED est plus utile. Pour les questions concernant les interfaces, VLAN, ponts ou conceptions RED, Planifier et configurer les zones et interfaces de Sophos Firewall est également utile.

4. Bien situer DHCP Relay

Avec DHCP Relay, Sophos Firewall transmet les requêtes des clients à un serveur situé dans un autre réseau. Les options DHCP se configurent donc sur le serveur qui attribue le bail, pas sur le pare-feu relais.

Configurer et tester le relais DHCP sur Sophos Firewall explique le choix de l’interface, plusieurs serveurs, les réseaux locaux ainsi que les VPN IPsec policy-based et route-based avec des exemples, des règles, des commandes et Packet Capture.

5. Utiliser la CLI de manière contrôlée

SFOS 22 documente toujours les deux étapes CLI : définir une option avec system dhcp dhcp-options add, puis la lier à un serveur DHCP avec system dhcp dhcp-options binding add. La présentation actuelle de Device Console ne fournit qu’un aperçu abrégé de la commande, tandis que la procédure officielle Avaya présente la syntaxe complète. WebAdmin reste plus clair pour les nouvelles configurations standard ; la CLI est surtout utile pour les runbooks existants, les cas de support et les migrations contrôlées.

N’envisagez Device Console que si :

• un ancien article ou runbook repose déjà sur des commandes CLI
• des options fournisseurs inhabituelles doivent être testées
• on souhaite voir exactement quelles liaisons sont enregistrées en interne en cas de support
• un environnement a été repris d’une version SFOS très ancienne
• une commande doit être reproduite ou vérifiée dans une documentation

Si vous devez employer une syntaxe confirmée pour la version installée, consultez d’abord Se connecter à Sophos Firewall via SSH. Après la connexion, utilisez 4. Device Console, et non Advanced Shell. Sauvegardez la configuration actuelle de l’interface web et les bindings existants avant toute modification.

Principe de base de la CLI : définir et lier une option

Dans la configuration CLI, il y a deux étapes :

1. L’option DHCP est définie.
2. L’option est liée à un serveur DHCP et reçoit une valeur.

D’abord, l’option est définie :

system dhcp dhcp-options add optioncode optionname optiontype

Les espaces réservés signifient :

• optioncode: code d’option DHCP numérique
• optionname: nom librement choisi de l’option
• optiontype: type de données, par exemple ipaddress ou string

Exemple pour une adresse IP comme option DHCP :

system dhcp dhcp-options add optioncode 234 optionname dhcp_magic_ip optiontype ipaddress

Ensuite, l’option est liée à un serveur DHCP :

system dhcp dhcp-options binding add dhcpname optionname(234) value

Les espaces réservés signifient :

• dhcpname: nom du serveur DHCP dans la configuration de la Sophos Firewall
• optionname(234): nom de l’option précédemment définie, y compris le code d’option entre parenthèses
• value: valeur à distribuer aux clients

Exemple :

system dhcp dhcp-options binding add dhcpname dhcp_red_avanet optionname dhcp_magic_ip(234) value 10.10.10.12

6. Exemples CLI

La syntaxe permettant de définir et de lier des options est officiellement documentée dans la procédure Avaya actuelle de SFOS 22. En revanche, les valeurs ci-dessous pour les clients légers, WDS et RED sont des exemples propres à un environnement : le code d’option, le type de données et le contenu doivent être vérifiés dans la documentation actuelle du fabricant avant toute utilisation.

Serveur de clients légers

Avec cette option, un client léger est informé du serveur sur lequel se trouve l’image ou le composant de gestion :

system dhcp dhcp-options add optioncode 161 optionname ThinClientServer optiontype ipaddress
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServer(161) value '10.10.10.12'

Si un port est également nécessaire, il peut être défini comme une chaîne :

system dhcp dhcp-options add optioncode 192 optionname ThinClientServerPort optiontype string
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServerPort(192) value '443'

WDS et PXE

Une valeur d’option DHCP pour le serveur WDS ou TFTP peut être définie ainsi :

system dhcp dhcp-options binding add dhcpname Home_Scope optionname TFTP_Server_Name(66) value 172.16.16.11

Le nom du fichier de démarrage pour l’environnement pré-boot est fourni en tant qu’option 67 :

system dhcp dhcp-options binding add dhcpname Home_Scope optionname Bootfile_Name(67) value \boot\x64\wdsnbp.com

Par environnement pré-boot, on entend l’environnement de démarrage avec lequel un client démarre pendant l’installation ou la restauration. Selon l’environnement, le chemin requis peut varier, notamment pour les clients UEFI, BIOS, 32 bits et 64 bits.

Afficher les options existantes

Avant de modifier, il est conseillé d’afficher les options existantes :

system dhcp dhcp-options list

La procédure officielle de SFOS 22 indique que, pour DHCPv4, le pare-feu prend en charge les objets d’option dont les codes vont de 1 à 255, mais que cette commande CLI n’affiche que les options 1 à 76. Appendix A, le registre IANA et la documentation du client ou du fabricant restent les références faisant autorité pour les codes, les types et l’encodage.

Afficher les liaisons d’un serveur DHCP :

system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN

Bien que la commande actuelle mentionne l’action delete, une suppression globale n’est pas un retour arrière sûr par défaut : la définition peut être liée à d’autres serveurs DHCP. Pour un seul scope, rétablir plutôt l’état précédent consigné dans WebAdmin.

7. Sources d’erreurs typiques

Si une option DHCP est enregistrée mais n’a pas l’effet escompté sur le client, cela est souvent dû à l’un de ces points :

• Le mauvais serveur DHCP répond à la requête.
• Le mauvais scope ou la mauvaise interface a été modifié.
• Le type de données ne correspond pas à la valeur attendue.
• L’adresse IP, le FQDN, le port ou le chemin est mal saisi.
• Le chemin du fichier de démarrage ne correspond pas à l’architecture du client.
• Le client attend une chaîne, mais l’option a été définie comme une adresse IP.
• Le fabricant utilise des options spécifiques au fournisseur qui nécessitent des paramètres supplémentaires.
• Le bail n’a pas été renouvelé après la modification.
• Le relais DHCP est utilisé alors que l’option a été maintenue sur la Sophos Firewall.

Après une modification, il est conseillé de renouveler le bail sur le client de test et de vérifier si le client reçoit réellement les options attendues. Si le comportement ne correspond toujours pas, une capture de paquets est souvent plus rapide qu’une longue supposition : dans les paquets DHCP, on peut voir quel serveur répond et quelles options sont réellement livrées.

8. Tester la modification

Après avoir enregistré une option DHCP, il ne faut pas seulement attendre que le prochain client obtienne un nouveau bail. Un test contrôlé avec un appareil connu dans le réseau concerné est préférable.

Procédure recommandée :

1. Connecter le client de test dans le bon VLAN ou interface.
2. Renouveler l’ancien bail ou redémarrer le client.
3. Vérifier quelles adresses DHCP, passerelle, serveurs DNS et options supplémentaires sont reçues.
4. Tester le système cible, par exemple démarrage PXE, démarrage WDS, enregistrement du client léger ou provisioning du téléphone.
5. Vérifier dans WebAdmin si le bail apparaît dans le scope DHCP attendu.
6. Si le résultat ne correspond pas, vérifier avec Packet Capture quel serveur DHCP répond et quelles options sont incluses dans l’offre ou l’ACK.

Pour une capture étroite, un filtre sur UDP 67 et 68 entre le client et le serveur DHCP suffit généralement. L’utilisation de l’outil WebAdmin est décrite dans Utiliser la capture de paquets de Sophos Firewall dans WebAdmin.

Lors des tests PXE et WDS, il est également conseillé de documenter si le client de test utilise BIOS ou UEFI. De nombreux problèmes de démarrage ne sont pas dus au DHCP lui-même, mais à un fichier de démarrage qui ne correspond pas à l’architecture.

9. Dépannage par symptômes

Si les options DHCP ne fonctionnent pas, un examen orienté sur les symptômes est souvent plus rapide que de recréer la même option.

• Le client ne reçoit pas d’adresse IP : Le serveur DHCP, le VLAN, l’interface ou le relay ne correspond pas. Vérifier la liste des baux, l’interface, le VLAN et DHCP Relay.
• Le client reçoit une IP, mais pas l’option : Le mauvais scope ou le mauvais serveur DHCP répond. Vérifier DHCP offer ou ACK avec Packet Capture.
• PXE trouve le serveur, mais ne démarre pas : L’option 67, le chemin du fichier ou l’architecture ne correspond pas. Vérifier le fichier de démarrage BIOS/UEFI et les logs TFTP/WDS.
• Le client léger ne se connecte pas : Code d’option, type ou valeur fabricant incorrect. Comparer la documentation du fabricant et la valeur réellement fournie.
• La modification agit plus tard : Le client utilise encore un ancien bail. Renouveler le bail, redémarrer le client ou tenir compte de la durée du bail.
• La commande CLI ne fonctionne pas : Nom DHCP, nom d’option ou notation entre parenthèses incorrect. Vérifier system dhcp dhcp-options list et la sortie du binding.

Si une autre réponse de serveur DHCP apparaît dans la capture, il faut d’abord clarifier la conception du réseau. Deux serveurs DHCP dans le même domaine de diffusion sont une cause classique de comportement changeant. Pour des questions plus complexes concernant les VLAN, ponts ou interfaces, Planifier et configurer les zones et interfaces de Sophos Firewall est utile.

Questions fréquentes