Messages

Thanks Franco, 26.1.7_3 solved this for me.

[edit:] @llama6668: I thought this was to do with cron as OPNSense actions are cronjobs under the surface, "not found for user root" made me think that the appropriate action or line in root's crontab was not generated correctly

After upgrading to 26.1.7_1 "action !.qfeeds.stats not found for user root" is littering the logs.
Reapplying Qfeeds settings in the GUI results in timeout and errors as well.
Something is off with Qfeeds settings or tasks i suppose.

Authpf(8) is a tool included in the FreeBSD base system - but not included in OPNsense - that can be used to configure dynamic network access based on successful SSH login for added security when using OPNsense as a bastion/jump host. Since authpf is part of the FreeBSD base it should work more-or-less frictionless with pf from CLI for advanced usecases (GUI controls could be developed but probably not worth the effort).
I suggest authpf to be included in OPNsense to be used if needed.

The tor plugin does not seem to work for me on freshly reinstalled v26.1.3 OPNsense boxes.
The plugin is seen as running but there is no traffic routed through it (no circuits, streams are estabilished).
It was working on v25.7 series. Is it just me?

Nevermind, it was uBlock as it turned out. (Don't know why the widget sizing breaks in that case though.)

I still have an error loading the Traffic widget on all my systems which in turn makes the whole dashboard unusable: a modified/locked dashboard cannot be saved.
Is there a way to disable/remove the Traffic widget when there isn't a close button for it?
(Previous widget settings are manually purged from the config xml file and the default theme is used.)
Cheers.

Reduce your possible causes by removing bits (temporarily) until it works properly and investigate the last removal. Either that, or start with a clean slate and add features until it breaks.

Sure thing. What breaks is monitoring a wireguard interface with suricata. Taking suricata out the equation (at least on the wireguard interface) everything works as it should.

This for now, otherwise we will get more of those and then blocking reboots will be more prominent. Remember, you are asking for a manual failsafe but a lot of expectations and automation will not trigger / know when to trigger it. Worst case on major upgrades you could kill the operating system killing the upgrade taking "too long".

I wasn't thinking of such a sophisticated solution, only sticking a 'reboot' at the end of /usr/local/etc/rc.reboot just in case. Best case it wouldn't even be reached, worst case it would forcefully reboot the router if 'shutdown -or now' doesn't manage for some reason. No accidental reboot due to delay would be involved.

[edit:] it wouldn't help. :( '/usr/local/etc/rc.freebsd halt' is not able to kill suricata, that's why the whole shutdown process goes sideways. (Suricata on my boxes can only be killed by SIGKILL but not SIGTERM for some reason.)

I suspect the culprit might be suricata (if you are using intrusion detection), that does the same for me lately as well. (see https://forum.opnsense.org/index.php?topic=34205.0)

Since a few minor versions my routers (apu3 and Fujitsu Futro thin clients) are not able to reboot properly from the webgui or after an update. I suspect this might be caused by some faulty suricata-netmap-wireguard interaction (that is giving me trouble sometimes).
The problem is that the shutdown script is able to stop enough services not to be able to log back in or continue to use the router but not enough to actually reboot the router itself. (If i am lucky i can log in to the webgui just to restart sshd to be able to log in through ssh; sshd does not accept my user/password after a failed reboot attempt for some reason unless restarted.)
Logging in through ssh and issuing a 'sudo reboot' successfully reboots the router every time (when it is possible to log in at all). So i would suggest adding a forceful 'reboot' after trying to gracefully shut down services in case it did not work as that would increase resiliency a lot.

[--redirect-gateway def1 ...]

I'm fairly certain that's the configuration required for split-tunnelling, which you would need to bypass the VPN for DDNS updates. This effectively disables the use of --redirect-gateway def1 ... when pushed (which it typically is).

Sure, it was just working differently with OpenVPN 2.4: the routes were added even with 'Don't pull routes' checked.

Yes, I think something changed with OpenVPN 2.6. But I'm not sure if it is the intended behaviour or not (to me the current behaviour seems more logical to be honest).

Hi Sam,

I did face the same problem as yourself in the past. The solution is if you are using unbound to resolve your DNS requests is to use 'access-control-view' records - there might bo something similar for the other DNS servers as well.

Under /usr/local/etc/unbound.opnsense.d create a .conf file (local.conf for example) with something like

Code Select Expand


access-control-view: 192.168.1.1/24 lan

view:
    name: "lan"
    local-data: "fw01 IN 192.168.1.1"
    view-first: yes


Reload unbound and you should be good.

Thanks for looking into this Franco! In the meantime I found out that probably OpenVPN was the culprit in my case (at least partly): it was working fine until the 23.1.7 upgrade, then the connection would build up, but the routes were not added to the routing table. So I unchecked the 'Don't pull routes' and 'Don't add/remove routes' switches and all was well until reboot as it seems. Now I have noticed that there was a 0.0.0.0 route added to the routing table (superseding the default route!) which of course redirected all traffic through OpenVPN - the dynamic DNS request among them - but still it is strange that it also overtook the dynamic DNS's WAN interface address.

[edit] So far it seems to be working fine having 'Don't add/remove routes' checked and 'Don't pull routes' unchecked in OpenVPN, but I still need to phisically travel to all the other routers to correct this on them as well so they can interconnect again. :/

It seems like the new routing subsystem (the one integrating the gateway switching) broke the ability to determine the IP address of an interface if there are other (VPN) interfaces going through them. For me none of ddclient's methods work reliably to find out the IP of my WAN interface (was working fine until now).

I don't know if it is also stemming from this or not but my local Wireguard LAN interface does not come up on the routers, so this change entirely brought down my so-far perfectly working infrastructure interconnected thorugh Wireguard. I am eagerly waiting for a fix, now that I will have to visit all the remote places where the routers reside...

Sorry for the long delay, work happened... :(
I have made a secret-redacted config xml to show my config, and in the same time i figured out it was actually an OpenVPN bug, it was just a coincidence that it's rule came after the ones it broke in the firewall.
v22.1.1 fixed it. :)