43494
21.04.2007, aktualisiert am 21.03.2009
4762
3
0
MSSQL 2000 über VPN
Hi. Ich möchte einem Client der sich über eine VPN Verbindung in unserem Netzwerk anmeldet die Möglichkeit geben auf eine MSSQL Datenbank zuzugreifen. Welche Ports muss ich dafür freigeben/weiterleiten?
Als VPN Router kommt der Lancom 1711 zum Einsatz und die Firewall habe ich so konfiguriert, dass alles geblockt wird bis es freigegeben wurde. Am Client PC habe ich über Start -> Ausführen -> "CLICONFG" TCP/IP aktiviert und Port 1433 eingetragen. Die Firewall meldet aber, dass der Client PC auf Port 1273 auf den Server zugreifen will, am Client sinds Ports von 2075-2081.
Als VPN Router kommt der Lancom 1711 zum Einsatz und die Firewall habe ich so konfiguriert, dass alles geblockt wird bis es freigegeben wurde. Am Client PC habe ich über Start -> Ausführen -> "CLICONFG" TCP/IP aktiviert und Port 1433 eingetragen. Die Firewall meldet aber, dass der Client PC auf Port 1273 auf den Server zugreifen will, am Client sinds Ports von 2075-2081.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 57236
Url: https://administrator.de/forum/mssql-2000-ueber-vpn-57236.html
Ausgedruckt am: 23.04.2025 um 10:04 Uhr
3 Kommentare
Neuester Kommentar
Innerhalb eines VPNs musst du gar keine Ports freigeben, denn die VPN Verbindung verhält sich netztechnisch gesehen wie eine transparente LAN Verbindung.
Ports musst du nur dann freigeben wenn du offen übers Internet revers über einen NAT Router gehen musst !
In deinem Fall bei einem VPN ist das überflüssig !
Oder meinst du deine Frage so: Welche Ports muss ich fürs VPN selber freigeben ???
Für eine fundierte Antwort ist die Schilderung deines Szenarios sehr oberflächlich, da du überhaupt nicht sagst welches VPN Protokoll bei dir zum Einsatz kommt ???
Es gibt derer viele als da sind IPsec(AH), IPsec(ESP), PPTP, L2TP, SSL usw. Jeder hat seine eigenen Ports und Verfahren.
Deine diffusen Aufzählungen von Ports sind irgendwie Wirrwarr. Anhand von Port TCP 1723 könnte man vage vermuten, das du wahrscheinlich eine PPTP Verbindung etablieren willst.
Dafür benötigst du in der Tat den Port TCP 1723 (PPTP Authentication) und das GRE Protokoll (Generic Route Encapsulation) für die Wirkdaten. GRE benutzt die Protokoll ID 47 (Achtung das ist Protokoll Nummer 47 nicht TCP oder UDP 47 !)
Bei anderen Protokollen sind es natürlich andere Ports !
Fürs SQL selber musst du natürlich, wie oben bemerkt, nichts öffnen, denn das wird transparent im VPN Tunnel übertragen !!!
Ports musst du nur dann freigeben wenn du offen übers Internet revers über einen NAT Router gehen musst !
In deinem Fall bei einem VPN ist das überflüssig !
Oder meinst du deine Frage so: Welche Ports muss ich fürs VPN selber freigeben ???
Für eine fundierte Antwort ist die Schilderung deines Szenarios sehr oberflächlich, da du überhaupt nicht sagst welches VPN Protokoll bei dir zum Einsatz kommt ???
Es gibt derer viele als da sind IPsec(AH), IPsec(ESP), PPTP, L2TP, SSL usw. Jeder hat seine eigenen Ports und Verfahren.
Deine diffusen Aufzählungen von Ports sind irgendwie Wirrwarr. Anhand von Port TCP 1723 könnte man vage vermuten, das du wahrscheinlich eine PPTP Verbindung etablieren willst.
Dafür benötigst du in der Tat den Port TCP 1723 (PPTP Authentication) und das GRE Protokoll (Generic Route Encapsulation) für die Wirkdaten. GRE benutzt die Protokoll ID 47 (Achtung das ist Protokoll Nummer 47 nicht TCP oder UDP 47 !)
Bei anderen Protokollen sind es natürlich andere Ports !
Fürs SQL selber musst du natürlich, wie oben bemerkt, nichts öffnen, denn das wird transparent im VPN Tunnel übertragen !!!
Hallo! Danke für deine (sehr ausführliche) Antwort. Mein Problem ist ja, dass die VPN Verbindung zwischen dem Client außerhalb des Netzwerkes und dem Server im Netzwerk zwar besteht und ich diese verbindung auch nutzen kann um z.B. auf Netzlaufwerke zuzugreifen, möchte ich jedoch eine Verbindung zu einem MSSQL Server vom Client aus herstellen (Server befindet sich im internen Netzwerk) wird dieser nicht gefunden. Von den Rechnern die direkt mit dem Server in einem Netzwerk hängen klappt es, nur bei dem über VPN verbundenen nicht.
Bei diesem "CLICONFG" Tool ist bei den Rechnern kein bestimmtes Protokoll ausgewählt, wenn es über VPN möglich sein soll dem MSSQL server zu erreichen muss man dort aber anscheinend TCP/IP auswählen (nach dieser Anleitung http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/SQLPublishi ..)
Dort kann ich ja einen port festlegen, tatsächlich versucht der Client aber über andere Ports die Verbindung aufzubauen. Bis jetzt war es so, dass ich die Firewall vom Lancom so konfiguriert habe, dass auch interner Traffic gefiltert wurde und nur die Ports die ich freigegeben habe verwendet werden konnten. Selbst wenn ich dies abschalte und intern allen Traffic erlaube wird der MSSQL Server am VPN Client nicht angezeigt. Dafür brauche ich eine Lösung
Bei diesem "CLICONFG" Tool ist bei den Rechnern kein bestimmtes Protokoll ausgewählt, wenn es über VPN möglich sein soll dem MSSQL server zu erreichen muss man dort aber anscheinend TCP/IP auswählen (nach dieser Anleitung http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/SQLPublishi ..)
Dort kann ich ja einen port festlegen, tatsächlich versucht der Client aber über andere Ports die Verbindung aufzubauen. Bis jetzt war es so, dass ich die Firewall vom Lancom so konfiguriert habe, dass auch interner Traffic gefiltert wurde und nur die Ports die ich freigegeben habe verwendet werden konnten. Selbst wenn ich dies abschalte und intern allen Traffic erlaube wird der MSSQL Server am VPN Client nicht angezeigt. Dafür brauche ich eine Lösung
Das kann einzig und allein nur eine Firewall oder MS Naming Problematik sein. SQL nutzt ja TCP/IP als Transportprotokoll und innerhalb eines transparenten VPNs ist es völlig egal auf welchen Ports diese Kommunikation stattfindet, denn der VPN Client und auch der Router sehen niemals in Layer die über dem OSI Layer 3 also dem Routing sprich IP Adressen liegen. Applikationen und deren Ports sind für diese Geräte Schall und Rauch ! Die VPN Verbindung verhält sich per se so wie eine lokale LAN Verbindung.
Deine Problematik ist also keinesfalls nachvollziehbar ! Dafür gäbe es lediglich 3 Gründe:
1.) Du realisierst die SQL Verbindung über den Servernamen. Wenn du hier stattdessen die nackte IP Adresse nimmst, sollte es in jedem Falle klappen wenn das Verbindungsproblem auf Windows Naming Problemen basiert. Ist es das, macht es Sinn den Server beim Client in die /windows/system32/drivers/etc/ hosts Datei fest statisch einzutragen, damit das nicht mehr passiert.
2.) Du filterst irgendwo auf Firewalls oder Packet Filter entsprecheden Ports die die Anwendung blocken.
3.) SQL nutzt große Packete und dein Router kann nicht richtig mit MTU Werten umgehen bzw. die MTU Path Discovery ist fehlerhaft bei VPN. Da hilft es den MTU Wert auf dem Router zu verkleinern oder mit Dr. TCP ( http://www.dslreports.com/drtcp ) dies auf dem Client anzupassen.
Punkt 3. ist aber sehr selten und sollte nur der letzte Versuch sein. Das Problem liegt mit an Sicherheit grenzender Wahrscheinlichkeit an den Punkten 1 und 2 obwohl man 3 nicht gänzlich ausschliessen kann.
Deine Problematik ist also keinesfalls nachvollziehbar ! Dafür gäbe es lediglich 3 Gründe:
1.) Du realisierst die SQL Verbindung über den Servernamen. Wenn du hier stattdessen die nackte IP Adresse nimmst, sollte es in jedem Falle klappen wenn das Verbindungsproblem auf Windows Naming Problemen basiert. Ist es das, macht es Sinn den Server beim Client in die /windows/system32/drivers/etc/ hosts Datei fest statisch einzutragen, damit das nicht mehr passiert.
2.) Du filterst irgendwo auf Firewalls oder Packet Filter entsprecheden Ports die die Anwendung blocken.
3.) SQL nutzt große Packete und dein Router kann nicht richtig mit MTU Werten umgehen bzw. die MTU Path Discovery ist fehlerhaft bei VPN. Da hilft es den MTU Wert auf dem Router zu verkleinern oder mit Dr. TCP ( http://www.dslreports.com/drtcp ) dies auf dem Client anzupassen.
Punkt 3. ist aber sehr selten und sollte nur der letzte Versuch sein. Das Problem liegt mit an Sicherheit grenzender Wahrscheinlichkeit an den Punkten 1 und 2 obwohl man 3 nicht gänzlich ausschliessen kann.
