Messages

The update check for Adguard Home is no longer working...

Probably a temporary network issue, unrelated to python 3.11.

There's nothing to check for really as long as there's no new release on GitHub

...
upgrade initially hung in GUI but completed cleanly via CLI (pkg update -f, pkg upgrade, reboot).

This is wrong.

There's never been any official OPNsense guidance about running those pkg commands.

Also, this is not Linux. Reboot and Shutdown -r do different things, and you never want to do a reboot in (OPNsense) FreeBSD

>> Can anyone else confirm?


No. A bit slow but working fine. Only finding was hostwatch not on automatic which I wasn't surprised about, easy fix

FWIW I have 4 FWs on RACK since December and all are running fine on FreeBSD14.3/OPNsense25.7/26.1

You still have time to reconsider.

With a vpn, WireGuard or OpenVPN you'd only allow specific users to access the resource. Otherwise the whole of the internet can hammer the nas at will.

Assuming you'd go for WireGuard, you'd create everything that's needed and only send the third party a QR code.

Should there be a breakage of the vpn, the nas data is still accessible without issues.

_IF_ you can have ddns running on the clients to connect then you can simply lock down the wan access to the reverse proxy by creating a rule with source alias < ddns clients >, and then get rid of the token altogether.

Anyway, food for thought. The goal is simpler and more secure, one way or another.



Should there be a faulty nas update that breaks 2FA - you're in a heap of trouble.

You're forgetting a key principle here - KISS

If you have a vpn there's no need to expose anything synology to the internet nor do you need 2FA.

Making sure that the management port is in a trusted vlan is all you need. Everything else way overkill.

Another thing I didn't see mentioned here:

Did you try disabling the auto negotiation on the ports ?

Is the issue reproducible on other ports?

Can you swap igc0 with another port to see if the same drops happen?

If you can confirm the issue on two ports then the next step I'd try after confirming with Deciso would be to update the firmware on one of the ports to 2.31 which is the latest we have publicly available and see if the issue persists.

Most likely Franco will check this out next week and see if there's something that can be done here or if it's an issue that needs to be fixed upstream

If the packets never touch the cores doesn't it make just a glorified switch running at wire speed?

Is there still full state tracking and traffic accounting?

In other words, as long as there's a HW bypass how and where is OPNsense still in control?

There should be no need for Kea to run on a WireGuard interface. Did you try deselecting  it in the settings ?

Only if something goes terribly wrong with 15.1 which is planned for 26.7

The relevant networking bits from 14.4 are already in OPNsense, some since the 25.7 days actually.

You can start by posting a health check and the output of this command

Code Select Expand

ls -ltrh /var/crash/

1) Kea didn't break, works just fine for most of us.

2) Kea is finicky and has had issues in the past with the machine hostnames. It is possible some restriction could have been introduced the latest update

3) You'll need to find out what's so special about the machine hostname that is not getting the reservation anymore and likely open an issue on GitHub opnsense/core

Curl was just updated today after a 3 month hiatus that skipped 8.18

https://www.freshports.org/ftp/curl/


It will definitely be in 26.1.6. There's no immediate danger in OPNsense in the meantime.