4
Problem mit VPN-Zugang über WinXP-Client und DLINK DFL 800 - Mitarbeiter Roaming User und Lan-Lan gleichzeitig - Namensauflösungsproblem?
Hallo Formumsteilnehmer,
ich laufe hier seit einer Woche im Kreis herum mit diesem Problem, daher versuche ich es jetzt einmal hier.
Situaltion ist folgende:
Wir haben seit einiger Zeit folgende VPN-Infrastruktur:
-DLink DFL-800 als L2TP /IPSEC Server mit PSK. WAN über DSL-Modem über Telekom, intern 192.168.100.0/24 , Für die VPN-User zusätzlich 192.168.102.0/24
-Mehrere Anwender mit Laptop WXP SP3, die sich über den WXP-VPN-Client verbinden.
-Auf den Laptops Office 2003, greifen über VPN auf Exchange Server 2000 zu
Bei einem Anwender gibt es seit letzter Woche Probleme, beim Start von Outlok dauert es mehrere Minuten, bis die Verbindung zum Exchange-Server steht. Die VPN-Verbindung steht in allen Fällen problemlos in Sekunden. Ich kann von der Maschine auch immer ins lokale Netzt pingen.
Der Anwender ist leider ziemlich variabel, er arbeitet teils im Lan, teils über UMTS und oft hängt er den Laptop zuhause und an anderen Orten in eine kleines Netzwerk mit Router hinein. Der Fehler tritt nur auf, wenn er in einem anderen Netzwerk arbeitet, per umts steht die Verbindung von Outlook zu Exchange sofort.
In der VPN-Konfiguration habe ich den User mit fester IP aus dem VPN-Pool hinterlegt, 192.168.102.105, wenn er lokal arbeitet erhält er vom DHCP die Adresse 192.168.100.130.
Folgendes habe ich schon festgestellt:
- Wenn sich der Kollege per UMTS einwählt, kann ich Ihn aus meinem Netz mit der IP-Adresse pingen. Wenn er in einem anderen Netz hängt nicht.
Wenn er mit UMTS (da gibts keine Probleme) eingewählt ist löst der Laptop für sich die VPN-Adresse 192.168.102.105 auf. Wenn er in einem anderen Netz hängt, Pingt er sich selbst mit der lokalen Adresse, z.B. 192.168.1.3. .
-Auf der Firewall finde ich, wenn der Rechner in einem anderen Lan steht, massenhaft solcher Logeinträge:
2009-06-09 17:47:24 Local0.Warning 192.168.100.40 [2009-06-09 17:47:47] FW: RULE: prio=3 id=06000051 rev=1 event=ruleset_drop_packet action=drop rule=Default_Access_Rule recvif=L2TP_Server srcip=192.168.1.3 destip=255.255.255.255 ipproto=UDP ipdatalen=68 srcport=1569 destport=22289 udptotlen=68
Ich interpretiere das so, dass der Laptop als 192.168.1.3, also seiner lokalen Adresse, ins Netz kommen will. Da das Netz unbekannt ist wird alles gedroppt. Es steht ja auch keine Route vom lokalen Netz zu diesem, soll und kann es auch nicht geben, da es immer ein anderes sein kann (Hotel, Heim, Praxis..)
Im Prinzip denke ich, dass er sich in einem anderen netz nicht mehr als Roaming user sieht, sondern irgendwie ein Lan-Lan einrichten will, was nicht konfiguriert ist.
Wie kann ich dem Laptop sagen, dass er bei einer aktiven VPN-Verbindung primär IMMER die VPN-Adresse nutzen soll, dass er nur als Roaming User arbeiten soll? Oder habe ich hier einen Denkfehler und das Problem ist ganz woanders?
- Auf dem Laptop verrät mir Route Print, dass die Standardroute korrekt über die VPN-Adresse läuft.
Folgendes habe ich schon versucht:
- Auf dem Laptop den Exchange-Server fest eigetragen, er löst auch die richtige Adresse auf.
- Auf dem Exchange Server Wins installiert und Wins und Netbios auf dem Laptop/Firewall konfiguriert. Ergebnis: Im Wins-Server steht der Name immer mit VPN-Adresse
- Auf dem Exchange-Server wird der Laptop immer mit der lokalen Adresse aufgelöst, anscheinend setzt der Laptop die nicht ynamisch im DNS-Server. Ich habe daher den Laptop auf dem Exchange-Server auch in der LMHOST eingetragen mit der VPN-Adresse, sodass zumindest auf diesem die Adresse vom Laptop korrekt aufgelöst wird.
Hat bisher alles nichts genützt.
Vielen Dank im Voraus !
Christoph
ich laufe hier seit einer Woche im Kreis herum mit diesem Problem, daher versuche ich es jetzt einmal hier.
Situaltion ist folgende:
Wir haben seit einiger Zeit folgende VPN-Infrastruktur:
-DLink DFL-800 als L2TP /IPSEC Server mit PSK. WAN über DSL-Modem über Telekom, intern 192.168.100.0/24 , Für die VPN-User zusätzlich 192.168.102.0/24
-Mehrere Anwender mit Laptop WXP SP3, die sich über den WXP-VPN-Client verbinden.
-Auf den Laptops Office 2003, greifen über VPN auf Exchange Server 2000 zu
Bei einem Anwender gibt es seit letzter Woche Probleme, beim Start von Outlok dauert es mehrere Minuten, bis die Verbindung zum Exchange-Server steht. Die VPN-Verbindung steht in allen Fällen problemlos in Sekunden. Ich kann von der Maschine auch immer ins lokale Netzt pingen.
Der Anwender ist leider ziemlich variabel, er arbeitet teils im Lan, teils über UMTS und oft hängt er den Laptop zuhause und an anderen Orten in eine kleines Netzwerk mit Router hinein. Der Fehler tritt nur auf, wenn er in einem anderen Netzwerk arbeitet, per umts steht die Verbindung von Outlook zu Exchange sofort.
In der VPN-Konfiguration habe ich den User mit fester IP aus dem VPN-Pool hinterlegt, 192.168.102.105, wenn er lokal arbeitet erhält er vom DHCP die Adresse 192.168.100.130.
Folgendes habe ich schon festgestellt:
- Wenn sich der Kollege per UMTS einwählt, kann ich Ihn aus meinem Netz mit der IP-Adresse pingen. Wenn er in einem anderen Netz hängt nicht.
Wenn er mit UMTS (da gibts keine Probleme) eingewählt ist löst der Laptop für sich die VPN-Adresse 192.168.102.105 auf. Wenn er in einem anderen Netz hängt, Pingt er sich selbst mit der lokalen Adresse, z.B. 192.168.1.3. .
-Auf der Firewall finde ich, wenn der Rechner in einem anderen Lan steht, massenhaft solcher Logeinträge:
2009-06-09 17:47:24 Local0.Warning 192.168.100.40 [2009-06-09 17:47:47] FW: RULE: prio=3 id=06000051 rev=1 event=ruleset_drop_packet action=drop rule=Default_Access_Rule recvif=L2TP_Server srcip=192.168.1.3 destip=255.255.255.255 ipproto=UDP ipdatalen=68 srcport=1569 destport=22289 udptotlen=68
Ich interpretiere das so, dass der Laptop als 192.168.1.3, also seiner lokalen Adresse, ins Netz kommen will. Da das Netz unbekannt ist wird alles gedroppt. Es steht ja auch keine Route vom lokalen Netz zu diesem, soll und kann es auch nicht geben, da es immer ein anderes sein kann (Hotel, Heim, Praxis..)
Im Prinzip denke ich, dass er sich in einem anderen netz nicht mehr als Roaming user sieht, sondern irgendwie ein Lan-Lan einrichten will, was nicht konfiguriert ist.
Wie kann ich dem Laptop sagen, dass er bei einer aktiven VPN-Verbindung primär IMMER die VPN-Adresse nutzen soll, dass er nur als Roaming User arbeiten soll? Oder habe ich hier einen Denkfehler und das Problem ist ganz woanders?
- Auf dem Laptop verrät mir Route Print, dass die Standardroute korrekt über die VPN-Adresse läuft.
Folgendes habe ich schon versucht:
- Auf dem Laptop den Exchange-Server fest eigetragen, er löst auch die richtige Adresse auf.
- Auf dem Exchange Server Wins installiert und Wins und Netbios auf dem Laptop/Firewall konfiguriert. Ergebnis: Im Wins-Server steht der Name immer mit VPN-Adresse
- Auf dem Exchange-Server wird der Laptop immer mit der lokalen Adresse aufgelöst, anscheinend setzt der Laptop die nicht ynamisch im DNS-Server. Ich habe daher den Laptop auf dem Exchange-Server auch in der LMHOST eingetragen mit der VPN-Adresse, sodass zumindest auf diesem die Adresse vom Laptop korrekt aufgelöst wird.
Hat bisher alles nichts genützt.
Vielen Dank im Voraus !
Christoph
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 118854
Url: https://administrator.de/contentid/118854
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
4 Kommentare
Neuester Kommentar
Das ist wie immer bei solchen Themen:
L2TP benutzt IPsec im ESP Modus für den Wirkdatentunnel damit rennt man in anderen Netzen immer in Probleme wenn dort eine NAT Firewall aktiv ist über die L2TP nicht rüberkann.
Mehrere Dinge sind nicht optimal in deinem Setup:
Befindet sich dein Benutzer in so einem Netz ist es unmöglich eine VPN Verbindung herzustellen.
Erheblich intelligenter wäre es gewesen andere IPs aus dem RFC-1918_Bereich zu verwenden mit denen eine VPN Dopplung so selten ist das sie quasi nicht vorkommt.
Also möglichst krumme Werte wie 172.27.100.0 /24 oder 172.19.30.0 /24 oder wenn 192.168. dann ganz krumme wie 192.168.243.0 /24 usw.
Damit hättest du den Konfilikt in den dieser User immer und immer wieder reinlaufen wird vermieden !
Deine Fehlermeldungen deuten immer auf eins dieser Probleme hin...
Da kommst du nur raus wenn dein VPN Server und Client sog. NAT Traversal supporten aber leider teilst du uns das ja nicht mit so das wir alle hier zum Raten verdammt sind
L2TP benutzt IPsec im ESP Modus für den Wirkdatentunnel damit rennt man in anderen Netzen immer in Probleme wenn dort eine NAT Firewall aktiv ist über die L2TP nicht rüberkann.
Mehrere Dinge sind nicht optimal in deinem Setup:
- Die Wahl von lokalen 192.168. Banalnetzen bei VPN Betrieb wie du es gemacht hast mit der .100 und .102 ist nicht gerade intelligent und zeugt davon das sich wenig bis keine Mühe bei der VPN Planung gemacht wurde ! Ob nun aus Unkenntniss oder Faulheit sei mal dahingestellt..
Befindet sich dein Benutzer in so einem Netz ist es unmöglich eine VPN Verbindung herzustellen.
Erheblich intelligenter wäre es gewesen andere IPs aus dem RFC-1918_Bereich zu verwenden mit denen eine VPN Dopplung so selten ist das sie quasi nicht vorkommt.
Also möglichst krumme Werte wie 172.27.100.0 /24 oder 172.19.30.0 /24 oder wenn 192.168. dann ganz krumme wie 192.168.243.0 /24 usw.
Damit hättest du den Konfilikt in den dieser User immer und immer wieder reinlaufen wird vermieden !
- Wenn in diesen Netzen eine NAT Firewall aktiv ist MUSS bei L2TP bzw. IPsec immer der Port UDP 500 und das IP Protokoll 50 (ESP) im Portforwarding stehen. Tut es das nicht ist ein VPN unmöglich aufzubauen. Private Netze haben das meist nie !
Deine Fehlermeldungen deuten immer auf eins dieser Probleme hin...
Da kommst du nur raus wenn dein VPN Server und Client sog. NAT Traversal supporten aber leider teilst du uns das ja nicht mit so das wir alle hier zum Raten verdammt sind
Hallo Aqui,
Vielen Dank für die Antwort,
Ich habe sowohl auf der Firewall Nat-T aktiviert als auch entsprechenden NAT-T-Registry-Keys auf dem Client gesetzt. Der VPN-Tunnel wird ja auch rasend schnell aufgebaut, ich kann auch Shares auf dem Fileserver mappen über den Tunnel, das ist das Problem mit hoher Wahrscheinlichkeit nicht. Die DFL 800 ist unsere zweite Firewall, die erste, DFL 200 , hatte nämlich kein NAT-T und deshalb ging da garnichts. Das ist jetzt völlig anders.
Den IP-Bereich sehe ich zwar auch nicht als optimal an, aber es gibt keinerlei Überschneidungen zu den erxternen Netzen. Wir haben die klassischen Heimnetze auf der anderen Seite, 192.168.1.0 und an anderen Standorten auch die 192.168.9.0, aber nirgendwo 192.168.xxx(dreistellig. Die oben angegebenen Adressen sind auch nicht echt, ich hab mir 2 Fantasienetze ausgedacht. Die Echten sind zwar im 192.168. Bereich, aber wesentlich krummer.
Wenn es also keine Überscheidungen mit gleichen Netzen gibt, sollte das doch keinerlei Probleme geben, auch wenns kein 172. oder 10. ist?
Gruß
Christoph
Vielen Dank für die Antwort,
Ich habe sowohl auf der Firewall Nat-T aktiviert als auch entsprechenden NAT-T-Registry-Keys auf dem Client gesetzt. Der VPN-Tunnel wird ja auch rasend schnell aufgebaut, ich kann auch Shares auf dem Fileserver mappen über den Tunnel, das ist das Problem mit hoher Wahrscheinlichkeit nicht. Die DFL 800 ist unsere zweite Firewall, die erste, DFL 200 , hatte nämlich kein NAT-T und deshalb ging da garnichts. Das ist jetzt völlig anders.
Den IP-Bereich sehe ich zwar auch nicht als optimal an, aber es gibt keinerlei Überschneidungen zu den erxternen Netzen. Wir haben die klassischen Heimnetze auf der anderen Seite, 192.168.1.0 und an anderen Standorten auch die 192.168.9.0, aber nirgendwo 192.168.xxx(dreistellig. Die oben angegebenen Adressen sind auch nicht echt, ich hab mir 2 Fantasienetze ausgedacht. Die Echten sind zwar im 192.168. Bereich, aber wesentlich krummer.
Wenn es also keine Überscheidungen mit gleichen Netzen gibt, sollte das doch keinerlei Probleme geben, auch wenns kein 172. oder 10. ist?
Gruß
Christoph
Das ist wohl wahr, keine Frage...
Wenn es nur Outlook ist das hängt ist es zwiefelsohne ein Problem dieser Anwendung und niemals des netzwerks selber.
Denn wenn Fiilesharing oder andere Dienste normal schnell gehen besteht das Problem ja nur bei diesem Exchange Server.
Mehr oder weniger hört sich das nach einem DNS Problem an was dann mit dem Netz als solchem ob mit oder ohne VPN nichts zu tun hat !!
Wenn es nur Outlook ist das hängt ist es zwiefelsohne ein Problem dieser Anwendung und niemals des netzwerks selber.
Denn wenn Fiilesharing oder andere Dienste normal schnell gehen besteht das Problem ja nur bei diesem Exchange Server.
Mehr oder weniger hört sich das nach einem DNS Problem an was dann mit dem Netz als solchem ob mit oder ohne VPN nichts zu tun hat !!
Das kann in der Tat ein DNS-Problem sein, daher auch meine Titel "Namensauflösungsproblem?"
Ich denke aber nicht, dass es ausschließlich ein Outlook-Problem ist, denn warum funktioniert es, wenn ich die Netzwerkkonfiguration ändere, sprich mit UMTS reingehe???
ich denke, der Exchange-Server arbeitet bei der Adressierung intern irgendwie mit dem Namen des Laptops, und dieser kommt - wenn er in einem anderen Netz hängt- eben mit 192.168.1.3 an. Das Standardgateway des lokalen Netz kennt aber dieses Netz nicht und weiss nicht, wie es die Packete weiterleiten soll.
Oder aber der Exchange Server arbeitet ausschließlich mit dem DNS-Server als Quelle (Einer ist auf dem Exchange - Server selbst) und nutzt die lokale Adresse.
Die anderen Server bedienen sich vielleicht aus anderen Quellen für die IP-Adresse, z.B. Wins, wo die korrekte Adresse drin steht, um die Anfragen zu beantworten oder nutzen die VPN-Adresse, die ankommt.
Ich denke, ich kann das Problem lösen, wenn ich dem Laptop beibringe, sich selbst unter der VPN-Adresse zu verkaufen. Und das sehe ich schon als Netzwerkproblem an. Es könnte auch helfen, wenn ich den DNS-Update hinbekomme, sodass auch der DNS Laptop1 mit der VPN-Adresse auflöst. Hat vielleicht hier jemand Tipps in der Hinsicht? Welches Forum ist für DNS Probleme das Richtige?
Ich denke aber nicht, dass es ausschließlich ein Outlook-Problem ist, denn warum funktioniert es, wenn ich die Netzwerkkonfiguration ändere, sprich mit UMTS reingehe???
ich denke, der Exchange-Server arbeitet bei der Adressierung intern irgendwie mit dem Namen des Laptops, und dieser kommt - wenn er in einem anderen Netz hängt- eben mit 192.168.1.3 an. Das Standardgateway des lokalen Netz kennt aber dieses Netz nicht und weiss nicht, wie es die Packete weiterleiten soll.
Oder aber der Exchange Server arbeitet ausschließlich mit dem DNS-Server als Quelle (Einer ist auf dem Exchange - Server selbst) und nutzt die lokale Adresse.
Die anderen Server bedienen sich vielleicht aus anderen Quellen für die IP-Adresse, z.B. Wins, wo die korrekte Adresse drin steht, um die Anfragen zu beantworten oder nutzen die VPN-Adresse, die ankommt.
Ich denke, ich kann das Problem lösen, wenn ich dem Laptop beibringe, sich selbst unter der VPN-Adresse zu verkaufen. Und das sehe ich schon als Netzwerkproblem an. Es könnte auch helfen, wenn ich den DNS-Update hinbekomme, sodass auch der DNS Laptop1 mit der VPN-Adresse auflöst. Hat vielleicht hier jemand Tipps in der Hinsicht? Welches Forum ist für DNS Probleme das Richtige?
