22
ODBC Timeout über VPN
Guten Morgen zusammen,
ich stehe hier vor einem Problem oder jemand auf der Leitung.
Wir haben zwei Netzwerke über VPN jeweils mit einer Sophos XG135 verbunden.
Über den VPN laufen Kopiervorgänge und ODBC Zugriffe auf einen MS SQL Express Server.
Das läuft in der Konfiguration seit ca. 7 Jahren.
Beide Sophos hingen bis vor einer Woche jeweils an einer Telekomleitung DLAN100 und DLAN10.
Den DLAN10 Anschluss haben wir vor einer Woche ersetzt durch einen Anschluss der netcom BW Glasfaser.professional 1000 (Download 1000, Upload 500) (gemessen im Betrieb ca. 800/300).
Seit wir auf diesem Anschluss sind, haben wir im VPN massive Probleme.
Die Sophos war bisher am LanCom für ein Transfernetz konfiguriert und wurde für die netcom Leitung auf PPPoE umgestellt.
Einwahl funktioniert, internet am Standort funktioniert, nur beim Zugriff auf den anderen Standort spielt alles verrückt:
ODBC timeout bei Anfragen auf den Server, manchmal funktioniert es ... manchmal nicht, versuche ich mit robocopy eine 53MB große Datei zu kopieren, meldet robocopy nach ca. 10sek. "Der angegebene Netzwerkname ist nicht mehr verfügbar", hat aber im Ziel die zu kopierende Datei gelöscht. Kleinere Dateien kopiert er anstandslos. Auch der TotalCommander tut sich schwer mit der Datei (entfernen sie den eventuelle vorhanden Schreibschutz), beim 3. oder 4. Anlauf kopiert er sie dann in 2sek. an den Standort. Größere Kopierbatchprozesse bleiben nach ein paar Dateien einfach stehen und machen eine 1/2h später weiter, dabei ist der netcom Anschluss aber immer online und auch der VPN ist immer aktiv.
Solche Phänomene kannte ich von früher, wenn bei einem DSLer was mit der MTU nicht stimmte. Bei der PPPoE Einwahl der Sophos lässt sich auch ein MTU einstellen, nach Rücksprache mit der netcom hieß es aber nichts ändern, das ist ein Glasfaseranschluss da ist der MTU Wert unwichtig.
Aktuell weiß ich nicht wie ich den Fehler lokalisieren soll und werde erst mal wieder auf die alte DLAN10 Leitung gehen.
Vielleicht habt ihr einen Tipp.
ich stehe hier vor einem Problem oder jemand auf der Leitung.
Wir haben zwei Netzwerke über VPN jeweils mit einer Sophos XG135 verbunden.
Über den VPN laufen Kopiervorgänge und ODBC Zugriffe auf einen MS SQL Express Server.
Das läuft in der Konfiguration seit ca. 7 Jahren.
Beide Sophos hingen bis vor einer Woche jeweils an einer Telekomleitung DLAN100 und DLAN10.
Den DLAN10 Anschluss haben wir vor einer Woche ersetzt durch einen Anschluss der netcom BW Glasfaser.professional 1000 (Download 1000, Upload 500) (gemessen im Betrieb ca. 800/300).
Seit wir auf diesem Anschluss sind, haben wir im VPN massive Probleme.
Die Sophos war bisher am LanCom für ein Transfernetz konfiguriert und wurde für die netcom Leitung auf PPPoE umgestellt.
Einwahl funktioniert, internet am Standort funktioniert, nur beim Zugriff auf den anderen Standort spielt alles verrückt:
ODBC timeout bei Anfragen auf den Server, manchmal funktioniert es ... manchmal nicht, versuche ich mit robocopy eine 53MB große Datei zu kopieren, meldet robocopy nach ca. 10sek. "Der angegebene Netzwerkname ist nicht mehr verfügbar", hat aber im Ziel die zu kopierende Datei gelöscht. Kleinere Dateien kopiert er anstandslos. Auch der TotalCommander tut sich schwer mit der Datei (entfernen sie den eventuelle vorhanden Schreibschutz), beim 3. oder 4. Anlauf kopiert er sie dann in 2sek. an den Standort. Größere Kopierbatchprozesse bleiben nach ein paar Dateien einfach stehen und machen eine 1/2h später weiter, dabei ist der netcom Anschluss aber immer online und auch der VPN ist immer aktiv.
Solche Phänomene kannte ich von früher, wenn bei einem DSLer was mit der MTU nicht stimmte. Bei der PPPoE Einwahl der Sophos lässt sich auch ein MTU einstellen, nach Rücksprache mit der netcom hieß es aber nichts ändern, das ist ein Glasfaseranschluss da ist der MTU Wert unwichtig.
Aktuell weiß ich nicht wie ich den Fehler lokalisieren soll und werde erst mal wieder auf die alte DLAN10 Leitung gehen.
Vielleicht habt ihr einen Tipp.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6623537101
Url: https://administrator.de/forum/odbc-timeout-ueber-vpn-6623537101.html
Ausgedruckt am: 24.12.2024 um 06:12 Uhr
22 Kommentare
Neuester Kommentar
Hi,
Mich würde mal interessieren, wie das Medium mit der MTU Size zusammenhängt. Bei uns im Nordwesten gibt es einen Provider, wo dies gerade bei LWL auf eine andere MTU gesetzt werden muss - in diesem Fall auf 1492 anstatt 1500. ich würde da also nochmal hinterher gehen.
Ansonsten: Sophos Firmware auf stand? Mal alter Filter ausgeschaltet? (IDS, APP, etc)?
Mich würde mal interessieren, wie das Medium mit der MTU Size zusammenhängt. Bei uns im Nordwesten gibt es einen Provider, wo dies gerade bei LWL auf eine andere MTU gesetzt werden muss - in diesem Fall auf 1492 anstatt 1500. ich würde da also nochmal hinterher gehen.
Ansonsten: Sophos Firmware auf stand? Mal alter Filter ausgeschaltet? (IDS, APP, etc)?
nach Rücksprache mit der netcom hieß es aber nichts ändern, das ist ein Glasfaseranschluss da ist der MTU Wert unwichtig
Die MTU ist nie unwichtig.
Bei PPPoE ist die MTU in der Regel bei maximal 1492 Bytes, weil du halt 8 Byte Overhead durch den PPPoE-Tunnel hast.
Reduziere mal testweise die MTU des VPN-Tunnels auf 1400 Bytes, das sollte immer gehen.
Und lasse dann mal eine MTU Discovery außerhalb des Tunnel laufen um zu sehen, welche MTU ihr da an dem Anschluss benutzen könnt, wenn man von netcom keine Vernünftigen Antworten bekommt.
wie das Medium mit der MTU Size zusammenhängt
https://de.wikipedia.org/wiki/Maximum_Transmission_Unithttps://www.cisco.com/c/de_de/support/docs/long-reach-ethernet-lre-digit ...
Dazu gibt es zig Dokumentationen...
das ist ein Glasfaseranschluss da ist der MTU Wert unwichtig.
Das ist eine fragwürdige Aussage und eher ein Armutszeignis für den Providersupport wenn auf dem Anschluss denn wirklich PPPoE verwendet wird. Du hast du ja dann immer einen Encapsulation Overhead und damit gelten dann MTU bzw. MSS Settings die angepasst werden müssen wenn die Sophos kein automatisches MSS Clamping im VPN macht.PPPoE auf einem Glasfaseranschluss ist zwar etwas ungewöhnlich weil häufig DHCP zum Einsatz kommt aber das kann jeder Provider ja so umsetzen wie er es will. Einen Standard gibt es da bekanntlich nicht.
Für dich gilt es also wasserdicht rauszufinden ob der Provider wirklich PPPoE macht und ggf. auch noch ein VLAN Tagging on Top wie es einige zusätzlich tun.
Du kannst es ja auch an deinem aktuellen Sophos Setup sehen. Wenn du dort am WAN Port das Setup in den PPPoE Mode geändert hast oder musstest, mit den Usercredentials direkt auf der Sophos, dann machst du de facto PPPoE und dann musst du auch zwingend MTU bzw. MSS Anpassungen für den VPN Betrieb machen ansonsten kommt es zu Fragmentierungen mit genau dem Fehlerbild das du aktuell siehst! Eine MTU Anpassung am WAN Port ist ebenso erforderlich sollte die Sophos das mit dem PPPoE Mode nicht automatisch machen.
Führe doch einmal einen Ping Check aus mit entsprechenden MTU Settings dann weisst du es doch genau?!
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
Super, Danke euch. Schwante mir doch schon sowas. Sophos ist Firmware mäßig aktuell, hab am Wochenende noch alles geupdatet. Ich spiel mal mit der MTU rum.
Hi aqui,
mit dem Pingtest lande ich bei 1364, ab 1365 will er fragmentieren.
mit dem Pingtest lande ich bei 1364, ab 1365 will er fragmentieren.
Im VPN oder im WAN?
Im WAN wäre das wirklich sehr klein…
Im WAN wäre das wirklich sehr klein…
mit dem Pingtest lande ich bei 1364, ab 1365 will er fragmentieren.
OK, normale Werte bei doppelter Encapsulation. Wenn man denn wüsste in welchem Umfeld?! Dazu machst du ja leider keine Aussage und man kann nur Kristallkugeln. 
Du kannst dir das ja auch immer selber ausrechnen mit einem MTU Calculator:
https://baturin.org/tools/encapcalc/
Bei IPsec und GRE VPNs ist das noch recht lesenswert zu dem Thema:
https://www.cisco.com/c/de_de/support/docs/ip/generic-routing-encapsulat ...
Stimmt ich hätte etwas genauer sein müssen:
Ist-Stand mit beschriebenem Fehlerbild:
Netz1 Sophos XG135 an Telekom DLAN Anschluss (statische IP) MTU 1500
Netz2 Sophos XG135 an netcom BW Anschluss (PPPoE) MTU 1500
IPSEC Site-to-Site VPN IKEv1
Ich vermute mal ich muss die MTU in beiden Geräten anpassen ? Also WAN und VPN (wobei ich aktuell gar nicht weiß wo ich die VPN MTU an der Sophos einstelle
ich glaub ich beauftrage da lieber ne Fachfirma.
Ist-Stand mit beschriebenem Fehlerbild:
Netz1 Sophos XG135 an Telekom DLAN Anschluss (statische IP) MTU 1500
Netz2 Sophos XG135 an netcom BW Anschluss (PPPoE) MTU 1500
IPSEC Site-to-Site VPN IKEv1
Ich vermute mal ich muss die MTU in beiden Geräten anpassen ? Also WAN und VPN (wobei ich aktuell gar nicht weiß wo ich die VPN MTU an der Sophos einstelle
ich glaub ich beauftrage da lieber ne Fachfirma.
Ich vermute mal ich muss die MTU in beiden Geräten anpassen ?
Nein, denn Netz1 hat ja eine korrekte MTU!Wenn, dann muss es nur an Netz 2 gemacht werden wenn dort wirklich PPPoE zur Anwendung kommt denn nur dort hast du ja dann eine andere MTU. Einfache Logik...
Das ist aber eine simple netzwerktechnische Binsenweisheit die jeder kennt wenn es sich um PPPoE Anschlüsse handelt!
ich glaub ich beauftrage da lieber ne Fachfirma.
Wenn schon der Provider dir eine fachlich falsche Auskunft gibt wird es spannend was eine Fachfirma dazu sagt?! Dieser Begriff ist ja sehr dehnbar... 
wobei ich aktuell gar nicht weiß wo ich die VPN MTU an der Sophos einstelle
3 Sekunden in der Sophos Knowledge Base.... https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/1389 ...
https://support.sophos.com/support/s/article/KB-000044840?language=en_US
Danke, da werde ich mich da mal reinlesen. Hatte bisher nur mit der Weboberfläche gearbeitet.
Ich bin kein Datenbankspezi, aber ich hab noch kein Softwarehersteller gefunden, der einen Datenbankzugriff über VPN offiziell unterstützt. Ich hab schon öffters mit diversenen Herstellen zu tun, auch größere, wie z.B. SAP darunter.
Ich würd jetzt mal behaupten, dass es seinen Grund hat warum das keiner freigibt und würde überlegen, ob es nicht anders geht.
Ich würd jetzt mal behaupten, dass es seinen Grund hat warum das keiner freigibt und würde überlegen, ob es nicht anders geht.
Der Datenbank ist es per se ja herzlich egal ob man per VPN, per Glasfaser oder Kupfer zugreift. Eine Datenbank kann logischerweise niemals wissen über welche IP Infrastrukur auf sie zugegriffen wird. In sofern ist dieser o.a. Einwand in puncto VPN nicht wirklich relevant zumindestens was die Infrastruktur betrifft.
Relevant für den Zugriff ist nur ob die Datenbank überhaupt remoten Zugriff aus fremden IP Netzen zulässt und wenn ja ob ggf. diese IP Netze dediziert vorgegeben sind.
Jede Datenbank lässt sich dafür in ihrer Setup Datei bekanntlich entsprechend customizen für den Zugriff.
Sowas sollte man natürlich tunlichst VORHER mit dem Datenbank Admin klären bevor man sich einen Wolf sucht an Komponenten die gar nichts damit zu tun haben. Der Admin weiss ja sowas in der Regel.
Relevant für den Zugriff ist nur ob die Datenbank überhaupt remoten Zugriff aus fremden IP Netzen zulässt und wenn ja ob ggf. diese IP Netze dediziert vorgegeben sind.
Jede Datenbank lässt sich dafür in ihrer Setup Datei bekanntlich entsprechend customizen für den Zugriff.
Sowas sollte man natürlich tunlichst VORHER mit dem Datenbank Admin klären bevor man sich einen Wolf sucht an Komponenten die gar nichts damit zu tun haben. Der Admin weiss ja sowas in der Regel.
@aqui Wie schon geschrieben, hab ich die Info auch nur von den jeweiligen Softwareherstellern, die mir quasi "verboten" haben die Clients über VPN an die Datenbank anzubiden. Begründet wurde das dadurch, dass damit die Konsistenz der Daten gefärdet wäre.
Mein persönliche Meinung dazu dekt sich ziemlich genau damit was du geschrieben hast, aber was soll man manchen wenns der Hersteller nicht supported und man dann nur der Depp ist wenn was nicht geht.
@Alexander2 Ich würde hier schon mal mit dem Softwarehersteller der Datenbankanwendung sprechen, evtl. ist das nicht vorgesehen oder irgendwie eingschränkt so wie es aqui schreibt.
Noch kurz zu deinen Leitungen. Ich kann mir gut vorstellen, das musst du überprüfen, das die Netcom BW Leitung asynchron läuft. Die DLAN Leitung sind Symetrisch und Synchron. Asynchron heißt dass kein Paket gesendet werden kann währen du etwas empfängst.
Worauf ich hinaus will. Vorher hattest du eine voll synchrone Verbindung zwischen den Standorten jetzt nur noch auf einer Seite und die andere Seite ist asynchron was die gesamte Verbindung asynchron macht.
Evtl. ist das eine Erklärung für deine Verbindungsprobleme.
Mein persönliche Meinung dazu dekt sich ziemlich genau damit was du geschrieben hast, aber was soll man manchen wenns der Hersteller nicht supported und man dann nur der Depp ist wenn was nicht geht.
@Alexander2 Ich würde hier schon mal mit dem Softwarehersteller der Datenbankanwendung sprechen, evtl. ist das nicht vorgesehen oder irgendwie eingschränkt so wie es aqui schreibt.
Noch kurz zu deinen Leitungen. Ich kann mir gut vorstellen, das musst du überprüfen, das die Netcom BW Leitung asynchron läuft. Die DLAN Leitung sind Symetrisch und Synchron. Asynchron heißt dass kein Paket gesendet werden kann währen du etwas empfängst.
Worauf ich hinaus will. Vorher hattest du eine voll synchrone Verbindung zwischen den Standorten jetzt nur noch auf einer Seite und die andere Seite ist asynchron was die gesamte Verbindung asynchron macht.
Evtl. ist das eine Erklärung für deine Verbindungsprobleme.
von den jeweiligen Softwareherstellern, die mir quasi "verboten" haben die Clients über VPN an die Datenbank anzubiden.
Das ist auch sicher berechtigt, hat aber ganz andere Gründe als die Infrastruktur selber, denn wie oben schon beschrieben kann die Datenbank nicht erkennen woher der an sie gerichtete IP Traffic herkommt.Verantwortungsvolle Datenbank Admins setzen die IP Bindung mit bind-address = 127.0.0.1 einzig an die Localhost Adresse (Beispiel MySQL, MariaDB)
Damit ist dann jeglicher Traffic von remoten IP Netzen unterbunden.
Entsprechend customized man z.B. die bind-address dann lediglich auf lokale LAN IP Segmente wenn man remoten Access benötigt und spart die VPN Netze eben aus.
Da die Latenzen auf VPNs nicht kalkulierbar sind besonders wenn man über öffentliche Netze tunnelt kann das in der Tat Auswirkungen auf die Daten haben. Das liegt aber in der Natur der Sache von VPNs an sich und nicht grundsätzlich in der externen IP Connectivity.
@aqui Wie schon geschrieben, hab ich die Info auch nur von den jeweiligen Softwareherstellern, die mir quasi "verboten" haben die Clients über VPN an die Datenbank anzubiden. Begründet wurde das dadurch, dass damit die Konsistenz der Daten gefärdet wäre.
Wenn wir davon ausgehen, dass der Hersteller Angst vor plötzlich abbrechenden oder sehr langsamen Verbindungen mit hoher Latenz hat, soll er ein DBMS benutzen, das transaktionssicher ist. Das ist kein Hexenwerk und das Problem ist gelöst.
Oder der Hersteller muss eine API (z.B. per HTTP) bereitstellen, damit die Clients nicht direkt mit der Datenbank reden müssen, was sowieso vernünftiger wäre.
In jedem Fall muss man dem Hersteller vorhalten, dass er seine Probleme nicht zu denen seiner Kunden machen soll.
Mir will aber abgesehen von diesen Punkten kein gültiger Grund einfallen, warum Datenbankzugriffe per VPN nicht "supported" sein sollen. Mal ganz unabhängig von der Frage woher der Datenbankserver eine Verbindung durch VPN sicher erkennen will.
Noch kurz zu deinen Leitungen. Ich kann mir gut vorstellen, das musst du überprüfen, das die Netcom BW Leitung asynchron läuft. Die DLAN Leitung sind Symetrisch und Synchron. Asynchron heißt dass kein Paket gesendet werden kann währen du etwas empfängst.
Worauf ich hinaus will. Vorher hattest du eine voll synchrone Verbindung zwischen den Standorten jetzt nur noch auf einer Seite und die andere Seite ist asynchron was die gesamte Verbindung asynchron macht.
Evtl. ist das eine Erklärung für deine Verbindungsprobleme.
Worauf ich hinaus will. Vorher hattest du eine voll synchrone Verbindung zwischen den Standorten jetzt nur noch auf einer Seite und die andere Seite ist asynchron was die gesamte Verbindung asynchron macht.
Evtl. ist das eine Erklärung für deine Verbindungsprobleme.
Das ist nicht die Bedeutung von "Synchron" in diesem Kontext, eigentlich ist es das exakte Gegenteil. Möglicherweise meinst du aber auch den Duplexmodus, aber auch der spielt eine untergeordnete Rolle.
Und Ursache der Verbindungsprobleme kann beides unmöglich sein, denn wenn du mal an die OSI-Schichten denkst und dass es jedem Layer egal ist was die jeweils anderen machen fällt auf, dass es ein IP-Paket nicht interessiert, welche Übertragungswege es irgendwo, auch im Backbone, an Internet Exchanges u.s.w. genommen hat.
Die Daten können von einem DSL-Anschluss über ein MPLS-Backbone, dann über STM, dann durch eine Richtfunkverbindung, dann in ein Ethernet-Netzwerk in ein GPON laufen - es ändert nichts.
Eine zu hohe MTU ist aktuell der mit Abstand wahrscheinlichste Grund für das Problem.
1
Guten Morgen zusammen,
ich teste nächste Woche weitere Werte.
Netcom hatte ich an der Leitung sie sagten MTU 1400 und haben noch ipv6 abgeschaltet. Mein externer IT sagt 1452.
@madnem: wir haben auch einen dritten Standort im VPN mit VDSL100 (100/25) das lief ohne Probleme bis es die Umstellung auf PPPoE gab. Ich melde mich.
ich teste nächste Woche weitere Werte.
Netcom hatte ich an der Leitung sie sagten MTU 1400 und haben noch ipv6 abgeschaltet. Mein externer IT sagt 1452.
@madnem: wir haben auch einen dritten Standort im VPN mit VDSL100 (100/25) das lief ohne Probleme bis es die Umstellung auf PPPoE gab. Ich melde mich.
und haben noch ipv6 abgeschaltet.
Was für ein Unsinn!!! Aber egal..muss man sicher nicht mehr kommentieren sowas.Mein externer IT sagt 1452.
Der redet dann nur von der PPPoE MTU. Hast du ihm auch gesagt das es PPPoE plus der VPN Protokolloverhead ist der für die WAN MTU relevant ist??
Morjn, ja er weiß eigentlich das wir da drüber ein VPN am laufen haben. Morgen abend teste ich.
Hallo zusammen, bin jetzt glücklicher Besitzer eines stabilen VPN. Am Ende war es stabil bei 1400. Trotzdem musste auch die Gegenstelle also die mit DLAN100 auf 1400 geändert werden.
Trotzdem musste auch die Gegenstelle also die mit DLAN100 auf 1400 geändert werden.
Es wäre ja ziemlich sinnfrei sowas nur einseitig zu machen. Eine simple Binsenweisheit bei MTU Setups die jeder gute Netzwerk Administrator kennt. Gut das es nun klappt wie es soll....
Sry, aber am 3.04. 13:39 hast du noch das ganze Gegenteil geschrieben ;)
Egal, jetzt geht es ja.
Egal, jetzt geht es ja.
Sorry das war dann missverstanden, denn im Thread hattes du ja gesagt das du an Netz 1 die MTU schon gesetzt hattest.
Egal, Fakt ist das es natürlich sinnvoll ist bei einer S2S Kopplung es beidseitig zu machen.
Egal, Fakt ist das es natürlich sinnvoll ist bei einer S2S Kopplung es beidseitig zu machen.
