Alias based firewall rules doesn't work after upgrade to 22.1.8

[RedVortex]

I have about 30 aliases and even though I haven't tested them all, I tested at least half of them without issue. But since I use them a lot, I'm watching this issue very closely as it would affect my setup a lot.

I have a few questions:

1 - Does this happens to every type of alias ? (Hosts, networks, ports)
2 - How many items do you have in the alias content that fails ? (3 IP addresses or 1 network or 4 ports for instance)
3 - If you have only one entry in the alias can you add a second item in the content (even if bogus) just to see if this happens only on aliases that have only 1 entry or more (All my aliases seems to work but they all have more than 1 entry)

[DavidGA]

This was broken for me too, and it broke a lot of stuff. There were a bunch of new aliases in the aliases view that started with an underscore that I'd never seen before. I wish I'd taken a screenshot, sorry. I reverted to 22.1.7_1 and rebooted and it's fine again. All the new aliases have disappeared.

[DavidGA]

It turns out I had an old stale browser tab open from before I did the downgrade so I was able to snag this screenshot.

All the aliases that start with an underscore I had never seen before. They look like internal stuff that wasn't supposed to be visible?

[Marin BERNARD]

This is just awful. Since some months, every couple of updates bring some kind of bug. This, added to the lack of proper release notifications (no mailing list, no GitHub releases, just a forum thread which cancels your subscription on any new release) make OPNsense quite unusable in demanding environments.

We deployed it to power schools and care centers; we've got tens of instances dispatched in many small sites on a wide area. I can't imagine losing access to all those distant sites because someone did not take the time to test the changes to such a critical feature as aliases.

I'm sure someone will soon answer me that we've got no right to complain since this is a free product, that quality assurance has a cost, and we should pay for professional support. OK, seems fair. But giving us nightmares every 2 months is not the best way to engage new customers. Since OPNsense is a free product, we do expect some bugs. We are prepared to handle proxy failures, unbound config errors (only a few weeks ago; another sweet memory), API bugs, et al. But certainly not empty aliases making 80+ instances unreachable in the middle of a week off.

[mannp]

This was broken for me too, and it broke a lot of stuff. There were a bunch of new aliases in the aliases view that started with an underscore that I'd never seen before. I wish I'd taken a screenshot, sorry. I reverted to 22.1.7_1 and rebooted and it's fine again. All the new aliases have disappeared.

The same situation for me... I have circa 100 aliases, and it was hard to tell which were broke and which were okay.

It appears a lot was broken though, no internet on the few vlans I tried, and editing and saving aliases didn't work for me, although I did only try a dozen of what I thought were the key ones....with no change.

I, too, had the additional ones with underscores too.

Got to say, my updates have been flawless for many months, but this certainly got me to document the recovery plan better :)

[AdSchellevis]

...This, added to the lack of proper release notifications

• https://docs.opnsense.org/releases/CE_22.1.html#may-25-2022
• https://forum.opnsense.org/index.php?topic=28492.0
• https://twitter.com/opnsense/status/1529391333852471297

...We deployed it to power schools and care centers; we've...

Which is a vey good reason why you should at least test our development versions before their being merged, their available at every release included in the exact same version as you're installing now.... The alias additions have been in there for a couple of cycles now.  (https://docs.opnsense.org/manual/firmware.html#settings)

I'm sure someone will soon answer me that we've got no right to complain since this is a free product...

Sure you do, it just doesn't bring much to the table when not thinking about how to help out from your end as well.

...started with an underscore that I'd never seen before

It's a new feature collecting the networks attached to an interface so we can reuse these later in the "xxx_network" rules. This increases visibility and also offers the possibility to "nest" and combine these into derivatives.

A full list of added features is in this merged pull request https://github.com/opnsense/core/pull/5668.

[abulafia]

Only issue I noticed is that the crowdsec aliases remain empty. That may be a crowdsec issue of course.

[marin]

...This, added to the lack of proper release notifications

• https://docs.opnsense.org/releases/CE_22.1.html#may-25-2022
• https://forum.opnsense.org/index.php?topic=28492.0
• https://twitter.com/opnsense/status/1529391333852471297

Yes, I know detailed release notes are published with every release; I routinely read them, but often after the instances were updated (by cron). My point was about release notifications, i.e. being notified when a new version is released, via GitHub, a mailing list, or anything. I suppose Twitter is fine for many people, but I don't use it.

...We deployed it to power schools and care centers; we've...

Which is a vey good reason why you should at least test our development versions before their being merged, their available at every release included in the exact same version as you're installing now.... The alias additions have been in there for a couple of cycles now.  (https://docs.opnsense.org/manual/firmware.html#settings)

Yes, this is something I'm considering, and/or maintaining a private update mirror and only pushing upgrades after they've been tested.

I'm sure someone will soon answer me that we've got no right to complain since this is a free product...

Sure you do, it just doesn't bring much to the table when not thinking about how to help out from your end as well.

Of course not... Sorry for the rant.

...started with an underscore that I'd never seen before

It's a new feature collecting the networks attached to an interface so we can reuse these later in the "xxx_network" rules. This increases visibility and also offers the possibility to "nest" and combine these into derivatives.

A full list of added features is in this merged pull request https://github.com/opnsense/core/pull/5668.

Are those internal aliases excluded from the JSON import/export feature ? We use it internally (via the API) to propagate alias changes to sets of nodes, and we don't want to overwrite those internal aliases on remote nodes  :-\

[chemlud]

This was broken for me too, and it broke a lot of stuff. There were a bunch of new aliases in the aliases view that started with an underscore that I'd never seen before. I wish I'd taken a screenshot, sorry. I reverted to 22.1.7_1 and rebooted and it's fine again. All the new aliases have disappeared.

I can help you out with a screnshot of 22.1.8, the underscore aliases are the internal networks, type is shown as "Internal (automatic)", appears to be benign...

[AdSchellevis]

Are those internal aliases excluded from the JSON import/export feature ? We use it internally (via the API) to propagate alias changes to sets of nodes, and we don't want to overwrite those internal aliases on remote nodes  :-\

They are in the export, but I don't mind omitting them in a future version. I don't expect much will happen when you do import them anyway to be honest.

[myksto]

I can confirm the same problem with some aliases. Especially I did have problems with network aliases (e.g. 192.168.20.0/24). Everything started working again after reverting to version 22.1.7_1.
I hope developer team can solve it in newer versions.

Have a nice day,
Michele.

[RedVortex]

Do you guys have any error when you run this ? (Make sure you are on 22.1.8, not a previous version...)

Code Select Expand

/usr/local/opnsense/scripts/filter/update_tables.py

I'm still trying to figure out why I'm not affected by this and so many others are.

[muchacha_grande]

Apparently I'm not affected by this problem. As @RedVortex.
Running update_tables.py returns {"status": "ok"}

[diekos]

I'm also affected by this bug.
It seems to be only with network and ports aliases, host aliases are not affected and still return the valid results under Diagnose > Aliases.

The Geo aliases are still filled with networks, so those seem to work as well.
The Spamhaus aliases are also still filled so remote aliases seem to work.

Ports aliases don't even show up under diagnose > Aliases.

Running the update_tables.py gives the result "Ok" but no changes in the aliases.

[franco]

The hotfix was published now. Took a bit longer due to national holiday getting in the way.


Cheers,
Franco