Port TCP DHCP : il n’existe pas, DHCP tourne sur UDP 67 et 68

DHCP ne possède pas de port TCP : tout le protocole tourne sur UDP, port 67 côté serveur et port 68 côté client (RFC 2131). Si un pare-feu, un scan ou une documentation vous parle d'un « port TCP DHCP », c'est soit une erreur, soit une fonction annexe entre serveurs comme le failover ISC (TCP 647).

Sommaire

Il n’y a pas de port TCP pour DHCP

La requête est piégée. DHCP est défini par la RFC 2131 (mars 1997) comme un protocole porté par UDP, et uniquement UDP. Le serveur écoute sur le port 67, le client émet depuis le port 68 et reçoit les réponses sur ce même port. Ces deux numéros sont hérités de BOOTP (RFC 951, 1985), dont DHCP est l'extension directe, ce qui explique que Wireshark ait longtemps nommé son filtre `bootp` avant de le renommer `dhcp` à partir de la version 3.0.

Concrètement, si vous cherchez « tcp port dhcp » parce qu'une règle de pare-feu, une fiche de configuration ou un audit vous le demande, vous pouvez ouvrir TCP 67 et TCP 68 : rien n'y répondra jamais. Un `nmap -sT -p 67 serveur` renvoie `closed` ou `filtered` sur un serveur DHCP en parfait état de marche. Il faut scanner en UDP (`nmap -sU -p 67`) pour voir quelque chose, et encore, la réponse dépend de la façon dont le démon traite un datagramme UDP vide.

La confusion vient souvent de DNS, le voisin de DHCP dans toutes les configurations réseau. DNS, lui, utilise bien UDP 53 et TCP 53 (transferts de zone, réponses trop longues pour un datagramme, puis DNS over TLS sur 853). DHCP n'a pas cet équivalent. Un serveur DHCP n'ouvre aucune socket TCP pour parler à ses clients.

Pourquoi UDP et pas TCP : le client n’a pas encore d’adresse

Au moment où une machine démarre, elle n'a ni adresse IP, ni masque, ni passerelle. TCP est inutilisable dans cet état : le handshake SYN / SYN-ACK / ACK suppose deux extrémités identifiées par une adresse, et un serveur ne peut pas renvoyer un SYN-ACK vers 0.0.0.0.

UDP s'affranchit de cette contrainte. Le premier message, DHCPDISCOVER, part avec une source 0.0.0.0, une destination 255.255.255.255 (broadcast limité), port source 68, port destination 67. Le serveur répond par un DHCPOFFER, en broadcast ou en unicast vers l'adresse MAC du client selon le bit BROADCAST du champ `flags`. Le client confirme par DHCPREQUEST, le serveur valide par DHCPACK. Quatre messages, mémorisés sous le sigle DORA. Avant d'utiliser l'adresse, le client la sonde en ARP pour vérifier que personne ne l'occupe déjà, comme le recommande la section 4.4.1 de la RFC.

Le renouvellement, lui, se fait en unicast. À T1, soit 50 % du bail par défaut (RFC 2131, section 4.4.5), le client contacte directement le serveur qui lui a attribué l'adresse, toujours en UDP 68 vers 67. À T2, 87,5 % du bail, s'il n'a pas eu de réponse, il repasse en broadcast vers n'importe quel serveur. Sur ISC dhcpd, le bail par défaut (`default-lease-time`) vaut 43200 secondes, soit 12 heures ; sur un serveur DHCP Windows, 8 jours.

Les ports à connaître : IPv4, IPv6, relais et failover

Le seul TCP que vous rencontrerez autour de DHCP concerne la communication entre serveurs, jamais entre serveur et client. Sur ISC DHCP, la directive `port 647;` dans le bloc `failover peer` ouvre un canal TCP pour synchroniser les baux entre les deux serveurs redondants (port enregistré à l'IANA sous le nom dhcp-failover). Sur Kea, le successeur, le hook `libdhcp_ha.so` dialogue en HTTP via l'agent de contrôle `kea-ctrl-agent`, port 8000 par défaut. Si vous filtrez entre deux serveurs DHCP en haute disponibilité, c'est là qu'il faut ouvrir du TCP. Nulle part ailleurs.

En IPv6 les numéros changent, 546 et 547, et le broadcast n'existe plus : le client émet vers l'adresse multicast ff02::1:2 (tous les serveurs et relais DHCP du lien). Le principe reste identique, UDP sans état, parce que le client ne dispose que d'une adresse de lien local fe80::/10 à ce stade.

Usage	Transport	Port	Référence
Serveur DHCPv4 (écoute)	UDP	67	RFC 2131
Client DHCPv4 (émission et réception)	UDP	68	RFC 2131
Relais DHCPv4 (ip helper-address)	UDP	67 vers le serveur, 68 vers le client	RFC 1542, option 82 RFC 3046
Client DHCPv6	UDP	546	RFC 8415
Serveur et relais DHCPv6	UDP	547	RFC 8415
Failover entre serveurs ISC DHCP	TCP	647 (dhcp-failover)	Registre IANA, doc ISC
Kea : agent de contrôle et HA	TCP (HTTP)	8000 par défaut	Documentation ISC Kea

Ouvrir, vérifier et capturer les ports DHCP

Sur un serveur Linux, vérifiez d'abord que le démon écoute : `ss -ulnp | grep ':67 '` doit afficher `dhcpd` ou `kea-dhcp4`. Si la ligne est vide, le pare-feu n'est pas votre problème, le service ne tourne pas ou écoute sur la mauvaise interface.

Pour forcer un cycle complet côté client et observer les échanges : `ipconfig /release` puis `ipconfig /renew` sous Windows, `sudo dhclient -r eth0 && sudo dhclient -v eth0` sur Debian et dérivés. Le `-v` affiche chaque étape avec le port utilisé, par exemple `DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3`. C'est la trace la plus lisible pour un débutant, avant même Wireshark.

ufw : `sudo ufw allow 67/udp` côté serveur ; côté client, `sudo ufw allow 68/udp` seulement si la politique entrante par défaut est en deny
iptables : `iptables -A INPUT -p udp --dport 67 -j ACCEPT`, avec `-i eth0` pour limiter à l'interface qui sert le LAN
firewalld : `firewall-cmd --permanent --add-service=dhcp && firewall-cmd --reload`, le service prédéfini couvre UDP 67
Windows : la règle « Core Networking - Dynamic Host Configuration Protocol (DHCP-In) » autorise UDP 68 en entrée ; ne la désactivez pas en durcissant un poste
tcpdump : `tcpdump -i eth0 -n -v 'udp port 67 or udp port 68'` montre les quatre messages DORA en clair, avec l'adresse offerte et les options
Wireshark : filtre d'affichage `dhcp` (ou `bootp` avant la 3.0), puis `dhcp.option.dhcp == 2` pour ne garder que les OFFER

Trois pannes où le port UDP est en cause

Le poste récupère une adresse 169.254.x.x. C'est l'APIPA (RFC 3927) : le client a envoyé ses DISCOVER en UDP 68 vers 67 et n'a rien reçu dans le délai imparti. Trois causes reviennent sans cesse : le serveur ne tourne pas, un pare-feu local bloque le retour sur UDP 68, ou le poste est dans un VLAN sans serveur et sans relais. Un `tcpdump` sur le serveur tranche en dix secondes. Si les DISCOVER n'y arrivent pas, cherchez en amont.

Un VLAN sans relais. Le broadcast 255.255.255.255 ne franchit pas un routeur. Si vos clients sont dans le VLAN 20 et le serveur dans le VLAN 10, il faut un agent relais sur la passerelle du VLAN 20 (`ip helper-address 10.0.10.5` sur Cisco, un service dhcp-relay sur un pare-feu). Le relais réécrit le paquet en unicast, renseigne le champ `giaddr` avec sa propre adresse pour que le serveur choisisse le bon pool, et l'envoie en UDP 67 vers le serveur. Sans lui, les clients n'obtiennent rien et le serveur ne voit aucune requête, ce qui rend le diagnostic trompeur : ses journaux restent vides.

Un serveur DHCP pirate. Quelqu'un branche une box personnelle sur une prise du bureau ; sa fonction DHCP répond plus vite que la vôtre et distribue du 192.168.1.x avec elle-même en passerelle. Le mot « port » prend ici un autre sens : le DHCP snooping d'un commutateur géré ne filtre pas un port UDP mais un port physique. Seules les interfaces déclarées `trust` ont le droit de laisser passer des OFFER et des ACK, tout le reste est jeté. Sur Cisco : `ip dhcp snooping` en global, puis `ip dhcp snooping trust` sur l'interface qui mène au vrai serveur.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Sur quel protocole de transport repose DHCP ?

Questions fréquentes

DHCP utilise-t-il le port 67 ou le port 68 ?

Les deux, mais pas dans le même sens. Le serveur écoute sur UDP 67, le client émet depuis UDP 68 et attend les réponses sur ce même port 68. Un paquet client vers serveur va donc de 68 vers 67, la réponse de 67 vers 68.

Faut-il ouvrir le port TCP 67 sur mon pare-feu ?

Non. Aucun serveur DHCP n'écoute en TCP sur ce port. Ouvrir TCP 67 ne casse rien mais ne sert à rien. Ce qui doit passer, c'est UDP 67 en entrée sur le serveur et UDP 68 en entrée sur les clients.

Pourquoi Nmap ne voit-il pas mon serveur DHCP ?

Parce qu'un scan par défaut (`-sS` ou `-sT`) ne teste que TCP. Lancez `nmap -sU -p 67 adresse` pour un scan UDP, ou plus fiable, `nmap --script broadcast-dhcp-discover`, qui envoie un vrai DHCPDISCOVER sur le segment et affiche le serveur qui répond, y compris un serveur pirate.

Quels sont les ports DHCP en IPv6 ?

UDP 546 pour le client et UDP 547 pour le serveur et les relais, définis dans la RFC 8415. Le client s'adresse au groupe multicast ff02::1:2 au lieu du broadcast, depuis son adresse de lien local.

Le renouvellement du bail passe-t-il par les mêmes ports ?

Oui, toujours UDP 68 vers 67. La différence est que le DHCPREQUEST de renouvellement part en unicast vers le serveur d'origine tant que T2 (87,5 % du bail) n'est pas atteint, puis repasse en broadcast si ce serveur ne répond plus.