Configurer et tester le relais DHCP sur Sophos Firewall

Un relais DHCP transmet les requêtes DHCP d’un réseau client à un serveur situé dans un autre réseau. Sur Sophos Firewall, ouvrez Network > DHCP, ajoutez sous Relay un agent pour l’interface client et saisissez l’adresse IP du serveur DHCP.

Procédure rapide : Sélectionner l’interface client, saisir le serveur DHCP, vérifier l’étendue correspondante et le chemin retour sur le serveur, renouveler le bail et capturer l’échange avec port 67 or port 68. Relay through IPsec s’active uniquement avec un VPN IPsec policy-based, pas avec un VPN route-based. Pour un VPN route-based, clarifier d’abord avec Sophos Support les divergences entre les sources décrites ci-dessous et la prise en charge du build exact ; cette procédure rapide ne constitue pas une validation de cette architecture.

L’exemple utilise le réseau client 10.20.0.0/24, l’interface relais 10.20.0.1 et le serveur DHCP 172.16.16.17. Il s’agit d’un exemple IPv4 : adaptez toutes les adresses, l’interface client et le nom à votre réseau. L’étendue est la plage d’adresses, accompagnée des paramètres réseau, dans laquelle le serveur attribue les baux. La passerelle doit se trouver dans le réseau client et être joignable ; le serveur DNS doit être joignable depuis le client. Avant toute modification, sauvegardez les étendues, les agents relais et les routes existants, et utilisez un client de test qui obtient automatiquement ses adresses par DHCP.

Prérequis et limitations

Le serveur DHCP doit posséder une étendue pour 10.20.0.0/24. Sophos Firewall n’attribue pas le bail elle-même ; elle utilise l’adresse de l’interface relais pour que le serveur sélectionne la bonne étendue.

Le relais doit disposer d’une route vers le serveur, et le serveur d’un chemin retour vers 10.20.0.1.

Si le pare-feu doit distribuer directement des adresses dans le réseau client connecté, consultez plutôt Configurer Sophos Firewall comme serveur DHCP. Les options DHCP se configurent sur le serveur qui attribue le bail.

Un serveur DHCPv4 et un relais peuvent également fonctionner sur la même Sophos Firewall :

• Le serveur écoute sur une autre interface.
• Accept client request via relay est activé.
• Chaque sous-réseau client possède sa propre étendue serveur avec une plage de baux, un masque de sous-réseau, une passerelle et des paramètres DNS adaptés.

L’agent relais utilise l’interface client correspondante et cible l’adresse de l’interface du serveur ; les clients du sous-réseau du serveur continuent à recevoir leurs adresses directement, sans relais.

Un serveur DHCPv6 et un relais DHCPv6 ne peuvent pas être actifs simultanément. Si le pare-feu doit distribuer lui-même les adresses IPv6, Configurer un serveur DHCPv6 sur Sophos Firewall explique la procédure distincte avec Router Advertisement, DUID et contrôle des baux.

Les limitations suivantes s’appliquent :

• L’interface relais doit appartenir au même sous-réseau que les clients et ne doit pas être l’interface du serveur DHCP.
• Les agents relais peuvent utiliser des interfaces physiques et virtuelles telles que VLAN, Wireless ou Bridge, mais pas un Interface Alias.
• Aucun agent relais ne doit être créé dans le sous-réseau du serveur DHCP.
• Un agent relais distinct doit être créé pour chaque sous-réseau client.
• Chaque agent relais peut contenir jusqu’à huit serveurs DHCP. La requête est envoyée à tous et le client utilise la première offre.
• Un serveur DHCPv4 et un relais DHCPv4 peuvent fonctionner sur le même pare-feu, mais pas sur la même interface.
• Un serveur DHCPv6 et un relais DHCPv6 ne peuvent pas être actifs simultanément sur le même pare-feu.
• Le client et le relais utilisent UDP 67 et 68 ; le relais et le serveur communiquent via UDP 67. Le serveur a besoin d’un chemin retour vers l’IP du relais 10.20.0.1.

Plusieurs cibles de relais devraient fournir des paramètres réseau et des options cohérents au même client, mais avec une attribution des adresses coordonnée (basculement entre serveurs selon leur documentation) ou des plages d’attribution dynamique sans chevauchement. Des réponses différentes entraînent sinon un comportement difficile à reproduire.

Configurer DHCP Relay sans VPN

1. Ouvrir Network > DHCP.
2. Sous Relay, cliquer sur Add.
3. Saisir un nom unique, par exemple relay-clients-vlan20.
4. Pour cet exemple, sélectionner IPv4 sous IP version. Pour IPv6, ne pas reprendre les adresses IPv4 ni les ports UDP de ce guide.
5. Sous Interface, sélectionner l’interface client VLAN20 - 10.20.0.1.
6. Sous DHCP server IP, saisir le serveur 172.16.16.17, l’ajouter à la liste avec le bouton plus et vérifier qu’il y figure.
7. Laisser Relay through IPsec désactivé et enregistrer.

Renouveler ensuite le bail depuis un client de test. Les requêtes relais constituent du trafic généré par le système ; cette procédure ne nécessite donc pas de règle dédiée sur le pare-feu relais. Les équipements entre le relais et le serveur doivent néanmoins autoriser UDP 67 dans les deux sens ; le segment client utilise UDP 67/68. Si le client ne reçoit aucune adresse, vérifier d’abord que le serveur possède une étendue pour 10.20.0.0/24 et connaît une route vers l’interface relais. Pour les problèmes de VLAN, consultez Configurer une interface VLAN sur Sophos Firewall.

API XML : identité et limite de validation IPv6

Pour l’automatisation, cette même configuration correspond à l’objet DHCPRelay : Name désigne l’agent relais, Interface l’interface client, IPFamily la famille choisie explicitement, IPv4 ou IPv6, et DHCPServerIP la liste des serveurs. La documentation Add/Edit pour SFOS 22 et 23 indique que ces quatre champs sont obligatoires ; la valeur par défaut documentée pour IPFamily est IPv4. DHCPServerIP est décrit comme un ARRAY acceptant IPADDRESS et IPADDRESS6 : plusieurs valeurs sont autorisées, les doublons sont ignorés et LINKLOCAL est exclu. Plusieurs cibles de relais restent donc possibles ; le seul champ de substitution présent dans l’exemple ne démontre ni la sérialisation de la liste ni un encodage IPv6. Conserver délibérément l’état de Relay through IPsec adapté à la variante VPN expliquée ci-dessous, sans le déduire d’un exemple d’API.

Le tableau des paramètres indique également un maximum de 15 caractères pour DHCPServerIP. Cette indication n’est pas compatible avec toutes les représentations d’adresses IPv6 autorisées par IPADDRESS6 : la documentation est incohérente sur ce point et ne démontre pas comment le validateur du build concerné traite IPv6. Cela ne permet de conclure ni que le produit ne prend pas en charge le relais DHCPv6, ni qu’un autre encodage existe, ni qu’il est permis de raccourcir les adresses.

Pour IPv6, utiliser d’abord la configuration manuelle dans WebAdmin et, avant toute automatisation IPv6, clarifier avec Sophos Support le schéma, la validation des adresses et le format de la liste des serveurs pour la version SFOS et le build exacts. Une configuration enregistrée dans l’interface graphique ou l’obtention réussie d’un bail par un client ne confirme pas la validité d’une requête XML IPv6. Les vérifications côté client et du flux de paquets, ainsi que le retour arrière tenant compte de l’état initial décrits ci-dessous, restent nécessaires ; les adresses IPv4 et les ports UDP de cet exemple ne doivent pas être repris pour IPv6.

Modifier l’intervalle de rafraîchissement du Relay uniquement de manière ciblée

Device Console affiche l’intervalle global des paquets de rafraîchissement DHCP Relay avec :

system dhcp dhcp-relay-refresh-interval show

La valeur par défaut documentée est de 10 secondes. Sophos indique deux limites supérieures différentes sur la même page SFOS 22 : la syntaxe affiche 10000, tandis que la description de l’option indique 1000 secondes. Ne pas utiliser une valeur supérieure à 1000 sur la seule base de la ligne de syntaxe. Faire d’abord confirmer tout besoin exceptionnel par Sophos Support.

La modification utilise ce modèle :

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

Remplacer l’espace réservé par une valeur vérifiée. Ne pas modifier cet intervalle comme optimisation générale ; il ne corrige ni un scope serveur absent, ni le routing, ni IPsec, ni les règles de firewall. Consigner d’abord la valeur actuelle, puis utiliser show, obtenir un nouveau bail client et vérifier le flux UDP 67/68. Le rollback rétablit la valeur lue auparavant.

DHCP Relay via un VPN IPsec route-based

L’aide SFOS-22 et SFOS-23 décrit DHCP Relay via XFRM vers un serveur DHCP externe situé derrière le pare-feu central. L’architecture décrite utilise un tunnel route-based Any-to-Any. Les Traffic Selectors route-based ne sont pas confirmés pour cette procédure.

⚠️ L’aide officielle présente des contradictions dans SFOS 22 et SFOS 23 : la vue d’ensemble DHCP et Routing and NAT for IPsec tunnels indiquent toutes deux que DHCP Relay ne fonctionne pas via un VPN route-based. En revanche, Add a DHCP relay et le guide route-based distinct décrivent l’architecture Any-to-Any ci-dessous. Cela ne permet pas de conclure à une prise en charge confirmée du produit. Si les champs diffèrent, ne pas utiliser les options policy-based à la place, mais clarifier la topologie et le build exact avec Sophos Support.

⚠️ Le conflit entre les sources reste non résolu ; l’architecture est documentée, mais n’a été ni confirmée ni testée comme capacité du produit. Avant sa mise en œuvre, Sophos Support doit clarifier la prise en charge du build SFOS exact et de la topologie Any-to-Any avec un serveur DHCP externe. Cette confirmation est un prérequis, pas une preuve déjà disponible ici. Tant que ce point n’est pas clarifié, ne modifiez pas la configuration route-based en suivant cette procédure.

L’architecture documentée comporte les prérequis suivants. Tant que la situation n’a pas été clarifiée avec Sophos Support, ces détails servent uniquement à la planification ; les modifications de configuration ne doivent être effectuées qu’après confirmation :

1. Des connexions IPsec Any-to-Any sur les deux pare-feu.
2. Des interfaces XFRM adressées avec une gateway.
3. Des routes statiques, SD-WAN ou dynamiques sur les deux pare-feu : du relais vers le serveur DHCP et, pour la réponse, vers l’IP du relais 10.20.0.1.
4. L’accès IPsec autorisé sous Administration > Device access pour les interfaces WAN concernées.
5. Une règle au siège de VPN vers la zone du serveur avec Source 10.20.0.1, Destination 172.16.16.17 et Service DHCP.

Sur le site distant, l’interface client est configurée comme agent relais ; Relay through IPsec reste désactivé. La requête relais y constitue du trafic généré par le système et ne nécessite pas de règle de pare-feu DHCP dédiée.

Une route SD-WAN utilise :

• Any comme Source ;
• l’hôte 172.16.16.17 comme Destination ;
• DHCP comme Service ;
• la passerelle XFRM distante.

Sur le site central, la route de retour du serveur DHCP vers l’IP du relais 10.20.0.1 passe par la passerelle XFRM.

Pour empêcher ce trafic de passer par une autre passerelle en cas de panne du tunnel, activer Route only through specified gateways dans les deux routes SD-WAN dédiées.

Pour créer ces routes SD-WAN dédiées après confirmation :

1. Ouvrir Routing > SD-WAN routes, sélectionner IPv4 > Add et attribuer un nom unique.
2. Sous Link selection settings, sélectionner Primary and backup gateways.
3. Renseigner sous Primary gateway la passerelle XFRM appropriée du pare-feu concerné ; enregistrer ensuite.

Sur le site central, créer la règle de pare-feu sous Rules and policies > Firewall rules > Add firewall rule > New firewall rule avec les hôtes et le service indiqués ci-dessus.

La Destination zone correspond au réseau réel du serveur, par exemple DMZ, et non automatiquement à LAN.

L’option Fail-closed empêche le routage de secours, mais signifie aussi qu’aucun nouveau bail ne peut être obtenu par ce chemin en cas de panne du tunnel.

Les règles VPN générales du tunnel Any-to-Any doivent également être présentes. Configurer un VPN IPsec Site-to-Site sur Sophos Firewall décrit en détail la configuration du tunnel et des routes XFRM.

⚠️ Cette procédure route-based s’applique à un serveur DHCP externe situé derrière le pare-feu du siège. Une interface Sophos Firewall configurée comme serveur DHCP central n’est pas prise en charge dans cette conception.

DHCP Relay via un VPN IPsec policy-based

Avec IPsec policy-based, Relay through IPsec est activé sur le site distant. Les sous-réseaux locaux et distants de la connexion IPsec doivent couvrir l’interface relais et le serveur DHCP.

Si un serveur DHCP externe se trouve derrière le pare-feu central, deux règles y sont nécessaires.

Un tunnel existant et fonctionnel est un prérequis. S’il doit être créé, le faire sous Site-to-site VPN > IPsec > IPsec connections > Add avec Connection type: Policy-based :

• Sur le site distant, Gateway type: Initiate the connection.
• Sur le site central, Respond only.

Listening interface correspond à l’interface WAN locale de chaque pare-feu, et Gateway address à l’adresse WAN du site opposé.

L’authentification et la Preshared key doivent correspondre ; les réseaux locaux et distants sont inversés sur le site opposé. Pour l’exemple avec un serveur externe, il s’agit de 10.20.0.0/24 et du réseau réellement utilisé par le serveur.

Autoriser l’accès IPsec depuis WAN sous Administration > Device access.

Sur le site distant, le trafic relais généré par le système ne nécessite pas de règle de pare-feu créée automatiquement ; sur le site central, les règles créées automatiquement peuvent être limitées aux hôtes DHCP, zones et services indiqués ci-dessous.

Ne pas supprimer les règles existantes pour les autres flux VPN.

• VPN vers la zone du serveur : réseau du relais vers le serveur DHCP, Service DHCP.
• Zone du serveur vers VPN : serveur DHCP vers le réseau client, Service DHCP.

Pour la procédure policy-based documentée, l’adresse source du trafic relais généré par le système doit être fixée à l’IP du relais avec sys-traffic-nat.

Les commandes suivantes s’exécutent dans la Device Console après la connexion SSH.

L’aide spécifique au routage/NAT pour SFOS 22 et 23 distingue le trafic transféré du trafic généré par le système : ce dernier ne nécessite pas de system ipsec_route supplémentaire.

La vue d’ensemble générale DHCP mentionne toutefois encore une étape de création de route IPsec. Cette différence ne justifie pas l’ajout systématique d’une autre route : vérifier d’abord la route existante et le flux de paquets, puis faire appel à Sophos Support si le comportement du build diffère.

Le NAT ne remplace pas une route.

• destination reste l’adresse du serveur.
• snatip est l’adresse source du relais, et non celle du serveur.
• Une règle WAN-MASQ ordinaire ne remplace pas sys-traffic-nat.

Relever l’état actuel avant la modification :

show advanced-firewall

⚠️ sys-traffic-nat add modifie la configuration NAT globale du trafic généré par le système. La destination et l’adresse source doivent correspondre au tunnel IPsec et au chemin retour.

Dans cet exemple, définissez l’adresse de l’interface relais comme adresse source vers le serveur DHCP :

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

Exécutez ensuite de nouveau show advanced-firewall et vérifiez que cette entrée exacte existe. Le serveur doit pouvoir atteindre 10.20.0.1 via le tunnel. Si cette entrée existait avant la modification, elle ne fait pas partie du retour arrière de cette procédure.

Pour une entrée créée par cette procédure, le retour arrière est :

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Créer une route IPsec sur Sophos Firewall explique d’autres cas particuliers de routage policy-based et les procédures pour les anciennes versions de SFOS.

Lorsque le pare-feu du siège est le serveur DHCP

Uniquement dans ce scénario policy-based, où la Sophos Firewall du siège est elle-même le serveur DHCP, laissez Create firewall rule décoché dans les connexions IPsec des deux pare-feu. La communication DHCP avec le serveur intégré au pare-feu n’est pas équivalente à la transmission vers un serveur externe ; les règles de transmission du siège décrites plus haut concernent le scénario avec serveur externe. Conservez l’accès IPsec depuis WAN sous Administration > Device access ainsi que les règles nécessaires aux autres flux utilisateurs de la VPN.

Si la Sophos Firewall centrale fait elle-même office de serveur DHCP avec IPsec policy-based :

1. Créer ou modifier une étendue serveur sous Network > DHCP > Server.
2. Activer Accept client request via relay, saisir une plage de baux dans 10.20.0.0/24 et définir 10.20.0.1 comme passerelle.
3. Sur l’agent relais, renseigner l’adresse de l’interface serveur du pare-feu central sous DHCP server IP ; dans l’exemple NAT précédent, cette adresse remplace alors 172.16.16.17.

Un exemple adaptable pour Dynamic IP lease est la plage de 10.20.0.10 à 10.20.0.30 avec le masque de sous-réseau 255.255.255.0 ; la passerelle 10.20.0.1 et les adresses fixes de l’infrastructure restent en dehors du pool.

Choisir le pool en fonction du nombre de clients et des adresses déjà réservées.

Utiliser Use device’s DNS settings uniquement si les serveurs DNS qui y sont configurés sont joignables depuis l’agence.

Pour ce serveur interne au pare-feu, les sélecteurs policy-based du site central utilisent l’adresse de l’interface serveur et le réseau client ; sur le site distant, l’association est inversée.

⚠️ Vérifier la version avant une modification globale : La procédure d’activation suivante s’applique uniquement au scénario documenté pour SFOS 22. Les pages d’aide SFOS 23 disponibles se contredisent : HO firewall as DHCP server and BO firewall as relay agent décrit les baux DHCP via IPsec comme activés par défaut, sans configuration supplémentaire ; la présentation DHCP demande toujours de les activer via la CLI. Ce conflit reste non résolu. Il ne confirme ni l’état réel après une mise à niveau ni la suppression de la commande CLI. Sous SFOS 23, ne pas activer systématiquement le paramètre global : consigner le build exact et l’état actuel, puis faire confirmer d’abord par Sophos Support si une modification est nécessaire. Si l’état n’est pas clair ou si la commande d’état n’est pas disponible, arrêter avant toute modification.

Consignez le build SFOS exact et, avant toute modification, affichez et sauvegardez l’état actuel dans la Device Console du pare-feu du siège qui attribue les baux :

system dhcp lease-over-IPSec show

⚠️ Le paramètre suivant s’applique globalement aux baux DHCP via IPsec. Activez-le uniquement sur le pare-feu qui attribue lui-même les baux. Notez l’état initial affiché afin de ne pas désactiver une configuration antérieure lors du retour arrière.

Uniquement sous SFOS 22, si l’état consigné est désactivé, activez-le puis vérifiez son état avec la commande show précédente. S’il est déjà activé, ne modifiez rien :

system dhcp lease-over-IPSec enable

Uniquement si la fonction était désactivée sur le pare-feu du siège qui attribue les baux et a réellement été activée pendant la procédure autorisée, revenez en arrière avec :

system dhcp lease-over-IPSec disable

Si elle était déjà activée, laissez-la activée. Dans les deux cas, system dhcp lease-over-IPSec show confirme l’état rétabli.

Tester la configuration et résoudre les erreurs

Un agent relais enregistré ne suffit pas à prouver que la configuration fonctionne. Renouvelez le bail depuis un client de test, puis définissez un filtre précis sous Diagnostics > Packet capture > Configure, dans le champ Enter BPF string :

port 67 or port 68

Le flux de paquets devrait montrer successivement :

1. La requête du client.
2. La requête transférée.
3. L’Offer du serveur.
4. Le chemin retour.

Les colonnes In interface, Out interface, Source IP, Destination IP, Ports [src, dst] et Status indiquent où l’échange s’arrête.

Les paquets relais peuvent apparaître comme Generated ou Forwarded. En cas de Violation, Reason fournit la prochaine piste de vérification.

Packet Capture dans Sophos Firewall WebAdmin explique l’utilisation et les champs.

Un Offer seul ne suffit pas : le client doit demander l’adresse et recevoir un ACK.

Vérifier ensuite sur le client l’adresse IP issue du pool prévu, le masque de sous-réseau, la passerelle et les paramètres DNS, puis contrôler l’entrée du bail sur le serveur qui l’a attribué.

Une réponse ping du serveur ne prouve ni la joignabilité UDP ni la réussite d’un échange DHCP.

Ces vérifications doivent être effectuées par l’administrateur.

Les contrôles suivants permettent de circonscrire les erreurs courantes :

• Aucune requête client visible : Vérifier le VLAN, le port du commutateur, l’interface client ou le client DHCP local.
• La requête atteint le pare-feu, mais n’est pas transférée : Vérifier l’interface relais, l’IP du serveur, la route et, avec IPsec policy-based, Relay through IPsec.
• Le serveur reçoit la requête, mais ne répond pas : Vérifier l’étendue du sous-réseau du relais, l’autorisation du serveur et le pare-feu local du serveur.
• L’Offer atteint le site central, mais pas le client : Vérifier la route de retour, les règles du pare-feu central, les sous-réseaux IPsec et l’entrée NAT.
• Le client reçoit une configuration incorrecte : Déterminer quel serveur répond en premier et comparer les étendues et les options DHCP sur toutes les cibles du relais.
• Policy rule denied avec Source 0.0.0.0 : Un client sans adresse commence avec cette adresse source. Vérifier si un serveur DHCP ou un relais prend en charge les requêtes sur la bonne interface client ; ne pas créer de règle Allow générale pour 0.0.0.0 ou Any afin de masquer le symptôme. La vue d’ensemble décrit le rejet en l’absence de serveur ; dans un scénario avec relais, vérifier le chemin réel des paquets plutôt que d’en déduire un blocage général du relais.

Annuler la configuration

Pour un retour arrière planifié, vérifiez d’abord que les clients peuvent joindre un autre serveur DHCP. Supprimez ensuite l’agent relais sous Network > DHCP > Relay. Ne supprimez les routes, objets hôte et règles dédiés qu’une fois que Packet Capture n’affiche plus de requêtes relais ; conservez les objets partagés avec d’autres flux VPN. Avec IPsec policy-based, supprimez également uniquement l’entrée sys-traffic-nat créée par cette procédure. Rétablissez lease-over-IPSec uniquement sur le pare-feu du siège qui attribue lui-même les baux, et seulement si son état a réellement été modifié pendant la procédure autorisée ; restaurez l’état consigné auparavant. Cela ne fait pas partie du retour arrière pour un relais vers un serveur DHCP externe ou pour un état resté inchangé.

Questions fréquentes