A device joins a network, asks for an address, and waits. If it never gets a lease, checking whether “DHCP is open” is not enough: DHCP uses different UDP ports for IPv4 and IPv6, and relays can add another leg to the path.
The ports to remember
| DHCP version | Client | Server or relay |
|---|---|---|
| DHCPv4 | UDP 68 | UDP 67 |
| DHCPv6 | UDP 546 | UDP 547 |
These are UDP ports, not TCP ports. A TCP firewall rule for port 67 or 68 will not allow standard DHCP traffic. Also, don’t swap the IPv4 and IPv6 pairs: DHCPv4 uses 67/68, while DHCPv6 uses 546/547.
For DHCPv4, the client typically sends from UDP 68 to UDP 67, and the server responds from UDP 67 to UDP 68. DHCPv6 assigns UDP 546 to the client and UDP 547 to servers and relay agents.
Why a DHCP request may not look like a normal connection
A new DHCPv4 client usually has no address yet, so it may broadcast to find a server. The familiar exchange is called DORA:
- Discover: the client looks for DHCP servers.
- Offer: a server offers an address and other lease settings.
- Request: the client asks to use an offered address.
- Acknowledge: the server confirms the lease.
The usual port roles remain client UDP 68 and server UDP 67 throughout this exchange. However, delivery can be broadcast or unicast depending on the message and client state. Later renewals may use unicast when the client already has a valid address and knows the server.
That matters when troubleshooting: a simple test of a unicast UDP port does not necessarily reproduce the broadcast behavior of a new client requesting a lease.
Relays change the path, not the port assignments
A DHCP server is often on a different subnet from its clients. Since a router does not normally forward a local broadcast as a broadcast onto another network, a DHCP relay agent forwards the client’s request to a configured server and provides information about the client network.
Think about the exchange as separate network legs:
- On the client-facing segment, DHCPv4 commonly uses client UDP 68 and server UDP 67.
- Between a DHCPv4 relay and server, the forwarded request and reply use the DHCP service on UDP 67.
- For DHCPv6, servers and relays use UDP 547, while clients use UDP 546.
When a lease fails across subnets, checking only the client and server can miss the problem. Verify the relay’s client-facing interface, its configured server destination, the return path, and whether the server has a scope for the client’s subnet.
Troubleshoot by following the packets
Start by identifying whether the client is using DHCPv4 or DHCPv6 and whether a relay is involved. Then check the network path in order:
- Confirm the protocol and UDP ports. Look for 67/68 for DHCPv4 or 546/547 for DHCPv6.
- Check the client’s network. Confirm it is on the expected VLAN or subnet and that the relevant broadcast or IPv6 link-local multicast can reach the intended server or relay.
- Inspect relay configuration. Check the client-facing interface, server destination, and return path. Confirm the server has configuration matching the relayed client network.
- Review firewall policy on each segment. Host firewalls, router ACLs, cloud rules, and network boundaries may see different parts of the exchange. Check UDP and any required broadcast or multicast handling.
- Capture on both sides of a relay or firewall. A client-side capture can show whether the request left the client network; a server-side capture can show whether it arrived.
On Linux, capture DHCPv4 traffic on the relevant interface with tcpdump:
sudo tcpdump -ni eth0 'udp port 67 or udp port 68'
Replace eth0 with the interface you want to inspect. For DHCPv6, use its port pair:
sudo tcpdump -ni eth0 'udp port 546 or udp port 547'
If the request appears on the client segment but not near the server, investigate the relay or routed path. If it reaches the server but no response returns, check the server’s scope or subnet configuration, firewall policy, and return path. Windows users can use tools such as WinDump or Pktmon; this Windows packet-capture comparison explains the available options and examples.
Firewall rules depend on where they sit
There isn’t one universal “open DHCP ports” rule. A client firewall, server firewall, and router between subnets encounter different traffic. Allow only the DHCP flows required for the actual topology: UDP 67/68 for relevant DHCPv4 segments, or UDP 546/547 for relevant DHCPv6 links and relays.
Stateful firewalls may allow return traffic automatically, but that does not guarantee they handle broadcasts, IPv6 multicast, or relay traffic as needed. Check the policy at each interface or zone boundary. For broader context on how host, router, and cloud firewall rules differ, see this guide to opening ports across common firewall layers.
The key diagnostic habit is to trace the exchange rather than assume a port is simply open or closed. Identify the DHCP version, map the client/server/relay roles, and capture traffic where it crosses each boundary.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)