Messages

There is a piece of text on the Deciso / OPNsense website: https://docs.opnsense.org/hardware/bios.html#hyper-threading

No, you cannot reliably use a 9/125µm (single-mode) cable with a 50/125µm (multimode) module.
While the connectors physically fit, the core diameter mismatch (9µm vs 50µm) causes catastrophic signal loss.

The cable we are using is a 2 fibers LC UPC Duplex to LC UPC Duplex OS2

You can't use single mode cables with multimode transceivers. Gotta be OM (usually OM3 or OM4)

https://en.wikipedia.org/wiki/Multi-mode_optical_fiber

Indeed, @Patient0

No, you cannot reliably use a 9/125µm (single-mode) cable with a 50/125µm (multimode) module.
While the connectors physically fit, the core diameter mismatch (9µm vs 50µm) causes catastrophic signal loss.

Just wanted to convey my appreciation for all the good and hard work the Opnsense team at Deciso is doing.
Great hardware and excellent software support!
Much appreciated.

Just donated 25EUR

Indeed it looks like im "too far down the rabbit hole", lol.
Thanks for sharing the freshport page. Indeed it seems im on the latest microcode as part of the repository.

I'll have a look at the package date for microcode later today.
The spectre-meldown tool provides identifies my EPYC 3101 CPU as: family 0x17 model 0x1 stepping 0x2 ucode 0x0 cpuid 0x800f12 pfid 0x8.
Does that look ok? What about the ucode 0x0? Is that the same as 0x8001278 truncated?

What about the failure of the manual microcode:
$ service microcode_update onestart
Updating CPU Microcode...
Re-evalulation of CPU flags Failed.

I'm at a loss here.

Hi, sorry to hijack the topic with a question about an AMD CPU. ;)
I've also been puzzled by this topic.

I'm on Opnsense 26.1.8_5 running on AMD EPYC (Zen1, CPUID: 0x00800f12).
It's Deciso Opnsense hardware (Dec3840) with the latest V17 BIOS dated Aug 2025.

$ sudo x86info -a | grep -i micro reports: the loaded microcode version is: 0x8001278.
I have the AMD microcode plugin installed, so you would think we would be up-to-date?

However, According to the output from "Spectre and Meltdown mitigation detection tool v26.33.0420460":
  * CPU microcode is the latest known available version:  NO  (latest version is 0x8001279 dated 2024/11/11 according to builtin firmwares DB v349+i20260227+1cce)

$ service microcode_update onestart
Updating CPU Microcode...
Re-evalulation of CPU flags Failed.

Is there indeed a newer version of the microcode than 0x8001278?

Hoi allemaal,

Ik heb mij zojuist aangemeld.

Kets

[ice_ddp_load]

Hi all, question about the default configuration of the dec3840 as downloadable from https://docs.opnsense.org/hardware/defaults.html.

I noticed that there is a tunable there i can't explain:
...
  <sysctl>
    <item>
      <tunable>ice_ddp_load</tunable>
      <value>YES</value>
      <descr>Include DDP package file for Intel ice driver</descr>
    </item>
  </sysctl>

Two questions come up in my head:
1. Why is his tunable in the default config for the dec3840? As far as i know this intended to the intel E810 NICs only.
I have intel i210 NICs. Is this tunable required for proper operation?

2. On the forums another (related?) tunable is mentioned often in conjunction with the former:  if_ice_load="YES".
Why is this not included in the default config?

PS: I've tried to add the ice_ddp_load tunable earlier, but caused instability/boot failure if i can recall correctly.

Thanks for the quick update and response! ;)

Please be aware of a recently published vulnerability in FreeBSD.
Specifically the component handling Router Advertisements (RA's) on local network is vulnerable.
Please find the description below.
Is an update/fix planned?

=============================================================================
FreeBSD-SA-25:12.rtsold                                     Security Advisory
                                                          The FreeBSD Project

Topic:          Remote code execution via ND6 Router Advertisements

Category:       core
Module:         rtsold
Announced:      2025-12-16
Credits:        Kevin Day
Affects:        All supported versions of FreeBSD.
Corrected:      2025-12-16 23:39:32 UTC (stable/15, 15.0-STABLE)
                2025-12-16 23:43:01 UTC (releng/15.0, 15.0-RELEASE-p1)
                2025-12-16 23:45:05 UTC (stable/14, 14.3-STABLE)
                2025-12-16 23:43:25 UTC (releng/14.3, 14.3-RELEASE-p7)
                2025-12-16 23:44:10 UTC (stable/13, 13.4-STABLE)
                2025-12-16 23:43:33 UTC (releng/13.5, 13.5-RELEASE-p8)
CVE Name:       CVE-2025-14558

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.freebsd.org/>.

I.   Background

rtsold(8) and rtsol(8) are programs which process router advertisement
packets as part of the IPv6 stateless address autoconfiguration (SLAAC)
mechanism.

II.  Problem Description

The rtsol(8) and rtsold(8) programs do not validate the domain search list
options provided in router advertisement messages; the option body is passed
to resolvconf(8) unmodified.

resolvconf(8) is a shell script which does not validate its input.  A lack of
quoting meant that shell commands pass as input to resolvconf(8) may be
executed.

III. Impact

Systems running rtsol(8) or rtsold(8) are vulnerable to remote code execution
from systems on the same network segment.  In particular, router advertisement
messages are not routable and should be dropped by routers, so the attack does
not cross network boundaries.

IV.  Workaround

No workaround is available.  Users not using IPv6, and IPv6 users that do not
configure the system to accept router advertisement messages, are not affected.
A network interface listed by ifconfig(8) accepts router advertisement messages
if the string "ACCEPT_RTADV" is present in the nd6 option list.

V.   Solution

Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.

Perform one of the following:

1) To update your vulnerable system via a binary patch:

Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms,
or the i386 platform on FreeBSD 13, can be updated via the freebsd-update(8)
utility:

# freebsd-update fetch
# freebsd-update install

2) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to the applicable
FreeBSD release branches.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch https://security.freebsd.org/patches/SA-25:12/rtsold.patch
# fetch https://security.freebsd.org/patches/SA-25:12/rtsold.patch.asc
# gpg --verify rtsold.patch.asc

b) Apply the patch.  Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.freebsd.org/handbook/makeworld.html>.

Restart the applicable daemons, or reboot the system.

VI.  Correction details

This issue is corrected as of the corresponding Git commit hash in the
following stable and release branches:

Branch/path                             Hash                     Revision
- -------------------------------------------------------------------------
stable/15/                              6759fbb1a553    stable/15-n281548
releng/15.0/                            408f5c61821f  releng/15.0-n280998
stable/14/                              26702912e857    stable/14-n273051
releng/14.3/                            3c54b204bf86  releng/14.3-n271454
stable/13/                              4fef5819cca9    stable/13-n259643
releng/13.5/                            35cee6a90119  releng/13.5-n259186
- -------------------------------------------------------------------------

Run the following command to see which files were modified by a
particular commit:

# git show --stat <commit hash>

Or visit the following URL, replacing NNNNNN with the hash:

<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>

To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:

# git rev-list --count --first-parent HEAD

VII. References

<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-14558>

The latest revision of this advisory is available at
<URL:https://security.freebsd.org/advisories/FreeBSD-SA-25:12.rtsold.asc>

I would first check if your hardware is functioning correctly.
Try a different cable for example.
What kind of network chip is in the router and in the pc you are pining from?

For what it's worth: Love to have you around franco. Very much appreciate all the effort and time you invest in Opnsense (including the forum)!

When the first DoT server does not respond, Unbound treats it as unresponsive and applies a probing scheme with exponential backoff. Initially, failed queries receive a SERVFAIL response. Unbound then blocks the non-responsive server for a default period (typically 15 minutes, controlled by infra-ttl) and periodically sends a single probe query to test its availability.

During this time, Unbound automatically forwards new queries to the next available server in the configuration. Once the blocked server responds to a probe, it is reinstated into the pool for normal use

[NTP client]

hi mb19,

Seems you are mixing up three possible situations:
1. LAN client requesting time from a NTP server on WAN
2. Opnsense router acting as an NTP client requesting time from an NTP server on WAN for synchronising its own clock
3. Opnsense router acting as a NTP server itself to serve time requests from LAN clients

situation 1: Appears to be working, since time of LAN client is synced.
situation 2: appears not to be working for unknown reasons. because of this, stiation 3 will also not work because of an unsynced clock on opnsense router.

From your example you say that for you can see traffic going out to WAN as well as coming back.
However, the NTPd daemon in Opnsense router does not appear to be synchronised.

Config looks ok.