Messages

[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 ...

Da ich die NICs per PCI passthrough verwende, nahm ich an, dass die Virtualisierung keine Rolle spielt.

Ich setze am WE mal eine ""bare Metal" Box auf und teste es da, inkl. der tweams aus dem englischen thread.

Not enough information.

Cross-referencing the English thread (not mine!): https://forum.opnsense.org/index.php?topic=41743.msg205110#msg205110

Es liegt ziemlich sicher an OPNsense; sowohl die FritzBox als auch eine testweise aufgesetzte Openwrt-Installation hatten dauerhaft stabiles IPv6.

This starts to sound like my problem: https://forum.opnsense.org/index.php?topic=43322.0

To summarise the German discussion:

0. Dual stack FTTH with M-Net as ISP. Connection is established via IPv4 PPPoE, IPv6 via DHCPv6 using the IPv4 link.
1. Initially, an IPv6 prefix delegation is received (over PPPoE). Everything is nice.
2. After the initial timeout, DHCPv6 tries to renew/rebind but fails.
3. IPv6 connection is lost. Only a reboot helps.

It seems from my limited investigation that the renew/rebind packets never actually are sent via WAN to my ISP and therefore cannot renew/rebind the IPv6 PD.

Alternative Routers have no issues and keep their IPv6 connection (FritzBox, Openwrt).

EDIT & UPDATE: The issue (or at least one issue) in my case was upstream traffic shaping (FQ-Codel).  Turning that off enables DHCPv6 lease renew.

Für die allgemein verfügbaren Blocklisten braucht man kein ZenArmor oder CrowdSec.

1. DNS-Blocklisten: Adguard Home. Oder einfach einen NextDNS account nutzen.

2. IP-Blocklisten (zB FireHOL): Firewall alias FireHOL erstellen. WAN-Regeln (i) Block traffic from FireHOL und (ii) Block traffic to FireHOL.

3. Fertig.

Leider keine Änderung - nach Ablauf der ursprünglichen lease period ist IPv6 weg.

Erst ein reboot hilft (für eben die 2 Stunden initial lease time).

Auf dem pppoe0 interface ist mit tcpdump kein IPv6 Verkehr zu erkennen, nachdem die lease time ausgelaufen ist. Die renew/rebind Anfragen scheinen also nicht mal zum pppoe0 zu kommen.

Good point - hatte die nicht näher angesehen. Das DHCPv6 war nicht als upstream gateway markiert(!). Habs mal geändert.
PS: Hardware VLAN Filtering habe ich AUS (statt default) - könnte das noch dazwischenfunken?

So far jedenfalls keine Besserung (im laufenden Betrieb) - mal sehen wie es nach einem reboot aussieht (das erst heute Abend).

Könnte man es mit einer statischen Route probieren?

Code Select Expand


2024-10-11T10:26:13 Notice dhcp6c reset a timer on pppoe0, state=SOLICIT, timeo=24, retrans=3571725
2024-10-11T10:26:13 Notice dhcp6c send solicit to ff02::1:2%pppoe0
2024-10-11T10:26:13 Notice dhcp6c set IA_PD
2024-10-11T10:26:13 Notice dhcp6c set IA_PD prefix
2024-10-11T10:26:13 Notice dhcp6c set option request (len 4)
2024-10-11T10:26:13 Notice dhcp6c set elapsed time (len 2)
2024-10-11T10:26:13 Notice dhcp6c set client ID (len 14)
2024-10-11T10:26:13 Notice dhcp6c Sending Solicit


Das pppoe0 Device halte ich für sinnvoller im Capture, da dort erstmal die Pakete sichtbar werden wie sie dhcp6c verschickt (und ggf. die Serverantworten).

Getestet mit tcpdump -vvv -i pppoe0 | grep IP6:

- solange ich ein gültiges IPv6 prefix habe: tcpdump zeigt IP6 traffic
- sobald ich kein gültiges IPv6 prefix habe: tcpdump zeigt keinen IP6 traffic

Siehe anbei ... (Befehl + console Ausgabe jeweils manuell am Anfang eingefügt in den beiden Dateien)

[TINY]

Ich werfe nochmal "meine" Lösung in den Raum: Lenovo m720q mit PCIe riser und Intel i350-T4 NIC. Ca. 200 EUR, bisher performant genug, regelmäßige BIOS-updates.

danke dafür, aber ich möcht ehrlich gesagt wieder was "kleines"
so kleine Elitedesk HP PCs hätte ich auch, aber die haben alle nur 1x NIC, das reicht ja nicht  ;D

Ich präzisiere: ich meinte einen Lenovo m720q TINY.

Die sind so klein wie ein elitedesk (kleiner als DIN A4) aber haben einen PCIe Slot in den man eine 4fach Netzwerkkarte stecken kann (mit riser).
https://smallformfactor.net/forum/threads/lenovo-m720q-tiny-router-firewall-build-with-aftermarket-4-port-nic.14793/

Geht auch mit 10G: https://blog.muffn.io/posts/m720q-opnsense-firewall/

Ich habe das Problem auch teilweise, das bestimmte domains vom unbound resolver nicht aufgelöst werden: Das waren typischerweisse .COM domains.

Hab aktuell dazu nichts mehr gespeichert/notiert, falls das wieder auftritt, schaue ich hier rein.

Lese ich das Log richtig:

Ich denke ja.

Ob der Versand über WAN überhaupt erfolgt, frage ich mich auch.

Kannst Du mir kurz einen Hinweis an die Hand geben, wie ich das am besten teste/prüfe?

Ich kann zwar zB tcpdump auf der Kommandozeile starten, welches Interface und welche Optionen genau ich nehmen soll weiss ich aber nicht. Ein tcpdump - pppoe0 scheint mir nur IPv4 Pakete zu zeigen. (das Interface ist jetzt pppoe0, das Log zeigt ein voriges Setup)

Oder das ganze über einen Switch (mit vlan40) ziehen und dort mirroring machen, um mit einem Laptop zu lauschen?

Wenn ich etwas Zeit habe würde ich das System zu Testzwecken auf bare Metal umziehen, sollte aber _eigentlich_ keinen Unterschied machen.