Messages

[...]I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.[...]

Improving FreeBSD's pf is an obvious goal, but pining for OpenBSD's implementation doesn't seem realistic. Unfortunately any attempts at real improvement would run straight into the politics being discussed here.

Yep, for sure.

Nope, cant volunteer, so basically it sounds like its still not clear if its properly resolved upstream, my view is, if it isnt regression tested, it shouldnt have been committed in the first place, which aligns with the view that Dok posted.

So another broken network path in FreeBSD potentially lasting several years and multi generations of release.  At least OPNsense has backed it out.

I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.  This situation is part of that fallout with picking specific patches from OpenBSD in the hope of fixing it on FreeBSD.  A Frankenstein PF.  I did mention this on reddit not that long ago and ironically the guy who responded to me quite angry is the same person making the commit's in that big report.  He really did not like me mentioning that.

I can offer my 5 pence on that long bug report conversation.  I apologise if anyone is offended by it.

First, my view is that the nature of the bug is pretty scary, we have had issues over the years with weird IPv6 behaviours, weird PF issues, which can be very frustrating for people operating misbehaving networks, if it also affected ICMP packet too big stuff, then it is especially nasty, and I think its clear regression testing is inadequate on FreeBSD. 
Second I can see the asks's to back out the original security patch, as a end user I definitely see the logic in the request, but I very rarely see developers back out code, they usually die on that hill.  I agree with dok's comment that the issues the patch was causing are far more serious than a vague low risk security bug. 
Third, I think the idea to use a vanilla FreeBSD kernel on OPNsense to get the bug moving again was sound and should have been done right away after it was suggested.  It doesnt matter if its felt it was wrong, just do it to satisfy all parties for democratic reasons. 
Fourth was some bickering which was not a good luck on anyone. 
Fifth the entire bug report makes FreeBSD look pretty bad in many areas, which its lask of regression testing as well as urgency in getting the issue fixed, even if it means backing out.

Is this still not properly fixed in FreeBSD upstream?

In the UI settings.  Read the docs as suggested above.

ZFS on opnsense already defaults to 90 sec async flush interval to help wear, I agree with the others, use a ram disk when using SSD storage.

Hi, will chime in here.

One thing I always considered a strength of opnsense was its dashboard, and will admit was surprised to read in the changelog when it changed, the "modern" phrase as I already considered it modern.

I updated and now have had a moment to generate some thoughts on it, I will try to be as respectable as possible as I respect the work that will have gone in to it.

I think that you can drag stuff around, resize and such is nice.  I cant remember if you could do all of that on the old dash, but that is nice.

I also like seeing interrupt usage on the cpu graph.

But some of the widgets have regressed on the information they provide.  I will give some examples.

Old dash widgets, you had all memory usage view on the screen, could quickly eye ball it, now have to move mouse over a half pie chart, and get some very limited information. 
Same issue with interface stats, although I think all the info is still there when mouse is in right place, I still have to move the mouse to see it.
The firewall widget, I am not sure is working, previously I would see live log entries flow in the widget box, now if I hover over it is just a number 1, and if I click it, then takes me to firewall log.
Disk usage widget used to show partition info, now its a generic used and free.

I think the main dash is ok, just I think the widgets need to be able to do what the old widgets did, no lost functionality.

Did ISC reveal the reason they abandoning software that works in favour of something thats incomplete and buggy?

I am guessing they have a new generational of developers who dont want to work on the old code so its the typical solution of rewriting.

Please dont remove ISC DHCP from future builds of opnsense.

I am just giving you an answer which might explain why it sits there for a long time on the installer boot.  I could I guess revert the assignments on the host and see if it speeds things up.

Well your case is a local install, if OPNsense is remote you need to at the very least have some kind of initial WAN access.  Even if its to setup a VPN.

Strange. What sort of WAN are we talking about here?


Cheers,
Franco

In my case its not even WAN as the auto assignment wrongly assigns the port.

OPNsense running in VM, two nic's one for WAN and one for LAN, it assigns the LAN port as WAN, and vice versa and I have to wait quite a while on the live system boot, interestingly the first boot post install is much quicker.

Output when vmstat -m ran manually.

# /usr/local/bin/vnstat -m

vtnet0  /  monthly

        month        rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       Mar '24      1.23 MiB |    8.28 MiB |    9.50 MiB |   32.96 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated    726.49 MiB |    4.79 GiB |    5.50 GiB |

Code Select Expand

[bf40d3d6-8e4f-4c8e-9815-621df3882190] Script action failed with Command '/usr/local/bin/vnstat -m ' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 44, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/bin/vnstat -m ' returned non-zero exit status 1.

The stats are accumulating.

Thanks, that does work.

So what happened with this? is a bit bizarre each icmp type needs its own rule.

I think OPNsense could do with an option on the console for punching an initial hole through to the UI for a specific WAN IP, I think a rule that specifically whitelists an IP is fine.  The default LAN only assumes one is running the firewall local to them so they can just access over a LAN, but this falls apart on remote installations, and adding a firewall rule in the console, when the whole software is designed to be managed from the UI is clearly not a clean way of doing it, hopefully a solution can be found.

As it stands now it is pfctl -d disable the entire firewall, then going into the UI to add some kind of management IP ACL rule for access the UI and finally turning the firewall back on with apply.