Beiträge von ::1

Also ich finde es schon auffällig, dass die erreichte Geschwindigkeit in der "schnelleren" Richtung statt des erwarteten theoretischen Werts von 100 MBit/s praktisch nur den Maximalwert von 40 MBit/s erreicht, der exakt dem theoretischen und praktisch ermittelten Maximalwert in der "langsamen" Richtung entspricht. So, als gäbe es da eine Symmetrie-Bedingung, die für beide Richtungen nur den kleineren der beiden richtungsabhängigen Werte aushandelt.

Allerdings finde ich in der Wireguard-Protokoll-Spezifikation (Link, ziemlich schwere Kost) keinerlei Hinweise auf so eine symmetrische Geschwindigkeitsaushandlung - das wäre für ein VPN-Protokoll wohl auch recht ungewöhnlich.

Natürlich könnten die RASPIs auch gerade ihr Limit bei 40 MBit/s erreicht haben, aber das wäre natürlich auch ein merkwürdiger Zufall, dass das gerade der Upload-Geschwindigkeit in der langsameren Richtung entspricht.

Dann noch ein Frage:

UDP/IP-Transport zwischen den RASPIs ist offenbar IPv4. Will heißen, dass wegen CGNAT am DG-Anschluss nur der RASPI am DG-Anschluss die Verbindung zum RASPI am Telekom-Anschluss aufbauen kann. Anderseits bietet ein Telekom-Anschluss auch IPv6. Eventuell könnte man das ja dort aktivieren, um mal eine Transport-Verbindung zwischen des beiden RASPIs mit IPv6 (mit getunneltem IPv4) zu testen? Vielleicht macht das ja einen Unterschied.

Zitat von Kevin

Zum Beispiel hier

https://ipv6-test.com/

Hm, was soll ich von einer IPv6-Testseite halten, die mir folgendes Ergebnis liefert?

Dann muss ich dort wohl mit IPv5 zugegriffen haben.

Man muss da öfter mal den Retry-Knopf pro Testsektion drücken, um etwas anderes zu sehen zu bekommen - und auch da können die Ergebnisse vom vorhergehenden Versuch abweichen. Mir scheint, die Seite hat erhebliche Ressourcen-Probleme - alles sehr zäh bis gar nicht (Ping- und Speed-Test) funktionierend.

Ich würde eher diese IPv6-Testseite empfehlen: https://test-ipv6.com/

Also, zur Abwechslung mal was Positives zum DG-Service:

In der neuesten Version des Kunden-Portals findet man jetzt unter "Mein Postfach" | "Meine Anfragen" eine Liste der Kontakte mit dem Service (über alle Eingangskanäle: E-Mail, Telefon, ...) mit Angabe der Bearbeitungsnummer und im Falle "E-Mail" auch mit Auflistung der ausgetauschten Mail-Inhalte.

Sehr gut!

Ebenfalls positiv zu erwähnen: Bei allen telefonischen Anfragen war die Erreichbarkeit stets hervorragend - kein ewiges Verweilen in einer Warteschlange!

Eine Kritik hätte ich dennoch (und die habe ich auch schon mehrfach gegenüber dem DG-Service geäußert): Die Fälle werden gerne vorzeitig geschlossen, auch wenn die damit verbundenen Probleme noch nicht gelöst sind. Meldet man sich erneut per Mail zu dem Problem, wird selbst dann eine neue Bearbeitungsnummer vergeben, wenn man im Betreff als Referenz die erstmalig vergebene Bearbeitungsnummer angibt. Das schafft aus Kundensicht Verdruss und stiftet Verwirrung, weil der Zusammenhang bzw. Bezug zum Ausgangsproblem verloren geht. Es sollte nicht mein Job als Kunde sein, den Zusammenhang durch Aufsammeln und Benennen aller Bearbeitungsnummern herstellen zu müssen. Da sehe ich noch deutlichen Verbesserungsbedarf im Fall-Management.

Nein, wer hätte es gedacht: Ab heute funktioniert das Kundenportal wieder wie es soll .

Gleich mal meine zweite Rufnummer dem 2. SIP-Account zugeordnet.

Auch wenn das jetzt keine Glanzparade von euch war, liebe DG, trotzdem vielen Dank!

Ich brauche das Kundenportal eigentlich nur, um meine Rechnungen abzurufen (was immerhin noch funktioniert), ansonsten nur einmalig, um endlich wieder meine zweite Rufnummer dem zweiten SIP-Account ("2. Telefonleitung") zuzuordnen. Das ist aus mir unerfindlichen Gründen auf den Default (beide Rufnummern auf dem 1. SIP-Account) zurückgesetzt worden. Die Kosten von 1,50 €/Monat für den 2. SIP-Account hat man mir immerhin für 3 Monate gutgeschrieben, aber wenn diese Zeit um ist, werde ich das Feature eben kündigen, weil ich keine Lust mehr habe, weiterhin wertvolle Lebenszeit für das Problem zu verschwenden. Die Kundenzufriedenheit scheint DG da wohl nicht sonderlich wichtig zu sein.

Möglicherweise sind wir beide ja auch die einzigen von diesem Problem betroffenen Nutzer (mich wundert schon, dass sich da sonst niemand hier im Forum gemeldet hat), dann ist's aus deren Sicht vermutlich eh egal.

Viel mehr nervt mich, dass ich in den letzten 3 Monaten zweimal (so im Abstand alle paar Wochen) Spaß und Kurzweil hatte mit DHCPv4- und DHCPv6-Leases, die nicht verlängert wurden - kann man schön in Packet-Traces am WAN-Port meiner Fritzbox 7590 mitschneiden: Wenn nach T1 kein Renew erfolgt, wird man schon nervös, ob denn bei T2 wenigstens noch ein Rebind erfolgt. Und wenn die Verbindung erst mal weg ist, wird der Abstand der DHCP-Solicits bei Nichtbeantwortung ja stets verdoppelt, so dass Stunden vergehen können, bis endlich mal wieder was kommt (kürzlich vergingen 5 Stunden, bis ich endlich wieder IPv6-Adressen bekam). Die Schaltfläche "Neu verbinden" wird so zum Angstknopf, den man ungern drückt, wenn man Internet für's Home-Office dringend braucht.

Bei Anruf beim Support bekommt man dann gesagt, dass es am Router liegt, und da das nicht deren Mietrouter ist, lassen sie einen im Regen stehen. Router-Reset hilft manchmal, möglicherweise aber nur, weil man deren DHCP-Server dann mit einer neuen XID zur Mitarbeit motivieren kann, wenigstens für eines der beiden Protokolle IPv4 bzw. IPv6.

Liebe DG: So geht das nicht! Ob ich nach Ablauf der ersten 2 Jahre noch euer Kunde bin, kann ich nicht versprechen.

Man muss das als Akt erzwungener Kundenbindung deuten: Das Kündigungsformular (Service | Kündigung) wird mit einem "Bad request" quittiert ...

Zitat von exponentialverteilt

in denen seit 2012 bei Neuanschaffung von Hardware IPv6-Unterstützung zum Pflichtkatalog gehört.

Lach - das habe ich in der Firma (und das ist keine kleine Klitsche), in der ich arbeite und u.a. für IPv6-Einführung zuständig bin, auch mal versucht. In einem Testballon hatten wir Drucker-Herstellern (IPv6-technisch kein großer Anspruch - es müssen ja lediglich Endgeräte-Features unterstützt werden) unseren IPv6-Anforderungskatalog geschickt. Oje - die konnten so gar nichts damit anfangen (was ist SLAAC?) - was da zurück kam, war nur peinlich.

Außerdem, was soll denn genau "IPv6-Unterstützung" sein? Nach welchem Kriterien-Katalog (das hier ist noch das beste, was es da gibt - hingegen ist das hier ziemlicher Müll, wird aber von einigen Herstellern gerne genutzt, um sich mit IPv6-Unterstützung zu schmücken - die bieten dann z.B. IPv6-Internet-Zugangsrouter für SOHO ohne IPv6-Firewallfunktion an)? Welcher Gerätetyp soll genau was können aus dem Zoo von Hunderten IPv6-RFCs, wobei in manchen Fällen je nach Gerät/HW auch nicht der Gesamt-Umfang eines bestimmten RFC erfüllt sein muss? Nachdem meine selbst erarbeitete Excel-Tapete, die Geräte-Typen gegen IPv6-RFCs und RFC-sub-features mit MUST, SHOULD, MAY aufgelisted hat, gefühlt unendlich groß geworden ist, habe ich sie weggeschmissen.

Und hier noch ein Beispiel aus der Praxis: L3-Switch eines namhaften Herstellers verspricht IPv6-Unterstützung - schön, haben wir also eine zukunftsfähige Hardware gekauft! Aber ach: Jetzt haben wir darauf VRF eingerichtet und stellen fest: Bestimmte Features innerhalb eines VRF stehen nur für IPv4 zur Verfügung, nicht aber für IPv6 - das kann das Modell für IPv6 nur im globalen Routing-Kontext. Vielen Dank, lieber Hersteller, wie fühlen uns veralbert!

Zitat von Luto

Wäre ein gangbarer Weg die Fritzbox in das 10er-Netz aufzunehmen und den Lancom dann einfach so daran zu hängen?

Also wenn der Lancom weiterhin noch eine Funktion haben soll, die die Fritzbox nicht übernehmen kann, dann macht das keinen Sinn. Andernfalls könnte man die Lancom-Box auch gleich ganz weglassen.

Wenn man also alles so lässt wie es ist, sehe ich zwei Lösungsmöglichkeiten, die oben schon beschrieben sind:

1. Du benutzt die bestehende Fritz-Fritz-VPN-Kopplung via IPv4 zu deinem Heimnetz - die funktioniert ja, wie du sagst (wobei nur die Firmen-Fritzbox die Verbindung zur Heim-Fritzbox aufbauen kann, nicht umgekehrt - CGNAT ist da wie eine Diode). Damit kommst du dann von zu Hause aus aber nur in das 192.168-Zwischennetz, nicht jedoch in das 10er-Netz der Firma. Du könntest nun in der Lancom-Box z.B. ein 1:1 NAT einrichten (pro 10er-Adresse eines Dienstes im Firmen-Netz, den du erreichen möchtest, eine 192.168-Adresse aus dem Zwischennetz) und die Lancom Firewall einkommend entsprechend aufmachen. Oder du richtest im Lancom für die IPv4-WAN-Adresse aus dem Zwischennetz Portweiterleitungen zu Diensten im 10er-Netz ein, die du erreichen willst, z.B. für den Zugriff auf einen WTS per RDP (3389\udp) - so einen WTS könntest du dann ja als Sprungserver ins Firmen-Netz verwenden.
2. Du verwendest in deinem Heimnetz an einem Desktop-PC einen geeigneten VPN-Client, der via IPv6 (muss in deinem Heimnetz und am dortigen Internetzugang natürlich vorhanden sein) eine VPN-Verbindung zur IPv6-Adresse des WAN-Ports des Lancom aufbaut. Im VPN-Tunnel muss dann IPv4 gesprochen werden. Damit kommst du direkt im 10er-Firmennetz raus. Du brauchst für den WAN-Port des Lancom noch DynDNS, da dessen IPv6-Adresse aus einem /56-Pool kommt, der sich potentiell ändern kann. Dein VPN-Client muss die Gegenstelle dann über den FQDN ansprechen, nicht direkt über die IPv6-Adresse.

Zitat von Sascha.F

Bei mir geht's nach wie vor nicht. Hat sich bei Dir etwas getan?

Nein.

Aber "die Experten dort arbeiten ja mit Hochdruck an einer Lösung"

Da können wir uns doch entspannt zurück lehnen.

Ja, so eine Nachricht, offenbar basierend auf einem Textbaustein, habe ich auch bekommen. Allerdings erst nach mehreren Anläufen am 06.07.2022, obwohl ich das Problem bereits mit einer sehr genauen Beschreibung am 11.06.2022 gemeldet hatte.

Was ich dabei ärgerlich finde: Wenn sie es doch wissen (und es doch sicherlich auch am 11.06. schon wussten) - wieso schicken sie dann nicht gleich diese Info raus?

"... und probieren Sie im Verlaufe der Tage nochmal" - Welches Wort passt hier wohl nicht?

Ich frage mich, was man bei DG für interne Schwierigkeiten hat, so ein Problem zeitnah zu lösen.

EDIT

Ich muss mich korrigieren: Wie ich eingangs schon geschrieben hatte, wurde ich doch schon am 20.06.2022 informiert dass ...

"Gerne habe ich Ihr Anliegen überprüft und muss Ihnen mitteilen, dass ein paar technische Herausforderungen mit unserem Kundenportal aufgetreten sind. Unser Expertenteam arbeitet schon intensiv daran, dies zu beheben." (Aber auch hier passt ein Wort nicht so recht ...)

Das liegt jetzt doch im Rahmen. Die zweite Nachricht vom 06.07.2022 war nur eine erneute Bestätigung, weil ich ungeduldigerweise nochmals nachgefragt hatte.

/EDIT

Zitat von exponentialverteilt

Ich habe z.B. an meinem Anschluss NAT64 als Übergangsmechanismus in die alte Welt.

Hallo, nur interessehalber:

Das ist vermutlich ein Eigenbau-NAT64 (mit zugehörigem DNS64)?

Oder ist das tatsächlich eine Dienstleistung deines ISP, weil der nur noch IPv6-only-Anschlüsse anbietet?

Sascha.F : Der Link zur JPG zeigt leider kein Bild ...

Aber ja, was für ein Armutszeugnis seitens DG.

Zitat von alfalfa

Das wird sich mit IPv6 nicht grundsätzlich ändern.

Hm, naja, angesichts der üblicherweise verwendeten Privacy-Extensions an Endgeräten hinter Consumer-Zugängen macht ein Blockieren einzelner IPv6-Adressen (hierzu gefunden: "UCEPROTECT Blacklist Policy LEVEL 1", siehe hier) nun wirklich keinen Sinn, da hoffe ich dann auch auf "vernünftige" Sichtweisen. Wenn schon, müsste man da gleich den zugehörigen /56 des PD-Blocks (Level 2) als Pendant zur geblockten IPv4-Adresse am WAN-Port des Internet-Zugangsrouters (sofern noch öffentlich) bzw. zur CGNAT-Adresse in die BL aufnehmen. Das hielte ich gelinde gesagt für sehr gewagt.

Zitat von alfalfa

Das "deshalb" bezog sich darauf, dass Web.de und GMX den Kunden anhand der Login-Daten einwandfrei identifizieren können und nicht darauf angewiesen sind, ihn per DNSBL in Sippenhaft zu nehmen. Eine IP-Adress-Sperre ist dann so, als würde man sagen: "Wir wissen zwar, wer du bist, aber wir blocken dich trotzdem, weil der da drüben dich nicht kennt." Das erscheint mir nicht vernünftig.

Dir mag das nicht vernünftig erscheinen, aber woher weißt du, dass GMX/web.de genauso vernünftig sind wie du?

Zitat von alfalfa

Sehr viele IP-Adressblöcke von Access Providern stehen auf DNSBLs. Das trifft auch auf Adressbereiche zu, die nicht für CGNAT verwendet werden.

Ok, auch an einem "vollwertigen" IPv4-Consumer-Anschluss (z.B. der Telekom) kann ich eine IPv4-Adresse zugewiesen bekommen, die durch Missbrauch des Vorbesitzers (der ggf. als Opfer bzw. Teil eines Bot-Netzes gar nichts davon wusste) auf eine BL gekommen ist. Aber die Wahrscheinlichkeit, dass mich solch eine Blockade trifft, ist mit einer CGNAT-Adresse doch ungleich größer, weil der ja eben in der Regel deutlich kleiner ist als der Access-Pool eines großen Providers wie Telekom, der jedem Kunden immer noch den Luxus einer eigenen öffentlichen IPv4-Adresse aus einem Riesen-Pool bieten kann. Ein /18 der DG enspricht 2^14=16384 CGNAT-Adressen - der Access-Pool der Telekom ist da sicherlich um einige Größenordnungen größer.

Zitat von alfalfa

Eine IP-Adress-Sperre erscheint mir deshalb wenig sinnvoll und das eigentliche Problem zu sein, und nicht etwa, dass du eine Verbindung mit CGNAT nutzt.

Nun ja, CGNAT-Adressen der DG liegen im Block 94.31.64.0/18. RIPEstat sagt dazu (siehe hier) :

94.31.64.0/18 has been found in RECENT blocklists

Zitat von alfalfa

Wenn das VPN mit IPv6 als Transportprotokoll auf dem Lancom hinter der Fritzbox terminieren soll, dann reicht es, wenn der Lancom eine IPv6 Adresse von der Fritzbox bekommt, was in der Voreinstellung ohne PD der Fall sein sollte.

Das ist wahrscheinlich die beste, weil stabilste (kein hinderliches NAT) Lösung:

Man muss ja auch keine site-to-site-Kopplung vom LANCOM-Router zur heimischen Fritzbox als VPN-Peer via IPv6-Transport herstellen (was seitens der Fritzbox vermutlich ohnehin nicht unterstützt würde). Es würde ja reichen, eine client-to-site VPN-Verbindung von einem VPN-Client auf einem IPv6 sprechenden PC im Heimnetz zur IPv6-Adresse des LANCOM-WAN-Ports aufzubauen.

Voraussetzungen:

• Heimnetz mit IPv6
• DynDNS für die IPv6-Adresse am WAN-Port des LANCOM-Routers (weil sich das /56-LAN-Präfix am privaten DG-Anschluss ja prinzipiell ändern kann)
• Geeignete VPN-Client-Software mit einem VPN-Protokoll (z.B. IPsec), das Client und LANCOM-Router unterstützen, und das getunneltes IPv4 mit IPv6-Transport ermöglicht.

Verständnisfragen zur Ausgangssituation:

Ich vermute mal, dass IPv6 im Firmennetz nicht von Interesse ist - das soll alles weiter laufen wie gehabt mit IPv4-only?

Wie ist der LANCOM-Router konfiguriert? Exakt wie vorher, als an seinem WAN-Port noch direkt das Internet hing - jetzt nur mit dem Unterschied, dass die WAN-IP eine private Adresse aus dem Fritzbox-LAN ist? Das würde dann ja bedeuten, dass der LANCOM seinerseits ein (ausschließlicher) NAT- bzw. PAT-Router ist, der ausgehend das 10er-Firmennetz auf die eine IP-Adresse am WAN-Port nattet. In Summe wäre das dann ein Triple-NAT zum Internet.

Hi,

ich weiß jetzt nicht, ob die "FritzBox-FritzBox-VPN-Verbindung" mit IPv6 als Transport-Protokoll durch das Internet unterstützt wird. Wenn das nur mit IPv4 möglich ist, kann ich mir ihr Zustandekommen nur dadurch erklären, dass die heimische Fritzbox an einem Internet-Anschluss hängt, die noch eine öffentliche IPv4-Adresse am WAN-Port bekommt - dann kann zumindest von der Fritzbox am DG-Anschluss eine Verbindung über CGNAT hinweg (mittels NAT-Traversal) zur heimischen Fritzbox aufgebaut werden, aber nicht umgekehrt.

Dass nun das 10er-Firmennetz hinter der LANCOM-Box nicht erreicht wird, könnte an zwei Dingen liegen:

• In der Fritzbox der Firma fehlt eine IPv4-Route zum 10er-Netz hinter dem LANCOM-Router
• Man muss bei der Einrichtung der "FritzBox-FritzBox-VPN-Verbindung" auch angeben, dass der betreffende 10er-Bereich, der ja nicht direkt an der Firmen-Fritzbox anliegt, ebenfalls durch die IPsec-Verbindung zu tunneln ist - da weiß ich nicht, ob die Fritzbox sowas überhaupt ermöglicht.

EDIT - zu den letzten beiden Punkten, falls zutreffend noch eine Idee als Workaround: Man könnte den LANCOM-Router als IPv4-NAT-Router konfigurieren, und einzelne IPv4-Adressen im 192.168.x.x-Netz der Firma als "Einwärts"-Dienstadressen zu definieren, die ins 10er-Firmennetz genattet werden zu 10er-Adressen von Diensten, die von außen durch den VPN-Tunnel angesprochen werden sollen.

Wow, so viel Resonanz auf meine Frage hätte ich gar nicht erwartet!

Danke für die guten Erklärungen - "again what learned"

Zitat von Phino

Aus eigenen Erfahrung weiß ich, dass das Hosten von mehreren Webseiten mit verschieden IPv6 Adressen deutlich aufwendiger ist als eine IPv4 Adresse für 50 und mehr Webseiten zu hosten. Das liegt daran, dass Bind es für IPv4 out-of-the-Box macht. Dasselbe mit IPv6 Adressen ist schon verwaltungsmäßig deutlich aufwendiger.

Nur interessehalber- ist nicht mein Fachgebiet:

Welche Zauberfunktion besitzt denn Bind (ich verstehe darunter die bekannte DNS-Server-Implementierung), um über die Auflösung von N (N>50) FQDNs verschiedener Webpräsenzen auf die immerselbe IPv4-Adresse hinaus zur richtigen Webpräsenz zu "routen"? Für mich liegt das etwas außerhalb des Scopes eines DNS-Servers bzw. des DNS-Funktionskonzepts.

Ich verstehe ja, dass es irgendeine Instanz geben muss, die anhand der den jeweiligen FQDN beinhaltenden Aufruf-URL entscheidet, welche Web-Präsenz zu präsentieren ist, hätte diese Instanz jetzt aber nicht im DNS-Server verortet.