Recent posts

#21
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 06:19:49 PM
As you have found, the enabled flag was not exported correctly nor were the categories.

I now used:

opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593
configctl webgui restart

And then re-exported the old settings. This time, the enabled and categories settings seemed correct in the CSV.

BTW: In the migration assistant list of steps, it says: "Deselect anti-lockout in advanced settings" - it should be "Enable anti-lockout in advanced settings".

The thing with the manual rule is that with 25.7.11, you saw the associated firewall rule name there, so you would know which one it was. This gets lost immediately upon update, you do not have to use the migration assistant. That means I see that there is an associated rule:

You cannot view this attachment.

Yet in the NAT rule, it does not identify which any more (before you would see the description "Allow DNS via IPv4" instead of "Manual"):

You cannot view this attachment.
#22
25.7, 25.10 Series / Re: IPv6 erratically broken fr...
Last post by rmayr - January 22, 2026, 06:18:03 PM
No changes. In response to packet like these that I see from the Android device with
tcpdump -n -i igb2_vlan64 ether host fa:17:c7:f8:dd:85 and ip6 (that is the Android device randomized MAC address for this SSID):

18:00:19.946419 IP6 2a03:fa00:650:30:9a7c:9494:3859:2d9b.45934 > 2606:4700:10::6814:2f59.443: Flags [S], seq 3003767200, win 65535, options [mss 1432,sackOK,TS val 3205487265 ecr 0,nop,wscale 8], length 0
So a simple TCP start of connection (SYN flag) to port 443 on the default route. I can ping that target IP from another Linux laptop on the same LAN/SSID.

I get the firewall log entry (not for exactly this packet, because once the Android device / OPNsense combination get into this state, I don't really get many log entries for this source IP anymore):

LAN In 2026-01-22T17:46:21 TCP [2a03:fa00:650:30:9a7c:9494:3859:2d9b]:49736 [2a00:1450:4001:805::200a]:443 block Default deny / state violation rule
With the (now even simplified) default rules on the OPNsense ruleset, I really, really don't understand why it would be blocked. Can there be any weird packet flags that cause the "state violation"? Or maybe this has to do with traffic shaping (simple QoS rules)? I am quite at a loss to understand this behavior.

As soon as the Android device starts using a new randomized client IPv6 address, traffic gets through again for a short while before the same happens with the new address.
#23
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 05:19:17 PM
> I tried to understand how the NAT rule linkage relates to new/old rules, but failed.

The old page added a separate "association rule" which is a bit of a broken firewall rule.

The new system will create a shadow rule in in "Register rule" mode somewhat resembling the old approach but without injecting a real firewall rule. Manual and pass are still the same.


Cheers,
Franco
#24
25.7, 25.10 Series / Re: After updating Opnsense fr...
Last post by wide - January 22, 2026, 05:12:49 PM
Most likely this was not related to 25.7.11_1 update but changes in IDS configuration I had done right after the update. Finally today I restored the Opnsense VM from the backup taken before 25.7.11_1 update and updated the VM then to latest 25.7.11_2 and now all good so far.
#25
High availability / Re: CARP OS-FRR timeout after ...
Last post by Monviech (Cedrik) - January 22, 2026, 05:05:46 PM
Hello, I think we found something.

https://github.com/opnsense/plugins/pull/5160

Can you try the following patch on the affected firewalls, it will only apply to the latest FRR version though (which means you have to be on 25.7.10 when you test).

# opnsense-patch https://github.com/opnsense/plugins/commit/d27619990739424db4e0aaa266c2392eeb7abe57
#26
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 05:05:08 PM
Scratch that, here's the fix for the enabled https://github.com/opnsense/core/commit/94081fd82f

And this is for categories: https://github.com/opnsense/core/commit/d1519593

Thanks!

Edit: Since were at the topic Stephan found this earlier today as well https://github.com/opnsense/core/commit/ba8194de
#27
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 22, 2026, 04:56:06 PM
Uwe, can you check the CSV if the enable flags and categories are exported correctly for you?


Thanks,
Franco
#28
Hi all,

I've put together a short video walkthrough explaining what Q-Feeds is, how to install and configure the, what the feeds actually represent, and how to apply the automatically managed Q-Feeds aliases directly in firewall rules for threat blocking.

The video covers:

  • What is Q-Feeds?
  • Installing the plugin
  • Basic configuration options
  • Different feeds, update frequency, and pricing
  • How the plugin maintains aliases automatically
  • Using those aliases in firewall rules for blocking malicious traffic

Blog post walkthrough and video:
OPNsense Firewall Security with Q-Feeds Threat Intelligence
#29
26.1 Series / Re: Upgrade to RC1 successful
Last post by meyergru - January 22, 2026, 04:14:05 PM
I switched to 26.1-RC1 as well. Most things worked OOTB, however, I found that the NAT rules filter associations were gone, showing only "Manual" instead, although some link still exists as evidenced by the associated firewall rules being non-editable as usual.

After I tried the first steps of rules migration, all new style rules had no categories and were disabled per default.  I wonder what would have happened if I followed the instructions and just removed the old rules at that point.

I tried to understand how the NAT rule linkage relates to new/old rules, but failed. Since it was a production system, I did not dare to remove the old rules.

What is irritating is that "floating rules" now are just the ones that have more than one interface, so if you add an interface to any existing interface rule, the rule shifts to floating rules (and also the other way around). However, I like that, because with the old style rules, you manually have to re-create a rule in the floating section. One has to get accustomed to this, however, because I also used 1-interface-only floating rules for blocking in the floating section just because of the priority being greater than implicit port forwarding rules.
#30
General Discussion / ISC-DHCP to KEA Migration Tool...
Last post by Sheridan Computers - January 22, 2026, 03:50:49 PM
I recently a small CLI tool I wrote for a client migration to help move ISC DHCP static mappings to Kea reservations using the OPNsense config.xml, as there's currently no way to export IPv6 static mappings via web interface.

I've open sourced it on github (should have releases for Linux, Windows, Mac).

It supports both IPv4 and IPv6 static mappings (including DUID, hostname, domain search, description). I originally wrote it mainly to handle DHCPv6 static reservations, since there isn't currently a GUI export/import path for those.

It's safe by default (reads the input config and writes to a new output file so you can review before importing) and only migrates static reservations, not pools or options.

This is very much a v1 community tool, so please test (pref in a lab) first and take a backup/snapshot before importing. If anyone wants to try it and provide feedback or edge cases, I'd really appreciate it.

See the Github README for command line usage.

  • Leave kea disabled for now
  • Create the relevant IPv4 and IPv6 subnets in kea
  • Download the config (from system settings in GUI)
  • Use scan option first to see what will change
  • Use the convert option to create a new xml config
  • Restore the new config from OPNsense gui
  • Check the kea settings everything imported
  • Disable isc and enable kea

Tested with 25.7.11:
ISC-DHCP to Kea Migration Tool