Messages

I've opened a feature request with the details (validation helper, the open-core changes, and the two Business Edition controller inserts described by file/method): https://github.com/opnsense/core/issues/10433

Brilliant! Thank you so much.

Thank you Marco.

When using OIDC and wanting to automatically create users, is it possible to make user creation require the existence of a specific group returned by the OIDC server?

As far as I can tell at the moment the user will be created if authorisation succeeds regardless of group configuration, leaving no way to restrict access to a specific set of users without putting an auth proxy in front of the firewall.

If OPNsense could check for the existence of a group and deny authorisation if the user is not a member of that group it would make OIDC quite a lot easier to use in situations where there are multiple people/teams who require access.

Thanks.

Thank you Marco & Franco.

If I have time to create the feature request I'll let you know here.

With password login if someone clicks on a URL like

Code Select Expand

https://my.opnsense.fw/ui/auth/user when not logged in they can log in and the correct page will load after they authenticate.

With OIDC, it seems as though the path is ignored and whatever the original URL was the user gets redirected to the dashboard after authenticating.

Is this a configuration error on my end, or is there something missing in the auth flow here?

Thanks.

This addresses the notification requirement, but the lifecycle management problem remains.

I'll leave this as a plea for Deciso: as your commercial support offering matures, please prioritize moving to a more typical release model which provides a short period of security updates for the previous release after a potentially breaking update drops. A minimum of 6 months is usually reasonable, to allow for scheduling and testing.

Business edition releases happen every 6 months so I'm not sure that timeframe is realistic.

The current situation dilutes the stability value of the subscription model, as it creates a scramble and an unavoidable gap in compliance and exposure twice a year.

What's the compliance gap for you?

For me, the thing I'd like to see is assurance that intermediate releases won't require a reboot and that being behind on a hotfix release won't prevent package operations in the GUI until the hotfix is installed.

Working through change control etc. and doing an upgrade is fine every six months, but having a hotfix or other release come out right afterwards and require another service-impacting upgrade is a gigantic PITA.

Right, that makes perfect sense, thank you.

I've been configuring multiple firewalls that need to be identical recently and I got curious.

What is the purpose of abstracting OS interfaces to OPNsense's 'optN' interfaces, vs. using the OS names directly?

Thanks.

Does anyone have a working setup using the os-OPENWAF plugin to reverse proxy the web GUI?

No matter what I try I just get a 'Forbidden' page.

There is excellent and extensive documentation for doing this with Caddy, but the documentation for os-OPENWAF is a lot less comprehensive.

Thanks.

Why don't you set it to 0, then? You can add arbitrary tunables from the UI.

I do now. I don't think I should have had to deal with firewalls going offline and requiring remote hands to diagnose the issue and reboot to figure out I needed to do that though.

Requires onsite visit? Do you mean to be able to do "reboot" from the console, or recycle the power?
If that's the type of remote location it is, then maybe some form of out-of-band console access should be there?

Or, set that option to 0, and still evaluate OOB access.

Yes, it requires someone to be on-site to do a reboot from the console.

It's fine to have this feature available in the event that someone is experiencing persistent problems and needs debug information but there's no way it should be the default on a production firewall. The FreeBSD hadnbook even says this outright.

Brilliant, thank you.

[Services: Caddy: Reverse Proxy]

Mostly posting this for the search. The explanation and solution is in https://forum.opnsense.org/index.php?topic=51150

If you have a setup where you use OIDC and your web GUI is behind Caddy reverse proxy, the upstream change to Caddy will break OIDC because the OIDC provider will see the redirect_uri as being https://localhost:8443/api/oidc/rp/finalize/Keycloak which is obviously invalid.

Adding the {host} header fixes it.

Services: Caddy: Reverse Proxy -> 'Headers' tab and add the header per the linked post.
Services: Caddy: Reverse Proxy -> 'Handlers' tab, edit your reverse proxy handler, go to Transport > HTTP Headers and select your custom header from the dropdown.

Apologies Franco, I completely missed that you'd replied.

Thank you for the fix.

I've applied that extension on my test firewall and it does prevent the API key from being overwritten.

It does leave the 'Users and groups' section always marked as out of sync though.

Thanks again.

Thanks Franco.

The issue that's bitten me a couple of times now doing upgrades of Business Edition at a remote office is something triggers a kernel panic on reboot, the firewall drops to KDB and just sits there until someone can physically access the console and restart it.

For a production firewall I would far rather have it auto reboot after 15 seconds

The Kernel Debugging chapter of the handbook says:

The third way is that any panic condition will branch to DDB if the kernel is configured to use it. For this reason, it is not wise to configure a kernel with DDB for a machine running unattended.
To obtain the unattended functionality, add:

options    KDB_UNATTENDED

to the kernel configuration file and rebuild/reinstall.

In the Glossary it says:

options KDB_UNATTENDED: change the default value of the debug.debugger_on_panic sysctl to 0, which controls whether the debugger is entered on panic. When options KDB is not compiled into the kernel, the behavior is to automatically reboot on panic; when it is compiled into the kernel, the default behavior is to drop into the debugger unless options KDB_UNATTENDED is compiled in. If you want to leave the kernel debugger compiled into the kernel but want the system to come back up unless you're on-hand to use the debugger for diagnostics, use this option.

I see DDB and KDB options in the kernel, but not KDB_UNATTENDED.

I'll submit a feature request to add this.

Cheers.