[Gelöst] VPN Tunel zwischen Fritzbox 7490 und iPhone (iOS9) funktioniert nicht mehr

Zuletzt bearbeitet:
Ich auch nicht. Welche nimmst du?

Bei mir geht es nicht. Ich glaube, ich bin derjenige, der das imore.com Thematik hervorgerufen habe. Ich benutze Google DNS 8.8.8.8 und 8.8.4.4.

Zum Thema VPN: Ich habe mithilfe eines Sniffers auf beide Seiten den VPN Verkehr mitgesnifft für iOS 8 und iOS 9 durch das UM Netz. Klare Auffälligkeiten sehe ich eigentlich nicht, leider.

Im Layer 3 Bereich wird alles natürlich sauber geroutet. Anzahl gesendete Pakete = Anzahl empfangene Pakete.

Layer 4-Mäßig musste ich feststellen, dass iOS 9 ein höheren Source-Port gewählt hat (Port 64916) als iOS 8 (Port 33208). Destination ist in beide Fällen 4500 für NAT-T, nat-türlich. Die Pakete kommen aber komplett durch, also es gibt kein ACL oder filtering drauf. (deny udp source 64000-65535 z.B.) Es könnte hier vielleicht ein miskonfigurierten QoS Policy greifen, aber was soll der Policy denn falsch gemacht haben? Die ESP Pakete (Nach Verbindungsaufbau werden ESP Pakete geschickt, um das Payload zu transportieren) haben die gleiche größen und SPI und die Daten sind gleich. Die kommen auch nicht out-of-order an... Nur die DSCP Werte im L3-header werden geändert, aber das passiert auch mit iOS 8 (von 0x00 auf 0x03, Explicit Congestion Notification, Congestion Experienced. Bin hier leider nicht der Experte, aber ich nehme an, dass die Pakete einfach in einem Router irgendwo auf dem Weg kurz gebuffert worden sind). Einziger Unterschied ist: iOS8 schickte direkt 5-7 ESP Pakete, iOS9 nur 3. Ob das was ist, weiß ich nicht.

Auf dem Application-Layer sehen die ESP Pakete an beide Enden Payload-mäßig gleich aus

Tja, ansonsten kann ich hier im ersten Blick nichts sehen, bzw ich kann hier kein groben Fehler feststellen. Wer interesse dran hat, stelle ich die .pcap Dateien gerne zur Verfügung.
 
Die Level 3 DNS. Eine IP muss ich Dir jedoch gerade schuldig bleiben.

Interessant. Mit den DNS-Servern von denen geht es auch bei mir einwandfrei. (209.244.0.3 und 4.2.2.1 probiert).

Nachtrag:

Ich habe noch etwas herumprobiert und kann jetzt folgendes berichten.

Google DNS mit UM -> imore.com nicht erreichbar
Google DNS über O2-Hotspot -> imore.com erreichbar!
Level3 DNS über UM -> imore.com erreichbar
Level3 DSN über O2-Hotspot -> imore.com erreichbar

Das "fühlt" sich von der Symptomatik her ähnlich an wie das VPN-Problem. Ob da wohl ein Zusammenhang bestehen könnte?
 
Zuletzt bearbeitet:
An einem Unitymedia Business gibt imore.com einen Timeout.
Traceroute zeigt plötzlich 100 ms mehr im NTT-Netzwerk.

Und ich kenn' jemanden mit iOS9 der nicht VPN an einen (anderen) UM-Anschluss machen kann.
 
Auf dem Application-Layer sehen die ESP Pakete an beide Enden Payload-mäßig gleich aus

Hmm, ich verstehe deine Ausführungen ja nicht, weil ich zu wenig Ahnung habe, aber was mich irritiert: Verstehe ich es richtig, dass hinter dem UM-Anschluss Daten ankommen? Und auch wieder Daten zurück ans iDevice gehen? Also Daten werden mengenmäßig bei iOS8 und iOS9 gleichermaßen transportiert?

Für mich sah es so aus, als ob Daten verloren gehen. Wenn die aber ankommen, dann können die ja nur entweder innen drin vom Sender falsch gesendet und/oder der Empfänger falsch interpretiert werden. Oder?
 
Habe UM auch soeben angeschrieben. Bleibt spannend...
 
Seit heute gibt es iOS 9.0.1 . Vielleicht bringt die Version bei euch ja Besserung.
 
Danke für den Hinweis, gerade installiert und gehofft - aber leider keine Veränderung...
 
Hmm, ich verstehe deine Ausführungen ja nicht, weil ich zu wenig Ahnung habe, aber was mich irritiert: Verstehe ich es richtig, dass hinter dem UM-Anschluss Daten ankommen? Und auch wieder Daten zurück ans iDevice gehen? Also Daten werden mengenmäßig bei iOS8 und iOS9 gleichermaßen transportiert?

Für mich sah es so aus, als ob Daten verloren gehen. Wenn die aber ankommen, dann können die ja nur entweder innen drin vom Sender falsch gesendet und/oder der Empfänger falsch interpretiert werden. Oder?

Also: ich habe auf der Arbeit einen packet sniffer an unser WLAN eingeschaltet und das gleiche bei mir zuhause gemacht. Dann habe ich die Verbindung aufgebaut und versucht was abzurufen. Es hat nicht funktioniert, aber die Pakete, die meine Firewall zuhause losschickte kamen alle bei mir auf der Arbeit (und weit weg vom UM Netz) an. Ich konnte keine Veränderungen in den Paketen feststellen. Total skurril. Das einzige was sich geändert hat, war das DSCP Feld im IP Header. Ist zwar eher nur für routing-Zwecke da, aber vielleicht kommt iOS 9 mit dem 0x03 DSCP flag klar?

DSCP bedeutet DiffServ Code Point und wird zwecks Quality of Service benutzt, um Informationen über Priorität/Inhalt und so an den Routern zu übermitteln.
 
Das ist wirklich sehr ominös. Danke für die Erklärung.

Gerade einen Rückruf von UM bekommen. Man sieht - wie fast zu befürchten war - das Problem und dessen Behebung bei Apple. Das Thema mit imore.com und den DNS-Servern hat man weitergegeben, weil es (zum Glück) sogar mit dem Google-DNS reproduzierbar ist. Ich hoffe immer noch, dass beide Probleme auf derselben Ursache beruhen könnte.
 
Mit iOS9.0.1 wurde natürlich auch nix gefixt. Ich bin gespannt, ob das dieses Jahr noch etwas wird. Sonst muss man sich ja fast überlegen, für die Hälfte des Preises das Lager zu wechseln - die haben ja auch sowas mit "S" und "6" :p
 
Das wird wohl noch dauern wenn selbst in 9.1 noch nicht behoben ist laut News, wenns selbe Problem ist.
 
Wäre ja schon eine tolle Geste wenn die das während der Entwicklung von iOS9.1 noch hinbekommen. Leider hab ich keinen Dev-Account, sonst könnte ich jetzt die 9.1b2 mal testen. Mein public-beta bietet mir die zweite beta noch nicht an
 
Du hast jedoch das Feedback App wo du Fehler melden kannst. Dort habe ich auch einen Fehler gemeldet für eine App und nach wenigen Tagen gab es ein Update ohne dass ich eine Rückmeldung bekommen habe wo es gefixt wurde.
 
Hallo zusammen,

wie ich früher berichtet habe, konnte ich nur ein kleinen Unterschied erkennen in die Pakete, die von meinem Anschluss zu Hause aus geflossen sind, und die, die angekommen sind, und zwar war das ECN (Explicit Congestion Notification) Feld gesetzt. Das Feld wird auf 0x03 (in Binär 11) gesetzt. Ich glaube jetzt, dass das Problem daran liegt.

Ich wollte versuchen, auf meiner Firewall hier auf der Arbeit, das Feld zurückzusetzen, bisher kein Erfolg. Ich kann mit der Firewall nur das DSCP Feld manipulieren. Ich hab ein Kollege gefragt, ob es möglich ist, die Wert auf dem Router davor zu manipulieren. Er schaut nach.

Fakt ist, aber, dass Apple in iOS 9 ECN neulich aktiviert hat: (https://en.wikipedia.org/wiki/Explicit_Congestion_Notification)
"In June 2015, Apple Inc. announced that it will enable ECN signalling by default on its hundreds of millions of deployed products..."

Das heißt, es gibt ganz klar ein Unterschied zwischen iOS 8 und iOS 9: ECN. Und die ECN wert wird (vermutlich) vom Unitymedia auf 0x03 gesetzt. Ich glaube, es gibt hier ein Problem mit der Implementierung von ECN im iOS 9 Network Stack in Verbindung mit VPN. Das bestätigt meine bisherige Erfahrungen mit dem Problem: Das iPhone schickt Pakete durch den Tunnel, sie werden beantwortet und wieder im Tunnel reingeschickt zum iPhone, aber das iPhone macht irgendwie nichts damit. Ich glaube, etwas passiert wenn die Pakete durch den Stack durchfließen. Vielleicht stören diese zwei bits so dass das VPN Modul sie einfach als ungültig betrachtet und wegwirft?

Ich habe Apple schon darüber informiert. Mal sehen ob sie sich bewegen.
 
Sehr interessanter Beitrag, vor allem auch der verlinkte Artikel - vielen Dank. Ich glaube, dass du der Sache auf der Spur bist.
 
Du glaubst also ernsthaft, dass Apple auf deine Information hin diese kürzlich eingeführte Änderung in ihren "Hunderten von Millionen-fach eingesetzten Produkten" wieder zurücknimmt, weil es im Netz von unitymedia zu Verstopfungen kommt? :confused:
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.