da ich im Web, in diversen Foren, in der KB von Lancom und NCP und auch hier noch nichts zu meinem Problem gefunden habe, verzweifle ich ein wenig.
Ein Kunde mit einem Lancom 1721VPN lässt für 3-4 Benutzer eine VPN-Einwahl zu. Jeder hat einen identischen Vertrag und UMTS-Stick. Die Lancom VPN-Client Versionen unterscheiden sich, je nachdem wann das entsprechende Gerät installiert wurde.
Ein neuer User mit einem neuen Notebook (Win7) sollte diesen Zugang ebenfalls bekommen -> Konfiguration erstellt mit 1-Klick und in einen Client Version 2.23 eingespielt.
Das funktioniert per LAN und WLAN auch super (die Verbindungseinstellung steht übrigens wie bei den anderen Usern auf "LAN (IP)"). Sobald der gute Mann aber UMTS auch nur aktiviert ist keine Einwahl mehr möglich. Auch wenn die vorher bestehende WLAN- oder LAN-Verbindung nicht getrennt wurde.
Die Vermutung liegt einfach nahe, dass irgendetwas einen Port oder ein Protokoll blockt, sobald die UMTS-Verbindung gestartet wird (z.B. IPSEC - 500)
Leider fehlt es mir ein wenig an Erfahrung um dieses Problem weiter einzugrenzen. Die Windows Firewall habe ich testweise komplett deaktiviert, das Problem ändert sich aber nicht.
Ich scheitere an der Meldung "ERROR - 4037: IKE(phase2):Waiting for message2, cleared by phase1"
Und irgendwie habe ich mich so festgefahren dass ich das Problem nicht mal mehr erkennen würde wenn ein dicker roter Pfeil auf die Lösung zeigen würde
Vielleicht hat hier noch jemand eine schlaue Idee.
Zuletzt geändert von MirkoS am 22 Aug 2013, 16:25, insgesamt 1-mal geändert.
Achja... hier ist mal noch ein Log von der funktionierenden und der nicht funktionierenden Verbindung:
Nicht funktionierende Verbindung über UMTS
8/22/2013 11:52:11 AM System: LinkStatus Change - 100,NDISWAN
8/22/2013 11:52:11 AM System: Ip Address Change - 203,NDISWAN
8/22/2013 11:52:11 AM Firewall: adapter <NDISWAN> is outside the friendly net
8/22/2013 11:53:00 AM System: Protecting RAS adapter - 0
8/22/2013 11:53:00 AM System: Protecting RAS adapter - 0
8/22/2013 11:53:00 AM System: Protecting RAS adapter - 0
8/22/2013 11:53:06 AM IPSec: Start building connection
8/22/2013 11:53:06 AM IPSec: DNSREQ: resolving GW=<x.no-ip.info> over lan:
8/22/2013 11:53:07 AM IPSec: DNSREQ: resolved ipadr: xxx.xxx.xxx.xxx
8/22/2013 11:53:07 AM Ike: Opening connection in PATHFINDER mode : VPN-FIRMA
8/22/2013 11:53:07 AM Ike: Outgoing connect request AGGRESSIVE mode - gateway=xx.xx.xx.xx : VPN-FIRMA
8/22/2013 11:53:07 AM Ike: XMIT_MSG1_AGGRESSIVE - VPN-FIRMA
8/22/2013 11:53:08 AM Ike: RECV_MSG2_AGGRESSIVE - VPN-FIRMA
8/22/2013 11:53:08 AM Ike: IKE phase I: Setting LifeTime to 28800 seconds
8/22/2013 11:53:08 AM Ike: IkeSa negotiated with the following properties -
8/22/2013 11:53:08 AM IPSec: Final Tunnel EndPoint is:xxx.xxx.xxx.xxx
8/22/2013 11:53:08 AM Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=128
8/22/2013 11:53:08 AM Ike: VPN-FIRMA ->Support for NAT-T version - 9
8/22/2013 11:53:08 AM Ike: Turning on NATD mode - VPN-FIRMA - 1
8/22/2013 11:53:08 AM Ike: XMIT_MSG3_AGGRESSIVE - VPN-FIRMA
8/22/2013 11:53:08 AM Ike: IkeSa negotiated with the following properties -
8/22/2013 11:53:08 AM Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=128
8/22/2013 11:53:08 AM Ike: Turning on DPD mode - VPN-FIRMA
8/22/2013 11:53:08 AM Ike: phase1:name(VPN-FIRMA) - connected
8/22/2013 11:53:08 AM SUCCESS: IKE phase 1 ready
8/22/2013 11:53:08 AM IPSec: Phase1 is Ready,AdapterIndex=203,IkeIndex=3,LocTepIpAdr=10.204.48.177,AltRekey=1
8/22/2013 11:53:09 AM IkeCfg: XMIT_IKECFG_REQUEST - VPN-FIRMA
8/22/2013 11:53:09 AM IkeCfg: RECV_IKECFG_REPLY - VPN-FIRMA
8/22/2013 11:53:09 AM IkeCfg: name <FOEG> - enter state open
8/22/2013 11:53:09 AM SUCCESS: IkeCfg ready
8/22/2013 11:53:09 AM IPSec: Quick Mode is Ready: IkeIndex = 00000003 , VpnSrcPort = 10954
8/22/2013 11:53:09 AM IPSec: Assigned IP Address: 192.168.1.227
8/22/2013 11:53:09 AM IPSec: Gateway IP Address: 0.0.0.0
8/22/2013 11:53:09 AM IPSec: DNS Server: 192.168.1.254
8/22/2013 11:53:09 AM IPSec: WINS Server: 192.168.1.254
8/22/2013 11:53:09 AM IkeQuick: XMIT_MSG1_QUICK - VPN-FIRMA
8/22/2013 11:53:28 AM Ike: NOTIFY : VPN-FIRMA : SENT : NOTIFY_MSG_R_U_HERE : 36136
8/22/2013 11:53:29 AM IkeQuick: phase2:name(VPN-FIRMA) - error - cleared by phase1
8/22/2013 11:53:29 AM ERROR - 4037: IKE(phase2):Waiting for message2, cleared by phase1 - VPN-FIRMA.
8/22/2013 11:53:29 AM IpsDial: From Ikemgr - Remote is denied request for an IPSec SA, AdapterIndex=203
8/22/2013 11:53:29 AM IPSec: Disconnected from VPN-FIRMA on channel 1.
8/22/2013 11:53:42 AM System: LinkStatus Change - 101,NDISWAN
8/22/2013 11:53:51 AM Firewall: adapter <NDISWAN> is outside the friendly net
Funktionierende Verbindung über LAN oder WLAN
8/22/2013 11:54:29 AM IPSec: Start building connection
8/22/2013 11:54:29 AM IPSec: DNSREQ: resolving GW=<x.no-ip.info> over lan:
8/22/2013 11:54:29 AM IPSec: DNSREQ: resolved ipadr: xxx.xxx.xxx.xxx
8/22/2013 11:54:29 AM Ike: Opening connection in PATHFINDER mode : VPN-FIRMA
8/22/2013 11:54:29 AM Ike: Outgoing connect request AGGRESSIVE mode - gateway=xx.xxx.xx.xx : VPN-FIRMA
8/22/2013 11:54:29 AM Ike: XMIT_MSG1_AGGRESSIVE - VPN-FIRMA
8/22/2013 11:54:29 AM Ike: RECV_MSG2_AGGRESSIVE - VPN-FIRMA
8/22/2013 11:54:29 AM Ike: IKE phase I: Setting LifeTime to 28800 seconds
8/22/2013 11:54:29 AM Ike: IkeSa negotiated with the following properties -
8/22/2013 11:54:29 AM IPSec: Final Tunnel EndPoint is:xxx.xxx.xxx.xxx
8/22/2013 11:54:29 AM Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=128
8/22/2013 11:54:29 AM Ike: VPN-FIRMA ->Support for NAT-T version - 9
8/22/2013 11:54:29 AM Ike: Turning on NATD mode - VPN-FIRMA - 1
8/22/2013 11:54:29 AM Ike: XMIT_MSG3_AGGRESSIVE - VPN-FIRMA
8/22/2013 11:54:29 AM Ike: IkeSa negotiated with the following properties -
8/22/2013 11:54:29 AM Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=128
8/22/2013 11:54:29 AM Ike: Turning on DPD mode - VPN-FIRMA
8/22/2013 11:54:29 AM Ike: phase1:name(VPN-FIRMA) - connected
8/22/2013 11:54:29 AM SUCCESS: IKE phase 1 ready
8/22/2013 11:54:29 AM IPSec: Phase1 is Ready,AdapterIndex=200,IkeIndex=4,LocTepIpAdr=192.168.1.63,AltRekey=1
8/22/2013 11:54:31 AM IkeCfg: XMIT_IKECFG_REQUEST - VPN-FIRMA
8/22/2013 11:54:31 AM IkeCfg: RECV_IKECFG_REPLY - VPN-FIRMA
8/22/2013 11:54:31 AM IkeCfg: name <FOEG> - enter state open
8/22/2013 11:54:31 AM SUCCESS: IkeCfg ready
8/22/2013 11:54:31 AM IPSec: Quick Mode is Ready: IkeIndex = 00000004 , VpnSrcPort = 10954
8/22/2013 11:54:31 AM IPSec: Assigned IP Address: 192.168.1.213
8/22/2013 11:54:31 AM IPSec: Gateway IP Address: 0.0.0.0
8/22/2013 11:54:31 AM IPSec: DNS Server: 192.168.1.254
8/22/2013 11:54:31 AM IPSec: WINS Server: 192.168.1.254
8/22/2013 11:54:31 AM IkeQuick: XMIT_MSG1_QUICK - VPN-FIRMA
8/22/2013 11:54:31 AM IkeQuick: RECV_MSG2_QUICK - VPN-FIRMA
8/22/2013 11:54:31 AM IkeQuick: Turning on PFS mode(VPN-FIRMA) with group 2
8/22/2013 11:54:31 AM IkeQuick: XMIT_MSG3_QUICK - VPN-FIRMA
8/22/2013 11:54:31 AM IkeQuick: phase2:name(VPN-FIRMA) - connected
8/22/2013 11:54:31 AM SUCCESS: Ike phase 2 (quick mode) ready
8/22/2013 11:54:31 AM IPSec: Created an IPSEC SA with the following characteristics -
8/22/2013 11:54:31 AM IpSrcRange=[192.168.1.213-192.168.1.213],IpDstRange=[192.168.1.0-192.168.1.255],IpProt=0,SrcPort=0,DstPort=0
8/22/2013 11:54:31 AM IPSec: connected: LifeDuration in Seconds = 20160 and in KiloBytes = 0
8/22/2013 11:54:31 AM IPSec: Connected to VPN-FIRMA on channel 1.
8/22/2013 11:54:31 AM PPP(Ipcp): connected to VPN-FIRMA with IP Address: 192.168.1.213
8/22/2013 11:54:31 AM SUCCESS: IpSec connection ready
8/22/2013 11:54:33 AM SUCCESS: Link -> <VPN-FIRMA> IP address assigned to IP stack - link is operational.
Ich habe keine Lösung aber beim Vergleich fällt folgendes auf:
Geht nicht: 8/22/2013 11:53:08 AM IPSec: Phase1 is Ready,AdapterIndex=203,IkeIndex=3,LocTepIpAdr=10.204.48.177,AltRekey=1
Geht: 8/22/2013 11:54:29 AM IPSec: Phase1 is Ready,AdapterIndex=200,IkeIndex=4,LocTepIpAdr=192.168.1.63,AltRekey=1
Der neue Client hat lokal ne 10.x Adresse, der Alte funktionierende 192.168.1.x (also IP die mit dem VPN Lan zur Sub passt)
Abbrechen tut das dann hier:
8/22/2013 11:53:09 AM IkeQuick: XMIT_MSG1_QUICK - VPN-FIRMA
8/22/2013 11:53:28 AM Ike: NOTIFY : VPN-FIRMA : SENT : NOTIFY_MSG_R_U_HERE : 36136
beim funktionierenden sieht das so aus:
8/22/2013 11:53:09 AM IkeQuick: XMIT_MSG1_QUICK - VPN-FIRMA
8/22/2013 11:54:31 AM IkeQuick: RECV_MSG2_QUICK - VPN-FIRMA
Außerdem fällt auf das du beim unkenntlich machen der Gate Adresse mit unterschiedlichen vielen xxx arbeitest. Tippfehler beim überschreiben oder ist bei der einen wirklich xx und bei der anderen xxx ?
Geht nicht: 8/22/2013 11:53:07 AM Ike: Outgoing connect request AGGRESSIVE mode - gateway=xx.xx.xx.xx : VPN-FIRMA
Geht: 8/22/2013 11:54:29 AM Ike: Outgoing connect request AGGRESSIVE mode - gateway=xx.xxx.xx.xx : VPN-FIRMA
AndreasL hat geschrieben:Ich habe keine Lösung aber beim Vergleich fällt folgendes auf:
Geht nicht: 8/22/2013 11:53:08 AM IPSec: Phase1 is Ready,AdapterIndex=203,IkeIndex=3,LocTepIpAdr=10.204.48.177,AltRekey=1
Geht: 8/22/2013 11:54:29 AM IPSec: Phase1 is Ready,AdapterIndex=200,IkeIndex=4,LocTepIpAdr=192.168.1.63,AltRekey=1
Der neue Client hat lokal ne 10.x Adresse, der Alte funktionierende 192.168.1.x (also IP die mit dem VPN Lan zur Sub passt)
Außerdem fällt auf das du beim unkenntlich machen der Gate Adresse mit unterschiedlichen vielen xxx arbeitest. Tippfehler beim überschreiben oder ist bei der einen wirklich xx und bei der anderen xxx ?
Das mit der Anzahl der x ist meine eigene Schlamperei
Und die 10.204.48.177 hat er irgendwie durch den im Falle UMTS verwendeten NDISWAN-Adapter erhalten. Aber auch das ist legitim (so eigenartig es auch aussieht).
Ich habe das Problem gerade (zumindest scheinbar) gelöst: Wenn man den Wald vor lauter Bäumen nicht mehr sieht: in den erweiterten Netzwerkverbindungen habe ich bei den Verbindungen die LAN-Adapter des Lancom nach ganz unten verschoben (direkt vor [RAS-Verbindungen])
Nun bleibt die Verbindung bestehen und bringt keine Fehler mehr. Noch haben wir es nicht geschafft sein Laufwerk zu verbinden, aber das hängt mit anderen Faktoren zusammen.
Trotzdem vielen Dank für die versuchte Lösungshilfe
Hi,
Wenn du 2 Logs vergleichen möchtest eignet sich sehr gut ein Programm verwenden, das einem Unterschied aufzeigt.
Ich verwende da meist: http://meldmerge.org/
Damit hättest du das "8/22/2013 11:53:28 AM Ike: NOTIFY : VPN-FIRMA : SENT : NOTIFY_MSG_R_U_HERE : 36136" vielleicht auch selber gefunden.
Dieser Logeintrag bestagt das du keine Antwort seit längerer Zeit erhalten hast und somit wohl das Lancom aus einem gewissen Grund nicht geantwortet hat.
Nun, da du schon das Grundproblem gelöst hast, brauchst du dieser Herrangehensweise jetzt nicht, aber du kannst sie dir ja merken.
Gruß
Erst wenn der letzte Baum gerodet, der letzte Fluss vergiftet, der letzte Fisch gefangen ist, werdet Ihr merken, dass man Geld nicht essen kann.
Ein Optimist, mit entäuschten Idealen, hat ein besseres Leben als ein Pessimist der sich bestätigt fühlt.
MariusP hat geschrieben:
Damit hättest du das "8/22/2013 11:53:28 AM Ike: NOTIFY : VPN-FIRMA : SENT : NOTIFY_MSG_R_U_HERE : 36136" vielleicht auch selber gefunden.
Dieser Logeintrag bestagt das du keine Antwort seit längerer Zeit erhalten hast und somit wohl das Lancom aus einem gewissen Grund nicht geantwortet hat.
Danke für die Info.
Ich wusste ja, dass an der Stelle keine MSG mehr kommt... das Problem war der Grund dafür. Ich ging inzwischen von einem Block durch eine Firewall, einen Virescanner, o.ä. aus, da das Problem ja NUR bei bestehender UMTS-Verbindung bestand.
Dass es eine Einstellung ist, die ich bei Problemen mit der Datenübertragung (Rx oder Tx) selbst schon mehrere Male umsetzen musste ist mir nicht in den Sinn gekommen.
