Wenn du aufmerksam lesen würdest, was als nicht betroffener zugegeben schwierig ist, dann würdest du schon auch feststellen das alles auf ein Problem und eine Ursache hinausläuft.
Ohne jetzt auf die Annahme, ich hätte nicht gelesen und/oder verstanden, was hier geschrieben wurde, näher einzugehen (glücklicherweise hast Du nicht auch noch gefragt, was ich als Außenstehender so zum Thema Intelligenz zu sagen hätte) ... es dreht sich in diesem Thread eben nicht nur um das von "sirin" und "salamihawk" festgestellte Problem.
Wie erklärst Du dann z.B. die Feststellung
sTaNy schrieb:
Ich kann allerdings sämtliche IP-Adressen im Internet anpingen (getestet mit der App Free Ping).
?
Insofern sind es vielleicht wirklich zwei unterschiedliche Probleme (ein anderer kann den Google-DNS auch erreichen, suche ich jetzt aber nicht, wer es wissen will, muß eben selbst noch mal ab #1 lesen) und ich sehe - offenbar im Gegensatz zu Dir - eher nicht, daß
sirin schrieb:
alles auf ein Problem und eine Ursache hinausläuft
.
sirin schrieb:
Ehrlich gesagt fehlt mir was IPsec angeht das Know-How
Nimm's mir nicht übel, aber dann ist die Feststellung
sirin schrieb:
der Artikel beschreibt einen völlig anderen Sachverhalt.
als unmittelbarer Schnellschuß schon etwas gewagt.
BTW @amatör: Der heise.de-Artikel beschreibt, daß die "Cisco AnyConnect"-App bei der Verwendung von "Split Tunneling"
von dem iOS-Bug betroffen ist. Wo ist in diesem Falle der Zusammenhang zur Feststellung
amatör schrieb:
Das in iOS eingebaute IPSec kann meines Wissens gar kein Split-Tunneling (zumindest nicht bei der Standard-Einrichtung auf dem iPhone).
? Die AnyConnect-App rüstet natürlich keinen eigenen IPSec-Stack im iOS nach (das ließe Apple wohl nicht einmal Cisco durchgehen) und basiert damit ebenfalls auf dem IPSec-Stack, den Apple ins iOS eingebaut hat. Hat der also einen Fehler, der die Arbeit von Cisco's AnyConnect-Client beeinflußt, existiert dieser Bug auch für die Apple-eigene Implementierung (des Frontends).
sirin schrieb:
Wenn du mit deinem offensichtlichen Know-How etwas zu dem Thema beitragen kannst dann freue ich mich und sicherlich auch alle anderen betroffenen.
Eigentlich gerne, aber fröhliches Raten ist eher nicht so sehr "meins". Entweder es fertigt jemand entsprechende Mitschnitte an oder stellt wenigstens die IKE-Protokolle einer FRITZ!Box oder noch besser die Debug-Protokolle einer pfSense (keine Ahnung, welche IPSec-Implementierung für FreeBSD da hinter den Kulissen werkelt, schmeiße ich auch immer mit IPFire durcheinander) zur Verfügung, dann helfe ich gerne bei der Analyse und Interpretation ... auch mit Tipps zur weiteren Eingrenzung. Ansonsten bin ich aber eben "nicht betroffen" und kann nichts selbst testen ... zum Kaffeesatz-Lesen habe ich mich schon geäußert.
EDIT: Um noch einmal etwas zum Thema "stabile Verbindung" zu bemerken ... eine IPSec-VPN-"Verbindung" ist nichts weiter als ein ausgehandelter Schlüssel, der für eine begrenzte Zeit und/oder Datenmenge zwischen den Peers vereinbart wurde. Wenn da gar keine Daten über eine solche Verbindung "übertragen" werden (können), kann man die "Stabilität" einer solchen Verbindung (ja, sogar ihren weiteren Bestand, wenn da nicht andere Techniken wie "dead peer detection" zu Einsatz kommen - die aber eine Ebene darunter schon ansetzen) gar nicht beurteilen. Im schlechtesten Falle verfällt einfach die SA nach Ablauf ihrer "lifetime" und die Verbindung ist wieder "zu". Solange so ein "VPN-Client" für eine IPSec-Verbindung kein dediziertes "virtuelles Interface" (wie z.B. der ShrewSoft-Client für Windows und Linux) verwendet, gibt es keine "Signalisierung" einer funktionierenden "Leitung".