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

Sehr, sehr interessant! Danke @emigre dass du dich dafür extra angemeldet hast!

Klappt wieder...

emigre schrieb:

Habe mich extra hierfür angemeldet
Erfolg brachte unter MacOS X folgendes:

# sysctl -w net.inet.ipsec.ecn=2
net.inet.ipsec.ecn: 0 -> 2

Der Wert "1" brachte nichts, was "2" bewirkt -> keine Ahnung - aber es funktioniert bei mir (UM Business).

Viel Erfolg,
emigre

Zum Vergrößern anklicken....

Benutze selbst OS X El Capitan mit einer VPN Verbindung zur Arbeit.
VPN Server auf der Arbeit läuft über einen UM Business Anschluss IPV4.
VPN Client bei mir zu Hause über UM Privat Anschluss.
Durch den Eintrag funktioniert jetzt auch der Datenverkehr wieder einwandfrei !!!
Ich hatte mir solange als Notlösung OS X Yosemite auf eine zweite Partition gezogen...kann ich ja jetzt wieder löschen.
Vielen Dank dafür.

Bekommt man sowas auch irgendwie für die iOS hin ?

Gruss
BarisA

Um es nicht nach jedem booten (ist bei mir eh sehr selten, UNIXoid halt) neu machen zu müssen kann man den Eintrag in '/etc/sysctl.conf' vornehmen, man sollte genau wissen was man tut.

Auf iOS nicht ohne Jailbreak, denke ich. Aber wenn ein Jailbreak da ist, wird man auch die sysctl ändern können, irgendwie.


@emigre: mach doch mal nen bugreport.apple.com und schreib deinen Work-Around mit rein.

9.1b5 is out - wäre schön zu wissen, ob der Bug behoben ist

ElvQuant schrieb:

Um es nicht nach jedem booten (ist bei mir eh sehr selten, UNIXoid halt) neu machen zu müssen kann man den Eintrag in '/etc/sysctl.conf' vornehmen, man sollte genau wissen was man tut.

Zum Vergrößern anklicken....

kannst du eine entsprechende "Anleitung" schreiben wie und wo man den Eintrag dauerhaft setzen muss ?

Wäre Super !

Ruhig Brauner (The Brad) ... 9.1b5 installiert sich gerade ...

BarisA schrieb:

kannst du eine entsprechende "Anleitung" schreiben wie und wo man den Eintrag dauerhaft setzen muss ?

Wäre Super !

Zum Vergrößern anklicken....

Als root (nicht per "sudo"! sondern per "su -"):

echo "net.inet.ipsec.ecn=2" >> /etc/sysctl.conf

Leider funktioniert es bei mir mit 9.1b5 immer noch nicht...Aber auch ich würde mich über eine Anleitung für El Capitan freuen! Dann koennte ich zumindest dort updaten!

EDIT: Da war ich zu langsam. Einfach nur den Parameter auf 2 setzen? Das klingt ja zu einfach um wahr zu sein!

emigre schrieb:

Als root (nicht per "sudo"! sondern per "su -"):

echo "net.inet.ipsec.ecn=2" > /etc/sysctl.conf

Zum Vergrößern anklicken....

Kaum einer der fragt, wird Root aktiviert haben.
Ich würde keinesfalls /etc/sysctl.conf überschreiben ohne geprüft zu haben dass diese leer ist oder noch nicht vorh. ist

echo "net.inet.ipsec.ecn=2" >> /etc/sysctl.conf

sTaNy schrieb:

Leider funktioniert es bei mir mit 9.1b5 immer noch nicht...

Zum Vergrößern anklicken....

Muss ich leider bestätigen. Keine Verbesserung in der Beta 5!

emigre schrieb:

net.inet.ipsec.ecn: 0 -> 2

Der Wert "1" brachte nichts, was "2" bewirkt -> keine Ahnung - aber es funktioniert bei mir (UM Business).

Zum Vergrößern anklicken....

Ich habe mal versucht herauszufinden, was der Wert 2 bewirken könnte. Sehr weit bin ich leider nicht gekommen. In den man-Pages zu OS X finde ich nur

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.

Der Draft auf https://tools.ietf.org/html/draft-ietf-ipsec-ecn-02 sagt natürlich nichts darüber aus, welcher Steuerwert bei einer Implementierung verwendet wird, aber ich könnte mir vorstellen, dass der unklare Bezug in den man-Pages auf diese beiden im Draft genannten Möglichkeiten abzielt:

[...] The result is that an IPsec security administrator is
presented with two alternatives for the behavior of ECN-capable
connections within an IPsec tunnel:
- A limited-functionality alternative in which the ECN bits are
preserved in the inner header, but ECN functionality is disabled
in the outer header. The only mechanism available for signaling
congestion occurring within the tunnel in this case is dropped
packets.
- A full functionality alternative that supports ECN in both the
inner and outer headers. This alternative propagates ECN
congestion notifications from nodes within the tunnel to endpoints
outside the tunnel.
Support for these alternatives involves changes to IP header
processing at tunnel ingress and egress. All IPsec implementations
MUST implement one of the above two alternatives in order to
eliminate the current incompatibility between ECN and IPsec tunnels,
but implementers MAY choose to implement either alternative.

Ich könnte mir vorstellen, dass mit 1 und 2 zwischen der full und der limited functionality umgeschaltet werden kann. Ist aber natürlich nur "a shot in the dark".

Edit: In der gif(4) man-Page steht:

gif can be configured to be ECN friendly, as described in draft-ietf-ipsec-ecn-02.txt. This is turned
off by default, and can be turned on by IFF_LINK1 interface flag.

und weiter unten

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

Ob der letzte Zusatz als veraltet betrachtet werden kann, ist mir nicht klar.

Weiter steht da:

With IFF_LINK1, gif will copy ECN bits (0x02 and 0x01 on IPv4 TOS byte or IPv6 traffic class byte) on
egress and ingress, as follows:

Ingress Copy TOS bits except for ECN CE (masked with 0xfe) from inner to outer. Set ECN CE bit
to 0.

Egress Use inner TOS bits with some change. If outer ECN CE bit is 1, enable ECN CE bit on the
inner.

Ja amatör. Ich habe auch nichts erhellendes zu "2" finden können.

na ja, langsam habe ich Routine im anlegen von Bugreports und immer neuen Formulierungen des immer gleichen Problems. Neue Version (auch wenn es eine Beta ist) und wieder den selben Bug reporten.

ElvQuant schrieb:

Kaum einer der fragt, wird Root aktiviert haben.
Ich würde keinesfalls /etc/sysctl.conf überschreiben ohne geprüft zu haben dass diese leer ist oder noch nicht vorh. ist

echo "net.inet.ipsec.ecn=2" >> /etc/sysctl.conf

Zum Vergrößern anklicken....

Völlig richtig und funktioniert bestens, selbst wenn es - wie bei mir - keine /etc/sysctl.conf gibt.

Ich habe den Tip vom emigre von jemandem verifizieren lassen. Nur soviel, korrekt ist in diesem Fall:


Habe ich gerade getestet mit El Capitan und IPSec hinter UM Anschluss - funktioniert. Ist persistent bis zum nächsten Reboot. Oder eben wie schon beschrieben in die /etc/sysctl.conf packen. Danke nochmal an emigre für die Spur! Zumindest El Capitan user können jetzt entspannt auf den richtigen Fix warten.

Jemandem? Wie geheimnisvoll!

The Dude schrieb:

Ich habe den Tip vom emigre von jemandem verifizieren lassen. Nur soviel, korrekt ist in diesem Fall:

Code:

sudo sysctl net.inet.ipsec.ecn=-1

Habe ich gerade getestet mit El Capitan und IPSec hinter UM Anschluss - funktioniert. Ist persistent bis zum nächsten Reboot. Oder eben wie schon beschrieben in die /etc/sysctl.conf packen. Danke nochmal an emigre für die Spur! Zumindest El
Capitan user können jetzt entspannt auf den richtigen Fix warten.

Zum Vergrößern anklicken....

Solange wir nicht wissen, was der jeweilige Wert wirklich bewirkt, stochern wir leider nur im Nebel.
Aber warum "-1" korrekt sein sollte, darfst Du gerne ausführlicher erklären. "Jemand" ist müßig.

Gem. Wiki: https://en.wikipedia.org/wiki/Explicit_Congestion_Notification#Linux heißt es:

• 0 – disable ECN and neither initiate nor accept it
• 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts
• 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections

Zum Vergrößern anklicken....

Ich bleibe daher erst mal bei dem Wert "2" - dazu habe ich wenigstens etwas gefunden.

Das experimentell ermittelte Ergebnis (value=2) widerspricht ja der (FreeBSD-)Dokumentation, die von Apple selbst an dieser Stelle verlinkt wird ... das hatten wir ja früher schon in diesem Thread.

Ausgehend davon, daß die Dokumentation ja deutlich sagt, daß "non-zero" das Verhalten einschaltet, den ECN-Status von den äußeren in die inneren Pakete (und umgekehrt beim Kapseln) zu kopieren, kann man vermuten, daß Apple da eine weitere Bedeutung für den Wert von ipsec.ecn implementiert hat.

Ich würde etwas in der Art:

0 - do not support ECN as specified in the draft (das Dokument wurde ja mehrfach verlinkt und zitiert hier)
1 - support ECN as specified in the draft, but drop packet with CE set
2 - support ECN as specified in the draft, but continue to process packet content, even if is CE set if CE is set (manchmal ist man nur noch blind)

annehmen wollen.

Das würde zumindest mal die Ergebnisse von emigre (inkl. der fehlenden Doku von Apple) erklären, nur der Beitrag #254 von The Dude paßt dann nicht dazu.

Hier wäre wieder ein Packetdump hilfreich, der die Unterschiede im Verhalten bei den o.a. Werten (0-2) in den inneren Paketen (nach dem Auspacken aus der IPSec-"Transportverpackung") ermittelt.

Es kann natürlich auch ganz simpel sein, daß Apple da einen Fehler in der Implementierung hat und an zwei verschiedenen Stellen aus dem neuen Wert beim "sysctl" eine Einstellung geändert wird, einmal mit dem Test "value != 0" und einmal mit dem Test "(value & 1) != 0" und damit im Ergebnis bei dem Wert 2 ein Mittelding aus "unterstützt" und "nicht unterstützt" eingeschaltet wird. Klingt zwar wirklich simpel (und ist reine Spekulation, das bitte nicht aus den Augen verlieren) und sollte einem erfahrenen Programmierer (selbst wenn es unterschiedliche Personen implementiert haben) nicht passieren, aber wir hatten auch schon "goto fail;"-Statements an falschen Stellen.

EDIT:
@emigre:
Da wirfst Du aber wieder die Definition für TCP und IP durcheinander bei der von Dir zitierten Stelle in der Wikipedia und während man bei Apple nur raten kann, kann man das für den Linux-Kernel ja jederzeit nachlesen. Aber wie gesagt ... es geht hier ohnehin um TCP-ECN und nicht um IP-ECN - das sind unterschiedliche Baustellen und ich werde nicht müde, das zu betonen.

Von jemandem? Wie geheimnisvoll!

amatör schrieb:

Von jemandem? Wie geheimnisvoll!

Zum Vergrößern anklicken....

Dèjá-vu? :gruebel:

The Dude schrieb:

Ich habe den Tip vom emigre von jemandem verifizieren lassen. Nur soviel, korrekt ist in diesem Fall:

Code:

sudo sysctl net.inet.ipsec.ecn=-1

Habe ich gerade getestet mit El Capitan und IPSec hinter UM Anschluss - funktioniert. Ist persistent bis zum nächsten Reboot. Oder eben wie schon beschrieben in die /etc/sysctl.conf packen. Danke nochmal an emigre für die Spur! Zumindest El Capitan user können jetzt entspannt auf den richtigen Fix warten.

Zum Vergrößern anklicken....

Gibt es eine Erläuterung warum "-1" richtiger sei, als "2"? emigre und PeterPawn haben ja einen Auszug aus der Doku beigelegt.


Ich wollte 9.0.2 jailbreaken und schauen, ob wie man dort was bewegen kann. Scheinbar ist aber TaiG fürs iPad nicht so weit, es gibt zwar eine WebSeite, die aber keinen iPad Support hat. Pangu sieht so schön einfach aus, aber keine der injizierten Apps funktionierte, vielleicht auch kein iPad Support? Tja, schade ...


Schräge Gedanken eines Entwicklers (reine Spekulation): Bei "2" und -1" ist das zweite Bit (von rechts) gesetzt, während das erste Bit und alle höhenwertigen als 2 wechseln, also keine Bedeutung haben!? Vielleicht funktioniert der IPSec Tunnel bei allen Werten, wo das zweite Bit gesetzt ist.
-1 = 255 (Einer-Komplement)
2
3
6
7
10
11
14
15
...