Why Ubuntu VMs Keep Changing IP Addresses After Reboot on Proxmox (And How to Fix It)

Ever noticed that your Ubuntu virtual machine gets a different IP address after almost every reboot, while Rocky Linux, AlmaLinux, or openSUSE VMs keep the same address?

If you're running a Proxmox homelab or enterprise virtualization cluster, this behavior can be frustrating—especially when DNS records, SSH shortcuts, monitoring systems, or automation scripts suddenly point to the wrong IP.

The good news is that this isn't a Proxmox bug.

It's actually the result of how Ubuntu identifies itself to DHCP servers.

Let's see why.

The Symptom

Imagine a Proxmox server hosting several Linux virtual machines.

All VMs:

• use VirtIO NICs
• have fixed MAC addresses
• connect to the same bridge
• receive addresses from the same DHCP server

Yet only Ubuntu appears to "forget" its previous address.

Naturally, many administrators assume Proxmox is changing the MAC address.

It isn't.

The Common Misconception

Most people believe DHCP works like this:

Same MAC address = Same IP address

That sounds reasonable.

Unfortunately, it isn't how DHCP actually works.

The DHCP protocol identifies clients using a Client Identifier, not necessarily the MAC address.

Depending on the operating system, that identifier can be:

• the MAC address
• a DHCP Unique Identifier (DUID)
• another client identifier generated by the network stack

This subtle difference explains almost everything.

Ubuntu vs Rocky Linux: Different DHCP Strategies

Ubuntu uses Netplan as its network configuration layer.

When Netplan is configured to use systemd-networkd, DHCP clients identify themselves using a DUID (DHCP Unique Identifier).

The DUID is generated from information such as:

• /etc/machine-id
• interface information
• system-generated identifiers

Notice what's missing?

The MAC address isn't necessarily the primary identifier.

Meanwhile, distributions such as Rocky Linux, AlmaLinux, or openSUSE typically rely on NetworkManager, whose traditional default behavior is to identify clients using the NIC's MAC address.

In practice

Rocky Linux:

MAC Address
        ↓
DHCP Client ID
        ↓
DHCP server recognizes same client
        ↓
Same IP

Ubuntu:

machine-id + DUID
        ↓
DHCP Client ID
        ↓
DHCP server identifies client by DUID

Different identification methods lead to different lease behavior depending on how the DHCP server manages leases.

The Second Piece of the Puzzle: Lease Release

Ubuntu's systemd-networkd often releases its DHCP lease during shutdown.

You'll frequently find log entries similar to:

DHCP lease lost

Once released, the address immediately returns to the DHCP server's available pool.

If another client requests an address before Ubuntu boots again, that client may receive the old address.

When Ubuntu comes back online, the DHCP server simply assigns the next available address.

This creates the impression that Ubuntu randomly changes IPs after every reboot.

In reality, it's just following DHCP rules.

How to Verify the Problem

First, determine what's managing networking.

cat /etc/netplan/*.yaml

Then inspect the interface.

networkctl status ens18

Look for information about the DHCP client identifier or DUID.

You should also verify that cloud-init isn't regenerating network configuration:

cloud-init status

Finally, ensure the machine ID remains stable.

cat /etc/machine-id

If this file changes after every reboot, that's a completely separate issue—often caused by improperly cloned VM templates.

Solution 1: Use the MAC Address as the DHCP Identifier

Netplan supports forcing DHCP identification by MAC address.

Add:

dhcp-identifier: mac

Example:

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: true
      dhcp-identifier: mac
      match:
        macaddress: bc:24:11:44:b8:8a
      set-name: ens18

Apply the configuration:

sudo netplan apply

This makes Ubuntu behave much more like Rocky Linux.

However, it doesn't prevent DHCP lease release during shutdown, so it's an improvement—not a guarantee.

Solution 2: Create a DHCP Reservation (Recommended)

The most reliable solution is configuring a static DHCP reservation on your DHCP server.

Whether you're using:

• pfSense
• OPNsense
• MikroTik
• UniFi
• Windows DHCP
• ISC DHCP
• dnsmasq

they all support binding a specific IP address to a MAC address.

Advantages include:

• centralized IP management
• no manual network configuration inside the VM
• guaranteed stable addressing
• easier infrastructure documentation

For servers, this is generally considered best practice.

Solution 3: Configure a Static IP in Ubuntu

If the server should never depend on DHCP, configure Netplan with a static address.

Example:

network:
  version: 2
  ethernets:
    ens18:
      addresses:
        - 192.168.1.155/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 192.168.1.1
      match:
        macaddress: bc:24:11:44:b8:8a
      set-name: ens18

Then apply:

sudo netplan apply

If using this approach, always ensure the chosen address is outside your DHCP pool to avoid IP conflicts.

Which Solution Should You Choose?

For production environments, DHCP reservations provide the best balance between flexibility and predictable addressing.

Final Thoughts

Ubuntu isn't doing anything "wrong," and neither is Proxmox.

The behavior stems from a combination of:

• Ubuntu's default DUID-based DHCP client identification
• systemd-networkd releasing DHCP leases during shutdown
• DHCP server lease allocation policies

Once you understand how DHCP actually identifies clients, the mystery disappears.

If your virtual machine hosts services like SAP, databases, monitoring agents, Kubernetes nodes, or backup software, don't rely on default DHCP behavior alone. Configure either a DHCP reservation or a static IP to ensure consistent addressing and eliminate unexpected network changes after reboots.