IThome

Ist auf dem Server die Windows-Firewall aktiv ? Wenn ja, für welchen Bereich ist die RDP-Ausnahme zugelassen ?

TCP 3389 ist im Tunnel erlaubt ? Wie ist die genaue Fehlermeldung bei Eingabe von MSTSC /V:<lokale IP-Adresse des Servers> ? Funktioniert ausser einem PING irgendwas anderes, beispielsweise \\<IP-des-Server> ?

Was ist denn das Problem ? Was funktioniert nicht so, wie Du es erwartest ?

Wie ist der DHCP-Server konfiguriert, hat er 2 IP-Adressen, 2 Karten, ein Superscope oder wird mit einem Relay-Agent gearbeitet ?

Ist das ein Startscript oder Anmeldescript ? Wo ist dieses GPO gelinkt und wie sind die Berechtigungen für den Zugriff auf das Script ? Wo befindet es sich ?

Du stellst in Active Directory Benutzer und Computer die erweiterten Funktionen unter Ansicht ein und kannst dann mit Rechtsklick auf die OU - Eigenschaften den Sicherheitsreiter sehen. Dort unter Erweitert kannst Du es wieder entfernen ...

Was heisst das, ist der Router als NAT-Router konfiguriert worden ? Mir ist kein Weg bekannt, interne Benutzer zeitlich mit einem RRAS, der als Router arbeitet, den Internetzugang zu verbieten. Ein Proxyserver wie der ISA wäre dafür das geeignete Mittel ...

Der RRAS routet es ja zu seinem Gateway, aber von da gibt es eben keinen Weg zurück. Allerdings gibt es eine Möglichkeit, was NAT angeht. Wenn Du NAT über "Neues Routingprotokoll" zufügst und dann die LAN-Schnittstelle als extern und die RRAS eigene Schnittstelle "Intern" als privat deklarierst. Du musst dann noch die VPN-Protokolle auf dem RRAS nach "innen" leiten, den HTTP/HTTPS Port ebenso (alles via Dienste und Ports). Ich hab´s nur mal kurz probiert und das klappt auch, allerdings weiss ich nicht, wie dieses Konstrukt in Deiner Umgebung funktioniert ...

IPSEC ist eine tiefere Ebene als HTTP, also kannst Du es nicht mit dem IIS konfigurieren. Du kannst aber den Server so konfigurieren, dass für den Zugriff auf HTTP Sicherheit erforderlich ist (IPSEC) ...

Naja, der Client steht auf automatisch beziehen, was ja nicht bedeutet, dass er via DHCP seine Adresse bekommt. Er bekommt vom DHCP Server nur die DHCP-Optionen und das Gateway, was er normalerweise einträgt, ist seine eigene IP-Adresse, wenn der Haken "Standardgateway im Remote..." gesetzt ist. Allerdings verstehe ich auch nicht so ganz, warum da 0.0.0.0 steht (liegt das an Vista?) ... Ich würde in diesem Fall auch eher mit DHCP arbeiten, aber nur, um die richtigen DNS-Server und Verbindungssuffixe zu übergeben (man würde auch das eigentliche Problem umgehen, dass das Internetgateway den Weg zum Client nicht findet). Fraglich ist aber, ob das in dieser Konstellation machbar ist. Oder eben eine Route auf dem Router definieren, das ist am einfachsten :)

Du musst nicht dem Client das Gateway bekannt machen, sondern dem Gateway den Client. Wie schon gesagt, hat der Client eine Adresse aus dem Bereich, in dem sich auch die LAN-Karte des RRAS befindet, sollte das klappen ...

Das Problem ist das Gateway, welches der RRAS hat und über das der Internetverkehr des VPN-Clients letztlich erfolgt. Es kennt den Weg zum VPN-Client nicht (die 62.xxx.xxx.1 kannst Du sicher auch nicht anpingen). Entweder legst Du dort eine Route an oder Du benutzt Adressen des lokalen Bereiches des RRAS ... @Dippas Was ist bei einer PPP-Verbindung falsch, wenn dort DHCP enabled = No steht ? Der PPP-Client bekommt seine Adresse nicht via DHCP. Ebenso ist es auch vollkommen normal, dass der Client 2 Standardrouten bekommt, wenn der Haken" Standardgateway im Remotenetzwerk verwenden" aktiviert ist (hier ist die Metrik entscheidend) ...

Default Gateway des PPP-Adapters ist 0.0.0.0 ???

Nach genauerer Durchsicht des ersten Artikels kann ich gar keinen Download zum WPA-Update finden, sondern nur Verweise auf das neueste Servicepack (vielleicht bin aber auch nur blind). Naja, wenn dem tatsächlich so ist, dann muss es SP2 sein ...

Und wieso kein Update auf SP 2 ? Dann klappt auch WPA2 ... geeignet für SP1 Overview of the WPA wireless security update in Windows XP geeignet für SP2 The Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) update for Windows XP with Service Pack 2 is available

Hat der Client einen DNS-Server in der DFÜ-Verbindung eingetragen ? Lässt das Gateway auf der Seite des VPN-Servers die "fremde" Adressrange durch ? Kann der Client überhaupt den Router, der ja auch als Gateway bei dem VPN-Server angegeben ist, anpingen ? Klappt es, wenn Du eine Range benutzt, die sich im lokalen Netz des RRAS befindet ?

Der Server wartet standardmässig 15 Minuten, bis er herunter fährt ? :suspect:

Schau mal in der Registry unter HKLM/CURRENTCONTROLSET/CONTROL/LSA/"Restrictanonymous" , was dort eingestellt ist. Wenn dort eine 1 eingestellt ist, ändere auf 0 und starte neu. Um zu verhindern, dass der Gast auf Ressourcen zugreifen kann, darf der Gruppe Jeder keine Berechtigung gegeben werden. An Stelle von Jeder kannst Du die Gruppe Benutzer bei Freigabeberechtigungen z.B. benutzen. Allerdings kannst Du mit der Gastauthentifizierung nicht mehr weiter unterscheiden, entweder dürfen Gäste zugreifen oder nicht. Drucker und Dateien getrennt voneinander authentifizieren zu lassen funktioniert nicht. Entweder ganz ohne Aufforderung einen Benutzernamen einzugeben oder eben immer (gleiche Benutzerkonten willst Du ja auch nicht einsetzen) ...

Sicher funktioniert das, habe ich gerade ausprobiert ... Welchen Fehler bekommst Du, wenn Du bei aktiviertem Gastkonto auf diesen Rechner via \\<Rechner> zugreifst ? Ist die einfache Dateifreigabe aktiviert ?

Die machen immer einen Login, wenigstens im Hintergrund. Wenn der sich anmeldende User nicht bekannt ist, wird eine Gastauthentifizierung versucht, Du könntest es also über das Gastkonto versuchen ...

IMHO ist E Quatsch, C und D ist richtig (so wird es auch vom Assistenten konfiguriert) ... Ausserdem steht in der Frage "You need to configure packet filters that allow only VPN traffic on AdventuresVPN´s internet (external) interface" , also wird auch im RRAS nur das externe Interface konfiguriert (eingehend und ausgehend)

Schick mal die Aufgabe ...

Ich habe nur die englische Ausgabe, die aber auch schon 2 Jahre alt ist, weiss also nicht, was bei Dir steht ...

Ich nehme jetzt mal an, dass Du die Filter meinst, die der RRAS Assistent anlegt ? Naja, nehmen wir die einfach mal und betrachten nur PPTP. Die Filter wurden nur auf dem als extern deklarierten Interface eingestellt, unter "Eingehende Filter" wie auch unter "Ausgehende Filter". Es existieren auf der externen Schnittstelle unter "Eingehende Filter" 3 Filter für PPTP (beispielhaft): 1. QA-beliebig , QM-beliebig, ZA-192.168.100.1, ZM-255.255.255.255, Proto-TCP, QP-0, ZP-1723 2. QA-beliebig, QM-beliebig, ZA-192.168.100.1, ZM-255.255.255.255, Proto-Weitere, Proto-Nr 47 3. QA-beliebig, QM-beliebig, ZA-192.168.100.1, ZM-255.255.255.0, Proto-TCP(eingerichtet), QP-1723, ZP-0 Die externe Schnittstelle wird vom PPTP-Client als Zieladresse benutzt, um eine Verbindung aufzubauen. Da der Client irgendeine Adresse/Maske haben kann, wird weder Quelladresse noch Maske spezifiziert, also kann jede Adresse eine Verbindung herstellen. Als Zieladresse wird die Adresse der externen Schnittstelle angegeben, mit einer 32er Maske, was bedeutet, dass genau diese Adresse von aussen angesprochen werden muss. Bei den Ports wiederum wird genau festgelegt, welcher Port des anfragenden Clients geprüft wird (0-also egal welcher Port, kann ja auch irgendeiner >1023 sein, daher werden alle erlaubt) und welcher Port als Ziel angegeben wird. In diesem Fall ist es der Port TCP 1723, den der Client anspricht als PPTP-Kommunikationskanal und GRE (IP-Port 47), der für PPTP-Tunneldaten benutzt wird. Der Filter Nr. 3 hat eine besondere Funktion, denn er wird nur benutzt, wenn der RRAS eine LAN-LAN Verbindung als Client aufbaut. Dieser Filter akzeptiert nur Daten von dem anderen PPTP-Server (daher als Quellport TCP 1723), wenn die Verbindung von diesem RRAS initiiert wurde (daher TCP(eingerichtet), weil die Verbindung schon besteht und es sich um Antwortpakete von dem von ihm angesprochenen PPTP-Server handelt. Als Zielport wird 0 angegeben, da dieser RRAS die PPTP-Verbindung aufgebaut hat, was mit einem Port > 1023 passiert ist). Ausgehende Filter: 1. QA-192.168.100.1, QM-255.255.255.255, ZA-beliebig, ZM-beliebig, Proto-TCP, QP-1723, ZP-0 2. QA-192.168.100.1, QM-255.255.255.255, ZA-beliebig, ZM-beliebig, Proto-Weitere, ProtoNr-47 3. QA-192.168.100.1, QM-255.255.255.255, ZA-beliebig, ZM-beliebig, Proto-TCP, QP-0, ZP-1723 Die ersten beiden Filter greifen, wenn dem anfragenden Client geantwortet wird, der dritte Filter greift, wenn der RRAS selbst eine LAN-LAN Verbindung als Client zu einem PPTP-Server herstellt. Wenn also irgendein Rechner eine PPTP-Verbindung zu diesem RRAS herstellen möchte und dann den Tunnel aufbaut, diese Verbindung also eingehend ist (aus der Sicht der externen Schnittstelle des RRAS), wird der eingehende Filter Nummer 1 und 2 benutzt. Antwortet der Server auf diese Anfragen (es ist also eine aus seiner Sicht ausgehende Verbindung), werden die ausgehenden Filter 1 und 2 benutzt. Stellt der RRAS selbst eine Verbindung zu einem anderen PPTP-Server her (also von ihm ausgehend), greift der ausgehende Filter 3. Die Antworten des PPTP-Servers werden durch den eingehenden Filter 3 behandelt . Ich hoffe, ich habe mich jetzt nicht selbst verhaspelt :D

Stimmt die DNS/WINS Konfiguration des Memberservers ?