Messages

Ok Ive tested multiple different configurations now and updated the main post completely.
So please read it again.

Hello everyone,

I currently have a reproducible issue with OPNsense on a PC Engines APU2D4 and would appreciate any hints or similar experiences.

## Hardware / Setup

- PC Engines APU2D4
- Serial console only (no VGA)
- mSATA SSD
- FreeBSD base installation with GELI encryption
- Afterwards bootstrapped to OPNsense

## Initial Situation

The system previously worked fine with OPNsense 25.7.

The upgrade to 26.1 was performed from an existing FreeBSD installation using:

opnsense-update -ur 26.1
pkg upgrade


The upgrade process itself completes successfully without errors.

---

# Problem

After:

- successfully upgrading to 26.1 with 3 reboots
  or
- performing a completely fresh FreeBSD + OPNsense 26.1 (bootstrap) installation and restoring my old configuration

the system gets stuck during the boot process.

Without restoring the config on a fresh FreeBSD + OPNsense 26.1 (bootstrap) installation, it boots normally.

However, with the restored config:

- GELI unlock works
- boot messages continue normally
- output then appears to stop at:


amdtemp0: found 4 cores and 1 sensors


---

# Important Findings

After additional testing, the system also seems to not be completely frozen on newer versions.

## 1) Testing with FreeBSD + OPNsense bootstrap

### FreeBSD + OPNsense 25.7

* install a fresh FreeBSD + OPNsense 25.7
- then restore the same old config

The APU2 shows EXACTLY the same behavior on the serial console:

- console output appears to stop at `amdtemp0`

HOWEVER, with the older 25.7 version:

- network interfaces are initialized correctly
- the WebGUI is fully reachable
- routing/firewall functionality works normally

This strongly suggests that:

- the serial console and/or
- console login / getty / tty handling

stops working correctly after restoring the configuration.

I have tested official FreeBSD + OPNsense bootstrap installations with and without:

- GELI
- hardening options such as:

  * hide_uids
  * hide_gids
  * hide_jail
  * procfs restrictions
  * read_msgbuf
  * random_pid
  * additional sysctl/hardening options
- different mSATA sizes (60GB / 120GB / 240GB)

=> none of these settings make any difference regarding the issue.

Independently from the boot stop on 26.1 on the APU2, I can boot the exact same device (mSATA) fully working on a ThinkPad T500 and X230:

- all interfaces are initialized correctly
- settings are applied correctly
- the system is fully usable

Therefore, this definitely appears to be an APU2-specific issue in combination with FreeBSD 14.x and OPNsense 26.1.

---

## 2) Testing with direct OPNsense 26.1 installation

- flashing a fresh OPNsense 26.1 image to the APU2 works correctly
- I can connect normally after installation, just like in test case 1

However, an important point is:

- restoring the old config does not seem to work correctly in this setup

What happens:

- the encrypted config file is accepted
- I receive the message that the restore was successful
- the APU2 reboots normally

BUT:

- on the serial console I still only see the default 2 interfaces from the stock installation
- after logging into the WebGUI, the system still looks like a fresh installation

So apparently the old configuration is either:

- not fully restored
  or
- partially ignored during boot/startup.

=> I will try to decrypt the config file and search for problematic settings.

---

The main issue seems to be related to OPNsense 26.1 itself, so there may have been significant changes affecting the APU2 boot process.

---

# Additional Observations on the Serial Console

- newly attached USB devices are still detected
- corresponding kernel messages continue to appear on the serial console
- the kernel/system itself therefore still appears to be running

On OPNsense 26.1 additionally (with restored old config):

- no reachable interfaces/WebGUI
- interfaces apparently are not initialized correctly
- possibly an additional issue related to config/plugins/interface mapping

---

# Current Suspicions

At the moment I suspect a combination of:

- serial console/getty issue
- old console/TTY settings in config.xml
- possible plugin incompatibility
- old interface/VLAN mapping
- FreeBSD 14.x / OPNsense 26.1 interaction on the APU2 (currently my main suspicion)

After my testing, the following point can probably be excluded regarding the boot hangs:

- interaction with enabled FreeBSD hardening options

Currently the behavior looks more like:

- console/login broken plus some init/startup issues

rather than:

- a complete system freeze.

---

# Planned Analysis

Next I plan to:

- boot the system with the restored config until the apparent "hang"
- power it off
- boot the mSATA in another machine
- analyze logs and config.xml there

However, as a FreeBSD beginner, recovering/debugging FreeBSD bootloader issues is still somewhat tricky for me and may take some time.

Relevant files are probably:


/var/log/system/latest.log
/var/log/boot/latest.log
/var/log/configd/latest.log
/conf/config.xml


---

# Questions

1. Has anyone experienced similar issues with:

   * APU2
   * serial console
   * restored configs
   * OPNsense 26.1
   * FreeBSD 14.x?

2. Are there any known issues involving:

   * old console/TTY settings
   * plugins
   * getty/serial login
   * restored config.xml on 26.1?

3. Could there be any known APU2-specific regressions in FreeBSD 14.x or OPNsense 26.1?

Thanks in advance.


EDIT-1 - 2026-05-13 (EU): after multiple testing => I changed Block "Important Findings" and add Points 1) and 2) ; updated "Additional Observations on the Serial Console" and "Current Suspicions"
EDIT-2 - 2026-05-13 (EU): add EDIT 1 and 2 =)

Hello community,

I need a some help to find a solution the following issue:


My opnsense WAN-Interface crashes today, so that no connection could be established from inside or outside.
Its the firs time after years, I had this issue.

Its a new opnsense installation (30 days old) with an imported config from another working opnsense.
It runs without problems up to today.

Infos:

- config: internet => modem (fritzbox 7490) => opnsense (apu4d) => multiple WANs VLANs (local lans)

- I see the unbound LOG process uses 60% from the 4GB physical ram.
- the last 5000 mails (there are not imported, all are from the last 30 days) shows the same messages like:

    *

Code Select Expand

subject cron  root@opnsense (sbin/pfctl -t 'virusprot' -T expire 3600) > /dev/null
see:

Code Select Expand

root:$ mail
:5

Message 5:
From root@OPNsense.internal Mon Oct  6 22:45:00 2025
From: Cron Daemon <root@OPNsense.internal>
To: root
Subject: Cron <root@OPNsense> (/sbin/pfctl -t 'virusprot' -T expire '3600') > /dev/null
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin>
X-Cron-Env: <REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Date: Mon, 06 Oct 2025 22:45:00 +0000

0/0 addresses expired.

& 5200
5200: Invalid message number
& 5150
Message 5150:
From root@OPNsense.intern Fri Nov  7 15:00:00 2025
From: Cron Daemon <root@OPNsense.intern>
To: root
Subject: Cron <root@OPNsense> (/sbin/pfctl -t 'sshlockout' -T expire '3600') > /dev/null
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin>
X-Cron-Env: <REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Date: Fri, 07 Nov 2025 15:00:00 +0100

0/0 addresses expired.

& 5170
5170: Invalid message number
& 5160
Message 5160:
From root@OPNsense.intern Fri Nov  7 16:15:00 2025
From: Cron Daemon <root@OPNsense.intern>
To: root
Subject: Cron <root@OPNsense> (/sbin/pfctl -t 'sshlockout' -T expire '3600') > /dev/null
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin>
X-Cron-Env: <REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Date: Fri, 07 Nov 2025 16:15:00 +0100

0/0 addresses expired.

& 590
Message 590:
From root@OPNsense.intern Fri Oct 10 01:00:00 2025
From: Cron Daemon <root@OPNsense.intern>
To: root
Subject: Cron <root@OPNsense> (/sbin/pfctl -t 'virusprot' -T expire '3600') > /dev/null
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin>
X-Cron-Env: <REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Date: Fri, 10 Oct 2025 01:00:00 +0200

0/0 addresses expired.

&


Furthermore I see, that my established onvpn connection from my phone are failed with TLS errors after I change the connection at 07:51 am from WLAN to mobile at my phone for one hour.
It seems to be, that all established connections are working after the unknown big fail. But if one of these connections gets a disconnect, they cant be established anymore.
But I cant find some hints in the logs on which time this happened...

All connections working succesfully after I physically reconnect the patch cable between modem and opnsense.


I dont know where I can find and inspect specific details at the logs.
Ive checkt all logs at /var/log/* but doesnt found some interesting points .. the two ones above.

Does anyone know, whats happend?


Edit-1: change WANs to VLANs

Vielen Dank für den Link.

Nach einigen fehlgeschlagenen Versuchen fielen mir einige Einstellungen in der Fritzbox unter

Heimnetz => Netzwerk => Netzwerkeinstellungen => IPv6-Einstellungen

auf.

Hier müssen 2 weitere Einstellungen gesetzt werden:

- "Auch IPv6-Präfixe zulassen, die andere IPv6-Router im Heimnetz bekanntgeben".
- "DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren" und "DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen"
- siehe AVM: https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/1239_IPv6-Subnetz-in-FRITZ-Box-einrichten/

Erst anschließend konnte der von der Opnsense angeforderte und empfangene Prefix an die Interfaces weitergegeben werden.
Entgegen der Darstellung von AVM empfängt die Opensense lediglich einen /64 Prefix statt einem /62er.
Die Fritzbox erhält jedoch einen /59er Prefix und scheint diesen trotz verschiedener Optionen in der Opnsense WAN Schnittstelle (/60-64er Prefix anforderung) nut als /64er Prefix weiterzureichen.
Einsehbar unter ssh-Zugriff und der opnsense-shell.

Daraus resultiert jedoch, das ich lediglich ein Prefix mit der ID 0 an eine Schnittstelle weiterreichen kann...
Umgehen lässt sich dies, in dem ich die Prefix-Anforerung auf /62 stelle.
Obwohl ein 64er Prefix empfangen wird, lassen sich jedoch die ID's von 0-3 vergeben.
Die Verteilung funktioniert. Jedoch ist das Thema IPv6 relativ neu für mich und ich erkenne hierbei noch nicht die Probleme die sich aus dieser Konfiguration eventuell ergeben können.
Anbei noch eine kleine Übersicht:






Eine Frage stellt sich mir aktuell jedoch noch:

Dass ein IPv6 Server durch seine globale IPv6 Adresse erreichbar ist und dahingehend das bekannte NAT aus der IPv4 Welt nicht mehr benötigt wird ist verständlich. Was ich jedoch aktuell nicht nachvollziehen kann ist, wieso es nicht auch im IPv6 Bereich möglich ist, die globale IPv6 Adresse der Fritzbox per DynDNS aufzurufen und durch Portweiterleitungen eine Verbindung mit dem dahinterliegenden auch über IPv6 angebundenen Server aufzunehmen?


Weiterhin sind mir noch kleine Besonderheiten im Bezug auf IPv6 aufgefallen:
- Fritzbox:
    * Eine explizite Anforderung einer bestimmten Prefix-Länge über die FB ist nur mit einer ungebrandeten FB möglich, siehe:
    https://forum.vodafone.de/t5/Ger%C3%A4te/IPv6-Pr%C3%A4fix-mit-Fritzbox-6660-nicht-62/td-p/2708605
    * Ist in der Fritzbox der DynDNS Dienst, unabhängig des Anbieters und myfritz ausgenommen, aktiviert und wird als verbunden angezeigt, muss dies nicht zwangsläufig auch der Fall sein.
        Gibt es bei der Weiterleitung einen Fehler, kann man diesen nicht direkt erkennen. Denn die Fritzbox leitet den Aufruf der DynDNS Adresse aus dem internen Netz direkt auf die Fritzbox-Oberfläche weiter.
        Siehe:
        https://www.ip-phone-forum.de/threads/fritzbox-portweiterleitung-funktioniert-nach-update-auf-fritzos-7-27-nicht-mehr.310499/
- bei einem Aufruf der DynDNS Adresse, ist zu beachten, dass logischerweise das Startnetz auch IPv6 unterstützt. Klingt trivial, aber entgegen meiner Annahme scheint das nicht bei allen Mobilfunknetzen der Fall zu sein.

Guten Morgen,

da ich aktuell über eine Fritzbox 6660 Cable an Vodafone DS-Lite angeschlossen bin, würde mich interessieren, ob die Möglichkeit besteht, ähnlich eines PPOE Anschlusses, den erhaltenen IPv6 Prefix direkt oder als "Sub-Prefix" an die Subnetze der Opnsense automatisch zu verteilen?

Ich habe unter der Opensense => WAN Schnittstelle folgendes angekreuzt:

* IPv4 + IPv6 DHCP
* IPv6 Präfix anfordern
* IPv6 Präfix Hint senden


Soweit scheint das auch zu funktionieren. Der von Vodafone vergebene x:x:x:x::x /59 Prefix wird als x.x.x.x.x /64 Präfix an die Opnsense WAN Schnittstelle weitergereicht.
Aber wie bekommen die Subnetzte der Opnsense nun automatisch Ihren zugehörigen Prefix bzw. Adressraum?

Vielen Dank für den Hinweis.

Um es den nächsten Fragenden etwas zu erleichtern,
habe ich einige Posts bzgl. Opnsense als WLAN AP angehängt:

https://forum.opnsense.org/index.php?topic=31393.msg151381#msg151381
https://forum.opnsense.org/index.php?topic=25981.msg125314#msg125314
https://forum.opnsense.org/index.php?topic=12755.0
https://forum.opnsense.org/index.php?topic=28266.msg137245#msg137245

Mit freundlichen Grüßen

Transmission

Guten Abend,

ich nutzte eine APU2D4 mit einer Atheros WLAN Karte (2,4GHz).

Ich habe diese als Schnittstelle mit folgenden Einstellungen eingerichtet:
https://docs.opnsense.org/manual/how-tos/interface_wireless_internal.html

Nach einem erfolgreichem Login und einer Nutzung von ca. 7-10 Minuten fliegt das Testhandy immer wieder aus dem WLAN. Bei erneutem Verbindungsversuchen erhält es keine oder nur kurz eine IPv4 Adresse und fliegt wieder heraus bzw. trennt die Verbindung.
Um wieder eine kurze stabile Verbindung zu erhalten, muss ich zwangsläufig ca. 10 oder mehr Minuten warten.
Nach jeder erneuten Verbindung wiederholt sich obiges.

Ich finde jedoch den Fehler nicht und habe vorerst das gleiches WLAN Netz ohne Radius eingerichtet und stoße auf das gleiche Problem ohne eine Lösung bzw. den Fehler zu finden.

Ich hoffe, es gibt dahingehende Erfahrungswerte mit evtl. Lösungsansätzen.

Hello lovely Opnsense forum,

I know this post is a little bit old, but I would like to post the actually configuration.


# install

Code Select Expand


pkg install getdns

# if you use DNSSEC aktually, there is no need for you to use the command down there for initial the trust anchor from unbound, ten there it is allready
# if you doesn't use it to day, use the folowing command:

Code Select Expand


su -m unbound -c /usr/local/sbin/unbound-anchor

# configure stubby to run - from NO to YES

Code Select Expand


nano /usr/local/etc/rc.d/stubby


Code Select Expand


: ${stubby_enable="YES"}


## write config
# i use the preconfigured config
# first, in there are functional comments for almost all commands.
# second, this commands comes with mostly useful preconfigured strings / variables

Code Select Expand


nano /usr/local/etc/stubby/stubby.yml

# add / rewrite the the following commands:

Code Select Expand


# dnssec_return_status: GETDNS_EXTENSION_TRUE
# the stuby doku don't know this command -> older versions also?
# actually the command is this:

dnssec: GETDNS_EXTENSION_TRUE # remove #

listen_addresses:
  - 127.0.0.1@8053 # add specific port
  #-  0::1 # important!: if you don't use ipv6 -> comment out;
  # if you use ipv6 the set the right port; for example: "- 0::1@8053"
# otherwise unbound can't srart, becouse without port, stubby uses the same port: 53, and stubby start faster then unbound after a reboot

# tls_ca_path: "/usr/local/share/certs/ca-root-nss.crt"
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt" # add this line

# for not sequentially using the listed upstreamserver,
# but for randomly using
round_robin_upstreams: 1 # add this line

dnssec_trust_anchors: "/usr/local/sbin/unbound-anchor" # add the right path

tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" # remove #
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" # remove # be aware: Use it only with OpenSSL; don't use it with LibreSSL -> see supplement
tls_min_version: GETDNS_TLS1_2 # remove #



You can use the test servers in the yml file, but i have add almost all servers from the post below.

# now two methods to  verify QNAME minimisation
drill txt qnamemintest.internet.nl
# or
dig txt qnamemintest.internet.nl +short
# The results in any of these scenarios will show either:
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
# or
"NO - QNAME minimisation is NOT enabled on your resolver :(."
# Reference from the post below:

https://discourse.pi-hole.net/t/unbound-and-qname-minimisation/10038/4
# You will and should get HOORAY ! - if you used the name servers listed in this guide for your Stubby configuration.
    # Note: Starting with Unbound 1.7.2 qname minimisation is enabled by default.
    # However, I still add these settings manually.
    # These settings are entered under Unbound " Custom Options":
    qname-minimisation: yes
    qname-minimisation-strict: yes
    harden-below-nxdomain: yes

I doesn't found these three variables in the standard config in /var/unbound/* and the unbound documentation is not really informative =) :
https://unbound.readthedocs.io/en/latest/topics/privacy/qname-minimisation.html
These are the facts why i add there to the unbound config also (GUI).
After upgrade to 21.1, unbound want start with these three commands (if unbound doesn't start, you can check the config with

Code Select Expand

unbound-checkconf /var/unbound/unbound.conf) also i removed it and test the command below again:

Code Select Expand


dig txt qnamemintest.internet.nl +short


..you should see the hoooray again =)

After you save the config in the GUI, you can find it in

Code Select Expand


nano /var/unbound/unbound.conf


# set a startscript to run the stubby script ( /usr/local/etc/rc.d/stubby) after boot

Code Select Expand


nano /etc/rc.conf.d/stubby


Code Select Expand


stubby_enable="YES"
stubby_bootup_run="/usr/local/etc/rc.d/stubby"


# Save and exit , then make the file executable

Code Select Expand


chmod 755 /etc/rc.conf.d/stubby

# I don't know why directnupe set permissions with chmod to 744 and then set the permissions with a+x to 755???
# Anyway, thanks to directnupe to the introduction!

# Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS

"UNBOUND" "GENERAL SETTINGS"
"Network Interfaces" =  Select ALL !

# Under Custom options enter the following below the three Qname variables:

Code Select Expand


server:
do-not-query-localhost: no
forward-zone:
name: "."    # Allow all DNS queries
forward-addr: 127.0.0.1@8053


# set

"Outgoing Network Interfaces" = Select ALL !

# Make sure the box for "DNS Query Forwarding" is unchecked
# Save and Apply Settings
# Next go to

"System" > "Settings"  > "General Settings"

# and set the first DNS Server to

127.0.0.1

# with

"no gateway"

# selected

# Make sure that DNS server option

"Allow DNS server list to be overridden by DHCP/PPP on WAN"

# is unchecked
# and DNS server option

"Do not use the DNS Forwarder/Resolver as a DNS server for the firewall"

# is unchecked also
# save all

# log in to ssh and check stubby works perfectly
# run:

Code Select Expand


stubby -l


# go to GUI under
"DNS check"
# and check out an ip from a website
# after this, go to ssh terminal and check the logs (stubby -l)
# is everything is fine (ip and logs), then restart opnsene and enjoy
# note: it is a good idea to check the DoT DNS servers in stubby.yml every half year

Afterwords, it is a good idea to check these boxes in Unbound :
hide-identity and hide-version.

So I hope this post trigger you to run DoT with verification and not only unbund to use Dot without verification.

kind regards

transmissionend


supplement / usecase LibreSSL:

1. At the moment, you can't use LibreSSL with the "tls_ciphersuites". This command isn't working.
If you use the command, stubby can't resolve any DNS query. You get the message:  "This LIbreSSL version does not support configurating cipher suites"

2. When you moved from OpenSSL to LibreSSL, you have to set stubby to enable again: "/usr/local/etc/rc.d/stubby"