VPN zu Fritzbox aus einem bestimmten Netzwerk heraus nicht möglich?!

[Canni]

Hallo zusammen,



ich verbinde mich zu verschiedenen Fritzboxen a) per Fritzbox VPN-Client und B) mit dem IPhone (IPSec). Das klappte bisher immer problemlos (egal ob 2G, 3G, LTE oder verschiedene WLAN-Netze).



Nun versuche ich das gleiche aus einem großen Netzwerk heraus und habe damit Probleme: die VPN-Verbindung lässt sich in allen Fällen herstellen. Danach ist aber keine der Adressen im Zielnetz erreichbar (auch kein Ping). Wenn ich am IPhone einen Netzwerkscan bei aktiver VPN-Verbindung mache, bringt er mir auch nicht wie sonst üblich die Frage, ob ich das WLAN oder das VPN scannen will, sondern scannt direkt das WLAN. Wenn ich in die Einstellungen gehe, sehe ich, dass eine private IP des VPN-Netzwerkes wie gewünscht zugewiesen wurde.



Woran kann das liegen? Ich hatte soetwas noch nie. Entweder VPN geht garnicht durch (z.B. wegen Portsperrungen) - oder die Verbindung kann hergestellt werden und dann komme ich aber auch auf die IP-Adressen im Zielnetz. Oder liegt hier ein Adresskonflikt vor? (WLAN-IP: 134.xx.xxx.xxx / VPN-IP der Fritzbox: 192.168.110.XXX). Oder ein NAT-Problem? PPTP zu einem Windows-Server funktioniert übrigens.



Danke für Eure Einschätzungen!

 

[PeterPawn]

http://www.ip-phone-forum.de/showthread.php?t=281439 eventuell?

Was genau mit dem FRITZ!Fernzugang-Client nicht funktioniert (bzw. ob der überhaupt auch von dem Problem betroffen ist), wird für mich nicht wirklich klar anhand von #1.

 

[Canni]

Damit sollte es nichts zu tun haben, u.a. gibt es dort m.W.n. auch kein Unitymedia. Wer hat noch eine Idee?

 

[PeterPawn]

Nun muß ja aber das Taggen von IP-Paketen mit ECN=3 (also CE) nicht unbedingt auf Unitymedia beschränkt sein, die werden die Geräte für ihr Kern-Netz ja auch nicht daheim in Handarbeit klöppeln. Also muß es irgendwelche Geräte (vermutlich von einem größeren Netzwerkausrüster) geben, die so eine Einstellung zumindest erlauben, wenn sie sie nicht unter gewissen Umständen sogar forcieren. Warum das bei dem von Dir frequentierten Netz nicht auch der Fall sein könnte (dazu hast Du ja nichts geschrieben, ob das nun ein kleines Netz für 3 Mann oder eine Firma mit 2000 Clients ist, das müssen wir raten, auch wenn es nach einem größeren Netz "klingt"), kann ich zwar nicht sehen (dafür sind die Infos auch tatsächlich zu spärlich oder ungenau in meinen Augen), aber Du wirst ja Deine Gründe haben.

Die Aussage "Unitymedia ist nicht involviert." hat ja mit dem Inhalt des Threads (den Du ja sicherlich wenigstens in Ansätzen gelesen hast) nur insofern zu tun, als daß UM ebenfalls (offenbar immer) mit ECN=CE taggt und das - i.V.m. passenden iOS-Versionen - als das eigentliche Problem herausgearbeitet wurde.

Vielleicht fällt Dir ja doch sogar noch etwas dazu ein, ob Du überhaupt iOS 9 einsetzt und/oder ob der Client von AVM nun funktioniert oder nicht - am Ende bin ja u.U. auch nur ich zu blöd, um das aus #1 abzulesen, aber das eine (kein iOS 9 auf dem iPhone) wie das andere (wenn der AVM-Client auch nicht funktioniert, wobei hier schon wieder andere Faktoren im Spiel sein könnten) wäre tatsächlich eine valide Begründung, warum das Problem woanders liegen sollte. Wenn ich nur zu beschränkt bin, um das aus #1 klar abzulesen, dann wird mich sicherlich einer der Mitstreiter hier auch aufklären. Ansonsten füge ich mich Deinem "Wunsch" und sage auch meinerseits: Der Nächste bitte.

Solltest Du es Dir noch einmal durch den Kopf gehen lassen wollen (und die zwei Fragen oben passend beantworten müssen), gäbe es in dem verlinkten Thread sogar einen Workaround, den man ja einfach mal ausprobieren könnte ... funktioniert der nicht, hast Du natürlich von vorneherein vermutlich richtig gelegen.

 

[Canni]

Vielen Dank für Deine ausführliche Antwort. Das verlinkte Problem ist mir vom Lesen her in der Tat einigermaßen bekannt, wurde ja auch vor einigen Wochen bereits auf Heise und Co. berichtet.

Ich habe das Problem aber bereits mit einem "Uralt-IPad" unter iOS 5.1.1 nachgestellt - und dort tritt es exakt ebenfalls so auf, wie unter meinem aktuellen Gerät unter iOS 9.0.2. Damit dürfte die verlinkte Problematik doch ausgeschlossen sein?

Ich bin leider absolut ratlos im Moment. Werde mich sicher noch an das Rechenzentrum wenden, allerdings ist es da bestimmt von Vorteil, wenn man ggf. einen Lösungsansatz nennen könnte. Würdet ihr das eigene IP-Netz (VPN) mal' verändern - oder wird das keinen Erfolg bringen? Seht ihr das Problem in Sperren des Netzwerkes? Danke Euch!

 

[PeterPawn]

Wenn es in beiden Fällen (iPad und iPhone) tatsächlich dieselbe Ursache ist, kann man das sicherlich ausschließen ... aber Du schreibst doch selbst, daß es mit dem AVM-Client und dem iPhone immer funktioniert hat, woraus ich jetzt lesen würde, daß Du es nicht regelmäßig mit dem iPad benutzt hast, sondern erst nachträglich zur Eingrenzung des Fehlers und da wäre es dann wieder wissenswert, ob die VPN-Konfiguration des iPads auch "neu" ist oder definitiv vorher auch schon funktionierte bzw. aus einem anderen Netz nach wie vor funktioniert.

Der AVM-Client würde das dann "endgültig" klären ... geht der ebenfalls nicht, kann man das ECN-Problem (die Meinungen, ob das mit dem bisher auch "in der Presse" berichteten VPN-Problem der neuen Apple-OS deckungsgleich ist, gehen auch in dem verlinkten Thread auseinander) tatsächlich aus den möglichen Ursachen entlassen - wenn ich das richtig verstehe.

Ansonsten könnte ich mir noch ein Border-Gateway vorstellen, was in einer größeren Installation "deep packet inspection" machen will und daher versucht, sich in so ziemlich jede Verbindung einzuklinken. Das geht bei VPN-Verbindungen naturgemäß (und hoffentlich zu 100%) schief ... aber selbst wenn beim AVM-VPN (IKEv1 mit "aggressive mode") keine Authentifizierung der Gegenstelle stattfindet bzw. die nur über den PSK erfolgt, sollte trotzdem nicht mal Phase1 des IKE erfolgreich abgeschlossen werden und dann dürfte kein Client die Verbindung als "aufgebaut" ansehen - was dann, nach meinem Verständnis, den Anzeigen Deiner Geräte widerspricht.

Solange das VPN wie berichtet aus anderen Netzen nach wie vor erreichbar ist und funktioniert, würde ich keine einzige Einstellung an der FRITZ!Box ändern. Erst einmal wieder die Ursache in aller Ruhe ermitteln (wenn der AVM-Client auch streikt, ist ein Wireshark auf dem PC ja das ideale Werkzeug, ansonsten verkraftet das alte iPad bestimmt auch ein Jailbreak für ein "tcpdump") und dann irgendetwas ändern ... solche Aktionen "auf Verdacht", bei denen die Leute dann nicht wieder auf "Los" gehen und die Hälfte der testweise geänderten Einstellungen "überleben", machen nach meiner Erfahrung die Sache nicht wirklich besser.

 

[Canni]

Vielen Dank, PeterPawn!

In der Tat kann man das aktuelle ECN-Problem "entlassen", da a) auch der Windows-Client betroffen ist und b) ebenfalls das "Uralt-IPad".

Wie wir gerade per PN geschrieben haben, deutet es wirklich darauf hin, dass das Problem von der öffentlichen IP-Adresse, die ich im problematischen WLAN zugewiesen bekomme, herrührt. Welche Abhilfe kann man hier (insbesondere vom IPhone aus) schaffen? Ggf. macht es ja auch Sinn, mal' AVM anzuschreiben, die sollten hierzu doch auch Abhilfe wissen, sofern das Problem wirklich im fehlenden NAT zu suchen ist. Vielen Dank!!

 

[Canni]

Weiss niemand weiter?

Es muss etwas mit NAT zu tun haben.

Im problematischen Netzwerk, von dem aus ich keine VPN-Verbindung zu meiner Fritzbox hinbekomme, ist die zugewiesene WLAN-IP-Adresse gleichzeitig die öffentliche Adresse - es gibt dort kein NAT (die scheinen genügend IP-Adressen zu haben).

Ich konnte nun zumindest die Verbindung aus dem fremden WLAN zu meinem VPN unter Windows herstellen, indem ich im Shrew Soft VPN-Client die Einstellung "NAT Traversal" von "enable" auf "force-rfc" gestellt habe!

Wie kann ich nun den IPSec-Client vom IPhone dazu bringen, sich ebenfalls zu verbinden? Welche Einstellung könnte dort helfen?

Vielen Dank!!

 

[PeterPawn]

Meines Wissens kann man es weder beim iOS-Client noch bei der FRITZ!Box "erzwingen", die erkennen das in einer Verbindung daran, daß ein Hash der "gegnerischen" IP-Adresse und des Ports - mit einem "Cookie" vermischt, damit das nicht vorherberechnet werden kann - gesendet wird in einem Paket. Stimmt das auf der Gegenseite mit der eigenen Vorstellung überein, über welche Adresse und welchen Port man selbst Verbindung zur Gegenstelle hält, ist da kein NAT-Router dazwischen und man bleibt bei UDP/500 und ESP als gesondertem Protokoll auf L4. Das scheitert dann auch schon mal an einem Router, der kein NAT macht.

Der Shrewsoft-Client wird einfach bei "force" hingehen und seinerseits behaupten, daß die bei ihm angekommene Adresse nicht stimmt (egal, ob das wahr ist oder nicht) und dann landen am Ende beide doch bei UDP/4500 als einziger Voraussetzung. Außer einer kompletten Blockade von UDP/500 im Router (dann sollte ISAKMP automatisch 4500 probieren), sehe ich auch nicht, was da der Admin des Netzes mit den öffentlichen IPs machen sollte.

Event. könntest Du noch probieren, bei Deiner FRITZ!Box die Freigabe für UDP/500 zu blockieren (die wird aber automatisch wieder eingerichtet bei Änderungen), indem Du die vpn.cfg änderst (ganz unten sind die Firewall-Freigaben). Wenn dann der iOS-Client bei ausbleibender Antwort auf 500 auch auf 4500 probiert, könnte das funktionieren.

 

[Canni]

Hallo PeterPawn,

dieses Problem fuchst mich! Deine Idee ist ja klasse, sie ließ sich aber nicht umsetzen bzw. testen: die FritzBox ändert den entsprechenden Bereich in der vpn.cfg sofort(!), ebenfalls ist auch keine Modifikation via FBEditor möglich.

Welche Möglichkeiten bleiben mir noch? Kann es wirklich sein, dass die FritzBox nicht mit eingehenden VPN-Verbindungen klarkommt, wenn öffentliche IP = private IP ist? Ich sehe nur dies als Problem, es muss etwas mit dem (fehlenden) NAT zu tun haben.

 

[PeterPawn]

Zumindest für einen Test sollte das Ändern der vpn.cfg über eine Shell ausreichend sein (ctlmgr beenden, vpn.cfg ändern, reboot) ... erst wenn man weiß, ob diese Änderung hilfreich wäre, kann man sich überlegen, wie man das "änderungsfest" oder sogar "restart-fest" hinbekommt. Sich darüber Gedanken zu machen, wenn die Änderung ohnehin nichts bringt, wäre verschwendete Energie.

EDIT: Falls das nicht klar hervorging aus meinem Text ... diese "sofortige Änderung" seitens des FRITZ!OS erscheint mir eher unwahrscheinlich (in gewissen Grenzen). Wenn ich über die vpn.cfg eine weitere Portweiterleitung hinzufüge, bleibt diese erhalten und überlebt auch einen Restart vollkommen problemlos. Nun mag das tatsächlich für die beiden "Standard-Weiterleitungen" anders geregelt sein, das habe ich nicht getestet ... nach bisherigen Erfahrungen beruhen solche Berichte in aller Regel aber doch auf der falschen Anwendung der Werkzeuge oder sogar auf falschen Werkzeugen für solche Änderungen. Das kann man halt in Deinem Falle nicht exakt einschätzen, damit aber auch nicht per se ausschließen.

EDIT2: Die Frage mit der mangelnden Fähigkeit der FRITZ!Box mit öffentlichen Adressen für Gegenstellen umzugehen, kann ich definitiv verneinen. Das Problem ist sicherlich eher der "reine ESP-Verkehr", der als gesondertes IP-Protokoll bei einer solchen Konfiguration verwendet wird ... ich würde eher in der Konfiguration des entfernten Netzes (bzw. in dessen Firewall/Gateway) suchen. Das mag auf den ersten Blick wie ein Widerspruch zu früheren Empfehlungen aussehen, da ging es aber um realistische(!) Szenarien, wie Du das in den Griff bekommen könntest.
Meine 7490 macht(e) jedenfalls problemlos eine VPN-Verbindung zu einer "racoon"-basierten IPSec-Installation auf einem Linux-Server (OpenSuSE) auf, sowohl mit als auch ohne NAT-T (da kann man von der Serverseite dann noch "force NAT-T" erzwingen, deshalb konnte ich das testen).

 

[chmars]

Allenfalls NAT444?

 

[PeterPawn]

Allenfalls NAT444?

:gruebel:
Den Zusammenhang verstehe ich nicht ... wenn CGN oder LSN am Anschluß mit der FRITZ!Box verwendet würde, käme ja auch aus einem anderen Netzwerk keine Verbindung dorthin zustande.

Beim Netzwerk, aus dem heraus der Kontakt nicht möglich ist, kann man CGN m.W. auch ausschließen, dort sollten schon "richtige öffentliche Adressen" verwendet werden (es gibt halt auch heute noch "Firmen", die aus historischen Gründen recht große Zuteilungen von der RIPE haben).

 

[Canni]

NAT444 trifft hier sicher nicht als Problem zu, da "falsche Seite".

@PeterPawn: danke Dir vielmals.

Ich habe als "Werkzeug" einmal den normalen vpn.cfg-Import genutzt und einmal den FBEditor. Wie ctlmgr ohne Freeze funktionieren soll, weiß ich nicht, da Telnet ja in Fritz!OS abgeschafft wurde.

Es stimmt, wenn man eine Portweiterleitung hinzufügt, bleibt diese erhalten und überlebt auch einen Neustart - dies konnte ich auch nachstellen. Eine Änderung an den beiden vorhandenen Regeln akzeptiert die FritzBox aber, wie oben geschrieben, leider nicht.

Wie würdest Du an meiner Stelle weiter verfahren? Wo liegt Deiner Meinung nach das Problem? Wenn im WLAN-Netzwerk: warum dort? Warum komme ich mit "force-rfc" über Shrew Soft durch und mit dem VPN-Clienten des IPhone nicht? Gibt es etwas, was ich beim WLAN-Netzwerkbetreiber anfragen könnte bzw. worum ich die bitten sollte? Oder wäre Kontakt mit AVM hilfreich?

Bitte um Hilfe!

 

[PeterPawn]

Telnet läßt sich auch ohne Freetz-Image wieder reaktivieren - wie groß der Aufwand ist, hängt vom Modell der Box ab, dazu bist Du aber schon auf der richtigen Internet-Site.

Das mit dem "Abschalten" der Portweiterleitung probiere ich jetzt nicht selbst ... wenn das tatsächlich nicht möglich ist, könnte man versuchen, den Port durch ein vorher gestartetes Programm zu blockieren. Ich könnte es mir tatsächlich vorstellen, daß das gesondert aktiviert wird vom avmike ... aber warum braucht es dann überhaupt die Eintragungen in der vpn.cfg bzw. warum funktioniert das Hinzufügen darüber? Selbst eine Verwendung des GUI-Assistenten verkraftet ja so ein zusätzlicher Eintrag bei den Portfreigaben in der vpn.cfg ... die Frage ist halt, wie sicher Du im Umgang mit den verschiedenen Möglichkeiten des Editierens bist - davon hängt natürlich unmittelbar die Evidenz Deiner Feststellungen ab. Auch andere Tricks, wie das Umleiten von UDP 500 auf einen unbenutzten Port (nirgendwo steht ja, daß UDP 500 auf UDP 500 an der FRITZ!Box-Adresse zeigen muß), könnte man noch probieren ... das setzt aber alles schon für den Test den Telnet-Zugang und auch einige Sicherheit im Umgang mit der FRITZ!Box beim "heimlichen Ändern von Einstellungen" voraus.

Die Erklärung, warum das mit dem ShrewSoft-Client funktioniert, ist eigentlich ziemlich simpel und paßt sich nahtlos in die von Dir eingangs beschriebenen Phänomene ein, die mich ja erst auf ein mögliches Problem mit dem NAT-T schließen ließen.

Bei IPSec ohne NAT-T braucht es für die "Einrichtung" der VPN-Verbindung (Schlüsselaustausch) den UDP-Port 500. Der eigentliche Datenverkehr findet dann über ein gesondertes IP-Protokoll (ESP) statt und das Fehlerbild "Verbindung wird aufgebaut, aber es können keine Daten übertragen werden" ist u.a. typisch für Probleme mit der Übertragung von ESP-Paketen.

Beim IPSec mit NAT-T läuft alles über den UDP-Port 4500. Daher auch der Versuch, die FRITZ!Box und das iPhone über ein Timeout auf Port 500 "auszutricksen" und auf Port 4500 zu hetzen. Der ShrewSoft-Client schaltet eben bei "force-rfc" zwangsweise auf UDP 4500 um (und die Gegenstelle auch, weil der ShrewSoft-Client (vermutlich) einen NAT-Router im Datenweg vortäuscht).

Die Frage an den Admin des WLAN-Netzes ist also, ob dort das ESP-Protokoll irgendwie blockiert wird. Das ist eigentlich die einzige logische Erklärung, ein Packetdump schafft Aufklärung, was da genau passiert.

AVM wird da nichts machen ... auch wenn so ein "erzwungenes NAT-T" schon schön wäre, aber es gäbe wichtigere Baustellen (auch im VPN-Bereich).

 

[Canni]

Vielen Dank für die tolle Erklärung!!

Den Packetdump kann ich nicht selbst erstellen, oder? Meinst Du auf deren Geräten? Oder während des VPN-Versuches mit Wireshark?

Ich werde dort wegen ESP anfragen.

Zwischenzeitlich noch ein weiterer Versuch von mir, den ich hier nicht vorenthalten will:

Zu meinem VPS (Windows Server 2012 R2) habe ich eine L2TP-Verbindung eingerichtet (IPhone). Auch diese lässt sich im "Problemnetzwerk" nicht aufbauen (hier scheitert bereits der Aufbau, während im Ausgangsfall ja die Verbindung hergestellt wird, aber kein Verkehr drüber läuft).

Untermauert das Deine These?

Danke Dir VIELMALS!