Fix "DHCP lease acquisition failed. No IP address could be obtained." Error

What's happening

Your machine sent a DHCP discover broadcast and got nothing useful back — so it fell back to a self-assigned 169.254.x.x (APIPA) address, or no address at all. The full error looks like:

DHCP lease acquisition failed. No IP address could be obtained.

Without a valid IP, nothing on the LAN can route traffic to your machine. Internet access is dead. The root cause sits somewhere on a spectrum: your adapter, the DHCP client service, or a local firewall — or the DHCP server itself is exhausted, misconfigured, or unreachable on the network side.

Debug process

Step 1 — Confirm you have no valid IP

Before touching any settings, check what address your interface actually has.

Windows:

ipconfig /all

A line reading Autoconfiguration IPv4 Address . . : 169.254.x.x confirms DHCP failed — Windows self-assigned an APIPA address as a fallback.

Linux:

ip addr show
# or older systems:
ifconfig -a

No inet line on your interface (e.g., eth0, ens33) means no lease was obtained.

macOS:

ipconfig getifaddr en0

No output, or a 169.254.x.x address, means DHCP failed.

Step 2 — Check if the DHCP server is reachable

On Linux, trigger a manual DHCP request with verbose output:

# Replace eth0 with your interface name
sudo dhclient -v eth0

Watch the output carefully. DHCPDISCOVER sent but no DHCPOFFER received means the problem is on the network side — the DHCP server is down, there's no server on this VLAN, or a firewall is blocking UDP ports 67/68.

Getting a DHCPOFFER followed by DHCPNAK is a different story: the server rejected your request. That usually points to IP pool exhaustion or an address conflict.

Step 3 — Check event logs / system journal

Windows Event Viewer:

# Run in PowerShell
Get-WinEvent -LogName System | Where-Object { $_.ProviderName -eq 'Dhcp-Client' } | Select-Object -First 20 | Format-List TimeCreated, Message

Linux systemd journal:

journalctl -u NetworkManager --since '10 minutes ago'
# or for dhclient directly:
journalctl -u dhclient -n 50

Solutions

Fix 1 — Release and renew the lease (try this first)

Windows:

ipconfig /release
ipconfig /renew

If ipconfig /renew hangs or throws an error, skip to Fix 2.

Linux:

# Kill any existing dhclient, then re-request
sudo dhclient -r eth0
sudo dhclient eth0

macOS:

sudo ipconfig set en0 DHCP

Or go to System Settings → Network → [Interface] → Renew DHCP Lease.

Fix 2 — Restart the DHCP client service

The DHCP daemon can get stuck in a bad state, especially after sleep/wake cycles or a network hiccup. Restarting it forces a clean re-handshake from scratch.

Windows:

# In PowerShell (Run as Administrator)
Restart-Service -Name Dhcp
ipconfig /renew

Linux (NetworkManager):

sudo systemctl restart NetworkManager
# Check status after
systemctl status NetworkManager

Linux (systemd-networkd):

sudo systemctl restart systemd-networkd

Fix 3 — Reset network adapter / flush state

A corrupted lease cache or stale adapter state will cause DHCP to fail on every attempt until you clear it. On Windows, the full reset sequence is:

# Run as Administrator
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Reboot after running these. The winsock reset and int ip reset commands don't fully take effect until the next boot.

Linux — remove stale lease file:

# Location varies by distro
sudo rm /var/lib/dhclient/dhclient.leases
sudo rm /var/lib/NetworkManager/*.lease
sudo systemctl restart NetworkManager

Fix 4 — Disable and re-enable the network adapter

Windows (PowerShell):

$adapter = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Select-Object -First 1
Disable-NetAdapter -Name $adapter.Name -Confirm:$false
Start-Sleep -Seconds 3
Enable-NetAdapter -Name $adapter.Name

Linux:

sudo ip link set eth0 down
sleep 3
sudo ip link set eth0 up
sudo dhclient eth0

Fix 5 — DHCP pool exhausted (server-side fix)

Multiple devices failing to get an IP at the same time? The pool is probably exhausted. A typical home router ships with a range like 192.168.1.100–192.168.1.150 — that's only 51 addresses. A medium-sized office with 60+ devices will blow straight past that limit.

Log into your router's admin panel and do one or more of:

• Expand the DHCP pool range (e.g., 192.168.1.100–200 instead of 100–150)
• Reduce the lease time from 24 hours down to 4–8 hours so stale leases expire faster
• Clear all active leases and let devices re-request fresh ones

On Linux servers running dnsmasq or isc-dhcp-server, check how many leases are currently active:

# Check current leases
cat /var/lib/misc/dnsmasq.leases
# or
cat /var/lib/dhcpd/dhcpd.leases | grep -c 'binding state active'

Fix 6 — Check firewall blocking UDP 67/68

DHCP traffic runs over UDP: port 67 for the server, port 68 for the client. A strict firewall rule can silently drop these packets — no error message, just silence from the server.

# Linux — check if iptables is dropping DHCP traffic
sudo iptables -L INPUT -n -v | grep -E '67|68'

# Temporarily allow (test only)
sudo iptables -I INPUT -p udp --dport 68 -j ACCEPT
sudo iptables -I OUTPUT -p udp --dport 67 -j ACCEPT

Verify the fix worked

# Windows
ipconfig /all
# Look for: IPv4 Address = 192.168.x.x (not 169.254.x.x)
# Look for: DHCP Enabled = Yes
# Look for: Lease Obtained = [recent timestamp]

# Linux
ip addr show eth0
# Look for: inet 192.168.x.x/24

# Ping gateway to confirm routing works
ping -c 4 192.168.1.1   # Linux/macOS
ping 192.168.1.1         # Windows

Tips

Dealing with a subnet misconfiguration or an IP range that doesn't look right? The Subnet Calculator at ToolCraft lets you verify CIDR ranges and check whether an IP actually falls within the expected subnet. Runs entirely in the browser with nothing uploaded.

Lessons learned

• 169.254.x.x is your first clue on Windows — that address means DHCP failed and Windows self-assigned an APIPA fallback.
• Use dhclient -v on Linux — verbose output shows the full DISCOVER → OFFER → REQUEST → ACK handshake, so you can see exactly which step breaks down.
• Lease pool exhaustion is common in offices and labs — dropping lease time to 4–8 hours (instead of 24) helps reclaim addresses from devices that left without releasing their lease.
• VMs and containers need special attention — the virtual network adapter or bridge can enter a bad state after live migrations or snapshot restores. A full adapter reset almost always clears it.