Messages

[What is the status of the ZFS issues related to sqlite in FreeBSD?]

As I feared this topic moved away from my original question. My question was not related to hostwatch and its i/o usage.

I don't want to sound ungrateful, but why is my question ignored or answered with something else I didn't ask. I am ok with answers like "I don't know", "never heard of such a thing", "check this ...", but unfortunatelety I just got unrelated answers.

But maybe my question was not specific enough, thus I'll try again:

What is the status of the ZFS issues related to sqlite in FreeBSD?

I didn't want to distract from my original question, which is why I didn't add too much info that is not BSD related, especially since this forum doesn't allow sections or to hide text. As mentioned in my original post, the sqlite/zfs issue in Linux was based on the PR I referenced. I really don't want this in this topic. I'll send a PM.

FreeBSD ZFS experts should know what I was asking. I was not talking about write amplification. The issue is that when using WAL, writes to the DB stall until they basically timeout, which brings the app using it down. The ones that were supposed to fix it, were reverted and the fix for the fix was closed w/o merging. But hey, maybe ZFS for BSD got a fix that solved it and I missed it. This is why I asked. I don't know the status. I only know that sqlite and zfs is usually a no-no.

After reading a few topics here, I have noticed that hostwatch uses sqlite. ZFS has been known for having issues with sqlite.

I have done some digging and there was a PR for FreeBSD in ZFS, which was closed (unmerged) by reverting a previous attempt to fix it.

So I don't really know what is going on. The fix for ZFS on Linux (which was based on the FreeBSD fix) was included in 2.4.0, yet the fix for FreeBSD was reverted.
Maybe the OPNsense devs have an idea what the status is, since they have deep knowledge of FreeBSD and ZFS.

will definitely hit the user regarding the final installation of the ISC plugin since it is the last operation in the upgrade, but this is is neither predictable nor prevalent.

As a weird workaround: any chance you can add a dummy package always as the last package?

I'm not aware of a static mappings issue (yet).

Great, thanks.

FWIW: I mocked around a bit with removing, changing and adding static mappings. Worked as intended.

Nice. Thanks. This makes me happy.

Regular clients finally got addresses, but static mappings still didn't work

@franco if DHCP dynamic addresses worked, this means that ISC was running. But why would static mappings not work? Is this another bug that was introduced with 26.1?

This is rather important to me, because I am using ISC DHCP and a lot of static mappings as well.

when I switch into the shell and enter "hostwatch --version" it shows 1.0.2 even 1.0.9 packet is installed.

Yep, the manifest was not updated: see https://github.com/opnsense/hostwatch/blob/1.0.9/Cargo.toml

I believe the release workflow is not yet stabilized. I will open an issue to make a few suggestions.

Because having to "Port Forward" for something like that was indeed a bit weird...

Yep, I've thought about it for a while and I think the renaming makes sense in this case. The Port Forwarding UI in OPNsense always allowed to do things that are actually DNAT, so all is good.

My "outcry" came from the fact that I actually only used port forwarding rules, thus my previous opinion about the renaming of this item was wrong.

I'm not familiar with other platforms but in OPNsense (at least) DNAT allows to translate both the destination host and/or the destination port.  Both functions in one.

Well, port forwarding is a subset of DNAT functionality (1:1 static translation w/o hairpinning plus port translation), maybe that's why it is renamed and then there will be additional or less options in the interface. I guess I will see. ;-)

n versions prior to 26.1, you can check the NAT rule itself.  IIRC, there were three options.  I don't remember their exact names but essentially one was to do nothing, one was to create an auto pass (without an associated rule), and one was to create an associated rule on the interface

Awesome, thanks. I checked my rules and all have the Filter rule association set to None. So I should be good.

This was discussed in another thread too.

This is a bit strange though. Port forwarding is not the same as DNAT. It's true that DNAT is often used in combination with port forwarding, but that doesn't mean that port forwarding rules should be renamed to DNAT. Hmm, this is rather concerning.

If you have existing NAT association rules on your interfaces

I don't think I have NAT association rules on my interfaces. Afaik I always created rules manually.
Is there a way to find out?

Thanks @OPNenthu

nothing changes except for the ability to set Floating rules on a single, specific interface.

Yep, this might be bad for me. I actually use quite a few of those.

Of course I could move them to the specific interface, but I used the floating rules UI for a reason. It is easier and more convenient to have an overview, especially if you want to clone a rule for a new interface. You don't have to click on every interface to find the rule.
The workaround to create groups with a single interface is a massive overhead in terms of administration. Why not support a single interface instead?

Anyway, I am sure I will adapt. I just hope it's not too much work and that the result won't be less intuitive and convenient.

Thanks for the all the replies. I am still trying to understand how the new interface will look like. Are there annotated before/after screenshots for all the changes available? I have read the link Franco provided about the processing order when I started to use OPNsense (many yers ago), but since I do not use "Rule Automation", the overall processing order documentation was much more helpful to me back then.

While I could glean that the changes mostly pertain to the automation rules and UI, a bunch of posts suggested that the order of other rules (interface, floating, NAT) will change with 26.1.

If this is not the case and if everything will still work without changes when I do not use automation, this can be closed from my side. (Although I am still interested in the current discussion about automation as well.)

However, if there's anything in the UI and/or processing order that will change for anything but automation, I would like to repeat my question: how exactly does it change and what is the difference to the current UI and/or processing order?

I have read the topics in this new 26.1 Series forum and I tried to understand what the new rule system entails.

I couldn't find any documentation or a clear direction and I am worried that my rules stop working, because I am using floating rules quite extensively and some posts suggest that the evaluation order will change with this new rule system in 26.1.

Can you please explain what the new rule system will look like and what the difference to the current one is?

P.S.: I don't have a test OPNsense VM, because I haven't had the time to properly isolate and setup such a test instance. It can't be a clone of my current (physical) OPNsense instance, since it would mess up my network. I would have to setup a system from scratch and create X VLANs for all interfaces in this test VM and then try to replicate my prod rules which would be a nightmare. This is just an explanation why I have to ask instead of playing around and testing it myself.

Yep, I read the script, but it's not working. I had the cronjob (Renew DNS for Wireguard on stale connections) scheduled to run every 5 minutes and it happened twice that the gateway was down but wg2 was not restarted. Of course it happened while I was sleeping thus it was offline for hours. I always had to manually restart the wg2 instance.

Only after I created my script, I never had the problem (of manually having to restart the interface) again. (I get notifications when it happens - only one so far.)

Creating an issue is not that easy, because the gw is usually online. Only sometimes it goes offline and I have no idea why. So I cannot forsee when this will happen and I cannot afford to disable my script and encounter potentially hours of no VPN connection.
Maybe I can add something to my script so that it will only restart the interface automatically when I am sleeping. Although this is a hassle, because I don't wear a smartwatch or a health tracker, which means I have to set a status var manually every time I go to sleep and get up. Rather a no-no on my side.

P.S.: I still think the current architecture has it backwards. It should be possible to trigger a script, when a gateway is down. pinger supports this. There just needs to be a field in the GUI to specify the script to run. As I mentioned before I am not a GUI person, thus I don't know how to do that. Otherwise I would have created a PR already. It's 5 minutes work (if you know how to do it): one field in the UI and invoke the dpinger with an additional parameter.

P.P.S.: Please note that I am not saying that your script is not working. It is not working for me for some reason. I only added my solution in case somebody runs into the same issue and the cronjob doesn't work for them either.

Unfortunately none of the solutions here worked. The Renew DNS for Wireguard on stale connections cronjob doesn't work in my case, because wg reports the connection as active (not stale) even though the gateway is down. So the action that should be triggered to restart the wg service is not triggered.

My current workaround is rather hacky (hardcoded wg service id), but it works. I will look into the script that is triggered in the previous mentioned cronjob. When I first looked into it I saw that it determined the id automatically.

Without further ado...

Use pluginctl -S wireguard to find the id of the wireguard connection. Make a note of that id.
Check which sockets are in use for your GW monitoring: ls -la /var/run/dpinger_*.sock (Make a note of the one you want to monitor. e.g. /var/run/dpinger_INTERFACE_NAME.sock)

Create a file, e.g. /root/bin/check-wg.sh (permissions 0750) and replace the values for SOCKET and WIREGUARD_ID

Code Select Expand

#!/bin/sh

SOCKET=/var/run/dpinger_INTERFACE_NAME.sock
WIREGUARD_ID=ad78e2ad-7ed9-422d-a0b9-ee7ed2795a3

RES=$(cat $SOCKET |cut -d ' ' -f2-)
DT=$(date +"%Y-%m-%d %H:%M:%S %z")

if [[ "$RES" == "0 0 100" ]]; then
    echo -n "[$DT] "
    /usr/local/sbin/pluginctl -s wireguard restart $WIREGUARD_ID

    # If you don't use or want gotify notifications delete the following lines (except the fi)
    TOKEN="$(cat ~/.config/gotify/cli.json |jq -r .token)"
    URL="$(cat ~/.config/gotify/cli.json |jq -r .url)"
    TITLE="check-wg ($(hostname -s))"
    TEXT="Wireguard restarted"
    curl -m 10 -so /dev/null -X POST "${URL}/message?token=$TOKEN" -F "title=$TITLE" -F "message=$TEXT"
fi

Unfortunately you can't add a cronjob by using crontab -e, because any manually added entries will be removed (either after a reboot or firmware update - I didn't check which, but my entry wasn't persisted).

Thus create another file: /etc/cron.d/check-wg

Code Select Expand

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem

*/5 * * * * root /root/bin/check-wg.sh >>/var/log/check-wg.log

That's it.