Error

Had the same problem a while ago, you need to regenerate the machineid: https://wiki.debian.org/MachineId

  • creation of DHCP host identifier (probably causing multiple machines fighting over the same IP address on the DHCP server)

Very cool

Looks like both of your vms probably have the same mac address - the 172 ip address is likely a self-assigned fallback when the dhcp server replies to the second vm that it can't give it an address. Double-check and make sure the mac address in each vm's proxmox network adapter settings match your pfsense dhcp reservations, and let me know if that resolves it.

A 172.16.0.0/12 address would be a very unusual fallback behavior. Normally you'll have only a 169.254.0.0/16.

You're saying one VM was cloned from the other. I could imagine a DHCP client saving leases to disk (they can have pretty long validity periods), and if the box was assigned the .106 address at any point and then cloned, the cloned machine would probably try to take that address, in other words ARP the address to determine if it's taken, and if so, fall back to some other thing. I would have expected an APIPA address but 172.x.y.z is not out of the question depending on config.

Also, if your bridge has an interface connected to e.g. another ISP-provided router then it would expose any DHCP server running behind that interface to your VMs, creating a race.

Agreed. I've seen 172 addresses self-assigned before, even though the apipa spec says it should be 169.254.x.x.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer LettersMore Letters
ARPAddress Resolution Protocol, translates IPs to MAC addresses
DHCPDynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network
IPInternet Protocol
ISPInternet Service Provider

4 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.

[Thread #320 for this comm, first seen 29th May 2026, 06:10] [FAQ] [Full list] [Contact] [Source code]

Is the 172. address on the same interface? Could just be some virtual docker interface being unrelated to the DHCP issue.

VM ≠ Docker