DHCP Ports 67 and 68 Explained: How DHCP Works

Key Takeaways 

• DHCP automates IP address assignment, eliminating manual configuration and reducing network errors. 

• DHCP uses UDP ports 67 (server) and 68 (client) for all communication. 

• Port 67 handles incoming client requests, while port 68 receives server responses. 

• The DORA process (Discover, Offer, Request, Acknowledge) defines how IP addresses are assigned. 

• DHCP relies on UDP instead of TCP because clients initially lack an IP address. 

• Relay agents (IP helpers) enable DHCP communication across different subnets and VLANs. 

Introduction 

Every device that connects to a network needs a unique IP address to communicate. Manually assigning addresses to hundreds or thousands of endpoints is impractical and error-prone. This is where the Dynamic Host Configuration Protocol (DHCP) comes in, automating IP address management across networks of every scale. 

 At the heart of DHCP’s operation are two dedicated UDP ports: port 67 and port 68. These two ports orchestrate every step of the IP assignment process, from a device’s first broadcast on the network to the final lease confirmation. Understanding how they work is essential for network administrators, IT operations teams, and anyone responsible for network reliability and security. 

 In this article, you will learn: 

• What DHCP ports are and why they matter 

• The distinct roles of DHCP port 67 (server) and port 68 (client) 

• How the four-step DORA process uses these ports 

• How relay agents extend DHCP across subnets 

• Common port-related issues and how to troubleshoot them 

• Security threats targeting DHCP ports and best practices to mitigate them 

 What Is DHCP? (A Quick Refresher) 

Dynamic Host Configuration Protocol (DHCP) is a network management protocol that automatically assigns IP configuration to devices on a network. When a device joins a network, instead of requiring a manually entered IP address, DHCP handles the entire process automatically. 

 DHCP automates the assignment of: 

• IP address — a unique identifier for the device on the network 

• Subnet mask — defines the network segment the device belongs to 

• Default gateway — the router the device uses to reach other networks 

• DNS server addresses — used to resolve domain names to IP addresses 

 This automation delivers significant benefits: it eliminates the risk of duplicate IP addresses, reduces administrative overhead, and scales seamlessly from home networks to enterprise environments with thousands of endpoints. 

DHCP operates on a client-server model. The DHCP server maintains a pool of available IP addresses and configuration parameters.  

What Is a DHCP Port? 

In networking, a port is a logical endpoint used to distinguish different types of traffic on the same device. Ports allow a single machine to run multiple services simultaneously — a web server on port 80, an email server on port 25, and a DHCP server on port 67, for example. 

DHCP uses two dedicated, standardized ports to separate its traffic from everything else on the network: 

• Port 67 — the server-side port, used by the DHCP server and relay agents 

• Port 68 — the client-side port, used by DHCP clients (the devices requesting IPs) 

Why UDP and Not TCP? 

DHCP uses UDP (User Datagram Protocol) rather than TCP (Transmission Control Protocol) for a fundamental reason: at the point a DHCP exchange begins, the client has no IP address yet. 

TCP requires a three-way handshake to establish a connection between two known IP addresses. A device that does not yet have an IP address cannot fulfill this requirement. UDP, being connectionless, allows the client to broadcast a request to the entire network without needing a pre-established connection. 

Key Insight: DHCP uses UDP because clients don’t have an IP address yet — TCP requires an established connection between known addresses, which isn’t possible at that stage. UDP’s connectionless, broadcast-capable nature is exactly what DHCP needs. 

DHCP Port 67 — The Server Port 

Port 67 is the well-known UDP port assigned to the DHCP server. It is the listening port — always open and waiting for incoming requests from clients and relay agents. 

What Happens on Port 67 

The DHCP server listens continuously on port 67 for two types of inbound messages: 

• DHCP Discover — the initial broadcast from a new device seeking an IP address 

• DHCP Request — the client’s formal acceptance of an offered IP address 

In addition to direct client communication, relay agents also communicate with the DHCP server via port 67 when forwarding requests from remote subnets (covered in detail in Section 7). 

Who Uses Port 67 

• The DHCP server — always listening for client requests 

• DHCP relay agents (IP helpers) — forwarding client requests from other subnets to the server on port 67

Common Scenarios Involving Port 67 

• A new laptop joins the corporate Wi-Fi and broadcasts a DHCP Discover to port 67 

• A relay agent on a remote VLAN receives a client broadcast and forwards it to the central DHCP server on port 67 

• A firewall rule inadvertently blocks port 67, causing all new devices to fail IP assignment 

DHCP Port 68 — The Client Port 

Port 68 is the UDP port used exclusively by DHCP clients. While port 67 is about receiving requests, port 68 is about receiving responses — specifically, the IP offers and confirmations sent back from the server. 

What Happens on Port 68 

The DHCP client listens on port 68 for two key server messages: 

• DHCP Offer — the server’s proposed IP address, subnet mask, lease duration, and other parameters 

• DHCP ACK (Acknowledgment) — the server’s final confirmation that the IP lease is active 

• DHCP NAK (Negative Acknowledgment) — the server’s rejection of a client’s request (e.g., the offered IP is no longer available) 

Why a Separate Port for the Client? 

Having separate ports for server (67) and client (68) ensures that DHCP traffic flows in an orderly, unambiguous way. Without distinct ports, a network device could not easily distinguish between a message intended for the DHCP server and one intended for the client. Separate ports also make firewall configuration, traffic filtering, and protocol analysis significantly simpler. 

Below is a side-by-side comparison of the two DHCP ports: 

Feature	Port 67 (Server)	Port 68 (Client)
Used by	DHCP Server, Relay Agents	DHCP Client (any device)
Listens for	Discover, Request messages	Offer, ACK, NAK messages
Protocol	UDP	UDP
IANA Assignment	Well-known port	Well-known port
Broadcast capable	Yes	Yes

How DHCP Works: The 4-Step DORA Process 

The complete IP assignment process in DHCP follows a four-step sequence known as DORA: Discover, Offer, Request, Acknowledge. Each step uses specific source and destination ports, ensuring messages are routed correctly between client and server. 

Here is the port usage at each stage: 

Step	Message	Source Port	Destination Port
1	DHCP Discover	68	67
2	DHCP Offer	67	68
3	DHCP Request	68	67
4	DHCP ACK / NAK	67	68

Step 1 — DHCP Discover (Client → Server) 

When a device connects to a network and has no IP address, it sends a DHCP Discover message as a broadcast. Since the client has no IP, it uses 0.0.0.0 as its source IP and 255.255.255.255 as the broadcast destination. 

Source port: 68 | Destination port: 67 

Every device on the subnet receives this broadcast, but only DHCP servers (listening on port 67) respond to it. 

Step 2 — DHCP Offer (Server → Client) 

Upon receiving the Discover message, the DHCP server checks its available address pool and responds with a DHCP Offer. This offer includes a proposed IP address, subnet mask, lease duration, default gateway, and DNS server details. 

Source port: 67 | Destination port: 68 

If multiple DHCP servers exist on the network, the client may receive multiple offers. The client typically accepts the first offer it receives. 

Step 3 — DHCP Request (Client → Server) 

The client broadcasts a DHCP Request to formally accept one of the offers. This broadcast serves two purposes: it tells the chosen server that its offer was accepted, and it informs any other DHCP servers that their offers were declined. 

Source port: 68 | Destination port: 67 

 The request is still a broadcast at this stage because the client does not yet have a confirmed IP address. 

Step 4 — DHCP ACK / NAK (Server → Client) 

The server sends a DHCP Acknowledgment (ACK) to finalize the lease, confirming that the client can use the assigned IP for the duration of the lease period. 

Source port: 67 | Destination port: 68 

In rare cases, the server may send a DHCP NAK (Negative Acknowledgment) instead. This occurs when the requested IP is no longer valid — for example, if the server’s address pool was reconfigured between the Offer and Request stages, or if the client’s lease request is inconsistent with the server’s current records. Upon receiving a NAK, the client restarts the DORA process. 

DHCP Relay Agents and Port Behavior Across Subnets 

DHCP Discover messages are layer 2 broadcasts. By design, broadcasts do not cross router boundaries; they are confined to their local subnet. This creates a challenge in enterprise environments where a single DHCP server must serve multiple subnets or VLANs. 

The Problem 

Without intervention, devices on VLAN 20 cannot reach the DHCP server on VLAN 10, because their broadcast Discover packets are dropped at the router. 

 The Solution: DHCP Relay Agents 

A DHCP relay agent (also known as an IP helper) is a service that runs on a router or layer 3 switch. It intercepts DHCP broadcasts on the local subnet, encapsulates them as unicast messages, and forwards them directly to the DHCP server’s IP address on port 67. 

The relay agent process: 

• Client broadcasts DHCP Discover on local subnet (source port 68, destination port 67) 

• Relay agent receives the broadcast and forwards it as unicast to the DHCP server on port 67, adding its own IP as the gateway address 

• DHCP server processes the request and sends the Offer back to the relay agent on port 67 

• Relay agent forwards the Offer to the original client on port 68 

 This relay mechanism means that a single DHCP server can serve all VLANs in an enterprise network. The IP helper address configured on each VLAN interface points to the DHCP server, ensuring that broadcasts from any segment are forwarded correctly. In these deployments, port 67 is especially critical — it must remain open and reachable between relay agents and the DHCP server. 

DHCP Lease Renewal and Port Usage 

An IP address assigned via DHCP is not permanent — it is leased for a defined period. As the lease approaches expiration, the client initiates a renewal process to retain its IP address. 

Renewal (Unicast) 

At the 50% mark of the lease duration (T1 timer), the client sends a DHCP Request directly to the DHCP server via unicast. Because the client already has an IP address, this is a targeted unicast message rather than a broadcast. 

Port usage: Source port 68, destination port 67 — same as the original DORA exchange. 

If the server approves the renewal, it responds with a DHCP ACK (source port 67, destination port 68) and the lease is extended. 

Rebinding (Broadcast) 

If the client does not receive a renewal response by the 87.5% mark (T2 timer) — perhaps because the original server is unavailable — it broadcasts a DHCP Request to any available DHCP server. Port behavior remains the same: source 68, destination 67. 

DHCP RELEASE and INFORM 

DHCP RELEASE: When a device disconnects intentionally (e.g., graceful shutdown), it sends a Release message to the server on port 67, informing it that the IP address can be returned to the pool. 

DHCP INFORM: A device that has a statically configured IP but needs other configuration details (DNS, gateway) can send a DHCP Inform message to the server on port 67. The server responds on port 68 with the requested configuration — without assigning an IP. 

DHCP Port Numbers: Why 67 and 68? 

The assignment of ports 67 and 68 to DHCP is not arbitrary. These port numbers were inherited from BOOTP (Bootstrap Protocol), the predecessor to DHCP, which was developed in the 1980s. BOOTP used port 67 for server communication and port 68 for client communication — conventions that DHCP adopted when it was standardized in RFC 2131 in 1997. 

These ports were officially assigned by IANA (Internet Assigned Numbers Authority) and are classified as well-known ports (in the range 0–1023), meaning they are reserved for standardized, widely-used protocols. Because of this standardization, every operating system, router, firewall, and network device recognizes ports 67 and 68 as DHCP ports by default — no configuration required. 

Common DHCP Port Issues and How to Troubleshoot Them 

DHCP port problems can cause widespread network disruption, as affected devices fail to obtain valid IP addresses. Here are the most common issues and their resolutions. 

Issue 1: Blocked DHCP Ports (67 and 68) 

Symptoms: Devices receive APIPA addresses (169.254.x.x) instead of valid IPs; no internet access. 

Cause: A firewall rule — on the router, host, or network appliance — is blocking UDP traffic on ports 67 or 68. 

Fix: Review firewall rules on the router and any host-based firewalls. Explicitly allow inbound and outbound UDP traffic on ports 67 and 68. On Windows Firewall, check for rules that block “DHCP Client” or UDP 68. On Linux, verify that iptables or nftables rules permit this traffic. 

Issue 2: Port 68 Conflict on the Client 

Symptoms: DHCP responses are not received by the client; repeated lease failures despite the server functioning correctly. 

Cause: Another application on the client machine has bound to port 68, preventing the DHCP client service from receiving server responses. 

Fix: Use netstat to identify the conflicting process. On Windows: netstat -an | findstr “:68”. On Linux: ss -ulnp | grep :68. Terminate or reconfigure the conflicting application, then restart the DHCP client service. 

Issue 3: Relay Agent Misconfiguration 

Symptoms: Devices in remote VLANs or subnets cannot obtain IP addresses, while devices on the local subnet function normally. 

Cause: The relay agent’s IP helper address is incorrect, points to the wrong server, or port 67 is blocked between the relay agent and the DHCP server. 

Fix: Verify the IP helper address configured on the remote VLAN’s layer 3 interface. Confirm routing exists between the relay agent and the DHCP server. Check that port 67 is not blocked by ACLs between the two. Test connectivity with a simple ping from the relay agent to the DHCP server. 

Issue 4: Rogue DHCP Server on the Network 

Symptoms: Devices receive unexpected IP addresses, wrong default gateways, or incorrect DNS servers. Users may experience connectivity issues or suspicious traffic redirection. 

Cause: An unauthorized DHCP server (a misconfigured device, a rogue access point, or a malicious actor) is responding to port 67 requests faster than the legitimate server. 

Fix: Enable DHCP snooping on managed switches — this feature restricts which switch ports are permitted to send DHCP Offer and ACK messages. Identify the rogue server using network monitoring tools or by inspecting DHCP logs. Physically or logically isolate the unauthorized device. 

Issue 5: DHCP Server Not Responding 

Symptoms: All clients across the network fail to obtain IP addresses simultaneously. 

Cause: The DHCP service has stopped, crashed, or is no longer listening on port 67. 

Fix: Verify the DHCP service is running on the server. Check whether port 67 is actively listening: on Linux, run ss -ulnp | grep :67 or netstat -an | grep 67. Restart the DHCP service if necessary, then review server logs for the root cause (pool exhaustion, configuration error, resource issue). 

How to Check If DHCP Ports Are Open 

Windows 

Open Command Prompt and run: 
netstat -an | findstr "67 68"


Look for entries showing UDP 0.0.0.0:67 (server listening) or UDP 0.0.0.0:68 (client listening). 

Linux 

ss -u -l -n

netstat -ulnp | grep -E '67|68'


Using Wireshark 

Launch Wireshark, select the relevant network interface, and apply the display filter: 

udp.port == 67 or udp.port == 68

This filter captures all DHCP traffic and allows you to inspect each DORA message, verify port usage, and identify any unexpected sources of DHCP traffic (such as rogue servers). 

Quick Firewall Audit Checklist 

• Allow UDP inbound on port 67 (DHCP server/relay agent) 
• Allow UDP outbound on port 67 (DHCP client sending requests) 
• Allow UDP inbound on port 68 (DHCP client receiving responses) 
• Allow UDP outbound on port 68 (DHCP server sending responses) 
• Verify no ACLs on inter-VLAN routing interfaces block 67/68

Security Threats Targeting DHCP Ports 

Because DHCP operates with minimal authentication and relies on broadcast communication, it presents an attractive attack surface. The following threats specifically exploit DHCP port behavior. 

DHCP Starvation Attack 

An attacker floods the network with DHCP Discover messages from spoofed MAC addresses, sending a continuous stream to port 67. Each fake request consumes an IP from the server’s address pool. Once the pool is exhausted, legitimate devices cannot obtain IP addresses, causing a network-wide denial of service. 

Rogue DHCP Server Attack 

An unauthorized DHCP server is placed on the network, whether through a misconfigured device or malicious intent. It listens on port 67 and races to respond to client discover messages before the legitimate server. By responding with a crafted DHCP Offer, it can supply clients with a fake default gateway or DNS server, enabling man-in-the-middle attacks and traffic interception. 

DHCP Spoofing 

A variation of the rogue server attack, DHCP spoofing involves crafting malicious DHCP Offer or ACK messages sent to port 68 on targeted clients. These spoofed responses direct clients to attacker-controlled DNS servers or gateways, enabling DNS hijacking, credential theft, and traffic surveillance — all without the user’s knowledge. 

The impact of these attacks ranges from network outages (starvation) to full man-in-the-middle scenarios where all traffic passing through the compromised gateway can be intercepted or manipulated. 

Best Practices to Secure DHCP Ports 

Enable DHCP Snooping: On all managed switches, enable DHCP snooping. This feature designates trusted and untrusted ports — only trusted ports (those connected to DHCP servers or relay agents) are permitted to send DHCP Offer and ACK messages. Untrusted ports (end-user ports) are restricted to sending only Discover and Request messages. 

Apply Port Filtering: Restrict UDP traffic on ports 67 and 68 to trusted devices and subnets only. Configure access control lists (ACLs) to prevent unauthorized devices from sending DHCP server-side messages. 

Use Firewall Rules for Relay Agents: If your network uses DHCP relay agents, configure firewall rules to allow port 67 traffic only from known relay agent IP addresses to the DHCP server. Block all other sources. 

Regular Security Audits: Periodically audit which devices are listening on ports 67 and 68. Any unexpected listener on port 67 is a potential rogue DHCP server and should be investigated immediately. 

Implement IPAM: An IP Address Management (IPAM) solution provides centralized visibility into all DHCP activity — active leases, available pools, lease history, and server health — making it significantly easier to detect anomalies. 

Continuous Log Monitoring: Monitor DHCP server logs for signs of starvation (rapidly depleting lease pools), unauthorized ACK messages, and unusual lease patterns. Automated alerting on these events allows teams to respond before users are affected. 

How Motadata Helps Monitor and Secure DHCP Activity 

Managing DHCP port security and health across large, multi-VLAN networks requires more than manual checks and reactive troubleshooting. Motadata’s network monitoring and IT operations platform provides the visibility and automation needed to stay ahead of DHCP-related issues. 

 With Motadata, your team can: 

• Monitor DHCP port traffic in real time — track activity on ports 67 and 68 across all network segments, with instant visibility into request volumes, lease success rates, and response times. 

• Detect rogue DHCP servers — receive automated alerts when an unauthorized device begins sending DHCP Offer messages, enabling rapid identification and isolation before clients are affected. 

• Identify unusual lease patterns — spot DHCP starvation attempts, lease exhaustion events, and abnormal Discover floods before they escalate into outages. 

• Correlate DHCP events with broader network health — connect DHCP failures to switch status, interface errors, or VLAN misconfigurations for faster root cause analysis. 

• Alert teams on port 67 and 68 anomalies — configurable thresholds and notification channels ensure the right people are informed before end users are impacted. 

 The business value is direct: reduced mean time to resolution (MTTR) for network incidents, improved security posture through proactive threat detection, and simplified IP address management across complex, distributed infrastructure. 

FAQs