20
Linksys WRV200 als VPN Server hinter Mac Airport
Unzähligen Stunden Recherche im Web haben mich leider nicht weitergebracht. Auch hier im Forum sind ein paar ähnliche Themen, die mich aber auch nicht weitergebracht haben.
Hoffe dass mir jemand helfen kann.
Die Situation:
Externe Windows-PCs sollen eine VPN mit dem Netzwerk HOME herstellen, um sich per RDP mit einem Windows Server zu verbinden, der sich im Netzwerk HOME befindet.
Als Router im HOME Netzwerk fungiert eine Mac Timecapsule, also Airport. Dahinter hängt ein Router Linksys WRV200, der lediglich die Funkton des VPN-Servers übernehmen soll.
Der Airport hat die IP 10.0.1.1 und stellt DHCP zur Verfügung.
Beim Linksys habe ich statische WAN IP 10.0.1.1 eingestellt, als eigene IP die 10.0.1.5 vergeben, DHCP deaktiviert. Dann einen VPN-Benutzer angelegt. Im Menü IPSec VPN habe ich schon alle Möglichen Einstellungen probiert, je nach Erklärungen, die ich im Web gefunden habe. Alles ohne Erfolg. Meist kommt die Meldung
"the ip address of remote gateway is conflict with the wan ip address of this router".
1. Wie müssen die Geräte verkabelt werden? Schließe ich den Linksys über die WAN-Buchse oder über eine der Netzwerkbuchen an den Airport an?
Muss der Windows-Server, der per VPN erreichbar sein soll, an den Linksys oder an die TimeCapsule angeschlossen werden?
2. Welche Einstellungen muss ich im Airport vornehmen, insbesondere welche Ports muss ich weiterleiten?
Mein letzter Versuch war:
Öffentliche UDP-Port: 47
Öffentliche TCP-Port: 1723
Private IP-Adresse: 10.0.1.5
Private UDP-Ports: 47
Private TCP-Ports: 1723
3. Wie muss der Linksys konfiguriert werden? D.h. insbesondre welche Interneteinstellung und welche Konfiguration im Menü "IPSec VPN"?
Würde mich sehr freuen, wenn hier jemand helfen kann. Denn wenn nicht hier, wo dann? =-)
Hoffe dass mir jemand helfen kann.
Die Situation:
Externe Windows-PCs sollen eine VPN mit dem Netzwerk HOME herstellen, um sich per RDP mit einem Windows Server zu verbinden, der sich im Netzwerk HOME befindet.
Als Router im HOME Netzwerk fungiert eine Mac Timecapsule, also Airport. Dahinter hängt ein Router Linksys WRV200, der lediglich die Funkton des VPN-Servers übernehmen soll.
Der Airport hat die IP 10.0.1.1 und stellt DHCP zur Verfügung.
Beim Linksys habe ich statische WAN IP 10.0.1.1 eingestellt, als eigene IP die 10.0.1.5 vergeben, DHCP deaktiviert. Dann einen VPN-Benutzer angelegt. Im Menü IPSec VPN habe ich schon alle Möglichen Einstellungen probiert, je nach Erklärungen, die ich im Web gefunden habe. Alles ohne Erfolg. Meist kommt die Meldung
"the ip address of remote gateway is conflict with the wan ip address of this router".
1. Wie müssen die Geräte verkabelt werden? Schließe ich den Linksys über die WAN-Buchse oder über eine der Netzwerkbuchen an den Airport an?
Muss der Windows-Server, der per VPN erreichbar sein soll, an den Linksys oder an die TimeCapsule angeschlossen werden?
2. Welche Einstellungen muss ich im Airport vornehmen, insbesondere welche Ports muss ich weiterleiten?
Mein letzter Versuch war:
Öffentliche UDP-Port: 47
Öffentliche TCP-Port: 1723
Private IP-Adresse: 10.0.1.5
Private UDP-Ports: 47
Private TCP-Ports: 1723
3. Wie muss der Linksys konfiguriert werden? D.h. insbesondre welche Interneteinstellung und welche Konfiguration im Menü "IPSec VPN"?
Würde mich sehr freuen, wenn hier jemand helfen kann. Denn wenn nicht hier, wo dann? =-)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 332091
Url: https://administrator.de/contentid/332091
Printed on: April 24, 2024 at 14:04 o'clock
20 Comments
Latest comment
Zitat von @knubbie:
Der Airport hat die IP 10.0.1.1 und stellt DHCP zur Verfügung.
Beim Linksys habe ich statische WAN IP 10.0.1.1 eingestellt
Der Airport hat die IP 10.0.1.1 und stellt DHCP zur Verfügung.
Beim Linksys habe ich statische WAN IP 10.0.1.1 eingestellt
Jetzt mal Butter bei die Fische, das erkennst du doch selber, oder? Und der Linksys sagt es dir sogar auch :D
Stimmt ! Das kann logischerweise niemals so gehen, denn so hat der TO eine doppelte IP vergeben. Das ist Grundschule IP Adressierung erste Klasse... Nicht groß verwunderlich das ein VPN damit scheitert.
Die TimeCapsule hat die 10.0.1.1 /24 und der Linksys dann die 10.1.254 /24 ! So wird ein Schuh draus.
Tödlich, denn Netze müssen im IP einzigartig sein....wie gesagt 1.Klasse IP Adressierung... Das geht so nicht. Das lokale LAN müsste dann sowas wie 10.0.2.0 /24 haben. Auf alle Fälle ein anderes IP Netz.
Grundlagen zu Routerkaskaden auch hier im Forum:
Kopplung von 2 Routern am DSL Port
Leider ist auch der Rest der Beschreibung recht oberflächlich, denn der TO hat versäumt mitzuteilen mit welchem der zahllosen VPN Protokolle er denn gedenkt den VPN Tunnel zu realisieren.
Wenn es die onboard Clients bei Winblows sind bleibt eigentlich ja nur L2TP oder PPTP was aber jetzt nur geraten ist.
Durch den Betrieb der Routerkaskade muss dann zwangsläufig auf dem davor liegenden Router die entsprechenden VPN Ports per Port Forwarding auf den dahinter kaskadierten VPN Router geforwardet werden. Hier dann im Beispiel die 10.0.1.254.
Bei PPTP ist das das GRE Protokoll (IP Nummer 47) und TCP 1723. Bei L2TP, ESP (IP Nummer 50) sowie UDP 500, 4500 und UDP 1701
https://technet.microsoft.com/en-us/library/dd458955(v=ws.10).aspx
Solche Recherchen findet man eigentlich schon nach mindestens 15 Minuten im Netz. Stunden der Recherche sollten solche banalen Grundlagen eigentlich umfassend klären. Fragt sich wo der TO gesucht hat danach..?!
Aber egal...mit sauberer IP Adressierung kommt das sofort zum Fliegen.
Die Timecapsule hat kein integriertes xDSL oder Kabelmodem. Hier stellt sich dann auch die Frage wie sie denn final beim TO ans Internet angebunden ist ?? So direkt per Ethernetport wird das ja schwerlich klappen.
Irgendeine Art Modem muss ja deshalb noch an ihr dran sein, es sei denn der TO hat direkt Glasfaser (FTTH) mit einem Kupferport....
Grundlagen zum VPN Betrieb mit PPTP findet man ansonsten hier:
VPNs einrichten mit PPTP
Die TimeCapsule hat die 10.0.1.1 /24 und der Linksys dann die 10.1.254 /24 ! So wird ein Schuh draus.
als eigene IP die 10.0.1.5 vergeben
Auch das ist verwirrend und vermutlich ebenso falsch ! Was soll das sein? Das lokale LAN am Linksys ?? Das wäre dann ein weiterer Fehler in der IP Adressierung, denn damit hätte man das gleiche IP Netz wie an der TimeCapsule also 2mal 10.0.1.0 /24.Tödlich, denn Netze müssen im IP einzigartig sein....wie gesagt 1.Klasse IP Adressierung... Das geht so nicht. Das lokale LAN müsste dann sowas wie 10.0.2.0 /24 haben. Auf alle Fälle ein anderes IP Netz.
Grundlagen zu Routerkaskaden auch hier im Forum:
Kopplung von 2 Routern am DSL Port
Leider ist auch der Rest der Beschreibung recht oberflächlich, denn der TO hat versäumt mitzuteilen mit welchem der zahllosen VPN Protokolle er denn gedenkt den VPN Tunnel zu realisieren.
Wenn es die onboard Clients bei Winblows sind bleibt eigentlich ja nur L2TP oder PPTP was aber jetzt nur geraten ist.
Durch den Betrieb der Routerkaskade muss dann zwangsläufig auf dem davor liegenden Router die entsprechenden VPN Ports per Port Forwarding auf den dahinter kaskadierten VPN Router geforwardet werden. Hier dann im Beispiel die 10.0.1.254.
Bei PPTP ist das das GRE Protokoll (IP Nummer 47) und TCP 1723. Bei L2TP, ESP (IP Nummer 50) sowie UDP 500, 4500 und UDP 1701
https://technet.microsoft.com/en-us/library/dd458955(v=ws.10).aspx
Solche Recherchen findet man eigentlich schon nach mindestens 15 Minuten im Netz. Stunden der Recherche sollten solche banalen Grundlagen eigentlich umfassend klären. Fragt sich wo der TO gesucht hat danach..?!
Aber egal...mit sauberer IP Adressierung kommt das sofort zum Fliegen.
Die Timecapsule hat kein integriertes xDSL oder Kabelmodem. Hier stellt sich dann auch die Frage wie sie denn final beim TO ans Internet angebunden ist ?? So direkt per Ethernetport wird das ja schwerlich klappen.
Irgendeine Art Modem muss ja deshalb noch an ihr dran sein, es sei denn der TO hat direkt Glasfaser (FTTH) mit einem Kupferport....
Grundlagen zum VPN Betrieb mit PPTP findet man ansonsten hier:
VPNs einrichten mit PPTP
okay, schon gut. Bin als Laie entlarvt 
Um so größeren Dank für eure Antworten!
Habe auch ehrlich gesagt nicht nach den Zusammenhängen und dem Hintergrundwissen gegoogelt, sondern nach einer Step-by-step Anleitung. Davon habe ich mehrere gefunden, besonders bei YouTube, aber keine traf 1:1 auf meine Situation zu. Und meine „Anpassungen“ dieser Anleitungen sind mangels Grundlagenwissen natürlich gescheitert.
Zu den Fragen von aqui:
- Die Timecapsule ist an ein Kabelmodem angeschlossen.
- PPTP VPN möchte ich nicht nehmen, da es mit dem aktuellen Apple iOS nicht mehr kompatibel ist. Und scheinbar ist es ja nach aktuellen stand auch nicht so sicher.
Der Linksys ist jetzt mit einem der 4 Netzwerkbuchsen mit der Timecapsule verbunden
Im Linksys unter „Setup“ habe ich folgeldes eingetragen:
Im Menü „VPN Client Access“ habe ich einen Unser angelegt:
Im Menü „IPSec VPN“ habe das eingetragen:
Alles richtig so?
Was in der der Timcapsule eingetragen werden soll, ist mir noch nicht klar.
Wenn ich im Pulldownmenü „Server VPN - L2TP“ auswähle, ist bei Öffentliche UDP-Port und Private UDP-Ports automatisch 1701 eingetragen.
Bei Öffentliche TCP-Port und Private TCP-Ports habe ich dann noch 50 eingetragen und bei Private IP-Adresse 10.0.1.254.
Ist das so korrekt?
Und was und wo muss ich mit den Ports 500 und 4500 machen?
Eine VPN Verbindung lässt sich so auf jeden Fall noch nicht herstellen.
Noch was:
Wenn ich mich mit einem PC in das WLAN vom Linksys eingeloggt bin, kann ich die Linksys-Oberfläche mittels Browser unter 10.0.2.1 aufrufen. Internetseiten kann ich jedoch keine erreichen, ebenso keine Geräte im IP-Kreis 10.0.1.X.
Und wie erreiche ich die Linksys-Obrfläche, wenn ich am Timecapsule eingeloggt bin? Unter 10.0.1.254 geht es nicht.
Um so größeren Dank für eure Antworten!
Habe auch ehrlich gesagt nicht nach den Zusammenhängen und dem Hintergrundwissen gegoogelt, sondern nach einer Step-by-step Anleitung. Davon habe ich mehrere gefunden, besonders bei YouTube, aber keine traf 1:1 auf meine Situation zu. Und meine „Anpassungen“ dieser Anleitungen sind mangels Grundlagenwissen natürlich gescheitert.
Zu den Fragen von aqui:
- Die Timecapsule ist an ein Kabelmodem angeschlossen.
- PPTP VPN möchte ich nicht nehmen, da es mit dem aktuellen Apple iOS nicht mehr kompatibel ist. Und scheinbar ist es ja nach aktuellen stand auch nicht so sicher.
Der Linksys ist jetzt mit einem der 4 Netzwerkbuchsen mit der Timecapsule verbunden
Im Linksys unter „Setup“ habe ich folgeldes eingetragen:
Im Menü „VPN Client Access“ habe ich einen Unser angelegt:
Im Menü „IPSec VPN“ habe das eingetragen:
Alles richtig so?
Was in der der Timcapsule eingetragen werden soll, ist mir noch nicht klar.
Wenn ich im Pulldownmenü „Server VPN - L2TP“ auswähle, ist bei Öffentliche UDP-Port und Private UDP-Ports automatisch 1701 eingetragen.
Bei Öffentliche TCP-Port und Private TCP-Ports habe ich dann noch 50 eingetragen und bei Private IP-Adresse 10.0.1.254.
Ist das so korrekt?
Und was und wo muss ich mit den Ports 500 und 4500 machen?
Eine VPN Verbindung lässt sich so auf jeden Fall noch nicht herstellen.
Noch was:
Wenn ich mich mit einem PC in das WLAN vom Linksys eingeloggt bin, kann ich die Linksys-Oberfläche mittels Browser unter 10.0.2.1 aufrufen. Internetseiten kann ich jedoch keine erreichen, ebenso keine Geräte im IP-Kreis 10.0.1.X.
Und wie erreiche ich die Linksys-Obrfläche, wenn ich am Timecapsule eingeloggt bin? Unter 10.0.1.254 geht es nicht.
Der Linksys ist jetzt mit einem der 4 Netzwerkbuchsen mit der Timecapsule verbunden
Das ist richtig...Im Linksys unter „Setup“ habe ich folgeldes eingetragen:
Hier hast du einen gravierenden Fehler gemacht !Dir hätte sofort ins Auge springen müssen das der DHCP Server des lokalen LANs eine falsche IP Range konfiguriert hat ! (192.168....)
Hier muss stehen: Start: 10.0.2.100, Number of Addresses: 100 !
Dann passt das auch !
Im Menü „IPSec VPN“ habe das eingetragen:
Auch hier hast du einen Fehler gemacht ! Den "Mode" solltest du zwingen statt Main auf Agressive schalten !Alles richtig so?
Bis auf die obigen beiden Kincken, ja !Was in der der Timcapsule eingetragen werden soll, ist mir noch nicht klar.
Warum nicht ?? Denk doch mal logisch nach...!!Du bist jetzt irgendwo im Internet und startest deinen IPsec VPN Client weil du auf deinen VPN Router zugreifen willst. Das VPN Protokoll ist ja IPsec wie man unschwer am Linksys erkennt.
Also IPsec VPN Client gestartet.... Der will jetzt eine Tunnel IP wissen und Username Passwort.
Die Tunnel IP muss ja logischerweise eine öffentliche IP Adresse sein die über das Internet erreichbar ist.
Die IP Adresse des Linksys mit der 10.0.1.254 ist das ja schonmal NICHT, denn das ist eine private RFC 1918 IP Adresse die NICHT im Internet geroutet wird !!
https://de.wikipedia.org/wiki/Private_IP-Adresse
Es kann also einzig nur die IP Adresse sein die am WAN Port der TimeCapsule anliegt.
Das ist die Provider IP ! Die kannst du im Setup der TimeCapsule sehen oder noch einfacher wenn du mit einem Client im lokalen Netz mal auf http://www.wieistmeineip.de oder http://myexternalip.com/raw surfst.
Dann siehst du die öffentliche IP die du dem Client als Ziel IP definieren musst für den Tunnel und die er über das Internet erreichen kann.
Die 10.0.1.254 kann er ja nicht erreichen, da diese ja hinter der NAT (IP Adress Translation) Firewall der TimeCapsule hängt und so unerreichbar ist.
Jetzt kommt das Port Forwarding der TimeCapsule ins Spiel !! Diese empfängt ja alle Client VPN Pakete da sie durch die öffentliche IP ja an sie gerichtet sind.
Anfangen kann sie aber nix damit, da sie ja kein IPsec VPN kann. Logisch, denn dafür hast du ja richtigerweise den Linksys beschafft.
Du musst also jetzt an der TimeCapsule dafür sorgen das diese ALLE IPsec relevanten IP Pakete dann an den Linksys und damit die 10.0.1.254er IP forwardet.
Du erinnerst dich ?? Die Protokollkomponenten von IPsec sind:
Port UDP 500 = IKE Protokoll
Port UDP 4500 = NAT Traversal Protokoll
IP Protokoll Nummer 50 = ESP Protokoll was den eigentlichen Tunnel mit den Produktivdaten realisiert.
Diese 3 Komponenten musst du also nun per Port Forwarding:
UDP 500 --> 10.0.1.254
UDP 4500 --> 10.0.1.254
ESP --> 10.0.1.254
forwarden.
Die Timecapsule schickt dann alle Daten dieser 3 definierten Protokollkomponenten weiter auf den Linksys Router wo sie dann entsprechend verarbeitet werden und der VPN Tunnel dann zum Client aufgebaut wird.
Eigentlich doch ganz einfach, oder ??
Man muss nur einmal ein klein wenig logisch nachdenken wie sich Daten und Pakete im Netzwerk und Internet bewegen.
Dein Szenario ist also ein simples Allerweltsdesign im VPN Umfeld und Millionen Nutzer lösen das so mit einer Router Kaskade !
Und was und wo muss ich mit den Ports 500 und 4500 machen?
Das ist mit der o.a. Erklärung dir nun hoffentlich durch und durch klar geworden, oder ?Bei de Ports müssen in der TC per Port Forwarding auf die lokale IP 10.0.1.254 geforwardet werden.
Bedenke auch das UDP 500 und 4500 nur die halbe Miete ist !!! Noch viel wichtiger ist das ESP Protokoll was ebenso geforwardet werden muss sonst klappt es nicht. ALLE erforderlichen IPsec Prtokollkomponenten muss die TC an den Linksys forwarden. Klar denn mit nur 3 Rädern kann man nicht Auto fahren...
Eine VPN Verbindung lässt sich so auf jeden Fall noch nicht herstellen.
Logisch ! Das warum kennst du ja jetzt !Wenn ich mich mit einem PC in das WLAN vom Linksys eingeloggt bin, kann ich die Linksys-Oberfläche mittels Browser unter 10.0.2.1 aufrufen.
Klar, denn wenn du am PC mal mit ipconfig in der Eingabeaufforderung nachsiehst, dann wirst du sehen das du eine 10.0.2.x IP Adresse bekommen hast !Natürlich nur wenn du deinen obigen Fehler mit dem falschen DHCP Range 192.168.1.x korrigiert hast auf 10.0.2.x !!
Du bist dann also im gleichen LAN wie die LAN IP des Linksys...alles richtig also.
Internetseiten kann ich jedoch keine erreichen
Ooops... ! Das darf nicht sein ! Internet sollte auch aus dem IP Netz fehlerlos klappen.Dann stimmt irgendwas noch nicht mit der IP Adressierung am WAN Port bzw. zur Time Capsule !
Eigentlich ist das Setting oben genau richtig.
IP: 10.0.1.254, Maske: 255.255.255.0, Gateway: 10.0.1.1, DNS: 10.0.1.1 das ist soweit alles korrekt.
Ggf. nach den einstellungen UND Korrektur des DHCP Bereich den Linksys mal rebooten !
Ist die TC denn wirklich über 10.0.1.1 zu erreichen ?
Der Linksys hat eine Ping Funktion unter Status. Kannst du die TC dort mit ihrer 10.0.1.1 anpingen ?
Nochwas wichtiges. Du schreibst:
Die Timecapsule ist an ein Kabelmodem angeschlossen.
Ist das wirklich ein reines Modem und KEIN Router ??Das kannst du daran sehen das die TC am WAN Port eine öffentliche IP Adresse bekommen hat und KEINE private RFC 1918 IP.
Siehe oben http://myexternalip.com/raw muss die IP sein die du in der TC am WAN Port siehst. Ist sie das nicht dann ist dein Modem davor kein Modem sondern ein Router.
Ein reines Modem macht nur eine passive Medienwandlung hat aber mit dem IP Forwarding an sich nichts zu tun. Ganz im Genesatz zu einem NAT Router.
Ist letzteres der Fall ist das Modem de facto KEIN Modem sondern auch ein NAT Router und du hättest dann eine tödliche 3fach Kaskade. Das wäre dann natürlich sinnfrei.
Dann macht es sinn die TC nur als reinen Accesspoint zu betreiben. Und nur die beiden Router zu kaskadieren.
Also...sicher klären ob dein Modem wirklich ein reines Modem ist und kein NAT Router !!!
Das Problem musst du zuallererst lösen. Internet Zugriff aus dem lokalen LAN des Linksys MUSS in jedem Falle möglich sein ! Bevor das nicht geht musst du mit dem VPN gar nicht erst weitermachen, denn das zeigt das da noch was im Argen mit der Verkabelung oder der IP Adressierung ist.
P.S.: Wieso hast du selber den Thread auf "gelöst" geklickt ?? Ist der jetzt denn gelöst ?? Wenn ja, was war das Problem ?
Vielen Dank für die ausführlichen Erklärungen und Links. Das ist für mich alles sehr aufschlussreich.
Im Linksys hatte ich die richtige IP Range schon eingetragen also Start: 10.0.2.100. War nur ein falscher screenshot, von meinen vorangegangenen „Experimenten“.
Allerdings hatte ich Number of Addresses: 155, statt 100. Ich denke, es macht keinen Unterschied, weil ich ja keine Adresse oberhalb 10.0.2.200 manuell vergeben habe, richtig?
Ich habe ich aber jetzt auf 100 geändert.
Im Menü „IPSec VPN“ habe ich den "Mode" von Main auf Agressive geädert. Was genau bewirkt das denn?
Bei dem Modem handelt es sich um ein Cisco EPC 3208.
Also wirklich ein reines Kabelmodem ohne Router.
Die Web-Oberfläche vom Linksys kann ich nur erreichen, wenn ich im WLAN vom Linksys eingeloggt bin. Nachdem was ich jetzt gelernt habe, ist das für mich logisch, denn ich bekomme ja von der Timecapsule eine 10.0.1.X IP zugewiesen und der linksys hat ja 10.0.2.1. Aber wie kann ich die Weboberfläche denn erreichen, wenn ich im WLAN der Timecapsule eingeloggt bin?
Irgendwas stimmt auf jeden Fall noch nicht. Manches Verhalten kommt mir willkürlich oder sporadisch vor.
Wenn ich im WLAN der Timecapsle eingeloggt bin, sehe ich alle Geräte aus diesem IP Kreis.
Hier sieht man übrigens auch, dass die Timecapsule tatsächlich die IP 10.0.1.1 hat.
Sobald ich mich ins WLAN vom Linksys eingelogge, hat die Timecapsule keine Internetverbindung mehr.
Außerdem hat der Mac immer noch die IP vom WLAN der Timecapsule.
Die Weboberfläche des Linksys kann ich über 10.0.2.1 aber trotzdem erreichen.
Per Ping-Funktion des linksys ist die Timecapsule nicht erreichbar
Wenn ich mich dann wieder in das WLAN der Timecapsule eingelogge, ändert das MANCHMAL! zunächst auch nichts, also die Timecapsule hat auch dann keine Internetverbindung und es werden keine Geräte im LAN gefunden, außer der Mac.
In der Timcapsule sind 2 WLAN konfiguriert, eins als 2,4 und eins als 5GHz. Mit gleichen Einstellungen. Wenn ich zwischen diesen ein par mal hin und her schalte, hat die Timecapsule irgendwann wieder eine Internetverbindung.
Es passiert manchmal auch, dass die Timecapsule zwar mit dem Internet verbunden ist, aber die Timecapsule selbst wird nicht gefunden.
Vielen Dank auch für die super Erklärung über das Port Forwarding. Das habe ich jetzt noch nicht probiert, denn wie du geschrieben hast, bringt es ja natürlich nichts, solange der Linksys keine Interntanbinung hat.
Über 3 Punkte bin ich aber schon gestolpert.
1. Ich finde nirgends „ESP“
2. Muss ich nicht auch 1701 vorwarden?
3. Es gibt Felder für „öffentliche“ und „privat“. Muss ich die Eintragung i n beiden machen?
Wäre es am Beispiel von ISAKMP/IKE so richtig?
Ich wüsste nicht, das ich im Thread auf "gelöst" geklickt habe. Viellecht unbeabsichtigt
Wie kann ich das denn rückgängig machen?
Im Linksys hatte ich die richtige IP Range schon eingetragen also Start: 10.0.2.100. War nur ein falscher screenshot, von meinen vorangegangenen „Experimenten“.
Allerdings hatte ich Number of Addresses: 155, statt 100. Ich denke, es macht keinen Unterschied, weil ich ja keine Adresse oberhalb 10.0.2.200 manuell vergeben habe, richtig?
Ich habe ich aber jetzt auf 100 geändert.
Im Menü „IPSec VPN“ habe ich den "Mode" von Main auf Agressive geädert. Was genau bewirkt das denn?
Bei dem Modem handelt es sich um ein Cisco EPC 3208.
Also wirklich ein reines Kabelmodem ohne Router.
Die Web-Oberfläche vom Linksys kann ich nur erreichen, wenn ich im WLAN vom Linksys eingeloggt bin. Nachdem was ich jetzt gelernt habe, ist das für mich logisch, denn ich bekomme ja von der Timecapsule eine 10.0.1.X IP zugewiesen und der linksys hat ja 10.0.2.1. Aber wie kann ich die Weboberfläche denn erreichen, wenn ich im WLAN der Timecapsule eingeloggt bin?
Irgendwas stimmt auf jeden Fall noch nicht. Manches Verhalten kommt mir willkürlich oder sporadisch vor.
Wenn ich im WLAN der Timecapsle eingeloggt bin, sehe ich alle Geräte aus diesem IP Kreis.
Hier sieht man übrigens auch, dass die Timecapsule tatsächlich die IP 10.0.1.1 hat.
Sobald ich mich ins WLAN vom Linksys eingelogge, hat die Timecapsule keine Internetverbindung mehr.
Außerdem hat der Mac immer noch die IP vom WLAN der Timecapsule.
Die Weboberfläche des Linksys kann ich über 10.0.2.1 aber trotzdem erreichen.
Per Ping-Funktion des linksys ist die Timecapsule nicht erreichbar
Wenn ich mich dann wieder in das WLAN der Timecapsule eingelogge, ändert das MANCHMAL! zunächst auch nichts, also die Timecapsule hat auch dann keine Internetverbindung und es werden keine Geräte im LAN gefunden, außer der Mac.
In der Timcapsule sind 2 WLAN konfiguriert, eins als 2,4 und eins als 5GHz. Mit gleichen Einstellungen. Wenn ich zwischen diesen ein par mal hin und her schalte, hat die Timecapsule irgendwann wieder eine Internetverbindung.
Es passiert manchmal auch, dass die Timecapsule zwar mit dem Internet verbunden ist, aber die Timecapsule selbst wird nicht gefunden.
Vielen Dank auch für die super Erklärung über das Port Forwarding. Das habe ich jetzt noch nicht probiert, denn wie du geschrieben hast, bringt es ja natürlich nichts, solange der Linksys keine Interntanbinung hat.
Über 3 Punkte bin ich aber schon gestolpert.
1. Ich finde nirgends „ESP“
2. Muss ich nicht auch 1701 vorwarden?
3. Es gibt Felder für „öffentliche“ und „privat“. Muss ich die Eintragung i n beiden machen?
Wäre es am Beispiel von ISAKMP/IKE so richtig?
Ich wüsste nicht, das ich im Thread auf "gelöst" geklickt habe. Viellecht unbeabsichtigt
Wie kann ich das denn rückgängig machen?
Allerdings hatte ich Number of Addresses: 155, statt 100. Ich denke, es macht keinen Unterschied
Letztlich nicht, denn es bestimmt die Anzahl der IP Adressen für die Clients im Pool.Wenn du nicht mehr als 100 Hast ist das OK. Vermutlich reichen bei dir auch 50
Was genau bewirkt das denn?
Das bewirkt das das IPsec Handshaking(Phase 1 und 2) bei Hersteller fremden Clients nicht ganz so strikt ist. Da du vermutlich mit unterschiedlichen Clients zugreifst ist das besser was die Kompatibilität anbetrifft.Also wirklich ein reines Kabelmodem ohne Router.
OK, wenn dem wirklich so ist ist alles gut. Relevant ist hier immer die TimeCapsule WAN IP Adresse. Das muss dann eine IP Adresse des Providers sein die öffentlich ist und keine private RFC 1918 IP !Die Web-Oberfläche vom Linksys kann ich nur erreichen, wenn ich im WLAN vom Linksys eingeloggt bin.
Nein, das ist mit Sicherheit Unsinn, denn das Web GUI des Linksys muss auch an einem seiner LAN Ports erreichbar sein. Das LAN und das WLAN des Linksys ist ein und dasselbe IP Netz.Das du das Linksys GUI nicht über die WAN IP aus dem 10.0.1.0er Netz erreichen kannst ist ja auch vollkommen logisch.
Am WAN Port ist die NAT Firewall des Linksys aktiv und die blockt jeglichen Zugriff von außen. Logisch das es darüber natürlich dann nicht klappen kann !
Im normalen Einsatz wäre der Linksys WAN Port ja direkt am Internet. Da willst du natürlich nicht das man den Router erreichen kann. Nicht anders verhält er sich in einer Kaskade.
WAN Zugriff kann durch die NAT Firewall nicht klappen. Ist also normal. LAN undWLAN muss aber klappen.
denn ich bekomme ja von der Timecapsule eine 10.0.1.X IP zugewiesen
Ja, klar aber einzig nur wenn du im lokalen LAN der TimeCapsule bist !Befindest du dich an einem der lokalen LAN Ports des Linksys oder seinem WLAN bekommst du logischerweise einen 10.0.2.x IP Adresse.
ACHTUNG: Hier musst du strikt aufpassen das du mit deinem PC niemals z.B. mit dem LAN im einen und mit dem WLAN im anderen IP Netz bist !!!
Also immer nur entweder oder und LAN oder WLAN deaktivieren wenn du testest bzw. konfigurierst !!!
Manches Verhalten kommt mir willkürlich oder sporadisch vor.
Das könnte der Grund sein wenn sich die LAN und WLAN Adapter in den beiden unterschiedlichen IP Netzen befinden. Sorge dafür das das NICHT passiert !Wenn ich im WLAN der Timecapsle eingeloggt bin, sehe ich alle Geräte aus diesem IP Kreis.
Das ist auch vollkommen normal und korrekt so !Geräte im lokalen LAN des Linksys kannst du logischerweise NICHT sehen, weil die NAT Firewall am WAN Port des Linksys dazwischen ist und den Zugriff verhindert ! Kommt man aber auch von selber drauf wenn man mal ein klein wenig nachdenkt
! Ne Menge GoPros hast du da im Netz 
Hier sieht man übrigens auch, dass die Timecapsule tatsächlich die IP 10.0.1.1 hat.
Mmmhhh...dem Hostnamen zu urteilen ist das ne GoPro Kamera und kein Apple. Übrigens haben Sonderzeichen wie ! usw. nichts zu suchen in Hostnamen. Nur mal nebenbei...Aber den Linksys hat er wenigstens sauber erkannt. Checke zur Sicherheit nochmal das sich die vergebene Linksys IP .254 nicht mit dem DHCP Pool der TimeCapsule überschneidet !!! Das wäre sehr wichtig.
Sobald ich mich ins WLAN vom Linksys eingelogge, hat die Timecapsule keine Internetverbindung mehr.
Das ist völliger Quatsch und technischer Unsinn !!Das IP Netz und die Internet Verbindung der TC ändert sich doch nicht von Geisterhand nur weil du im WLAN des Linksys bist ! Vergiss diesen Blödsinn !!
Vermutlich nutzt du zum check der TC das Airport Dienstprogramm, richtig ?!
Das kann aber sobald du im Linksys WLAN eingebucht bist die BonJour Broadcasts der TC nicht mehr empfangen und "sieht" damit die TC dann nicht mehr.
Das heisst aber lange noch nicht das die TC die Internet Verbindung verloren hat. Das kannst du auch daran sehen das alle anderen Clients im 10.0.1er Netz der TC vermutlich weiter fröhlich Internet Zugang haben.
Also bitte denk mal etwas nach wie dein Airport Dienstprogramm funktioniert, dann leucht das Verhalten doch ein !!
Was in jedem Falle gehen muss ist der Internet Zugang aus dem lokalen Linksys LAN oder WLAN in der Konstellation.
Wenn du also mit dem Test PC am LAN oder WLAN des des Linksys hängst (und zwar NUR am Linksys) solltest du wenn du die Eingabeaufforderung aufmachst und mal ping 8.8.8.8 eingibst eine Antwort bekommen !
Die 8.8.8.8 ist ein Rechner direkt im Internet !
Das MUSS klappen. Wenn nicht brauchst du erstmal mit dem VPN nicht weiterzumachen.
Außerdem hat der Mac immer noch die IP vom WLAN der Timecapsule.
Das zeigt dann ganz klar das dein MAC nicht mit dem WLAN des Linksys verbunden ist !! Wie gesagt hier besteht die Gefahr das der LAN Port im einen und WLAN Port im anderen IP netz ist. Das geht dann so NICHT !Achte darauf das erstmal immer nur ein Port aktiv in EINEM Netz ist !
Per Ping-Funktion des linksys ist die Timecapsule nicht erreichbar
Das bedeutet das TC und Linksys NICHT richtig verbunden sind ! Ein Ping vom Linksys auf die TC muss immer möglich sein.also die Timecapsule hat auch dann keine Internetverbindung und es werden keine Geräte im LAN gefunden, außer der Mac.
Das liegt vermutlich nur am Airport Dienstprogramm wie oben beschrieben. Kann das sein ??Ansonsten arbeitet die TC ggf. gar nicht als Router sondern nur als einfacher Accesspoint. Kann man aber wohl ausschliessen das dem so ist, denn ansonsten wären alle Geräte direkt am vermeintlichen Modem und das Modem dann kein Modem sondern dann doch ein Router.
Die Tatsache das das vermeintliche Modem auch Telefonie kann nährt eher die Vermutung das das doch ein Router ist, denn ein reines Modem kann niemals VoIP Telefonie bedienen. Frage also ob du über die Cisco Box auch Telefonie machst, denn dann wäre es de facto ein Router und ganz sicher KEIN nur Modem !
Da bleiben also erhebliche Zweifel.
In der Timcapsule sind 2 WLAN konfiguriert, eins als 2,4 und eins als 5GHz
Ja, das ist normal. Die TC hat 2 Radios die aber alle im Bridging mit dem lokalen LAN Port der TC verbunden sind und damit im 10.0.1.0er Netzwerk. Das ist also völlig normal.Niemals aber darf die TC egal unter welchen Umständen die Internet Verbindung verlieren. Die fasst du doch niemals an. Wie gesagt..lass dich nicht in die Irre leiten durch das Airport Dienstprogramm. Das kann die TC nur dann "sehen" wenn es im gleichen Netz der TC ist und dessen Bonjour Broadcasts empfängt. Im Linksys Netz ist das durch die Abtrennung durch die NAT Firewall nicht mehr möglich !
dass die Timecapsule zwar mit dem Internet verbunden ist, aber die Timecapsule selbst wird nicht gefunden.
Genau DAS ist der Punkt wenn du im Linksys WLAN bist...siehe oben warum !Vielen Dank auch für die super Erklärung über das Port Forwarding. Das habe ich jetzt noch nicht probiert, denn wie du geschrieben hast, bringt es ja natürlich nichts, solange der Linksys keine Interntanbinung hat.
Nichts zu danken...dafür ist ein Forum da Und ja...erst muss der Linksys fehlerlos laufen sonst lohnt es nicht weiterzumachen.Über 3 Punkte bin ich aber schon gestolpert.
1. Ich finde nirgends „ESP“
Das ist erstmal schlecht. Wenn du Glück hast "erkennt" aber der TC Router das wenn er UDP 500 und 4500 forwardet dann auch ESP forwardet. Die meisten der besseren Router handhaben das so.1. Ich finde nirgends „ESP“
Dazu sollte deine TC natürlich auf dem aktuellsten Firmware Stand sein. Worst Case wäre wenn sie ESP nicht forwardet. Das kannst du aber wasserdicht checken indem du den Linksys mal abziehst und einen PC anklemmst die die IP Adresse 10.0.1.254 eingestellt hat und auf dem ein Wireshark_Sniffer läuft. Kannst du eingehende ESP Pakete dort sehen forwardet der Router das dann korrekt und alles ist gut !
2. Muss ich nicht auch 1701 vorwarden?
Wie kommst du auf diesen Port und meinst du TCP oder UDP ??UDP 1701 ist nur relevant wenn du L2TP als VPN Protokoll nutzt. Das kann dein Linksys aber nicht, denn der macht wenn man es von den Screenshots oben richtig interpretiert einzig nur IPsec. Dazu solltest du aber nochmal ins Datenblatt oder Manual sehen was der Linksys da genau supportet an VPN Protokollen !!!
3. Es gibt Felder für „öffentliche“ und „privat“.
Öffentlich bedeutet welchen Port eingehende IP Pakete am Router Port mit der öff.IP Adresse haben. Hier muss dann UDP 500 und UDP 4500 reinPrivat bedeutet welchen Port diese Pakete im Internen Netzwerk haben sollen wenn sie per Port Forwarding weitergeleitet werden.
Das sollte dann natürlich auf UDP 500 und UDP 4500 bleiben da diese Port zwingend von IPsec erwartet werden.
Gemeint ist damit z.B. optional ein Port Translation.
Wenn du z.B. einen internen kleinen Webserver betreibst im lokalen LAN z.B. Raspberry Pi oder einen auf einem USB Stick wie den HFS_Webserver oder was auch immer um den von außen für Freunde erreichbar zu machen. Dann kannst du z.B. sagen von außen soll der nicht über seinen Standard Port TCP 80 (HTTP) erreichbar sein sondern mit Port TCP 58080.
Das macht man um das etwas zu verschleiern damit nicht jeder Portscanner Hacker Heini im Internet diesen Server gleich beim ersten Portscan Angriff mit TCP 80 Standartport sieht. Solche Angriffe kommen im Sekundentakt an jedem Internet Router 24x7 an....
Dann sagst du z.B. Öffentlich TCP 58080 und Privat TCP 80.
Wie es dann geht ist dir dann wohl nun auch klar...
Wenn du von außen mit http://<öff.Router_IP>:58080 zugreifst dann forwardet der Router das weiter an die interne Webserver IP z.B. 10.0.1.111 mit dem Port TCP 80 und dann antwortet dein kleiner Webserver ins Internet. So kann man interne Geräte und Applikationen von außen zugänglich machen.
Allerdings ist das tödlich, da die Daten dann vollkommen unverschlüsselt und ungeschützt über das Internet gehen !
Genau DAS willst du mit deinem VPN ja richtigerweise und vernünftigerweise nicht machen sondern geschützt über ein VPN !
Das aber nur als Beispiel. Du machst KEIN Port Translation und deshalb sind deine öffentlichen und privaten Ports immer GLEICH bei VPN Anwendungen.
Deine Erklärungen und Tipps sind echt klasse!
Laut Auskunft eines Unitymedia-Experten ist das Modem wirklich als reines Modem ohne Router-Funktionen zu betrachten. Die Telefonanschlüsse sind zwar VoIP, aber sie werden irgendwie intern mit speziellen Protokollen gerootet. Ein "versteckes" IP-Netz hat das Gerät nicht. Die Telefonanschlüsse sind für den User nicht konfigurierbar, sondern da ist ausschließlich die von Unitymedia zur Verfügung gestellte Festnetznummer drauf gelegt.
Ich habe jetzt noch mal alles von rechts auf links gedreht. Jetzt scheint soweit alles korrekt zu sein.
Der Linksys kann jetzt die Timecapsule mit 10.0.1.1 anpingen.
Wenn ich im WLAN der Timecapsule eingeloggt bin, kann ich wegen der NAT Firewall am WAN Port des Linksys ja nur Geräte mit 10.0.1.Xer IP erreichen.
Das verstehe ich jetzt soweit auch.
Wenn ich im WLAN des Linkys eingeloggt bin, kann ich hingegen alle Geräte in beiden Netzen erreichen, also sowohl die 10.0.1.Xer wie die 10.0.2.Xer, bis auf die Linksys WAN IP 10.1.1.254
Das heißt also, die Geräte, die ich per VPN erreichen will, müssen im Linksys-Netz sein? Oder können sie auch im Timecapsule-Netz sein?
Portweiterleitung in der Timecapluse habe ich jetzt gemacht. Vorsichtshalber auch für L2TP:
Eine VPN Verbindung lässt sich aber nicht herstellen.
Vielleicht also tatsächlich ein Problem mit ESP?
Ich habe den Linksys abgeklemmt und einen Win-PC mit IP 10.0.1.254 ins Netz gestöpselt. Auf dem hab ich WihteShark installiert, wie Du gesagt hast.
Kenne mich mit dem Tool natürlich absolut null aus
Was muss ich denn jetzt machen, um zu testen ob ESP Pakete eingehen?
Warum mit dem LanScan Programm bei einigen Hostnamen Go Pro! angezeigt wird, habe ich mich auch schon drüber gewundert. Es werden dann nur die ersten 3 Zeichen des Hostnamen angezeigt und der Rest mit „...Go Pro!..“ überschrieben. Vermutlich Werbung, weil ich die kostenlose Varante von LanScan habe ?!?
Noch was:
Die Oberfläche des Linksys kann ich mittels Browser ja nicht aufrufen, wenn ich mich im 10.0.1.1 Netz befinde. Das ist mir soweit jetzt auch klar. Nach Deiner Erklärung über „Port Translation“ müsste man dass doch irgendwie forwarden können, oder?
Und merkwürdiger Weise kann ich auf die Oberfläche nur zugreifen, wenn ich im LAN der Linksys eingestöpselt bin. Wenn ich im WLAN vom Linksys eingeloggt bin, kommen je nach Browser verschiedene Meldungen:
Laut Auskunft eines Unitymedia-Experten ist das Modem wirklich als reines Modem ohne Router-Funktionen zu betrachten. Die Telefonanschlüsse sind zwar VoIP, aber sie werden irgendwie intern mit speziellen Protokollen gerootet. Ein "versteckes" IP-Netz hat das Gerät nicht. Die Telefonanschlüsse sind für den User nicht konfigurierbar, sondern da ist ausschließlich die von Unitymedia zur Verfügung gestellte Festnetznummer drauf gelegt.
Ich habe jetzt noch mal alles von rechts auf links gedreht. Jetzt scheint soweit alles korrekt zu sein.
Der Linksys kann jetzt die Timecapsule mit 10.0.1.1 anpingen.
Wenn ich im WLAN der Timecapsule eingeloggt bin, kann ich wegen der NAT Firewall am WAN Port des Linksys ja nur Geräte mit 10.0.1.Xer IP erreichen.
Das verstehe ich jetzt soweit auch.
Wenn ich im WLAN des Linkys eingeloggt bin, kann ich hingegen alle Geräte in beiden Netzen erreichen, also sowohl die 10.0.1.Xer wie die 10.0.2.Xer, bis auf die Linksys WAN IP 10.1.1.254
Das heißt also, die Geräte, die ich per VPN erreichen will, müssen im Linksys-Netz sein? Oder können sie auch im Timecapsule-Netz sein?
Portweiterleitung in der Timecapluse habe ich jetzt gemacht. Vorsichtshalber auch für L2TP:
Eine VPN Verbindung lässt sich aber nicht herstellen.
Vielleicht also tatsächlich ein Problem mit ESP?
Ich habe den Linksys abgeklemmt und einen Win-PC mit IP 10.0.1.254 ins Netz gestöpselt. Auf dem hab ich WihteShark installiert, wie Du gesagt hast.
Kenne mich mit dem Tool natürlich absolut null aus
Was muss ich denn jetzt machen, um zu testen ob ESP Pakete eingehen?Warum mit dem LanScan Programm bei einigen Hostnamen Go Pro! angezeigt wird, habe ich mich auch schon drüber gewundert. Es werden dann nur die ersten 3 Zeichen des Hostnamen angezeigt und der Rest mit „...Go Pro!..“ überschrieben. Vermutlich Werbung, weil ich die kostenlose Varante von LanScan habe ?!?
Noch was:
Die Oberfläche des Linksys kann ich mittels Browser ja nicht aufrufen, wenn ich mich im 10.0.1.1 Netz befinde. Das ist mir soweit jetzt auch klar. Nach Deiner Erklärung über „Port Translation“ müsste man dass doch irgendwie forwarden können, oder?
Und merkwürdiger Weise kann ich auf die Oberfläche nur zugreifen, wenn ich im LAN der Linksys eingestöpselt bin. Wenn ich im WLAN vom Linksys eingeloggt bin, kommen je nach Browser verschiedene Meldungen:
Deine Erklärungen und Tipps sind echt klasse!
Wichtig ist das sie dich zum Erfolg führen... Laut Auskunft eines Unitymedia-Experten ist das Modem wirklich als reines Modem ohne Router-Funktionen zu betrachten.
Sehr gut ! Das eliminiert dann den Verdacht das es doch als Router arbeiten könnte und schliesst Fehler diesbezüglich dann aus.Was die Erklärung mit VoIP anbetrifft lassen aber doch wieder erhebliche Zweifel an der technischen Kompetenz dieses Unitymedia Mitarbeiters aufkommen.
VoIP Pakete können nur geroutet werden und eine VoIP Implementation erzwingt ein Routing und eine Komponenten die aktiv am IP Forwarding beteiligt ist und das ist nunmal imemr ein Router und kein reines Modem.
Aber glauben wir der Auskunft mal...egal wie auch immer das technisch dann gelöst ist.
Entscheidend wäre hier die IP Adresse am WAN Port der TimeCapsule zu der du leider dich weiterhin mit keinem einzigen Wort äußerst. Die würde das im Handumdrehen klären, denn das müsste eine öffentliche IP Adresse vom Provider sein.
Der Linksys kann jetzt die Timecapsule mit 10.0.1.1 anpingen.
OK, das bringt uns einen Riesenschritt weiter und zeigt jetzt das du alles richtig gemacht hast !Wenn ich im WLAN des Linkys eingeloggt bin, kann ich hingegen alle Geräte in beiden Netzen erreichen,
Das ist auch logisch, denn wenn du von dort (dem lokalen LAN 10.0.2.0 /24) am Linksys eine Verbindung aufbaust du so durch die NAT Firewall des Linksys nach draussen kommst.Der Linksys "merkt" sich diese Session in der NAT Tabelle und leitet Antwortpakete dann durch die NAT Firewall wieder auf den Client.
Wichtig ist hierbei das die Session VOM lokalen Linksys LAN nach draussen aufgebaut wird. Dann erreichst du alles. Entsprechend sollte jetzt auch aus dem Linksys LAN ein Internet Zugriff fehlerlos klappen, richtig ??
Ein Sessionaufbau von außen darf nie passieren und das verhindert die NAT Firewall des Linksys. Dashalb sind diese Szenarien mit NAT Routerkaskaden immer routingtechnische Einbahnstrassen.
Dieses Tutorial erklärt dir genau das Warum:
Kopplung von 2 Routern am DSL Port
Bitte lesen und verstehen..!
Das heißt also, die Geräte, die ich per VPN erreichen will, müssen im Linksys-Netz sein? Oder können sie auch im Timecapsule-Netz sein?
Generell ja. Es gibt aber die Möglichkeit einzelne Geräte auch im TC Netz erreichbar zu machen mit entsprechendem Firewall Einstellungen auf dem Linksys. Das ist aber durch die nicht abschlatbare NAT Firewall auf dem Linksys nur sehr sehr eingeschränkt möglich.Es wäre hier sinnvoller wenn du dein gesamtes Konzept überdenken würdest mit der Routerkaskade. Was bringt dir das noch ??
Es ist viel sinnvoller den Linksys zentral als Internet Router an das Kabelmodem anzuschliessen und die TC rein nur noch als Accesspoint mit Netzwerk Festplatte zu konfigurieren.
Damit wärst du das ganze Problem mit der Routerkaskade und der elenden Frickelei mit dem Port Forwarding auf einen Schlag los.
Besser noch deinen Performance im Netz steigt und...du kannst auch die Netzwerk Festplatte auf der TC ohne Probleme mit allen VPN Clients problemlos erreichen.
Das wäre der erheblich besser Weg und du solltest dir ernsthaft Gedanken machen dein Netzwerk so umzustellen. Es bietet nur Vorteile für dich als diese elendige Kaskade.
Ein weiterer Vorteil wäre das das Linksys WLAN und das TC WLAN dann durch den Accesspoint Betreib des TC in einem gemeinsamen IP Netz sind und du so dein WLAN vergrößern und verbessern kannst von der betriebssicherheit.
SSID (WLAN Name) und Passwort wären dann auf beiden WLAN Accesspoints TC und Linksys gleich.
Den Weg solltest du gehen wenn du es perfekt machen willst !
Bzw. mindestens darüber nachdenken bevor wir jetzt mit der Kaskaden Fricklei hier weitermachen !
Vorsichtshalber auch für L2TP:
Ist Schwachsinn, denn dein Linksys kann gar kein L2TP !!Damit hast du nur weitere gefährliche Löcher in deine Firewall gebohrt die dich mehr gefährden als das es was bringt. Du kannst ja gar kein L2TP VPN machen weil eben dein Linksys das gar nicht kann. Wozu also ??
Eine VPN Verbindung lässt sich aber nicht herstellen. Vielleicht also tatsächlich ein Problem mit ESP?
Davon kann man fast ausgehen ! Denek also über das sinnvollere Redesign des Netzwerkes nach wie oben beschrieben !Kenne mich mit dem Tool natürlich absolut null aus Was muss ich denn jetzt machen, um zu testen ob ESP Pakete eingehen?
Macht das Troubleshooting dann leider nicht einfacher... 
Lass den Wireshark laufen, mach einen VPN Client auf dem Smartphone auf und verbinde dich mit der IP WAN Port Adresse des TC. Diese Pakete müsstest du dann als eingehenden UDP 500, 4500 und ESP Pakete im Wireshark sehen. Er zeigt dir das als IKE, NATT und ESP auch an !
Kannst du dir auch mit dem Redesign sparen.
Die Oberfläche des Linksys kann ich mittels Browser ja nicht aufrufen, wenn ich mich im 10.0.1.1 Netz befinde. Das ist mir soweit jetzt auch klar. Nach Deiner Erklärung über „Port Translation“ müsste man dass doch irgendwie forwarden können, oder?
Ja ! Du musst in der Firewall Einstellung des Linksys den Web Zugriff über den WAN Port erlauben. Dort gibt es einen Haken in der Konfig der das aktiviert. Dann kannst du über die 10.0.1.254 auch auf den Linksys zugreifen.Würde durch ein Redesign aber auch obsolet werden !
Und merkwürdiger Weise kann ich auf die Oberfläche nur zugreifen, wenn ich im LAN der Linksys eingestöpselt bin
Ja und das ist dir oben ja auch schon mehrfach erklärt worden warum !!Die NAT Firewall am WAN Port des Linksys (10.0.1.254) verhindert jeglichen Zugriff auf die Linksys IP Adressen von außen ! "Außen" ist alles was jenseits des WAN Ports ist !
Wenn ich im WLAN vom Linksys eingeloggt bin, kommen je nach Browser verschiedene Meldungen:
Ja, das ist klar weil die Verbindung des Browsers über HTTPS (S = Secure) verschlüsselt passiert. Der Linksys Router benutzt dazu ein selbstsigniertes Zertifikat was die meisten Browser heutzutage nicht mögen. Klar, denn dafür kann dir ja alles mögliche untergeschoben werden. Stell dir mal vor deinen banking Seite würde das machen !!!In sofern trauen die Browser dem Router Zertifikat nicht und meckern entsprechend.
Nun ja...wenn du mal etwas lesen würdest kannst du dort aber immer auf "Advanced" oder "Forfahren" oder "Erweitert" (wie oben) oder sowas klicken und manuell das Zertifikat akzeptieren und eine Ausnahme (Exception) klicken.
Dann meckert der Browser beim nächsten Mal nicht mehr und akzeptiert die selbstsignierte HTTPS Verbindung weil du sie abgenickt hast.
Mensch, dir muss man aber auch jeden F.... als Erklärbär erklären
Wie wärs mal mit etwas Wikipedia lesen ???Es ist viel sinnvoller den Linksys zentral als Internet Router an das Kabelmodem anzuschliessen und die TC rein nur noch als Accesspoint mit Netzwerk Festplatte zu konfigurieren.
Das war eigentlich mein ursprünglicher Gedanke. Und da habe ich heute auch noch mal dran gedacht, falls die Timecapsule tatsächlich kein ESP weiterleiten kann.Deine Argumente sind natürlih nicht von der Hand zu weisen.
Ich dachte mir aber, dass die Timecapsule erst 1 Jahr alt ist und deshalb aus mehreren Punkten vorteilhafter ist (Sicherheit,
Performance, Stabilität, WLAN-Reichweite etc,) als der über 10 Jahre alte Linksys.
Ist dem nicht so?
Oder hast Du einenTipp worauf ich achten sollte wenn ich mir einen neueren Router mit integriertem VPN-Server anschaffe, den ich vor die Timecapsule setzen kann?
Ach ja: Die IP Adresse am WAN Port der TimeCapsule die öffentliche IP Adresse vom Provider. Also dieselben, die bei wieistmeineip.de angezeigt wird.
So, habe jetzt die Timecapsule abgeklemmt und nur den Linksys als Router an das Modem geklemmt.
Internet funktioniert einwandfrei.
Eine VPN-Verbindung lässt sich aber nicht aufbauen.
Was hab ich jetzt wieder verbockt?
Konfiguration mehr oder weniger wie gehabt:
Internet funktioniert einwandfrei.
Eine VPN-Verbindung lässt sich aber nicht aufbauen.
Was hab ich jetzt wieder verbockt?
Konfiguration mehr oder weniger wie gehabt:
als der über 10 Jahre alte Linksys. Ist dem nicht so?
Das kommt darauf an. Wenn der Linksys mit der aktuellsten Firmware betankt ist die nicht älter als ein Jahr ist und wenn er hardwareseitig den Durchsatz schafft muss er nicht schlechter sein.Außerdem gibt es mit DD-WRT auch noch eine weitaus potentere freie Firmware. https://www.dd-wrt.com/site/
Über die Router Database kannst du checken ob dein Linksys Modell supportet ist.
Oder hast Du einenTipp worauf ich achten sollte wenn ich mir einen neueren Router mit integriertem VPN-Server anschaffe,
Der sollte performant genug sein und möglichst viele VPN Protokolle supporten.Du solltest hier keinen Router sondern eine kleine Firewall nehmen.
Diese hier wäre eine sehr gute Wahl, denn sie kann das alles:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
WAN Port der TimeCapsule die öffentliche IP Adresse vom Provider. Also dieselben, die bei wieistmeineip.de angezeigt wird.
Perfekt ! Sehr gut. Damit ist auch dieser möglich Fehler ausgeräumt.Mit Unitymedia ist so ohne Weiters gar kein VPN-Tunnel mehr möglich
Das wäre ja Quatsch und widerspricht deiner Äußerung von oben: (Zitat) Die IP Adresse am WAN Port der TimeCapsule die öffentliche IP Adresse vom Provider. Also dieselben, die bei wieistmeineip.de angezeigt wird.Wenn du hier also ein öffentliche IP Adresse siehst und diese IP KEINE IP Adresse aus dem privaten RFC 1918 Bereich: 10.0.0.0 /8, 172.16.0.0 /12 und 192.168.0.0 /16 ist kann es das NICHT sein.
Ist diese IP aber eine aus dem o.a. Bereich dann hast du Pech.
Dann macht dein Provider CGN (Carrier Grade NAT) also eine zentrale IP Adress Translation. Das ist dann in der Tat das Aus für VPNs.
https://de.wikipedia.org/wiki/Carrier-grade_NAT
Das was VPN seitig dann bei CGN möglich ist in einem Kabel TV Netz kannst du hier nachlesen:
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...
Das wäre ja Quatsch und widerspricht deiner Äußerung von oben: (Zitat) Die IP Adresse am WAN Port der TimeCapsule die öffentliche IP Adresse vom Provider. Also dieselben, die bei wieistmeineip.de angezeigt wird.
Stimmt, war Blödsinn. Habe ich heute mit dem Unitymedia Support geklärt und dann meinen Beitrag schnell geändert. Ich hab ne ganz normale öffentliche IPv4 (Siehe meinen geänderten Beitrag oben).
VPN geht aber wie gesagt trotzdem nicht. Irgendwo habe Ich da schon wieder bzw. immer noch was falsch gemacht.
Das was VPN seitig dann bei CGN möglich ist in einem Kabel TV Netz kannst du hier nachlesen:
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...Auf genau diese Website bin ich heute Nacht auch schon gestoßen.
Ich hab ne ganz normale öffentliche IPv4 (Siehe meinen geänderten Beitrag oben).
Perfekt. Dann ist alles Bella bei dir und deinem VPN steht nix mehr im Wege ! Der ct Artikel ist dann überflüssig für dich.VPN geht aber wie gesagt trotzdem nicht. Irgendwo habe Ich da schon wieder bzw. immer noch was falsch gemacht.
Ja, ganz sicher. Da liegt der Fehler dann zu 98% zwischen den Kopfhörern Erste Anlafstelle ist hier IMMER das Linksys Log !!! Was steht da drin wenn du auf den Linksys die VPN Verbindung öffnest.
2te wichtige Frage: Mit welchem VPN Client und von WO öffnest du eine VPN Verbindung.
Dir sollte klar sein das das aus dem lokalen LAN aufgrund der NAT Haiprin Problematik NICHT geht:
https://wiki.mikrotik.com/wiki/Hairpin_NAT
Du musst also den VPN Client in einem anderen Netz starten also beim Freund oder Kollegen oder aus dem Mobilfunknetz mit dem Smartphone.
Auch hier gilt beim Letzteren Vorsicht. Wenn du einen billigen NUR Surf Account hast blockieren viele Billigprovider die gängigsten VPN Protokolle, denn das gestehen sie nur den teureren Business Tarifen zu. Also da Augen auf wenn du es via Mobilfunk versuchst.
Da der Linksys nur native IPsec als VPN supportet, kannst du nur VPNs auf native IPsec Basis aufbauen. Klar und logisch... Mit einem PPTP oder L2TP Client auf den Linksys zu gehen schlägt also sofort fehl, das ist dir hoffentlich klar ?!
Die aktuellste Firmware Version 1.0.39 hast du geflasht ?? http://www.cisco.com/c/en/us/support/routers/wrv200-wireless-g-vpn-rout ...
Der Router supportet 10 Standard IPsec Tunnel mit 3DES/AES Verschlüsselung, MD5, SHA1 Authentication und IPsec NAT Traversal (NAT-T),
In jedem Falle brauchst du also einen klassischen IPsec Client. Entweder den eigenen von Cisco:
Quick Virtual Private Network (QVPN) Utility
http://www.cisco.com/c/en/us/support/routers/wrv200-wireless-g-vpn-rout ...
oder den freien Klassiker Shrew VPN Client:
https://www.shrew.net/download
Oder onboard IPsec VPN Clients sofern auf deinem Endgerät vorhanden !
Als Tunnel Ziel IP Adresse im Client musst du immer die aktuelle öffentliche WAN IP Adresse des Linksys angeben!!
Hier macht es ggf. Sinn später mit einem DynDNS im Linksys zuarbeiten sollte sich diese WAN IP Adresse dynamisch ändern wie bei xDSL Anschlüssen.
Also...sieh immer ins Linksys Log wenn du den VPN Zugriff machst, da steht sofort wo der Fehler ist.
Oder auch Log des VPN Clients sofern vorhanden. Auch da steht was Sache ist.
Ich habe gerade noch einmal versucht, über ein iPhone 6S im LTE-Netz.
Businesstarif. Habe den onboard VPN IPSec Client vom iOS verwendet. Als Ziel IP hab ich die aktuelle öffentliche WAN IP vom Linksys angeben, also die die auch mit wieistmeineip.de angezeigt wird.
Server wird aber nicht gefunden:
Wo und ob es im iPhone ein Log gibt, weiß ich nicht.
Die Einstellungen im VPN Client vom iPhone sind korrekt.
Habe ich also vielleicht doch irgendwo eine falsche Einstellung im Linksys?
Businesstarif. Habe den onboard VPN IPSec Client vom iOS verwendet. Als Ziel IP hab ich die aktuelle öffentliche WAN IP vom Linksys angeben, also die die auch mit wieistmeineip.de angezeigt wird.
Server wird aber nicht gefunden:
Erste Anlafstelle ist hier IMMER das Linksys Log !!!
empty Wo und ob es im iPhone ein Log gibt, weiß ich nicht.
Die aktuellste Firmware Version 1.0.39 hast du geflasht ??
Ja. Siehe oben rechts im screenshot:Die Einstellungen im VPN Client vom iPhone sind korrekt.
Habe ich also vielleicht doch irgendwo eine falsche Einstellung im Linksys?
Hab jetzt mal alles abgeschaltet und vom Netz genommen und rebootet, einschließlich iPhone.
Dann noch einmal versucht mit dem iPhone die VPN aufzubauen.
Meldung im iPhone ist immer noch die selbe, also "Der VPN-Server antwortet nicht".
Aber jetzt gibt es ein Log in linksys.
Ich kann die Einträge im Log nicht so richtig interpretieren.
Denke aber, dass Zeile 14 bis 18 Ausschuss geben könnte, wo der Hund begraben ist, obwohl ich nicht weiß was das bedeuten soll und daher auch nicht, wie ich das Problem lösen kann.
000 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: responding to Main Mode from unknown peer 89.204.155.175
001 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
002 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
003 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
004 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
005 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
006 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
007 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
008 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
009 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
010 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
011 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
012 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
013 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
014 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
015 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
016 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: no acceptable Oakley Transform
017 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
018 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
019 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: responding to Main Mode from unknown peer 89.204.155.175
020 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
021 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
022 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
023 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
024 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
025 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
026 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
027 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
028 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
029 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
030 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
031 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
032 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
033 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
034 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
035 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: no acceptable Oakley Transform
036 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
037 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
038 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: responding to Main Mode from unknown peer 89.204.155.175
039 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
040 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
041 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
042 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
043 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
044 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
045 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
046 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
047 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
048 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
049 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
050 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
051 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
052 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
053 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
054 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: no acceptable Oakley Transform
055 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
056 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
057 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: responding to Main Mode from unknown peer 89.204.155.175
058 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
059 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
060 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
061 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
062 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
063 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
064 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
065 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
066 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
067 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
068 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
069 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
070 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
071 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
072 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
073 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: no acceptable Oakley Transform
074 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
075 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
/code>
Dann noch einmal versucht mit dem iPhone die VPN aufzubauen.
Meldung im iPhone ist immer noch die selbe, also "Der VPN-Server antwortet nicht".
Aber jetzt gibt es ein Log in linksys.
Ich kann die Einträge im Log nicht so richtig interpretieren.
Denke aber, dass Zeile 14 bis 18 Ausschuss geben könnte, wo der Hund begraben ist, obwohl ich nicht weiß was das bedeuten soll und daher auch nicht, wie ich das Problem lösen kann.
000 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: responding to Main Mode from unknown peer 89.204.155.175
001 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
002 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
003 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
004 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
005 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
006 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
007 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
008 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
009 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
010 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
011 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
012 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
013 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
014 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
015 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
016 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: no acceptable Oakley Transform
017 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175 #9: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
018 [Fri 12:00:25] "TunnelA"[9] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
019 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: responding to Main Mode from unknown peer 89.204.155.175
020 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
021 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
022 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
023 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
024 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
025 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
026 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
027 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
028 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
029 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
030 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
031 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
032 [Fri 12:00:28] "TunnelA"[10] 89.204.155.175 #10: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
033 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
034 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
035 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: no acceptable Oakley Transform
036 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175 #10: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
037 [Fri 12:00:29] "TunnelA"[10] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
038 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: responding to Main Mode from unknown peer 89.204.155.175
039 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
040 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
041 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
042 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
043 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
044 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
045 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
046 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
047 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
048 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
049 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
050 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
051 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
052 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
053 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
054 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: no acceptable Oakley Transform
055 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175 #11: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
056 [Fri 12:00:32] "TunnelA"[11] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
057 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: responding to Main Mode from unknown peer 89.204.155.175
058 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
059 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
060 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
061 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
062 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
063 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
064 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
065 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
066 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
067 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
068 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
069 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
070 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
071 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
072 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
073 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: no acceptable Oakley Transform
074 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175 #12: sending notification NO_PROPOSAL_CHOSEN to 89.204.155.175:41267
075 [Fri 12:00:35] "TunnelA"[12] 89.204.155.175: deleting connection "TunnelA" instance with peer 89.204.155.175 {isakmp=#0/ipsec=#0}
/code>
Über 1 Stunde gegoogelt. Scheint für mich mangels Kenntnissen ein unüberwindbares Problem zu sein
Weitere Recherchen im Web und etliche Tüfteleien brachten leider keinen Erfolg.
Beim Versuch mit einem Mac als VPN-Client sieht das Log im Linksys nahezu identisch aus.
Beim Versuch mit einem Mac als VPN-Client sieht das Log im Linksys nahezu identisch aus.
Mir ist aufgefallen, dass der Thread ziemlich vom ursprünglichen Thema abgewichen ist.
Ich habe deshalb einen neuen Thread erstellt und die neue Frage noch einmal übersichtlich formuliert:
VPN IPSec mit Linksys Router funktioniert nicht
Ich habe deshalb einen neuen Thread erstellt und die neue Frage noch einmal übersichtlich formuliert:
VPN IPSec mit Linksys Router funktioniert nicht
Welchen VPN Client hast du denn im Mac verwendet ? Wenn dann geht nur IKE2. Die Cisco Version mit Groupauth kann der WRV200 nicht.
Fraglich ob der WRV aufgrund seines Alters dann auch IKE2 kann. Vermutlich macht er nur IKE1.
Wenn du einen Winblows Rechner irgendwo hast kannst du mal den Shrew Client probieren. Mit dem wird es ggf. klappen. Hilft dir nur nicht wirklich weiter
https://www.shrew.net/download
Hier die Anleitung:
https://www.shrew.net/support/Howto_Linksys
Fraglich ob der WRV aufgrund seines Alters dann auch IKE2 kann. Vermutlich macht er nur IKE1.
Wenn du einen Winblows Rechner irgendwo hast kannst du mal den Shrew Client probieren. Mit dem wird es ggf. klappen. Hilft dir nur nicht wirklich weiter
https://www.shrew.net/download
Hier die Anleitung:
https://www.shrew.net/support/Howto_Linksys
