Proxmox Vlan Issues 8.4 to 9.1

C

Crpt0110

New Member
Mar 28, 2026
5
0
1
Hey there I unfortunately am having some issues with the 9.1 and I'm just here double checking if anyone else has any ideas or solutions for this odd problem. Unfortunately this configuration works perfectly on my 8.4.1.7 PVE versions but when updated to proxmox 9 or fresh installed, this configuration ends up with the host being pingable, but the management web UI will refuse to load. If I set the IP address on the vmbr0 with bond0 in no vlan the webui loads just fine on reboot such as 192.168.1.16.

Here is the relevant area of my /etc/network/interfaces. This would be utilizing Mellanox Connectx3 cards.

Once again, this configuration works perfectly fine on 8.4.1.7 on this exact device

BUT when updated to 9.1 or fresh install to 9.1 the management web ui will load with the vlan assignment ONLY AFTER I CONNECT TO THE 9.1 VIA PUTTY, dont need to login, just connect then the management ui will load.



auto lo
iface lo inet loopback

iface enp5s0f0 inet manual

iface enp5s0f1 inet manual

auto enp139s0
iface enp139s0 inet manual
mtu 9000

auto enp139s0d1
iface enp139s0d1 inet manual
mtu 9000

auto bond0
iface bond0 inet manual
bond-slaves enp139s0 enp139s0d1
bond-miimon 100
bond-mode 802.3ad
mtu 9000

auto vmbr0
iface vmbr0 inet manual
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40 50 60 70 80 90 100
mtu 9000

auto vmbr0.10
iface vmbr0.10 inet manual

auto vmbr0.20
iface vmbr0.20 inet static
address 192.168.20.16/24
gateway 192.168.20.1
mtu 9000
 
Last edited:
That connecting via PuTTY triggering the web UI to load is a dead giveaway - it means pveproxy is starting before the VLAN sub-interface is fully up. On 8.4 the timing was just different enough not to matter, but 9.1 must be starting services fractionally earlier in the boot sequence. Two things worth trying: first, add a post-up systemctl restart pveproxy to your vmbr0.20 stanza in /etc/network/interfaces so the proxy restarts once the management VLAN interface is confirmed up. Second, check which IP pveproxy is binding to at startup - you can see this in systemctl status pveproxy and the journal. If it is binding before the VLAN interface assigns the IP, it will miss it. Also worth verifying with ip -br addr right after boot before connecting via PuTTY to confirm vmbr0.20 has its address at that point.
 
It is binding to the correct address, the post-up didn't seem to affect this issue, even directly restarting the service didn't bring the WebUI back alive. Directly after boot it lists the correct vlan address. Even more odd is that it will time out after about 20-30 minutes on the webui, but another hit from Putty, will bring connectivity back to the WebUI Management and it is functional once again. All while a continuous ping does not drop a single packet.
 
upgrade 8.4 to 9.1 some change might need to force pve certificate update
for rebinding https config and renew certificate.
> pvecm updatecerts --force
> reboot
 
Wichets said:
upgrade 8.4 to 9.1 some change might need to force pve certificate update
for rebinding https config and renew certificate.
> pvecm updatecerts --force
> reboot
Click to expand...
Unfortunately this isn't it either, tried that, tried fresh install, same behavior.
 
Other LXCs and VMs when the 192.168.20.16 IP address is assigned to VMBR0.20 on the PVE host, the LXCs will not carry any VLAN tags properly resulting in them not having any connectivity while the host still has connectivity. Something obviously is either different or not acting as it should unfortunately without a single change in the config or networking switches. Unfortunately with me upgrading one of my zfs pools I need to be on Proxmox9 or I would just downgrade and wait for these issues to be fixed.

Also having issues with mount points attributes being passed through but that is a separate issue with PVE 9.
 
You must log in or register to reply here.
Top Bottom
Back