Jump to content

SSTP: Problem mit Sperrlisten


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar
  • 2 Monate später...

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...!!

bearbeitet von Bambinator
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

Hi Bambinator,

 

Du musst Dich erst mal entscheiden: Entweder möchtest Du Hife haben oder Dich beschweren, wie gemein die Welt ist und dass das alles teuer genug ist und so weiter und so fort :-)

 

Im Small Business Server ist die vorgesehen Remote Access-Technologie RRAS. Dafür gibt es dort fertige Assistenten. Wenn Du unbedingt SSTP nutzen möchtest, dann gibt es im SBS keinen einfachen Assistenten dafür. Das musst Du dann selbst konfigurieren. Da sind dann auch die Abhängigkeiten von OWA, RD Gateway und SSTP auf ein und demselben Server zu berücksichtigen. Das ist ein komplexes Szenario (so wie der SBS halt ein komplexes Stück Software ist).

 

Ich empfehle Dir hier dringend ein passendes öffentliches Zertifikat zu nutzen. Wenn Du das noch mit einer eigenen CA machst und der externe Client kein Domänenmitglied ist, dann vertraut er Deiner CA nicht. Wenn Deine CA Zertifikate ausstellt, in denen die CRL nicht richtig eingetragen ist, dann wird die nicht genutzt. Wenn Du mit einer Intermediate CA arbeitest, dann liefert der Server (im Gegensatz zum IIS) nicht die ganze Zertifikatskette aus. Dann musst Du die ganze Kette lokal auf dem externen Client importieren und richtig konfigurieren.

 

Das ist nun mal nicht so trivial und per Forum auch schwer zu unterstützten. Ich sehe hier zwei Möglichkeiten: Entweder Du nimmst einfach eine der vom SBS vorgesehenen Remotefunktionen oder Du machst Dich schlau, wie SSTP implementiert wird. Hier zwei Links zu Howtos:

Have fun!
Daniel

bearbeitet von Daniel -MSFT-
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...