10
SMB via VPN langsam, via WAN schnell
Hallo zusammen,
Wir haben folgendes Problem und können uns das Verhalten nicht wirklich erklären:
Ausgangssituation sind zwei Standorte die jeweils über eine 400/200 Mbit Glasfaseranbindung verfügen. Beide Standorte sind via Site2Site VPN vernetzt.
Clients von Standort B greifen via SMB auf Freigaben eines Windows Servers am Standort A zu. Hierbei ist die Geschwindigkeit aber teils miserabel. Das übertragen einzelner Dateien läuft noch sehr schnell (40 Mb/s), aber gerade das Wechseln / Navigieren durch Ordnerstrukturen ist extrem langsam. Die Ping-Zeit beträgt aber „nur“ 18ms durch die VPN.
Nun haben wir testweise Server A öffentlich erreichbar gemacht und vom Standort B via SMB via Internet, aber ohne VPN zugegriffen. Ergebnis: Alles läuft hervorragend. Übertragungsgeschwindigkeit und Ping sind mit 43 MB/s und 17ms ähnlich schnell wie via VPN, aber das Navigieren durch Ordner und Auflisten von Dateien ist gefühlt 5-6x schneller. Einziger Unterschied: Via VPN / ohne VPN.
Bisher lief die VPN über MikroTik Router ubd L2TP/IPSec. Wir haben gestern aber testweise auch eine Vernetzung mit zwei leistungsstarken Wireguard VMs aufgebaut mit dem gleichen Ergebnis.
Wie kommt es, dass die SMB „Verzögerung“ via VPN gefühlt 5-6x höher ist, obwohl Bandbreite und Latenz via VPN identisch zu sein scheinen?
Vielen Dank und viele Grüße
Joshua
Wir haben folgendes Problem und können uns das Verhalten nicht wirklich erklären:
Ausgangssituation sind zwei Standorte die jeweils über eine 400/200 Mbit Glasfaseranbindung verfügen. Beide Standorte sind via Site2Site VPN vernetzt.
Clients von Standort B greifen via SMB auf Freigaben eines Windows Servers am Standort A zu. Hierbei ist die Geschwindigkeit aber teils miserabel. Das übertragen einzelner Dateien läuft noch sehr schnell (40 Mb/s), aber gerade das Wechseln / Navigieren durch Ordnerstrukturen ist extrem langsam. Die Ping-Zeit beträgt aber „nur“ 18ms durch die VPN.
Nun haben wir testweise Server A öffentlich erreichbar gemacht und vom Standort B via SMB via Internet, aber ohne VPN zugegriffen. Ergebnis: Alles läuft hervorragend. Übertragungsgeschwindigkeit und Ping sind mit 43 MB/s und 17ms ähnlich schnell wie via VPN, aber das Navigieren durch Ordner und Auflisten von Dateien ist gefühlt 5-6x schneller. Einziger Unterschied: Via VPN / ohne VPN.
Bisher lief die VPN über MikroTik Router ubd L2TP/IPSec. Wir haben gestern aber testweise auch eine Vernetzung mit zwei leistungsstarken Wireguard VMs aufgebaut mit dem gleichen Ergebnis.
Wie kommt es, dass die SMB „Verzögerung“ via VPN gefühlt 5-6x höher ist, obwohl Bandbreite und Latenz via VPN identisch zu sein scheinen?
Vielen Dank und viele Grüße
Joshua
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: 631676
Url: https://administrator.de/contentid/631676
Ausgedruckt am: 13.11.2024 um 09:11 Uhr
10 Kommentare
Neuester Kommentar
Guten Morgen,
nur kurz, ist das Routing sauber?
Oder laufen die Pakete ein paar mal im Kreis rum?
Geht das kopieren der Dateien auch direkt am Anfang schnell, oder dauert das etwas?
Evtl. wäre es einen Versuch wert mal die MTU auf der VPN-Strecke zu reduzieren, evtl. macht euer Provider da noch was dazwischen.
Die 18ms finde ich bei der Leitung, sofern sie leer ist, doch was hoch.
Wie ist es im WLAN?
Viele Grüße,
Deepsys
nur kurz, ist das Routing sauber?
Oder laufen die Pakete ein paar mal im Kreis rum?
Geht das kopieren der Dateien auch direkt am Anfang schnell, oder dauert das etwas?
Evtl. wäre es einen Versuch wert mal die MTU auf der VPN-Strecke zu reduzieren, evtl. macht euer Provider da noch was dazwischen.
Die 18ms finde ich bei der Leitung, sofern sie leer ist, doch was hoch.
Wie ist es im WLAN?
Viele Grüße,
Deepsys
1
Zitat von @Deepsys:
Die 18ms finde ich bei der Leitung, sofern sie leer ist, doch was hoch.
Wie ist es im WLAN?
Die 18ms finde ich bei der Leitung, sofern sie leer ist, doch was hoch.
Wie ist es im WLAN?
@@Deepsys hatt er doch geschrieben...
Zitat von @JoRu1407:
Übertragungsgeschwindigkeit und Ping sind mit 43 MB/s und 17ms ähnlich schnell wie via VPN
Übertragungsgeschwindigkeit und Ping sind mit 43 MB/s und 17ms ähnlich schnell wie via VPN
@@JoRu1407
So wie ich das sehe, bin ich derselben Meinung wie @Deepsys das es wahrscheinlich ein Routing Problem der VPN ist. Schau dir am besten nochmal deine VPN Konfigurationen an. Ansonsten könnte es natürlich auch an deiner SMB einstellung liegen.
1
Moin,
was hier auch gerne mal die Bremse anzieht sind UTM-Features wie IPS / IDS. Ist das bei Dir auf dem Tunnel eingerichtet?
Welche VPN-Leistung sollte denn laut Hersteller durch den Tunnel gehen (evtl. kann die Hardware nicht schneller)?
Gruß
Looser
was hier auch gerne mal die Bremse anzieht sind UTM-Features wie IPS / IDS. Ist das bei Dir auf dem Tunnel eingerichtet?
Welche VPN-Leistung sollte denn laut Hersteller durch den Tunnel gehen (evtl. kann die Hardware nicht schneller)?
Gruß
Looser
1
Zitat von @Looser27:
Moin,
was hier auch gerne mal die Bremse anzieht sind UTM-Features wie IPS / IDS. Ist das bei Dir auf dem Tunnel eingerichtet?
Welche VPN-Leistung sollte denn laut Hersteller durch den Tunnel gehen (evtl. kann die Hardware nicht schneller)?
Gruß
Looser
Moin,
was hier auch gerne mal die Bremse anzieht sind UTM-Features wie IPS / IDS. Ist das bei Dir auf dem Tunnel eingerichtet?
Welche VPN-Leistung sollte denn laut Hersteller durch den Tunnel gehen (evtl. kann die Hardware nicht schneller)?
Gruß
Looser
Das mit den UTM kann ich bei Fortinet so unterschreiben, wenn das aktiv auf den Side2Side Tunnel ist, geht nahezu alles in die Knie, kann aber auch an der Firewall selbst liegen, wenn die nicht genug Leistung hat.
Gruß
@clSchak
1
Moin,
Mal mit iperf3 die Geschwindigkeit, Latenz und Jitter gemessen?
lks
Mal mit iperf3 die Geschwindigkeit, Latenz und Jitter gemessen?
lks
1
Hi,
ich bringe als mögliches Problem auch eine fehlerhafte Namensauflösung ins Spiel.
gibt es Unterschiede ob du dich per IP, Netbios-Name oder DNS Name verbindest ?
CH
ich bringe als mögliches Problem auch eine fehlerhafte Namensauflösung ins Spiel.
gibt es Unterschiede ob du dich per IP, Netbios-Name oder DNS Name verbindest ?
CH
1
UTM kann man ja sicher ausschliessen wenn das VPN mit Mikrotiks realisiert wurde.
Denkbar wäre auch eine MTU bzw. MSS Problematik die zu verstärkter Fragmentierung führt. L2TP ist da auch eher kontraproduktiv weil grßerer Overhead und weniger netto Daten. Fragt sich warum der TO nicht native IPsec verwendet hat wie es durch die Bank üblich ist bei Site to Site VPNs. Leider bietet die Beschreibung wenig Details um das zielgerichtet zu beurteilen.
Denkbar wäre auch eine MTU bzw. MSS Problematik die zu verstärkter Fragmentierung führt. L2TP ist da auch eher kontraproduktiv weil grßerer Overhead und weniger netto Daten. Fragt sich warum der TO nicht native IPsec verwendet hat wie es durch die Bank üblich ist bei Site to Site VPNs. Leider bietet die Beschreibung wenig Details um das zielgerichtet zu beurteilen.
1
Vielen Dank für die zahlreichen Antworten!
Ein Performance-Problem des Routes kann ich aktuell ausschließen, auch mit meinem Test (VPN mit 2 VM's und Wireguard) konnte ich das noch mal untermauern. Eine UTM ala Sophos oder Fortinet sind nicht im Einsatz, lediglich zwei MikroTik Router.
Die Pingzeiten von bis zu 20ms sind glaube ich normal - Oder vertue ich mich?
Beide Glasfaseranschlüsse sind bei unterschiedlichen ISP's geschaltet und am jeweils anderen Ende von Deutschland.
DNS-Problem war auch mal meine Vermutung, allerdings trat das Problem auch beim Zugriff via IP-Adressen auf.
Eure Vermutung in Richtung Routing-Problem scheint sich zu bestätigen, ich habe heute ein mal einen Fileserver am Standort A in ein vollständig separiertes Subnet gepackt, ein Site2Site VPN eingerichtet und am Standort B ebenfalls aus einem separierten Subnet auf den Server zugegriffen. Demnach waren in diesem Testaufbau ja tatsächlich nur die Routen gesetzt, die benötigt werden. Hier lief nun alles 1A.
Im Testaufbau habe ich ausschließlich mit IPv4 gearbeitet, im produktiven Netz ist bereits alles im Dual-Stack Betrieb mit IPv6. So sind hier natürlich auch Routes für ULA Adressen via VPN gesetzt und bei Hostnames A und AAAA-Records gesetzt. Ich vermute dass es hier irgendwo hakt - Obgleich an sich ja alle Verbindungen auch per IPv6 "funktionieren", aber leider nicht so zuverlässig wie gewünscht.
Oder sind euch generell im Bereich IPv6 / SMB / Latenz Probleme bekannt?
Viele Grüße,
Joshua
Ein Performance-Problem des Routes kann ich aktuell ausschließen, auch mit meinem Test (VPN mit 2 VM's und Wireguard) konnte ich das noch mal untermauern. Eine UTM ala Sophos oder Fortinet sind nicht im Einsatz, lediglich zwei MikroTik Router.
Die Pingzeiten von bis zu 20ms sind glaube ich normal - Oder vertue ich mich?
Beide Glasfaseranschlüsse sind bei unterschiedlichen ISP's geschaltet und am jeweils anderen Ende von Deutschland.
DNS-Problem war auch mal meine Vermutung, allerdings trat das Problem auch beim Zugriff via IP-Adressen auf.
Eure Vermutung in Richtung Routing-Problem scheint sich zu bestätigen, ich habe heute ein mal einen Fileserver am Standort A in ein vollständig separiertes Subnet gepackt, ein Site2Site VPN eingerichtet und am Standort B ebenfalls aus einem separierten Subnet auf den Server zugegriffen. Demnach waren in diesem Testaufbau ja tatsächlich nur die Routen gesetzt, die benötigt werden. Hier lief nun alles 1A.
Im Testaufbau habe ich ausschließlich mit IPv4 gearbeitet, im produktiven Netz ist bereits alles im Dual-Stack Betrieb mit IPv6. So sind hier natürlich auch Routes für ULA Adressen via VPN gesetzt und bei Hostnames A und AAAA-Records gesetzt. Ich vermute dass es hier irgendwo hakt - Obgleich an sich ja alle Verbindungen auch per IPv6 "funktionieren", aber leider nicht so zuverlässig wie gewünscht.
Oder sind euch generell im Bereich IPv6 / SMB / Latenz Probleme bekannt?
Viele Grüße,
Joshua
KOMMANDO ZURÜCK - Das Problem tritt auch im Testszenario auf.
Bisher funktionierte alles problemlos, weil ich auf die Shares direkt via \\ zugegriffen habe.
Tatsächlich wird das Directory Listing erst langsam, sobald ich das Share auch als Netzwerklaufwerk mappe.
Die produktiven Zugriffe liefen immer über die dazugehörigen Netzlaufwerke.
Es scheint sich also fast eher um ein Windows-Spezifisches Problem zu handeln als um ein Netzwerkproblem.
Eingrenzen lässt sich das aber nicht - Auf allen 20 Rechnern tritt das Problem gleichermaßen auf, aktuellstes Win 10 Pro.
Bisher funktionierte alles problemlos, weil ich auf die Shares direkt via \\ zugegriffen habe.
Tatsächlich wird das Directory Listing erst langsam, sobald ich das Share auch als Netzwerklaufwerk mappe.
Die produktiven Zugriffe liefen immer über die dazugehörigen Netzlaufwerke.
Es scheint sich also fast eher um ein Windows-Spezifisches Problem zu handeln als um ein Netzwerkproblem.
Eingrenzen lässt sich das aber nicht - Auf allen 20 Rechnern tritt das Problem gleichermaßen auf, aktuellstes Win 10 Pro.
Vielleicht ist genau das das Problem, ich meine, Microsoft hat in letzter Zeit einiges verbockt.
Hauptsache Cloud First ...
