Beiträge von lp24db

Gerne auch mit Iperf3 und Wireshark. So wirklich unterscheidet sich das aber nicht. Da die Smokeping Proben nur alle 30s laufen, zeigen die natürlich seltener irgendetwas an aber Gefühlt ist das alles das gleiche Verhalten. Ergebnisse:

Von allen Clients zur OPNsense - nichts. Von meinem Homeserver (oder auch von der OPNSense direkt) zu einem IONOS VPS Server UDP Losses und TCP Retransmits. Interessanterweise scheint im Reverse Mode vom IONOS VPS Server kein UDP Paket verloren zu gehen. Aber was sagt mir das? Zum Zeitpunkt der TCP Retransmits sieht man im Wireshark DupACKs und Fast sowie normale Retransmits. Bei UDP sieht man hier (logischerweise) nur die ausgehenden Pakete.

Hilft das jetzt irgendwie? Warum wird im Reverse mode kein UDP loss generiert? (ich habe es dreimal laufen lassen, weil ich es nicht geglaubt habe)

Homeserver > OPNSense FW
- UDP
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0.000 ms 0/15539 (0%) sender
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0.048 ms 0/15539 (0%) receiver

- TCP
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0  sender
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec receiver

Homeserver > OPNSense FW Reverse (-R)
- UDP
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0.000 ms 0/15539 (0%) sender
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0.023 ms 0/15539 (0%) receiver

- TCP
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0 sender
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec receiver

Homeserver (oder auch von der OPNsense - vergleichbare Werte) > IONOS VPS Server
- UDP
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0.000 ms 0/15539 (0%) sender
[ 5] 0.00-180.01 sec 21.3 MBytes 993 Kbits/sec 0.682 ms 114/15539 (0.73%) receiver

- TCP
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 32 sender
[ 5] 0.00-180.02 sec 21.5 MBytes 1.00 Mbits/sec receiver

Homeserver (oder auch von der OPNsense - vergleichbare Werte) > IONOS VPS Server Reverse (-R)
- UDP
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-180.02 sec 21.5 MBytes 1.00 Mbits/sec 0.000 ms 0/15541 (0%) sender
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec 0.052 ms 0/15539 (0%) receiver

- TCP
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-180.01 sec 21.5 MBytes 1.00 Mbits/sec 13 sender
[ 5] 0.00-180.00 sec 21.5 MBytes 1.00 Mbits/sec receiver

Tja, also alles wieder auf Anfang.

Zitat

(von ::1 aus einem anderen Thread)

Ok, dann befindest du dich am "Frankfurt-BNG-Cluster1" der DG. Der deckt die beiden folgenden /41-Blöcke ab:

1. 2a00:6020:5000::/41 mit WAN-Port-Adressen aus 2a00:6020:1000:40::/112 (BNG=2a00:6020:ffff:ffff::d)
2. 2a00:6020:5080::/41 mit WAN-Port-Adressen aus 2a00:6020:1000:41::/112 (BNG=2a00:6020:ffff:ffff::e)

Aktuell gehen meine Verbindungen über den ffff::e, das konnte ich jetzt herausfinden.

Zahni ich will ja mein Netzwerk ausschließen. Oder als Schuldigen finden. Da aber interne alle Pings (icmp und tcp) 100% ohne Loss sind, und auch die Interfacestatistikten meines Homeservers sowie der OPNSense keinerlei Loss / error / transmit /crc oder sonstige Probleme anzeigen, kann ich das lokale Netzwerk eigentlich schon ausschließen. Hardware der OPNSense habe ich schon drei verschiedene getestet - mit immer dem gleichen Fehlerbild.
Ab dem ONT ist es Blackbox und genau da versuche ich Licht reinzubringen.

Ich kenne mich mit Hardware und Netzwerken schon ein wenig aus, natürlich keine ISP Konstruktionen. Deswegen Danke an ::1 für die Insights.

Ich habe mir aber nochmal die Ripe Rrobes von ::1 angesehen., Wenn man bei den Probes die am Franfurter Knoten hängen, auf einen Monat geht, sieht man auch den Packetloss beim Hovern über die Messpunkte. ICMP hin oder her.

RIPE Atlas - RIPE Network Coordination Centre

RIPE Atlas is the RIPE NCC's main Internet data measurement system.

atlas.ripe.net

Wenn man das jetzt auf ein Jahr zieht, sieht man optisch (jeder schwarze Kringel ist ein Loss) alleine schon Optisch bereits, das sich da im September (zumindest bei dieser Probe) deutlich was geändert hat. Bei mir ist das Problem Anfang / Mitte November das erste mal aufgetreten.
Und ich spiele seit über 5 Jahren online ein (altes) Multiplayer Online Game, was konstant per TCP arbeitet und man jeden Loss sofort bemerkt. Und vor November 2025 ist mir da nie etwas aufgefallen - das muss man mir halt auch ohne Graphen glauben

Bedeutet wohl für mich, dass ich hier meine Hoffnungen auf saubere Verbindungen erstmal begraben kann. Traurig.

Ich bin immer noch am Rätseln ob backbone oder "letze Meile". Ich weiß nur, dass ich vier Jahre lange keine Probleme hatte, da ich regelmässig in der Woche abens mal was spiele. Ich schau mal und berichte weiter.

Zitat von pufferueberlauf

Nun ja, ich wuerde da vermutlich einfach mal versuchen die MAC zu clonen bevor ich den Router austausche... das sollte kein Hexenwerk sein und hat gute Aussichten zu funktionieren...

Mache ich ja Aber warum macht man sowas überhaupt?

Langzeitmessungen werden auch nichts anderes zeigen. Ob icmp oder tcp es ist alles betroffen. Hab mal die trip Screenshots angehängt, die aber auch keine neue oder andere Erkenntnis bringen. Loss, immer mal wieder sporadisch und grundsätzlich nach dem Gateway der DG.

Ich werde mal meine IPv6 von meinem Webserver mit trip beboachten, danke für den Tip. Aber würde das wirklich Erkenntnisse bringen?

Mal zusammengefasst:

- Das mit dem Portlimit habe ich bereits gelesen. Halte ich aber für unwahrscheinlich, da das Fehlerbild anders ist.
- CGNat kann man eigentlich auch schon ausschließen, da auch IPv6 Adressen betroffen sind.
- Ich habe schon vier unterschiedliche Router / Hardware verwendet, auch mit älteren Softwareständen, das Fehlerbild ist immer gleich.
- ONT Neugestartet usw. kein Unterschied
- Dämpfung scheint ok zu sein, falls das nicht so wäre würde ich auch mit einer höheren Fehlerquote rechnen (kenne ich von Servern im Fibrechannel oder bei Ethernet >=10Gbit zumindest so)
- vor Mitte November war alles 100%ig ok.

Am Wahrscheinlichsten:
- ONT ne Macke?
- SFP auf deren Seite?
- Leitung überbucht?

Spekulation:
- Kann es die Faser selbst sein? Es gab im September 2025 einen Schaden wegen eines Wasserrohrbruchs, das wurde aber repariert und lief 2 Montate ohne Probleme (hab ich schon wieder verdrängt) Wenn aber die Dämpfung ok ist?
- ich habe noch den alten 400/200 für 49€ Vertrag. Heute bekommt man hier für 49€ nur noch 300/150 Wollen die mich da runtermobben ?

Es wäre halt so einfach, wenn die DG einfach beliebige Endgeräte wie bei einem DSL Anschluss z.B. erlauben würden. Aber nein. 1h Mac Sperre, keine "Zugangsdaten" also PLOAM oder sonstige Infos im Kundeportal, NULL Response bei Fehlertickets, Informationhiding an allen Ecken. Ich frag mich manchmal, warum sowas überhaupt sein darf. Ok die Fritzbox mit GPON kann man jetzt automatisch provisionieren lassen aber auch das hat vier Jahre gedauert.
Von einem Kollegen aus der Nähe von Mainz habe ich gehört, dass das auch ganz anders gehen kann.

Am liebsten würde ich ja auf den Gigabit wechseln, dann könnte ich zumindest das GPON Thmea sparen. Aber ich befürchte das könnte genauso in die Hose gehen. Vier Jahre bestes Internet und jetzt nervt es nur noch.

Zitat von frank_m

Das ist aber ein Zeichen dafür, dass es auf TCP Ebene keine Paketverluste gibt. Auf sowas reagieren Speedtests recht empfindlich.

Die Losses sind ja nicht ständig. Könnte auch gut sein, dass ich beim Speedtest keine erwischt habe. Machnmal passiert ja auch eine Stunde lang gar nichts. Ich denke auch nicht, dass das "Backbone" hier ein Problem ist, sonst wäre der Aufschrei ja wesentlich größer. Ich kann ja nochmal ein Speedtests anfertigen. Das geht leider nur nachts, weil gerade jetzt am Wochenende hier Hochbetrieb ist.

Wir haben in der Schule unseres Sohnes einen DG-Business Anschluss (bin dort Ehrenamtlich tätig). Da ist überhaupt kein Loss - ist aber auch kein GPON also nicht direkt vergleichbar. (und man bekommt sogar echten Support, wenn man dort anruft)

Dann versuche ich mal mein "Glück" nächste Woche mal telefonisch. - Parallel schaue ich mal, ob ich so mein ONT geclont bekomme.

Hier mal der Stand der letzten ca. 20 Stunden. Auch bei TCP Verbindungen (hier 443 und teilweise 80/ bzw. 8080 getestet. IPv6 (facebook, google) und IPv4 ( der maskierte Graph - ist ein Citrix Netscaler und der "FA Silent" ) zeigen Gleiches.
Immer wieder sproadische losses. Das fängt alles schon beim v4 Gateway 100.84.0.1 an - wenn man ICMP als Referenz nimmt. (ich traue mich kein nmap auf die 100.84.0.1 zu machen, nicht dass die mich noch vom Anschluss werfen )

Das ONT zeigt mir "Optical power (dBm)" mit dem Wert -19,4 an. Ist das gut / schlecht? Ich meine gut. Mehr bekommst du aus dem Nokia Ding nicht raus.

::1 hast du eine Idee, was das sein könnte? Oder wo man ansetzen könnte? Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.

Die TCPPing auf 443 Ports der möglichen Server läuft noch. Ich poste morgen. Spoiler: klar ist jetzt schon, auch hier sporadischer Loss.
Korrekt, IPv6 Range ist 2a00:6020:usw.... mit /56, also genau in deiner beschrieben Range

Ich hab nochmal geschaut, ich pinge das Gateway, was ich vom DHCP der DG bekomme - 100.84.0.1 (was bei OPNsense als Gateway angezeigt wird) Dachte, das wäre der CG-NAT auf der mir zugewandten Seite.

Danke für die Ripe Links. Wusste gar nicht, dass es so etwas gibt. BNG-Cluster... never heard of before. Gibt auch ein nettes PDF auf der Seite der Bundesnetzagentur dazu

Übel was gelernt... Und das am Freitag Abend Danke

Ok, es war halt verdächtig, weil es ungefähr das gleiche Verhalten zeigte.

Leider mögen Gameserver kein TCPPing

Ich habe nun für Google und Teams mal nen TCP Ping auf Port 443 konfiguriert. Muss erstmal etwas laufen. Den DG-Router werde ich wohl mit TCPPing nicht bekommen

(UDP Mtr kommt bei mir nirgendwo richtig durch (durch die FW schon) aber sonst nicht wirlich) ICMP Limit gibt es keines, afaik

Danke für den Hinweis.. Wer misst....

Liebe Glasfasermitstreiter/innen,

ich bin nun seit 03/2021 Kunde bei der DG (PLZ Bereich 635xx) und habe von Anfang an eine OPNSense am ONT hängen. ONT typ ist Nokia G-010G-P. Das lief 4 1/2 Jahre lang einwandfrei - bis auf einige DHCPv6 Themen, die aber mittlerweile gelöst sind - aber seit November 2025 (genauer Tag weiß ich nicht) habe ich immer mal wieder Packetloss auf der Leitung. Aufgefallen ist das beim Zocken (ja, ich zocke selbst und habe drei Jungs hier im Haus, die das auch tun) aber auch bei Teams-Meetings bleibt hin und wieder das Bild mal für eine Sekunde stehen.

Ich lasse auf meinem kleinen Heimserver einen SmokePing Container laufen, um Pings zu einigen Endpunkten (IPv4 und IPv6) über den Tag zu beobachten. Was ich sehen kann, ist, dass meine OPNsense nie Verluste zeigt, während der erste Hop dahinter schon diese Losses hat. Alle anderen Webseiten / DNS / Gamingserver zeigen auch dieses Verhalten.

Nun habe ich auch den Artikel Deutsche Glasfaser als erstes Netzwerk mit 800GE Port am DE-CIX gelesen und hab schon die Befürchtung, dass da etwas mit zu tun hat. Bandbreite ist halt nicht Alles, was ein guter Internetanschluss braucht.

DG Support Ticket ist eröffnet, geht bei denen wohl /dev/null. Seit über einem Monat keine Antwort.

Ich habe schon darüber nachgedacht, die OPNsense direkt ans Glas zu hängen, um das ONT als Ursache ausschließen zu können. Ich war schon auf dem Webinterface vom ONT aber außer die Dämpfung bekommt man da keine Infos, die auf Fehler auf der Glasstrecke hindeuten. Ich denke aber aktuell nicht, dass es das ONT ist. (Telnet geht bei meinem nicht)

Die Interfacestatisktik auf dem WAN Port der Opnsense zeigt keinerlei Errors, crcs oder losses.

Ich wollte nur fragen, ob es hier Personen gibt, die Ähnliches beobachtet haben, damit ich den Aufwand hier sparen kann, eine ONT zu klonen oder ein SFP passend zu Programmieren. Fritzbox ist für mich keine Option.

(Ich habe die Forumssuche benutzt, finde aber immer nur Themen, die etwas Abweichendes berichten wie hohe Latenz oder niedrige Downloadbandbreite oder kein IPv6, was bei mir nicht der Fall ist)

MS-Teams und Google.com Graph ist IPv6, alles andere IPv4. DG-CGN ist (denke ich) der NAT Router von der DG, also der erste Hop, den ich im MTR sehen kann

(Spessart ist der Container)

Danke & Viele Grüße

Ursächlich kam ich ja von 6rd, was von einem auf den anderen Tag nicht mehr funktionierte. Nach wie vor kann ich bei 6rd Konfiguration das zugeteilte Gateway nicht erreichen, was mir immer noch ein Rätsel ist. Privat als auch in der Schule.

Aber DHCPv6 funktioniert nun doch. Ich konnte da erst wirklich dahinter steigen, seitdem ich meinen privaten Anschluss habe und ohne Beschränkung alle Option testen konnte. Leider war "die Lösung" nicht so ganz nahe liegend, da ich auch nach der Konfiguration von meinem (v)LAN als "Track Interface" keine Adresse bekam. Da ich an dieser Stelle meist wieder aufgegeben hatte, konnte ich auch nicht weiter kommen

Nach etlichen Suchanfragen konnte ich ein Forenbeitrag bei Netgate (pfSense) finden. Hier wurde aufgrund einer anderen Frage darauf hingewiesen, dass man bei der Aktivierung von "Track Interfaces" immer die Kiste erstmal durchbooten soll. (Wie soll man darauf kommen?) In der normalen Doku findet man da kein Wort drüber. Dazu kommt, dass viele schreiben, man soll die RA intern auf "Managed" stellen. Das traf bei mir auch nicht zu. Erst bei "assisted" fing das Teil an konsequent Adressen zu delegieren.

Letztendlich habe ich es aktuelle nicht mehr mitgeschnitten, aber es deckt sich mit euren, etwas verwunderten, Fragen. Es war nicht nachvollziehbar, warum hier eine "Nicht"-Kommunikation stattfindet. Was der Boot genau ändert, weiß ich bis heute auch noch nicht.

Trotz stundenlangen Probierens und Podcast hören und Doku lesen, komme ich jetzt erst so langsam an den Punkt ansatzweise zu Verstehen, was da im Hintergrund eigentlich passiert. Die Fritzbox ist halt diesbezüglich eine Blackbox - Einschalten und geht halt. Warum interessiert auch 90% der Nutzer nicht.

Insofern lag es nicht an der DG (sorry), sondern an meinem mangelhaften Verständnis von IPv6 und der nicht ganz transparenten pfSense.

Für meinen ursächlichen Usecase, der VPN Verbindung für die Schule, verstehe ich trotzdem nicht, warum ich kein DHCPv6 an der pfSense nutzen kann ohne v6 Adressen ins LAN zu blasen. Ich will ja nur, dass die pfSense eine v6 Adresse erhält, damit der OpenVPN Server erreicht werden kann. Warum ich dafür erst Clients brauche, verstehe ich nicht. Evtl. muss ich doch auch dort nochmal den RA Mode ändern.

Wahrscheinlich liegt es wieder am mangelnden KnowHow bzgl. ipv6, ich geb es ja zu. Ach, v4 war so einfach =)

Ich danke euch für die Unterstützung.

Hab gestern mit der Hotline telefoniert. Zitat: "klar Doku gibts, für die Fritzbox...." Nach meiner Nachfrage zu "technischen Details des Anschlusses", der Hinweis, das könne nur schriftlich angefragt werden. Die Telefonjoker wären hier technisch nicht informiert. Nachdem ich meinen Unmut über die mangelnden Informationen abgeladen hatte, hab ich dann aufgegeben.

Später gegen Abend kam dann tatsächlich eine Mail auf meine Anfrage vom Samstag: "..klar Haben wir" Mit dem Link auf die Anleitung, wie man den Anschluss am Beispiel einer TATAAAA: Fritzbox einrichtet. Das musste ich erstmal verdauen, bevor ich mich darüber aufregen konnte. Ich hab mich in diesem Zustand nicht getraut auf die Mail zu antworten.
Ja Fritzbox, total supi... Will ich aber halt nicht bzw. ist einfach keine Option.
Kaskadieren möchte ich auch nicht, aber ich bin fast soweit das in Betracht zu ziehen. Finde ich technisch ziemlich mau und kann nur die allerletzte Option neben Kündigung sein.

@alfalfa hatte nur am Samstag einmal kurz die Fritzbox dran. Wie schon gesagt, ich muss mal debuggen

Waishon Der Solicit der PFsense ist recht dünn. Hab dann manuell noch einen mit rapid-commit ergänzt. In beiden Fällen keine Antwort.

Frame 1: 86 bytes on wire (688 bits), 86 bytes captured (688 bits)
Ethernet II, Src: HewlettP_75:xx:xx (ac:16:2d:75:xx:xx), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::ae16:2dff:fe75:xxxx, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x950afc
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 00030001ac162d75xxxx
DUID: 00030001ac162d75xxxx
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: ac:16:2d:75:xx:xx
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0000
Elapsed time: 0ms

Frame 1: 90 bytes on wire (720 bits), 90 bytes captured (720 bits)
Ethernet II, Src: HewlettP_75:xx:xx (ac:16:2d:75:xx:xx), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::ae16:2dff:fe75:xxxx, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
Message type: Solicit (1)
Transaction ID: 0xac29c9
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 00030001ac162d75xxxx
DUID: 00030001ac162d75xxxx
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: ac:16:2d:75:xx:xx
Rapid Commit
Option: Rapid Commit (14)
Length: 0
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0000
Elapsed time: 0ms

ich hatte im Wireshark nur auf "dhcpv6" gefiltert. Gibt es noch andere Kommunikation, die interessant wäre? Auf der dhcp(v4) Ebene hatte ich schon mal geschaut, da war im DHCP Handshake nichts ipv6-verdächtig.

RAs kommen ab und zu, aber da scheint die PFsense nicht darauf zu reagieren. Man kann die PFsense ja einstellen, dass sie nicht auf RAs wartet sondern direkt eine Anfrage absetzt. Was ja auffällt, die Fritzbox sendet gleich einen Sack von Request Options. Das scheint der ja irgendwie bekannt zu sein. Der Solicit der PFsense enthält dagegen praktisch keine Request Options.
Wenn ich die nächsten Tage etwas Zeit dafür finde, schicke ich mal ein paar selbst gebaute Solicits ab, um zu schauen ab wann die DG antwortet. Stück für Stück den der Fritzbox nachbauen - aus purer Verzweiflung und Neugier

übrigens: immer noch keine Antwort auf meine Anfrage (Email). Ich lass morgen mal die Hotline glühen.

So sieht das RA der DG aus, ein Hauch von Nichts, wie @alfalfa es bereits beschrieben hat:

00:00:00.000000 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ff:fe00:10 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32
        hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): 02:00:00:00:00:10
            0x0000:  0200 0000 0010
          mtu option (5), length 8 (1):  1500
            0x0000:  0000 0000 05dc

Das mit der DUID habe ich versucht (ist änderbar), hat aber auch kein Erfolg gebracht. Ich warte mal auf die Antwort der DG. Ich hoffe es lässt sich einfach klären. Danke erstmal für die Unterstützung!

Danke schonmal für den Tip. Ich habe vorhin mal die Fritzbox angeschlossen und mit geschnitten. Ja die Vermutung war richtig, seit kurzem macht der Anschluss wohl DHCPv6. Die Fritzbox schickt einen Solicit und bekommt eine Reply darauf. Dort steht alles drin. Wenn ich die PFsense dran hänge sehe ich einen (mehrere) Solicit aber keine Antwort aus dem DG Netz. Muss ich nun etwas spezielles einstellen oder filtert die DG doch irgendwie auf eine bzw. die Fritzbox? Hab aber auch schon die Mac von der Fritzbox auf der PF eingetragen - das alleine hilft nicht.

Was kann ich jetzt machen? Ich habe das DHCP so eingestellt wie hier beschrieben ( https://beechy.de/deutsche-glasfaser-ipv6-vs-pfsense/ ) Aber damit bekomme ich keine Antwort aus dem Netz. Bevor ich jetzt die DG mit der Frage nach MAC-Filter o.ä. konfrontiere, würde ich nur gerne wissen, ob DG mit DHCPv6 so wie in der verlinkten Anleitung auch funktioniert.

Frame 1924: 185 bytes on wire (1480 bits), 185 bytes captured (1480 bits)
Ethernet II, Src: AVMAudio_xx:xx:d9 (f0:b0:14:xx:xx:d9), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::f2b0:14xx:xxx:xxd9, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
    Message type: Solicit (1)
    Transaction ID: 0xa23b8f
    Elapsed time
        Option: Elapsed time (8)
        Length: 2
        Value: 0000
        Elapsed time: 0ms
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        Value: 00030001f0b014xxxxd9
        DUID: 00030001f0b014xxxxd9
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: f0:b0:14:xx:xx:d9
    Rapid Commit
        Option: Rapid Commit (14)
        Length: 0
    Identity Association for Non-temporary Address
        Option: Identity Association for Non-temporary Address (3)
        Length: 12
        Value: 14xxxxd90000000000000000
        IAID: 14xxxxd9
        T1: 0
        T2: 0
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 41
        Value: 14xxxxd90000000000000000001a00190000000000000000…
        IAID: 14xxxxd9
        T1: 0
        T2: 0
        IA Prefix
    Reconfigure Accept
        Option: Reconfigure Accept (20)
        Length: 0
    Option Request
        Option: Option Request (6)
        Length: 18
        Value: 00170038001f001900030011005200530056
        Requested Option code: DNS recursive name server (23)
        Requested Option code: NTP Server (56)
        Requested Option code: Simple Network Time Protocol Server (31)
        Requested Option code: Identity Association for Prefix Delegation (25)
        Requested Option code: Identity Association for Non-temporary Address (3)
        Requested Option code: Vendor-specific Information (17)
        Requested Option code: SOL_MAX_RT (82)
        Requested Option code: INF_MAX_RT (83)
        Requested Option code: PCP Server (86)
    Vendor Class
        Option: Vendor Class (16)
        Length: 4
        Value: 00000368
        Enterprise ID: AVM GmbH (872)


Frame 1925: 231 bytes on wire (1848 bits), 231 bytes captured (1848 bits)
Ethernet II, Src: 02:00:00:00:00:10 (02:00:00:00:00:10), Dst: AVMAudio_xx:xx:d9 (f0:b0:14:xx:xx:d9)
Internet Protocol Version 6, Src: fe80::ff:fe00:10, Dst: fe80::f2b0:14ff:fexx:xxd9
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
    Message type: Reply (7)
    Transaction ID: 0xa23b8f
    Identity Association for Non-temporary Address
        Option: Identity Association for Non-temporary Address (3)
        Length: 40
        Value: 14xxxxd90000000000000000000500182a006020xxxxxxxx…
        IAID: 14xxxxd9
        T1: 0
        T2: 0
        IA Address
            Option: IA Address (5)
            Length: 24
            Value: 2a006020xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            IPv6 address: 2a00:6020:1000:13:xxxx:xxxx:xxxx:xxxx
            Preferred lifetime: 2250
            Valid lifetime: 3600
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 41
        Value: 14xxxxd90000000000000000001a0019000008ca00000e10…
        IAID: 14xxxxd9
        T1: 0
        T2: 0
        IA Prefix
            Option: IA Prefix (26)
            Length: 25
            Value: 000008ca00000e10382a006020xxxxxxxxxxxxxxxxxxxxxxx…
            Preferred lifetime: 2250
            Valid lifetime: 3600
            Prefix length: 56
            Prefix address: 2a00:6020:xxxx:xxxx::
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        Value: 00030001f0b014xxxxd9
        DUID: 00030001f0b014xxxxd9
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: f0:b0:14:xx:xx:d9
    Server Identifier
        Option: Server Identifier (2)
        Length: 14
        Value: 000100011d9c43c4005056b97db1
        DUID: 000100011d9c43c4005056b97db1
        DUID Type: link-layer address plus time (1)
        Hardware type: Ethernet (1)
        DUID Time: Sep 28, 2015 20:30:28.000000000 Mitteleuropäische Sommerzeit
        Link-layer address: 00:50:56:b9:7d:b1
    Rapid Commit
        Option: Rapid Commit (14)
        Length: 0
    Reconfigure Accept
        Option: Reconfigure Accept (20)
        Length: 0
    DNS recursive name server
        Option: DNS recursive name server (23)
        Length: 32
        Value: 2a0060200100000000000000000000012a00602002000000…
         1 DNS server address: 2a00:6020:100::1
         2 DNS server address: 2a00:6020:200::1

Moin,

den Thread habe ich gelesen. Da es hier aber darum ging, dass auch die Fritzbox keine Verbindung bekam, habe ich das nicht in Zusammenhang stellen wollen.

Ich habe einen TCPDump (tcpdump -i xxx -nvv port 67 and port 68) mitlaufen lassen und habe dort beim v4 Handshake keine Option 212 entdeckt. Was ich nicht ganz verstanden habe, frage die pfSense die Option 212 automatisch ab wenn ich auf 6rd stelle oder muss ich das in den Advanced-Options erst aktivieren?

Die Fritzbox bekommt es ja hin (siehe Anhang), also denke ich, dass ich etwas falsch eingestellt habe. Ich weiß nicht ob mir die DGF da diesbezüglich weiterhelfen kann. Offensichtlich scheint der Anschluss ja in Ordnung zu sein. Vielleicht hat jemand ein funktionierendes pfSense-DHCPv6 Beispiel, damit ich das vergleichen kann.

Hallo liebe Mitglieder,

ich habe ein für mich nicht mehr ganz begreifbares Problem. Wir nutzen für eine Schule seit Ende letzten Jahres einen Anschluss der Deutschen Glasfaser. An diesem hängt eine pfSense Installation (2.4.5-RELEASE (amd64)) für diverse Zwecke, u.a. auch VPN. Bisher hat das Ganze über die im Internet auffindbare 6rd Konfiguration sehr gut funktioniert. Die Glasfaser ist über den "eigenen Router" informiert und grundsätzlich geht (ging) der Anschluss auch (Bandbreite etc. alles ok)

Eingestellt auf WAN ist:

6rd Prefix 2A00:61E0::/32

6rd Border relay 100.127.0.1

6rd IPv4 Prefix length 8

Seit ca. Mitte April bekomme ich keine Verbindung mehr über IPv6 zustande. Das automatisch berechnete IPv6 Gateway ist nicht pingbar (das IPv4 GW schon) Aus Verzweiflung habe ich eine Fritzbox an den Anschluss gesteckt und nach DGF Vorgabe konfiguriert. Hier klappt es mit IPv6. Interessanterweise kommt hierbei ein 2A00:6200:xxxx:xxxx / 56 Prefix um die Ecke. Ich weiß nun nicht ob die Fritzbox 6rd oder DHCPv6 macht, meine aber einen Haken bei 6rd gesehen zu haben.
Mit der pfSense bekomme ich weder mit 6rd noch mit DHCPv6 eine IPv6 Verbindung. v4 geht einwandfrei.

Eine Anfrage ist seit Freitag an die DGF raus. Leider noch unbeantwortet.

Da die VPN-Sache gerade in der jetzigen Zeit natürlich äußerst wichtig ist habe ich mir gedacht, ich frage hier einmal nach. Vielleicht gibt es ja andere Nutzer, die ein ähnliches Problem bereits haben / hatten.

Kann man der Fritzbox vielleicht irgendwie den Prefix / BR etc. entlocken? Bin für jeden Tip dankbar (erweiterte Linux Kenntnisse vorhanden)

Danke & Grüße
Andreas