TLDR; how do I add a default matching rule that won't be overwritten when the GUI adds a new manual user?
Long story
short slightly longer:
I'm on OPNsense 20.1.9-amd64 with modern UniFi APs and FreeRadius plugin to offer very basic RADIUS auth setup, plus Cisco 3560 switches with VLANs tagged on my PoE WiFi switchports to use multiple VLANs on the same AP / SSID. I migrated back from a UniFi USG Pro and I couldn't be happier. Here's my WiFi connection flow:
- User WiFi devices connect with the WPA-PSK password
- then offer $MACADDRESS / $MACADDRESS as user / pass
- clients (my APs) are configured in the "clients section" of FreeRADIUS to use its auth
- a user is matched from the config (as entered in the GUI), mapped to their defined VLAN
- OR (via my manual entry), a DEFAULT user rule matches anyone else with the correct WiFi PSK and maps to a default VLAN with restrictions
Everything works nicely.
I'm managing known users in the GUI, but I need this default rule in the `users` file too,
/usr/local/etc/raddb/users, symlinked from
/usr/local/etc/raddb/mods-config/files/authorize:
DEFAULT Auth-Type := Accept
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = 123,
Framed-Protocol = PPP
When inserted manually (and I restart FreeRadius using the arrow "refresh" button at the top of the GUI), this gives the desired result... but gets overwritten when the GUI adds a new specific user (and I click APPLY to add that user).
Is it possible to use the GUI and still include a static rule such as this one? If so, where? I can't determine how the `users` file is actually being built. The `hints` file has some similar rules to the defaults at the bottom of `users`, but adding this to `hints` doesn't make it show up in the `users` file.
I'm looking to accomplish any of these:
- Understand the way the file is constructed when the "APPLY" button is clicked in the GUI and add my DEFAULT rule into a template that will put it in place
- Understand where the back-end users are parsed if it's possible to add this in that format as a default rule to be added at the time of build (the config file contains user/pass of each client, but doesn't appear to contain the verbiage to regenerate my default rule)
- Or... I might need to find another iteration of RADIUS that I should be using if this isn't possible. This is my first rodeo with RADIUS, so I just need to know if the OPNsense plugin is limited, where another version would make this easy
I figured it out so I wanted to share, in case someone else is stuck on the same thing.
I added it this file. Take a look at the contents at the very bottom (you'll see it's the same block that's added to the users file when you apply changes in the GUI):
/usr/local/opnsense/service/templates/OPNsense/Freeradius/users
And it now generates into the bottom of the users file here automatically every time:
/usr/local/etc/raddb/users
{% endif %}
DEFAULT Auth-Type := Accept
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = 11,
Framed-Protocol = PPP
## I added the one above. The ones below are defaults and were here already at the install
DEFAULT Framed-Protocol == PPP
Framed-Protocol = PPP,
Framed-Compression = Van-Jacobson-TCP-IP
DEFAULT Hint == "CSLIP"
Framed-Protocol = SLIP,
Framed-Compression = Van-Jacobson-TCP-IP
DEFAULT Hint == "SLIP"
Framed-Protocol = SLIP
{% endif %}
Manual users added via GUI get a VLAN assigned, per their entry. Default users end up in the restricted VLAN.
I suspect this won't survive a plugin upgrade, but it's nice to know where to make the change.
Hi,
Nice to see you figured this out. A more permanent workaround is:
https://docs.opnsense.org/development/backend/templates.html#target-overwrites
But keep in mind that using static configuration with the plugin leads to friction sooner or later. Our recommendation is to not use the plugin (deinstall plugin but reinstall freeradius3 package) and configure the service by hand as you would on any UNIX system.
Cheers,
Franco
Perhaps a feature request would be two GUI blocks that would generate before and after the configured `users` sections? (Textarea input from GUI stored as a non-parsed block of text in the DB / as a random addendum file).
The answer I stumbled across most when researching this was "stop using the GUI and configure it by hand," which completely negates the simplicity of a one-stop product.
Respectfully, if the answer is "don't use the GUI," my suggestion might be "add this feature into the gui?" Then again, I guess I can submit a PR myself if I'm that passionate about such an idea. ;)
You are quite right on all of this.
We do not allow custom fields for security and stability reasons. Our philosophy has always been implementing a proper feature and avoiding the custom glue in the configuration as it may deprive the GUI from useful features now or in the future as less advanced users will not use it and the more advanced achieve their goals away from the community.
The solution to not use the plugin is a last resort if the plugin is getting in the way more than it should. The plugin certainly wasn't aimed at disrupting a workflow. It was designed to automate it.
A feature request on GitHub is the best way forward indeed and recommended in general as a number of responses in the forum already indicate. :)
https://github.com/opnsense/plugins/issues/new?assignees=&labels=&template=feature_request.md&title=
Cheers,
Franco