The authoritative DHCP option fails because the virtual network interface is likely bridged to a physical router that intercepts and overrides the server’s responses. To fix this, you must isolate the VMs in a host-only or internal network segment where no external gateway exists, ensuring the DHCP server retains full control over address allocation without interference from upstream routers.
Understanding the Network Conflict
When two virtual machines operate on a single physical host, the networking configuration determines how they communicate with each other and the outside world. In many default setups, virtual machine managers like VirtualBox, VMware, or Hyper-V create a NAT (Network Address Translation) network or a Bridged Adapter by default. This creates a significant problem for DHCP testing or deployment scenarios.
If your DHCP server VM is connected via a Bridged Adapter, it appears as another device on your local area network (LAN). When the client VM broadcasts a DHCPDISCOVER packet, both your virtual DHCP server and your physical router’s DHCP service hear it. Most modern routers are configured to respond quickly to these requests. If the router responds before your virtual server can send its DHCPOFFER, the client accepts the router’s offer. Consequently, the "authoritative" flag on your virtual server becomes irrelevant because the client never even sees the request to evaluate authority; it simply takes the first valid offer it receives.
This behavior is not a bug in the DHCP protocol but a consequence of shared broadcast domains. The authoritative option tells a DHCP server to decline an IP if it conflicts with existing leases or if the client requests an IP it doesn't have, but it does not prevent other active DHCP servers on the same subnet from responding. Therefore, the core issue is environmental rather than configurational within the DHCP daemon itself.
Why External Interference Occurs
In a typical home or office environment, the router acts as the primary DHCP provider. It listens on UDP port 67. When a new device joins the network, it sends a broadcast. If your virtual network setup allows this broadcast to reach the physical router, the router will reply. Even if you configure your virtual DHCP server with
authoritative; in ISC DHCP or equivalent settings in Windows Server, it cannot suppress the router's response. The client machine operates on a simple principle: accept the first valid offer. Since the router is often physically closer in terms of network hops or has lower latency in processing, its response wins the race.
To resolve this, you must eliminate the path between the virtual machines and the physical router. This requires changing the virtual network topology. You need a network segment that is invisible to the physical LAN. This ensures that only the virtual DHCP server can hear the broadcast requests from the virtual client.
Solving the Issue via Host-Only Networking
The most reliable solution is to use a Host-Only or Internal network mode provided by your hypervisor. This creates a private network adapter that exists only within the host machine’s memory. Devices on this network cannot see the physical router, and the physical router cannot see them.
Here is how to implement this in common virtualization platforms:
- VirtualBox: Go to File > Preferences > Network. Create a new Host-Only Network. Then, in the VM settings, change the network adapter type from "Bridged Adapter" to "Host-Only Adapter." Ensure both the DHCP server VM and the client VM are attached to the same Host-Only network name.
- VMware Workstation: Navigate to Edit > Virtual Network Editor. Select the network interface used by your VMs (often vmnet1). Check the box for "Host-Only" mode. Remove any checkmarks related to DHCP service if you want to manage it manually, or ensure the VMware DHCP service is disabled if you are running your own DHCP server in the guest OS. Connect both VMs to this specific vmnet.
- Hyper-V: Create a New Virtual Switch. Choose "Private" switch type. Do not select "External" or "Internal" if you want complete isolation from the host's physical NIC traffic, though "Internal" works if the host itself does not act as a DHCP relay. Assign both VMs to this Private switch.
Once the network mode is changed, restart the network services in both virtual machines. The client VM should now send its DHCPDISCOVER broadcast into the void of the isolated network. Only your virtual DHCP server will hear it. It will then send a DHCPOFFER. The client will receive this offer and proceed with the DHCPREQUEST/DHCPACK handshake. Because there is no router to interfere, the authoritative setting functions correctly, allowing you to test lease renewals, conflict detection, and static binding assignments accurately.
Verifying the Configuration
After switching to the isolated network, verify the connection using command-line tools. On the client VM, run
ipconfig /release followed by
ipconfig /renew (on Windows) or
dhclient -r and
dhclient (on Linux). Check the lease details to ensure the IP address matches the range defined in your virtual DHCP server. If you still see an IP from your physical router's subnet (e.g., 192.168.1.x instead of 10.0.50.x), the network adapter is still bridged. Double-check the hypervisor settings to ensure no secondary adapters are active in Bridged mode.
For more advanced networking setups involving multiple subnets or complex routing requirements between virtual machines and the host, you might need to explore exposing local servers securely. Understanding how to preserve real client IPs while managing network boundaries is crucial for troubleshooting deeper connectivity issues. See our guide on
Expose Local Server on VPS Preserving Real Client IPs (OS Level) for insights into network layer interactions.
Common Pitfalls and Troubleshooting
Even after isolating the network, users may encounter issues due to cached configurations or firewall rules.
Firewall Blocking DHCP Traffic
Linux firewalls such as UFW or iptables, and Windows Defender Firewall, often block incoming UDP traffic on ports 67 and 68 by default. If the client sends a request but the server does not respond, check the server's firewall logs. Allow inbound traffic for UDP ports 67 and 68. In Ubuntu, you can use
sudo ufw allow 67:68/udp. In Windows, create an inbound rule for "File and Printer Sharing (Echo Request)" or specifically for DHCP Server ports.
Static IP Misconfiguration
Ensure the virtual DHCP server itself has a static IP address assigned to its network interface. If the server tries to obtain an IP via DHCP from itself or falls back to APIPA (Automatic Private IP Addressing), it may not listen correctly on the expected interface. Manually assign a static IP in the 10.0.50.x range (or whatever subnet you chose) and set the netmask appropriately.
Lease Database Corruption
If the authoritative option seems to fail during lease renewal, check the DHCP lease database file (usually
/var/lib/dhcp/dhcpd.leases on Linux). A corrupted lease file can cause the server to behave unpredictably. Back up the file and restart the DHCP service to force a regeneration of the state.
Frequently Asked Questions
Can I use Bridged mode if I disable the router's DHCP?
Yes, disabling the DHCP service on your physical router is a viable alternative to using Host-Only networking. However, this affects all devices on your LAN, not just the VMs. If you only want to isolate the VMs temporarily, Host-Only mode is safer and less disruptive to your main network.
Why does my client get an IP from 169.254.x.x?
This indicates an APIPA (Automatic Private IP Addressing) address, meaning the client could not reach any DHCP server. This usually happens when the virtual network is misconfigured, the DHCP server service is stopped, or a firewall is blocking the UDP 67/68 ports. Verify the server is running and listening on the correct interface.
Does the authoritative option work in Windows Server DHCP?
Yes, Windows Server DHCP includes an "Authoritative" checkbox in the server properties under the Advanced tab. When checked, the server declines offers for unconfigured scopes or conflicting leases. Like Linux, it requires an isolated network to function effectively against other DHCP sources.
How do I clear the DHCP cache on a Windows client?
Open Command Prompt as Administrator and run
ipconfig /release followed by
ipconfig /flushdns and
ipconfig /renew. This forces the client to discard old lease information and request a fresh address from the available server.
What is the difference between Internal and Private switches in Hyper-V?
An Internal switch allows communication between VMs and the host machine but not with the external physical network. A Private switch restricts communication strictly between VMs, excluding the host. For DHCP testing, either works, but Private provides stricter isolation if you do not need the host to access the VMs directly.