Add a Windows VM and Configure DNS/DHCP

Deploy DNS and DHCP on Ubuntu Server to manage a Windows 11 lab network.

Introduction

30 Second Summary

Every time you type a website name instead of a raw IP address, a DNS server is doing the translation for you behind the scenes. Every time a new device joins your home Wi-Fi and gets an IP address without you configuring anything, a DHCP server handled it.

In this project, you will turn your existing Ubuntu Server into the infrastructure backbone of a private lab network. You'll deploy DNS and DHCP services that let multiple machines find each other by name and receive their network settings automatically.

What You'll Build

When you finish, you can type ping ubuntu.lab from your Windows VM and watch it resolve instantly to the correct IP address. Any new VM you add to your network in the future will automatically receive an IP and DNS configuration with zero manual setup.

By the end of this project, you'll have:

  • A Windows 11 VM connected to your private lab network, communicating with your Ubuntu Server by friendly hostnames instead of IP addresses.
  • A DNS server powered by dnsmasq that resolves custom hostnames (ubuntu.lab, windows.lab, host.lab) to IP addresses across all machines in your network.
  • A DHCP server that automatically assigns IP addresses, DNS settings, and domain information to any client that joins the network.
  • Secret Mission: Configure reverse DNS lookups so you can resolve IP addresses back to hostnames, the same technique enterprise logging systems use to identify machines.

Are there any prerequisites?

This project builds on Project 1 in the series. You need your Ubuntu Server VM already running with host-only networking on the 192.168.67.0/24 subnet and SSH access confirmed.

You also need the Windows 11 Enterprise Evaluation ISO downloaded before starting. Grab it from the Microsoft Evaluation Center (it's a free 90-day trial, no product key required).

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters for your networking skills.

Create and Install the Windows 11 VM

Your lab currently has a single Ubuntu Server VM. A network with one machine cannot demonstrate DNS or DHCP because there is no client to serve.

In this step, you will create a Windows 11 VM from scratch in VirtualBox. This second machine acts as the client that will request DNS lookups and DHCP leases from your Ubuntu server in later steps.

In this step, get ready to:
  • Create a Windows 11 VM in VirtualBox with the correct hardware settings.
  • Install Windows 11 Enterprise from the evaluation ISO.
  • Install VirtualBox Guest Additions for better display and integration.
Create the VM in VirtualBox with Windows 11 settings

VirtualBox needs a VM shell with the right hardware profile before you can install an operating system. Windows 11 has strict requirements including EFI boot firmware and a TPM 2.0 security chip.

  • Open VirtualBox Manager.
  • Click New in the toolbar to start the Create Virtual Machine wizard.

What does this wizard do?

The Create Virtual Machine wizard walks you through four pages: naming the VM and selecting the OS, configuring hardware (RAM, CPU), and setting up a virtual hard disk. VirtualBox uses your OS selection to automatically enable features that OS requires.

On the first wizard page (Specify Name and Operating System):

  • In the Name field, type Windows11.
  • In the ISO Image field, click the dropdown and select the Windows 11 Enterprise Evaluation ISO you downloaded earlier.
  • VirtualBox will auto-detect the OS and fill in the Type and Version fields. Confirm they show Microsoft Windows and Windows 11 (64-bit).
  • Check the Skip Unattended Installation checkbox. You will install Windows manually so you can control each step.
  • Click Next.

On the hardware page (Set Up VM Hardware):

  • Set Base Memory to 4096 MB.
  • Set Processors to 2.
  • Check the Enable EFI (Special OSes only) checkbox. Windows 11 requires EFI firmware to boot.
  • Click Next.

On the virtual hard disk page:

  • Select Create a Virtual Hard Disk Now.
  • Set the Disk Size to 64 GB. The disk is dynamically allocated, so it only uses space as Windows fills it.
  • Click Next, then click Finish on the summary page.

The new VM now appears in VirtualBox Manager's machine list on the left.

Now verify the TPM 2.0 setting. VirtualBox should have enabled it automatically when it detected the Windows 11 ISO, but let's confirm:

  • Select the Windows11 VM in the machine list.
  • Click Settings in the toolbar.
  • Click System in the left panel.
  • On the Motherboard tab, find the TPM dropdown. Confirm it is set to v2.0. If not, change it to v2.0.
  • Confirm Enable EFI (Special OSes only) is checked.
  • Click OK to close Settings.

Why does Windows 11 need EFI and TPM 2.0?

Windows 11 requires UEFI firmware (EFI) and a Trusted Platform Module (TPM) 2.0 chip for installation. VirtualBox 7.x can emulate both of these in software, so the VM passes Windows 11's hardware checks without needing physical TPM hardware on your host.

Don't see the VM in the machine list?

Make sure you clicked Finish on the wizard's summary page. If you closed the wizard early, click New and start again.

If the TPM dropdown only shows None, ensure your VirtualBox version is 7.0 or later. Help me troubleshoot my VirtualBox TPM settings for Windows 11.

Install Windows 11 from the evaluation ISO

The VM shell is ready. Now you will boot it and run through the Windows 11 installer.

  • Select the Windows11 VM in VirtualBox Manager.
  • Click Start in the toolbar to boot the VM.

What happens when the VM boots?

Because you attached the Windows 11 ISO during VM creation, VirtualBox mounts it as a virtual DVD drive. The VM boots from this ISO into the Windows installer. You may briefly see a black screen with the VirtualBox logo or a "Press any key to boot from CD/DVD" prompt.

If you see the prompt, press any key quickly. If you miss it, power off the VM (Machine > Reset) and try again.

Once the Windows Setup screen appears:

  • Leave the language, time, and keyboard settings at their defaults.
  • Click Next.
  • Click Install now.
  • When prompted for a product key, click I don't have a product key. The Enterprise evaluation runs for 90 days without one.
  • Select Windows 11 Enterprise from the edition list.
  • Click Next.
  • Accept the license terms and click Next.
  • Select Custom: Install Windows only (advanced).
  • Select the 64 GB unallocated drive and click Next. Windows will begin installing.

The installation takes several minutes. The VM will reboot automatically during this process.

After the reboot, the Out-of-Box Experience (OOBE) wizard starts. Complete it with a local account:

  • Select your region and keyboard layout.
  • When asked to connect to a network, look for a I don't have internet option or Skip link at the bottom. Click it.
  • Click Continue with limited setup.
  • Enter a username (e.g. LabUser) and set a password.
  • Set your security questions and click through the remaining privacy settings.

Windows 11 will finish setup and bring you to the desktop.

No option to skip network connection?

Windows 11 Enterprise edition may require you to press Shift+F10 to open a Command Prompt, then type oobe\bypassnro and press Enter. The VM will reboot and the OOBE will now show the skip option.

Help me bypass the network requirement during Windows 11 OOBE setup.

Install Guest Additions and shut down the VM

VirtualBox Guest Additions are drivers that improve the VM's display resolution, mouse integration, and performance. Without them, the VM runs at a low fixed resolution.

  • With the Windows 11 VM running and at the desktop, click the Devices menu in the VirtualBox VM window's menu bar.
  • Click Insert Guest Additions CD image. This mounts a virtual CD inside the VM.

What is the Guest Additions CD image?

VirtualBox ships with an ISO file called VBoxGuestAdditions.iso containing drivers for Windows, Linux, and other guest operating systems. The Devices > Insert Guest Additions CD image menu item mounts this ISO as a virtual disc drive inside your VM.

  • Inside the Windows 11 VM, open File Explorer.
  • Click This PC in the left sidebar.
  • Double-click the VirtualBox Guest Additions disc drive under Devices and drives.
  • Double-click VBoxWindowsAdditions to launch the installer.
  • Click Yes on the User Account Control prompt.
  • Click Next through the installer pages.
  • Click Install.
  • When prompted, select Reboot now and click Finish.

The VM reboots. After logging back in, you should notice the display resolution adjusts when you resize the VM window.

Before you do anything else, what do you expect to see if you resize the VirtualBox window now that Guest Additions are installed?

Try resizing the VM window by dragging a corner. The Windows desktop resolution changes dynamically to match the window size. This confirms Guest Additions are working.

Display doesn't resize with the window?

Make sure you rebooted the VM after the Guest Additions installer finished. If you skipped the reboot, shut down Windows (Start > Power > Shut down) and start the VM again.

If it still doesn't resize, try View > Auto-resize Guest Display in the VM window's menu bar and ensure it is checked.

Help me fix Guest Additions display resizing in my Windows 11 VirtualBox VM.

Now shut down the Windows 11 VM so you can configure networking in the next step:

  • Inside Windows, click Start > Power > Shut down.
  • Wait for the VM window to close. The VM status in VirtualBox Manager should show Powered Off.

Your Windows 11 VM is ready. Next up, you will connect it to the same private network as your Ubuntu Server so the two machines can talk to each other.

Connect Windows to the Lab Network

In Step 1 you built the Windows 11 VM from scratch. Right now it is an isolated machine with no path to your Ubuntu Server. Both VMs exist, but they cannot see each other.

In this step, you will wire both VMs onto the same private subnet and assign fixed IP addresses so they can always find each other. By the end, a ping from either machine reaches the other instantly.

In this step, get ready to:
  • Add a host-only network adapter to the Windows VM.
  • Configure static IP addresses on both Ubuntu and Windows.
  • Test bidirectional connectivity with ping.
Add network adapters to the Windows VM

VirtualBox lets each VM have multiple network adapters, each in a different mode. You will give your Windows VM two adapters: a NAT adapter for internet access, and a host-only adapter for private communication with Ubuntu.

  • In VirtualBox Manager, make sure the Windows 11 VM is powered off (it should already be shut down from Step 1).
  • Select the Windows 11 VM in the left pane, then click Settings
  • Click Network in the left sidebar.

You will see four adapter tabs across the top. Configure them as follows:

  • Click the Adapter 1 tab.
  • Confirm Enable Network Adapter is checked.
  • Set the Attached to dropdown to NAT.
  • Click the Adapter 2 tab.
  • Check Enable Network Adapter.
  • Set Attached to to Host-only Adapter.
  • In the Name dropdown, select VirtualBox Host-Only Ethernet Adapter #3.
  • Click OK to save the settings.

Why two adapters?

NAT gives Windows internet access through your host's connection. The host-only adapter creates a private network that only your VMs and host can reach. This mirrors how enterprise servers have a management interface (private) and a production interface (public).

  • Start the Windows 11 VM by selecting it and clicking Start.
  • Log in with your local account.

Windows should boot normally. You now have two network adapters visible to the operating system.

VM won't start?

Make sure the VM was fully shut down (not saved state) before changing network settings. If VirtualBox shows a warning about the adapter name, confirm you selected the exact name VirtualBox Host-Only Ethernet Adapter #3 from the dropdown.

Help me troubleshoot my VirtualBox adapter settings

Configure a static IP on Ubuntu's host-only interface

Your Ubuntu Server already has a host-only adapter from Project 1, but it does not yet have a predictable static IP configured via netplan. You need to assign 192.168.67.10 so that every machine on the lab network always knows where to find it.

  • Start your Ubuntu Server VM from VirtualBox Manager.
  • On your Windows host machine, open Windows Terminal (or PowerShell) and SSH into Ubuntu by running:
ssh your-username@192.168.67.1

What if my SSH IP is different?

If you used a different IP to SSH in Project 1, use that same address. The important thing is to get a terminal session on Ubuntu. You can also log in directly through the VirtualBox console window.

  • Once logged in, check what network interfaces Ubuntu has by running:
ip addr show enp0s8

You should see the enp0s8 interface listed. It may show an IP from VirtualBox's built-in DHCP, or it may show no IP at all. Either way, you are about to give it a permanent address.

  • Open the netplan configuration file for editing by running:
sudo nano /etc/netplan/00-installer-config.yaml
  • Replace the entire contents of the file with the following configuration:
network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses:
        - 192.168.67.10/24

What does this configuration do?

enp0s3 is the NAT adapter. It uses DHCP to get an IP from VirtualBox automatically, giving Ubuntu internet access.

enp0s8 is the host-only adapter. You assign it the static IP 192.168.67.10/24 with no default route. The /24 means the subnet mask is 255.255.255.0. No gateway is listed because this private network has no internet exit.

  • Save the file by pressing Ctrl+O, then Enter, then exit nano with Ctrl+X.
  • Apply the new network configuration by running:
sudo netplan apply
  • Verify the static IP is active by running:
ip addr show enp0s8

You should see inet 192.168.67.10/24 in the output. This confirms Ubuntu is now reachable at that address on the host-only network.

Don't see the IP on enp0s8?

Check for YAML indentation errors. Netplan requires spaces (not tabs) and consistent indentation. Run sudo netplan apply again and read any error messages carefully. The most common issue is a missing space after the colon in addresses:.

Help me fix my netplan configuration

Configure a static IP on Windows and test connectivity

Now you need to assign a fixed IP to the Windows host-only adapter so it is always reachable at 192.168.67.50. You will use the classic Network Connections interface.

  • Inside the Windows 11 VM, press Windows key + R to open the Run dialog.
  • Type ncpa.cpl and press Enter.

The Network Connections window opens showing your adapters. You will see two Ethernet adapters. You need to identify which one is the host-only adapter.

  • Open Command Prompt by pressing Windows key, typing cmd, and pressing Enter.
  • Run this command to see all adapter details:
ipconfig /all
  • Look for the adapter with an IP in the 10.0.2.x range. That is the NAT adapter (Adapter 1).
  • The other Ethernet adapter is your host-only adapter (Adapter 2). Note its name. It is typically called something like Ethernet 2.

Now configure the host-only adapter with a static IP:

  • Switch back to the Network Connections window you opened earlier.
  • Right-click the host-only adapter (the one that is NOT on 10.0.2.x) and select Properties.
  • Select Internet Protocol Version 4 (TCP/IPv4) from the list.
  • Click Properties.
  • Select Use the following IP address.
  • Enter the following values:
  • IP address: 192.168.67.50
  • Subnet mask: 255.255.255.0
  • Default gateway: leave blank (this network has no internet gateway).
  • DNS servers: leave blank for now (you will configure DNS in Step 3).
  • Click OK to close the IPv4 properties.
  • Click OK again to close the adapter properties.

Why no gateway or DNS?

A host-only network is isolated by design. There is no router to serve as a gateway. Internet traffic goes through the NAT adapter (Adapter 1) which has its own gateway. DNS will be handled by your Ubuntu DNS server once you set it up in Step 3.

Now for the moment of truth. Before you run the next command, think about what you expect to happen. Both machines are on the same 192.168.67.0/24 subnet now. Do you think they can reach each other?

  • In the Windows Command Prompt, test connectivity to Ubuntu by running:
ping 192.168.67.10

You should see replies from 192.168.67.10 with response times. This proves Windows can reach Ubuntu across the host-only network.

  • Press Ctrl+C to stop the ping.
  • Now test the reverse direction. In your Ubuntu SSH session, ping Windows by running:
ping -c 4 192.168.67.50

You should see 4 replies from 192.168.67.50. Bidirectional connectivity is confirmed.

  • Finally, test that both VMs can reach the host machine by pinging 192.168.67.1 from either VM.
ping -c 4 192.168.67.1

Replies from 192.168.67.1 confirm your host is reachable too. All three machines (host, Ubuntu, Windows) can communicate on the private subnet.

Ping to Ubuntu times out from Windows?

The most common cause is Windows Firewall blocking ICMP on the host-only adapter. Alternatively, double-check that both adapters are on the same host-only network name (VirtualBox Host-Only Ethernet Adapter #3). If Ubuntu's adapter shows a different network, the VMs cannot see each other.

Also verify that you saved the netplan file correctly on Ubuntu. Run ip addr show enp0s8 on Ubuntu and confirm 192.168.67.10/24 appears.

Help me debug why ping between my VMs is not working

Your two-machine lab network is live. Both VMs talk to each other by IP. Next up, you will turn Ubuntu into a DNS server so you can reach machines by name instead of memorising numbers.

Set Up DNS with dnsmasq

Your two VMs can talk to each other by IP address. But what happens if you try to reach your Ubuntu Server by name instead of by number?

In a real network with dozens of machines, nobody memorizes IP addresses. DNS translates human-friendly names like ubuntu.lab into IP addresses automatically. In this step, you'll install dnsmasq on your Ubuntu Server and configure it as a DNS server for your entire lab network.

In this step, get ready to:
  • Disable the systemd-resolved stub listener and install dnsmasq.
  • Configure DNS records so all lab machines resolve each other by name.
  • Test name resolution from your Windows VM.
See why you need DNS

Before changing anything, let's prove that name resolution does not work yet. Switch to your Windows 11 VM.

Before you run this, what do you think will happen when Windows tries to resolve a hostname it has never heard of?

  • Open Command Prompt by pressing the Windows key, typing cmd, and pressing Enter.
  • Try to ping your Ubuntu Server by name by running:
ping ubuntu.lab

You'll see an error like "Ping request could not find host ubuntu.lab." That failure is the gap this step closes. Windows has no idea what ubuntu.lab means because no DNS server is translating that name into 192.168.67.10.

Disable the systemd-resolved stub listener and install dnsmasq

Ubuntu runs a service called systemd-resolved that occupies port 53 by default. Port 53 is the standard DNS port. You need to free it so dnsmasq can listen there instead.

  • Switch to your Ubuntu Server SSH session.
  • Open the resolved configuration file by running:
sudo nano /etc/systemd/resolved.conf
  • Find the line that says:
#DNSStubListener=yes
  • Add the following line directly below it:
DNSStubListener=no
  • Save the file by pressing Ctrl+O then Enter, and exit nano by pressing Ctrl+X.

What does DNSStubListener=no do?

By default, systemd-resolved runs a stub DNS listener on 127.0.0.53:53. This blocks any other DNS server from using port 53.

Setting DNSStubListener=no tells systemd-resolved to stop occupying that port so dnsmasq can take over DNS duties.

  • Restart systemd-resolved and repoint the /etc/resolv.conf symlink by running these two commands:
sudo systemctl restart systemd-resolved
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

Why repoint resolv.conf?

The /etc/resolv.conf file tells your system where to send DNS queries. By pointing it at /run/systemd/resolve/resolv.conf, Ubuntu will use the upstream DNS servers configured in systemd-resolved rather than the now-disabled stub listener.

  • Verify that port 53 is now free by running:
ss -ulnp | grep 53

You should see no output, or nothing listening on :53. That means the port is free for dnsmasq.

Still seeing something on port 53?

If you still see systemd-resolve listed, double-check that you added DNSStubListener=no (not DNSStublistener) and that you restarted the service with sudo systemctl restart systemd-resolved.

help me troubleshoot why systemd-resolved is still listening on port 53 after I set DNSStubListener=no

  • Install dnsmasq by running:
sudo apt install dnsmasq -y
  • Confirm dnsmasq is running by checking its status:
sudo systemctl status dnsmasq

You should see active (running) in green. dnsmasq started automatically after installation and claimed port 53.

dnsmasq failed to start?

If the status shows failed, another process may still be holding port 53. Run ss -ulnp | grep 53 again and resolve the conflict. Then restart dnsmasq with sudo systemctl restart dnsmasq.

help me fix dnsmasq failing to start on port 53

Configure DNS records for the lab

dnsmasq is running, but it only has its default configuration. You need to tell it about your lab domain and which hostnames map to which IP addresses.

  • Back up the original configuration file by running:
sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.bak
  • Create a fresh, clean configuration file by running:
sudo nano /etc/dnsmasq.conf
  • Paste the following configuration into the empty file:
# Lab DNS Server Configuration

# Don't read /etc/resolv.conf for upstream servers
no-resolv

# Upstream DNS servers for external lookups (e.g. google.com)
server=8.8.8.8
server=8.8.4.4

# Lab domain configuration
domain=lab
local=/lab/

# Local DNS records - resolve lab hostnames to IPs
address=/ubuntu.lab/192.168.67.10
address=/windows.lab/192.168.67.50
address=/host.lab/192.168.67.1
  • Save the file with Ctrl+O then Enter, and exit with Ctrl+X.

What does this configuration do?

  • no-resolv tells dnsmasq to ignore /etc/resolv.conf and only use the upstream servers you define explicitly.
  • server=8.8.8.8 and server=8.8.4.4 are Google's public DNS servers. dnsmasq forwards any query it cannot answer locally (like google.com) to these.
  • domain=lab sets the local domain name. local=/lab/ tells dnsmasq to answer .lab queries itself and never forward them upstream.
  • Each address= line creates a DNS record mapping a hostname to an IP address.
  • Validate your configuration syntax by running:
dnsmasq --test

You should see a message confirming the syntax is OK.

Seeing a syntax error?

Check for typos in your /etc/dnsmasq.conf file. Common mistakes include missing the / characters around hostnames in address= lines or adding spaces around the = signs.

help me fix a dnsmasq configuration syntax error

✔️ Awesome, I've got everything!

Great. Double check you've saved the file.

ⓧ I'd like to double check the full code

Your /etc/dnsmasq.conf should contain exactly this:

# Lab DNS Server Configuration

# Don't read /etc/resolv.conf for upstream servers
no-resolv

# Upstream DNS servers for external lookups (e.g. google.com)
server=8.8.8.8
server=8.8.4.4

# Lab domain configuration
domain=lab
local=/lab/

# Local DNS records - resolve lab hostnames to IPs
address=/ubuntu.lab/192.168.67.10
address=/windows.lab/192.168.67.50
address=/host.lab/192.168.67.1
Start dnsmasq and test name resolution from Windows

Your configuration is valid. Now restart dnsmasq so it picks up the new DNS records.

  • Restart dnsmasq and enable it to start on boot by running:
sudo systemctl restart dnsmasq
sudo systemctl enable dnsmasq
  • Verify dnsmasq is listening on port 53 by running:
ss -ulnp | grep 53

You should see dnsmasq listed as listening on port 53. That confirms it is ready to answer DNS queries.

Why enable on boot?

The enable command tells systemd to start dnsmasq automatically whenever the Ubuntu VM boots. Without it, you would have to manually start dnsmasq every time you restart the VM.

Now you need to tell the Windows VM to use your Ubuntu Server as its DNS server.

  • Switch to your Windows 11 VM.
  • Press the Windows key, type Control Panel, and press Enter.
  • Click Network and Internet.
  • Click Network and Sharing Center.
  • Click Change adapter settings in the left sidebar.
  • Right-click the host-only adapter (the one named Ethernet 2 or similar, with the 192.168.67.50 address) and select Properties.
  • Double-click Internet Protocol Version 4 (TCP/IPv4).
  • In the Preferred DNS server field, enter 192.168.67.10.
  • Click OK, then OK again to close the dialogs.

What did you just do?

You told the Windows host-only adapter to send all DNS queries to 192.168.67.10 (your Ubuntu Server). When Windows asks "what IP is ubuntu.lab?", the question goes to dnsmasq, which looks up its address= records and returns the answer.

Time to test. What do you think will happen now when you run nslookup ubuntu.lab from Windows?

  • Open Command Prompt on Windows (if it is not still open) and test DNS resolution by running:
nslookup ubuntu.lab 192.168.67.10

You should see ubuntu.lab resolve to 192.168.67.10, with the server listed as 192.168.67.10. Your DNS server is working.

  • Now test with a ping to confirm full end-to-end resolution:
ping ubuntu.lab

This time you should see replies from 192.168.67.10. The same command that failed at the start of this step now succeeds because dnsmasq is translating the name for you.

nslookup times out or ping still fails?

  • Confirm dnsmasq is running on Ubuntu with sudo systemctl status dnsmasq. If it is not active, check for config errors with dnsmasq --test.
  • Make sure you set the Preferred DNS server to 192.168.67.10 on the correct adapter (the host-only one with the 192.168.67.50 IP, not the NAT adapter).
  • If the adapter selection is confusing, run ipconfig /all in Command Prompt to see which adapter has the 192.168.67.50 address.

help me troubleshoot why nslookup to my dnsmasq server is timing out from Windows

Your lab network now has its own DNS server. Machines can find each other by name instead of by raw IP address. Next up, you'll add DHCP so that new machines joining the network get their IP address and DNS settings automatically.

Add DHCP to dnsmasq

Your DNS server is resolving names beautifully, but think about how you got the Windows VM onto the network. You manually typed in an IP address, a subnet mask, and a DNS server address.

If you add another VM to this lab (like the Kali box in Project 3), you would have to repeat that entire manual process. DHCP automates IP assignment so every client that joins the network receives its configuration automatically.

In this step, get ready to:
  • Disable VirtualBox's built-in DHCP server to prevent conflicts.
  • Add DHCP configuration to dnsmasq with a pool and a static reservation.
  • Switch Windows to automatic IP and confirm it receives the correct address from your server.
Disable VirtualBox's built-in DHCP server

VirtualBox ships with its own DHCP server for host-only networks. If you leave it running while dnsmasq also serves DHCP on the same subnet, the two servers will race to answer client requests. The client may get an IP from VirtualBox instead of yours.

  • Switch to the VirtualBox Manager window on your host machine (not inside a VM).
  • Click File in the top menu bar.
  • Hover over Tools, then click Network Manager.
  • In the Network Manager window, select the Host-Only Networks tab (it should be the first tab).
  • Click on your host-only network (VirtualBox Host-Only Ethernet Adapter #3) to select it.
  • Click Properties if the settings panel is not already visible.
  • Click the DHCP Server tab.
  • Uncheck Enable Server to disable VirtualBox's built-in DHCP.
  • Click Apply to save the change.

Confirm that the Enable Server checkbox is now unchecked. This means VirtualBox will no longer hand out IP addresses on your lab network.

Why disable VirtualBox's DHCP?

Two DHCP servers on the same subnet is a classic networking conflict. Whichever server responds first wins, and the client gets unpredictable settings. By disabling VirtualBox's server, you guarantee that dnsmasq is the sole authority for IP assignment on this network.

Don't see the DHCP Server tab?

Make sure you selected the host-only network name in the list first. The DHCP Server tab only appears when a host-only network is selected and Properties is expanded.

help me find the DHCP Server tab in VirtualBox Network Manager

Add DHCP configuration to dnsmasq

Now you will teach dnsmasq to hand out IP addresses. You need three pieces of information: the address pool for dynamic clients, a static reservation for Windows (so it always gets the same IP), and DHCP options that push DNS and domain settings to clients.

  • First, find your Windows VM's MAC address. In your Windows VM, open Command Prompt and run:
ipconfig /all
  • Look for the adapter whose description mentions VirtualBox and Host-Only. Note the Physical Address value (it looks like 08-00-27-XX-XX-XX).
  • Write this MAC address down. You will need it in the next step. Convert the dashes to colons for the dnsmasq config (e.g. 08:00:27:XX:XX:XX).

Where else to find the MAC

You can also find the MAC in VirtualBox Manager. Select the Windows VM, click Settings, go to Network, expand Adapter 2, click Advanced, and read the MAC Address field. Add colons between every two characters.

  • Now SSH into your Ubuntu Server from your host terminal (or switch to its console window).
  • Open the dnsmasq configuration file by running:
sudo nano /etc/dnsmasq.conf
  • Scroll to the bottom of the file (below your existing DNS address records) and add the following DHCP configuration:
# DHCP address pool - hand out IPs in this range with 12-hour leases
dhcp-range=192.168.67.100,192.168.67.200,255.255.255.0,12h

# Static reservation - always give this MAC the same IP
dhcp-host=[[WINDOWS_MAC="your Windows VM MAC address (e.g. 08:00:27:ab:cd:ef)"]],192.168.67.50,windows

# Push DNS server address to all DHCP clients
dhcp-option=option:dns-server,192.168.67.10

# Push domain name to all DHCP clients
dhcp-option=option:domain-name,lab

What does this configuration do?

The dhcp-range line defines the pool of addresses dnsmasq can give out. Future VMs (like Kali in Project 3) will receive an IP from 192.168.67.100 to 192.168.67.200 automatically.

The dhcp-host line pins your Windows VM to 192.168.67.50 every time, based on its MAC address. This is called a static reservation.

The two dhcp-option lines push settings to clients. option:dns-server tells clients to use Ubuntu for DNS. option:domain-name sets the search domain to lab so clients can resolve short names like ubuntu without typing the full ubuntu.lab.

  • Save the file with Ctrl+O, press Enter, then exit nano with Ctrl+X.
  • Test your configuration for syntax errors by running:
dnsmasq --test

You should see a message indicating the syntax is OK. If you see an error, re-open the file and check for typos (mismatched commas are the most common mistake).

Seeing a syntax error?

Double-check that each dhcp-option line uses a comma after option:dns-server or option:domain-name with no spaces around the comma. Also verify that your dhcp-host line has the MAC address in colon-separated format (not dashes).

help me fix a dnsmasq configuration syntax error

Restart dnsmasq and test DHCP on Windows
  • Restart dnsmasq to load the new DHCP configuration by running:
sudo systemctl restart dnsmasq
  • Verify that dnsmasq is now listening on both DNS (port 53) and DHCP (port 67) by running:
ss -ulnp | grep -E "(53|67)"

You should see port 53 (DNS) and port 67 (DHCP) listed in the output. This confirms dnsmasq is ready to serve both services.

Port 67 not showing up?

Check the dnsmasq status for errors by running sudo systemctl status dnsmasq. If it failed to start, the output will show what went wrong. The most common issue is a typo in the DHCP lines you just added.

help me troubleshoot dnsmasq not starting after adding DHCP config

Now switch to your Windows VM. You need to change the host-only adapter from its current static IP to automatic (DHCP) mode.

  • Right-click the network icon in the Windows taskbar and click Network and Internet settings.
  • Click Advanced network settings.
  • Find your host-only adapter (the one whose description mentions VirtualBox) and click the expand arrow next to it.
  • Click Edit (or View additional properties, then Edit).
  • Find Internet Protocol Version 4 (TCP/IPv4) and click Edit.
  • Select Obtain an IP address automatically.
  • Select Obtain DNS server address automatically.
  • Click Save (or OK) to apply.

Before you test, think about this: when Windows requests an IP from dnsmasq, do you think it will get a random address from the 192.168.67.100-200 pool, or will it get 192.168.67.50 specifically? Why?

  • Open Command Prompt in your Windows VM. Release the current IP and request a new one from dnsmasq by running:
ipconfig /release "Ethernet 2"
ipconfig /renew "Ethernet 2"

What if your adapter has a different name?

The adapter name in quotes must match what ipconfig shows for your host-only adapter. Run ipconfig without arguments first and look for the adapter connected to VirtualBox. Use that exact name in the release and renew commands. If the name contains spaces, keep the quotes.

  • After the renew completes, verify your IP assignment by running:
ipconfig /all

Find your host-only adapter in the output. You should see 192.168.67.50 as the IPv4 address. The DHCP Server field shows 192.168.67.10 (your Ubuntu VM). That is the static reservation at work.

  • Finally, confirm that DNS still works over the DHCP-assigned connection by running:
ping ubuntu.lab

You should see replies from 192.168.67.10. Your Ubuntu server is now providing both DNS and DHCP to the lab network, and Windows is using both services automatically.

Renew hanging or getting 169.254.x.x?

A 169.254.x.x address means Windows could not reach any DHCP server. Check that dnsmasq is running on Ubuntu (sudo systemctl status dnsmasq). Also verify you disabled VirtualBox's built-in DHCP server in the previous substep. Two DHCP servers fighting can also cause a timeout.

If the renew command hangs, your adapter name might not match. Press Ctrl+C to cancel, run ipconfig alone to find the correct adapter name, and retry with the exact name in quotes.

help me troubleshoot Windows not getting an IP from dnsmasq DHCP

Your Ubuntu server now runs a complete network infrastructure stack. Any new VM you add to this host-only network will automatically receive an IP address, DNS server, and domain name from dnsmasq. In the next project, you will add Kali Linux and it will join with zero manual configuration.

Secret mission

Configure Reverse DNS Lookups

You have forward DNS working. Names resolve to IPs. But what about the other direction? In production networks, logging systems, SSH host verification, and troubleshooting tools all need to translate IP addresses back into hostnames. Configure reverse DNS so your lab network supports full bidirectional name resolution.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally, so there are no ongoing cloud costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Windows 11 Enterprise Evaluation VM (90-day trial, 64 GB virtual disk on your local machine).
  • dnsmasq service running on Ubuntu Server (DNS, DHCP, and reverse DNS for the lab network).

Keep everything running

No action needed. Choose this if you are still actively building on this lab network.

  • Leave both VMs configured as-is. The Windows 11 Enterprise evaluation runs for 90 days from install.
  • This setup is required for Project 3 (Kali Linux and security testing). Keep it running if you plan to continue the series.
  • dnsmasq will start automatically when Ubuntu boots, so DNS and DHCP will be ready whenever you power on the VMs.

Pause - I'll come back to this later

Shut down both VMs to free up system memory. Your configurations persist on disk and will work when you boot them again.

  • In the Windows 11 VM, click the Start menu, click the power icon, and select Shut down.
  • In the Ubuntu Server VM, run the following command:
sudo shutdown now
  • When you are ready to resume, open VirtualBox Manager and start both VMs. SSH back into Ubuntu and confirm dnsmasq is running with:
sudo systemctl status dnsmasq

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps to fully clean up.

Delete the Windows 11 VM:

  • Shut down the Windows 11 VM if it is running.
  • In VirtualBox Manager, right-click the Windows 11 VM.
  • Select Remove, then click Delete all files.
  • This removes the VM and its 64 GB virtual disk from your machine.

Remove dnsmasq from Ubuntu:

  • SSH into your Ubuntu Server VM and run:
sudo apt remove dnsmasq
  • This removes the dnsmasq package and stops DNS/DHCP services on the lab network.

Revert systemd-resolved to its default state:

  • Open the resolved configuration file:
sudo nano /etc/systemd/resolved.conf
  • Remove or comment out the DNSStubListener=no line, then save and exit.
  • Restore the default resolv.conf symlink and restart the service:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

Re-enable VirtualBox's built-in DHCP (optional):

  • In VirtualBox, open File > Tools > Network Manager.
  • Select the Host-Only tab, click on VirtualBox Host-Only Ethernet Adapter #3, then enable the DHCP Server checkbox if you want the default DHCP behavior restored.

Nice Work!

Nice Work!

You just built a fully functioning internal network where your Ubuntu Server provides DNS and DHCP services to a Windows 11 client. That is the same infrastructure backbone that runs inside every enterprise network.

Here's what you accomplished:

  • Built a multi-VM lab network from scratch with a Windows 11 Enterprise VM and Ubuntu Server communicating over a private host-only subnet.
  • Deployed dnsmasq as a combined DNS and DHCP server that resolves friendly hostnames (ubuntu.lab, windows.lab, host.lab) and automatically assigns IP addresses to any client joining the network.
  • Took full control of network services by disabling VirtualBox's built-in DHCP and configuring static reservations for predictable addressing across your lab.
  • Secret Mission: Configured reverse DNS (PTR records) so that looking up an IP address returns the hostname, just like production logging and security tools expect.

Ready to quiz yourself?