Recent posts

#91
Development and Code Review / Re: Improved Freeradius for Om...
Last post by mimugmail - November 27, 2025, 07:21:23 AM
Yep it's really easy to add a PR.
#92
25.7, 25.10 Series / Re: (Solved?) Freeradius - can...
Last post by mimugmail - November 27, 2025, 07:19:52 AM
opnsense-revert -r 25.7.7 os-freeradius will just revert the plugin. I'll try to fix it today.
#93
25.7, 25.10 Series / Re: Code quality reminder for ...
Last post by mimugmail - November 27, 2025, 07:18:32 AM
Yep, this is the reason for a Business Edition like in most other open source projects...
#95
General Discussion / Re: No Beep on Startup and Shu...
Last post by johnmcallister - November 27, 2025, 03:58:41 AM
Quote..I'm not sure what hardware brand or version of OPNSense you're running, but this also happened to me. I was just tinkering with it today. I have a Lenovo M720q Tiny as well as a M715q Tiny. The beep can be heard on the M715q but not on the M720q..

I'm running a Lenovo® M90n-1 Nano and encountered the same problem: No friendly OPNsense beeps on startup/shutdown. Definitely mission-critical, couldn't let it go unaddressed.

After some poking around I got it fixed. There were three separate problems:

  • Two different versions of the "beep" binary, one of which doesn't work on my system.
  • The opnsense-beep shell script calling the wrong (non-functional) version of "beep."
  • The opnsense start / stop beep sound definition files contain beep durations in bare integers that are interpreted as "centiseconds" by one version of beep, but as "milliseconds" in another version of beep.

There are for whatever reason multiple versions of the "beep" binary on my system. (25.7.8.) (As best I can tell it looks like one might use /dev/speaker and another version uses /dev/dsp instead? )

Each of these versions has different command-line options, and only one of them (/usr/bin/beep) actually makes sounds on my system.

root@router:~ # ls -al /usr/bin/beep
-rwsr-xr-x  1 root wheel 10088 Nov 24 23:26 /usr/bin/beep
# This version interprets tone-length integers as millisecond values, and it
# works (makes beep noises) on my system.

root@router:~ # ls -al /usr/local/bin/beep
-r-xr-xr-x  1 root wheel 7584 Jul 21 16:21 /usr/local/bin/beep
# This version interpretes tone-length integers as centi-second values, and it
# DOESN'T work (no sounds) on my system.


The /usr/local/sbin/opnsense-beep script, as-shipped, calls /usr/local/bin/beep.

So I altered the script it to call the other version of beep instead. I also altering the command-line flags as-required.

root@router:/usr/local/sbin # diff opnsense-beep opnsense-beep-ORIGINAL
69c69
<      /usr/bin/beep  -F "${NOTE}" -D "${DURATION}" -g 100
---
>         /usr/local/bin/beep -p "${NOTE}" "${DURATION}"

#  The -g 100 argument optionally boosts the output volume to 100%, which is necessary
#  for the tiny speaker in this system.


But after doing this, while I could type, say, /usr/bin/beep -F 1000 -D 100 from the command line and it would work fine, the opnsense-beep script still wasn't working.

I finally checked the beep-sound definition files in /usr/local/etc/opensense-beep.d/* and found them to have DURATION lengths of "25." Those lengths were meant for the (non-working, on my system)
/usr/local/bin/beep, which takes tone lengths in units of centi-seconds. (Hundredths of a second.)


But /usr/bin/beep  takes tone lengths in units of milliseconds, with 50 ms the lowest-valid value.  Once I changed the beep definitions in the /usr/local/etc/opensense-beep.d/* tune definition files from "25" to "250," my modified version of /usr/local/sbin/opnsense-beep started producing the usual friendly beep sounds.



FWIW, here are the audio devices as-reported on my system:

root@router:~ # cat /dev/sndstat
Installed devices:
pcm0: <Realtek ALC235 (Analog 2.0+HP/2.0)> (play/rec) default
pcm1: <Intel Kaby Lake (HDMI/DP 8ch)> (play)
No devices installed from userspace.
#96
25.7, 25.10 Series / Re: Dropdown Menu Error on Viv...
Last post by charles.adams - November 27, 2025, 03:52:26 AM
For others who run into this issue. It is caused by setting a chromium flag:

You cannot view this attachment.

If you set it wrong you will get this problem on selection boxes that the browser can't guess at the autofill.
#97
25.7, 25.10 Series / Re: Dropdown Menu Error on Viv...
Last post by charles.adams - November 27, 2025, 03:45:22 AM
They are from 25.10

#98
Zenarmor (Sensei) / Zenarmor BF Sale
Last post by charles.adams - November 27, 2025, 03:42:44 AM
There was a BF sale last year. Do you think there will be another again this year?
#99
25.7, 25.10 Series / Re: Using Adguard Home and DNS...
Last post by OPNenthu - November 27, 2025, 03:28:55 AM
Quote from: JMini on November 27, 2025, 02:28:12 AMDoes Unbound use DOH/DOT to send the request to the resolvers? Because the DNS req will still go through my ISP. So even though they're not serving the DNS request themselves, they can still see the unencrypted DNS request.

You can configure Unbound as a DoT forwarder.

If your threat model involves preventing your ISP collecting your DNS queries then I think that's a good reason not to use any kind of plain DNS, such as Unbound in recursive mode.  However it's not as simple as that.  You have to trust that your DoT provider isn't colluding with other entities to share or sell your data.  Furthermore, the encryption between you and the provider is not infallible- certificates can be spoofed.  If you're not using a VPN then the ISP can anyway infer your DNS queries by just timing your connections to web servers.  If you are using a VPN, then you are again giving all the data to a single entity who may sell/share it on (and as we see playing out now, governments are increasingly pushing to weaken VPNs).

There's no privacy.  It's just a matter of who you wish to share with and what features you need.  For instance, Quad9 offers malware filtering based on threat intelligence which you may decide is a valuable tradeoff for giving them your DNS queries.
#100
General Discussion / new setup cannot reach line sp...
Last post by muusemuuse - November 27, 2025, 03:05:01 AM
I've set up a fedora server and threw OPNsense into a VM on it.  The system has a ryzen 5800xt CPU and a dual port intel i226v NIC installed.  I have pinned 2 CPU cores to the OPNsense VM and fed 1 thread from each core to the VM.  The WAN port is passed to the VM via direct attachment (bridge right now, though I will probably change that to private) and the LAN port uses linux bridges for the untagged traffic as well as the vlan ports on it.  The plan is to pass them all as separate interfaces into OPNsense, then tell the host to grab an IP on whatever bridge I need it to talk to.

OPNsense is configured right now to only use the WAN and LAN ports.  I havent set up the vlan interfaces yet.  Firewall rules are still defaults.

My interent connection speed is 1000 down/40 up, but in this configuration I can only hit 670 down/40 up on speedtest.net from a client device on the network.  I tried doing this bare metal for comparison and it hit 824/40.  connecting a macbook to the modem directly got me to 916/40. I'm using virtuio since passthrough is just not going to happen with this crappy motherboard but supposedly that should be fine.

I know there's going to be some overhead with this, and I haven't done any performance tuning yet because I'm still testing out basic functionality first, but this seems a bit severe.  I have clearly overlooked something, but I'm stumped as to what I'm missing.

I checked the read me first posts on here.  I saw there were some mitigations I could disable in OPNsense and did try that but no change.  There is a firmware update possibly out there for this NIC but the linux host has custody of the NIC and it's not telling me what version firmware it has on it.  That update seems to be more about stability than performance anyway and I'm getting stable connections, just not performant ones.

What am I overlooking?