Bambinator

Uff... da versteh ich jetzt leider nur die Hälfte... Auf dem VPN-Server (der SBS2011) läuft eine Zertifizierungsstelle für unsere Domäne und ja, der Client ist kein Mitglied in der Domäne, sondern mein privater PC. Das Stamm-Zertifikat unserer CA ist auf meinem PC als vertrauenswürdige Stammzertifizierungsstelle (auf "Zertifikate (Lokaler Computer)") installiert, ohne dieses motzt er schon viel früher und natürlich mit einer anderen Fehlermeldung ("... nicht vertrauenswürdig..."). BTW: was hat das Ganze damit zu tun, dass mein PC nicht in der Domäne ist, das ist ja gerade der Sinn, warum ich eine VPN-Verbindung herstellen will, ich will ja auf Freigaben, Datenbanken und andere Netzwerkressourcen aus der Domäne von zu Hause aus zugreifen. Die Domäne ist ihm doch völlig wurscht zu dem Zeitpunkt, es geht ja nur darum, dass er die Sperrliste nicht gleich abruft. Was mich stutzig macht, sobald ich ja dann in der Fehlermeldung auf "Wiederholen" klicke, ruft er sofort die Sperrliste ab und stellt die Verbindung her. Wenn ihm also die Zertifizierungskette beim ersten Mal nicht passt, warum frisst er sie dann beim zweiten Mal? Bin ich denn der einzige, der's mit Bordmitteln nicht hinbekommt, zwischen "gleichen" Systemen (Win7 Pro und SBS2011) und einem Microsoft-eigenen Protokoll eine simple VPN-Verbindung herzustellen. Windows (v.a. Server) ist teuer genug, da möcht ich nicht noch in eine noch teurere VPN-Hardware investieren! Zumal sich das bei uns in Grenzen hält, es ist eher selten, dass mal mehr als zwei Benutzer gleichzeitig per VPN verbunden sind.

So, nach einiger Zeit Stillstand hab ich mich dem Thema VPN mal wieder gewidmet. Es sah wohl so aus, dass der IIS sich brav schlafen gelegt hat, die Antwortzeit des Webservers auf die Sperrlistenanfrage war also dann jedes mal zu lang. ... dachte ich zumindest, dass das mein Problem war. Aber: es läuft halt immer noch nicht. Ich hab nochmal ne genauere Untersuchung mit Wireshark gemacht. Dabei hab ich folgenden Ablauf aufgezeichnet: - Client stellt Verbindung über Port 443 (SSTP) her und bekommt ein korrektes Zertifikat zurück, der Handshake läuft korrekt ab. - Nach ca. 10 Sekunden schließt der Client dann die Verbindung mittels "RST" und zeigt mir die Sperrlistenwarnung an. Aber wieder: Er hat die Sperrlistenanfrage auf Port 80 noch gar nicht gestellt, bisher nur Verkehr auf 443!!! Dann: ich klicke auf "Wiederholen" in der Fehlermeldung, und siehe da, sofort ruft er die Sperrliste auf Port 80 ab, kriegt nach knappen 100ms ne schöne Antwort und stellt die Verbindung einwandfrei fertig her. Nochmal meine Frage: ist das ein bekanntes Problem, oder hab ich einen Konfigurationsfehler? Warum sagt mir Windows, dass der Server oflline is, wenn ers noch gar nicht versucht hat???? Beim Klick auf "Wiederholen" funktionierts ja einwandfrei! Ich krieg die Krise...!!

Hallo Leute, bis jetzt hab ich ja echt zu jedem Problem hier eine Hilfe gefunden. Aber jetz bin ich mit meinem Latein am Ende... Folgende Situation: wir haben bei uns einen Server mit SBS2011 stehen (ob das jetzt optimal ist, sei dahingestellt, is halt so). Jetz soll eine VPN-Verbindung von einem Win7Pro-Rechner über SSTP hergestellt werden. Zertifizierungsstelle ist eingerichtet und läuft korrekt, Zertifikate sind alle richtig ausgestellt und gültig, Zertifizierungsstellenzertifikat lokal installiert usw... Wenn ich jetzt auf dem Win7-Rechner die Verbindung herstellen will, wirft er mir den bekannten Sperrlistenfehler 0x80092013: "Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war." Erkenntnis aus Wireshark: Er überträgt das Serverzertikat korrekt, da steht auch die passende Sperrlisten-URL drin (die auch extern erreichbar ist). Der springende Punkt: die Sperrliste wird vom Windows-VPN-Client nie abgefragt (also weit und breit kein Request an den Server auf Port 80)... Woher soll er dann wissen, ob sie offline ist?? Wenn ich sie manuell im Browser eintrage, kommt sofort die richtige Sperrliste. Komisch auch: ich hatte diesen Sperrlistenfehler auch bei der Verbindung über einen Remotedesktopgateway. Nach den entsprechenden Anpassungen im Server funktioniert der jetzt anstandslos (aber auch der frägt die Sperrliste nicht ab, auch nach Cache-Leerung ("certutil -urlcache crl delete" im Win7)... :-/ ). Wenn ich in der Registry diese ominöse Einstellung eintrage, dass der VPN-Client die Sperrlistenprüfung nicht durchführen soll, funktionierts einwandfrei (die Sperrliste ist also das einzige Hindernis) - ist aber wohl keine Lösung... Weiterer Test: die Sperrliste tatsächlich offline genommen -> Remotedesktopgateway geht weiterhin. Gibts da also noch ne zweite Cache-Ebene in den Clients selber?? Wie kann ich die denn leeren, bzw. anschauen bzw. welche Cachedauer hat die??? Alles sehr komisch... Was hab ich vergessen? Gibts da noch ne fiese Falltür? Wenn ihr noch weitere Infos braucht, ruhig auch richtig triviale und blöde Sachen nachfragen, ich glaub langsam, dass ich bei der Sache schon betriebsblind bin... Gruß Stephan