Messages

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. :)

It might actually not be the firewall's fault (my rules are in place and are working well for about 5 years now), but some trouble with the automatic gateway selection and/or openvpn.
I have a static route to my cable modem in the routing table through the physical interface the modem is connected to. If i disable the openvpn gateway i can ping the cable modem all right, but if i enable the openvpn gateway (the static route is not set up through it nor am i pulling routes from the openvpn server!), i cannot ping the cable modem, as the router would send the packets to it through the openvpn interface despite the static route, gateway priority and default route setting anyway!

what version did you upgrade from?

At first from 21.7.7 to 21.7.8 then to 22.1 back to back.

by what rule did the firewall allow this traffic before adding a new rule?

This traffic i see is mostly my pc (and other devices on the same network segment) trying to connect to the firewall for DNS and NTP (ports 53 and 123). The first example rule did allow this as the [local addresses alias] contains all unicast, multicast and local(host) addresses used on my networks. The strange thing is that the firewall tries to use the vpn gateway in the second example rule to route traffic to itself.

No worries. :)
I don't have much experience yet, but the latest one (v4.15.0.2) seems to work fine, even with IOMMU (amd-v) enabled in BIOS despite the recommended and default setup. (It is needed for passing through the wifi to an OpenWRT vm running under OPNsense to have better hw support - though this should arrive in FreeBSD soon, so need for the OpenWRT vm.)

Hey,

I have in fact just upgraded an apu4 from 21.7.1 to 21.7.8 to 22.1 a few hours ago, it went smoothly. (I do have firewalling/routing issues on my production boxes under 22.1 but that's a different question.)

I also had GPT errors at one point, for me it was because of an older linux installation existed on the apu4 at first. (I think if you install OPNsense on the internal SSD, the GPT errors should go away.)

What firmware version ( https://pcengines.github.io/ ) do you have on the apu4? That could make a difference.