how to create floating (and group rules) after migrating to new firewall rules?

[defaultuserfoo]

I've seen the new rules being there since quite a while, and I didn't want to update.

Then why did you ??

Because these assumptions :

But it looks as if it won't be long before the so-called 'migration assistant' will be gone and you'll suddenly find yourself without a way to switch after an update.

Yes, what else are users supposed to assume?  Assuming something else
would be unreasonable and contradict all experience.  Software changes
fast and all the time.

I already had waited an uncomfortably long time before switching to
the new rules.  I didn't expect a total disaster.  For at least four
years now I've seen opnsense working great.  Despite all the many
updates of several machines, nothing went wrong.  That's quite an
accomplishment.  The developers have done an outstanding job.

So what was I supposed to expect?

Is there a way to switch from DHCP to kea yet?  When will DHCP be gone?  It would really suck if we had to convert everything manually.

Are simply NOT TRUE !!

That's not an assumption but a question.  I'd gladly switch if I
wouldn't have to transfer all the information painstakingly and error
prone by hand from ISC DHCP to kea.  Maybe there will be a 'migration
assistant'.

Moving from ISC to either KEA or DNSmasqd has been discussed in
multiple topics by now which you can find in the 25.7 and 26.1
sections or just use the Forum Search ;)

Again, I don't come to the forum unless I can't avoid it since I was
told to stay away.  The search isn't really helpful.

I just checked the documentation.  It 'strongly suggests' to switch
--- so I'm not wrong this either.

But why doesn't the documentation say when DHCP will go away at the
same place where it tells you to switch?

IMHO it's not that complicated, but you need to know what you are doing, so please also read the information @ https://docs.opnsense.org/

Ok where does it say when DHCP will be gone?  Does 'strongly suggest'
mean it'll be gone soon?  When is 'soon'?

I admit that I don't want to read all the documentation.  It's a lot
to read and I'm assuming that the information is probably not in it
anyway.

Why would developers want to let us define firewall rules on a concept that doesn't exist?

They don't and making such statements isn't going to get you much help from them either...

You misunderstood what I was saying.

I don't understand why group rules would have to be in a specific order, i. e. between floating rules and interface rules.
I can understand that they can be useful in the way I'm using them, but that isn't a good way at all and only due to a lack of better alternatives.

AFAIK it's explaned @ https://docs.opnsense.org/ and you can see there that they all have what are called 'Sequence Numbers' if I am not mistaken :
10000
20000
30000
40000
etc.

Right, and I understand that the rules are numbered so the rules can
easily be sorted by the numbers.  I also understand why the rules
need to be in a desirable order.

That doesn't explain why the rules would have to be in a specific
order.  When a user moves a rule, the rules need to be renumbered
anyway to bring them into the order the user desires them to be in.

So why do group rules have to be between floating rules and interface
rules?  Just renumber the rules according to where the user moved a
rule to so they can be brought into the desired order.

Use just these numbers or create some kind of hybrid between the current system and them...

This is the same question: Why do the rules need to be in a specific
order which then can be different from the order the user may want
them to be in?

'Floating' seems like a kinda random term for the rules that get applied first.
You could as well, or better, call floating rules, group rules and interface rules first rules, second rules and third rules, respectively.

Actually the current system makes a lot of sense to me, but as with everything : You need to read the documentation and get used to new things!

Do you mean the old rules or the new?  There are currently two systems.

Now I do have to admit that I did not do that for a lot of OPNsense things because I knew what I was doing from the start, but for some things you simply have no other choice and IMHO it's not something to complain about either...

I'm not complaining, I'm merely questioning why there is no other and
possibly better choice.  IMO having to create overkill rules isn't a
good design and there's currently no other choice with the new rules.
Or is there?

Perhaps with the new rules, I could omit the floating rules and the
group rules and instead put a whole bunch of interface rules to block
all traffic between all interfaces after allowing what needs to be
allowed.  That would be much worse in that it would be a lot of rules
and very error prone.  Interface groups are very useful.

It's only the inability to put the rules into the desired order that
forces users to make overkill rules.  Change that and there wouldn't
need to be overkill rules.

I always read the notes that are being shown when I'm about to update.  I don't recall any mentioning of the new rules at all, though my memory isn't what it used to be.

Yet if there had been a suitable warning about the new rules like I suggested in my previous post, I would have remembered it.

The message that appears after checking for updates clearly displays it : Your choice to read it or not.

No it doesn't.  The message didn't say not to use the so-called
migration assistant and didn't say that the firewall rules will be
screwed up when using it.

I usually don't look into the forum.  One of the moderators drove me away by telling me to stop posting when I was trying to help, so now I only come here when I can't avoid it.

Sorry you had to go through that...

I know the feeling : I left a forum last year that I was a member of since 2002 because of the same reason!

It's ok; I told him that I'm happy to help, especially when I'm
getting help myself, and that I have no need to spend my time on doing
that.  I have plenty other things to do, and when it's not wanted I'll
just stop.

Generally, I'm done helping, done making bug reports, done
contributing, done asking questions.  It's not wanted and usually
results in being insulted and/or censored or blocked, and almost never
gets any useful answers.  There are few exceptions.  The internet
keeps getting more fiendish and unfriedly all the time and is way past
any reasonable limits in regards to respect and simple decency.

I remember different times.  Just sometimes it can't be avoided to ask
questions.

Besides, people are taking way too long to figure out what I'm saying.

I clearly remember the advice and warnings in the documentation on 26.1, before I tested then fully migrated without issue.

Yep! :)

Which documentation was that?  Like I said, I can only go by what is
being presented when I'm updating, not by posts hidden in some forum
I'm not even supposed to look at.

When you have warnings to give, present them to the users where they
see them.

In general terms, my advice is first allow what you must, then block the rest.

Actually a Firewall should always be : Block First then Allow what you need to allow.

Hm.  Good point.  Ok.

How do you do that?

To give you a simplyfied example:


Suppose you have a setup with a WAN interface, a LAN interface and a
GUEST interface.  Both LAN and GUEST networks are private networks
meant to allow internet access for clients through the WAN interface.
They both have IPv4 and IPv6 enabled, but unfortunately you don't have
a static IPv6 prefix.

You want to block all traffic between the LAN and GUEST network.

You also have a SERVICE interface that also has IPv6 on its network,
and IPv4 in another private network. You have an XMPP server on the
SERVICE network.  Clients on LAN and GUEST networks need to
communicate with the XMPP server on the SERVICE network.


When you design your firewall to first block all traffic, then how do
you allow traffic between your server and the clients on the LAN and
GUEST networks?  Keep in mind that you can't tell what IPv6 address
your server will have, and that its IPv6 address keeps changing.

OPNsense does this too : When you create a new network there is no Internet access at all : It's blocked.
_{(This is simply put ofcourse. We all know it's not exactly like that, but most people experience it like that!)}

Right, that's not how it works.  It's not unreasonable to assume that
a lot of people have a guest network and don't want all their guests
to be able to access their workstations on the LAN because there is no
way to block the IPv6 traffic when you don't have a static IPv6
prefix because you don't know what you need to block.

Maybe not so many have an XMPP server but some may have some
installation of homeassistant (though XMPP is great for automation)
...

If everything goes soo wrong that I need to reinstall : So be it! :)

You wouldn't have much choice.  However, that can get pretty
expensive.

Maybe it's you that are handling this badly?

Hate to say it, but that's probably the case here...

No, it's not.

[defaultuserfoo]

Most migrations happen automatically under the hood without user interaction.

For firewall rules an automatic forced migration would have been far worse than an optional one.

After an upgrade nothing is broken, everything is 100% transparent. You can even compare old and new ruleset before deleting the old rules.

We did the right approach here, your reaction shows nothing would have been appreciated except 100% perfection. But thats not feasible because whatever we would have done, some concepts would have been lossy one way or another.

Having an optional instead of a forced migration is great for the user.

You are putting words into my mouth :(

I've said nowhere that the switch should have been done automatically and that I would expect 100% perfection.  I have also not said anything about wether doing it automatically or manually would be a wrong or a right approach.

I have said, and I keep saying so, that it has been handled badly because there is a lack of information, warning and documentation about this switch.

Why don't you just change that instead of falsely blaming me?  It's really easy to do.

[defaultuserfoo]

Most migrations happen automatically under the hood without user interaction.

For firewall rules an automatic forced migration would have been far worse than an optional one.

After an upgrade nothing is broken, everything is 100% transparent. You can even compare old and new ruleset before deleting the old rules.

We did the right approach here, your reaction shows nothing would have been appreciated except 100% perfection. But thats not feasible because whatever we would have done, some concepts would have been lossy one way or another.

Having an optional instead of a forced migration is great for the user.

You are putting words into my mouth :(

I've said nowhere that the switch should have been done automatically and that I would expect 100% perfection.  I have also not said anything about wether doing it automatically or manually would be a wrong or a right approach.

I have said, and I keep saying so, that it has been handled badly because there is a lack of information, warning and documentation about this switch.

Besides, if something was handled badly or not doesn't have necessarily have to do anything with picking the right approach or not.  You can pick the right or the wrong approach and still handle it badly or well regardless.

Why don't you just put better information and a warning on the page of the migration assistent so anyone who considers using it doesn't think it'll be an easy transition instead of falsely blaming me?  It's really easy to do.  It's not necessary to make a big deal of it.  Just do it.

[Monviech (Cedrik)]

Don't victimize yourself now, you started with strong emotional arguments and throughout this thread people have pointed out technical and documentational arguments why it's not the way you are laying it out to be.

We can all write as much as we want if nobody reads it.

I will not respond here anymore.

We can react in a github issue that outlines whats wrong and what is expected to change.

Shuffling some words around will likely not do much if people do not read changelogs before updating.