Solved

IPv6 TCP timeouts

2 years ago

Guten Morgen liebe Telekomhilfe-Community,

 

seit gestern bin ich im Festnetz der Telekom angebunden. IPv4; Einwahl über PPPoE / VLAN 7 hat wunderbar funktioniert. Nun hänge ich ein wenig an der IPv6 Thematik.

 

Das RA bekomme ich sauber mit einem 56 Prefix. Die Unterteilung in ::64 Netze klappt wunderbar und auch mein DHCPv6 verteilt die Adressen. Mit den Endgeräten kann ich sauber ipv6.google.com anpingen. Was leider überhaupt nicht funktioniert sind TCP Verbindungen, diese timeouten.

 

MTU habe ich unter Berücksichtigung vom 60bytes IPv6 Header, 8 bytes PPPoE Header und ein wenig Buffer auf 1400 gesetzt.

TCP MSS ist auf 1300 gesetzt.

 

PINGs mit Payload bis 1250B sind kein Problem.

 

Firewall ist entsprechend konfiguriert ICMP rein und rauszulassen, sowie HTTP/HTTPS ausgehend zuzulassen. NAT wird entsprechend nicht genutzt, da die Geräte dank genug Adressen mit IPv6 direkt im Netz hängen.

 

Hat jemand eine ähnliche Problematik und eine Idee?

Danke!

 

1006

12

    • 2 years ago

      guten Morgen @bternes 
      Was meinst Du mit: Was leider überhaupt nicht funktioniert sind TCP Verbindungen, diese timeouten.

      Rein oder raus ??
      Wie testet Du ?

      Kannst Du WebSeiten per ipv6 only öffnen ?

      Wenn ja, dann funktioniert TCP.

       

      Rein geht nicht, da diese per default vom Router geblockt werden.
      Ist eine Security Feature.
      Diese mußt du einzeln frei schalten.

      1

      Answer

      from

      2 years ago

      @WerWeißWas  Guten Morgen

       

      danke für die schnelle Rückmeldung. Ich möchte vom Endgerät eine TCP Verbindung initieren. Ich versuche beispielsweise mit curl ipv6.google.com zu laden, welches ausschließlich über IPv6 erreichbar ist. Timeout bedeutet ich sehe im Wireshark einen haufen TCP Retransmissions und irgendwann hat die Anwendung, in diesem Fall curl keine Lust mehr und bricht ab.

       

      Rein möchte ich ja auch nicht Fröhlich

      Unlogged in user

      Answer

      from

    • 2 years ago

      Was für einen Router setzt denn ein?

      8

      Answer

      from

      2 years ago

      Ich bin mittlerweile in der Thematik ein wenig weiter. Es ist wohl doch kein Routing Problem. IPv6 scheint ein wenig anders zu funktionieren als ich es von IPv4 kenne. Über ND erhält mein Netzwerk-Gerät die MAC-Adresse der Fortigate, dorthin werden die Pakete übergeben. Die Fortigate übergibt das Paket an das über RA adversierte Gateway. Danach verschwindet es aus meiner Sicht. Antworten bleiben aus.

       

      Damit funktioniert im TCP kein Handshake. Ich sehe im Wireshark einen haufen TCP Retransmissions. TCP-MSS, MTU passen.

      UDP Pakete verhalten sich ein wenig anders, kommen UDP Pakete von außen rein, funktioniert es aussgehend für eine gewisse Zeit. Das hat beim IPSec das interessente verhalten, dass eine von der Gegenstelle initierte Verbindung in beide Richtungen funktioniert, bis kein Traffic mehr auf dem Tunnel ist, danach komme ich auch nicht über den Tunnel raus, er ist aufgebaut aber "IDLE". Die UDP Pakete um die Verbindung wieder aufzubauen kommen nicht an 😕

      Answer

      from

      2 years ago

      Irgendwas wurde wohl geändert, jetzt funktioniert es, ohne dass ich bei meiner Fortigate die Konfiguration geändert habe.

      Answer

      from

      2 years ago

      Ich habe die eigentliche Lösung gefunden ... es hat funktioniert als ich auf mein Büro mit direktem LAN Anschluss gewechselt bin. 

      Jetzt als ich per Zufall es nochmal übers WLAN versucht habe ist der Fehler wieder aufgetaucht. 

       

      Es ist einfach ein Bug in der Firmware der eingesetzten WLAN APs ... 

      https://community.tp-link.com/en/business/forum/topic/593488

      Unlogged in user

      Answer

      from

    • Accepted Solution

      accepted by

      2 years ago

      Ich habe die eigentliche Lösung gefunden ... es hat funktioniert als ich auf mein Büro mit direktem LAN Anschluss gewechselt bin. 

      Jetzt als ich per Zufall es nochmal übers WLAN versucht habe ist der Fehler wieder aufgetaucht. 

       

      Es ist einfach ein Bug in der Firmware der eingesetzten WLAN APs ... 

      https://community.tp-link.com/en/business/forum/topic/593488

      0

      Unlogged in user

      Ask

      from

      This could help you too

      Solved

      in  

      3678

      0

      5

      in  

      407

      0

      3

      in  

      25765

      0

      128

      Solved

      in  

      1303

      0

      2