Messages

@meyergru Thank you for your support and for your clear answers — much appreciated.
We have now disabled the auto-update on the site. We were not aware that it was enabled, so it's likely that the latest updates caused the issue, which initially made us think it was related to OPNsense.
We will keep a close eye on this from now on.

Do you use mixed tagged and untagged traffic on the same port or any VLANs at all? FreeBSD is not too good at doing that.
Also, the latest beta releases of Unifi switch software have problem with mixing up traffic as do some newer Unifi switch lines - especially when they boot up.

There can also be loops introduced by Unifi APs meshing together.

Did you verify that going back to an older OpnSense release fixes the problem? In that case, there may be driver "fixes" for your network hardware which are the culprit? You did not by any chance, use any type of network offloading?

We are using VLANs, and the Unifi APs untag the traffic. This issue is happening consistently across three different sites (my home, my kids, and my parents), all running the same setup. The only real difference is the OPNsense version — the problems only appear after upgrading.

Environment details:

Switch/AP: UniFi Switch US-24 PoE-250W (firmware 7.2.120)

OPNsense: 25.7.1_1-amd64

Base OS: FreeBSD 14.3-RELEASE-p1

SSL: OpenSSL 3.0.17

On older OPNsense releases, we did not see this problem, so it seems tied to the newer release. No loops are showing from Unifi AP meshing, and configs are otherwise identical across the sites.

Hardware Offloading Settings:

Selected Disable hardware checksum offload

Selected Disable hardware TCP segmentation offload

Selected Disable hardware large receive offload

VLAN hardware filtering: Leave default

Suppress ARP messages: Disabled

Allow IPv6: Disabled

So far, no change in behavior after disabling hardware offloading.

Hello everyone,
I'm hoping to get some advice on a strange issue I've been running into since updating OPNsense to version 25.7.
After the update, the uplink port on my UniFi switch that connects to my OPNsense box is showing as "STP Blocked" in the UniFi controller. My network topology hasn't changed, and everything was working fine before the upgrade. The link between the two is a direct cable, and there's no physical loop in the network.
This is causing a major problem, obviously, as my internet connection is now down. I've tried a few basic things like rebooting both the OPNsense machine and the UniFi switch, but the problem persists. The UniFi controller logs show "Port disabled by STP to prevent a network loop."
Has anyone else experienced this after the 25.7 update? I'm looking for guidance on where to start troubleshooting this.
Things I'm considering:
 * Are there new STP settings in OPNsense 25.7 I need to be aware of?
 * Is OPNsense now broadcasting something that UniFi is interpreting as a loop?
 * Are there any settings in UniFi I should check, like STP priority, to force it to prefer the OPNsense uplink?
Any advice on where to look in the logs on either OPNsense or UniFi, or specific commands to run, would be greatly appreciated.
Thanks in advance for any help!

Don't use porcelain commands, because these change over time. Either the console option 12 or the GUI firmware.


Cheers,
Franco

thank you so much, i'll update it and report back.

It's not strange. The screenshot speaks for itself.


Cheers,
Franco

Is updating to the latest release sufficient, or should I run the following commands to update?
textopnsense-update -UR
opnsense-update -p
opnsense-update -kr
reboot

HardenedBSD 12.1?

Time to update IMO.


Cheers,
Franco

i am on
Versions
OPNsense 25.1.12-amd64
FreeBSD 14.2-RELEASE-p4
OpenSSL 3.0.17

its strange it does shows freebsd 12.X

the error

this the error we found out after the box is not respondig.

System details:
   •   OPNsense version: 25.1.10
   •   Hardware: Sophos GX125
   •   Install method:  SSD
   •   Typical uptime before failure: ~7 days
   •   Active services: NAT, DHCP, DNS Resolver, WireGuard
   •   Plugins: No heavy plugins like Zenarmor or Suricata installed

⸻

Symptoms:

Roughly once per week:
   •   The Web GUI becomes unreachable
   •   SSH access is also unavailable
   •   However, internet access still works, and WireGuard remains active
   •   I can still access remote servers via WireGuard tunnels
   •   Some managed switches (on LAN) become unreachable until a manual reboot

After reboot, everything works normally for another week.

⸻

What I've observed:
   •   No crash reports appear in System > Crash Reporter
   •   No partitions appear full (df -h shows healthy disk usage)
   •   Health graphs show memory usage gradually increasing
   •   No errors stand out in /var/log/* before crash (though I may be missing something)
   •   The system is still routing traffic, which suggests the kernel/network stack is alive

⸻

Suspicions:
   •   Memory or resource leak affecting web/ssh daemons?
   •   Lighttpd/nginx and sshd silently dying after prolonged uptime?
   •   Cron job or logrotate process causing silent failure?
   •   ARP/cache/broadcast issues causing LAN-side disconnects?

⸻

Questions:
   1.   Is this a known issue on 25.1.10 or the Sophos GX125 platform?
   2.   How can I better log or monitor what's failing before GUI/SSH becomes unreachable?
   3.   Any specific services I can safely restart from the console (if reachable) to avoid a full reboot?
   4.   Would a scheduled reboot (e.g. every 6 days) be a safe temporary workaround?

I'm happy to provide more logs or config info if helpful.

Thanks in advance for any insights or suggestions!

Hi all,

I'm running OPNsense 25.1.7_4-amd64 (FreeBSD 14.2-RELEASE-p3, OpenSSL 3.0.16) on a hardware appliance (not virtualized).
Today I noticed that the LAN interface is showing 5 errors in the interface statistics.

The network seems to be functioning fine, but I would like to understand:

where these errors come from,

whether I should be worried about them,

and what steps I can take to troubleshoot the issue.

Questions:

What types of errors are reported under the LAN interface stats (CRC errors, packet drops, collisions, etc.)?

Is there a log or diagnostic view in OPNsense where I can see more detail about these errors?

Could they be caused by bad cables, switch ports, or NIC driver issues?

Is a small number of errors (5 errors) considered normal, or does it point to a potential problem?

What steps would you recommend to troubleshoot and hopefully eliminate the cause?

System Details:

OPNsense version: 25.1.7_4

FreeBSD: 14.2-RELEASE-p3

Appliance type: hardware

LAN NIC: Intel(R) I211 (Copper)

Thanks for any advice or experiences you can share!

Is this the same configuration as PPPoE? Will the authentication be handled automatically?

Yes. The server will negotiate the authentication protocol with the client (OPNsense). All of this is automatic.

Thank you for your response.
I've got it configured, and it seems to be working well. I'm in the process of switching 10 firewalls from pfSense to OPNsense.

Thank you for your quick response.

Is this the same configuration as PPPoE? Will the authentication be handled automatically?
I ask because I don't see any option to select the protocol during the PPPoE setup—will this be managed behind the scenes?

Hi everyone,

We're planning to migrate a customer from pfSense to OPNsense and are currently validating compatibility for their setup.

We've successfully tested PPPoE on OPNsense, but we need to confirm if PAP (Password Authentication Protocol) is supported and working reliably in this context.

This is important for us before moving forward with the migration.

Has anyone used PAP authentication on OPNsense? Any known issues or limitations?

Thanks in advance!

If you need WireGuard VPN access to your network you obviously need to open the matching ports with an allow rule on WAN.  ;) This or I did not understand your question.

thank you for your answers.
your first answer has point me to the right direction. on the firewall WAN i had the wireguard ports on the destination port to any. i specified the incoming port too.

Thank you for your answer, I appreciate it!

Good catch—it's something I hadn't paid attention to.

Would it be smarter to limit the incoming ports for WireGuard, or should I leave them open?

Please find the attached.
the rule has been disabled for now.