Proxmox DNS picks incorrect address

P

PMX151

New Member
May 29, 2025
10
0
1
I have 4 ethernet ports, 1 as management and 3 bonded for VM, added to the relevant bridges.

Bash: 
auto lo
iface lo inet loopback

auto enp3s0f0
iface enp3s0f0 inet manual
#Port 1 - Management
auto enp3s0f1
iface enp3s0f1 inet manual
#Port 2 - Bridge Port 1
auto enp4s0f0
iface enp4s0f0 inet manual
#Port 3 - Bridge Port 2
auto enp4s0f1
iface enp4s0f1 inet manual
#Port 4 - Bridge Port 3
auto vmbr1
iface vmbr1 inet dhcp
        bridge-ports enp3s0f0
        bridge-stp off
        bridge-fd 0
#Management Bridge
auto bond0
iface bond0 inet manual
        bond-slaves enp3s0f1 enp4s0f0 enp4s0f1
        bond-miimon 100
        bond-mode balance-alb
#VM Port Bonding
auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
#VM Bridge

source /etc/network/interfaces.d/*

The management bridge uses DHCP (all IPs are statically assigned/managed on the router) but it picks up the DNS address handed out by the VM that manages the VM network. Now I will in the fullness of time be using the firewall and/or VLANs but this is how it is for now. The management port receives the correct address but the DNS is always wrong. If I set it manually in the GUI or edit /etc/resolv.conf it changes back to the VM DHCP address almost immediately.

Results of ip -4 -p -br a

Bash: 
lo               UNKNOWN        127.0.0.1/8
enp3s0f0         UP             172.16.200.203/24
enp3s0f1         UP             192.168.99.78/24
enp4s0f0         UP             192.168.99.70/24
enp4s0f1         UP             192.168.99.68/24
bond0            UP             192.168.99.78/24
vmbr0            UP             192.168.99.78/24 192.168.99.72/24
veth109i0@if2    UP             192.168.99.64/24
fwbr100i0        UP             192.168.99.114/24
fwln100i0@fwpr100p0 UP             192.168.99.114/24
fwbr100i1        UP             192.168.99.116/24
fwln100i1@fwpr100p1 UP             192.168.99.116/24
fwbr100i2        UP             192.168.99.127/24
fwln100i2@fwpr100p2 UP             192.168.99.127/24
vmbr1            UP             172.16.200.203/24

I thought I had hit upon the solution here but it again gets reverted almost instantly after displaying correctly the contents of my manual edit to /etc/resolv.conf.

My "simple" question is, why won't Proxmox just use the DNS server given to it via the DHCP server on the management port?

Also why do all network ports and vmbr0 grab an IP when there is no IP setting in /etc/network/interfaces telling it to do so?
 
Last edited:
And another related issue I have just encountered is that despite Proxmox using the DHCP address for the DNS it can't actually access it as it adds all of the VM IPs as routes for the network so it just arbitrarily tries to access the network using a random port/interface it seems, and fails, so DNS resolution fails and now it can't connect to anything (using hostnames).

ip route

Bash: 
default via 172.16.200.1 dev vmbr1
172.16.200.0/24 dev vmbr1 proto kernel scope link src 172.16.200.203
172.16.200.0/24 dev enp3s0f0 proto kernel scope link src 172.16.200.203
192.168.99.0/24 dev fwln100i1 proto kernel scope link src 192.168.99.116
192.168.99.0/24 dev fwbr100i1 proto kernel scope link src 192.168.99.116
192.168.99.0/24 dev veth109i0 proto kernel scope link src 192.168.99.64
192.168.99.0/24 dev enp4s0f1 proto kernel scope link src 192.168.99.68
192.168.99.0/24 dev enp4s0f0 proto kernel scope link src 192.168.99.70
192.168.99.0/24 dev fwln100i2 proto kernel scope link src 192.168.99.127
192.168.99.0/24 dev fwln100i0 proto kernel scope link src 192.168.99.114
192.168.99.0/24 dev vmbr0 proto kernel scope link src 192.168.99.72
192.168.99.0/24 dev fwbr100i2 proto kernel scope link src 192.168.99.127
192.168.99.0/24 dev fwbr100i0 proto kernel scope link src 192.168.99.114

traceroute 192.168.99.18 (the IP of the DNS server it keeps incorrectly using)

Bash: 
traceroute to 192.168.99.18 (192.168.99.18), 30 hops max, 60 byte packets
 1  192.168.99.116 (192.168.99.116)  3079.262 ms !H  3079.001 ms !H  3078.988 ms !H

I am clearly missing something here (coming from ESXi where the vSwitch just isolated internal/external "devices").
 
The lack of any replies to any of my posts about DNS issues suggests to me that DNS on Proxmox doesn't work?
 
PMX151 said:
coming from ESXi where the vSwitch just isolated internal/external "devices"
Click to expand...
If you want a similar setup, you may have to took at OpenVSwitch, which does AFAIK something similar.

PMX151 said:
The management bridge uses DHCP (all IPs are statically assigned/managed on the router) but it picks up the DNS address handed out by the VM that manages the VM network.
Click to expand...
That's not what's configured. Your vmbr1 uses DHCP, then you configured a bond that you labeled bridge and a bridge on that bond that is labeled VM Port bonding, whatever that should be. It is part of the management network which could be intended.

Could you please post the ouput of ip a in code tags?
 
LnxBil said:
That's not what's configured. Your vmbr1 uses DHCP, then you configured a bond that you labeled bridge and a bridge on that bond that is labeled VM Port bonding, whatever that should be. It is part of the management network which could be intended.
Click to expand...

enp3s0f0 is port 1, which is the only member of the management bridge vmbr1. There is DHCP enabled on the management bridge.

The other 3 ports; enp3s0f1, enp4s0f0, enp4s0f1 are part of bond0 and vmbr0 which does not have DHCP enabled.

You're saying that vmbr0/bond0 is somehow linked to vmbr1 still?

LnxBil said:
Could you please post the ouput of ip a in code tags?
Click to expand...

Bash: 
root@pve03:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:74 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.203/24 brd 172.16.200.255 scope global dynamic enp3s0f0
       valid_lft 3597sec preferred_lft 3597sec
3: enp3s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.78/24 brd 192.168.99.255 scope global dynamic enp3s0f1
       valid_lft 819sec preferred_lft 819sec
4: enp4s0f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:64 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.70/24 brd 192.168.99.255 scope global dynamic enp4s0f0
       valid_lft 1523sec preferred_lft 1523sec
5: enp4s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.68/24 brd 192.168.99.255 scope global dynamic enp4s0f1
       valid_lft 1525sec preferred_lft 1525sec
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.78/24 brd 192.168.99.255 scope global dynamic bond0
       valid_lft 682sec preferred_lft 682sec
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.72/24 brd 192.168.99.255 scope global dynamic vmbr0
       valid_lft 982sec preferred_lft 982sec
    inet 192.168.99.78/24 brd 192.168.99.255 scope global secondary dynamic vmbr0
       valid_lft 724sec preferred_lft 724sec
    inet6 fe80::ae16:2dff:feb6:fe76/64 scope link
       valid_lft forever preferred_lft forever
8: veth109i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:96:fa:96:3d:f4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.99.64/24 brd 192.168.99.255 scope global dynamic veth109i0
       valid_lft 927sec preferred_lft 927sec
9: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i0 state UNKNOWN group default qlen 1000
    link/ether b2:12:f8:40:8f:03 brd ff:ff:ff:ff:ff:ff
10: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5a:f2:a7:14:de:49 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.114/24 brd 192.168.99.255 scope global dynamic fwbr100i0
       valid_lft 1532sec preferred_lft 1532sec
11: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 16:33:1d:76:4c:48 brd ff:ff:ff:ff:ff:ff
12: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
    link/ether 5a:f2:a7:14:de:49 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.114/24 brd 192.168.99.255 scope global dynamic fwln100i0
       valid_lft 1528sec preferred_lft 1528sec
13: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i1 state UNKNOWN group default qlen 1000
    link/ether 22:ec:27:87:2f:f1 brd ff:ff:ff:ff:ff:ff
14: fwbr100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ae:e6:c7:03:56:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.116/24 brd 192.168.99.255 scope global dynamic fwbr100i1
       valid_lft 1648sec preferred_lft 1648sec
15: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 8e:5d:76:23:88:8c brd ff:ff:ff:ff:ff:ff
16: fwln100i1@fwpr100p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i1 state UP group default qlen 1000
    link/ether ae:e6:c7:03:56:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.116/24 brd 192.168.99.255 scope global dynamic fwln100i1
       valid_lft 1775sec preferred_lft 1775sec
17: tap100i2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i2 state UNKNOWN group default qlen 1000
    link/ether 2a:3a:48:1d:92:44 brd ff:ff:ff:ff:ff:ff
18: fwbr100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:26:bf:01:40:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.127/24 brd 192.168.99.255 scope global dynamic fwbr100i2
       valid_lft 1535sec preferred_lft 1535sec
19: fwpr100p2@fwln100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 7e:02:d2:2d:c4:ba brd ff:ff:ff:ff:ff:ff
20: fwln100i2@fwpr100p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i2 state UP group default qlen 1000
    link/ether 06:26:bf:01:40:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.127/24 brd 192.168.99.255 scope global dynamic fwln100i2
       valid_lft 1531sec preferred_lft 1531sec
21: veth103i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:3f:28:a2:0f:fd brd ff:ff:ff:ff:ff:ff link-netnsid 1
23: veth108i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:6c:84:88:2b:32 brd ff:ff:ff:ff:ff:ff link-netnsid 3
24: veth105i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:6f:0f:2d:ed:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 4
25: veth102i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:56:31:e2:68:89 brd ff:ff:ff:ff:ff:ff link-netnsid 5
26: tap106i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 76:ca:03:46:89:8e brd ff:ff:ff:ff:ff:ff
27: tap107i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 12:33:58:0c:45:e1 brd ff:ff:ff:ff:ff:ff
28: tap110i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether f2:c7:fe:1a:dd:38 brd ff:ff:ff:ff:ff:ff
29: tap111i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 3e:e0:e6:15:c1:67 brd ff:ff:ff:ff:ff:ff
31: tap112i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 42:0f:a8:7c:49:d0 brd ff:ff:ff:ff:ff:ff
32: veth104i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:d0:c7:74:9f:9c brd ff:ff:ff:ff:ff:ff link-netnsid 2
33: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:16:2d:b6:fe:74 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.203/24 brd 172.16.200.255 scope global dynamic vmbr1
       valid_lft 3313sec preferred_lft 3313sec
    inet6 fe80::ae16:2dff:feb6:fe74/64 scope link
       valid_lft forever preferred_lft forever
 
Last edited:
PMX151 said:
enp3s0f0 is port 1, which is the only member of the management bridge vmbr1. There is DHCP enabled on the management bridge.

The other 3 ports; enp3s0f1, enp4s0f0, enp4s0f1 are part of bond0 and vmbr0 which does not have DHCP enabled.

You're saying that vmbr0/bond0 is somehow linked to vmbr1 still?
Click to expand...
Oh man ... sorry, my bad. I assumed "normal" comment order, so before the actual setup, not afterwards. I never even thought about this order until now.

It is really strange indeed that all devices, also the ones in the bond, the bond and the bridge itself does have ip addresses. Are there any files in /etc/network/interfaces.d/? Did you start the command dhclient by any chance by hand? What about ps aux | grep dhclient?
 
LnxBil said:
Oh man ... sorry, my bad. I assumed "normal" comment order, so before the actual setup, not afterwards. I never even thought about this order until now.
Click to expand...
First time I've seen it this way round, standard Proxmox order for some reason.

LnxBil said:
It is really strange indeed that all devices, also the ones in the bond, the bond and the bridge itself does have ip addresses.
Click to expand...
Ah good, not just me that thinks this is odd then.

LnxBil said:
Are there any files in /etc/network/interfaces.d/?
Click to expand...
Bash: 
root@pve03:~# ls -als /etc/network/interfaces.d
total 9
1 drwxr-xr-x 2 root root  2 Nov 15  2024 .
9 drwxr-xr-x 8 root root 11 Jul 20 20:04 ..

LnxBil said:
Did you start the command dhclient by any chance by hand?
Click to expand...
I have when I've changed /etc/network/interfaces myself rather than via the Proxmox GUI. I was under the assumption dhclient only ran on the interfaces that had DHCP enabled. Are you thinking that it is just blindly running on all interfaces?

LnxBil said:
What about ps aux | grep dhclient?
Click to expand...
Bash: 
root@pve03:~# ps aux | grep dhclient
100000     71903  0.0  0.0   5876  2432 ?        Ss   Jul18   0:05 dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
100000     72355  0.0  0.0   5876  1792 ?        Ss   Jul18   0:05 dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
100000     72537  0.0  0.0   5876  2304 ?        Ss   Jul18   0:06 dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
100000    112280  0.0  0.0   5880  2432 ?        Ss   Jul18   0:05 /sbin/dhclient -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
root      850429  0.0  0.0   6336  1408 pts/0    S+   21:33   0:00 grep dhclient
root     2691193  0.0  0.0   5952  2560 ?        Ss   Jul19   3:20 dhclient
100000   2719026  0.0  0.0   5876  2560 ?        Ss   Jul19   0:05 dhclient
100000   3118838  0.0  0.0   5876  2688 ?        Ss   Jul19   0:04 dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
root     3938108  0.0  0.0   5876  2560 ?        Ss   Jul20   0:04 /sbin/dhclient -pf /run/dhclient.vmbr1.pid -lf /var/lib/dhcp/dhclient.vmbr1.leases vmbr1
root     4076164  0.0  0.0   5876  2688 ?        Ss   Jul20   0:14 /sbin/dhclient -pf /run/dhclient.vmbr0.pid -lf /var/lib/dhcp/dhclient.vmbr0.leases vmbr0
root     4077250  0.0  0.0   5956  2560 ?        Ss   Jul20   2:39 dhclient

I also just checked /var/lib/dhcp...

Bash: 
root@pve03:~# ls -als /var/lib/dhcp
total 31
9 drwxr-xr-x  2 root root     6 Jul 20 14:29 .
9 drwxr-xr-x 38 root root    39 Jun  4 14:13 ..
1 -rw-r--r--  1 root root     0 Jul 13 17:56 dhclient.bond0.leases
5 -rw-r--r--  1 root root  9375 Jul 28 21:36 dhclient.leases
5 -rw-r--r--  1 root root 13809 Jul 28 21:12 dhclient.vmbr0.leases
5 -rw-r--r--  1 root root  7826 Jul 28 21:17 dhclient.vmbr1.leases

So maybe I need to clean out this folder entirely as each of these files has loads of entries with incorrect/old info in, and then run dhclient again?
 
Last edited:
There should not be processes and/or files for the devices that are set to manual and should not have an IP. This could be the problem.

Can you have a downtime and restart the whole network or even reboot in order to see if this clears itself out?
 
Sort of answering my own question a bit here but as you pointed me in the right direction I checked https://linux.die.net/man/8/dhclient and it says

If no interface names are specified on the command line dhclient will normally identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to configure each interface.
Click to expand...

So looks like maybe when I run it manually it just runs on all interfaces. If I run dhclient -r I assume this will clean out dhclient.leases folder? Not sure how I then apply it to vmbr1 only? Maybe using /etc/dhcp/dhclient.conf?

LnxBil said:
Can you have a downtime and restart the whole network or even reboot in order to see if this clears itself out?
Click to expand...

I was also thinking that maybe a clean out of the above directories and old leases files then a reboot might somewhat "reset" things. I am in the process of moving the entire lab over to Proxmox so I think I will stand up another server and test on that. I'll report back.
 
You must log in or register to reply here.
Top Bottom