Recent posts

#1
General Discussion / Re: troubleshoot potentially b...
Last post by newsense - September 05, 2026, 11:42:25 PM
Do you see the flip flops when setting igc0 on 1000baseT ?

Is the appletv nic flopping if connected to the USW-pro-8 ? Try both auto negotiation and static on the switch side
#2
26.7 Series / Re: Network Driver Install
Last post by newsense - September 05, 2026, 11:30:53 PM
Download and install os-realtek-re and realtek-re-kmod packages from here

https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/MINT/26.7/latest/All/

 Copy to a stick, move to the minipc box and install.

Once installed the nics should be available upon restart.

If you have a mix of Intel and realtek cards then use the Intel one as wan so you'll be able to install the driver and perform the upgrades a lot easier than fiddling around with a usb stick.
#3
26.7 Series / Re: Upgrade 26.1 to 26.7 - bnx...
Last post by newsense - September 05, 2026, 10:56:40 PM
Ok but that means the bnxt driver on 15.1 is broken for the Broadcom 57504 chipset and a ticket needs to be opened upstream.


While using the driver provided by the manufacturer clearly works it clearly has issues - nontechnical - that prevent its redistribution both in FreeBSD and OPNsense.

The best path forward here is to have the driver maintainers look into this issue by opening a FreeBSD ticket.


As soon as this issue is addressed upstream you can be sure the next OPNsense release will include the patch.
#4
26.7 Series / Re: os-vnstat: Interface?
Last post by defaultuserfoo - September 05, 2026, 09:15:59 PM
Thanks!  I don't think it can be unassigned, see pictures.

It seems to be working fine --- but is/was it a good idea to change the configuration file from the console first?

It seems that the instruction to do so may be a remnant from when there was no way to configure vnstat through the GUI.  Perhaps it interferes?
#5
26.7 Series / Re: Confused by 26.7 upgrade
Last post by defaultuserfoo - September 05, 2026, 07:58:15 PM
Quote from: nero355 on September 05, 2026, 03:53:58 PM
Quote from: defaultuserfoo on September 03, 2026, 07:14:02 PMAnd what is 'config.xml'?
Ehh... seriously... ?!?!

It's the file that holds your complete OPNsense configuration and can be easily downloaded for backup purposes via the webGUI so you can restore it in the current or new installation of OPNsense ;)

Yeah I download the configuration every now and then, but the file has a pretty long name I don't pay a lot of attention to other than always saving it in the directory designated for it.  Besides, 'config.xml' is a very generic name.  What do you think how many files with that name do you have?

And what are these items


o firewall: move config.xml default LAN allow rules to new rules GUI
o firewall: legacy rules pages move to plugin


in the change log supposed to tell me?  I'm not familiar with the format and the contents of a file with the generic name 'config.xml'.  I don't know where and how firewall rules are stored.  What's with 'default LAN'?  That entry doesn't tell me anything because it's incomprehensible and meaningless to me.

What are the 'legacy rules pages'?  I happen to have an idea because I migrated my rules.  After migrating, there were still the automatic rules left and I didn't dare to delete those.  Now I can't see them anymore, if they are still there.  Will they stay forever now?  If I hadn't migrated, that entry would also be completely meaningless to me.

Where do the release notes tell me that I can't en-/disable firewall rules without installing a plug-in?  That would have been a relevant information.

QuoteYou have just hit a bad spot in time during the history of OPNsense in my opinion where a lot of migrations need to be done to be compatible with future source code upgrades or whatever it's officially called :
- ISC DHCP got moved to a plug-in.
Luckily migrating to either KEA or DNSmasq is pretty easy thanks to .CSV file exports for your Static DHCP Mappings.

Dunno, ISC DHCP is still there.  I was wondering if there is a way to migrate and hoping for one.  It would be very tedious and error prone to do it all manually.

Where in the release notes were we told that there is some kind of DHCP migration tool and how to use it?

Quote- Firewall Rules (Leagacy) got moved to a plug-in.
Firewall Rules [New] is now the only Firewall Rules section and needs to be migrated indeed.
The official plan was before upgrading from 26.1 to 26.7 but luckily it's not that strict and can be done afterwards too!

A couple weeks ago I was told it'll be years before a migration is required.  I do hope it's still many years because if I'd have to migrate, I'd have to completely redo those installations because the migration tool doesn't work.  That would take a week or so.

Quote- Port Forward just got renamed to Destination NAT.
So that was pretty easy :)

- Outbound NAT is going to be the new Source NAT from now on.
So this also needs migrating now.
The offical plan is during 26.7 and before upgrading to 27.1 next year, but maybe you can get away with doing that later on too... Dunno...

Yeah I noticed.  From my perspective, fortunately it was merely a change in naming.  I didn't do anything with source NAT.

QuoteAnd last but absolutely not least :
!!! Upgrade your Bootloader after upgrading to 26.7 !!!
However this is a FreeBSD thing and not OPNsense specific ;)

Upgrade the bootloader?  Was that mentioned anywhere?  Doesn't that work automatically?  How would I upgrade it?

QuoteOnce we get all this stuff behind us I am sure the updates/upgrades will be a lot less hassle than they seem to be now :)

The firewall rules were a nightmare, and that was handled badly by not telling us that we don't need to migrate and that the migration will break all the rules.  Instead it was made to appear as a harmless migration, using that tool, taking a look at the export to see if it looks messed up or not, and importing it.  It looked fine and all the rules were broken after the import.

A big fat warning is required, but there was none, and there still doesn't seem to be one.

QuoteGood luck! with all of the above...

Thanks, to you too.
#6
26.7 Series / Re: Confused by 26.7 upgrade
Last post by defaultuserfoo - September 05, 2026, 07:27:51 PM
Quote from: bamf on September 03, 2026, 10:15:59 PMThis is neither a consumer product nor a commercial solution. This is the community edition of an enterprise firewall. If you choose to use it, you need to educate yourself and read the release notes of every update before pressing the button. Community support relies on users doing their homework. Expecting enterprise-grade stability and active hand-holding without carefully reading the changelog misses the point of a community edition.

That the idea of 'community' --- whatever that idea might be --- is attributed to something doesn't mean that everyone who comes in contact with that something has to be educated to such an extend as, for example, to be able to read the very source code of all the components of a product like OPNsense.  Communities running (school) busses to transport residents (kids) usually do not require such residents (kids) to able to rebuild the engines of the very busses in order to use them, and they don't require the users of the busses to follow all the maintenance logs in detail in case a bus might have a flat tire or needs an engine rebuilt.  They don't even expect something like that from the bus drivers.

'Community' is a horribly overinflated word since a long time now such that it has become virtually meaningless.

There is only so much anyone can do.  Don't expect the bus drivers to rebuild the engines.  Don't expect the manufacturers of the busses to produce perfect busses the engines of which never fail.  And when someone suggests how the bus could be easier to use, don't just ignore his suggestion, and don't blame the user as uneducated and not sufficiently competent to use the bus.

Make it so that the bus driver can easily change a flat tire.  Make it so that everyone can understand the timetable.

Fortunately I don't need to use busses.  Last time I tried there wasn't even a timetable.  If there had been one, I probably wouldn't have been able to understand it.  These timetables are not for 'normal users'.  Busses suck.
#7
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - September 05, 2026, 07:25:22 PM
seems like I'm not the only one - 26.7: https://forum.opnsense.org/index.php?topic=52711.0

and a much older entry: https://forum.opnsense.org/index.php?topic=37223.0

I'll provide the requested diagnostic information shortly. Thank you!
#8
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by meyergru - September 05, 2026, 07:07:08 PM
As for Q1: I do not know. But that does not really matter. Even if DNS is broken immediately after OPNsense boots, the cron job should eventually heal that condition. As I already stated, this should not be your main concern; you can shorten the recovery time simply by running the cron job more frequently.

What your experiments did establish quite convincingly is my earlier point about FQDN resolution causing problems with S2S connections.

Alas, you did not provide any of the diagnostic information I asked for that could actually shed light on what goes wrong when a C2S client cannot resolve DNS.
#9
26.7 Series / Re: Confused by 26.7 upgrade
Last post by defaultuserfoo - September 05, 2026, 06:54:21 PM
Quote from: franco on September 04, 2026, 07:09:26 AMSome people are not aware, but it bears repeating:

In the context of the BSD licenses, the "as is" provision means that the software is provided without warranties, and the authors generally disclaim liability for issues, failures, or damages resulting from its use, including operational errors.

We try our best to describe the changes.

of course

And you're doing a fantastic job.  All the OPNsense installations I've to do with have been working 100% reliably without problems for years now, and that is quite an accomplishment.  Thank you.

QuoteThe code is open so it also documents the changes in a straightforward (but still very technical) way. If you want more you may want to consider participating in this process: the documentation is open and the changelogs are open too.


Cheers,
Franco

Let me suggest this:

What if you were to point out the changes that may possibly break stuff for users or hide things more clearly, plus a link to the release notes, instead of presenting the relatively short note and the long list of detailed changes that is being shown when someone is about to update?

That might give room for the real important stuff, and when someone wants to know all the details they would still be easy to find.

The long list seems to me like it might be good information for developers and users who have been following the development rather closely --- and such users are probably interested only in a particular issue or change and not the whole list anyway.

I don't think you can expect from the 'normal user' to be familiar with all the details, and it doesn't --- and shouldn't --- matter what all the details are.  But, for example, it matters to the 'normal user' to know that it's a bad idea to use the firewall rule migration tool and/or that the 'normal user' needs to install a certain plug-in when he wants to en-/disable firewall rules after the update.  Why aren't we told such things?  Why are we being told things that don't mean anything to us instead?

Perhaps it might help to make updates less confusing :)
#10
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - September 05, 2026, 06:47:10 PM
And another troubleshooting attempt and its result: I have temporarily replaced the three outbound tunnel endpoints DNS names with their external IPs, and rebooted. In this configuration, the OPNsense rebooted quickly, and the inbound WG client DNS resolution works flawlessly.

Therefore it appears that the online advice (of replacing names with IPs for WG endpoints) improves things, but this isn't a workable solution, as some endpoints' IPs will change over time.

Is there any way to influence the ordering of the start of the OPNsense services? Ideally, wireguard would only start after DNS (both Unbound and DNSmasq) is fully up and running - as mentioned previously, I notice two instances of Unbound starting, one before and one after the "Configurating Wireguard VPN"...