Recent posts

Pages1 2 3 ... 10
#1
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by LisaMT - Today at 02:47:30 AM
My system crashed today.  Thanks for all the notes on here.  I disabled the hostwatch and logs and it's running again. 
There should be some indicator on the dashboard that monitors disk usage better.
#2
26.1 Series / Re: Firewall rules migration
Last post by meyergru - January 22, 2026, 11:54:40 PM
Some of this was already discussed here. There are a few more glitches with the migration...
#3
26.1 Series / Firewall rules migration
Last post by julsssark - January 22, 2026, 10:57:18 PM
Thank you devs for the hard work that went into 26.1! It's going to be a great release and I am especially looking forward to the new rules interface. I have some feedback to share based on my initial testing of the rules migration. Please take my comments in the helpful spirit I intend:

  • Anti-lockout instruction clarity: The instruction text says "enable the anti-lockout rule" while step 2 says "Deselect anti-lockout in advanced settings." Given the wording of the control itself ("Disable anti-lockout"), I suggest revising the instruction text to: "To prevent being locked out during the rule migration process, enable automatically generated lock-out rules..." and updating step 2 to: "Uncheck the 'Disable anti-lockout' checkbox."
  • Import rules dialog: The dialog would be clearer with an explicit "Import" button instead of relying on the checkbox. On first use, I wasn't sure what to click to initiate the import—I expected the checkbox to validate the file and then present a button to execute the import.
  • Destination field validation: The firewall rules in my test VM are the default LAN rules (allow LAN to any, v4 and v6). The import validation failed with "[destination_net] A value is required." The rules export should automatically populate "any" for the destination_net field in these cases. If this behavior is by design, the error message should clarify whether to enter "any" or "*" to resolve it. (I used "any" and the import succeeded.)
  • Import completion feedback: No confirmation is displayed when the import completes—the dialog simply disappears. In my test case with no floating rules, the dialog closed with no visible indication of success because the default view is floating rules and I didn't import any (i.e., it looks like nothing happened). Suggest adding a confirmation dialog: "X rule(s) successfully imported. Select the interface dropdown to view imported rules for each interface."
  • Typo: "Now we can import the exsiting rules..." → "existing"
#4
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 10:38:25 PM
Another one: When I imported the rules after the patches, I got one "new style" rule that is not editable after importing (pressing edit just does nothing).

The imported rule was:

Code Select
0b229e23-b728-4a32-85fc-4226bda46771,1,keep,,61,pass,1,0,"lan,opt1,opt2,VLANS,wireguard",in,inet46,TCP/UDP,,,,,0,0,0,0,0,,,,,,,,,,,,,,,,,,"LAN Rules",,,,,"Allow DNS to firewall",0,any,,0,(self),53

where VLANS is a group of VLAN interfaces.

I see an error in the browser console when pressing edit on that rule:

Code Select
Uncaught Error: Syntax error, unrecognized expression: .protocol_tcp/udp:not(div)
    jQuery 7
    <anonymous> https://opnsense.localhost:488/ui/firewall/filter/:2327
    jQuery 8
    setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:217
    each jQuery
    setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:140
    jQuery 2
    setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:132
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:142
    jQuery 2
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:139
    complete https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:312
    jQuery 6
    ajaxGet https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:304
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:137
    each jQuery
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:136
    show_edit_dialog https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1743
    show_edit_dialog https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1737
    command_edit https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1902
    _linkCellCommand https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:947
    jQuery 2

P.S.: The old rule is editable....
#5
Virtual private networks / Re: OpenVPN instance setup and...
Last post by Maduck - January 22, 2026, 10:23:16 PM
Thank you for your fast reply.

Of course it was my own fault. Linux OpenVPN failed, because it strictly verified the VPN server certificate's CN, which was missing; Android/Windows were less strict. So I created a new VPN Server Certificate with CN field for OpenVPN role (Server) instance and then exported my personal client .ovpn profile. Now it works, also Android/Windows after updating .ovpn.
#6
General Discussion / Forum connection issues
Last post by OPNenthu - January 22, 2026, 09:43:37 PM
I'd say over the last 1-2 days I'm experiencing a high number of connection issues on the forum.  Server overloaded?

You cannot view this attachment.

You cannot view this attachment.
#7
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 09:04:37 PM
Yep, I already agreed. I'll bring it up tomorrow.
#8
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 08:48:25 PM
The edit really should be re-enabled: The lack of editing of associated rules was fine as long as they were associated, IMHO - if they become disassociated, they should gain "full freedom" during upgrade (i.e. become editable) and not stay around like they were still associated.

By not being able to edit them or see their details, it would be error-prone, because everyone used to the old scheme (like me) would assume they are still linked to and controlled by their respective NAT rule - which they are not.
#9
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 08:35:44 PM
Yes, that was how it always was.  There was a point in time where they were editable but it also led to strange results so at some point it was disabled. Now in theory the edit could be re-enabled.

I'm not sure what the issue was.  Only remember that the associated rules were very partial rules and this lead to expectation vs. reality situations too during the time edits were allowed.


Cheers,
Franco
#10
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 08:32:17 PM
Quote from: franco on January 22, 2026, 08:04:53 PMYes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.

Yet the disassiciated rule is not editable (only the rule order is and I can delete the rule)? Then if I change something in the underlying NAT rule (say, change the port), I could not even make the corresponding change in the firewall rule? See my screenshots above for what I mean...
 
Pages1 2 3 ... 10