18
Miserable SMB Downloadrate über OpenVPN, WireGuard, IKEv2
Auf dem Diagramm ist mein Setup abgebildet.
Im LAN funktioniert alles perfekt. Beim Zugriff von außen auf das NAS:
- HTTP funktioniert gut
- SMB-Upload: WireGuard nimmt alles, was der Internet-Provider liefert. OpenVPN kommt bei 12-16Mb/s an seine Grenzen
- SMB-Download ist eine Katastrophe. Getestet mit OpenVPN, WireGuard, IKEv2/IPSec.
Ich habe die meiste Zeit bis jetzt in die OpenVPN-Config investiert, unterschiedliche MTU-Werte und Ciphers ausprobiert. Es gab hin und wieder Schübe bei der DL-Performance, aber nichts Signifikantes oder Langfristiges.
Dachte dass es mit WireGuard besser wird. Der Upload vom LAN über einen externen OpenVPN-Server geht mit ca. 50 Mb/s - alles, was der Provider liefert. D.h. an der Hardware liegt das Problem sicher nicht.
Habt Ihr Ideen, woran das DL-Problem liegt?
Im LAN funktioniert alles perfekt. Beim Zugriff von außen auf das NAS:
- HTTP funktioniert gut
- SMB-Upload: WireGuard nimmt alles, was der Internet-Provider liefert. OpenVPN kommt bei 12-16Mb/s an seine Grenzen
- SMB-Download ist eine Katastrophe. Getestet mit OpenVPN, WireGuard, IKEv2/IPSec.
Ich habe die meiste Zeit bis jetzt in die OpenVPN-Config investiert, unterschiedliche MTU-Werte und Ciphers ausprobiert. Es gab hin und wieder Schübe bei der DL-Performance, aber nichts Signifikantes oder Langfristiges.
Dachte dass es mit WireGuard besser wird. Der Upload vom LAN über einen externen OpenVPN-Server geht mit ca. 50 Mb/s - alles, was der Provider liefert. D.h. an der Hardware liegt das Problem sicher nicht.
Habt Ihr Ideen, woran das DL-Problem liegt?
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: 665251
Url: https://administrator.de/forum/miserable-smb-downloadrate-ueber-openvpn-wireguard-ikev2-665251.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
18 Kommentare
Neuester Kommentar
Hi
da bei einem DL deine pfsense die verschlüsselung vom transport übernimmt: Wie ist denn die CPU Auslastung auf der Kiste?
Ist das ne Hardware-pfsense? Wenn ja welche? Oder besser gefragt: Hat die einen eigenen Crypto-Chip ?
da bei einem DL deine pfsense die verschlüsselung vom transport übernimmt: Wie ist denn die CPU Auslastung auf der Kiste?
Ist das ne Hardware-pfsense? Wenn ja welche? Oder besser gefragt: Hat die einen eigenen Crypto-Chip ?
Hi,
ja, die pfSense läuft auf einer APU2E4. CPU-Crypto ist an.
CPU-Boost ist an, bringt aber auch nichts. CPU-Load liegt beim DL bei 2.5-5%.
ja, die pfSense läuft auf einer APU2E4. CPU-Crypto ist an.
CPU-Boost ist an, bringt aber auch nichts. CPU-Load liegt beim DL bei 2.5-5%.
Schönen guten Abend,
mal eine Frage die vielleicht auch unwichtig sein kann, was hängt alles an diesem Switch 1GBit/s noch dran, und was ist an dieser Stelle das übliche Traffic aufkommen ?
Kann dieser Switch verwaltet werden ?
Wenn das kein prof. Kiste ist, kann allein schon die Nebentraffic auf den anderen Ports, die mit diesem Szenario nicht zu tun haben dafür sorgen, dass in Richtung pfSence nicht mehr viel übrig bleibt.
Würdest du bitte noch in deiner Skizze ergänzen, welche max Übertragungsraten zwischen den einzelnen Geräten ab Fritz Cable Box bis zum NAS ( was wohl auch der SAMBA ist ) theoretisch möglich sind.
Gesunde Grüße
Kai
mal eine Frage die vielleicht auch unwichtig sein kann, was hängt alles an diesem Switch 1GBit/s noch dran, und was ist an dieser Stelle das übliche Traffic aufkommen ?
Kann dieser Switch verwaltet werden ?
Wenn das kein prof. Kiste ist, kann allein schon die Nebentraffic auf den anderen Ports, die mit diesem Szenario nicht zu tun haben dafür sorgen, dass in Richtung pfSence nicht mehr viel übrig bleibt.
Würdest du bitte noch in deiner Skizze ergänzen, welche max Übertragungsraten zwischen den einzelnen Geräten ab Fritz Cable Box bis zum NAS ( was wohl auch der SAMBA ist ) theoretisch möglich sind.
Gesunde Grüße
Kai
Wie hoch sind denn die Latenzzeiten durch das VPN?
SMB reagiert sehr stark auf Latenzen und Jitter — je höher die Latenz, desto geringer die Datenrate.
Am NAS lassen sich dahingehend ggf. Konfigurationen hinsichtlich der SMB-Write-Buffers und TCP-Einstellungen vornehmen (hier will man TCP_NODELAY haben).
Probiere notfalls mal andere Protokolle, z.B. WebDAV oder ganz Stumpf einen Download über HTTP vom NAS aus.
SMB reagiert sehr stark auf Latenzen und Jitter — je höher die Latenz, desto geringer die Datenrate.
Am NAS lassen sich dahingehend ggf. Konfigurationen hinsichtlich der SMB-Write-Buffers und TCP-Einstellungen vornehmen (hier will man TCP_NODELAY haben).
Probiere notfalls mal andere Protokolle, z.B. WebDAV oder ganz Stumpf einen Download über HTTP vom NAS aus.
Das ist ein Ubiquiti USW-24-PoE Switch. An diesem hängen vier PoE-AP's, diverse Clients wie TV's und Drucker, alle aktuell im Idle-Mode oder ausgeschaltet. 1 GB/s funktioniert im LAN einwandfrei.
Es gibt kein Nebentraffic, kein einziger Client erzeugt Traffic, nur Lebenszeichen hin und wieder.
So sieht es aktuell aus, während ich über WireGuard drin bin. Die Spitzenlast im LAN ist bei 60k.
Es gibt kein Nebentraffic, kein einziger Client erzeugt Traffic, nur Lebenszeichen hin und wieder.
So sieht es aktuell aus, während ich über WireGuard drin bin. Die Spitzenlast im LAN ist bei 60k.
Zitat von @LordGurke:
Wie hoch sind denn die Latenzzeiten durch das VPN?
SMB reagiert sehr stark auf Latenzen und Jitter — je höher die Latenz, desto geringer die Datenrate.
Am NAS lassen sich dahingehend ggf. Konfigurationen hinsichtlich der SMB-Write-Buffers und TCP-Einstellungen vornehmen (hier will man TCP_NODELAY haben).
Probiere notfalls mal andere Protokolle, z.B. WebDAV oder ganz Stumpf einen Download über HTTP vom NAS aus.
Wie hoch sind denn die Latenzzeiten durch das VPN?
SMB reagiert sehr stark auf Latenzen und Jitter — je höher die Latenz, desto geringer die Datenrate.
Am NAS lassen sich dahingehend ggf. Konfigurationen hinsichtlich der SMB-Write-Buffers und TCP-Einstellungen vornehmen (hier will man TCP_NODELAY haben).
Probiere notfalls mal andere Protokolle, z.B. WebDAV oder ganz Stumpf einen Download über HTTP vom NAS aus.
HTTP-Download vom NAS Gerade ausprobiert. Schwankt stark zw. 30 KB/s und 1900 KB/s.
Die zwei Screenshots wurden im Abstand von 10 Sek. gemacht.
Weißt Du, wo ich bei einem QNap-NAS SMB-Write-Buffers und TCP-Einstellungen ändern kann? Wenn ja, welche Werte sind sinnvoll?
Hallo ,
Darf ich dieser Aussage entnehmen, dass die pfSense genauso mit 1Gbit wie auch das NAS angeschlossen ist.
Wie und woher kommt jetzt Samba aus dem ersten Blockschaltbild ?
Ich würde jetzt einfach mal vermuten, weil mein Glaskugel weder in die Zukunft schauen kann, noch in die Vergangenheit, dass wenn über den Ubiquiti USW-24-PoE Switch wirklich was "los" ist, das es eine Traffic Problem zwischen pfSense und diesem Switch gibt.
Nur mal die theoretische Betrachtung, wenn auch das FritzCable nicht mehr kann, laufen bei wirklich intensiver Nutzung sehr viele Daten erst einmal bis zum pfSense ! DNS usw. Dazu kommt noch die Traffic die aus, oder über das Internet kommt. Ich gehe dabei immer noch davon aus, dass die pfSense auch für mögliche PoE APs das Netzwerkmanagment übernimmt. Adressvergabe gleich welcher Art ?
Eigentlich müsste man jetzt hier mal die Routing Strukturen kennen um weiter zu kommen.
PoE -APs macht da jeder seins, oder ist das eine organisierte Mesh, oder CapsAp Struktur ?
Hast du schon einmal versucht Paket-Filter einzusetzen, die diesen VPN Gedöns eine Prio gibt ?
Gesunde Grüße
KAI
PS: PFIFO ist nicht immer gut, wenn im Router / = Firewall keine Prio-Regeln aufgestellt sind.
Darf ich dieser Aussage entnehmen, dass die pfSense genauso mit 1Gbit wie auch das NAS angeschlossen ist.
Wie und woher kommt jetzt Samba aus dem ersten Blockschaltbild ?
Ich würde jetzt einfach mal vermuten, weil mein Glaskugel weder in die Zukunft schauen kann, noch in die Vergangenheit, dass wenn über den Ubiquiti USW-24-PoE Switch wirklich was "los" ist, das es eine Traffic Problem zwischen pfSense und diesem Switch gibt.
Nur mal die theoretische Betrachtung, wenn auch das FritzCable nicht mehr kann, laufen bei wirklich intensiver Nutzung sehr viele Daten erst einmal bis zum pfSense ! DNS usw. Dazu kommt noch die Traffic die aus, oder über das Internet kommt. Ich gehe dabei immer noch davon aus, dass die pfSense auch für mögliche PoE APs das Netzwerkmanagment übernimmt. Adressvergabe gleich welcher Art ?
Eigentlich müsste man jetzt hier mal die Routing Strukturen kennen um weiter zu kommen.
PoE -APs macht da jeder seins, oder ist das eine organisierte Mesh, oder CapsAp Struktur ?
Hast du schon einmal versucht Paket-Filter einzusetzen, die diesen VPN Gedöns eine Prio gibt ?
Gesunde Grüße
KAI
PS: PFIFO ist nicht immer gut, wenn im Router / = Firewall keine Prio-Regeln aufgestellt sind.
Zitat von @Kai-aus-der-Kiste:
Hallo ,
Darf ich dieser Aussage entnehmen, dass die pfSense genauso mit 1Gbit wie auch das NAS angeschlossen ist.
Hallo ,
Darf ich dieser Aussage entnehmen, dass die pfSense genauso mit 1Gbit wie auch das NAS angeschlossen ist.
Ja, die Annahme ist korrekt.
Wie und woher kommt jetzt Samba aus dem ersten Blockschaltbild ?
Samba läuft auf dem NAS.
Ich würde jetzt einfach mal vermuten, weil mein Glaskugel weder in die Zukunft schauen kann, noch in die Vergangenheit, dass wenn über den Ubiquiti USW-24-PoE Switch wirklich was "los" ist, das es eine Traffic Problem zwischen pfSense und diesem Switch gibt.
An der Stelle gab es noch nie ein Problem. Das ganze Setup ist in einem privaten Haushalt, es gibt keine Traffic-Probleme im LAN oder WAN.
Nur beim Zugriff auf das NAS von außen und nur beim DL. Bei UL bekomme ich 200 Mb/s über den gleichen Kanal.
Nur mal die theoretische Betrachtung, wenn auch das FritzCable nicht mehr kann, laufen bei wirklich intensiver Nutzung sehr viele Daten erst einmal bis zum pfSense ! DNS usw. Dazu kommt noch die Traffic die aus, oder über das Internet kommt. Ich gehe dabei immer noch davon aus, dass die pfSense auch für mögliche PoE APs das Netzwerkmanagment übernimmt. Adressvergabe gleich welcher Art ?
Die Annahme ist auch korrekt. Auf der pfSense laufen DHCP Server für die VLANs, alle Clients haben statische DHCP-Mappings, auch die AP's. DNS-Server ist auch aktiviert, aber diese beiden erzeugen sicher keine Last, die zum Einbruch der DL-Geschwindigkeit über VPN führen.
Eigentlich müsste man jetzt hier mal die Routing Strukturen kennen um weiter zu kommen.
PoE -APs macht da jeder seins, oder ist das eine organisierte Mesh, oder CapsAp Struktur ?
Kein Mesh. LAN-Kabel vom Switch zu allen AP's. Gleiche VLAN-config und gleiche SSID's. Unifi-Controller managt das ganze SDN.PoE -APs macht da jeder seins, oder ist das eine organisierte Mesh, oder CapsAp Struktur ?
Hast du schon einmal versucht Paket-Filter einzusetzen, die diesen VPN Gedöns eine Prio gibt ?
Nein, noch nicht.
Gesunde Grüße
KAI
PS: PFIFO ist nicht immer gut, wenn im Router / = Firewall keine Prio-Regeln aufgestellt sind.
Ehrlich gesagt, denke ich gerade in die gleiche Richtung wie @LordGurke. Ich denke, das Problem liegt nicht am Netzwerk, sondern am NAS.
Denn das Problem ist gleich bei allen getesteten VPN-Protokollen, inzwischen mit neuerer pfSense-Hardware.
Ich werde versuchen die SMB-Parameter am NAS zu ändern.
Hallo @justas
Ich bin leider nur eine HW Ressourcen Denker !
Der Switch macht alles für die APs ? Richtig ?
Wenn jetzt eine AP Endgerät oder auch ein paar mehr ohne wirkliches WDS zwischen den APs springen, was passiert dann im Backbone = deinem Switch ?
Der hat Last !
Weil er muss Datenpakete die zu AP1 sollten, nun noch einmal zu einem weiteren AP senden, damit der Datenstrom am WLAN Client nicht abreist ! Das heißt aber auch, ohne das ein Mangementsystem gleich welcher Art verwendet wird, oder zum Einsatz kommt, dass der Switch je nach Time Out Einstellung die Pakete erst verwirft, wenn das Timeout Limit erreicht ist.
Solange und der Routing Prozessor in diesem Switch kann nicht mehr als als 1 GBit/S ohne Regel durchleiten. Also kreiseln konsequenter Weise irgendwelche Pakete solange in diesem Switch bis diese als "abegnommen" bestätigt wurden. Damit kommt die Pfifo Regel ins Schleudern. Denn die will diese Pakete weil sie zuerst reingekommen sind auch wieder loswerden. Nun kommt noch hinzu, dass die Datenraten-Kapazität auf 1 Gbit beschränkt sind ! Jetzt kommt die Verbindung zu pfSence ins Stocken und der muss immer weiter und weiter rechnen, bekommt aber nur eine unvollständige Antwort um deinen Crypto-Schlüssel der auch noch zu diese externen Open-VPN Server muss.
Schau dir das Protokoll an !
Gesunde Grüße
KAI
PS: Wenn die pfSence Kiste keine wirkliches Lastproblem hat, dann liegt automatisch an diesem Switch ! Der ist der Hemmschuh ! Wenn der ohnehin fast ohne echtes WLAN Management überlastete Switch dann auch noch andere Sachen muss. Nur zum Verständnis "PfiFo" heist, Packet first in - First out !
Was als erstes eintrifft wird und muss als erstes wieder abgegeben werden !
Das sind primitive Routing Regeln.
Ich bin leider nur eine HW Ressourcen Denker !
Der Switch macht alles für die APs ? Richtig ?
Wenn jetzt eine AP Endgerät oder auch ein paar mehr ohne wirkliches WDS zwischen den APs springen, was passiert dann im Backbone = deinem Switch ?
Der hat Last !
Weil er muss Datenpakete die zu AP1 sollten, nun noch einmal zu einem weiteren AP senden, damit der Datenstrom am WLAN Client nicht abreist ! Das heißt aber auch, ohne das ein Mangementsystem gleich welcher Art verwendet wird, oder zum Einsatz kommt, dass der Switch je nach Time Out Einstellung die Pakete erst verwirft, wenn das Timeout Limit erreicht ist.
Solange und der Routing Prozessor in diesem Switch kann nicht mehr als als 1 GBit/S ohne Regel durchleiten. Also kreiseln konsequenter Weise irgendwelche Pakete solange in diesem Switch bis diese als "abegnommen" bestätigt wurden. Damit kommt die Pfifo Regel ins Schleudern. Denn die will diese Pakete weil sie zuerst reingekommen sind auch wieder loswerden. Nun kommt noch hinzu, dass die Datenraten-Kapazität auf 1 Gbit beschränkt sind ! Jetzt kommt die Verbindung zu pfSence ins Stocken und der muss immer weiter und weiter rechnen, bekommt aber nur eine unvollständige Antwort um deinen Crypto-Schlüssel der auch noch zu diese externen Open-VPN Server muss.
Schau dir das Protokoll an !
Gesunde Grüße
KAI
PS: Wenn die pfSence Kiste keine wirkliches Lastproblem hat, dann liegt automatisch an diesem Switch ! Der ist der Hemmschuh ! Wenn der ohnehin fast ohne echtes WLAN Management überlastete Switch dann auch noch andere Sachen muss. Nur zum Verständnis "PfiFo" heist, Packet first in - First out !
Was als erstes eintrifft wird und muss als erstes wieder abgegeben werden !
Das sind primitive Routing Regeln.
1
@Kai-aus-der-Kiste:
Könnten wir uns darauf einigen, dass das Netzwerk beim TO nicht der Flaschenhals ist?
Laut den Grafiken der Portauslastung ist das weit entfernt davon, ausgelastet zu sein. Ganz weit davon entfernt.
Wenn da wenigstens 600-700 Mbps Last im 15s-Durchschnitt auf dem Port wären, würde ich auch anfangen, in Richtung Congestion zu denken.
Bei weniger als 1 Mbps (also 0,1% Last) wie hier ist da aber weit und breit keine Überlastung des Links.
Abgesehen davon, dass das, was du da beschreibst, in großen Teilen haarsträubender Unsinn ist.
Vielleicht willst du ja nochmal nachsehen, ob in einem Layer 2-Switch wirklich ein Routing-Prozessor ist und dann solltest du auch mal nachsehen, wie so eine Backplane eines Switches dimensioniert ist. Der USW-24 kann mindestens 26 Gbps non-blocking forwarden bei > 38 Mpps.
Nichts von dem, was da am NAS und den restlichen Geräten passiert, dürfte einen dieser Werte ausreizen. Und siehe Grafiken: Weniger als 0,1 Prozent Auslastung des Ports zwischen Switch und pfSense.
@justas:
Nachdem das bei HTTP auch hakt, wäre eigentlich SMB als schuldiges Protokoll raus.
Derartig stakkatohafter Datentransfer könnte von Packetloss stammen - kannst du mal mehrere HTTP-Übertragungen gleichzeitig laufen lassen und gleichzeitig per Dauerping durch den VPN-Tunnel auf die Gegenstelle (die Tunnel-Adresse der pfSense) machen? Oder auch auf das NAS?
Die 1,7 MByte/s würden dem Maximum deines verfügbaren Uploads von 16 Mbps entsprechen - da lässt sich wenig rausholen.
Wenn da aber Packetloss auftritt (weshalb auch immer) erklärt das zumindest die Einbrüche der Geschwindigkeit.
Falls der Packetloss auftritt, weil da irgendwo ein Rate-Limiting für UDP stattfindet, könnte man testweise mal versuchen, OpenVPN über TCP zu benutzen. Das wäre zwar langsamer als nötig, aber möglicherweise dennoch schneller als UDP.
Nachtrag:
Wenn wir von "Upload" und "Download" sprechen - welche Richtung meinen wir dann?
Beschreibt "Download" die Richtung "Client lädt etwas auf das NAS hoch?"
Falls dem so ist, kannst du in den Systemeinstellungen -> Netzwerk- und Dateiservices -> Win/Mac/NFS -> im Tab "Microsoft-Netzwerk" -> Erweiterte Optionen
einmal versuchen "Asynchrones E/A" zu aktivieren. Da wird aber zu Recht vor gewarnt, das sorgt dafür, dass mehr Buffers im RAM gehalten werden und es könnte gerade bei abruptem Ausschalten des NAS eher zu Datenverlust kommen.
Könnten wir uns darauf einigen, dass das Netzwerk beim TO nicht der Flaschenhals ist?
Laut den Grafiken der Portauslastung ist das weit entfernt davon, ausgelastet zu sein. Ganz weit davon entfernt.
Wenn da wenigstens 600-700 Mbps Last im 15s-Durchschnitt auf dem Port wären, würde ich auch anfangen, in Richtung Congestion zu denken.
Bei weniger als 1 Mbps (also 0,1% Last) wie hier ist da aber weit und breit keine Überlastung des Links.
Abgesehen davon, dass das, was du da beschreibst, in großen Teilen haarsträubender Unsinn ist.
Vielleicht willst du ja nochmal nachsehen, ob in einem Layer 2-Switch wirklich ein Routing-Prozessor ist und dann solltest du auch mal nachsehen, wie so eine Backplane eines Switches dimensioniert ist. Der USW-24 kann mindestens 26 Gbps non-blocking forwarden bei > 38 Mpps.
Nichts von dem, was da am NAS und den restlichen Geräten passiert, dürfte einen dieser Werte ausreizen. Und siehe Grafiken: Weniger als 0,1 Prozent Auslastung des Ports zwischen Switch und pfSense.
@justas:
Nachdem das bei HTTP auch hakt, wäre eigentlich SMB als schuldiges Protokoll raus.
Derartig stakkatohafter Datentransfer könnte von Packetloss stammen - kannst du mal mehrere HTTP-Übertragungen gleichzeitig laufen lassen und gleichzeitig per Dauerping durch den VPN-Tunnel auf die Gegenstelle (die Tunnel-Adresse der pfSense) machen? Oder auch auf das NAS?
Die 1,7 MByte/s würden dem Maximum deines verfügbaren Uploads von 16 Mbps entsprechen - da lässt sich wenig rausholen.
Wenn da aber Packetloss auftritt (weshalb auch immer) erklärt das zumindest die Einbrüche der Geschwindigkeit.
Falls der Packetloss auftritt, weil da irgendwo ein Rate-Limiting für UDP stattfindet, könnte man testweise mal versuchen, OpenVPN über TCP zu benutzen. Das wäre zwar langsamer als nötig, aber möglicherweise dennoch schneller als UDP.
Nachtrag:
Wenn wir von "Upload" und "Download" sprechen - welche Richtung meinen wir dann?
Beschreibt "Download" die Richtung "Client lädt etwas auf das NAS hoch?"
Falls dem so ist, kannst du in den Systemeinstellungen -> Netzwerk- und Dateiservices -> Win/Mac/NFS -> im Tab "Microsoft-Netzwerk" -> Erweiterte Optionen
einmal versuchen "Asynchrones E/A" zu aktivieren. Da wird aber zu Recht vor gewarnt, das sorgt dafür, dass mehr Buffers im RAM gehalten werden und es könnte gerade bei abruptem Ausschalten des NAS eher zu Datenverlust kommen.
@LordGurke
Nein. Darauf einige ich mich nicht mit ihren !
denn "schitt" doch auf diese undurchsichtige Kommentierfunktion ! Mir ist das jetzt auch egal !
Sieht es halt aus wie es ist !
Er schrieb das alle oder keine aktiven Geräte vorhanden waren, oder in der Idle ( Schlafstellung ) waren !
Wenn der Switch nicht über andere Ports angesprochen wird / oder wurde, dann ergibt das kein Gesamtbild ! Sorry
Es ist nur eine Momentaufnahme als ein Gerät von Außen, ohne das interne Traffic bestand, oder genutzt wurde so für ein Zeitfenster X dokumentiert wurde.
Gesunde Grüße und gute Nacht
KAI
Zitat von @LordGurke:
@Kai-aus-der-Kiste:
Könnten wir uns darauf einigen, dass das Netzwerk beim TO nicht der Flaschenhals ist?
Laut den Grafiken der Portauslastung ist das weit entfernt davon, ausgelastet zu sein. Ganz weit davon entfernt.
Wenn da wenigstens 600-700 Mbps Last im 15s-Durchschnitt auf dem Port wären, würde ich auch anfangen, in Richtung Congestion zu denken.
Bei weniger als 1 Mbps (also 0,1% Last) wie hier ist da aber weit und breit keine Überlastung des Links.
@Kai-aus-der-Kiste:
Könnten wir uns darauf einigen, dass das Netzwerk beim TO nicht der Flaschenhals ist?
Laut den Grafiken der Portauslastung ist das weit entfernt davon, ausgelastet zu sein. Ganz weit davon entfernt.
Wenn da wenigstens 600-700 Mbps Last im 15s-Durchschnitt auf dem Port wären, würde ich auch anfangen, in Richtung Congestion zu denken.
Bei weniger als 1 Mbps (also 0,1% Last) wie hier ist da aber weit und breit keine Überlastung des Links.
Nein. Darauf einige ich mich nicht mit ihren !
Das ist ein Ubiquiti USW-24-PoE Switch. An diesem hängen vier PoE-AP's, diverse Clients wie TV's und Drucker, alle >>Aktuell im Idle-Mode oder ausgeschaltet. 1 GB/s funktioniert im LAN einwandfrei.
Sieht es halt aus wie es ist !
Er schrieb das alle oder keine aktiven Geräte vorhanden waren, oder in der Idle ( Schlafstellung ) waren !
Wenn der Switch nicht über andere Ports angesprochen wird / oder wurde, dann ergibt das kein Gesamtbild ! Sorry
Es ist nur eine Momentaufnahme als ein Gerät von Außen, ohne das interne Traffic bestand, oder genutzt wurde so für ein Zeitfenster X dokumentiert wurde.
Gesunde Grüße und gute Nacht
KAI
Auf die Gefahr hin, die Trolle zu füttern:
Dir ist klar, dass ein Fehler, der auftritt wenn man die vermeintliche Ursache ("Nebentraffic") ausschließt, im wesentlichen nur beweist, dass die vermeintliche Ursache eben doch nicht die Ursache für das Problem ist?
Wenn zu Hause Wasser aus der Decke tropft und du eine gebrochene Wasserleitung vermutest, das Wasser abstellst und es trotzdem weiter tropft, dann war die Ursache offensichtlich keine geborstene Wasserleitung.
Und wenn auf einem Switch, bei dem du Überlastung vermutest, auch bei Wegnahme des Traffics aller sonstigen Teilnehmer das gleiche Fehlerbild bestehen bleibt, dann kann es wohl kaum eine Überlastung des Switches sein.
Erst Recht nicht, weil der "Nebentraffic" mindestens 26 Gbps oder 38 Mpps erreichen müsste.
Er schrieb das alle oder keine aktiven Geräte vorhanden waren, oder in der Idle ( Schlafstellung ) waren !
Wenn der Switch nicht über andere Ports angesprochen wird / oder wurde, dann ergibt das kein Gesamtbild ! Sorry
Wenn der Switch nicht über andere Ports angesprochen wird / oder wurde, dann ergibt das kein Gesamtbild ! Sorry
Dir ist klar, dass ein Fehler, der auftritt wenn man die vermeintliche Ursache ("Nebentraffic") ausschließt, im wesentlichen nur beweist, dass die vermeintliche Ursache eben doch nicht die Ursache für das Problem ist?
Wenn zu Hause Wasser aus der Decke tropft und du eine gebrochene Wasserleitung vermutest, das Wasser abstellst und es trotzdem weiter tropft, dann war die Ursache offensichtlich keine geborstene Wasserleitung.
Und wenn auf einem Switch, bei dem du Überlastung vermutest, auch bei Wegnahme des Traffics aller sonstigen Teilnehmer das gleiche Fehlerbild bestehen bleibt, dann kann es wohl kaum eine Überlastung des Switches sein.
Erst Recht nicht, weil der "Nebentraffic" mindestens 26 Gbps oder 38 Mpps erreichen müsste.
In der Zwischenzeit habe ich eine kleine Verbesserung erzielt:
Auf dem NAS: Network Settings -> Interfaces -> Adapter 1 -> Jumbo-Frame auf 9000 erhöht.
Bei der DL-Rate ist jetzt alles zwischen 0 und 4,5 MB/s möglich.
An dem Gebirge auf dem letzten Bild sieht man, die instabil die Rate ist.
Wenn ich gleichzeitig mehrere HTTP-Downloads starte, bleibt die DL-Rate stabiler und springt nicht mehr so wie bei einem DL.
Ping ist bei ca. 50ms mit drei parallelen Downloads sowie ohne Downloads.
Langfristig werde ich vermutlich auf WireGuard umsteigen, welches nur über UDP geht.
Nachtrag:
Wenn wir von "Upload" und "Download" sprechen - welche Richtung meinen wir dann?
Beschreibt "Download" die Richtung "Client lädt etwas auf das NAS hoch?"
Mit Download meine ich dass der Client etwas vom NAS downloadet. Bis zu 50 Mb/s sind möglich.
Upload, wenn ich etwas vom Client aufs NAS schiebe. Dabei komme ich mit WG auf 200 Mb/s - alles, was der Provider hergibt.
Falls dem so ist, kannst du in den Systemeinstellungen -> Netzwerk- und Dateiservices -> Win/Mac/NFS -> im Tab "Microsoft-Netzwerk" -> Erweiterte Optionen
einmal versuchen "Asynchrones E/A" zu aktivieren. Da wird aber zu Recht vor gewarnt, das sorgt dafür, dass mehr Buffers im RAM gehalten werden und es könnte gerade bei abruptem Ausschalten des NAS eher zu Datenverlust kommen.
Habe die Option gerade getestet. Der Gewinn, den ich mit Jumbo-Frame vorher erzielt habe, wird dadurch getilgt. DL-Rate bricht wieder auf 350 Kb/s. Habe sie wieder ausgeschaltet.
Auf dem NAS: Network Settings -> Interfaces -> Adapter 1 -> Jumbo-Frame auf 9000 erhöht.
Bei der DL-Rate ist jetzt alles zwischen 0 und 4,5 MB/s möglich.
An dem Gebirge auf dem letzten Bild sieht man, die instabil die Rate ist.
Zitat von @LordGurke:
@justas:
Nachdem das bei HTTP auch hakt, wäre eigentlich SMB als schuldiges Protokoll raus.
Derartig stakkatohafter Datentransfer könnte von Packetloss stammen - kannst du mal mehrere HTTP-Übertragungen gleichzeitig laufen lassen und gleichzeitig per Dauerping durch den VPN-Tunnel auf die Gegenstelle (die Tunnel-Adresse der pfSense) machen? Oder auch auf das NAS?
@justas:
Nachdem das bei HTTP auch hakt, wäre eigentlich SMB als schuldiges Protokoll raus.
Derartig stakkatohafter Datentransfer könnte von Packetloss stammen - kannst du mal mehrere HTTP-Übertragungen gleichzeitig laufen lassen und gleichzeitig per Dauerping durch den VPN-Tunnel auf die Gegenstelle (die Tunnel-Adresse der pfSense) machen? Oder auch auf das NAS?
Wenn ich gleichzeitig mehrere HTTP-Downloads starte, bleibt die DL-Rate stabiler und springt nicht mehr so wie bei einem DL.
Ping ist bei ca. 50ms mit drei parallelen Downloads sowie ohne Downloads.
Die 1,7 MByte/s würden dem Maximum deines verfügbaren Uploads von 16 Mbps entsprechen - da lässt sich wenig rausholen.
Mein verfügbarer Upload ist bei 50Mb/s.Wenn da aber Packetloss auftritt (weshalb auch immer) erklärt das zumindest die Einbrüche der Geschwindigkeit.
Falls der Packetloss auftritt, weil da irgendwo ein Rate-Limiting für UDP stattfindet, könnte man testweise mal versuchen, OpenVPN über TCP zu benutzen. Das wäre zwar langsamer als nötig, aber möglicherweise dennoch schneller als UDP.
Das werde ich morgen versuchen.Falls der Packetloss auftritt, weil da irgendwo ein Rate-Limiting für UDP stattfindet, könnte man testweise mal versuchen, OpenVPN über TCP zu benutzen. Das wäre zwar langsamer als nötig, aber möglicherweise dennoch schneller als UDP.
Langfristig werde ich vermutlich auf WireGuard umsteigen, welches nur über UDP geht.
Nachtrag:
Wenn wir von "Upload" und "Download" sprechen - welche Richtung meinen wir dann?
Beschreibt "Download" die Richtung "Client lädt etwas auf das NAS hoch?"
Mit Download meine ich dass der Client etwas vom NAS downloadet. Bis zu 50 Mb/s sind möglich.
Upload, wenn ich etwas vom Client aufs NAS schiebe. Dabei komme ich mit WG auf 200 Mb/s - alles, was der Provider hergibt.
Falls dem so ist, kannst du in den Systemeinstellungen -> Netzwerk- und Dateiservices -> Win/Mac/NFS -> im Tab "Microsoft-Netzwerk" -> Erweiterte Optionen
einmal versuchen "Asynchrones E/A" zu aktivieren. Da wird aber zu Recht vor gewarnt, das sorgt dafür, dass mehr Buffers im RAM gehalten werden und es könnte gerade bei abruptem Ausschalten des NAS eher zu Datenverlust kommen.
Habe die Option gerade getestet. Der Gewinn, den ich mit Jumbo-Frame vorher erzielt habe, wird dadurch getilgt. DL-Rate bricht wieder auf 350 Kb/s. Habe sie wieder ausgeschaltet.
Das mit den Jumboframes ist aber sonderbar...
Spätestens der Router zum Internet macht da wieder kleine Päckchen draus.
Spätestens der Router zum Internet macht da wieder kleine Päckchen draus.
Heute ist der gestrige Gewinn durch Jumbo-Frames wieder verschwunden. Ich habe trotz des Settings wieder die alte DL-Rate von 350 KB/s. Sowohl bei WG als auch bei OpenVPN - UDP und TCP.
Es muss tiefer in den QNap-NAS-Settings gegraben werden.
Any ideas?
Es muss tiefer in den QNap-NAS-Settings gegraben werden.
Any ideas?
schleife doch mal dein NAS Webinterface direkt per Portfreigabe durch und lade mal direkt vom NAS runter, ohne die VPN dazwischen.
Dann weisst du schon mal ob es an der VPN und damit an der Firewall liegt oder nicht.
Ansonsten musst du einfach nach dem Ausschlussprinzip ran gehen.
Erst die NAS Box direkt an die Fritte hängen und so probieren.
Dann an die Firewall hängen
usw
einfach den Schuldigen langsam einkreisen. Weil, wir wissen ja weiterhin nicht wo das eigentliche Problem liegt. Also muss man erst mal die zu untersuchende Fläche reduzieren
[EDIT]
Auch mal das Protokoll ausschliessen und mit iPerf messen
Dann weisst du schon mal ob es an der VPN und damit an der Firewall liegt oder nicht.
Ansonsten musst du einfach nach dem Ausschlussprinzip ran gehen.
Erst die NAS Box direkt an die Fritte hängen und so probieren.
Dann an die Firewall hängen
usw
einfach den Schuldigen langsam einkreisen. Weil, wir wissen ja weiterhin nicht wo das eigentliche Problem liegt. Also muss man erst mal die zu untersuchende Fläche reduzieren
[EDIT]
Auch mal das Protokoll ausschliessen und mit iPerf messen
Zitat von @SeaStorm:
schleife doch mal dein NAS Webinterface direkt per Portfreigabe durch und lade mal direkt vom NAS runter, ohne die VPN dazwischen.
Dann weisst du schon mal ob es an der VPN und damit an der Firewall liegt oder nicht.
Ansonsten musst du einfach nach dem Ausschlussprinzip ran gehen.
Erst die NAS Box direkt an die Fritte hängen und so probieren.
Dann an die Firewall hängen
usw
einfach den Schuldigen langsam einkreisen. Weil, wir wissen ja weiterhin nicht wo das eigentliche Problem liegt. Also muss man erst mal die zu untersuchende Fläche reduzieren
[EDIT]
Auch mal das Protokoll ausschliessen und mit iPerf messen
schleife doch mal dein NAS Webinterface direkt per Portfreigabe durch und lade mal direkt vom NAS runter, ohne die VPN dazwischen.
Dann weisst du schon mal ob es an der VPN und damit an der Firewall liegt oder nicht.
Ansonsten musst du einfach nach dem Ausschlussprinzip ran gehen.
Erst die NAS Box direkt an die Fritte hängen und so probieren.
Dann an die Firewall hängen
usw
einfach den Schuldigen langsam einkreisen. Weil, wir wissen ja weiterhin nicht wo das eigentliche Problem liegt. Also muss man erst mal die zu untersuchende Fläche reduzieren
[EDIT]
Auch mal das Protokoll ausschliessen und mit iPerf messen
Danke für die gute Idee. Kabel umstecken kann ich erst, wenn ich wieder vor Ort bin.
Habe gerade den Port 443 durchgeschleift.
Habe auch den Port 445 (SMB) durchgeschleift. Komme vom Windows 10 Client mit \\public_ip\ nicht auf das NAS. Da fehlt wohl noch etwas.
Mit iPerf kenne ich mich leider (noch) nicht aus.
Zitat von @SeaStorm:
schleife doch mal dein NAS Webinterface direkt per Portfreigabe durch und lade mal direkt vom NAS runter, ohne die VPN dazwischen.
Dann weisst du schon mal ob es an der VPN und damit an der Firewall liegt oder nicht.
Ansonsten musst du einfach nach dem Ausschlussprinzip ran gehen.
Erst die NAS Box direkt an die Fritte hängen und so probieren.
Dann an die Firewall hängen
usw
Habe gerade das NAS direkt hinter die Fritte gehängt und den Port 443 umgeleitet. Die Downloadrate vom NAS zum Client ist ca. 2,5 Mb/s. Mit der pfSense-Box dazwischen sind es aktuell 120-200 KB/s. Der Upload zum NAS ist gut, auch mit pfSense dazwischen.schleife doch mal dein NAS Webinterface direkt per Portfreigabe durch und lade mal direkt vom NAS runter, ohne die VPN dazwischen.
Dann weisst du schon mal ob es an der VPN und damit an der Firewall liegt oder nicht.
Ansonsten musst du einfach nach dem Ausschlussprinzip ran gehen.
Erst die NAS Box direkt an die Fritte hängen und so probieren.
Dann an die Firewall hängen
usw
Folglich hat das Problem nichts mit SMB oder VPN zu tun -> bleibt die pfSense-config.
Habe Snort auf dem WAN-Interface von pfSense abgeschaltet. Downloadrate mind. verfünffacht: 600-1200 KB/s. Ist bereits deutlich besser, aber noch nicht so gut wie ohne pfSense. Wenn ich weiter nichts finde, mache vermutlich einen neuen Thread auf und skizziere beide Setups ohne VPN und mit mehr Details zur pfSense-config.
