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

[Barthsimpson]

Genau, wir haben nen Linux Router vor dem iPhone im Netz gesetzt und dort die Pakete gesäubert.

Hut ab! Du bist der Wahnsinn!

 

[sTaNy]

Muss ich auch sagen. Geiler Typ salamihawk! Ich hoffe, wie dann doch nicht so wenige, auf ein baldiges Entgegenkommen seitens UM oder Apple...

 

[Paolo]

@salamihawk, ist das mit einer Fritzbox mit Freetz (iptables-cgi) möglich oder was für eine Router / Distri verwendest du?

 

[Deifie]

Imore.com funktioniert seit heute wieder im UM Netz, VPN leider noch nicht...

 

[A6_neu]

Mir hat heute UM geantwortet, dass das Problem nach einem Werksreste der Fritz!Box wieder gehen würde:

Sehr geehrter Kunde, Ihre Stoerung kann durch einen Werksreset der Fritzbox behoben werden. Hierzu schließen Sie bitte ein analoges Telefon an die Fritzbox an und waehlen Sie die #991*15901590* Bei Fragen wenden Sie sich bitte an unseren Kundenservice. Ihr Unitymedia Team

Hab ich so auch gemacht, leider aber ohne Erfolg :-(

Wie sehen Eure Erfahrungen aus?

 

[paddyfalk]

Tja, so eine SMS kam gestern auch bei mir an. Natürlich hat es nichts gebracht. Außer das meine Telefonnummern im UM-Netz jetzt nicht mehr einzurichten sind. Normalerweise sollte das Netz diese Daten automatisch wieder in die Box pushen.
Habe dann dort angerufen - es soll jetzt ein Techniker kommen !? Was bitte soll der hier machen? Die 0x03-Pakete umwandeln? Dann muss ich dem ja noch ein Bett aufstellen und Essen kochen usw...*Ironie off*
Dann nochmal angerufen, weil ich nach einiger Überlegung diesen Einsatz für völlig überflüssig halte. Diesmal wurde jedesmal nach einer Minute Warteschleife aufgelegt. Ich glaube, die halten mich für einen lästigen und nervigen Kunden... (Ist aber bei denen jeder, der mehr möchte, als die Grundgebühr vom Konto abgebucht zu bekommen)
So langsam verstehe ich da aber auch keinen Spass mehr. Das VPN funktioniert einfach nicht. Und eine Nachbesserung von Apple ist nicht abzusehen. Weder in 9.0.2 noch in der 9.1b3.

 

[amatör]

Mit solchen Antworten stellt sich der UM-Support wahrlich kein gutes Zeugnis aus. :-(

 

[ElvQuant]

Mir hat heute UM geantwortet, dass das Problem nach einem Werksreste der Fritz!Box wieder gehen würde:

Den Bullshit hat man mir vor zwei Tagen nach meiner Störungsmeldung auch geschrieben. Vorher hatte ich noch einen Anruf, der Details durchsprechen wolle, obwohl ich eine lange Erläuterung geschrieben habe, die keiner gelesen hat. Der gute Mann wollte den Fehler mit seiner Checkliste klassifizieren, aber keiner der Multiple Choice Antworten passte, also wollte er eine zufällige nehmen, dem ich massiv wiedersprochen habe, weil es ja eine falsche Angabe sei. Man solle die Fehlerbeschreibung mal lesen ... "aber die sei soooooo lang"

Nach dem Erkenntnissen in diesem Thread habe ich sicherheitshalber eine Sicherung meiner Fritzbox gemacht, wenn die Junx bei UM auf den Gedanken kämen es Remote zu machen. Ich habe es gelassen, weil es nichts bringen kann. Dadurch verschwindet die 0x03 auch nicht aus dem ECN!

Der Support ist wirklich erbärmlich!


EDIT: gleichen Fehler mit OSX an UM und Apple (bugreport) gemeldet.

 

[amatör]

Moin,
Problem an Heise.de gemeldet: Keine Reaktion!
Problem an Golem.de gemeldet: Keine Reaktion!

Ich hatte die Hoffnung, dass da vielleicht jemand Recherche betreibt und die betroffenen Unternehmen (fairerweise) erst noch um eine Stellungnahme bittet. Aber inzwischen glaube ich, dass da gar nichts passiert. Artikel abzuschreiben ist halt einfacher und ökonomischer als richtige Recherche zu betreiben.

Edit:
Ich irre mich gerne!

 

[jeanluca]

Ich bin sicherlich kein Fachmann für ip Technologie aber folgender Versuchsaufbau bzw Test lässt mich glauben, dass es ausschliesslich an Unity Media liegt:

Ich habe 2 Häuser, jeweils mit UM Anschluss. Wenn ich in Haus A über Fritzbox (WLAN) per Macbook Air und eingerichtetem VPN in den Netzwerkeinstellungen
des Macbook auf meine Diskstation in Haus B an Fritzbox B zugreifen möchte, bekomme ich keine Verbindung.

Nutze ich das gleiche Macbook Air und gehe anstatt per Fritzbox WLAN am UM Netz über den MobileHotspot meines iPhone6 mit Telekom LTE ins Netz, klappt die Verbindung tadellos.

Ebenfalls funktionieren tut die Verbindung direkt über das Handy, der Zugriff per VPN im iPhone (8.4.1) aber nur, wenn ich per LTE im Netz bin. Nehme ich die identischen Einstellungen
und versuche es mit dem iPhone in Haus A über das WLAN der Fritzbox A passiert nichts...

Die Apple Geräte sind immer gleich und immer gleich eingestellt. Ich ändere "nur" den Zugang über LTE oder UM...

Ich habe aber ebenfalls die Erfahrung gemacht, dass iOS 9x das gar nicht hinbekommt... deshalb der Downgrade auf iOS 8.4.1...

 

[ElvQuant]

Unitymedia die fünfte. Ein Supporter scheint den Artikel zu dem Split-DNS Problem aus 9.0 gefunden zu haben, der mit 9.0.1 behoben wurde. Daher wurde ich informiert, dass Apple das Problem behoben habe.

Das wir ein anderes Problem haben verstehen die Leute nicht. Leider kommt man auch nicht bis zu jemanden, der etwas von dem versteht, was man zu berichten hat. Und da in den Technik-Blogs und -News das Problem mit dem ECN nicht thematisiert wird ... Weiß auch nicht mehr weiter!


@jeanluca
Ja es tritt nur in iOS ab 9.0 und OSX El Capitan auf. Unitymedia setzt vereinfacht gesagt ein "Hier ist alles verstopft im Datennetz" und Apple verwirft diese Daten innerhalb eines VPN Tunnels. Siehe "salamihawk"

EDIT: Downgrade auf 8.4.1 geht seit zwei Tagen nicht mehr!

EDIT2: ich werde mal in der Geniusbar um Rat fragen.

 

[amatör]

Geniusbar? Da bin ich aber mal gespannt!

 

[amatör]

Genau, wir haben nen Linux Router vor dem iPhone im Netz gesetzt und dort die Pakete gesäubert.

Bezüglich El Capitan - wäre es denn möglich, unter OS X mit dem Packetfiler pfctl die ECN-Flags zurückzusetzen? So dass man wenigstens mit einem Mac ins VPN käme? (Für iOS ist das sicher nicht möglich...)

Ich habe mich noch ein bisschen damit beschäftigt und - obwohl ich immer wieder betonen muss, dass ich kein Fachmann bin - habe im Netz viele Hinweis darauf gefunden wie problematisch ECN oft sein kann. In diesem RFC-Dokument (insbesondere ab Abschnitt 3) wird darauf eingegangen wie man mit ECN umgehen kann, wenn es unterwegs nicht korrekt verwendet wird (was bei UM der Fall sein könnte). Das Dokument ist allerdings von 2002... Wenn ich es recht verstehe (was keineswegs garantiert ist), ist jedenfalls eine Idee, dass der VPN-Host optional auf die Anfrage des Clients, ECN zu verwenden, reagiert, indem er so tut als könne er das nicht. Der Client sollte daraufhin so funktionieren wie ohne ECN.

Ich verwende am UM-Anschluss das VPN der Fritzbox und frage mich nun, ob die Probleme nicht wenigstens als Work-around so gelöst werden können, indem auf der Fritzbox beim Aushandeln der VPN-Verbindung keine Unterstützung für das ECN angeboten wird? Wäre dann nicht alles wie früher?

Was meinen die Experten (salamihawk!) hier in dieser Runde dazu?

EDIT:

Habe gerade diesen Wikipedia-Eintrag (wieder-)entdeckt (siehe auch hier):

Mac OS X 10.5 and 10.6 implements ECN support for TCP. It is controlled using the boolean sysctl variables net.inet.tcp.ecn_negotiate_in and net.inet.tcp.ecn_initiate_out.[17] The first variable enables ECN on incoming connections that already have ECN flags set; the second one tries to initiate outgoing connections with ECN enabled. Both variables default to 0, but can be set to 1 to enable the respective behavior.

Kann bitte mal jemand mit El Capitan ausprobieren, ob nach

sudo sysctl -w net.inet.tcp.ecn_negotiate_in=0
sudo sysctl -w net.inet.tcp.ecn_initiate_out=0

die VPN-Verbindung wieder funktioniert?

Nachtrag zur Vermeidung von Missverständnissen: Ich meinen einen Mac mit El Capitan, der sich auf einen UM-Anschluss per VPN verbindet. Klar ist, dass man damit nur das Problem für diesen Client und nicht generell lösen kann.

 

[wunschname]

Kann bitte mal jemand mit El Capitan ausprobieren, ob nach

sudo sysctl -w net.inet.tcp.ecn_negotiate_in=0
sudo sysctl -w net.inet.tcp.ecn_initiate_out=0

Sorry. Bringt nichts.

$ sysctl -w net.inet.tcp.ecn_negotiate_in=0
net.inet.tcp.ecn_negotiate_in: 0 -> 0
$ sysctl -w net.inet.tcp.ecn_initiate_out=0
net.inet.tcp.ecn_initiate_out: 0 -> 0

 

[amatör]

Schade. Vielleicht wird IPSec separat konfiguriert. Zwei Settings, die man noch probieren könnte:

net.inet.ipsec.ah_cleartos
If set to non-zero, the kernel clears the type-of-service field in the IPv4 header during AH authentication data computation. This variable is used to get current systems to inter-operate with devices that implement RFC1826 AH. It shouldbe set to non-zero (clear the type-of-service field) for RFC2402 conformance.


net.inet.ipsec.ecn
If set to non-zero, IPv4 IPsec tunnel encapsulation/decapsulation behavior will be friendly to ECN (explicit congestion notification), as documented in draft-ietf-ipsec-ecn-02.txt. gif(4) talks more about the behavior.

Gefunden auf: https://www.freebsd.org/cgi/man.cgi?query=ipsec&sektion=4

 

[Biker73]

Nachdem ich in Eintrag #123 gelesen habe, daß Mechman eine Verbindung mit OpenVPN hin bekommen hat,
es bei mir aber weiterhin nicht funktioniert hat, habe ich das Zertifikat und die Konfigurationsdatei auf dem
OpenVPN Server neu erzeugt und auf iPad und iPhone installiert.
Ergebnis: Zugriff auf Geräte im lokalen Netz über OpenVPN ist jetzt wieder möglich

Hier kurz die Beschreibung zur Vorgehensweise:

Ausgangssituation (Vor dem Reimport wurde der Zugriff auf beide unten genannten Netze nochmal kontrolliert):
1. Heimnetz (hängt am UM Netz):
iPhone und iPad (beide mit iOS 9.0.2) können eine Verbindung mit dem OpenVPN Server auf einer Synology Diskstation
hinter einer Fritzbox 7390 herstellen, aber ein Zugriff auf das lokale Netz ist nicht möglich.
Funktioniert aber mit iOS 8.4.1 (iPhone 5).
2. Zugriff auf ein Netzwerk das an einem Telekom DSL Anschluß hängt:
iPhone und iPad (beide mit iOS 9.0.2) können eine Verbindung mit dem OpenVPN Server auf einer Synology Diskstation
hinter einer Fritzbox 3370 herstellen, ein Zugriff auf das lokale Netz ist möglich.

Vorgehensweise Reimport:
Zertifikat und Konfiguration durch OpenVPN Server neu erzeugt.
Dateien über iTunes auf iPhone neu importiert.
Über 3G mit OpenVPN Server im Heimnetz verbunden.

Ergebnis:
iPhone kann wieder über den OpenVPN Server auf die Geräte des lokalen Netzes zugreifen.
Das Gleiche habe ich mit dem iPad auch nochmal durchgeführt mit dem selben Ergebnis.

Technisch erklären kann ich leider nicht warum es mit 8.4.1 funktioniert hat und mit 9.0.2 erst
wieder nachdem die Konfigurationsdatei und das Zertifikat neu importiert wurden.

Eine direkte VPN Verbindung mit der Fritzbox führt allerdings weiter zu dem Ergebnis,
daß die Geräte im lokalen Netz nicht erreichbar sind.

 

[wunschname]

net.inet.ipsec.ah_cleartos
net.inet.ipsec.ecn

Hat leider nichts gebracht:

$ sysctl -w net.inet.ipsec.ah_cleartos=0
net.inet.ipsec.ah_cleartos: 1 -> 0
$ sysctl -w net.inet.ipsec.ecn=0
net.inet.ipsec.ecn: 0 -> 0

 

[PeterPawn]

Sorry. Bringt nichts.

Das dürfte u.a. daran liegen, daß damit wohl das ECN für TCP gesteuert wird, das sind andere Bits im TCP-Header, der beim vom IPSec verwendeten UDP nicht existiert. Die fraglichen Bits in den IP-Paketen befinden sich im TOS-Feld (Bits 6 und 7 im zweiten Byte eines IP-Headers) und werden - zumindest legt das der Name der Variablen nahe - von den TCP-bezogenen Einstellungen sicherlich nicht beeinflußt.

Für das theoretische Verständnis der ECN-Verwendung (jenseits dessen bzw. als klarere Darstellung dessen, was ich in #93 versucht habe zu beschreiben), sei jedem Interessierten der englische (der deutsche ist praktisch unbrauchbar) Artikel aus der Wikipedia zu dieser Thematik empfohlen: https://en.wikipedia.org/wiki/Explicit_Congestion_Notification

Insbesondere die dortigen Ausführungen zu den Verantwortlichkeiten bei der Steuerung des Datenflusses bei den verschiedenen IP-Protokollen sollten den Unterschied zwischen TCP-ECN und IP-ECN (die zwar korrespondieren können, es aber nicht zwangsweise müssen) deutlich werden lassen.

Es gibt (zumindest in iptables 1.4.21) auch die Option, gezielt einzelne Bits im TOS-Feld des IP-Headers auszublenden, was - anders als der bisher von salamihawk verwendete Workaround - die anderen Angaben im zweiten Byte des IP-Headers (das DSCP-Feld, was die eigentliche Infomation zum "Typ" der enthaltenen Daten darstellt) intakt lassen könnte (das "--set-tos" schreibt offenbar alle 8 Bit, wenn man es ohne "mask" verwendet). Allerdings habe ich außer dem Hilfetext

~ # iptables -j TOS -h
iptables v1.4.21
[...]
TOS target vlibxtables.so.10 options:
  --set-tos value[/mask]  Set Type of Service/Priority field to value
                          (Zero out bits in mask and XOR value into TOS)
  --set-tos symbol        Set TOS field (IPv4 only) by symbol
                          (this zeroes the 4-bit Precedence part!)
                          Accepted symbolic names for value are:
                            (0x10) 16 Minimize-Delay
                            (0x08)  8 Maximize-Throughput
                            (0x04)  4 Maximize-Reliability
                            (0x02)  2 Minimize-Cost
                            (0x00)  0 Normal-Service

[COLOR="#008000"]  --and-tos bits          Binary AND the TOS value with bits[/COLOR]
  --or-tos  bits          Binary OR the TOS value with bits
  --xor-tos bits          Binary XOR the TOS value with bits
~ #

bisher auch noch kein einziges Beispiel gefunden, wie die Angabe von "bits" denn zu erfolgen hätte. Mangels UM-Anschluß ist mir auch ein Test nicht ohne weiteres möglich ... nicht einmal die Quellen der vlibxtables finde ich auf Anhieb, damit fällt auch die Analyse des Quelltextes aus.

Es ist bei diesen TOS-Geschichten auch immer etwas schwierig, zwischen dem "alten Standard" (TOS-Feld mit 8 Bit) und dem "neuen Standard" (6 Bit DSCP, 2 Bit ECN) zu unterscheiden, da sich die verfügbaren Kommandos mal auf den einen und mal auf den anderen stützen.

Die Angaben, ob bei Apple/FreeBSD nun das "generic tunnel interface" (gif) genutzt wird, wenn man eine IPSec-Verbindung im "tunnel mode" benötigt, sind auch nicht eindeutig.

Zwar beschreibt der Abschnitt "ECN friendly behavior" genau das (in #93 nur als Vermutung geäußerte) Verhalten, daß ECN-Conditions von den äußeren Paketen in die inneren gekapselten Pakete kopiert werden (am Endpoint), aber andererseits steht dort auch deutlich:

There are many tunneling protocol specifications, defined differently from each other. gif may not
interoperate with peers which are based on different specifications, and are picky about outer header
fields. For example, you cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode.

Wird denn nun so eine IPSec-Verbindung unter iOS/OS X über ein "gif" abgewickelt oder nicht? Eigentlich sollte das "tunnel mode" sein ... wenn ich mich nicht irre. Wenn es auf die Verwendung von "gif" hinausläuft (oder dieses "ECN friendly behavior" analog implementiert wurde), sollte sich der von salamihawk angeregte Test mit "[sudo] sysctl w net.inet.ipsec.ecn=0" in jedem Falle lohnen ... auf einem iOS-Gerät sicherlich schwerer umzusetzen (aber dem Vernehmen nach soll ja auch beim 9.0.2 der Jailbreak funktionieren).

Spannend ist allerdings noch die Feststellung in der oben verlinkten man-Page:

Note that the ECN friendly behavior violates RFC2893. This should be used in mutual agreement with the peer.

die ja durchaus ein Problembewußtsein beim (nicht standardisierten) Kopieren von ECN-Bedingungen aufzeigt (auch wenn RFC 2893 sich auf IPv6/IPv4-Interoperabilität bezieht).

EDIT: Ok ... die Frage, ob "ipsec.ecn=0" etwas bringt, ist inzwischen geklärt ... schade.

EDIT2: Hat mal jemand mit "El Capitan" versucht, mit pfctl eine zusätzliche Regel für

scrub in on $ext_if proto udp from any port 4500 set-tos 0

(oder so ähnlich, habe gerade kein System mit "pf" zur Hand, um die Syntax zu testen) zu setzen?

Die Idee wäre hier dieselbe wie beim zusätzlichen Linux-"Mangling" ... das Löschen der ECN-CE-Kennzeichnung bei allen IPSec-Paketen (UDP/4500 bei NAT-T) über das Setzen eines neuen TOS-Wertes.

Wenn das OS X-Gerät der "Client" (Initiator) in der IPSec-Verbindung ist, sollten die betreffenden Pakete von der entfernten IP-Adresse (any) vom Port 4500 kommen, wenn ich keinen Knoten im Gehirn habe. Allerdings weiß ich nicht, ob die "raw packets" einer IPSec-Verbindung überhaupt schon am "packet filter" ankommen oder ob die schon vorher "weggefangen" werden und nur der entschlüsselte Traffic den "pf" passiert.

 

[amatör]

Hat leider nichts gebracht:

$ sysctl -w net.inet.ipsec.ah_cleartos=0
net.inet.ipsec.ah_cleartos: 1 -> 0
$ sysctl -w net.inet.ipsec.ecn=0
net.inet.ipsec.ecn: 0 -> 0

Müsste wohl auf 1 gesetzt werden, um zu wirken:

"If set to non-zero [...]"

Ich hab mal die Settings auf meinem OS X 10.9 ausgelesen, da ist alles auf 0 außer dem ipsec.ah_cleartos, das auf 1 gesetzt ist.

 

[amatör]

Ergebnis:
iPhone kann wieder über den OpenVPN Server auf die Geräte des lokalen Netzes zugreifen.
Das Gleiche habe ich mit dem iPad auch nochmal durchgeführt mit dem selben Ergebnis.

Technisch erklären kann ich leider nicht warum es mit 8.4.1 funktioniert hat und mit 9.0.2 erst
wieder nachdem die Konfigurationsdatei und das Zertifikat neu importiert wurden.

Eine direkte VPN Verbindung mit der Fritzbox führt allerdings weiter zu dem Ergebnis,
daß die Geräte im lokalen Netz nicht erreichbar sind.

Dazu hätte ich folgende Fragen:

Hast die Konfiguration und das Zertifikat auf der Fritzbox auch neu erstellt und importiert?
Wie importierst du Konfiguration und Zertifikat über iTunes ins iPhone (ich verwende hierzu das iPhone Configuration Utility)?