Fehler bei sstp VPN

Hallo Community,

nochmal ich.

Ich hab mich die letzten Tage mit VPN gequält und bin schließlich bei sstp angekommen (l2tp geht nicht, trotz Portfreigaben).

Es sieht so aus: server1 (Windows Server 2012 r2 Datacenter mit Essentials Rolle) und server2 (auch 2013 R2 Datacenter). Ich hab durch die Essentials-Rolle ein Zertifikat bekommen und einen Domänennamen bei MS eingerichtet. Das Zertifikat ist von GoDaddy, gültig und funktioniert.
Nun möchte ich aber nicht, dass der DC als Einwählpunkt gilt sondern server2, also habe ich das Zertifikat exportiert, auf server2 in "eigene Zertifikate" importiert und mal dem IIS zugeordnet. Soweit klappt der Zugriff von extern.

Dann hab ich die Routing und RAS Rolle installiert, VPN mit dem Assistenten ausgewählt und dann unter den Servereigenschaften -> Sicherheit das GoDaddy Zertifikat ausgewählt.

Will ich jetzt von meinem Client (keine Domäne) eine VPN Verbindung aufbauen, kommt, dass der Server nicht überprüft werden kann, ich kann dann auswählen ob ich verbinden will oder nicht.

Wie kriege ich das weg und warum kommt das? Zugriff über den DynDNS Namen im Browser klappt doch ohne Fehler?

Ändere ich das Zertifikat am Server auf eines von der Domänen-CA (intern) kommt sofort beim Verbindungsaufbau, dass der CA nicht getraut wird.

Kann jemand helfen?

Billy

PS: per NPS Richtlinie wird nur "peap mschap" erlaubt hat das damit was zu tun?

Please also mark the comments that contributed to the solution of the article

Content-Key: 300729

Url: https://administrator.de/contentid/300729

Printed on: April 23, 2024 at 19:04 o'clock

5 Comments

Latest comment

Moin.

Zitat von @billy01:
Ich hab mich die letzten Tage mit VPN gequält und bin schließlich bei sstp angekommen (l2tp geht nicht, trotz Portfreigaben).

L2TP o. IPSec geht einwandfrei

wenn man denn alle Bedingungen kennt, und sich vernünftig darüber informiert!! Nur mit Ports öffnen ist es hier nicht getan. VPN-Technologien erfordern ein breites Verständnis verschiedenster Bereiche. Mit Tutorials auf Youtube schauen ist es da in keinem Fall getan. Nur wenn man sich mal die Zeit nimmt und alle Teilbereiche wirklich versteht ist man auch in der Lage solche Probleme erfolgreich zu beheben.

Mit "och bekomm ich damit jetzt nich hin, nehmen wir mal das nächste" so wie sich deine letzten Posts lesen, kommst du in der IT-Welt nicht weit. Nur die Harten kommen in den Garten

Es sieht so aus: server1 (Windows Server 2012 r2 Datacenter mit Essentials Rolle) und server2 (auch 2013 R2 Datacenter). Ich hab durch die Essentials-Rolle ein Zertifikat bekommen und einen Domänennamen bei MS eingerichtet. Das Zertifikat ist von GoDaddy, gültig und funktioniert.
Nun möchte ich aber nicht, dass der DC als Einwählpunkt gilt sondern server2, also habe ich das Zertifikat exportiert, auf server2 in "eigene Zertifikate" importiert und mal dem IIS zugeordnet. Soweit klappt der Zugriff von extern.

Dann hab ich die Routing und RAS Rolle installiert, VPN mit dem Assistenten ausgewählt und dann unter den Servereigenschaften -> Sicherheit das GoDaddy Zertifikat ausgewählt.

Will ich jetzt von meinem Client (keine Domäne) eine VPN Verbindung aufbauen, kommt, dass der Server nicht überprüft werden kann, ich kann dann auswählen ob ich verbinden will oder nicht.
Wie kriege ich das weg und warum kommt das? Zugriff über den DynDNS Namen im Browser klappt doch ohne Fehler?

Bei SSTP ist zwingend zu prüfen ob im Zertifikat eine CRL-URL hinterlegt ist. Wenn das der Fall ist muss diese URL immer vom Client erreichbar und verfügbar sein, ansonsten verweigert Windows die Verbindung.

Ändere ich das Zertifikat am Server auf eines von der Domänen-CA (intern) kommt sofort beim Verbindungsaufbau, dass der CA nicht getraut wird.

Das ist erstens normal wenn man auf dem Client der nicht der Domäne angehört, das Stammzertifikat der CA nicht in die vertrauenswürdig Zertifizierungsstellen importiert hat, um zweitens gilt hier ebenfalls das was ich oben geschrieben habe. Wenn die Zertifikatskette eine OSCP oder CRL-URL hinterlegt hat muss diese für den Client abrufbar sein. Dort fragt der Client nämlich die gesperrten Zertifikate ab. Kann er das nicht, Ende Gelände = Keine Verbindung. SSTP ist hier sehr restriktiv! Da muss in der SSL-Kette alles stimmen.
https://technet.microsoft.com/de-de/library/cc731352(v=ws.10).aspx

Gruß jodel32

Hallo Jodel,

danke für deine Antwort.

Wie und wo finde ich denn diese CRL-URL?

Wenn ich mir das Zertifikat anschaue und die URL da öffne, lädt er eine Datei runter - da kommt der Client doch ran?

Schönen Sonntag,

Billy

Wenn ich mir das Zertifikat anschaue und die URL da öffne, lädt er eine Datei runter - da kommt der Client doch ran?

OK wenn das der Fall ist ist das in dieser Hinsicht OK.

Ich habe dir nochmal extra alle wichtigen Dinge aufgelistet.

Überprüfe folgende Einstellungen in der Verbindung auf dem Client:

Auf dem NPS-Server solltest du dann eine Netzwerkrichtlinie mit folgenden Einstellungen haben (Zusätzlich benötigst du natürlich eine passende Verbindungsanforderungsrichtlinie für die DFÜ Einwahl im NPS):

Eine Benutzergruppe die Einwahl gewähren und die jeweiligen User hinzufügen

Folgende Auth-Methode genügt vollkommen für den Zugriff via SSTP wenn Kennwörter statt Client-Zertifikaten bei der Einwahl genutzt werden.

Im Benutzerprofil der User sollte die Einwahloption so konfiguriert sein:

Dann sollten im RRAS die SSTP-Ports aktiviert sein

Und das richtige Zertifikat und IP-Einstellungen in den Eigenschaften des Servers hinterlegt sein:

Möchte man das der eigene DHCP im internen Netz die Verteilung der IP-Adressen der VPN-Clients übernimmt stellst man dies folgendermaßen ein:

Alternativ lässt sich hier auch ein fester Adresspol für die Clients vergeben.

Damit funktioniert hier die Einwahl bei korrektem Zertifikat und auch bei Computern die kein Mitglied der Domain sind auf einem SRV2012R2 mit SSTP einwandfrei ohne irgendwelche Nachfragen!

Ich mache das immer ohne jegliche Assistenten. Die Assis machen einen doch immer nur Blind und dann wissen die User noch nicht mal was eigentlich im Hintergrund passiert. Wenn man es manuell macht, hat man immer das Zepter selbst in der Hand wenn man weiß was man tut, gleichzeitig steht man so nicht gleich wie die Axt im Walde wenn mal was nicht funktioniert.

Gruß jodel32