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

[amatör]

Ok, einigen wir uns darauf, dass mit "Client" der initiierende und mit "Server" der anderer Endpoint gemeint sind. Ich dachten das sei so die übliche Bezeichnung.

Biker73 hat in #29 auch schon berichtet, dass weder Fritzbox IPSec VPN noch OpenVPN (ohne Angabe ob TCP oder UDP - nehme letzteres mal an) am UM-Anschluss funktionieren. Also ist das Problem nicht auf das iOS 9 IPSec beschränkt. Meines Wissens wird eine OpenVPN-Verbindung ja von einem eigenen Nicht-Apple-Client aufgebaut. Somit müsste sich dort derselbe Implementierungsfehler befinden, wenn es ein solcher wäre, was ich für relativ unwahrscheinlich (wenn auch nicht unmöglich) halte. Natürlich kann es sein, dass sich der Fehler so tief im Stack befindet (UDP?), dass er sich auf jede darauf aufbauende Implementierung auswirkt, was dann doch ursächlich Apples Problem wäre.

Ich kann mir aber nicht vorstellen, dass es bei allen anderen Providern nur deswegen funktioniert, weil sie kein ECN einsetzen. Naheliegender ist doch die Vermutung, dass ECN bei UM nicht korrekt eingesetzt wird.

 

[PeterPawn]

Das artet am Ende doch wieder in die (unnütze) Diskussion aus, ob das "Verhalten" von UM sinnvoll ist oder nicht ... es ist ganz klar nicht wirklich sinnvoll und hilfreich, aber auch nicht wirklich "verboten" (und Du kannst ohnehin nicht kontrollieren, ob im UM-Netz nun "Stau" ist oder nicht). Wenn diese Situation wegen tatsächlichem Stau irgendwann mal berechtigterweise auftreten sollte, müßte das Apple-OS damit ebenfalls richtig umgehen können (wozu hat man es sonst implementiert, wenn man nicht will, daß es genutzt wird), auch ein - dann nur temporäres - Problem mit dem VPN in diesem Falle ist ja nicht Sinn der Sache.

Der entscheidende Punkt ist doch, ob bei Biker73 nun das "OpenVPN Connect" für iOS im Spiel war oder nicht - bei "nicht" wäre es nur noch merkwürdiger. Andere Betriebssystem und/oder IPSec-Implementierungen kommen ja auch mit UM-Anschlüssen klar (das originale AVM-VPN kennt gar nichts anderes als IPSec mit IKEv1 und da ist immer UDP im Spiel, zumindest in der IKE-Phase, bei NAT-T ständig) ... da beißt die Maus ja keinen Faden ab, daß es ohne eines der neuen Apple-OS das Problem auch nicht wirklich gibt.

Zumindest nicht in der Form nicht funktionierender VPN-Verbindungen, das Tagging der Pakete findet ja trotzdem (schon seit Jahren) statt, das macht UM ja nicht nur dann, wenn sie feststellen, daß da an einem Ende ein Apple-OS lauert.

PS: Auf die Definition von "Client" und "Server" können wir uns gerne einigen, hatte ich ja auch schon so vorgeschlagen ... mir ging es weniger um die Begrifflichkeiten als vielmehr um die Feststellung, daß es für den resultierenden Datenverkehr (und nur den "sieht" UM und kann ihn beeinflussen) am Ende egal ist ... da UDP auch - anders als TCP - keine echte "Verbindung" kennt, die man von außen erkennen könnte (beim TCP ist eben derjenige mit dem ersten SYN-Paket der Anfragende, das gibt es bei UDP schlicht nicht), kann da keiner feststellen, wer der "Client" und wer der "Server" ist.

 

[ElvQuant]

gerade eben getestet unter OS X 10.11.1, keine Veränderung !
allerdings funktioniert weiterhin der Befehl "sudo sysctl -w net.inet.ipsec.ecn=2" als vorübergehende Lösung.
Im komme damit im Moment ganz gut klar mit aber leider halt nicht für iOS.

Danke mir hat das Update mein System zerbröselt. Gut, dass es nur ein Clone meines produktiven Systems war.
für iOS nur mit JB, wobei ich nicht weiß, ob der für 9.0.x von Pangu auch für 9.1 geht. Aber TaiG soll für 9.1 einen bringen. http://www.ip-phone-forum.de/showthread.php?t=281439&page=15&p=2123143&viewfull=1#post2123143

 

[Tomacco81]

Hallo zusammen,

ich verfolge den Thread nun auch schon einige Tage, da ich leider ebenfalls von dem Problem betroffen bin.

Zuhause habe ich folgende Konstellation:
- FB 6340 Cable
- FB 7490 als exposed host an der FB 6340
- Synology DiskStation DS213+ als OpenVPN-Server an der FB 7490

Folgende Szenarien wurden getestet:
- IPSec VPN von iOS < Version 9 zu FB6340: funktioniert
- IPSec VPN von iOS < Version 9 zu FB7490: funktioniert
- IPSec VPN von iOS >= Version 9.0.2 zu FB6340: funktioniert nicht
- IPSec VPN von iOS >= Version 9.0.2 zu FB7490: funktioniert nicht
- OpenVPN (UDP) von iOS >= Version 9.0.2 zu DS213+: funktioniert
- OpenVPN (TCP) von iOS >= Version 9.0.2 zu DS213+: funktioniert

Wenn ich es richtig verstanden habe, sollte das Problem ebenfalls mit der UDP OpenVPN-Verbindung auftreten - dies funktioniert bei mir aber problemlos. Das Problem, dass ich keine Daten durch den Tunnel schicken kann habe ich nur mit der IPSec-Verbindung zu den Fritzboxen.

Grüße Tomacco

 

[PeterPawn]

@Tomacco81:
Danke für diese Feststellung. Dann war das bei der vorhergehenden Meldung also genauso ein temporäres (oder anders gelagertes) Problem wie bei den zwischenzeitlich ja auch angemerkten Problemen mit der Namensauflösung (auch das wäre ja UDP gewesen) und der Annahme, da gäbe es ebenfalls einen direkten Zusammenhang (irgendwo hier am Beginn des Threads), was sich ja auch kurze Zeit später als "erledigt" herausstellte.

Dann darf man wohl annehmen, daß es sich tatsächlich auf die IPSec-Implementierung von Apple konzentriert bzw. reduzieren läßt, der Variablename beim gefundenen Workaround legt das ja irgendwie auch nahe.

Ich hatte mich auch nur erneut eingemischt (bin ja nicht betroffen), weil aus der Antwort von UM in #327, daß andere VPN nicht betroffen sind, dann irgendwann der Bogen zu der einen Fehlermeldung für OpenVPN-Verbindungen erneut geschlagen wurde (das nachträgliche EDIT von amatör in #331 hatte ich noch gar nicht gesehen, erst jetzt bei der Suche nach der Nummer des Beitrags) und das dann noch irgendwie in eine Unterscheidung, wer da nun Client und wer Server ist, mündete - verbunden mit der These, daß nur VPN-Server an UM-Anschlüssen betroffen wären.

Gerade solche "Verknüpfungen" leisten aber - wenn man die Probleme nicht sauber voneinander trennt bzw. das nicht wirklich belegen kann, während es dank salamihawk's Packet-Dump und der gefundenen Lösung mit dem Workaround beim ECN-Problem ja evident ist - dem eigentlichen Anliegen einen Bärendienst, denn wenn man das zusammenwirft ("OpenVPN geht ja auch nicht, sind also schon zwei VPN-Lösungen betroffen."), dann geht am Ende der "Problemlöser" bei UM unter Umständen hin (kann passieren, muß nicht so sein) und testet eben genau eine solche OpenVPN-Verbindung. Ergebnis: funktioniert -> Ticket closed, works for me. Das bringt dann das eigentliche Thema eben nicht vorwärts, es verkompliziert die späteren Erklärungsversuche nur noch mehr, denn wer hört schon gerne, daß er sich geirrt hat. Das braucht dann noch mehr Überzeugungsarbeit.

EDIT: Da in #344 auch im Fazit steht:

Das Problem, dass ich keine Daten durch den Tunnel schicken kann habe ich nur mit der IPSec-Verbindung zu den Fritzboxen.

und das aber ohne FRITZ!Box nach der Liste gar nicht getestet wurde (also z.B. "IPSec VPN von iOS >= Version 9.0.2 zu DS213+" - keine Ahnung, ob die DS das könnte), würde ich gerne noch die Frage aufwerfen, ob nicht andere IPSec-Implementierungen mit IKEv1 (da das Problem vermutlich schon beim IKE auftritt, halte ich es für beweiskräftiger, wenn da auch nur Äpfel miteinander verglichen werden) genauso betroffen sind oder ob wirklich eine FRITZ!Box ein weiterer entscheidender Faktor ist.

 

[Tomacco81]

@PeterPawn: besten Dank für deine Rückmeldung.
Leider habe ich zuhause keine Möglichkeit einen weiteren IPSec-Server eines anderen Herstellers aufzusetzen und dies zu testen.
Was ich allerdings testen konnte, war der L2TP/IPSec VPN-Server meiner Synology.
Getestet habe ich die Verbindung mit iOS 9.1 mit dem Fazit, dass die Verbindung erfolgreich aufgebaut und auch Daten durch den Tunnel übertragen werden konnten.

 

[ElvQuant]

Ok, also die Spekulation mit UDP ist falsifiziert. Also reines IPSec Problem.

Kennt jemand eine IPSec App? Das was ich auf die Schnelle im Store gefunden sind scheinbar alles Tunnel zu jeweiligen Anbietern, aber keine frei zu konfigurierbaren Apps?

 

[Tomacco81]

Auf die schnelle habe ich diese App gefunden:

„VPN On“ von Shenggang Tang
https://appsto.re/de/xYfT4.i

Ist allerdings kostenpflichtig...

 

[amatör]

@ElvQuant: Ich habe mal die Cisco Anyconnect ausprobieren wollen, habe es aber nicht geschafft, eine Verbindung zur Fritzbox zu konfigurieren. Wobei ich nicht weiß, ob es an meinen Halbkenntnissen lag oder ob die App grundsätzlich nicht dafür geeignet ist. Seltsamerweise ist die App zz. nicht mehr im AppStore zu finden?!

Was Tomacco81 schreibt, irritiert mich jetzt noch mehr: Wenn iOS9 mit dem IPSec VPN der Synology kann, warum das? Wird dabei vielleicht keine ECN-Kontrolle vereinbart? Oder hängt anderweitig vom Server (in obigem Sinne) ab?

 

[Tomacco81]

@amatör: die Synology macht kein reines IPSec sondern nur IPSec in L2TP verpackt.
Siehe:
http://apfelcheck.de/osx/synology-mehr-sicherheit-durch-vpn/
http://www.tcp-ip-info.de/tcp_ip_und_internet/tunneling_protokolle.htm

 

[amatör]

Okay, und was verwendet die Fritzbox? PPTP?

 

[Tomacco81]

Die Fritzbox verwendet IPSec.
Siehe: http://avm.de/service/vpn/tipps-tri...ritzbox-unter-apple-ios-zb-iphone-einrichten/

 

[amatör]

Danke. Ich dachte, IPSec wird immer mit L2TP oder PPTP gemacht, aber da merke ich mal wieder, dass ich da einfach nicht wirklich durchblicke.

 

[ElvQuant]

Auf die schnelle habe ich diese App gefunden:

„VPN On“ von Shenggang Tang
https://appsto.re/de/xYfT4.i

Ist allerdings kostenpflichtig...

sah mir aber auch nach einem Localisierungs-Umgehungs-VPN-Service aus. Erfahrungen damit?

 

[Tomacco81]

Ich habe die App nicht im Einsatz da ich derzeit auf OpenVPN umgestellt habe.
Laut der Beschreibung ist die App aber providerunabhängig. Allerdings gehe ich davon aus, dass hier die Standard IPSec Implementierung von iOS verwendet wird.

Hier noch ein Link zur englischen Beschreibung: http://www.iosmobileapp.com/shenggang_tang/vpn_on/appId951344279#

 

[PeterPawn]

Ich verstehe die Suche nach einer "unabhängigen" IPSec-Implementierung für ein iOS-Gerät (ohne JB) nicht so richtig.

Meines Erachtens (ggf. bitte mit Link auf entsprechende API-Dokumentationen von Apple korrigieren) ist es einer iOS-App nicht möglich, so tief in das Netzwerk eines iOS-Gerätes einzugreifen, daß dabei der Netzwerk-Stack so weit verändert wird (bzw. der "Paketfluß"), daß so eine App überhaupt möglich wäre.

Die "OpenVPN Connect"-App arbeitet (vermutlich, vielleicht hat ja hier jemand JB + diese App am Start und kann mal nachsehen) mit einem normalen TUN/TAP-Interface, das wohl auch schon seitens Apple im Kernel unterstützt wird und als Treiber bereits vorliegt, damit nur noch von der App instanziert wird. So ein Device arbeitet dann aber auch komplett anders als die "Ausleitung" des Verkehrs für einen IPSec-Tunnel (soweit man da Analogien zwischen FreeBSD und Darwin unterstellen will). Werden Datenpakete auf dieses TUN/TAP-Device geroutet, erhält sie die Anwendung, die dieses Gerät steuert und ändert sie nach ihrem Belieben. Die daraus entstehenden Pakete werden dann über ein anderes Interface - wie jeder andere Netzwerk-Verkehr auch - an das Ziel übertragen.

Damit dürfte es (wie gesagt, bitte seitens eines iOS-Developers gerne zu korrigieren) keine Möglichkeit für eine App geben, die bei IPSec nach RFC 4301 ohne den Apple-Stack auskommt. RFC-IPSec ist tatsächlich etwas komplett anderes als L2TP/IPSec, auch wenn teilweise (für IKE) dieselben Ports zum Einsatz kommen, sind die Pakete vollkommen anders aufgebaut und noch einmal zusätzlich gekapselt (IPSec -> L2TP -> PPP -> IP, im Extremfall (NAT-T) besteht dann der IPSec-"Umschlag" noch aus drei Ebenen, so daß es bis zum eigentlichen Payload insgesamt 6 Schritte braucht), was schon erklären könnte, warum das vermutlich auch wieder mit dem eingebauten L2TP-Client des iOS funktioniert (auch wenn da nur L2TP stehen mag, verbirgt sich dahinter L2TP/IPSec), wenn da bei einem dieser "decapsulation steps" die ECN-Bits nicht mit kopiert werden. Wobei das jetzt meinerseits extrem spekulativ ist, denn dazu hat hier m.W. auch noch niemand mit einem UM-Anschluß etwas getestet (oder geschrieben, aber der Thread ist ja auch inzwischen recht lang, da kann man schon mal den Überblick verlieren).

Vielleicht kann jemand mit der passenden Technik (die DS sollte das können, eine FRITZ!Box kann es nicht, ein Windows-Server hingegen auch wieder) und einem entsprechenden DOCSIS-Anschluß beim richtigen Provider ja noch einmal probieren, ob es bei L2TP/IPSec ähnliche Probleme gibt. Wenn ja, "verschwinden" die Pakete mit ECN-CE-Tag offenbar schon im ersten Schritt der Entschlüsselung, wenn der "IPsec-Envelope" von den Paketen entfernt wird. Funktioniert so eine L2TP/IPSec-Verbindung hingegen, sollte es erst irgendwo bei der Auswertung der ECN-Bits in den "inneren Paketen" bei RFC-IPSec zu der Entscheidung "will ich nicht" kommen.

 

[ElvQuant]

Deine Argumentation ist richtig PeterPawn. Ich habe bisher auch nur für den Haushebrauch in Cocoa und ObjC für OS X programmiert und kann auch nix zu iOS in den Tiefen sagen. Ein Versuch wäre es wert, da Apple sich bugreprt-resistent zeigt. Wollte gerade fragen ob jemand Steve Jobs Mail-Adresse hat, aber ist ja dieser "Neue", wenig charismatischer Typ.

 

[amatör]

Also ehrlich gesagt habe ich mir schon überlegt mal an den zu schreiben, zumal Apple ja nach eigener Aussage mehr die Business-User da sein möchte. Dazu gehört meiner Meinung eine saubere Basis zu bieten.

 

[PeterPawn]

[email protected]

Aber Vorsicht, bei Kritik ist der "shitstorm" vorprogrammiert (vermutlich kann man als Apple-Kunde auch "exkommuniziert" werden von dieser Glaubensgemeinschaft) und wahrscheinlich hatte Jobs mit dem Debakel mit der geänderten ECN-Funktionalität in iOS9 / OS X "El Capitan" tatsächlich nichts mehr zu tun ... so lang wird auch der "Vorlauf" bei Apple nicht sein.

 

[amatör]

Ich meinte auch "den Neuen".