12
ShrewSoft VPN Client: "negotiation timeout occurred"
Hallo zusammen,
ich arbeite derzeit im Home Office. Um mich mit dem PC im Firmen-Netzwerk zu verbinden, nutze ich den VPN Access Manager von ShrewSoft.
Ich bin kein Profi, daher ist von unserer EDV alles schön vorkonfiguriert - Ein Profil im .vpn-Format, das ich einfach importieren konnte um den Tunnel aufzubauen und eine .rdp-Datei mit der ich die eigentliche Verbindung herstelle. Ich habe dieses Setup jetzt monatelang auf meinem Windows 7 Desktop-PC verwendet (welchen ich aus diversen Gründen nicht auf Windows 10 upgraden möchte - wenn die Preise von Bauteilen sich wieder stabilisieren, möchte ich eher einen neuen PC bauen) und keine Probleme damit gehabt. Mein Router ist eine Unitymedia Connectbox... Nichts tolles, nicht sehr viel Freiraum, aber bisher tat sie ihren Job.
Von einem Tag auf den anderen ließ sich leider der VPN-Tunnel nicht mehr aufbauen. Bei der Meldung "bringing up tunnel" blieb der VPN Client vorübergehend hängen, dann kamen die Meldungen "gateway is not responding - tunnel disabled - detached from key daemon". Ein Anruf bei unserer EDV ergab, dass zwar meine Anfragen im Unternehmen ankamen, aber aus unbekanntem Grund keine Verbindung aufgebaut wurde. Unternehmensseitig funktioniere alles reibungslos, daher blieb mir nichts anderes übrig, als ins Auto zu steigen und von dem Moment an vor Ort zu arbeiten.
Ich habe natürlich einiges ausprobiert und Informationen gesammelt seit dieses Problem besteht.
- Andere User mit identischem Setup können nach wie vor ohne Probleme von zu Hause arbeiten.
- Mit meinem VPN-Profil gab es im Unternehmen auf einem Laptop einen Login-Test, der erfolgreich verlief.
- VPN-Client deinstalliert + Ordner unter appdata/local gelöscht - mit den ursprünglichen Dateien und Profilen neu installiert.
- Router (statische IP) über Nacht ausgeschaltet - Reset und IP-Wechsel.
- Laut Speedtest ist bei mir alles in Ordnung (32000er Leitung).
- Laut Netzwerkdiagnose über Router ist ebenfalls alles okay.
- Eine deaktivierte Windows-Firewall macht keinen Unterschied.
Im Laufe meiner Tests änderte sich die Fehlermeldung. Statt "gateway is not responding" wurde mir nun "negotiation timout occurred" [sic] angezeigt.
Ich erstellte zwischenzeitlich auch einen Debug-Log des VPN Clients:
Meine Befürchtung war zunächst, dass es irgendwie an meinem eigenen Router oder der generellen Internetverbindung liegt, aber ich glaube, dass ich das inzwischen ausschließen kann, denn ich habe noch folgende Versuche unternommen:
- Frische Installation auf leistungsschwachen Windows 8 Laptop in meinem Heimnetzwerk (über WLAN verbunden): negotiation timout occurred
- Frische Installation auf ausgeliehenen, recht leistungsstarken Windows 10 Laptop in meinem Heimnetzwerk (über WLAN verbunden): tunnel enabled - es funktioniert!
Und jetzt das besonders kuriose:
- Frische Installation auf Windows XP in einer virtuellen Maschine, die auf meinem eigenen Desktop-PC läuft (Der XP-Mode von Windows 7 Ultimate): tunnel enabled - Auch hier funktioniert es! Ich testete, ob ich sogar den Remote-PC ansteuern könnte, aber das ergab die Meldung: "Der Remotecomputer erfordert die Authentifizierung auf Netzwerkebene. Diese Funktion wird von Ihrem Computer nicht unterstützt."
Insbesondere der letzte Test spricht ja eigentlich dafür, dass meine LAN-Verbindung zwischen Desktop-PC und Router kein Problem sein dürfte. Und durch die erfolgreichen Tests auf Windows 10 Laptop und XP VM würde ich Probleme mit Unitymedia generell ausschließen.
Was bleibt ist mein eigener Windows 7 Desktop PC... Ich habe zwischen dem funktionierenden Status und den aktuellen Problemen nichts an meinem System verändert. Ein Blick in meine installierten Programme ergab lediglich ein automatisches Update von Google Chrome.
Die einzige Hilfestellung, die ich beim Googeln fand, war eine Deaktivierung des Microsoft Virtual WiFi Miniport-Adapters. Das tat ich auch über die Eingabeaufforderung, doch leider machte es keinen Unterschied.
Eine Systemwiederherstellung ist so weit zurück leider nicht mehr möglich.
Ich bin mit meinem Latein nun ziemlich am Ende und würde eine Lösung nur noch darin sehen ein anderes Gerät zu verwenden. Ich würde mich freuen, wenn hier vielleicht noch jemand hilfreiche Lösungsansätze für mich hätte.
LG
Vic
ich arbeite derzeit im Home Office. Um mich mit dem PC im Firmen-Netzwerk zu verbinden, nutze ich den VPN Access Manager von ShrewSoft.
Ich bin kein Profi, daher ist von unserer EDV alles schön vorkonfiguriert - Ein Profil im .vpn-Format, das ich einfach importieren konnte um den Tunnel aufzubauen und eine .rdp-Datei mit der ich die eigentliche Verbindung herstelle. Ich habe dieses Setup jetzt monatelang auf meinem Windows 7 Desktop-PC verwendet (welchen ich aus diversen Gründen nicht auf Windows 10 upgraden möchte - wenn die Preise von Bauteilen sich wieder stabilisieren, möchte ich eher einen neuen PC bauen) und keine Probleme damit gehabt. Mein Router ist eine Unitymedia Connectbox... Nichts tolles, nicht sehr viel Freiraum, aber bisher tat sie ihren Job.
Von einem Tag auf den anderen ließ sich leider der VPN-Tunnel nicht mehr aufbauen. Bei der Meldung "bringing up tunnel" blieb der VPN Client vorübergehend hängen, dann kamen die Meldungen "gateway is not responding - tunnel disabled - detached from key daemon". Ein Anruf bei unserer EDV ergab, dass zwar meine Anfragen im Unternehmen ankamen, aber aus unbekanntem Grund keine Verbindung aufgebaut wurde. Unternehmensseitig funktioniere alles reibungslos, daher blieb mir nichts anderes übrig, als ins Auto zu steigen und von dem Moment an vor Ort zu arbeiten.
Ich habe natürlich einiges ausprobiert und Informationen gesammelt seit dieses Problem besteht.
- Andere User mit identischem Setup können nach wie vor ohne Probleme von zu Hause arbeiten.
- Mit meinem VPN-Profil gab es im Unternehmen auf einem Laptop einen Login-Test, der erfolgreich verlief.
- VPN-Client deinstalliert + Ordner unter appdata/local gelöscht - mit den ursprünglichen Dateien und Profilen neu installiert.
- Router (statische IP) über Nacht ausgeschaltet - Reset und IP-Wechsel.
- Laut Speedtest ist bei mir alles in Ordnung (32000er Leitung).
- Laut Netzwerkdiagnose über Router ist ebenfalls alles okay.
- Eine deaktivierte Windows-Firewall macht keinen Unterschied.
Im Laufe meiner Tests änderte sich die Fehlermeldung. Statt "gateway is not responding" wurde mir nun "negotiation timout occurred" [sic] angezeigt.
Ich erstellte zwischenzeitlich auch einen Debug-Log des VPN Clients:
21/04/29 06:44:31 ## : IKE Daemon, ver 2.2.2
21/04/29 06:44:31 ## : Copyright 2013 Shrew Soft Inc.
21/04/29 06:44:31 ## : This product linked OpenSSL 1.0.1c 10 May 2012
21/04/29 06:44:31 ii : opened 'C:\Program Files\ShrewSoft\VPN Client\debug\iked.log'
21/04/29 06:44:31 ii : opened 'C:\Program Files\ShrewSoft\VPN Client/debug/dump-ike-decrypt.cap'
21/04/29 06:44:31 ii : rebuilding vnet device list ...
21/04/29 06:44:31 ii : device ROOT\VNET\0000 disabled
21/04/29 06:44:31 ii : network process thread begin ...
21/04/29 06:44:31 ii : pfkey process thread begin ...
21/04/29 06:44:31 ii : ipc server process thread begin ...
21/04/29 06:44:49 ii : ipc client process thread begin ...
21/04/29 06:44:49 <A : peer config add message
21/04/29 06:44:49 <A : proposal config message
21/04/29 06:44:49 <A : proposal config message
21/04/29 06:44:49 <A : client config message
21/04/29 06:44:49 <A : local id [...] message
21/04/29 06:44:49 <A : remote id [...] message
21/04/29 06:44:49 <A : preshared key message
21/04/29 06:44:49 <A : remote resource message
21/04/29 06:44:49 <A : peer tunnel enable message
21/04/29 06:44:49 DB : peer added ( obj count = 1 )
21/04/29 06:44:49 ii : local address [...] selected for peer
21/04/29 06:44:49 DB : tunnel added ( obj count = 1 )
21/04/29 06:44:49 DB : new phase1 ( ISAKMP initiator )
21/04/29 06:44:49 DB : exchange type is aggressive
21/04/29 06:44:49 DB : [...] <-> [...]
21/04/29 06:44:49 DB : [...]
21/04/29 06:44:49 DB : phase1 added ( obj count = 1 )
21/04/29 06:44:49 >> : security association payload
21/04/29 06:44:49 >> : - proposal #1 payload
21/04/29 06:44:49 >> : -- transform #1 payload
21/04/29 06:44:49 >> : key exchange payload
21/04/29 06:44:49 >> : nonce payload
21/04/29 06:44:49 >> : identification payload
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports nat-t ( draft v00 )
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports nat-t ( draft v01 )
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports nat-t ( draft v02 )
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports nat-t ( draft v03 )
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports nat-t ( rfc )
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports FRAGMENTATION
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local supports DPDv1
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local is SHREW SOFT compatible
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local is NETSCREEN compatible
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local is SIDEWINDER compatible
21/04/29 06:44:49 >> : vendor id payload
21/04/29 06:44:49 ii : local is CISCO UNITY compatible
21/04/29 06:44:49 >= : cookies [...]
21/04/29 06:44:49 >= : message 00000000
21/04/29 06:44:49 -> : send IKE packet [...] -> [...] ( 503 bytes )
21/04/29 06:44:49 DB : phase1 resend event scheduled ( ref count = 2 )
21/04/29 06:44:49 <- : recv IKE packet [...] -> [...] ( 102 bytes )
21/04/29 06:44:49 DB : phase1 found
21/04/29 06:44:49 ii : processing informational packet ( 102 bytes )
21/04/29 06:44:49 =< : cookies [...]
21/04/29 06:44:49 =< : message d3ddf390
21/04/29 06:44:49 << : notification payload
21/04/29 06:44:49 ii : received peer NO-PROPOSAL-CHOSEN notification
21/04/29 06:44:49 ii : - [...] -> [...]
21/04/29 06:44:49 ii : - isakmp spi = [...]
21/04/29 06:44:49 ii : - data size 46
21/04/29 06:44:54 -> : resend 1 phase1 packet(s) [0/2] [...] -> [...]
21/04/29 06:44:54 <- : recv IKE packet [...] -> [...] ( 102 bytes )
21/04/29 06:44:54 DB : phase1 found
21/04/29 06:44:54 ii : processing informational packet ( 102 bytes )
21/04/29 06:44:54 =< : cookies [...]
21/04/29 06:44:54 =< : message d3ddf390
21/04/29 06:44:54 << : notification payload
21/04/29 06:44:54 ii : received peer NO-PROPOSAL-CHOSEN notification
21/04/29 06:44:54 ii : - [...] -> [...]
21/04/29 06:44:54 ii : - isakmp spi = [...]
21/04/29 06:44:54 ii : - data size 46
21/04/29 06:44:59 -> : resend 1 phase1 packet(s) [1/2] [...] -> [...]
21/04/29 06:44:59 <- : recv IKE packet [...] -> [...] ( 102 bytes )
21/04/29 06:44:59 DB : phase1 found
21/04/29 06:44:59 ii : processing informational packet ( 102 bytes )
21/04/29 06:44:59 =< : cookies [...]
21/04/29 06:44:59 =< : message d3ddf390
21/04/29 06:44:59 << : notification payload
21/04/29 06:44:59 ii : received peer NO-PROPOSAL-CHOSEN notification
21/04/29 06:44:59 ii : - [...] -> [...]
21/04/29 06:44:59 ii : - isakmp spi = [...]
21/04/29 06:44:59 ii : - data size 46
21/04/29 06:45:04 -> : resend 1 phase1 packet(s) [2/2] [...] -> [...]
21/04/29 06:45:04 <- : recv IKE packet [...] -> [...] ( 102 bytes )
21/04/29 06:45:04 DB : phase1 found
21/04/29 06:45:04 ii : processing informational packet ( 102 bytes )
21/04/29 06:45:04 =< : cookies [...]
21/04/29 06:45:04 =< : message d3ddf390
21/04/29 06:45:04 << : notification payload
21/04/29 06:45:04 ii : received peer NO-PROPOSAL-CHOSEN notification
21/04/29 06:45:04 ii : - [...] -> [...]
21/04/29 06:45:04 ii : - isakmp spi = [...]
21/04/29 06:45:04 ii : - data size 46
21/04/29 06:45:09 ii : resend limit exceeded for phase1 exchange
21/04/29 06:45:09 ii : phase1 removal before expire time
21/04/29 06:45:09 DB : phase1 deleted ( obj count = 0 )
21/04/29 06:45:09 DB : policy not found
21/04/29 06:45:09 DB : policy not found
21/04/29 06:45:09 DB : policy not found
21/04/29 06:45:09 DB : policy not found
21/04/29 06:45:09 DB : policy not found
21/04/29 06:45:09 DB : policy not found
21/04/29 06:45:09 DB : removing tunnel config references
21/04/29 06:45:09 DB : removing tunnel phase2 references
21/04/29 06:45:09 DB : removing tunnel phase1 references
21/04/29 06:45:09 DB : tunnel deleted ( obj count = 0 )
21/04/29 06:45:09 DB : removing all peer tunnel references
21/04/29 06:45:09 DB : peer deleted ( obj count = 0 )
21/04/29 06:45:09 ii : ipc client process thread exit ...
21/04/29 06:45:56 ii : hard halt signal received, shutting down
21/04/29 06:45:56 ii : ipc server process thread exit ...
21/04/29 06:45:56 ii : network process thread exit ...
21/04/29 06:45:56 ii : pfkey process thread exit ...Meine Befürchtung war zunächst, dass es irgendwie an meinem eigenen Router oder der generellen Internetverbindung liegt, aber ich glaube, dass ich das inzwischen ausschließen kann, denn ich habe noch folgende Versuche unternommen:
- Frische Installation auf leistungsschwachen Windows 8 Laptop in meinem Heimnetzwerk (über WLAN verbunden): negotiation timout occurred
- Frische Installation auf ausgeliehenen, recht leistungsstarken Windows 10 Laptop in meinem Heimnetzwerk (über WLAN verbunden): tunnel enabled - es funktioniert!
Und jetzt das besonders kuriose:
- Frische Installation auf Windows XP in einer virtuellen Maschine, die auf meinem eigenen Desktop-PC läuft (Der XP-Mode von Windows 7 Ultimate): tunnel enabled - Auch hier funktioniert es! Ich testete, ob ich sogar den Remote-PC ansteuern könnte, aber das ergab die Meldung: "Der Remotecomputer erfordert die Authentifizierung auf Netzwerkebene. Diese Funktion wird von Ihrem Computer nicht unterstützt."
Insbesondere der letzte Test spricht ja eigentlich dafür, dass meine LAN-Verbindung zwischen Desktop-PC und Router kein Problem sein dürfte. Und durch die erfolgreichen Tests auf Windows 10 Laptop und XP VM würde ich Probleme mit Unitymedia generell ausschließen.
Was bleibt ist mein eigener Windows 7 Desktop PC... Ich habe zwischen dem funktionierenden Status und den aktuellen Problemen nichts an meinem System verändert. Ein Blick in meine installierten Programme ergab lediglich ein automatisches Update von Google Chrome.
Die einzige Hilfestellung, die ich beim Googeln fand, war eine Deaktivierung des Microsoft Virtual WiFi Miniport-Adapters. Das tat ich auch über die Eingabeaufforderung, doch leider machte es keinen Unterschied.
Eine Systemwiederherstellung ist so weit zurück leider nicht mehr möglich.
Ich bin mit meinem Latein nun ziemlich am Ende und würde eine Lösung nur noch darin sehen ein anderes Gerät zu verwenden. Ich würde mich freuen, wenn hier vielleicht noch jemand hilfreiche Lösungsansätze für mich hätte.
LG
Vic
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: 666308
Url: https://administrator.de/contentid/666308
Printed on: April 18, 2024 at 12:04 o'clock
12 Comments
Latest comment
Du hast Recht mit deiner Vermutung das es nicht an der Infrastruktur selber liegt. Entscheidend ist die Fehlermeldung: "received peer NO-PROPOSAL-CHOSEN notification"
Diese besagt das sich Client und Server in der IPsec Phase 1 nicht auf ein gemeinsames Schlüsselverfahren einigen konnten. Das was dein Client dem Server vorschlägt oder andersrum passt nicht was die jeweilige Gegenstelle hat. Z.B. der eine macht AES 128 mit SHA 1 der andere will aber AES 256 mit SHA 256 oder in irgendeiner anderen Kombination.
Normal sollte sich das niemals verstellen. Warum es bei dir nicht mehr korrespondiert kann man jetzt nur wild raten.
Das ist aber der Knackpunkt an dem es liegt.
Logs zu lesen hilft also....
Ob du jetzt als Nicht Profi bei dem es schon am Latein an sich hapert etwas damit anfangen kannst ist jetzt die Frage. Ggf. hilft die IT Abteilung wenn sie genau wissen müssen wonach sie suchen sollen...?!
Das sie dich mit einem Win 7 PC überhaupt noch ins Firmen VPN lassen hat ja auch schon eine gewisse Brisanz die man besser nicht kommentiert.
Diese besagt das sich Client und Server in der IPsec Phase 1 nicht auf ein gemeinsames Schlüsselverfahren einigen konnten. Das was dein Client dem Server vorschlägt oder andersrum passt nicht was die jeweilige Gegenstelle hat. Z.B. der eine macht AES 128 mit SHA 1 der andere will aber AES 256 mit SHA 256 oder in irgendeiner anderen Kombination.
Normal sollte sich das niemals verstellen. Warum es bei dir nicht mehr korrespondiert kann man jetzt nur wild raten.
Das ist aber der Knackpunkt an dem es liegt.
Logs zu lesen hilft also....
Ob du jetzt als Nicht Profi bei dem es schon am Latein an sich hapert etwas damit anfangen kannst ist jetzt die Frage. Ggf. hilft die IT Abteilung wenn sie genau wissen müssen wonach sie suchen sollen...?!
Das sie dich mit einem Win 7 PC überhaupt noch ins Firmen VPN lassen hat ja auch schon eine gewisse Brisanz die man besser nicht kommentiert.
1
Moin,
ich fürchte, es liegt doch eher an Deinem Internetanschluss via Kabel. Dazu wäre aber ein paar weitere Informationen nötig:
- Hast Du mit dem geliehenen Windows 10 Laptop mal einen Verbindungsversuch auf einen Server in der Firma unternommen?
- Ich nehme an, dass es sich um einen Unitymedia/Vodafone Privatkundenanschluss ohne öffentliche IPv4 handelt? Da gibt es das Problem häufiger, da einfach ausgedrückt der Rückweg Firma -> eigewählter PC nicht gefunden wird. Dafür spricht auch Dein Logfile und dass Du zuerst den Fehler "Gateway not responding" bekommen hast.
- Erlaubt Deine Firma tatscähclih, dass Du Dich mit einem potentiell unsicher Windows 7 Gerät einwählst?
- Überprüfe mal nach augenscheinlich erfolgreicher Einwahl im VPN Connect Dialog das "Network"-Tab. Was steht da unter "Security Associations" und unter "Tunnel"?
- Haben die Kollegen, bei denen es funktioniert, alle auch einen Unitymedia-Anschluss und wirklich das geliche Setup (auch von der Hardware)?
Als Gegenprobe könntest Du es auch mal über einen Handy-Hotspot versuchen, da dann aber mit Verbindungsversuch in die Firma (Terminalserver o.ä.)
Gruß
cykes
ich fürchte, es liegt doch eher an Deinem Internetanschluss via Kabel. Dazu wäre aber ein paar weitere Informationen nötig:
- Hast Du mit dem geliehenen Windows 10 Laptop mal einen Verbindungsversuch auf einen Server in der Firma unternommen?
- Ich nehme an, dass es sich um einen Unitymedia/Vodafone Privatkundenanschluss ohne öffentliche IPv4 handelt? Da gibt es das Problem häufiger, da einfach ausgedrückt der Rückweg Firma -> eigewählter PC nicht gefunden wird. Dafür spricht auch Dein Logfile und dass Du zuerst den Fehler "Gateway not responding" bekommen hast.
- Erlaubt Deine Firma tatscähclih, dass Du Dich mit einem potentiell unsicher Windows 7 Gerät einwählst?
- Überprüfe mal nach augenscheinlich erfolgreicher Einwahl im VPN Connect Dialog das "Network"-Tab. Was steht da unter "Security Associations" und unter "Tunnel"?
- Haben die Kollegen, bei denen es funktioniert, alle auch einen Unitymedia-Anschluss und wirklich das geliche Setup (auch von der Hardware)?
Als Gegenprobe könntest Du es auch mal über einen Handy-Hotspot versuchen, da dann aber mit Verbindungsversuch in die Firma (Terminalserver o.ä.)
Gruß
cykes
1
Moin,
@cykes
Gegen die UM/ VF-Breitbandanbindung spricht doch aber sein folgender Test:
@cykes
Gegen die UM/ VF-Breitbandanbindung spricht doch aber sein folgender Test:
Und jetzt das besonders kuriose:
- Frische Installation auf Windows XP in einer virtuellen Maschine, die auf meinem eigenen Desktop-PC läuft (Der XP-Mode von Windows 7 Ultimate): tunnel enabled - Auch hier funktioniert es! Ich testete, ob ich sogar den Remote-PC ansteuern könnte, aber das ergab die Meldung: "Der Remotecomputer erfordert die Authentifizierung auf Netzwerkebene. Diese Funktion wird von Ihrem Computer nicht unterstützt."
Insbesondere der letzte Test spricht ja eigentlich dafür, dass meine LAN-Verbindung zwischen Desktop-PC und Router kein Problem sein dürfte. Und durch die erfolgreichen Tests auf Windows 10 Laptop und XP VM würde ich Probleme mit Unitymedia generell ausschließen.
- Frische Installation auf Windows XP in einer virtuellen Maschine, die auf meinem eigenen Desktop-PC läuft (Der XP-Mode von Windows 7 Ultimate): tunnel enabled - Auch hier funktioniert es! Ich testete, ob ich sogar den Remote-PC ansteuern könnte, aber das ergab die Meldung: "Der Remotecomputer erfordert die Authentifizierung auf Netzwerkebene. Diese Funktion wird von Ihrem Computer nicht unterstützt."
Insbesondere der letzte Test spricht ja eigentlich dafür, dass meine LAN-Verbindung zwischen Desktop-PC und Router kein Problem sein dürfte. Und durch die erfolgreichen Tests auf Windows 10 Laptop und XP VM würde ich Probleme mit Unitymedia generell ausschließen.
... "Tunnel enabled" heißt noch lang nicht tunnel working - also, dass auch Daten/Verbindungen durch den Tunnel funktionieren. Deswegen mein Hinweis bei "tunnel enabled" mal unter dem Network-Tab zu schauen, wenn nur der "Failed" Zähler bei bspw. einem ping oder einer RDP-Verbindung hochzählt, gehen keine Daten durch den Tunnel.
- also, dass auch Daten/Verbindungen durch den Tunnel funktionieren. Deswegen mein Hinweis bei "tunnel enabled" mal unter dem Network-Tab zu schauen, wenn nur der "Failed" Zähler bei bspw. einem ping oder einer RDP-Verbindung hochzählt, gehen keine Daten durch den Tunnel.
Hallo cykes, danke für deine Nachricht, ich versuche mal auf alles einzugehen, bin aber leider teilweise überfragt.
- Ich bin nicht sicher, ob ich deine Rückfrage zum Windows 10 Laptop richtig deute. Ich kann mich über diesen erfolgreich mit dem VPN verbinden und auch auf meinen Remote-PC zugreifen. Heißt das nicht im Endeffekt, dass ich eine Verbindung zu einem "Server in der Firma" herstellen kann?
- Ja, es ist ein UM/Vodafone Privatanschluss. Ob dieser jetzt "ohne öffentliche IPv4" ist - keine Ahnung... In den Router-Einstellungen lese ich nur von einer IPv6 Adresse. Kann ich das irgendwie nachvollziehen?
- Die ganze Home Office Geschichte sollte anfangs temporär sein (und zieht sich jetzt aus bekannten Gründen immer weiter), da wurde das mit meinem Privat-PC durchgewunken. Früher oder später soll ich wohl einen eigenen Laptop fürs Home Office erhalten. Interessanterweise bekomme ich für Windows 7 nach wie vor regelmäßig größere Updates, also so ganz scheint der Support auch noch nicht abgestorben zu sein.
- "Nach augenscheinlich erfolgreicher Einwahl" im XP Mode sieht es wie folgt aus:
Security Associations:
Established: 0
Expired: 0
Failed: 0
Tunnel:
Status: Connected
Remote Host: [IP-Adresse]
Transport Used: NAT-T v03 / IKE | ESP
IKE Fragmentation: Disabled
Dead Peer Detection: Enabled
- Oh, nein, mit identischem Setup meinte ich lediglich, dass das gleiche Tool und die gleiche Verbindungsmethode genutzt wird. Ein User ist tatsächlich auch bei Unitymedia/Vodafone, aber nicht alle. Die Hardware ist unterschiedlich und die Betriebssysteme ebenfalls.
- Für den Test mit dem Handy-Hotspot mangelt es leider an einer WLAN-Antenne, hätte es sonst auch so schon mal versucht über WLAN, statt über LAN, mit meinem Router zu verbinden.
LG,
Vic
- Ich bin nicht sicher, ob ich deine Rückfrage zum Windows 10 Laptop richtig deute. Ich kann mich über diesen erfolgreich mit dem VPN verbinden und auch auf meinen Remote-PC zugreifen. Heißt das nicht im Endeffekt, dass ich eine Verbindung zu einem "Server in der Firma" herstellen kann?
- Ja, es ist ein UM/Vodafone Privatanschluss. Ob dieser jetzt "ohne öffentliche IPv4" ist - keine Ahnung... In den Router-Einstellungen lese ich nur von einer IPv6 Adresse. Kann ich das irgendwie nachvollziehen?
- Die ganze Home Office Geschichte sollte anfangs temporär sein (und zieht sich jetzt aus bekannten Gründen immer weiter), da wurde das mit meinem Privat-PC durchgewunken. Früher oder später soll ich wohl einen eigenen Laptop fürs Home Office erhalten. Interessanterweise bekomme ich für Windows 7 nach wie vor regelmäßig größere Updates, also so ganz scheint der Support auch noch nicht abgestorben zu sein.
- "Nach augenscheinlich erfolgreicher Einwahl" im XP Mode sieht es wie folgt aus:
Security Associations:
Established: 0
Expired: 0
Failed: 0
Tunnel:
Status: Connected
Remote Host: [IP-Adresse]
Transport Used: NAT-T v03 / IKE | ESP
IKE Fragmentation: Disabled
Dead Peer Detection: Enabled
- Oh, nein, mit identischem Setup meinte ich lediglich, dass das gleiche Tool und die gleiche Verbindungsmethode genutzt wird. Ein User ist tatsächlich auch bei Unitymedia/Vodafone, aber nicht alle. Die Hardware ist unterschiedlich und die Betriebssysteme ebenfalls.
- Für den Test mit dem Handy-Hotspot mangelt es leider an einer WLAN-Antenne, hätte es sonst auch so schon mal versucht über WLAN, statt über LAN, mit meinem Router zu verbinden.
LG,
Vic
Da hats du grundsätzlich recht.
Aber er baut aus der XP-Kiste heraus den Tunnel auf, will sich per RDP zum Zielsystem verbinden und erhält dann die Info (richtigerweise), dass eine Authentifizierung auf Netzwerkebene erforderlich ist. Für mein Verständnis steht somit der Tunnel und "wir" sind einen Layer weiter!?
Ich hatte nämlich auch erst auf ein Problem am Breitbandanschluss (BBA) getippt, ggf. verursacht durch CGN - aber obige Meldung zeigt ja, dass er "trotzdem" raus kommt.
Wobei natürlich wieder deine Theorie dafür spricht, dass ein frisches Win8 selbige Probleme hat.
Generell kann man aber - wie von dir schon angeregt - mal ein Wechsel des BBA testen. Entweder Hotspot vom Handy (Gefahr durch CGN?) oder mal eben zum Kumpel/ Nachbarn huschen (natürlich Abstandskonform..) und dort einmal testen. Ggf. sogar mal zwei verschiedene Leute ansteuern - einmal mit Kabel-Anschluss einmal mit xDSL bzw. FTTB/ FTTH
Aber er baut aus der XP-Kiste heraus den Tunnel auf, will sich per RDP zum Zielsystem verbinden und erhält dann die Info (richtigerweise), dass eine Authentifizierung auf Netzwerkebene erforderlich ist. Für mein Verständnis steht somit der Tunnel und "wir" sind einen Layer weiter!?
Ich hatte nämlich auch erst auf ein Problem am Breitbandanschluss (BBA) getippt, ggf. verursacht durch CGN - aber obige Meldung zeigt ja, dass er "trotzdem" raus kommt.
Wobei natürlich wieder deine Theorie dafür spricht, dass ein frisches Win8 selbige Probleme hat.
Generell kann man aber - wie von dir schon angeregt - mal ein Wechsel des BBA testen. Entweder Hotspot vom Handy (Gefahr durch CGN?) oder mal eben zum Kumpel/ Nachbarn huschen (natürlich Abstandskonform..) und dort einmal testen. Ggf. sogar mal zwei verschiedene Leute ansteuern - einmal mit Kabel-Anschluss einmal mit xDSL bzw. FTTB/ FTTH
Zitat von @VictorStagnetti:
- Für den Test mit dem Handy-Hotspot mangelt es leider an einer WLAN-Antenne, hätte es sonst auch so schon mal versucht über WLAN, statt über LAN, mit meinem Router zu verbinden.
Das erkläre einmal bitte!?- Für den Test mit dem Handy-Hotspot mangelt es leider an einer WLAN-Antenne, hätte es sonst auch so schon mal versucht über WLAN, statt über LAN, mit meinem Router zu verbinden.
Dein Laptop hat keine integrierte WLAN-Karte?
Das wurde doch "serienmäßig" mit den Intel-Centrinos eingeführt - also lange vor Windows 7!?
Ansonsten kannst du dein Handy auch per Kabel mit dem Laptop verbinden und darüber den Hotspot betreiben - sofern das Handy das mitmacht.
Beim Apfel: https://support.apple.com/de-de/HT204023
Beim Droiden: https://www.giga.de/apps/android-os/tipps/tethering-mit-android-so-verbi ...
Ich soll es ja schätzungsweise mit dem Windows 7 Desktop-PC ausprobieren, oder? Daher keine integrierte WLAN-Karte, nein. Der Versuch wäre höchstens mit dem Windows 8 Laptop möglich (welchen ich letztendlich nicht verwenden wollen würde, da dieser recht schwach ist).
Mea culpa
Dein Windows7 ist ja ein PC, kein Laptop ^^
Dann verbinde das Handy per USB und nutze auf diese Weise den Hotspot.
Dein Windows7 ist ja ein PC, kein Laptop ^^
Dann verbinde das Handy per USB und nutze auf diese Weise den Hotspot.
1
Okay, danke für die Tipps! Sowohl der Windows 8 Laptop über mobilen Hotspot, als auch der Windows 7 Desktop-PC über USB-Tethering ergeben "negotiation tim(e)out occurred". Am Smartphone waren nur mobile Daten eingeschaltet und WLAN deaktiviert. Die LAN-Verbindung, bzw. mein Router, kann damit als Ursache definitiv ausgeschlossen werden, denke ich.
Bleibt also dann wie oben schon vermutet an der Inkonsistenz der IPsec Phase 1 Verschlüsselungs Algorythmen zwischen Server und Client !
Die IT Abteilungskollegen sollten mal das Log des VPN Servers capturen wenn du mit deinem Client einen Tunnelaufbau versuchst. So würde man auch mal die andere Seite sehen was die an den Phase 1 Client Proposals nicht mag !
Dadurch das auch dein Client Setup hier fehlt ist ein tieferes Troubleshooting nicht möglich und eher dann Kristallkugel schaun weil leider konkretere Infos fehlen. Bei VPNs sind immer beide Seiten wichtig.
Die IT Abteilungskollegen sollten mal das Log des VPN Servers capturen wenn du mit deinem Client einen Tunnelaufbau versuchst. So würde man auch mal die andere Seite sehen was die an den Phase 1 Client Proposals nicht mag !
Dadurch das auch dein Client Setup hier fehlt ist ein tieferes Troubleshooting nicht möglich und eher dann Kristallkugel schaun weil leider konkretere Infos fehlen. Bei VPNs sind immer beide Seiten wichtig.
Zitat von @VictorStagnetti:
[...] Die LAN-Verbindung, bzw. mein Router, kann damit als Ursache definitiv ausgeschlossen werden, denke ich.
Diesen Rückschluß würde ich nicht zu 100% unterschreiben, aber wir werden es so hier nicht lösen können. Ich habe schon mehrstündige Diskussionen mit dem Vodafone/Unitymedia-Support geführt, die alle zu nichts führten. Im Vodafone Forum gibt es hunderte (wenn nicht mehr) Diskussionen mit demselben Fehlerbild. Bei einigen funktioniert es, bei anderen funktioniert es ab und an, bei wieder anderen gar nicht.[...] Die LAN-Verbindung, bzw. mein Router, kann damit als Ursache definitiv ausgeschlossen werden, denke ich.
Interessant wäre in Bezug auf das Windows 10 Laptop, ob es da immer funktioniert - ich hatte auch schon Fälle, wo es zu bestimmten Zeiten funktionierte und zu anderen (den wichtigen) (Arbeits-)Zeiten wieder nicht. Das lag dann ebenfalls am bereits erwähnten CGN, an dem Du/man aber nichts ändern kann. Auch gab es Fälle, wo der Router nicht geeignet war und der IPSec-Tunnel irgendwie geblockt wurde.
Du könntest auf Deinem PC nochmal probieren, den Shrewsoft VPN Client neu zu installieren, ich hatte auch schon Fälle, wo das (virtuelle) Netzwerkinterface nicht richtig installiert war und sich in der Folge deaktiviert hat. Entweder einfach nochmal drüberinstallieren oder - wenn das nichts hilft - deinstallieren und neu installieren. Wichtig bei der Installation ist auch noch, nicht die Professional auswählen, sonder ausschließlich die Standard-Versiuon nehmen, wenn man keine Lizenz für die Pro hat.
Den Rest kannst Du nur mit eurer IT klären, eventuell mal die .vpn Datei des Kollegen mit Unitymedia-Anschluss testen.
