Messages

The IPv6 MTU should be much loser, often 1280.

I would try some Public IPv6 test Sites for diagnosis.

Na dann. Denk mal darüber nach, warum das nicht klappt. Tipp: RFC1918-IPs werden von den wenigsten ISPs geroutet...

Lesestoff:

https://forum.opnsense.org/index.php?topic=42985.0, speziell Punkt 4.

Ich habe das nie so gemacht (aus Gründen), deswegen kann ich auch keine Schritt-für-Schritt-Anleitung geben, wie das mit geeigneten Firewall- und NAT-Regeln rein und raus sowie erlaubten IP-Ranges im Wireguard-Profil geht. Irgendwie bekommt man das sicher hin, ist aber wahrscheinlich komplex.

Zugegebenermaßen wüsste ich aber auch nicht, ob es reine Kabelmodems gibt...

Ist das ein Router-Behind-Router Szenario, z.B. Fritzbox vor der OpnSense? Sonst wäre ja wohl keine RFC1918 auf dem WAN-Device...

Du müsstest einen Unterschied der jeweiligen Ausgaben der Tools zwischen "funktionierend" und "nicht funktionierend" sehen. Wenn einer da ist, wäre die Frage, was die entsprechende Änderung bewirkt. Bei Routen könnte es ein RA sein, der nicht da sein dürfte, bei NDs entsprechend ND-Pakete, die nicht (mehr) durchkommen oder den Cache löschen. Theoretisch kann ein Client ja seine IPv6 wechseln, beispielsweise bei Nutzung der Privacy Extensions.

Unter Linux gibt es z.B. noch das ndptool, mit dem man entsprechende NDP-Frames sehen kann. Für RAs gibt es radvdump.

@JamesFrisch: Interessanter Gedanke. Ich hatte angenommen, das ZyXEL sei als reines VDSL-Modem in Betrieb, nicht, dass es als vorgeschalteter Router genutzt wird. Das kann natürlich alle möglichen dummen Effekte haben.

@bamf: Also, wer macht die Einwahl? OpnSense oder das ZyXEL?

[wenn]

Das ist so lange keine Erkenntnis, wie Du nicht testest, ob die Route und der Neighbor Cache noch intakt sind. Beheben kannst Du es frühestens, wenn Du erstens sicher weißt, dass das die Ausprägung ist, die das beobachtete Verhalten verursacht und dann zweitens überlegst, wieso das passiert (wenn es denn so ist).

Wir hatten ja z.B. anfangs mal über Proxmox diskutiert. Da ist es so, dass ein fehlendes bridge-mcsnoop 0 den Neighbor Cache kaputt macht, weil bestimmte Pakete nicht durchgelassen werden. Ist bei Dir nicht der Fall, weil Deine OpnSense nicht unter Proxmox läuft.

So etwas kann aber die seltsamsten Ursachen haben, beispielsweise fehlerhafte Switches, wie ich vor kurzem bei Ubiquiti erleben durfte, oder, oder oder.

Oder anders: Meine Glaskugel ist kaputt. Dein Problem ist offenbar sehr speziell, da kann man (mindestens: ich) leider nur Denkanstöße geben, sorry. So funktioniert Debugging nach meiner Erfahrung nun mal.

Does the problem go away when you disable IPv6?

Also, HTTP/3 uses a mix of TCP and UDP traffic. Depending on your firewall settings, you may experience problems when UDP is blocked or impaired.
Mind your, TCP will usually find out when the MTU is incorrect. UDP does not. So it might well be MTU problems.

Theorectically, the difference could be that your browser runs on a client, but I gues you are using the CLI version on OpnSense itself? You can well have problems that allow your clients to have different routes or settings than OpnSense.

For example, when you only use IPv6 prefixes (IA_PD), but no IA_NA and your OpnSense has no IPv6 of its own, it could happen that it can only use IPv4, but no IPv6. Depending on the speed of IPv4 vs. IPv6 on the way to the test server, the results can differ. Same goes for policy-based routes.

IDK what type of traffic Speedtest uses, though. A packet trace would show any differences. Speedtest is not exactly transparent about what IP the server is.

Das sieht so aus, als ob Deine Clients die OpnSense nicht mehr finden, weil die neighbor discovery oder die Route nicht mehr funktioniert. Solange der Ping läuft, bleibt die MAC gecached, startest Du nach einer Pause neu, ist sie weg.

Ja, passt doch. Zwei mit + und einer mit *, reicht.

Das Problem bei Gigabit ist, dass davon bei 1 GBit Engpass dahinter aufgrund von Protokolloverhead nur ca. 940 MBit/s ankommen. Nur, wenn man einen ONT hat, der mehr (sprich 2.5 Gbps) kann, kommt die volle Bandbreite. Teilweise dann mehr, wie bei mir, weil die ISPs überprovisionieren.

SFP+ kann per se nur 1 und 10 Gbps, man kann aber manche GPONs in den SGMII-Modus schalten, das unterstützen aber wie gesagt die SFP+-Slots zu 95% nicht. Mit Ethernet ist das alles viel einfacher, solange die OpnSense und der ONT beide 2.5 GBit/s können, weil das bei Ethernet genormt ist.

Und ja, Daniele oder Giammarco schicken Dir ggf. ein fertig geflashtes ONT zu.

SGMII ist nicht reines 2.5 Gbps, ich wäre da nicht zu optimistisch. Tatsächlich nutze ich lieber externe ONTs, z.B. das ZTE F6005 (speziell geflasht, u.a. zum Klonen der S/N), das per Ethernet 2.5 Gbps kann. Das funktioniert allemal zuverlässiger als ein GPON in einem windigen SFP+-Slot, von denen die wenigsten SGMII unterstützen.

Meistens liefern die ISPs ja ein externes ONT (oft 1 Gbps), das klone ich dann und habe im Normalfall dann volles Gigabit (oder mehr, siehe Signatur) und immer noch ein Fallback-ONT in der Hinterhand.

Es gibt übrigens eine Liste von allen möglichen GPONs hier: https://hack-gpon.org, es gibt da auch ein ONT von LEOX, das hatte anfangs aber Firmware-Probleme.

Die Website wird von ein paar Italienern betrieben, die echt Ahnung haben, weil GPON in Italien schon viel länger als in D gängig ist. Die haben auf Telegram auch einen Kanal "Hack GPON". Zwei von denen besitzen einen OLT und können damit GPONs umflashen, so dass sie komplett offen sind. Die verschicken die auch. Wende Dich einfach auf englisch an Daniele (@Dankeros oder daniel_e88@hack-gpon.org), der kann die besorgen. Sag ihm einen schönen Gruß von mir.

Set the checkbox at "Services: Unbound DNS: General" -> "Do not register system A/AAAA records"
Instead, create a manual DNS entry as you like.

An sich sollte jedes GPON-Model funktionieren, u.a. die Digitalisierungsbox Glasfasermodem. Der Cisco kann nur 1 oder 10 Gbps, also geht SMGII mit 2.5 GBps nicht - das bedeutet, Du kannst nicht ganz das volle Gigabit erreichen.

Die neueren Versionen der Digitalisierungsbox sind nicht mehr "offen", d.h. man kann die Seriennummer nicht mehr ändern (z.B. um ein ONT zu klonen), bei der Telekom kann man aber m.W. ohne Probleme einen neuen ONT registrieren lassen.

Nochmal: Das sind Pools mit vielen Adressen, nicht zwei verschiedene Server. Wie viele Kandidaten aus dem Pool oder der Liste von Servern genutzt werden, wird durch die anderen Konfigurationsparameter bestimmt, wie in den Hilfetexten dazu erläutert wird (u.a. Maxclock).

Ansonsten ist das ein hochkomplexer Auswahlprozess, der zu N Kandidaten und einem "System Peer" (Activer Peer) führt, siehe:

https://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_basics
https://docs.ntpsec.org/latest/ntp_conf.html

Die Synchronisation wird nach erfolgter Auswahl auch mit den Kandidaten durchgeführt. Der "System Peer" ist eigentlich als der Haupt-Kandidat gemeint, das kann z.B. auch eine lokale GPS-Quelle sein.

Natürlich müssen die Peers alle erreichbar sein und das WAN-Interface sollte aktiviert werden. Was nämlich bei Dir komisch ist, ist, dass Du gar keine Kandidaten hast. Bei mir sieht das so aus (+ ist Kandidat, * ist System Peer):

Code Select Expand

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 1.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
-167.235.70.245  195.176.26.204   2 u   50   64  377    8.227   +1.809   0.717
-94.130.23.46    192.53.103.104   2 u   55   64  377   10.171   +1.528   1.480
+129.70.132.35   129.70.137.82    2 u   45   64  377   14.946   +0.132   1.790
#195.201.19.162  118.163.81.62    2 u   49   64  377    7.501   +3.352   0.813
#217.160.19.219  10.50.0.2        2 u   50   64  377   17.507   +0.239   1.564
+130.162.220.39  169.254.169.254  3 u   46   64  377    8.524   +0.076   2.188
-109.230.228.196 131.188.3.220    2 u   42   64  377    9.220   +0.843   1.463
+185.194.239.35  192.53.103.108   2 u   41   64  377    8.808   +0.315   1.492
*178.215.228.24  189.97.54.122    2 u   43   64  377    6.900   -0.361   0.951
+217.144.138.234 192.53.103.108   2 u   41   64  377   12.266   +0.149   1.294
-167.235.139.237 237.17.204.95    2 u  103  128  377    8.148   +1.826   4.177
+192.248.187.154 91.135.4.191     2 u   30   64  377    6.800   +0.014   1.238
+109.123.244.54  79.143.250.33    2 u   37   64  377    9.491   -0.388   1.525
-157.90.24.29    193.79.237.14    2 u   99  128  377    8.435   +1.922   1.585
-217.91.44.17    237.17.204.95    2 u   95  128  377   22.769   +2.087   0.746

Zeig mal die komplette NTPD-Konfiguration.

Wenn Dir das zu kompliziert ist, nimm Chrony, dort kannst Du eine konkrete Liste von Peers angeben. Der kann auch NTS. NTPD ist halt einfach uraltes, gewachsenes Zeug: https://chrony-project.org/comparison.html

Das sind keine Rechner, sondern Pools, d.h. Listen von Rechnern, die dynamisch zusammengestellt werden. Die Synchronisation dauert mitunter sehr lange, ehe NTPD sich auf bestimmte Server einschießt.

Ich nutze inzwischen lieber os-chrony.