O2 VDSL - nur noch Verbindungen via IPV6 möglich, IPV4 tot

[mokabo]

Guten Abend,

Seit letzter Woche ist der Zugriff auf das Internet für mich auf IPV6 beschränkt und ich konnte dies bisher nicht beheben.
Ich kann bspw. computerbase via HTTP erreichen(IPV6 Support), amazon bspw. nicht
Andere Protokolle, bspw. ssh, selbe Problematik

Facts:

• VDSL50 Anschluss bei O2, also nix mit DS Lite etc. sondern reale IPV4 Verbindung mit parelleler IPV6 Verbindung in die Außenwelt
• O2 sagt Leitung sei in Ordnung, ich soll doch das Endgerät überprüfen(ja, dafür hab ich extra ne Fritzbox gekauft), bin nach außen hin sichtbar via IPV4 sowie IPV6, Fritzbox bestätigt dies.
• Fritzbox 7530 als Alternative zu vorherigem TP Link Archer vr600v geholt, gleiche Problematik
• 3 verschiedene Endgeräte(Windows/Debian/Android), selbe Problematik.
• https://ipv6-test.com (und andere ähnliche Seiten) sagt IPV4 not supported
• verschiedene DNS-Server manuell gesetzt, keine Veränderung
• sobald ich IPV6 an der fritzbox testweise deaktiviere, ist logischerweise alles tot

Die Fritzbox ist neu und damit quasi auf Werkseinstellungen, nur den O2 Anschluss mit Zugangsdaten eingerichtet, sonst nichts verändert.

Ich bin echt überfragt, inwiefern da der Fehler noch an meinem Ende liegen soll, die einzige Option, die ich noch testen kann, ist die komische Homebox von O2 direkt.

Generell liest man von solchen Problemen ja gelegentlich bei den Kabelanbietern, die DS-Lite nutzen. Im Kontext von VDSL aber findet man online relativ wenig, bin mit meinem Latein am Ende und hoffe hier hat evtl. jemand den ultimativen Tipp, bevor ich erneut in der O2 Hotline Warteschlange platz nehme

Hier nun bisschen Debug-Output vom Windows-Rechner, aber wie bereits gesagt, die Problematik am Latop(Debian) und Smartphone(Android) ist die Gleiche.

Spoiler: ipconfig

C:\Users\user>ipconfig -all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : DESKTOP-AP9EVJ0
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : 40-61-86-87-F4-99
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2a01:c22:7a21:a900:f448:3d2d:e331:cd20(Preferred)
   Temporary IPv6 Address. . . . . . : 2a01:c22:7a21:a900:85f:49d:25cd:50f5(Preferred)
   Link-local IPv6 Address . . . . . : fe80::f448:3d2d:e331:cd20%7(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.178.25(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::2e91:abff:fe6d:eb1c%7
                                       192.168.178.1
   DHCPv6 IAID . . . . . . . . . . . : 71328134
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-8A-F0-19-40-61-86-87-F4-99
   DNS Servers . . . . . . . . . . . : fd00::2e91:abff:fe6d:eb1c
                                       8.8.8.8
                                       8.8.4.4
   NetBIOS over Tcpip. . . . . . . . : Enabled

Exemplarisch für superuser.com (IPV4 only)

Spoiler: nslookup

C:\Users\user>nslookup superuser.com
Server:  fritz.box
Address:  fd00::2e91:abff:fe6d:eb1c

Non-authoritative answer:
Name:    superuser.com
Addresses:  151.101.129.69
          151.101.1.69
          151.101.193.69
          151.101.65.69

Spoiler: tracert

C:\Users\user>tracert superuser.com

Tracing route to superuser.com [151.101.129.69]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     9 ms     8 ms     8 ms  loopback1.0004.acln.01.muc.de.net.telefonica.de [62.52.200.115]
  3    18 ms    20 ms    20 ms  bundle-ether14.0005.dbrx.01.muc.de.net.telefonica.de [62.53.13.38]
  4    16 ms    15 ms    15 ms  ae5-0.0001.corx.04.muc.de.net.telefonica.de [62.53.2.130]
  5    16 ms    16 ms    15 ms  ae20-0.0002.corx.02.fra.de.net.telefonica.de [62.53.5.83]
  6    16 ms    16 ms    16 ms  bundle-ether2.0002.dbrx.01.off.de.net.telefonica.de [62.53.0.209]
  7    26 ms    26 ms    27 ms  bundle-ether2.0001.prrx.01.off.de.net.telefonica.de [62.53.28.177]
  8    16 ms    15 ms    16 ms  fastly1.fra.ecix.net [62.69.146.88]
  9    16 ms    15 ms    15 ms  151.101.129.69

Spoiler: ping

C:\Users\user>ping superuser.com (IPV4 o

Pinging superuser.com [151.101.129.69] with 32 bytes of data:
Reply from 151.101.129.69: bytes=32 time=16ms TTL=56
Reply from 151.101.129.69: bytes=32 time=15ms TTL=56
Reply from 151.101.129.69: bytes=32 time=15ms TTL=56
Reply from 151.101.129.69: bytes=32 time=15ms TTL=56

Ping statistics for 151.101.129.69:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 16ms, Average = 15ms

Spoiler: curl

C:\Users\user\Desktop\curl>curl.exe -v superuser.com
*   Trying 151.101.129.69:80...
* connect to 151.101.129.69 port 80 failed: Timed out
*   Trying 151.101.1.69:80...
* connect to 151.101.1.69 port 80 failed: Timed out
*   Trying 151.101.193.69:80...
* connect to 151.101.193.69 port 80 failed: Timed out
*   Trying 151.101.65.69:80...
* connect to 151.101.65.69 port 80 failed: Timed out
* Failed to connect to superuser.com port 80: Timed out
* Closing connection 0
curl: (28) Failed to connect to superuser.com port 80: Timed out

Exemplarisch für computerbase.de (IPV4&IPV6)

Spoiler: nslookup

C:\Users\user\Desktop\curl>nslookup computerbase.de
Server:  fritz.box
Address:  fd00::2e91:abff:fe6d:eb1c

Non-authoritative answer:
Name:    computerbase.de
Addresses:  2a02:cbf3:210::a2
          87.230.75.2

Spoiler: tracert

C:\Users\user\Desktop\curl>tracert computerbase.de

Tracing route to computerbase.de [2a02:cbf3:210::a2]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [2a01:c22:7a21:xxxx:xxxx:xxxx:fe6d:eb1c]
  2     9 ms     9 ms     8 ms  2a02:3001::135
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6    24 ms    24 ms    24 ms  2a02:3001::164
  7    24 ms    23 ms    23 ms  2a02:3001::15
  8    25 ms    25 ms    26 ms  xe-0-1-3.cr1.ham1.plusserver.com [2001:7f8:8:10:0:eee5:0:1]
  9    24 ms    24 ms    24 ms  2a02:cbf2:0:29::2
10    24 ms    23 ms    24 ms  2a02:cbf2:0:2b::2
11    27 ms    28 ms    28 ms  ae8.cr2.dus6.plusserver.com [2a02:cbf2:0:11::1]
12    28 ms    28 ms    28 ms  ae3.cr2.cgn3.plusserver.com [2a02:cbf3:0:5::1]
13    31 ms    31 ms    31 ms  www.computerbase.de [2a02:cbf3:210::a2]

Spoiler: ping

C:\Users\user\Desktop\curl>ping computerbase.de

Pinging computerbase.de [2a02:cbf3:210::a2] with 32 bytes of data:
Reply from 2a02:cbf3:210::a2: time=31ms
Reply from 2a02:cbf3:210::a2: time=31ms
Reply from 2a02:cbf3:210::a2: time=31ms
Reply from 2a02:cbf3:210::a2: time=30ms

Ping statistics for 2a02:cbf3:210::a2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 30ms, Maximum = 31ms, Average = 30ms

Spoiler: curl

C:\Users\user\Desktop\curl>curl.exe -v computerbase.de
*   Trying 2a02:cbf3:210::a2:80...
* Connected to computerbase.de (2a02:cbf3:210::a2) port 80 (#0)
> GET / HTTP/1.1
> Host: computerbase.de
> User-Agent: curl/7.73.0
> Accept: */*
>
...
Rest vom HTTP Packet

Mit Wireshark hab ich auch noch etwas rumgespielt, der spuckt beim Aufbau der Verbindung aufällig viele Retransmissions und fehlende ACK Pakete aus, beispielsweise während des TSL-Handshakes.

PS: Immerhin youtube & computerbase und wenige andere Websites sind via IPV6 erreichbar, echt unglaublich wie man dann erstmal feststellt, dass der IPv6 Support immer noch so spärlich ist. Wir haben bald 2021.

Witzig ist auch, dass die Hilfe-Seite von O2 (hilfe.o2online.de) via IPv6 erreichbar ist, der Login (via. login.o2online.de) und die restlichen Subdomains samt der Hauptdomain o2online.de aber nicht.

 

[GTrash81]

Vielleicht ist deren IPv4-Gateway kaputt?
Oder vielleicht routet o2 falsch?
Für diese Analyse müsste man es aber mal schaffen über den Level 1 Support hinauszukommen, was je nach Laune des Callcenters schwierig sein kann.

 

[mokabo]

Keine Ahnung, auf welchem Support-Level ich bereits war, denke aber Level 1 war das nicht mehr.
Der letzte, den ich an der Leitung hatte, war dann - nachdem ich schilderte extra eine neue Fritzbox gekauft zu haben - immerhin so nett ein Störungsticket zu erzwingen. Das geht angeblich eigentlich nicht bei Fremdhardware.

Ende vom Lied war dann lediglich eine SMS am nächsten Tag:
"Lieber Kunde!. Es konnte keine Störung ihres Anschlusses festgestellt werden. Bitte prüfen Sie Ihr Endgerät", Ticket geschlossen

Und ja, soweit ich das von hier beurteilen kann, ist das Bild für mich, dass via IPv4 keine TCP Verbindung aufgebaut werden kann. TCP ACK Messages gehen verloren, ständige Retransmissions, keine Ahnung... tracert(ICMP) und ping(ICMP) zum Endpunkt funktionieren ja.

wireshark während curl zu superuser.com läuft

 

[brainDotExe]

Vielleicht ist deren IPv4-Gateway kaputt?
Oder vielleicht routet o2 falsch?

Dann würde weder ein Ping durch kommen noch tracert funktionieren.

Es scheinen nur TCP Verbindungen betroffen zu sein.
Das könnte ein Problem mit der MTU sein.

Edit: Die MSS von 1464 von deinem Wireshark Screenshot ergibt eine MTU von 1504 (+20 Byte IPv4 Header + 20 Byte TCP Header), das ist eigentlich zu viel für einen typischen DSL Anschluss mit PPPoE (1492).
Andererseits sollte das bei IPv4 automatisch runtergeregelt werden.

Prüfe Mal die maximale MTU deines Anschlusses mit einem IPv4 Ziel.
https://kb.netgear.com/de/31507/Fes...outer-mithilfe-eines-Ping-Tests-1479991120725

 

[mokabo]

Danke für den Inpu, MTU kann ich laut kurzer Recherche bei der Fritzbox ehh nicht manuell setzen, oder?
Müsste ich dann den TP Link nochmal hochfahren, iirc lässt sich das dort einstellen.

Aber keine Ahnung, ehrlich gesagt glaube ich mittlerweile immer weniger, dass ich das von meiner Seite aus lösen kann.
2 verschiedene Modemrouter und 3 Endgeräte, bis letzten Donnerstag war alles okay. Rechnerkommunikations-Vorlesung an der Uni ist zwar ein paar Jahre her, dennoch hätte ich das aber denke ich mittlerweile gelöst, wenn es ein triviales Problem auf meiner Seite wäre

Dachte nur ich steh irgendwo komplett auf dem Schlauch und frage erstmal hier um Rat, bevor ich mich gezwungenermaßen erneut in die O2 Service Hölle wage.

Edit: Danke, I'll try, die Anleitung ist für mich aber schon mal wieder nicht erreichbar, hehe
Muss ich erstmal auf Mobiles Internet wechseln

 

[Salamimander]

Also das ist mal ein cooles Problem

Hast du eventuell eine Linux VM am start? Ich will nur software ausschließen. Für mich wirkt das wie ein Portbasiertes Problem.

Funktioniert folgendes:
www.asnt.org:8080/Test.html? (http only)

 

[brainDotExe]

Ich könnte mir es so erklären, dass dem Router bei der PPPoE Einwahl eine falsche/zu hohe MTU mitgeteilt wird.
Daher mein Vorschlag zu prüfen, welche MTU tatsächlich maximal durch geht.

 

[chrigu]

Nur so als sicherheit... kein Dlan/powerline in der Wohnung?

 

[mokabo]

Spoiler: Fritzbox 7530 MTU Test

Pinging superuser.com [151.101.1.69] with 1465 bytes of data:
Packet needs to be fragmented but DF set.

C:\Users\user\Desktop\curl>ping superuser.com -f -l 1464

Pinging superuser.com [151.101.1.69] with 1464 bytes of data:
Control-C

Bin nun wieder mit dem TP-Link 'online'.
Der steht nach Factory-Reset und initialem O2(über Telekom) Setup auf MTU 1480

Spoiler: Archer vr600v MTU Test

C:\Users\user\Desktop\curl>ping superuser.com -f -l 1453

Pinging superuser.com [151.101.65.69] with 1453 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 151.101.65.69:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\user\Desktop\curl>ping superuser.com -f -l 1452

Pinging superuser.com [151.101.65.69] with 1452 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 151.101.65.69:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\user\Desktop\curl>ping superuser.com -f -l 1451

Pinging superuser.com [151.101.65.69] with 1451 bytes of data:
Reply from 151.101.65.69: bytes=1451 time=20ms TTL=56
Reply from 151.101.65.69: bytes=1451 time=20ms TTL=56
Reply from 151.101.65.69: bytes=1451 time=20ms TTL=56
Reply from 151.101.65.69: bytes=1451 time=20ms TTL=56

Ping statistics for 151.101.65.69:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 20ms, Maximum = 20ms, Average = 20ms

Bei 1452 bytes meckert er nicht mehr, dass das Packet fragmentiert werden muss, gibt aber Timeout.
Bei 1451 bytes läufts durch.

Ich hab den Wert nun mal testweise im Router auf 1479 gesetzt.

Spoiler: curl.exe -v superuser.com

C:\Users\user\Desktop\curl>curl.exe -v superuser.com
*   Trying 151.101.1.69:80...
* Connected to superuser.com (151.101.1.69) port 80 (#0)
> GET / HTTP/1.1
> Host: superuser.com
> User-Agent: curl/7.73.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< cache-control: no-cache, no-store, must-revalidate
< location: https://superuser.com/
< server: Microsoft-IIS/10.0
< x-flags: AA
< x-aspnet-duration-ms: 0
< x-request-guid: eb1bf30f-ed2b-4260-ab30-4862b7c1e855
< x-is-crawler: 1
< x-providence-cookie: 10609f70-52fc-3e9b-4f80-4b18fe9c16ad
< content-security-policy: upgrade-insecure-requests; frame-ancestors 'self' https://stackexchange.com
< content-security-policy-report-only: default-src https: wss: data: blob: 'unsafe-eval' 'unsafe-inline'; frame-ancestors 'self'; report-uri /_/csp-reports
< Transfer-Encoding: chunked
< Accept-Ranges: bytes
< Date: Mon, 02 Nov 2020 21:41:20 GMT
< Via: 1.1 varnish
< Connection: keep-alive
< X-Served-By: cache-fra19175-FRA
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1604353281.677391,VS0,VE183
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=10609f70-52fc-3e9b-4f80-4b18fe9c16ad; domain=.superuser.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
<
* Connection #0 to host superuser.com left intact

Voila, auf Port 80 bekomm ich Antwort.

Spoiler: curl.exe -v https://superuser.com

C:\Users\user\Desktop\curl>curl.exe -v https://superuser.com
*   Trying 151.101.1.69:443...
* Connected to superuser.com (151.101.1.69) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: C:\Users\user\Desktop\curl\curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection was reset in connection to superuser.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection was reset in connection to superuser.com:443

HTTPS failed

@chrigu nope
@Salamimander Der Aufruf geht aktuell via curl durch, Microsoft Edge ebenso, Chrome lädt sich tot

EDIT: Denke nicht, dass es am MTU-Wert liegt, wenn ich den auf 1480(default) zurücksetze ist die Problematik aktuell unverändert.
Die Verbindung via HTTP-IPv4 geht nun, HTTPS produziert wieder obige Fehler, die ich vor paar Tagen schon feststellte.

 

[Salamimander]

Provider Problem. Sorry aber sag den Hotlineaffen es liegt nicht an der Leitung sondern an deren PPPoE Server ... Des weiteren 14 Tage Frist setzten (Schriftlich) und wenn die Störung als "geloest" markiert wurde, wiedersprechen.

 

[Wilhelm14]

Ohne das Problem zu sehen, fällt mir als Laie auf, dass du zwar die Router zurückgesetzt hast, aber dennoch bei ipconfig 8..8.8.8 usw. als DNS ausgespuckt wird. Nur als Idee, dass da doch nicht alles auf default läuft. Und eine zu große MTU sollte "eigentlich nur" fragmentieren, also ungünstig laufen, aber nicht komplett ins Leere.

 

[mokabo]

Korrekt, hatte ich verändert, machte aber keinen Unterschied.

Gerade war für 10 Minuten kein PPPoE Aufbau möglich und zack, auf einmal alles wieder normal wie vor einer Woche. Aber klar O2, mit meiner Leitung war alles in Ordnung...

Danke an alle, die versucht haben zu helfen!

 

[chrigu]

MTU hat nur mit der grösse der datenpakete zu tun, nicht mit Unterbrechungen.
Mein Tipp: bei o2 künden und einen anderen Provider suchen. Du zahlst schliesslich für Unterbrechungsfreies Internet, nicht aber für diesen Murks