Messages

Looks like you were right ! Only posting relevant parts of the log (last three lines are actually the last three in the file) but I definitively missed this when it went through.

Code Select Expand

# opnsense-update -G
...
os-realtek-re-1.0: already unlocked
...
realtek-re-kmod-1100.00.1401000_1: already unlocked
...
[184/209] Upgrading realtek-re-kmod from 1100.00.1401000_1 to 1100.00.1402000_1...
[184/209] Extracting realtek-re-kmod-1100.00.1402000_1: .... done
...
[209/209] Reinstalling os-realtek-re-1.0...
[209/209] Extracting os-realtek-re-1.0: .. done
pkg-static: Fail to rename /usr/local/etc/rc.loader.d/.pkgtemp.50-realtek-re.x4XvZnhNXmT0 -> /usr/local/etc/rc.loader.d/50-realtek-re:No such file or directory
#

I have no idea what caused it... I never use the shell, but I did numerous setting updates in the past and went through some sunday-hobbyist incidents (burned NIC, power cuts, hot removing of cables, etc.) ; therefore I'm not too surprised such a glitch could happen.

Let me know if I can help to anything else :) thanks again

Hi Franco,

Thanks for your feedback.

Unfortunately I didn't keep track of the firmware upgrade log when I rolled it yesterday... I'm not sure it's saved somewhere as I'm running over RAM, but I'll be happy to retrieve it for you if it is.

I'm pretty sure it was the reinstall how did the trick... I've been encountering "link state changed to DOWN" random errors, that persisted when I removed the plugin, but disappeared right after reinstall. I don't remember editing any other setting (except for the brand new dashboard ahah) neither did I switch interfaces, cables or anything related to hardware.

Anyway, thanks again for your dedication. Please let me know if I can do anything to help :)

[Only issue : I had to uninstall, then reinstall the "os-realtek-re" plugin]

Short feedback... I've upgraded from 24.1.10 to 25.1.3 last night.

All went good, a piece of cake for the network hobbyist that I am. Thanks OpnSense team & contributors, fantastic work as always.

Only issue : I had to uninstall, then reinstall the "os-realtek-re" plugin to get my (cheap) RTL8111-based NIC card working properly under heavy load. This is already why I installed it on 24.1 ; I guess the upgrade disabled the plugin, as its version (1.0) didn't change.

Unfortunately, even if FreeBSD is stating RTL8111 to be supported in 14.2 (which is the version OpnSense 25.1 relies on), the test I made with plugin disabled were unconclusive.

https://www.freebsd.org/releases/14.2R/hardware/

I know neither third-party plugins or FreeBSD development are under the control of OpnSense ; this post is only for raising awareness about this behavior, for anybody who may be concerned.

Cheers :)

I recently migrated from the "legacy" OpenVPN client configuration to the "instance" one.

I'm not skilled enough to give a valuable opinion about which one is best. However since migrating I'm having a strange issue, that I believe could be because of the "Bind address" mentioned earlier in this thread.

I'm playing with multiple OpenVPN and Wiregard clients; most of them are in use at random times during the day and I strongly suspect some connections are not keeped-alive continuously.

From time to time, one of the clients will randomly (and silently) redirect all traffic through another one; which mostly shows up on the "Traffic" bandwidth graphs, where one interface clearly correlates the other in both directions. The problem is resolved by restarting one of the two clients involved.

I do believe this can be caused by the "Bind addresses" being left empty - most of the time, connection or keep-alive is done through WAN ; but not always.

I'm lucky enough to have a fixed IP address; I've set up the field accordingly, restarted all OpenVPN clients - works fine so far. As I stated before it is a random issue (sometimes days before it happens), I'll keep you all posted with the results  :)

EDIT. Didn't work :( same behavior all over again, this time between a Wiregard client and an OpenVPN one. Looks like OpnSense is using the OpenVPN tunel to establish the Wiregard connection; but there's not "Bind address" option in the later, so I guess it's not the same issue after all.

EDIT 2. Finally found it :) the issue was indeed caused by migrating from the legacy client configuration to the new one... My OpenVPN provider is pulling routes when establishing a connection, leading all further traffic - including other VPN connections, such as Wireguard - to use it to access the larger network :P This behavior was previously corrected by the "Don't pull routes" option, but in the new interface one has to define the "route-nopull" option.

[AND]

Hi everybody

Quick post as I ran into a similar issue ;D Made me scratch up my head for a good while, hopefully with the help of all the fine folks here I managed to get it working !

The solution I found appear simpler than the previous one, but it could lead to a different result. I'm not good enough in networking to find out the difference anyway - but I'm sure one of you will :)

On 24.1.9, assuming you already have a Wireguard instance (and gateway) running, with "Disable routes" option checked...

Go to "System > Settings > General" under DNS configuration and select your WG gateway ; then, make sure that the gateway AND the Wireguard VPN instance have the same, fixed IP - the trick being : the later one is hidden :P under "Advanced mode" when editing the instance in "VPN > Wireguard > Instances".

Once done, routing is pretty much automatic - DNS traffic is routed through WG without having to define any route or editing the firewall 8) I'm using it on top of AdGuard and UnboundDNS