Forum thread with a nice workaround by giuppo77: https://forum.vyos.io/t/wan-failover-with-dhcp/
Not a generic solution but maybe an inspiration for implementation.

Forum thread with a nice workaround by giuppo77: https://forum.vyos.io/t/wan-failover-with-dhcp/
Not a generic solution but maybe an inspiration for implementation.

Link to forum thread: https://forum.vyos.io/t/output-similar-to-packet-tracer/

@Viacheslav tested and confirmed fixed in RC2.

I take it RC2 will contain these new versions @Viacheslav?

Seems you're right @indrajitr:

See also forum thread @ https://forum.vyos.io/t/grub-menu-fails-to-load-on-serial-only-devices-with-no-kvm/

That looks better:

        chain VZONE_LOCAL_OUT {
                oifname "lo" counter packets 387 bytes 33672 return
                oifname "bond0.40" counter packets 14 bytes 496 jump NAME_LOCAL_TO_ALL
                oifname "bond0.40" counter packets 0 bytes 0 return
                oifname "bond0.70" counter packets 0 bytes 0 jump NAME_LOCAL_TO_ALL
                oifname "bond0.70" counter packets 0 bytes 0 return
r packets 0 bytes 0 jump NAME_LOCAL_TO_ALL
                oifname { "bond0.7", "bond0.30", "bond0.90", "bond0.88" } counter packets 0 bytes 0 return
                oifname { "eth0", "pppoe0", "eth1.281" } counter packets 3 bytes 180 jump NAME_LOCAL_TO_ALL
                oifname { "eth0", "pppoe0", "eth1.281" } counter packets 0 bytes 0 return
                oifname "bond0.80" counter packets 2 bytes 80 jump NAME_LOCAL_TO_ALL
                oifname "bond0.80" counter packets 0 bytes 0 return
                oifname { "bond0.1", "podman-cntr-net" } counter packets 2 bytes 128 jump NAME_LOCAL_TO_ALL
                oifname { "bond0.1", "podman-cntr-net" } counter packets 0 bytes 0 return
                oifname { "wg0", "vti0", "vtun0", "podman-ts-net" } counter packets 0 bytes 0 jump NAME_LOCAL_TO_ALL
                oifname { "wg0", "vti0", "vtun0", "podman-ts-net" } counter packets 0 bytes 0 return
                counter packets 0 bytes 0 drop comment "zone_LOCAL default-action drop"
        }

Thanks, I'll wait for the merge and test the new iso ASAP.

@n.fort Unfortunately, I'm hitting an issue with traffic sent from the router itself.
Running 1.4-rolling-202311021131.
Interfaces eth0 and pppoe0 are WAN. Interfaces bond0* are LAN.
For example, running dig google.nl @9.9.9.9 from the VyOS CLI will fail. The kernel log says:

@Viacheslav @n.fort Regarding https://github.com/vyos/vyos-1x/pull/2388: I just tested on 1.4-rolling-202311021131: ZBF config from 1.4-rolling-202304120317 loaded without a hitch.
This is a 8 zone, 959 line config.

@Viacheslav confirmed working.

@Viacheslav Confirmed fixed, thank you.

In T4362#146398, @Viacheslav wrote:

@marc_s Will be fixed in the next rolling release, could you check?

Thanks @Viacheslav will test ASAP, next week I have a maintenance window, will let you know.

@Viacheslav Confirmed, that is the culprit.
To be precise: I deleted ipsec-dhclient-hook and renamed 98-vyatta-dhclient-hook back to vyatta-dhclient-hook. Then I ran a renew dhcp interface eth0 and I got a correct .lease file.
Even when the IPSec script is fixed, it might be wise to prepend all scripts in /etc/dhcp/dhclient-exit-hooks.d with a number to enforce script order execution, just like in /etc/dhcp/dhclient-enter-hooks.d.

@Viacheslav I may be on to something. It's related to the order of execution of the DHCP client exit hook scripts in /etc/dhcp/dhclient-exit-hooks.d.

Also see https://forum.vyos.io/t/1-4-rolling-route-table-for-wan-load-balancing-not-created/.

Thanks @Viacheslav https://github.com/vyos/vyos-1x/pull/1838 fixed it for me.

Same problem here, on 1.3:

@c-po confirmed fixed, thank you.

@pasik please see https://github.com/vyos/vyatta-cfg-system/pull/191

TLDR; confirmed fixed for 1.3, please backport.

Brilliant, thanks @c-po!

@c-po I see that you've marked this as resolved, but I don't see any comments (maybe I'm doing something wrong). I'd appreciate some feedback.
Is it resolved as in: will be fixed as soon as third-party code is fixed? Or have you made changes to the code to mitigate?