Messages

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.

What ive always wondered is what MTU to set the Quantum to, since i have three different interfaces which have different MTU settings:
Physical WAN: 1512
VLAN WAN: 1508
PPPOE WAN: 1500

Documentation doesnt appear to show this case.

Hi, thanks for the information. Does that mean that all TOR nodes (exists and relays) are on the list?

BTW: it appears that one of my wifi repeaters is the culprit that is trying to contact these NTP servers.
Why it would try to do that is beyond me, i have a fixed NTP server set for the whole network.
To prevent this i have added a specific port-forwarding rule which should forward this traffic to a server of my liking ;)

@meyergru
I block QUIC totally by blocking all UDP traffic on ports 80 and 443.

This is indeed a maintained source of DoH servers i use as well.
You also could add this rule to apply to TCP traffic on these ports only, since DoH uses TCP.

Thanks for the suggestion.
However, I don't have managed switches installed. All other networking equipment I have monitored for years without such behaviour.

Strangely nslookup of 94.16.122.152 resolves s7.vonderste.in.
Not known as a part of the ntp.pool, maybe just an NTP client.
Indeed this doesnt explain the source ip.

Update:
Just now a new request was made from 192.168.90.100:123 to a different destination ip: 217.144.138.234, which appears to be an NTP server: ntp2.wup-de.hosts.301-moved.de. Again i am unable to locate the source ip / host on my LAN. Maybe some WireShark is in order...

Hi,

Today i noticed that suspicious traffic from LAN -> WAN was blocked by Q-Feeds (thanks Q-feeds).
What i cannot understand is where this traffic originated from: 192.168.90.100 (port 123).
This should be impossible, since the DHCP range that i use is 192.168.1.0/24.
No fixed IPs are assigned.
ARP Table does not show the source IP (192.168.90.100).
Hostname of the source IP is empty.

The destination was 94.16.122.152 (port 123).
While this may look as ordinary NTP traffic, the destination IP does not appear an NTP server (no response).
Also, why would the originating IP address be out of the DHCP range?
And why would the destination IP be on a Q-Feeds blocklist?

Is this a spoofing attempt? Is this legit?
What am i missing?
How to find out which client this originated from?

As a mitigation and while i am figuring this out I have:
- Blocked the ASN for the destination address in F/W;
- Allowed only 192.168.1.0/24 and 224.0.0.0/8 out from LAN into F/W.

You are trying to reroute any LAN traffic to 172.16.200.1 but using the same desination port.
Are you sure this is correct? Is the TOR plugin listening on these ports?

Updated to 25.7.7_2 without a problem.
Thanks!

Indeed may seem pretty 'fringe' haha.
Im not understanding everything, but the things i do get and agree with i have implemented.
My goal is to see how this works for some time.

I'm especially fascinated by replacing the suffix of the IPv6 address for all devices on LAN by some random address using Outbound NAT.
For now i have created ~20 random suffixes and loaded these in an alias. These are used round-robin (sticky).
Since i have a fixed IPv6 prefix, i don't need to worry about that changing. I plan to rotate these random suffixes regularly, but would love to see a more automatic solution.

Thanks Millerwissen for your time and ideas.