raisu_de

o.k aber auch drann denken, was es bedeutet die Domänenebene auf Windows 2003 Server anzuheben ... . Habe in einer Testumgebung auch schon mal den Namen eines Domänencontrollers im Modus 2000 gemischt geändert. Der Name wurde geändert und die Einträge im AD passen auch. Würde mich daher mal interessieren wieso MS behauptet es muß 2003 Server Modus sein.

Hallo , zuerst mal Frage 1 : Da scheint wohl etwas mit Deiner Namensauflösung nicht zu stimmen. Hier müssen mehrere Fragen beantwortet werden: -Gibt es einen host (A) record für den client im dns. - Haben die Rechner das gleiche primäre DNS-Suffix oder gibst Du den FQDN an. - Ist der "spezielle Client" im gleichen physikalischen Subnet wie die anderen Rechner oder ist ein Router dazwischen ... (Wenn Du nur den Rechnernamen eingibst könnte es sein dass Du über NETBIOS gehst, nachdem Du von keinem WINS schreibst funktioniert die Namensauflösung dann nur über Broadcast, der geht aber nicht durch nen Router) Zu Frage 2: Du mußt Dich Abmelden. Wenn Du das Fenster nur schließt, bleibt Deine Sitzung offen. schöne Grüße

So wie es aussieht hast Du nicht wirklich physikalisch getrennte Subnetzte. Nachdem Dein client WS3 eine Lease bekommen hat ohne aktivierten DHCP-Relay Agent glaube ich, dass Deine Rechner alle am selben Hub oder Switch angeschlossen sind. Ist das richtig ?

Generell ist die Auswahl Deines DHCP Servers ein bischen unglücklich. Die Kombination RRAS/DHCP ist schlecht. Für einen DHCP Server gilt: Der Server muß eine feste IP-Adresse aus dem Bereich haben für den er Leases vergibt. Hat der Rechner auf dem der dhcp Server ausgeführt hat zwei Netzwerkkarten, so wird der DHCP Serverdienst an eine Karte gebunden. An dieser Karte hört er dann auf Broadcasts für ein DHCP Discover. Wenn ein DHCP Server nun einen zweiten Bereich bedienen soll so geht das nur über einen DHCP-Relay Agent. Der DHCP-Relay Agent wird auf dem RRAS-Server installiert und an eine Schnittstelle gebunden. Zudem wird der DHCP-Relay Agent so konfiguriert, dass er DHCP Discover Pakete an einen DHCP Server weiterleitet. Aufgrund des GIADDR Feldes kann der DHCP Server nun erkennen aus welchem Bereich er die IP-Adresse wählen muß. Ich weiß nun nicht sicher, ob Du den DHCP Server auf dem RRAS Server belassen kannst. Versuche es einfach mal. Konfiguriere auf dem RRAS Server den DHCP-Relay Agent so, dass er auf das Interface, das mit lan2 verbunden ist hört und an den DHCP Server auf dem Interface in lan1 weiterleitet.

Nein den Schlüssel brauchst Du nicht. Dafür ist ja das IPSec Zertifikat da.

Ich denke nun ist mir klar wo Dein Problem liegt. Das IPSec Zertifikat ist für den Tunnel gedacht. Wenn Du nun EAP als Authentifizierung verwenden willst brauchst Du von einer Unternehmenszertifizierungsstelle noch ein Benutzerzertifikat. Wie es in der Anleitung zu PPTP VPN beschrieben ist. Also brauchst Du noch eine 2. Zertifizierungsstelle. Wenn Du das nicht haben möchtest, mußt Du die Benutzerauthentication auf MS-CHAP oder MS-CHAP V2 lassen.

Jo und jetzt mach das mal mit nem xp client. Der zischt dann direkt Richtung apipa ab.

Und Du hast bei Deiner VPN- Verbindung auf dem client das Zertifikat auch angegeben ? Und der RRAS Server verwendet auch das Zertifikat ?

Ist die CA auch in der Liste Deiner vertrauenswürdigen CAs ?

wenn ich es richtig verstehe, wird hier nicht davon ausgegangen, dass die clients keine IP-Adresse mehr besitzen (das Verhalten beim Neustart ist bei den Clientbetriebssystem unterschiedlich), sondern viel mehr davon, dass Sie kein Gateway mehr besitzen und deshalb Ihr Ziel im anderen Subnet nicht mehr erreichen ...

Als erstes mußt Du bei Deinem DHCP-Server 2 Bereiche definieren. für jedes lan eben einen. Dann mußt Du die entsprechenden Bereichsoptionen konfigurieren. Speziell das Standardgateway. So nun mußt Du Deinen Clients und dem DHCP- Server noch beibringen wer aus welchem Bereich zieht. Hierzu empfehle ich Dir folgenden Artikel: http://support.microsoft.com/kb/240247/EN-US/

Ich denke mal Du hast in den TCP/IP Eigenschaften deiner Netzwerkkarten Gateway-Einträge. Die gehören raus. Und dann trägst Du den Joker-Eintrag in Deine statischen Routen ein. 0.0.0.0 0.0.0.0 192.168.15.48 192.168.15.49 1

OK. Du hast 2 lans die Du über RRAS verbunden hast. Wenn Du für alle clients das entsprechende Interface des RRAS als Gateway einträgst können alle WS der beiden lans kommunizieren. Soweit so gut: Nun möchtest Du aber das Deine clients auch ins Internet kommen. daher mußt Du einen Jokereintrag auf dem RRAS generieren. Indem Du Deinen HW-Router nun als Standardgateway des RRAS eingetragen hast gibt es den schon. (das ist der Eintrag der mit 0.0.0.0 0.0.0.0 beginnt). Nun ist Dein einziges Problem noch, dass Dein Router nicht vernünftig mit Deinen lans umgehen kann. Durch setzten der richtigen Subnetmaske geschieht das für lan1. Pakete, die an lan2 gehen sollen(also auch die Antwort auf den ping)werden nicht richtig transportiert. Damit das funktioniert, mußt Du erstens die richtige Subnetmaske auf dem HW-Router eingetragen haben und zudem eine Route für lan2 eintragen.

Du müsstest noch surfen können. Da Dein RRAS alles für das er keine Route hat an Deinen HW- Router schickt .. Dass Du den HW- Router nicht von WS3 anpingen kannst liegt wohl daran, dass Dein HW-Router noch der Meinung ist, dass er im gleichen Subnet wie WS3 ist und deshalb nicht über das Gateway geht. Der Router braucht die richtige Subnetmaske und eine Route für lan2. Wie Du die anlegst sollte im Handbuch des Routers beschrieben sein.

Hi, wie schaut ein route print aus ? Und hast Du auf dem RRAS-Server Routen eingerichtet ? Wenn ja wie schauen die aus ? Wenn ich mir Dein Bild so ansehe, könnte man meinen, dass WS1 und WS2 den HW Router als Standard- Gateway haben. Hat der HW Router eine Route für lan2 ? Oder haben die WS in lan1 eine Route für lan2 ?

Wenn Du alle Schritte dieser Anleitung gewissenhaft abgearbeitet hast. Dann funktioniert das ganze auch. Ich hatte auch mal so meine Probleme mit L2TP Verbindungen. Damals habe ich mich dann an diese Anleitung gehalten.

Tja da hört wohl schon was auf Port 80. Probiers mal hiermit: http://support.microsoft.com/kb/261194/en-us alternativ könntest Du auch den Port Deines IIS umsetzen.

das schon. Aber die Problematik hier ist ja, dass nicht nur der Port sondern auch die IP-Adresse verändert werden muß. Eine Quick and dirty Möglichkeit wäre nun im Netzwerk einem Rechner diese IP-Adresse 60:60:60:60 zuzuweisen und die entsprechende Software laufen zu lassen ... . Natürlich müßte der client eine entsprechende Route zum Rechner kennen ... . ein Tool das automatisch sowohl die Ziel Ip-Adresse als auch den Zielport ändert kenne ich nicht.

Beim Installieren der Zertifizierungsstelle wird der IIS angepasst. So wie Du das schreibst, könnte es auch ein Problem mit der Namensauflösung sein. Auch könnte es sein, dass der IIS Dienst nicht gestartet ist. Was sagt das IIS Snap-In ? schöne Grüße

Hi, ich kann zwar nix versprechen, aber fplgender link klingt gut: http://www.skylarktechnology.com/software/stlportforward.php schöne Grüße

lies bitte folgenden link aufmerksam durch: http://www.gruppenrichtlinien.de/index.html?/HowTo/VPN_Remote_Einwahl.htm Insbesondere der Punkt 11 dürfte für Dich relevant sein. schöne Grüße

Hallo, soweit ich mich erinnere gibt es im Ressource-Kit ein Tool Namens robocopy.

das kommt drauf an, ob Du reine Netbios Anwendungen verwenden willst. Z.B. das Browsen in der Netzwerkumgebung. Wenn dies erforderlich ist, solltest Du einen WINS Server implementieren. Da ansonsten die ganze Geschichte im schlechtesten Fall über Broadcasts geht und eine ganze Weile dauert. Ich denke auch, dass dieser Punkt mit dem Beschleunigen gemeint war.

1. hosts Datei 2. DNS Cache 3. DNS Für die Netbios Abfragen kommt es dann auf den Knotentyp an: B-Knoten (Broadcastknoten) Zur Auflösung von NetBIOS-Namen werden nur Broadcasts (Rundmeldungen) verwendet P-Knoten (Punkt-zu-Punkt-Knoten) Unicast-Meldungen werden zur Auflösung von NetBIOS-Namen verwendet Also Punkt-zu-Punkt-Verbindungen unter WINS-Servern. M-Knoten (MischModusknoten) Benutzt zuerst einen Broadcast zum Auflösen eines NetBIOS-Namens und danach eine Punkt-zu-Punkt-Verbindung zu einem WINS-Server Modifizierter B-Knoten Benutzt zuerst einen Broadcast für die Auflösung und danach wird die lokale "LMHOSTS"-Datei befragt. Dies ist die Standard-Methode von Windows, solange kein WINS-Server in den Netzwerkeinstellungen eingetragen ist. H-Knoten (Hybridknoten) Benutzt zuerst einen WINS-Server zur Auflösung und danach Broadcasts. Dies ist die Standard-Methode von Windows, mit aktiviertem WINS-Client. Erweiterter H-Knoten Ist wie der H-Knoten, nur das danach noch die lokale "LMHOSTS"-Datei, ein DNS-Server und die lokale "HOSTS"-Datei befragt wird.

keine Ursache. Gern geschehen ... . schöne Grüße