Windows Server 2003 Ping und Freigaben VPN Verbindung
Hallo zusammen,
erst einmal möchte ich mich vorstellen. Mein Name ist Christian Schröder, bin 34 Jahre alt und komme aus Mülheim. Von Beruf bin ich Windows / Linux Netzwerkadministrator, Anwendungsbetreuer, man könnte sagen Mädchen für alles was IT Technisch bei uns in der Fa. anfällt, da ich der einzige Admin bin.
So aber jetzt genug gefaselt, nun zu meinem Problem!
Hoffe mein Thema ist hier richtig platziert!
Folgendes Szenario stellt sich dar:
Standort Mülheim - 1x VPN Router von Netscreen - 2 Windows SBS 2003 Standard (Server1 & Server2) - 30 XP Clients - Scalix Mailserver - etc.
Standort Erlangen - 1 x Router - 1 x XP Client (Laptop)
Standort Mülheim (Mein Homeoffice) - 1 x Router - 1 XP Client
Alle Standorte haben verschiedene interne Netzwerkadressen!
Mitarbeiter (Standort Erlangen) meldet sich lokal am Laptop an, stellt dann per VPN Client (Netscreen Remote) die Verbindung zum VPN Router (Standort Mülheim) her.
Direkt danach hat er Zugriff auf Server2, Laufwerke können gemappt werden, Ping funktioniert, einfach alles!
Nur auf Server1, wo Erlangen eigentlich den Zugriff drauf habe sollte, funktioniert es nicht. Kein Ping möglich. Gebe ich unter "Start/Ausführen" \\server1 ein, kommt nach geraumer Zeit die Meldung das der Netzwerkpfad nicht gefunden wurde.
Spiele ich das selbe Szenario aber von meinem Homeoffice aus ab, klappt alles! Ping sowie Zugriff auf Server1 und Server2 und alle anderen Clients im Netzwerk.
Ich habe die Konfiguration des Laptops aus Erlangen 1:1 auf meinem Homeoffice (VPC emuliertes System nachgestellt). Klappt alles wunderbar.
Ich weiß nicht mehr wo da der Schuh klemmt.
Hoffe Ihr könnt mir nen paar Tipps geben, oder den rechten Weg weisen.
Dank im Voraus, Chris
erst einmal möchte ich mich vorstellen. Mein Name ist Christian Schröder, bin 34 Jahre alt und komme aus Mülheim. Von Beruf bin ich Windows / Linux Netzwerkadministrator, Anwendungsbetreuer, man könnte sagen Mädchen für alles was IT Technisch bei uns in der Fa. anfällt, da ich der einzige Admin bin.
So aber jetzt genug gefaselt, nun zu meinem Problem!
Hoffe mein Thema ist hier richtig platziert!
Folgendes Szenario stellt sich dar:
Standort Mülheim - 1x VPN Router von Netscreen - 2 Windows SBS 2003 Standard (Server1 & Server2) - 30 XP Clients - Scalix Mailserver - etc.
Standort Erlangen - 1 x Router - 1 x XP Client (Laptop)
Standort Mülheim (Mein Homeoffice) - 1 x Router - 1 XP Client
Alle Standorte haben verschiedene interne Netzwerkadressen!
Mitarbeiter (Standort Erlangen) meldet sich lokal am Laptop an, stellt dann per VPN Client (Netscreen Remote) die Verbindung zum VPN Router (Standort Mülheim) her.
Direkt danach hat er Zugriff auf Server2, Laufwerke können gemappt werden, Ping funktioniert, einfach alles!
Nur auf Server1, wo Erlangen eigentlich den Zugriff drauf habe sollte, funktioniert es nicht. Kein Ping möglich. Gebe ich unter "Start/Ausführen" \\server1 ein, kommt nach geraumer Zeit die Meldung das der Netzwerkpfad nicht gefunden wurde.
Spiele ich das selbe Szenario aber von meinem Homeoffice aus ab, klappt alles! Ping sowie Zugriff auf Server1 und Server2 und alle anderen Clients im Netzwerk.
Ich habe die Konfiguration des Laptops aus Erlangen 1:1 auf meinem Homeoffice (VPC emuliertes System nachgestellt). Klappt alles wunderbar.
Ich weiß nicht mehr wo da der Schuh klemmt.
Hoffe Ihr könnt mir nen paar Tipps geben, oder den rechten Weg weisen.
Dank im Voraus, Chris
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 88571
Url: https://administrator.de/forum/windows-server-2003-ping-und-freigaben-vpn-verbindung-88571.html
Ausgedruckt am: 27.04.2025 um 10:04 Uhr
7 Kommentare
Neuester Kommentar
Hallo Chris,
ich schreibe mal, wie ich reden würde, wenn wir zusammen Kaffee trinken wären oder so.
Also: Du hast also in Mühlheim in einem Netz 2 Server stehen. Der Scalix dürfte dann vermutlich der dritte sein, ist aber ja nicht das Teil, worum es geht.
Im Standort Erlangen gibt es 1 Router und 1 Client
Im Standort Mühlheim2 gibt es 1 Router und 1 Client.
Sagen wir also mal:
MH-Z(entrale) = 192.168.0.0/24
MH-H(omeOffc) = 192.168.1.0/24
ER-A(ussenst) = 192.168.2.0/24
MH-H -> MH-Z = ok für 192.168.1.0/24 und 192.168.2.0/24
ER-A -> ok, jetzt kommt eine Unklarheit:
Die beiden Server: Sind die auch in unterschiedlichen Netzen oder sind beide im gleichen IP-Kreis?
Wenn beide im gleichen IP-Kreis sind, hat server1 ein Problem mit der Route zu ER-A. Überprüfe in dem Fall Standardgateway und / oder Routen.
Moment, stimmt nicht ganz: In allen Fällen, die mir jetzt mal so auf die Schnelle einfallen, gibt es folgende Möglichkeiten:
Der Router in ER-A hat eine Firewallregel oder Route eingetragen, die eine Verbindung speziell zu Server1 nicht zulässt. Die XP-Installation dürfte in Ordnung sein, evtl. dass es eine Desktop-Firewall mit Regel gibt...
Oder der Router in MH-Z hat eine Firewallregel oder Hostroute eingetragen, die das verhindern.
Oder Server1 hat... siehe oben.
Was ergibt denn ein tracert von ER-A-XP auf server1? Welche ist die letzte Station, die antwortet? Da oder an dem nächsten Gerät ist der Fehler zu suchen.
Meine Spezialität in solchen Fällen: Zehlendraher in der Subnetmaske. Schau mal nach!
Bonkers
ich schreibe mal, wie ich reden würde, wenn wir zusammen Kaffee trinken wären oder so.
Also: Du hast also in Mühlheim in einem Netz 2 Server stehen. Der Scalix dürfte dann vermutlich der dritte sein, ist aber ja nicht das Teil, worum es geht.
Im Standort Erlangen gibt es 1 Router und 1 Client
Im Standort Mühlheim2 gibt es 1 Router und 1 Client.
Sagen wir also mal:
MH-Z(entrale) = 192.168.0.0/24
MH-H(omeOffc) = 192.168.1.0/24
ER-A(ussenst) = 192.168.2.0/24
MH-H -> MH-Z = ok für 192.168.1.0/24 und 192.168.2.0/24
ER-A -> ok, jetzt kommt eine Unklarheit:
Die beiden Server: Sind die auch in unterschiedlichen Netzen oder sind beide im gleichen IP-Kreis?
Wenn beide im gleichen IP-Kreis sind, hat server1 ein Problem mit der Route zu ER-A. Überprüfe in dem Fall Standardgateway und / oder Routen.
Moment, stimmt nicht ganz: In allen Fällen, die mir jetzt mal so auf die Schnelle einfallen, gibt es folgende Möglichkeiten:
Der Router in ER-A hat eine Firewallregel oder Route eingetragen, die eine Verbindung speziell zu Server1 nicht zulässt. Die XP-Installation dürfte in Ordnung sein, evtl. dass es eine Desktop-Firewall mit Regel gibt...
Oder der Router in MH-Z hat eine Firewallregel oder Hostroute eingetragen, die das verhindern.
Oder Server1 hat... siehe oben.
Was ergibt denn ein tracert von ER-A-XP auf server1? Welche ist die letzte Station, die antwortet? Da oder an dem nächsten Gerät ist der Fehler zu suchen.
Meine Spezialität in solchen Fällen: Zehlendraher in der Subnetmaske. Schau mal nach!
Bonkers
Hallo Bonkers,
na den Kaffee hab ich jetzt auch nötig! Vielen Dank für deine ausführliche Antwort.
Also, Server1 und Server2 sind Domainencontroller und befinden sich im selben Subnetz. Ich habe den Kollegen in Erlangen mal gebeten den tracert durchzuführen. Das Ergebnis werde ich dann hier Preis geben!
Das komische an der Sache ist ja, das es schon ein mal funktioniert hatte!
*grübel*
Chris
Edit:
So habe jetzt das tracert Ergebnis aus Erlangen. Da ich nicht weiß wie ich hier Bilder anhängen kann, haue ich alles händisch hier rein!
cmd> tracert server1
Routenverfolgung zu server1.zentrale.local [192.168.*.*] über Maximal ......
1 * * * Zeitüberschreitung...
2 -> 6 das selbe
7 115ms 117ms 117ms server1.zentrale.local [192.168.*.*]
Ablaufverfolgung beendet.
Scheint als wenn das Problem in Erlangen beginnt, oder irre ich da?!
Gruß, Chris
Edit2:
Habe jetzt die Tracertergebnisse auf Server2 aus Erlangen erhalten. Diese sind genau so wie bei Server1, jedoch hat er ja auf Server2 vollen Zugriff!
Chris
na den Kaffee hab ich jetzt auch nötig! Vielen Dank für deine ausführliche Antwort.
Also, Server1 und Server2 sind Domainencontroller und befinden sich im selben Subnetz. Ich habe den Kollegen in Erlangen mal gebeten den tracert durchzuführen. Das Ergebnis werde ich dann hier Preis geben!
Das komische an der Sache ist ja, das es schon ein mal funktioniert hatte!
*grübel*
Chris
Edit:
So habe jetzt das tracert Ergebnis aus Erlangen. Da ich nicht weiß wie ich hier Bilder anhängen kann, haue ich alles händisch hier rein!
cmd> tracert server1
Routenverfolgung zu server1.zentrale.local [192.168.*.*] über Maximal ......
1 * * * Zeitüberschreitung...
2 -> 6 das selbe
7 115ms 117ms 117ms server1.zentrale.local [192.168.*.*]
Ablaufverfolgung beendet.
Scheint als wenn das Problem in Erlangen beginnt, oder irre ich da?!
Gruß, Chris
Edit2:
Habe jetzt die Tracertergebnisse auf Server2 aus Erlangen erhalten. Diese sind genau so wie bei Server1, jedoch hat er ja auf Server2 vollen Zugriff!
Chris
Hm, der erste Hop, also die Zeitüberschreitung müßte normalerweise die IP des Routers sein. Kann natürlich sein, dass der keine NetBios-Info durchlässt. Dadurch, dass 2-6 das gleiche Ergebnis bringen, der Server aber letztlich doch erreicht wird, würde ich tatsächlich in Erlangen auf dem Router oder der Workstation eine Firewallregel vermuten.
Ungewöhnlich ist aber auch die lange Laufzeit. Normal wäre ja etwa:
1 - Router Erlangen interne IP
2 - Router Erlangen VPN-Endpunkt (je nach Konfig)
3 - Router Mühlheim VPN-Endpunkt (je nach Konfig)
4 - Router Mühlheim interne IP
5 - Server
So wie das bei Dir aussieht, müssten ja noch mehr Router im Einsatz sein. Und 115/117ms sind auch nicht gerade überragend schnell, das sollte ja eine lokale Verbindung sein. Oder war nur gerade etwas Last auf dem Netz?
Wenn aber nun beide Server das gleiche Ergebnis liefern - hmpf. Firewallregel, die NetBios nicht durchlässt? Letztlich kommt aber jetzt doch wieder jedes Gerät in Frage, das beteiligt ist.
Ich denk' da nochmal drüber nach.
Ungewöhnlich ist aber auch die lange Laufzeit. Normal wäre ja etwa:
1 - Router Erlangen interne IP
2 - Router Erlangen VPN-Endpunkt (je nach Konfig)
3 - Router Mühlheim VPN-Endpunkt (je nach Konfig)
4 - Router Mühlheim interne IP
5 - Server
So wie das bei Dir aussieht, müssten ja noch mehr Router im Einsatz sein. Und 115/117ms sind auch nicht gerade überragend schnell, das sollte ja eine lokale Verbindung sein. Oder war nur gerade etwas Last auf dem Netz?
Wenn aber nun beide Server das gleiche Ergebnis liefern - hmpf. Firewallregel, die NetBios nicht durchlässt? Letztlich kommt aber jetzt doch wieder jedes Gerät in Frage, das beteiligt ist.
Ich denk' da nochmal drüber nach.
Hallo Jörg,
ja wir haben schon den ganzen Tag über Probleme mit unserer DSL Leitung! Techniker sind dabei das Problem zu lösen!
Dieses - hmpf- von dir könnte auch von mir sein. Sitze schon seit Wochen an diesem Problem und bekomme es nicht in den Griff.
Zum Glück ist der Mitarbeiter mehr als Geduldig!
Könnte es vielleicht daran liegen das es den Benutzer auch hier in der Zentrale gibt als Domänenmitglied, und er sich in Erlangen lokal mit dem selbem Namen anmeldet?
Irgendwo muss ja das Problem mit dem Benutzer und dem Server1 zusammenhängen! Denke ich mal! Nur wie,was und wo?!
Chris
ja wir haben schon den ganzen Tag über Probleme mit unserer DSL Leitung! Techniker sind dabei das Problem zu lösen!
Dieses - hmpf- von dir könnte auch von mir sein. Sitze schon seit Wochen an diesem Problem und bekomme es nicht in den Griff.
Zum Glück ist der Mitarbeiter mehr als Geduldig!
Könnte es vielleicht daran liegen das es den Benutzer auch hier in der Zentrale gibt als Domänenmitglied, und er sich in Erlangen lokal mit dem selbem Namen anmeldet?
Irgendwo muss ja das Problem mit dem Benutzer und dem Server1 zusammenhängen! Denke ich mal! Nur wie,was und wo?!
Chris
Hmm, keiner mehr eine Idee?
Ich werde mal versuchen den Laptop aus dem AD zu löschen, und schauen ob es dann geht!
Evtl. liegt es ja daran, das es den Laptop mit dem Namen + zentrale.local gibt, und über VPN einfach nur mit dem Namen?!
Wer weiß...! Aber wundert mich ja das es auf dem Server2 klappt!
Die Sync zwischen den beiden Servern klappt auch, habe extra noch mal alles überprüft und Unreinheiten beseitigt!
Die Ereignisanzeige ist sauber!!!
Chris
Ich werde mal versuchen den Laptop aus dem AD zu löschen, und schauen ob es dann geht!
Evtl. liegt es ja daran, das es den Laptop mit dem Namen + zentrale.local gibt, und über VPN einfach nur mit dem Namen?!
Wer weiß...! Aber wundert mich ja das es auf dem Server2 klappt!
Die Sync zwischen den beiden Servern klappt auch, habe extra noch mal alles überprüft und Unreinheiten beseitigt!
Die Ereignisanzeige ist sauber!!!
Chris
Hi Chris,
sorry, hatte zwischenzeitlich einiges zu tun und hab daher Deinen Post von vorgestern irgendwie übersehen.
Zuerst mal: DSL-Leitung: Naja, aber das wird's nicht sein.
Was heißt eigentlich "...dass es den Laptop mit dem Namen + Zentrale.local gibt und über VPN nur einfach mit dem Namen"? Der Rechner sollte lt. ipconfig oder bei "Computername" nachzusehen etwa "laptop.domain.local" heißen. So heißt der immer, das ist sein DNS-Name, der so genannte FQDN.
Kannst Du den über's VPN nicht auflösen? Mach doch mal bitte bei bestehendem Tunnel in der DOS-Box
ipconfig /registerdns
und starte das Notebook dann neu. Starte auch den Router neu, zumuindest mal den VPN-Tunnel. Versuch danach, ob Du den kompletten FQDN bei stehender VPN-Verbdindung aufgelöst bekommst und mit welcher Adresse, ob die richtig sein kann.
Wenn das nicht funktioniert, ist irgendwas mit der Namensauflösung nicht rund. Welche Auswirkungen das jetzt für diesen Fall hier hat, weiß ich noch nicht, aber zumindest haben wir's dann nicht übersehen.
Wie sieht das mit Firewalls aus, was ist wo drauf und wie konfiguriert?
Bonkers
sorry, hatte zwischenzeitlich einiges zu tun und hab daher Deinen Post von vorgestern irgendwie übersehen.
Zuerst mal: DSL-Leitung: Naja, aber das wird's nicht sein.
Was heißt eigentlich "...dass es den Laptop mit dem Namen + Zentrale.local gibt und über VPN nur einfach mit dem Namen"? Der Rechner sollte lt. ipconfig oder bei "Computername" nachzusehen etwa "laptop.domain.local" heißen. So heißt der immer, das ist sein DNS-Name, der so genannte FQDN.
Kannst Du den über's VPN nicht auflösen? Mach doch mal bitte bei bestehendem Tunnel in der DOS-Box
ipconfig /registerdns
und starte das Notebook dann neu. Starte auch den Router neu, zumuindest mal den VPN-Tunnel. Versuch danach, ob Du den kompletten FQDN bei stehender VPN-Verbdindung aufgelöst bekommst und mit welcher Adresse, ob die richtig sein kann.
Wenn das nicht funktioniert, ist irgendwas mit der Namensauflösung nicht rund. Welche Auswirkungen das jetzt für diesen Fall hier hat, weiß ich noch nicht, aber zumindest haben wir's dann nicht übersehen.
Wie sieht das mit Firewalls aus, was ist wo drauf und wie konfiguriert?
Bonkers
Was heißt eigentlich "...dass es den Laptop mit dem Namen + Zentrale.local gibt und über VPN nur einfach mit dem Namen"? Der Rechner sollte lt. ipconfig oder bei "Computername" nachzusehen etwa "laptop.domain.local" heißen. So heißt der immer, das ist sein DNS-Name, der so genannte FQDN.
Stimmt, gedankenfehler meinerseits. Mich beschäftigt das Problem schon so derbst, das mir ,logische Dinge schon gar nicht mehr logisch vorkommen. *grmpf*
Das mit dem DNS werde ich im laufe des Tages ausprobieren! *dankdir*
Chris ;)
Soooo, Problem gelöst. Nach den Befehlen:
ipconfig /flushdns und anschließend ipconfig /registerdns
läufts! Hört sich für mich nach einer unsauberen dns registrierung an.
Vielen Dank Bonkers für den Zaunpfahl!
