You are right - I wonder why it didn't work when I tested it back then. (Most likely I forgot to write "comment")

So most likely we will have to find another implementation.

I just did a quick search - it doesn't seem like dnsmasq supports option 82 when acting like a relay.

They switched to the OpenBSD fork of dhcrelay (I still have a router running OPNsense to test some stuff) 🙂

While I do somewhat agree on that, having more than one to choose from, for everything, is going to be a maintenance nightmare.
If you have just 5 things with 2 packages to choose from, you already have 32 different combinations to support.
Having something else than everyone else sounds great, but again, people are not going to switch due to a vuln being found - they are going to push for a fix for it instead.

Depending on how BSD dependent the OpenBSD one is, that might be the easiest drop-in replacement.
Otherwise I would suggest going for dnsmasq, since it is quiet small and well maintained. (not saying the other projects aren't being maintained, but I don't know about them)

I just built and tested with the latest sagitta commits, and it is preventing it now as expected.
So I would say it can be closed as fixed, since it has been fixed some time between November and now.

Great 😃

Just wondering - is it possible to add a vti interface to a zone in the firewall?
How would one go about using this with the zone based firewall? 🙂

I just did a test - without the VLAN interfaces added, the VLAN traffic is still offloaded.
So the CLI should be updated to prevent VLAN's from being added (since it doesn't make any sense to add them, since they work when the parent interface is added)

The issue is only on boot, if after booting you run the load command, it loads fine and commit works without any issues.

Booting now gives this:

Just thinking aloud - could it be the period that is causing issues with the loading?

Mounting a ram disk on top should be pretty easy.
The question is, how much ram should be allocated for this, and how to make sure it doesn't run out of space.
I am no expert in logrotate, but it sounds like it should be able to do it.

In T5775#168092, @marvin wrote:

Excellent; thanks @GurliGebis! I built 1.4 today and confirmed it's working as expected.

As far as I'm concerned, this issue is now resolved and the ticket can now be closed.

Pull requests for 1.4 backport: https://github.com/vyos/vyos-1x/pull/2641

I have implemented this - PR: https://github.com/vyos/vyos-1x/pull/2638

I have create a PR for backporting this to 1.4 : https://github.com/vyos/vyos-1x/pull/2597

@n.fort I have a branch with a backport of this for 1.4 (needs manual changes).

Backport to 1.4?

I agree, without it, you end up repeating yourself alot, with the established, related and invalid rules.
As long as they are applied before the zone specific rules (which is how I guess it used to work), it makes sense.

Can this get backported to 1.4?

Hey @fernando - yes, I tested it with two routers in a test environment, with the following setup: https://docs.vyos.io/en/latest/configuration/vpn/site2site_ipsec.html

PR: https://github.com/vyos/vyos-build/pull/457