Messages

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 :-)

But I wanna use Bandwith priorisation based on source / target / protocol (whatever) in place, too. So my IPTV is working WHILE steam is downloading big blobs.

You should not need this -- FQ_codel should automatically handle this (i.e., prioritising bursty IPTV and putting steam in the background).

I see this as well but it happened when upgrading from r_6 to r1 and r2 did not make it go away.

Same here.

For the default zroot pool, autotrim is on. While you could scrub, it would only be useful if you had multiple disks.

I tend to disagree: a scrub will check the checksums and therefore
show if the file system is corrupted.

It won't be able to self-heal with just one disk, but it will be able to tell you that you need to pay attention to that pool (e.g. replace the disk and restore from backup).

Traffic shaping breaks some IPv6 functionality (esp. DHCPv6 / ICMPv6).

"Real" traffic, though, is not affected I think.

See https://github.com/opnsense/core/issues/7342

So it _might_ be that the packet loss shown is real, as it is packet loss of ICMPv6 only, but your speeds are fine, as those are unaffected TCP/IP(v6) traffic.

Been running 25.1 since December. No issues encountered. Thanks for all the work on OPNsense!

[Ursache]

Habe gerade etwas Zeit zum testen gehabt.  Derzeit unter 25.1-beta (das Verhalten unterscheidet sich aber nicht von 24.7.x).

Vermutlich habe ich die Ursache gefunden: Shaping.

Sobald ich traffic shaping (FQ-Codel) für "ip" verwende, tritt o.g. Fehler auf (der DHCPv6 renew request geht nicht über das WAN-Interface raus). 

Schalte ich upstream shaping aus oder beschränke es auf "ipv4", funktioniert es problemlos:

Code Select Expand

2025-01-03T14:11:37    Notice    dhcp6c    receive reply from fe80::46ec:ceff:xxxx:xxx%pppoe0 on pppoe0   
2025-01-03T14:11:37    Notice    dhcp6c    send renew to ff02::1:2%pppoe0
Shaping von "ip" oder "ipv6" im upload führt zum o.g. Fehler. Download-shaping macht keinen Unterschied.

Es handelt sich also möglicherweise um das gleiche Fehlerbild wie https://forum.opnsense.org/index.php?topic=39624.0 / https://github.com/opnsense/core/issues/7342

Edit: Ja, gleicher Fehler -- sobald ICMPv6 vom shaping erfasst wird, geht es schief. Alles andere (TCP, UDP, ...) über IPv6 kann geshaped werden.

FYI @franco / @meyerguru

What to set for a 2 core system?

1, obviously :-) (2^1=2)

Use 2. Four cores is plenty enough.

Opnsense 23.1 bare Metal: PPPoE und IPv6 funktionieren problemlos:

Code Select Expand

2024-10-21T08:11:23 Notice dhcp6c got an expected reply, sleeping.
2024-10-21T08:11:23 Notice dhcp6c removing an event on pppoe0, state=RENEW
2024-10-21T08:11:23 Notice dhcp6c script "/var/etc/dhcp6c_wan_script.sh" terminated
2024-10-21T08:11:23 Notice dhcp6c dhcp6c RENEW on pppoe0
2024-10-21T08:11:23 Notice dhcp6c executes /var/etc/dhcp6c_wan_script.sh
2024-10-21T08:11:23 Notice dhcp6c update a prefix 2001:a61:XXXx:8000::/56 pltime=3600, vltime=7200
2024-10-21T08:11:23 Notice dhcp6c update an IA: PD-0
2024-10-21T08:11:23 Notice dhcp6c nameserver[1] 2001:a60::53:2
2024-10-21T08:11:23 Notice dhcp6c nameserver[0] 2001:a60::53:1
2024-10-21T08:11:23 Notice dhcp6c get DHCP option DNS, len 32
2024-10-21T08:11:23 Notice dhcp6c IA_PD prefix: 2001:a61:XXXX:8000::/56 pltime=3600 vltime=7200
2024-10-21T08:11:23 Notice dhcp6c get DHCP option IA_PD prefix, len 25
2024-10-21T08:11:23 Notice dhcp6c IA_PD: ID=0, T1=1800, T2=2880
2024-10-21T08:11:23 Notice dhcp6c get DHCP option IA_PD, len 41
2024-10-21T08:11:23 Notice dhcp6c DUID: XXXX
2024-10-21T08:11:23 Notice dhcp6c get DHCP option server ID, len 26
2024-10-21T08:11:23 Notice dhcp6c DUID: XXXX
2024-10-21T08:11:23 Notice dhcp6c get DHCP option client ID, len 14
2024-10-21T08:11:23 Notice dhcp6c receive reply from fe80::ee7c:5cff:fe0c:8625%pppoe0 on pppoe0
2024-10-21T08:11:23 Notice dhcp6c send renew to ff02::1:2%pppoe0

Ich teste mich die nächsten Nächte grob durch 23.7, 24.1 und 24.7 durch ...