SSTP mit Vista über einen nicht Standardport

[Eratum]

Tach allerseits.

Ich habe hier einen W2K8 R2 Server "rumstehen". Dieser soll als VPN Gateway via SSTP dienen. Als kleinen Sicherheitsaspekt (und anderen Gründen) habe ich den SSTP Port verbogen und bspw. 5123 gesetzt. Die Tests mit Windows 8.1 & 10 liefen schonmal erfolgreich. Soweit so gut

Das Problem ist, dass die benötigten Clients wahrscheinlich Windows Vista drauf haben werden. Der aktuelle Test zeigte, dass Vista scheinbar nicht mit der Portangabe hinter der zu verbindenden Adresse umgehen kann (bspw. vpn.gateway.de:5123). Sobald ich die entsprechende Verbindung wähle, erhalte ich im Bruchteil einer Sekunde (also scheinbar ohne den Versuch einer Verbindung) den Fehler 769, der besagt, dass das angegebene Ziel nicht erreicht werden kann. Ohne Portangabe startet Vista einen Verbindungsversuch, der natürlich nicht angenommen wird.

Hat jemand eine Idee, ob ich Vista irgendwie dazu bringen kann die SSTP Verbindung eben nicht über den Standardport aufzubauen? (auch wenn ich in einem MS Statement, welches ich gerade nicht mehr finde gelesen habe, dass das wohl nicht möglich sein soll)

 

Danke schonmal...Eratum

[SilentDemise]

security by obscurity hat noch nie geholfen - oder mit anderen worten: finger weg von verbogenen ports. der port ist eh offen, finde ich mit nem portscanner in sekunden. wenn du eh server 2k8r2 verwendest würde ich nen tmg für die verwaltung vom sstp oben drauf setzen. in der kombi funktioniert es am stressfreisten. 

 

vllt noch als anstoss nebenbi: der clou an sstp ist ja gerade, dass es port 443 nutzt und keine weiteren firewall angriffapunkte bietet, wie üblicher ssl traffic aussieht und mit ner ssl inspection gelesen werden kann. warum also d vorteil über bord werfen?

Bearbeitet 3. November 2015 von SilentDemise

[SilentDemise]

Die Anfrage musst du ja so oder so zum Server bekommen

Best practice ist entweder eine eigene IP Adresse für den VPN Dienst (seperation of concerns, keine Verbindung zwischen normalen ssl diensten und vpn, würde ich bevorzugen) oder zumindest eine eigene subdomain.

 

mit jeder der beiden optionen kannst du über die Firewall bzw. einem ALG das Ziel nach Kategorien filtern und die Pakete entsprechend weiterleiten - ja reines routing ist hier keine Option, sollte es aber bei einem web publishing sowieso nie sein.

 

warum eigentlich sstp? War das ne bewusste Entscheidung?

[Eratum]

Man sollte vielleicht manchmal erstmal ein wenig herumspielen bevor man Fragen in den Raum stellt

Mir hat es jetzt mit rumsuchen nach Drittsoftware und der "Securtiy by obscurity" (danke für diesen Ausspruch) gereicht. Ich habe jetzt einfach nochmal den Standardport für SSTP genommen, sprich Port 443, und auf den beiden Routern Port 443 "geforwarded". Damit funktioniert erstmal die SSTP Verbindung.

Für mich etwas überraschend, für Andere sicher nicht, hatte dies keinen Einfluss auf sonstigen Datenverkehr (bspw. Aufrufe in Richtung HTTPS Seiten von sonsigen Clients). Ebenfalls keinen Einfluss hatte die Weiterleitung auf den HTTPS Zugriff auf den Routern. An dieser Stelle schreib' ich mir mal auf mich doch mal wieder mit den Grundlagen des Networking auseinanderzusetzen ^^

Sollte es wiedererwarten doch noch zu Effekten kommen, werde ich den Ansatz vlt. wieder aufleben lassen.

Danke nochmal an alle die heute mit "rumgesucht" und diskutiert haben

 

Als weitere Ansätze, die in der Chatbox heute geflogen sind:

• Alternative VPN Clients (Lancom Advanced VPN Client [bezahlung], Softether VPN Client [free])
• TMG, ALG

[Eratum]

Danke erstmal für die Antwort.

Problem dabei ist, dass in der aktuellen Konstellation 2 Router dazwischen hängen und unterschiedliche Netze geroutet werden. Die entsprechenden Anfragen muss ich doch bis zum Server "durchschleifen". Wenn ich das nun mit Port 443 mache, landet dann nicht sämtlicher Datenverkehr der über SSL läuft fälschlicherweise auf dem VPN Server?

Oder hab ich gerade eine völlig falsche Denkrichtung?

[Eratum]

Servus

Die Entscheidung zu SSTP fiel, da sich einige Clients hinter einem UMTS/LTE Router befinden und, warum und wie auch immer, andere VPN Verbdindungen scheinbar nicht durchgelassen werden bei unserem Provider.

 

Mit eigene IP-Adresse für den VPN Dienst meinst du eine eigene öffentliche IP Adresse? Das würde ich gern machen, geht allerdings in der gegenwärtigen Konstellation leider nicht. Eigene Subdomain wird, glaube ich, auch eher schwierig in dieser Konfiguration.

Zur Erklärung:

Ich habe hier einen StiNo DSL Anschluss, mit einem einfachen D-Link Router dran. Dieser Stellt zum einen die Internetverbindung für einen speziellen Fachbereich bei uns, sprich Netz A und dient uns zum anderen zum verteilen von "freien" Internetplätzen im Haus (Netz B). Da wir auch in anderen Aussenstellen solche freien Internetplätze haben (die hinter den UMTS Routern hängen) und die Administration "vieler" Clients via Teamviewer als zunehmend unpraktisch erweist kam uns die Idee die Administration der Plätze über eine VPN Verbindung zu einem Server in Netz B zu betreiben. Ich habe das ganze nun Testweise mal aufgebaut und fange via DynDNS die IP des D-Link Routers ab. Den eingehenden VPN Verkehr muss ich nun also irgendwie über die 2 Standardrouter zum Server durchschleifen. - Ich hoffe das ist irgendwie halbwegs verständlich.

In dieser Konstellation auf Port 443 zurückzugreifen wäre eher nicht so der Hit, glaube ich.

Mehr/Andere DSL Anschlüsse sind nicht verfügbar. Statische IP-Adressen bekomme ich nicht und ne andere Alternative sehe ich gerade nicht wirklich :/
(Vielleicht bin ich ja auch gerade zu festgefahren in meiner Vorstellung, wie das imho aussehen kann)

[Eratum]

Mir fällt gerade auf, dass ich das hier gar nicht aufgelöst habe.

Nachdem das mit Vista und verbogenem Port partout nicht klappen wollte und sämtliche in Frage kommenden Clients nur gegen Gebühr erhältlich waren, habe ich's einfach mal mit Port 443 probiert. Die 2 Router forwarden jetzt Port 443 zum entsprechenden Server. Sonstige Dienste und Aufrufe sind davon nicht betroffen! Da bspw. beim Aufruf einer HTTPS Seite ja bereits eine Verbindung etabliert wird und die Antwort nicht direkt an den Router gestellt wird. Somit wird Port 443 zum richtigen Ziel und nicht zum Server geleitet. Einziges "Manko": Wenn man nun von aussen via HTTPS/SSL auf den/die Router zugreifen wöllte, geht das nicht mehr, da diese Anfragen - logischerweise - weitergeleitet werden. Mit der Internen IP-Adresse klappt dies allerdings und das reicht uns in diesem Fall aus.

 

Vielen Dank an alle die sich an der Lösungsfindung beteiligt haben