abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

IPv6 6rd Problem

Contributor
1 von 12

Ich habe da ein Problem bei dem mir vielleicht hier jemand behilflich sein kann.

 

Ich versuche auf meinem Linux-Router 6rd zu konfigurieren.

Mein Setup:

  • Swisscom Internet Box Standard
  • Linux Router mit DMZ-Interface und LAN-Interface mit lokalem subnet

 

[DSL router 10.0.0.1] --{10.0.0.0/24} --> [Linux] --{10.0.1.0/24} --> (clients)

 

Jetzt möchte ich auf der Internet Box IPv6 deaktivieren und direkt einen 6rd Tunnel von meinem Linux Router her aufbauen. Dies hat vor ein paar Monaten noch funktioniet (damals mit Centro Piccolo).

 

Meine 6rd Konfiguration:

  • 6rd gateway: 6rd.swisscom.com (193.5.29.1)
  • 6rd prefix: 2a02:1200::/28

 

Die Konfiguration sieht dann unter Linux so aus:

  • ip tunnel add 6rd mode sit ttl 64 local 10.0.0.2
  • ip tunnel 6rd dev 6rd 6rd-prefix 2a02:1200::/28
  • ip link set 6rd up
  • ip -6 addr add 2a02:120x:xxxx:xxx0::1/64 dev 6rd
  • ip -6 addr add 2a02:120x:xxxx:xxx1::1/64 dev lan0
  • ip -6 route add 2000::/3 via ::193.5.29.1 dev 6rd

 

Das Problem ist nun, dass ich keine TCP Verbindungen aufbauen kann. ICMP Pakete funktionieren prima was auch ein tcpdump auf die Pakete zum Gateway zeigt:

 

17:05:03.937159 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx > 2a00:1450:400a:804::2004: ICMP6, echo request, seq 150, length 40
17:05:03.954431 IP 193.5.29.1 > 10.0.0.6: IP6 2a00:1450:400a:804::2004 > 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx: ICMP6, echo reply, seq 150, length 40

 

 

Für TCP Verbindungen sieht das (hier exemplarisch anhand ipv6.google.com) so aus:

 

17:11:57.826484 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63467 > 2a00:1450:400a:804::200e.80: Flags [P.], seq 2834115036:2834115790, ack 1358787893, win 255, length 754: HTTP: GET / HTTP/1.1
17:11:58.536448 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63467 > 2a00:1450:400a:804::200e.80: Flags [F.], seq 754, ack 1, win 255, length 0
17:11:58.542784 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63468 > 2a00:1450:400a:804::200e.80: Flags [S], seq 797766985, win 65320, options [mss 1420,nop,wscale 8,nop,nop,sackOK], length 0
17:11:58.553930 IP 193.5.29.1 > 178.195.x.y: IP6 2a00:1450:400a:804::200e.80 > 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63467: Flags [.], ack 0, win 213, options [nop,nop,sack 1 {754:755}], length 0
17:11:58.553996 IP 193.5.29.1 > 178.195.x.y: IP6 2a00:1450:400a:804::200e.80 > 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63467: Flags [.], ack 0, win 213, options [nop,nop,sack 1 {754:755}], length 0
17:11:58.561069 IP 193.5.29.1 > 10.0.0.6: IP6 2a00:1450:400a:804::200e.80 > 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63468: Flags [S.], seq 4008144593, ack 797766986, win 27200, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
17:11:58.561694 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63468 > 2a00:1450:400a:804::200e.80: Flags [.], ack 1, win 255, length 0
17:11:58.562293 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63468 > 2a00:1450:400a:804::200e.80: Flags [P.], seq 1:738, ack 1, win 255, length 737: HTTP: GET / HTTP/1.1
17:11:58.795341 IP 10.0.0.6 > 193.5.29.1: IP6 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63468 > 2a00:1450:400a:804::200e.80: Flags [P.], seq 1:738, ack 1, win 255, length 737: HTTP: GET / HTTP/1.1
17:11:58.861692 IP 193.5.29.1 > 10.0.0.6: IP6 2a00:1450:400a:804::200e.80 > 2a02:120x:xxxx:xxxx:xxxx:xxxx:xxx:xxxx.63468: Flags [S.], seq 4008144593, ack 797766986, win 27200, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0

 

 

 

Dabei ist 178.195.x.y meine Public IPv4 Adresse. Ich habe noch nicht ganz verstanden warum die ACK Pakete hier an die Public IPv4 Adresse geschickt werden und somit vom Linux Router wieder über den Default-Gateway zum Router geschickt werden anstatt an die interne IP 10.0.0.6 (die DMZ IP meines Linux Routers) geschickt zu werden. Mit anderen Paketen geht das wunderbar, aber mit den ACK Paketen scheint das nicht zu klappen.

 

 

Weiss hier jemand welche Fehlkonfiguration hier vorliegt?

 

 

11 Kommentare
Anonym
2 von 12

Das Verhalten sieht ganz nach einem Fehler in der NAT-Verarbeitung für das IP-Protokoll 41 in der Internet-Box aus. Mich erstaunt eher, dass dieses nicht komplett von der Internet-Box gefiltert wird.

Contributor
3 von 12

Ich bin mir da nicht ganz sicher. Immerhin werden die Pakete über den Tunnel bis zum IPv6 Endpunkt auf meinem (internen) Router geleitet. Ich sehe diese Pakete auf meinem internen Interface (nicht auf dem Interface zwischen Internet Box und meinem Linux Router). Daher gehe ich davon aus, dass die Pakete vom 6rd Gatewa falsch verpackt werden bzw. mit falscher Empfänger-IP über den Tunnel geschickt werden.

 

Damit kann ich mich aber auch täuschen. Vermutlich sollte die Ziel-IP von der Internetbox im Protokoll 41 Paket angepasst werden was bei ACK Paketen offenbar versagt.

 

Ich setze aktuell wegen des fehlenden statischen Routings in der Internet Box Standard Firmware 08.01.08 die Beta-Firmware 08.05.22 ein. Vorher hatte ich die vorherige Beta-Firmware (08.05.08?) drauf und das Problem bestand ebenfalls schon.

 

 

Auch eine IP Firewall Konfiguration fehlt dieser Firmware komplett. Genau so wie ein CLI. Auch Bridging fehlt (dann könnte man dieses Problem hier zumindest umschiffen). Für IPv6 (sofern man die Box selber dafür Verwendet) kann man die Firewall nur rudimentär konfigurieren. Wenn man Subnetze und Gateways konfigurieren könnte, dann könnte man IPv6 ja der Internet-Box überlassen. Was dann nur problematisch wäre weil der Präfix sich ändert sobald die IPv4 Adresse am 6rd sich ändert und somit die interne Konfiguration jedesmal angepasst werden müsste. Daher würde ich den 6rd Tunnel lieber direkt auf meinem LAN-Gateway terminieren und ich denke es geht vielen so die hinter der Internet-Box noch einen eigenen Router oder Firewall betreiben wollen/müssen.

 

Leider hab' ich nur die Internet-Box standard. Ich würde den Test ja mit gerne einer Internet-Box 2 oder sonst einem funktionierenden Router machen aber leider steht mir keiner zur Verfügung.

Anonym
4 von 12

@SkyBeam schrieb:

Damit kann ich mich aber auch täuschen. Vermutlich sollte die Ziel-IP von der Internetbox im Protokoll 41 Paket angepasst werden was bei ACK Paketen offenbar versagt.

 


Die Internet-Box müsste genau das machen und die Ziel-IP auf das lokale Netz umbiegen.

Dieser Fehler ruiniert sämtliche Versuche, IPv6 anderweitig zu tunneln.

 

Ich hoffe doch nicht, dass solche Schnitzer absichtlich geschehen...

 

P.S. Die anderen Internet-Boxen werden sich vermutlich genau gleich verhalten, da scheinbar überall die gleiche Software läuft. Bis auf die IB-Light, welche überhaupt kein IPv6 kann und die Centro Business Serie.

Contributor
5 von 12
6rd hat bei mir aber definitiv einmal funktioniert mit dem Centro Piccolo. Mir wurde dann aber die IB Standard zugeschickt mit der Bitte diese auch in Betrieb zu nehmen. Seit da hab' ich also keinen konfigurierbaren IPv4 Paketfilter, keine statischen Routen, kein funktionierendes IPv6, kein CLI und einen erhöhten Stromverbrauch. Aber immerhin kann ich die Status-LED jetzt deaktivieren was den Keller jetzt viel wohnlicher macht :).
Anonym
6 von 12

@SkyBeam schrieb:
6rd hat bei mir aber definitiv einmal funktioniert mit dem Centro Piccolo.

Leider haben die Centro Piccolo eine völlig andere Firmware als die Internet-Boxen.

 

Für mich war der erste Kontakt mit einer Internet-Box ein richtiger Schock, weil ich davon ausgegangen bin, dass diese nicht weniger können, sondern mehr. Die Centro Piccolo liessen sich noch wunderbar per Telnet konfigurieren. Inklusive Abschalten des von mehr sehr gehassten TR-069 Remote Management.

 

Wer weiss, vielleicht gibt es die Fritz!Box 7590 auch einmal für den Schweizer Markt. Die aktuelle Fritz!Box ist schon etwas in die Jahre gekommen.

Super User
7 von 12
Denkfehler ist eben das der Router in den Keller muss. Der gehört ins Wohnzimmer 😂

Falls du in deinem Thread eine Antwort von Tux0ne wünschst, so ergänze deinen Text mit @Tux0ne. Damit erhalte ich eine Benachrichtigung.

Selbstdeklaration


Swisscom spezifische Kenntnisse in Sales/Tech:

inOne/inOne KMU > In allen Rollen sowie own Gateway, own SIP Device

Smart Business Connect: Business Internet Services > CB2 Router Konfig in allen Rollen, Business Communication Services > Hosted, Trunk direct, UCC

BNS Business Network Solutions: Managed LAN > Switches, Access Points. Managed Security > Antivirus, Webfilter. RAS, PWLAN, DCS Anbindung

Generell: L1-L7, Firewall, DMZ, VPN Client/Site-Site, 802.1x, SIP, ISDN, Mivoice400, DNS, Dual Stack uvm. wie zB. Fachkundigkeit nach NIV.
Contributor
8 von 12
OK, dann verschiebe ich den mal ins Wohnzimmer. Und wehe so Basisfunktionen wie statisches Routing und 6rd gehen dann immer noch nicht! 🙂
Contributor
9 von 12

Aktuell ist bei mir die Firmware 08.95.50/01144 installiert und das Problem besteht immer noch. Kann das jemand bestätigen oder gibt es gar Infos ob und wann IPv6 endlich auch mit der IBS funktionieren wird?

Super User
10 von 12

@MichelB kannst Du mal dazu was sagen ?

Knowledge: Netzwerk Allgemein | Telekomunikation | Betriebssysteme| sonstiges
# Wenn ich geholfen habe, könnt ihr mir danken in dem ihr auf den Like klickt #
Contributor
11 von 12

Inzwischen ist an meiner IBS die Firmware 08.08.28/01177 installiert und das Problem besteht immer noch. Kein IPv6 an meinem internen Router möglich. 😞

Contributor
12 von 12

Um das Problem ggf. weiter einzukreisen habe ich heute nochmals Tests gemacht. Auf der IBS sehe ich immer noch das gleiche Phänomen:

19:06:49.419563 IP 193.5.29.1 > 188.62.214.248: IP6 2a00:1450:400a:806::200e.80 > 2a02:120b:c3ed:6f81::1.42130: Flags [.], ack 1, win 106, options [nop,nop,TS val 837353318 ecr 1842392641,nop,nop,sack 1 {7:8}], length 0

Dies ist ein Antwort-Paket welches über den 6rd Tunnel ankommt.

Meiner Meinung nach sollte die Zieladresse hier die interne Adresse des Routers sein. Ich habe diese inzwischen auf 192.168.1.3 geändert weil ich schon vermutet hatte, dass meine 10.0.0.6 (IBS auf 10.0.0.1) hier Probleme machen könnte. Aber auch mit der IBS auf 192.168.1.1 und der Router auf 192.168.1.3 sehe ich das gleiche Problem.

Ausserdem habe ich versucht nochmals ein Centro Piccolo anzuschliessen. Leider ohne Erfolg der Line-Sync hat zwar funktioniert und auch eine öffentliche IP hat mein Centro bekommen aber weder Telefonie noch IP forwarding hat funktioniert. Ich wollte noch die Firmware aktualisieren aber auf der Download-Seite steht nur noch, dass das Gerät veraltet ist und man sich ein neues bestellen soll.

Na toll, wenn denn eines davon funktionieren würde. Das nehme ich gerne.

Bin ich der einzige mit dem Problem?
Funktioniert eventuell IB2 richtig?
Liegt das Problem an einer falschen Konfiguration meinerseits?

Vielleicht bin ich ja wirklich auf dem Holzweg und das Problem liegt irgendwo bei mir aber es scheint nur TCP Traffic zu betreffen denn ICMP-Pakete werden tadellos geroutet.

 

Ach ja, inzwischen hat meine IBS die Firmware 09.00.42/01238.