Beiträge von ::1

Zitat von ::1

dg.voip.dg-w.de löst übrigens nur nach IPv4 auf: 185.22.44.186.

Ich würde deshalb bei "Internettelefonie-Anbieter kontaktieren über" explizit mal "Nur via IPv4" einstellen.

Vergiss das bitte.

Der Ablauf zur Registrierung erfolgt über einen DNS-Query

des Typs SRV für _sip._udp.dg.voip.dg-w.de

wie folgt (hier mit NSLOOKUP nachgestellt):

C:\>nslookup - 185.22.44.50
Standardserver:  dnscache001.dg-w.de
Address:  185.22.44.50

> set q=SRV
> _sip._udp.dg.voip.dg-w.de
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 20
          weight         = 1
          port           = 5060
          svr hostname   = sip20.voip.dg-w.de
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 10
          weight         = 1
          port           = 5060
          svr hostname   = sip10.voip.dg-w.de
> set q=A+AAAA
> sip20.voip.dg-w.de
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
Name:    sip20.voip.dg-w.de
Addresses:  2a00:6020:200:603::165
          185.22.45.165

> sip10.voip.dg-w.de
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
Name:    sip10.voip.dg-w.de
Addresses:  2a00:6020:100:603::186
          185.22.44.186

>

Die Registrierung kann also sowohl via IPv4 als auch via IPv6 zu sip10 oder sip20 erfolgen. Registrierungen via IPv6 und Telefonie via IPv6 habe ich auch schon in Paketmitschnitten an meinem Fritzbox-WAN-Port gesehen.

dg.voip.dg-w.de löst übrigens nur nach IPv4 auf: 185.22.44.186.

Ich würde deshalb bei "Internettelefonie-Anbieter kontaktieren über" explizit mal "Nur via IPv4" einstellen.

Zitat von Glasgau

Ich komme nicht zur Registrar. Sobald ich bei Anbieter, über andere Anbieter, die DG angebe, kann ich nur Username und Passwort eingeben.

Mehr kommt da nicht. Oder wo könnte ich das noch eingeben?

Der Registrar und weitere Einstellungen sind implizit durch Wahl des Telefonie-Anbieters "Deutsche Glasfaser" in der Box vordefiniert. Du kannst diese Daten sichtbar machen, indem du bei "Telefonie-Anbieter" auf "Andere Anbieter" umstellst.

Zitat von DaSokas

Mich macht das schon etwas stutzig, was die genauen Unterschiede sind.

Ich bin immer noch nicht ganz weg von der Idee interface-bezogener Filter bei der Palo, die den ND-Traffic reglementieren ...

Siehe meine Anmerkungen in #131.

Zitat von Neurothiker

Ich habe auf den Schnittstellen LAN&WAN v6 deaktiviert - wie ich aber schonsagte, kann es sein, dass die neu hinzugefügten Schnittstellen vlan&PPPoE v6 nutzen. Da muss ich, wenn das Frontend wieder nutzbar ist(derzeit eingefroren), nachschauen.

Da könnte ein Packet-Capture am Client helfen. Aus dem ginge hervor, welchen Resolver er verwendet.

Also, wenn dein Client beliebige Internet-FQDNs per DNS auflösen kann (kann er?), die zugehörigen DNS-Requests jedoch in deinem UNBOUND-Log nicht auftauchen, dann liegt der Verdacht nahe, dass dein Client unter Umgehung des UNBOUND einen anderen Resolver verwenden kann (über ein anderes Interface und/oder via IPv6 statt IPv4).

Also der Client hat nur eine IPv4-Adresse, aber keine IPv6-Adresse?

Und die IPv4-Adresse des per DHCP-Option erhaltenen DNS-Servers entspricht *.140.1?

Ich frage nur, um herauszufinden, ob der Client evtl. noch einen anderen Resolver anstelle des UNBOUND fragen könnte, z.B. via IPv6 und somit ggf. deinen UNBOUND umgehen könnte.

Zitat von Neurothiker

...kein Client mehr

Und der Testclient hat welche Resolver-Adesse(n) per DHCP/DHCPv6 bzw. ggf. SLAAC erhalten? sind das die LAN-seitigen UNBOUND-Adressen?

Ok, hat sich jetzt überschnitten. Wenn man dir jetzt eine öffentliche IPv4-Adresse geben konnte, dann hast du offensichtlich kein DS-Lite. Dann kannst du meinen letzten Post ignorieren.

Mir ist nicht so ganz klar, welche Art von Internetzugang du mit Novanetz du nun hast. Entsprechen die Screenshots in #6 denn der aktuellen Einstellung deiner Fritzbox? Falls ja, dann hast du einen sog. DS-Lite-Anschluss. Das bedeutet: Dein Router bekommt an seinem WAN-Port gar keine IPv4-Adresse mehr, sondern nur noch eine IPv6-Adresse. Dein LAN bekommt ein sog. IPv6-Präfix, aus dem sich die Endgeräte per Autokonfiguration selbst jeweils eine (öffentliche!) IPv6-Adresse generieren. IPv4-Pakete Richtung Internet werden nun von der Fritzbox über IPv6 "getunnelt", d.h. der Inhalt eines IPv6-Pakets ist ein vollständigen IPv4-Paket. Das wird dann beim Provider aus dem Tunnel "ausgepackt" und über einen zentralen NAT-Router beim ISP (CGNAT) nach dortiger Übersetzung deiner privaten IPv4-Quelladresse in eine öffentliche ins Internet gesendet.

Der Fritzbox-DynDNS-Client kann bei Selfhost folglich gar keine IPv4-Adresse mehr registrieren, weil du gar keine mehr hast. Er kann nach entsptrechender Anpassung nur noch die IPv6-Adresse am WAN-Port deiner Fritzbox registieren. Das würde ja passen, wenn du im Anschluss dorthin eine VPN-Verbindung via Wireguard konfigurieren möchtest.

Falls du MyFritz nutzt, brauchst Du Selfhost wiederum nicht mehr, weil MyFritz ja eine alternative DnyDNS-Lösung darstellt, die zudem auch noch die stellvertrendende Registrierung von Endgeräten (z.B. deine Synology) übernehmen könnte.

Aber nur zeige doch erst Mal, dass in deinem Netz IPv4 und IPv6 sauber funktionieren: Poste bitte mal die Ausgabe folgender Kommandos in einer Eingabeaufforderung an einem Windows-Rechner (ich gehe davon aus, dass du einen hast):

• ping -4 www.google.com
• ping -6 www.google.com

Dann zeige bitte mal folgende Screenshots deiner Fritzbox, wobei du gerne die Ziffern 9-16 (von links gezählt, also die zwischen dem zweiten und vierten ":") in deinen IPv6-Adressen schwärzen kannst:

• Internet | Online-Monitor | Verbindungsdetails
• Heimnetz | Netzwerk | Netzwerkeinstellungen | IPv6-Einstellungen | Verwendete IPv6 Präfixe (ganz unten auf der Seite)

Zitat von DaSokas

Ich bin sogar so weit gegangen und habe versucht der BNetzA zu erklären, dass man hier durchaus einen Router-Zwang ableiten könnte, da ich dazu gezwungen werde einen Nicht-Standardkonformen Router zu verwenden, wenn ich IPv6 verwenden möchte.

Ich denke, diese Aussage meinst du nur einschränkend für den BNG-Port zu deinem Kundenanschluss, um dessen vermutete Fehlkonfiguration zu kompensieren, also jedenfalls nicht generell?

Ich habe mir mal die Mühe gemacht, neben der allgegenwärtigen Fritzbox andere Router-Modelle an allen IPv6-aktiven DG-Anschlüssen zu identifizieren, die eine RIPE-Atlas Probe betreiben (LINK).

Auf Basis der Eigenbeschreibungen im Datenfeld "Router Type" konnte ich folgende Router-Modelle identifizieren:

• OPNsense: Probe 60646
• OpenBSD: Probe 53717
• MikroTik: Probes 1359, 14149, 28932, 61286, 1006149, 1010188

Ich denke mal, unter diesen drei genannten Router-Modellen wird sich bestimmt mindestens eines befinden, das bzgl. ND standardkonform arbeitet .

Zitat

IPv6 funktioniert, aber nur wenn ich einen defekten Router verwende, den die DG auch ganz zufälligerweise ihren Kunden anbietet.

Oder eher so:

Dein BNG (DG-Gateway) ist bezogen auf deinen Kundenanschluss mindestens dahingehend gestört/fehlkonfiguriert, als dass es die von deiner Palo erhaltenen NS an die zu seiner Gateway-Adresse gehörende SNMA nicht mit NA beantwortet. Diesen Fehler kann zwar eine Fritzbox aufgrund nicht RFC-konformer ND-Implementierung kompensieren, nicht jedoch ein RFC-konform arbeitender Router bzw. Endgerät. Ohne die BNG-Fehlkonfiguration könnte auch deine Palo reibungslos IPv6 nutzen.

Ich könnte mir folgende Ursache am BNG vorstellen:

Für das Interface zu deinem Anschluss hat kein Join zu der Multicast-Gruppe stattgefunden, die der SNMA der link-lokalen IPv6-Adresse des DG-Gateways entspricht. Deswegen nimmt es keine an diese SNMA gerichteten NS an. Das zu überprüfen, wäre mal ein konkreter Hinweis an DG.

Dein BNG gehört wohl zum "Hannover-BNG-Cluster-2", das für deinen Anschluss zuständige BNG müsste die DG-interne Adresse 2a00:6020:ffff:ffff::13 haben.

Zitat von DaSokas

Ich vermute mal, dass du sowas gesucht hast?

Nö, ich suchte nach Informationen zu rein interface-basierten Filterregeln, mit denen man ND-Traffic reglementieren kann. Ganz im Sinne von Chapter 4.4 in RFC4890 bezüglich dessen, was dort als "ICMPv6 Local Configuration Traffic" bezeichnet wird - im Gegensatz zu "ICMPv6 Transit Traffic" im Chapter 4.3 (was ich in einem früheren Post als "Passthrough" bezeichnet hatte).

Aber sowas scheint es bei einer Palo nicht zu geben, wie du ja auch schon gesagt hast.

Zitat von DaSokas

Ich habe auch meine alte FritzBox 7590 angeschlossen und festgestellt, dass es dabei keine Probleme gibt. Ein Packet Capture hat ergeben, dass die FritzBox (anscheinend) nicht Standardkonform arbeitet und aufgrund der eingehenden RA den Router sofort als "erreichbar" markiert.

Ja, wenn ich in die Packet-Captures aus meiner Fritzbox 7590 anschaue, sehe ich folgendes Verhalten:

Bis zum Abschluss der DHCPv6-Transaktionen zum Bezug einer IPv6-Lease (IA_NA, IA_PD) sehe ich keinerlei NS/NA-Kommunikation außer denen, die die Fritzbox für ihre eigenen IPv6-Adressen im Rahmen der DAA (Duplicate Address Detection) sendet.

Die erste NS, die die Fritzbox zur Auflösung der DG-Gateway-Adresse sendet, erfolgt bereits als IPv6-Unicast an eben jene Gateway-Adresse und nicht als IPv6-Multicast an die aus der Gateway-Adresse abgeleitete SNMA (solicited node multicast address). Das deutet darauf hin, dass die Fritzbox die DG-Gateway-Adresse zusammen mit deren MAC-Adresse bereits im Neighbor-Cache hatte (statt state=STALE, offenbar schon als REACHABLE geflagt). Dort hinein kann der Eintrag aber nur durch vorangegangene, erhaltene RA des DG-Gateways gelangt sein. Eine Verwendung von SNMA sehe ich nur für NS, die das DG-Gateway an meine Fritzbox sendet, witzigerweise auf Ethernet-Ebene als Unicast an die MAC meiner Fritzbox und nicht als Ethernet-Multicast an 33:33:xx:xx:xx:xx.

Ach, noch eine Idee: Um die Palo als Ursache wirklich auszuschließen, klemm doch einfach mal einen PC direkt an den Anschluss (aber erst mal 1 Stunde warten!). In deinem Packet Capture dort solltest du dann auch keine NS/NA-Kommunikation sehen, wenn es tatsächlich an DG liegt.

Zitat von DaSokas

Ich stimme der Aussage, dass dort "genügend Raum" sei, allerdings nicht zu.

Dann würde ich die fundierte Problembeschreibung in ein separates Dokument auslagern und dieses als PDF-Attach anhängen.

Zitat von DaSokas

Das TKG macht keine Vorgaben, dass eine Konnektivität via IPv4 oder IPv6 gegeben sein müsse.

Das wäre ja ziemlich sinnfrei!?

Aber ja, das Problem ist herausfordernd, du kannst nur hoffen, bei DG einen last-level-Techie zu finden, der es versteht und in die richtigen Bahnen leiten kann. Und genau das passiert aber leider häufig erst nach Regress- oder Kündigungsandrohungen.

Eine Unsicherheit in der technischen Analyse habe ich noch: Welchen View zeigen deine Captures?

1. Den Traffic, bevor (outbound) eine Firewall-Regel greift, die das Paket dann doch verwirft, und (inbound), nachdem zuvor schon eine Firewall-Regel gegriffen und ein Paket verworfen hat, so dass du es im Capture gar nicht mehr siehst?
2. Den Traffic so, wie er (nach Berücksichtigung von FW-Regeln) outbound die Firewall verlässt, bzw. inbound, bevor eine FW-Regel greift?

Im Fall (1) würdest du genau die Captures sehen, die du durchgeführt hast - tatsächlich hätte deine Firewall aber ausgehend und einkommend NS/NA gedroppt.

Die Palo ist schon ein ziemliches Monster. Die Doku zu PAN-OS wirkt erschlagend - was ich dort suchte, fand ich jedenfalls nicht.

Zitat von DaSokas

Wenn dem wenigstens so wäre, allerdings wurde ein Routing-Problem von Anfang an von der DG ausgeschlossen. Ich wüsste nicht, wie ich das auf meiner Seite überprüfen könnte.

NS/NA-Kommunikation erfolgt ja stets nur link-lokal. Wenn sie also nicht funktioniert, kann das nicht an einem Routing-Problem liegen. Ein solches liegt ja auch nicht vor, denn IPv6 funktioniert problemlos mit dem statischen Neighbor-Cache-Eintrag. (Nachtrag: Entschuldigung, deine Aussage bezog sich ja auf die von mir zitierten fehlgeleiteten NA-Antworten zu anderen Kundenanschlüssen als dem, aus dem das anfordernde NS kam - ja, insofern ein "Fehlrouting", obwohl es streng genommen kein "Routing" ist, sondern ein Konfigurationsfehler des BNG)

Ich würde nochmal ein Packet-Capture von einem DG-Connect, beginnend mit der WAN-Interface-Initialisierung erstellen, das alle relevanten Pakete (Raw-Daten geeignet filtern: icmpv6 || dhcpv6) enthält. Hinweis: Dein gezeigter Packet Capture bestand aus zwei getrennten Traces für beide Richtungen. Diese kannst du in Wireshark wie folgt mergen: Öffne erst eine der beiden Dateien. Wähle dann "Datei | Zusammenführen...". Aktiviere im Dateiauswahl-Dialog die Option "Chronologisch zusammenführen" und wähle anschließend die andere Datei aus. Anschließend den Merge unter separatem Namen speichern.

Wie auch schon mehrfach hier im Forum empfohlen, verwende unbedingt das DG-Kundenportal und mache dort unter "Service | Kontaktformular" ein Ticket auf. Dort hast du genügend Raum, das Problem möglichst präzise zu beschreiben. Füge auch einen Screenshot des Packet Capture bei, das allein ist schon sehr aussagekräftig. Die Capture-Datei solltest du natürlich als Attach mit anhängen. Du kannst ja auch noch gerne deinen Einstiegs-Post in diesem Thread mit verlinken.

Da deine technische Argumentation ziemlich schlüssig ist, kannst du auch etwas tougher auftreten und durchaus Regress-Ansprüche andeuten. Ich habe gelernt, dass bei DG letzteres tatsächlich weiterhelfen kann (leider, ich würde mir das auch anders wünschen).

Zitat von Hotte

Wenn ich allerdings über VPN ins Netz gehe habe ich nur ipv4 und das bei mehreren Servern.

Ruf doch mal wasistmeineip auf, wenn du über VPN ins Netz gehst. Dort wirst du wahrscheinlich nur eine IPv4-Adresse sehen, die nicht dir, sondern dem VPN-Anbieter gehört (deshalb nutzt du ja auch VPN).

Übrigens: In diesem Post zu einem ähnlichen Problem (erhält IPv6-Adressen, kann aber dennoch nicht via IPv6 mit dem Internet kommunizieren) habe ich nach Auswertung eines Packet Capture die folgende Beobachtung festgehalten:

"Die IPv6-Kommunikation beschränkt sich auf den Austausch von ND-Paketen (NS, NA, RA) mit der DG-Gegenstelle (fe80::22). Auch hier auffällig: Du erhältst unzählige Neighbor-Advertisments (NA) als Unicasts an linklokale IPv6-Adressen, die vermutlich nicht zu deinem Anschluss gehören, und die als "solicited reply" geflagt sind, obwohl von deinem Router zuvor keine dazu passenden Neighbor-Solicit (NS) gesendet wurden."

Ich hatte dann mal näher anhand der OUI der Ziel-MAC-Adressen der fehlgeleiteten NA festgestellt, dass sie alle zu AVM bzw. SAGEMCOM (von denen ist der einfachere DG-Mietrouter) gehören.

Vielleicht werden die NA zu den von deiner Palo gesendeten NS ja auch zu anderen Kundenanschlüssen fehlgeleitet ...

Der RFC formuliert diesbezüglich auch nur "SHOULD", nicht "MUST". Wenn die Palo einen Eintrag erzeugt, müsstest du ihn nach Erhalt eines RA sehen.

Noch eine andere Frage:

In deinem Packet Capture habe ich keinerlei NS gesehen, die vom DG-Gateway an die Palo gesendet werden. War das nur in diesem Capture der Fall, oder sieht man auch keine ankommenden NS bei längeren Laufzeiten? Ein NS von der Gegenstelle enthält ja ebenfalls eine "Source link-layer address option", mit der die Palo einen Neighbor-Cache-Eintrag generieren könnte bzw. würde.