Topics

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.

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.

[below]

Updating to 22.1 i noticed that my firewall rules stopped working as they should (they were fine up to the 22.1/FreeBSD 13 upgrade).

If i have only a single firewall rule like:

• allow in quick ipv4+6 * [local addresses alias:*] to [local addresses alias:*] through [default] gw

i can access my local machines just fine, but if i add another rule below this like:

• allow in quick ipv4+6 * [local addresses alias:*] to [local addresses alias:*] through [default] gw
• allow in quick ipv4 tcp/udp [interface net:*] to [any:*] through [vpn] gw

then the connection breaks as according to the firewall logs the router tries to route its own [interface address] through the [vpn gw]. I can see blocked outgoing packets on the vpn interface with a destination of the router's own originating interface address. (Say [interface net] is 192.168.1.0/24, [interface address] is 192.168.1.1, then i see blocked outgoing traffic on the vpn interface with destination of 192.168.1.1.)
The system routing table looks fine (though the whole 'Use' column has 'NaN' values), and all connections work from the router itself (which is not firewalled).

Has anyone also experienced this? How should it be fixed without having to have an [allow any to any through default gw] rule, which obviously makes routing and firewalling pointless?

Hello,

If time and developer capacity allows I would really love to see Bitmask VPN (https://bitmask.net/) among the plugins. The main reason would be the ability to use RiseupVPN (respectable community effort, good security practices, does not need registration, free even for p2p; it might be the perfect choice for newcomers to the infosec field on a budget).
What do you guys think?

Cheers.

Would you guys consider optionally (opt-in) integrating some extra signatures for ClamAV into the GUI for general public use to make it more reliable against fresh malware? (The SaneSecurity signatures look very promising if I had to name one.)
There is a ready-made bash script to integrate and update the most widely used sources: https://github.com/extremeshok/clamav-unofficial-sigs .
If you guys consider it as something worth doing I'll help converting the script to standard csh (stripping off the functions) if that helps - or maybe it could be integrated into the GUI separately by source and then it's even comfortably configurable from the browser.

What do you think?
Cheers, Istvan

[gop set 10]

Hi guys!

Thank you for all your hard work making this amazing OS possible!
I am experimenting with OPNsense on a Wyse 7010 box for a few months now (starting with 16.7.10 I think). [at the end of the linked document are some crude hardware specs, but these are the best I found]
It generally is working well, though I think I spotted a few things that might make OPNsense even better:

- a manually installed system won't boot after the install is complete! (guided install works fine though) I think this might have to do with the box being an EFI system (the guided install even asks if I want a GPT or MBR install), and going with the defaults (use the whole disk for / and make it bootable) in the manual install creates an MBR/BIOS system.

- upgrading from 16.7 to 17.1R1 resulted something like a serial port issue mentioned in the PFsense forums a few years ago (something like this) even though this box does not have any serial ports, not even headers or options to disable in the firmware setup. I just found a newer firmware for this, and will try to update it later on tonight, but freshly reinstalling 17.1 solved this fortunately.)

[the following are definitely upstream FreeBSD issues, but might help someone as I found a workaround for these]
- the VGA console output through DisplayPort is garbled (looks like 640x480 with horizontally offseted lines), gop set 10 at the boot prompt and/or in the loader.rc.local solves it for most modern displays (1920x1080);  solution [note: this is a UEFI issue, not FreeBSD specifically, a firmware update might help]

- the AR938x wifi chip has some problems associating with the AP using WPA2 in spite of supposedly being supported by FreeBSD. I found that it can be (partially) solved by booting up the box with Alpinelinux, connecting manually and then restarting it with OPNsense. (I said partially because it was working with 16.7 before;  with 17.1 it associates but the connection is not working either because of a configuration issue or the driver itself: pinging an arbitrary IP or the AP itself results in network unreachable messages.) I will also try to investigate this further tonight and try to see if connecting in linux solves the problem because it registers the card with the AP or is it a firmware glitch in the wifi card?

I will try to keep you guys posted.
Thanks for all again! :)
Istvan