Messages

don't know about the repository, but ET Open is available as a plugin

- Then upgrade to OPNsense 26.7.x
- Then upgrade your FreeBSD Bootloader.

This did not work for me (bootloop) -- I had to upgrade the Bootloader BEFORE upgrading to 26.7.x.

Just for reference (in case someone else stumbles over this thread):

I had boot loops on update to 26.7 too, but for a different reason: I was still using an ooold EFI boot loader (from 2022?).

Updating the boot loader per FreeBSD 15.1 instructions helped in my case. See https://forum.opnsense.org/index.php?topic=52508.0.

My initial attempt to upgrade from 26.1.11_10 to 26.7 failed with a boot loop: the update process could not go through as it requires several automatic reboots.

1. Removing the Intel microcode plugin as well as AdGuardHome and the community repo did not fix the boot loop.
2. Updating the EFI boot loader as per https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-loader-uefi helped.
3. Now the update went through. Re-installed community repo and AdGuardHome.
4. Yay!

I would love to know how to incorporate the IPfire Suricata IDS/IPS rules (for malware TLS/HTTPS SNI inspection)

Accessible here: https://www.ipfire.org/dbl/how-to-use with a link to https://dbl.ipfire.org/lists/suricata.tar.gz

Does anyone know how to include them as (custom) rulesets in opnsense?

The DNSBL as such are ... meh.

same config (dual stack, IPv6 via PPPoE) gives me lower MTUs:

Code Select Expand

Direction Tested Maximum Size Segment Client Sent MSS Notes
Server to Client IPv4 1452 1452 OK
Client to Server IPv4 unlimited (n/a) OK
Server to Client IPv6 1432 1432 OK
Client to Server IPv6 unlimited (n/a) OK


Code Select Expand

got in probe for mss 536 (max seg 1452)
got in probe for mss 1452 (max seg 1452)
got in probe for mss 1452 (max seg 1452)
finished in probing, maximum mss 1452 peer mss 1452 initial peer mss 1452
got out probe for mss 343
got out probe for mss 1453
got out probe for mss 9000
finished out probing, maximum mss 9000
got in probe for mss 536 (max seg 1432)
got in probe for mss 1432 (max seg 1432)
got in probe for mss 1432 (max seg 1432)
finished in probing, maximum mss 1432 peer mss 1432 initial peer mss 1432
got out probe for mss 343
got out probe for mss 1433
got out probe for mss 9000
finished out probing, maximum mss 9000
PINGs seem to transmit the "full" MTU 1500, though (both from a client and from OPNsense):

Code Select Expand

ping -4 -c4 -D -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
[1770722028.061190] 1480 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=5.63 ms
[1770722029.062243] 1480 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=4.75 ms
^C

I'd really like to get it working again. Any suggestions where I should look?

My AGH -> Unbound setup runs fine (and has run fine) for several years, so it is something in your setup.

As one data point: Do not use port 5353.  That port is used for mDNS.  Most of the guides get this wrong because 5353 is just so convenient and easy to remember ...

That probably does not explain your issues, though.

Thank you all for the feedback!  Does the 3rd party plugin automatically update itself?  I would like to try to stay as hands-off as possible.

Not really. The mimugmail repo is not updated often.
You can easily update Adguard Home from the "update" button of Adguard Home's web GUI.

Same here.

There is also a 3rd party plugin for Blocky - another DNS sinkhole like AGH or pihole:

https://forum.opnsense.org/index.php?topic=42631.0

Does anyone have insights into whether this new (beta) feature is working?

I am looking to use firewall rules to move my DHCPv6 traffic to a WFQ pipe and all my other IPv6 UDP traffic to a FQ_Codel pipe (which would otherwise eat the DHCPv6 traffic for some unknown reason).

I know of LibeQoS (Dave Täht's last project), but not much about how to employ it on a small non-ISP scale. Especially not in conjunction with OPNsense.

Care to elaborate?

Ergänzung / Präzisierung:

DHCPv6 darf nicht durch FQ-Codel o.ä. geshaped werden (sonst kommt es zum o.g. Problem, daher die "renew"s werden nicht versandt).

Bei mir funktioniert DHCPv6 nur, wenn folgendes _nicht_ durch FQ-Codel geshaped wird:
- ICMPv6
- UDP über IPv6 (!)

ICMPv6 habe ich auf eine separate "control plane" pipe gelegt (zusammen mit ICMPv4), entsprechend https://forum.opnsense.org/index.php?topic=46990.30.

Aber UDP über IPv6 macht weiterhin Probleme.

UDP über IPv6 muss ich gänzlich vom shaping ausnehmen, da (1) die "traffic shaping" rules keine Filterung nach DHCPv6 ermöglichen und (2) ich die pipe auch nicht mittels individueller firewall-rules zuweisen kann, da die automatischen Regeln für "allow IPv6" als "quick" ausgestaltet sind und daher von späteren, individuellen firewall-rules nicht mehr erfasst werden können.

Das ist unschön.

Hat jemand eine Idee? 
- Kann DHCPv6 als "Protokoll" zu den traffic shaping rules hinzugefügt werden, so dass ich das in die control plane schieben könnte?
- Kann ich die "allow IPv6" option von opnsense ausschalten und manuelle DHCPv6-Regeln verwenden, oder macht die Option noch mehr als die beiden "DHCPv6 automatic rules" zu setzen?
- ... ?

Unfortunately, the fix in acme.sh v3.1.1 does not fix this issue for me:

after ACME has updated the certificate, the user is again root:wheel:

Code Select Expand

% ls -la /usr/local/share/java/unifi/data/keystore
-rw-r-----  1 root wheel 5974 May 25 21:33 /usr/local/share/java/unifi/data/keystore

I understand the new "experimental" section in the firewall rules can replace the "rules" in the shaper setting, nothing more.

I'd LOVE that, too :-)