I have another finding about something that must have broken between 29-04-2026 and 09-06-2026:
cloud-init can no longer deploy haproxy config on a VRRP floating listen address. Checking the vyos-configd-script-stdout yields the following:
~$ cat /tmp/vyos-configd-script-stdout
listen-address "194.x.x.x" not assigned on any interface!
Leaving the resulting config tree functional, but the haproxy section completely empty. As nothing was changed in the cloud-init file, I’m pretty sure this is a regression on the VyOS side. It might also be some timing issue, as I’m not 100% sure the haproxy check looks at the device config or the actual interface. It is important to note, that setting it up like this also worked on the backup instances, which don’t get this floating IP set to their interface to begin with. I’d appreciate any help, as this blocks us from rolling out new images with all the good fixes for the latest kernel vulnerabilities
Interesting, I stumbled across your report, but didn’t grasp it could be related.
Your proposal seems sound. Question is where this check should be performed? I assume the existing (and used) function is_addr_assigned in utils/network.py should be modified to always return true when the according afi and sysctl is set. Is that doable? Where should the existence/value of the sysctl be fetched from?
Besides that, now that I tried to work around the issue by leveraging VRRP transition scripts, I’ve noticed haproxy by default listens to every interface (i.e. binds to *) when no explicit listen-address is set. However due to this behavior it is no longer possible to add a listen-address when haproxy is already running, as the on-commit check refuses to apply due to the port being occupied. For obvious reasons it should ignore the port being in use in such cases. The only solution for now is completely removing all haproxy config before reapplying all of it, which is very much suboptimal.
the one you encountered too, where the CLI validation code checks the listen-address IP, and (now) requires it to be assigned to an interface.
This issue could be worked around by checking if nonlocal_bind is active, and if so, skip that validation step.
the problem that haproxy (but also other services, I use Caddy as reverse proxy which has the same issue) are not able to bind to an IPv6 address, even if that is assigned to an interface, if that interface is down (no cable connected). They don’t have the same issue with an IPv4 bind on the same interface.
I had to connect the port to a not-in-use VLAN switch port to make it bind succesfully.
I’m not sure, as I’ve been using Linux since the mid '90’s, everything in our datacentre runs on Linux (albeit Redhat, not Debian), all dual-stack, and I’ve never experienced this issue.
So, as an example, if I have this config:
set interfaces ethernet eth3 speed auto
set interfaces ethernet eth3 duplex auto
set interfaces ethernet eth3 address 172.18.5.1/24
set interfaces ethernet eth3 address fdfd:dead:beef:cafe::5:1/112
and I have this haproxy config
frontend TEST
bind 172.18.5.1:3306
bind [fdfd:dead:beef:cafe::5:1]3306
It binds the IPv4 address just fine (and netstat confirms that) but I get a bind error on the IPv6 address. If the interface is down:
Jun 6 20:28:21 firewall haproxy[239985]: [ALERT] (239985) : Binding [/run/haproxy/haproxy.cfg:51] for frontend TEST: cannot bind socket (Cannot assign requested address) for [fdfd:dead:beef:cafe::5:1:3306]
I understand your issue, though I can’t tell where it comes from. If you never encountered issues with this on other Linux platforms, my guess about it not being VyOS must have been wrong.
