One of the things I've noticed recently in using OPNsense is that it's particularly labor-intensive to create a basic VLAN. I decided to measure how many clicks and keystrokes it actually takes, and it turns out for my flow it's:
- 26 mouse clicks
- 71 keystrokes
- 6 distinct dialogs
- 3 separate workflows
I shared more details and a full video of my VLAN creation flow in this post:
- Add a VLAN to OPNsense in Just 26 Clicks Across 6 Screens (https://mtlynch.io/notes/opnsense-clicks/)
OPNsense does have an extra layer of interface indirection ("lan", "wan", etc.) - it's a legacy element.
Do you have some ideas on streamlining the, uh, interface interface? It doesn't really bother me - it's an initial setup issue, and if I really want to monkey with it, I'll fight with an XML config.
This might best be part of a wider discussion about usability, which, in my opinion, is not necessarily the top priority in opnsense development.
I think more focus on this would be beneficial.
And how would you actually go about that?
I often pointed to the obvious fact that along with great flexibility and functionality, "easy going" for end-users goes out the window. I accept the fact that OpnSense is an expert tool.
As a simple example, take the fact that ISC DHCPv4 is a part of the initial rant (while that did not even include the firewal setup or IPv6). And at this point, we have no less than three (!) DHCP daemons, namely ISC, Kea and DNSmasq. Which would you choose if the process was indeed more streamlined?
The only approach I could imagine was a set of some kind of "helpers for common tasks", but these would have to be on top of the fine-grained settings menus. Also, they would be prone to break pre-existent settings, just because they have to be limited to default settings (which ones, BTW?) instead of the wide variety of potential settings.
I can already picture upcoming forum discussions about how the default X of helper Y "does not suit my needs, can we change it or at least make it selectable?".
I guess this mostly falls into the Macro/Wizard dicussion.
Technically a vlan, layer 3 interface and dhcp are different technologies. So the GUI does not intermingle them for maximum flexibility.
Since all new components are API enabled, crafty individuals could build their own workflows (e.g a script that does exactly what they want with all assumptions their environment requires)
These could also have their own GUIs as the plugin system is very advanced and can hook into existing models.
For more inspiration check out the new system wizard.
I agree that this is not the best case for a bad UI, in other firewalls you would also have to do a lot of clicking to achieve this result.
However I would like to see some UI streamlining for firewall rules and aliases.
Ideas that are in the mind is e.g. creating a new Alias while having a Firewall Rules dialog open, but for that to ever happen we have to follow the roadmap a bit further and push the "Firewall - Automation - Filter" component which is entirely MVC and was reworked a lot during the past year. It's soon going to be called "Firewall - Rules [new]".
GUI improvements take a long time to develop and test.
Basically what people are asking for is a setup wizard. We'll be extending the existing wizard with a few use-case type presets in 26.1 but nothing that resembles a non-first-time setup yet.
If this is viable then we can talk about extending this idea based on the new wizard structure, but you still need all the old pages if you ever want to go back and edit a specific parameter.
Cheers,
Franco
Not really a wizard, but I'm a big fan of being able to edit things in context, so edit or create an alias while having a firewall rule open - a good example would be the way the old Sophos UTM did it, or Fortinet does it now.
Quote from: bimbar on November 20, 2025, 10:23:25 AMNot really a wizard, but I'm a big fan of being able to edit things in context, so edit or create an alias while having a firewall rule open
I use tabs for that :-P
Its more like:
- You already half finished a firewall rule
- You notice you need a new alias
- You can add it in a different tab, but you have to save the rule and then edit it again and then add the alias
I mean yeah its a planning issue but it interrupts the workflow surprisingly often. I dont know if often enough to create complex dependencies to solve this, but it would be a "nice to have" if at least the available aliases in an open firewall rule would update.
Quote from: franco on November 19, 2025, 09:28:24 PMBasically what people are asking for is a setup wizard. We'll be extending the existing wizard with a few use-case type presets in 26.1 but nothing that resembles a non-first-time setup yet.
Not sure if this is in response to the blog post or subsequent discussion, but I think one of the important pieces here is that OPNsense in a lot of places asks the user to manually enter data when OPNsense already knows the answer:
- On the create VLAN device page, OPNsense insists the user manually prefix the name with vlan
- On the DHCPv4 page, OPNsense makes the user type the IP range assignment instead of defaulting to the full range of the subnet
I also feel like there are low-lift opportunities to improve the default options, like when the user assigns a static IPv4 to a VLAN, the default is a /32, when it feels like /24 is likely a more common choice. I think on a lot of these "whatever the user chose last time" would be a pretty good default.
> but I think one of the important pieces here is that OPNsense in a lot of places asks the user to manually enter data when OPNsense already knows the answer:
I don't agree and the past discussions are all over the forum and GitHub to read through. I don't enjoy starting at the "but what if we just did it this way". This is not how projects work when they span multiple decades in total.
Cheers,
Franco
If you're using clicks, you're not a modern OPs.
Its not a Windows Machine where you Click anything and hopefully not build a SecurityFlaw....
If you wan't to administer OPNSense over a modern Way (like API) I suggest to read the Manual.
There's a way to use the API for that (that's how I do it with versioning and a Git repo in my local Network only for this task).
It Takes 2-3 Minutes and voila a new VLAN is there.
Here's an Example on how to do it:
curl -X POST "https://OPNSENSE-IP/api/interfaces/vlan/addVlan" \
-H "Content-Type: application/json" \
-u "APIKEY:APISECRET" \
-d '{
"vlan": {
"enabled": "1",
"tag": "30",
"description": "LAN_Prod",
"if": "igb0",
"priority": "0"
}
}'
Its a simple curl Post Call with a json file:
| Field | Description |
| ------------- | ------------------------------------------- |
| `enabled` | 1 = enable VLAN |
| `tag` | The VLAN ID (e.g., 30) |
| `description` | Description visible in GUI |
| `if` | Parent physical NIC (e.g., igb0, igb1, em0) |
| `priority` | Optional (0–7) |
To verify:
curl -X GET "https://OPNSENSE-IP/api/interfaces/vlan/searchVlan" \
-u "APIKEY:APISECRET"
What exactly is your problem? Your statement doesn't make sense.
Quote from: franco on November 22, 2025, 09:05:07 AM> but I think one of the important pieces here is that OPNsense in a lot of places asks the user to manually enter data when OPNsense already knows the answer:
I don't agree and the past discussions are all over the forum and GitHub to read through. I don't enjoy starting at the "but what if we just did it this way". This is not how projects work when they span multiple decades in total.
What is the correct way for OPNsense customers to give feedback?
I've searched for Github issues and forum discussions, and I can't find any discussion about why the user is required to input a specific prefix name for VLANs or why OPNsense doesn't offer a default IP range for an IPv4 subnet.
I'm not arguing that my preferred flow is correct. I'm just giving a datapoint as an OPNsense customer of 4 years that this is really confusing and I don't see any reason for it. I get why in different scenarios, other OPNsense users might want something different than my expected defaults (e.g., defaulting the VLAN to enabled), but I have a hard time understanding why anyone would want to manually type a specific prefix into the UI when the UI already knows what it must be.
You summarized my feedback as me asking for a wizard, and I was clarifying that that wasn't entirely what I was saying.
QuoteIf you're using clicks, you're not a modern OPs.
Its not a Windows Machine where you Click anything and hopefully not build a SecurityFlaw....
If you wan't to administer OPNSense over a modern Way (like API) I suggest to read the Manual.
There's a way to use the API for that (that's how I do it with versioning and a Git repo in my local Network only for this task).
It Takes 2-3 Minutes and voila a new VLAN is there.
I have pretty simple needs, so the value of OPNsense to me is that it offers a web UI to cover my needs.
The example you shared doesn't seem to achieve the same thing I shared in the video in that it doesn't enable DHCP or assign an IP range. I'm sure I could do it with more scripting, but if I'm going to write custom code to manage VLANs, I feel like I'm probably better off using FreeBSD/OpenBSD and scripting on top of pf directly rather than try to manage pf indirectly through a thick OPNsense layer.
You dont have to input anything into the vlan field, the name gets auto generated if you leave it empty.
Quote from: mtlynch on November 22, 2025, 04:57:30 PMWhat is the correct way for OPNsense customers to give feedback? [...]
Personally, I think the forum is the place to start. Naturally, in an ideal world everyone would research their issue and incorporate prior discussion and work, but this isn't always realistic, for a number of reasons. For myself, I like to throw stuff out and get feedback, and then perhaps open an issue on github if I think it actually has merit. I try to see the legacy and direction of the project, but I don't always succeed, of course.
As far as your suggestions, they don't strike me as significant. That is, filling in some default values would make no difference to me, just as a lots of clicking and typing to set up a VLAN doesn't bother me. Oh, and I care little for/about wizards, and I'm not likely to use the API. My $.02, and worth every penny.
Quote from: franco on November 22, 2025, 09:05:07 AM[...] I don't enjoy starting at the "but what if we just did it this way". [...]
Understandable. All I can say is "Y'all keep up the good work", because occasionally I'm going to have this great idea that I can't believe y'all haven't considered...
> I try to see the legacy and direction of the project, but I don't always succeed, of course.
That's fair. I don't try to preach if I can and instead get to the technical side quickly, because ideas and actual patches can often differ in scope and complexity and person who has to carry it out.
Some discussions tend to sway to the wall-of-text postings, which usually means someone else should do the work. I'm not judging, but also blunt enough to say it's not going to be me either.
Cheers,
Franco
Just chipping in my 2 bits --
While there are a lot of places where Opnsense's web UI could be improved or re-worked, IMO ALL of that sort of intention to polish and optimize the UI/UX -- 100% of it, every last bit -- is secondary, possibly even tertiary, to the reasons I use Opnsense in the first place:
• Stability
• Broad feature set with fine-grained configurability
• Frequent security updates.
Just continuing to keep the above 3 priorities fully-realized, as I believe they are now, is enough to keep me satisfied going forward.
Granted, ones's use case does influence such an opinion. That is to say as a small-time user who runs 3 small separate site networks on Opnsense, I probably only touch firewall rules, VLAN & interface assignments, etc. a few times a year, and when I do, all I care about is that they continue to work as-expected and reliably, regardless of whether it takes me 8 clicks or 58 clicks to make a change.
If I was a network admin in a enterprise setting, configuring one more new Opnsense instances a week, I might have a stronger wish for UI/UX polishing.
(*cough* that said, it sure would be nice to be able to copy-and-paste firewall rules between interfaces, say, by ticking the rule-selector checkbox and clicking "copy to Interface X"... although, thinking that through further, it might grease the rails overmuch towards people making broadly insecure and/or breaking changes to their firewall rule sets.)
Quote from: johnmcallister on November 23, 2025, 08:56:02 PM*cough* that said, it sure would be nice to be able to copy-and-paste firewall rules between interfaces, say, by ticking the rule-selector checkbox and clicking "copy to Interface X"...
Click the "duplicate" symbol to the right, change interface in the opened rule edit dialog, possibly change some more things like source from "interface1 net" to "interface2 net", save, done. The UI will even take you to the "interface2" rules instead of where you started.