Messages

Adguard is indeed the "easiest" way to keep large blocklists without butchering Unbound implementation on Opnsense.
It's unfortunate though that the Adguard plugin isn't officially supported as it's the only viable way.
Unless the Opnsense devs move to RPZ, Unbound will continue to consume 4 times the amount of RAM for DNSBL compared to Adguard.

What I've done for both unbound and suricata is to create 2 small bash scripts to monitor their status. If they get killed, they are restarted automatically.

Code Select Expand

root@fwall:~ # cat dnscheck.sh
#!/usr/local/bin/bash

LOGFILE="/root/log/unbound_monitor.log"
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")

if ! pgrep -x "unbound" > /dev/null; then
    echo "$TIMESTAMP: Unbound process not found, restarting..." >> $LOGFILE
    /usr/local/sbin/configctl unbound restart
    echo "$TIMESTAMP: Unbound restart command executed" >> $LOGFILE
fi

root@fwall:~ # cat /etc/cron.d/dnscheck
*/5      *       *       *       *    root   /root/dnscheck.sh > /dev/null

A major issue with DNSBL on opnsense is the lack of memory usage optimization when the blocklists get updated.
First issue is the blocklist update process loads all the blocklists in RAM then format them for Unbound, instead of streaming them.
Second issue is at DNSBL swap time, Unbound effectively has 2x all the blocklists loaded for a brief moment before releasing the old blocklist.
Both situations can lead to the highest memory consumer being killed by FreeBSD (expected behavior).

What I did is include the netflow storage path in the var/log ram disk by modifying the end of /usr/local/etc/rc.subr.d/var :

Code Select Expand

        echo -n "Setting up /var/log memory disk..."
        mount -t tmpfs -o size=$((MAX_MEM_SYS / 100 * MAX_MFS_VAR)) tmpfs /var/log
        echo "done."

ln -s /var/log/netflow /var/netflow
mkdir -p /var/log/netflow
chown root:wheel /var/log/netflow
chmod 750 /var/log/netflow

fi

# prep boog log
: > /var/log/boot.log

I also did something similar for the unbound.duckdb.

You'll need to re-apply these changes after each opnsense update as they'll be overwritten.

The problem is most likely with emergingthreats. I reported it to their forum : https://community.emergingthreats.net/t/opnsense-suricata-rule-update-for-et-telemetry/1952/22

As pointed by gpb, the incorrect logging is not limited to IPv6. Since 25.1.1, having IPv4 only and NAT redirection for ntp and dns, my 2 associated 'quick pass no log' firewall rules for ntp and dns generate wrong cosmetic block logs. This misbehavior was not present in 25.1.
My other pass rules don't generate any block logs

That's expected behavior from the firewall component. It cannot filter based on hostnames but only on IPs and ports.
You should use a DNS blocklist with unbound for your purpose. That way you won't get these expected name resolutions.

Faced wireguard errors and not connecting.
Looks like the new code cannot handle dns resolutions and requires ip address for Endpoint address.

Your setup should work with siteB having a /16 or /24 (NAT has nothing to do here and there is no madness) if you have the redundant static routes set for each tunnel at both sites. At least on cisco and juniper, it would work.
Don't know if there is something fishy with bsd handling for 2 static routes with the same destination prefix.
If the static routes don't work, you might try the frr plugin and setting a routing protocol like ospf with redistribute connected. Ospf would only need to be enabled on the 2 tunnels.

Suggest you read the pfsense page about arc tuning so you can limit its usage https://docs.netgate.com/pfsense/en/latest/hardware/tune-zfs.html

Still having weird thing maybe related. The tab "ui/diagnostics/firewall/pf_top" shows Rule = null for all entries.
"ui/diagnostics/firewall/states" shows the rules properly.
Just did a reinstall of base to be sure and still the same. Is that expected or not ?

Had the same problem with empty widget after base reinstall. It started to populate entries in the widget the next day. Don't know if there is any log rotation involved but maybe leave it alone for now and check back tomorrow if it finally works.

6.5 seems fine. No crash so far.
Please improve the QA. Are updates not pushed first to development branch and test gear before deployment to production branch ? This issue and the others would have been quickly spotted. Guess it's better to wait a week before deploying updates

I guess almost constant crashing is a good way to prevent security risks.
More seriously, I think it would have been better to keep the previous version or go for 6.3 and highlight the risks rather than providing an updated version that doesn't work and will trigger people to ask for help.

Squid6.4 keeps crashing and dumping core. This wasn't happening with the previous version.
Always the same fatal error in cache log :
kid1| FATAL: assertion failed: stmem.cc:98: "lowestOffset () <= target_offset"   

This isn't an isolated occurrence - see https://www.mail-archive.com/squid-users@lists.squid-cache.org/msg25028.html. Crashes were apparently not happening in 6.3

Widget still remains empty for me after reinstalling base and having Live view showing labels again