Dec 18, 2017, updated at 15:43:40 (UTC)

10855

SSL-VPN Durchsatz mit ZyXEL USG 110 und USG 100 sehr gering

Hallo Leute,

ich eröffne dann mal mein zweites größeres Thema mit dem ich mich schon lange rumschlage...

Ich habe seit einigen Jahren als Firewall eine ZyXEL ZyWALL USG 100 im Einsatz gehabt, welche mich an sich nie enttäuscht hat. Das einzige Thema, welches mir immer wieder unangenehm aufgestroßen ist, war der Duchsatz des SSL-VPN. Ich habe diese Angelegenheit vom Hersteller aber nicht weiter verfolgen lassen und selbst auch irgendwann aufgehört mit der Fehlersuche, da ich es schlicht und einfach auf die CPU-Geschindigkeit dieser Firewall geschoben habe (400 MHz Single Core Prozessor ist verbaut).

Wir reden hier von Geschwindigkeiten von ca. 70-170 Kbyte/sec. in eingehende Richtung und ca. 230 Kbyte/sec in ausgehende Richtung. Getestet wurde dies mit Dateitransferns von einem im LAN hängendem Server hin zum VPN-Client. Die Gesamtkapazität der Leitung ist Syncron 10MBit in beide Richtungen (Diese gehen auch durch. Normale Downloads oder Uploads laufen mit ca. 1,1 MByte/sec.)

Auf Grund der Durchsatzproblematik habe ich mir irgendwann eine ZyXEL USG 110 angeschafft, welche ich auf Ebay Kl. Anzeigen mal "relativ günstig" bekommen habe (425€). Ich habe soweit es die Konfigurationsmöglichkeiten der neuen Firewall zugelassen haben, die Konfig von der alten händisch und manuell übernommen. Bandbreitenlimitierung ist abgeschaltet, ADP ist abgeschaltet, Virenscan für Clients im LAN ist eingeschaltet, Firewall ist ebenfalls eingeschlatet und beinhaltet ca. 90 Rules.

Auf jedenfall: Ding eingerichtet, in Betrieb genommen und gefreut, dass es stabil läuft. Dann habe ich wieder den Durchsatz-Test des SSL-VPNs gemacht und musste mit entsetzen feststellen, dass sich nichts geändert hat. Die Geschwindigkeiten sind immer noch auf dem gleichen Neviau. Die Firewall läuft hinter einem VDSL 100-Anschluss der Deutschen Telekom. Teste ich via HTTP-Traffic (Also Downloads und Uploads via Browser) komme ich auf die volle Geschwindigkeit meiner Leitung (~95 MBit down, ~39 MBit up). Teste ich via IPSec/L2TP-VPN habe ich ebenfalls vollkommen zufriedenstellende Geschwindigkeiten. Nichts schaut dort danach aus als hätte die Firewall Performanceprobleme. Die Technischen Hardwaredaten der USG 110 sind: 4x 1 GHz QuadCore-Prozessor und 1 GB Ram.

Ich habe anschließend auch einen Test via LAN --> LAN gemacht. Das heißt ich habe HTTPS eingehend auf einem LAN-Interface erlaubt und mich auch direkt über das LAN in das SSL-VPN eingewählt (Linkspeed war in diesem Fall 1 Gbps). Die Testergebnisse waren hier zwar ein kleines Bisschen höher (ausgehend ~4,5MByte/sec., eingehend ~1,5MB/sec.). Diese Ergebnisse sind jedoch sowohl für die Hardwarespezifikationen dieser Firewall als auch für die im Test vorhandene Leitungskapazität absolut miserabel (Siehe Spezifikationen im Anhang). Mit dem LAN --> LAN Test wollte ich Probleme mit dem Internet-Modem ausschließen.

Im Übrigen ist die Prozessorauslastung der Firewall bei Übertragungen via SSL-VPN ebenfalls äußerst neidrig (3-5% max.). Das heißt an überforderter Hardware kann es ebenfalls nicht liegen. ZyXEL ist in dieses Thema mittlerweile schon seit einer Weile eingebunden und deren technische Experten haben sich die Config bereits mehrmals angesehen. Mittlerweile ist es so weit, dass mein Ticket diesbezüglich in der Entwicklungsabteilung gelandet ist und die meine Infrastruktur mit meiner Config simulieren.

Bzgl. dieses Problemes bin ich mit meinem Latein am Ende. Vor allem weil man in der USG 110 bzgl. des SSL-VPN fast keine Einstellungen treffen kann. Also zumindest bzgl. der Netzwerkverbindungseigenschaften (MTU, UDP oder TCP und so weiter...)

Ich hoffe hoffe hoffe von Euch weiß jemand was da los ist oder los sein könnte. Ich weiß es nicht und ZyXEL scheinbar auch nicht. Vielleicht hjat jemand das gleiche Problem mit einer ZyXEL USG Firewall.

Beste Grüße

Benjamin

Please also mark the comments that contributed to the solution of the article

Content-Key: 358509

Url: https://administrator.de/contentid/358509

Printed on: April 26, 2024 at 16:04 o'clock

53 Comments

Latest comment

Getestet wurde dies mit Dateitransferns von einem im LAN hängendem Server hin zum VPN-Client.

Nicht wirklich aussagekräftig und eher kontraproduktiv, denn da liegen Sharing Protokolle darunter die eben nicht optimiert sind.
Besser und sinnvoller wäre es gewesen mit einem kleinen Tool wie z.B. NetIO zu messen um aussagekräftige Resultate zu bekommen die auch vom Transportprotokoll unabhängig sind und für unterschiedliche Paketgrößen messen:
http://www.nwlab.net/art/netio/netio.html
https://web.ars.de/netio/
Allerdings ist der Durchsatz wirklich so unterirdisch mies das das auch keine großen Veränderungen gibt nach oben.

Teste ich via IPSec/L2TP-VPN habe ich ebenfalls vollkommen zufriedenstellende Geschwindigkeiten.

Das wiederspricht jezt aber diametral deinen Angaben von oben ??
Was denn nun ? Kann sie nur Kilobit/s oder ist alles zufriedenstellend. Das ist jetzt verwirrend und versteht man nicht wirklich

Aber wenn die Entwickler schon die Karten legen was erwartest du von uns. Man könnte nioch vermuten das das grundlegende Übel ein MTU Mismatch ist. Das ist häufig bei Low Budget Hardware denn viele Firmwares berechnen den Overhead durch die doppelte Encapsulierung bei VPNs falsch und stellen eine zu große MTU auf dem Link ein. Ein MTU Mismatch bewirkt dann heftige Retransmissions und reisst den Gesamtdurchsatz in den Keller.
Da du aber versäumt hast uns mitzuteilen welches VPN Protokoll du überhaupt genau verwendest von den zahllosen die es gibt ist es müßig zu spekulieren.
Auch was den Test anbetrifft, der zweifelsohne der richtige Weg ist, ist nicht wirklich klar ob du das über ein und dasselbe Interface getestet hast also quasi als Lollipop oder Router on the Stick oder ob du es wirklich über 2 Interfaces getetestet hast was richtiger wäre.
So oder so sind die Wert aber wirklich Grotte hoch 3. Eine pfSense auf einem uralten Single Core ALIX 2D13 Mainboard schafft gute 20Mbit mit SSL oder IPsec VPNs. Mit NAT geringfügig weniger.
Das sollte die Zyxel auch schaffen...eigentlich.
Hast du denn die MTU Tests mal gemacht im Testsetup ?
Lesenswert dazu:
https://www.cisco.com/c/en/us/td/docs/interfaces_modules/services_module ...
https://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issue ...

Das ein Filesharing-Protokoll zum testen nicht unbedingt 1A ist ist mir klar. Dennoch komme ich hier (wie schon erwähnt) auf Werte die selbst bei einem 1 Gbps-Link das massivst schlechteste sind, was ich je gesehen habe. DerTest-Client hängt via Lan-kabel am Switch, Der Switch hängt via Lan-Kabel an der Firewall. Also eine ganz simple und überall zu findende Config. auf dem Switch sind VLANs konfiguriert. Alle normalen Netzwerkclients aus dem Lan sind im VLAN1. Der Switch ist dafür entsperchend mit VLAN1 Access-Ports konfiguriert. Der Link vom Switch zur FW ist getagged. Also habe ich am Switch einen getaggten Port im VLAN1, als auch das VLAN1 auf der FW konfiguriert (Was ja automatisch getagged ist). Die Transferraten von einem VLAN in einanderes VLAN (In den VLANs sind natürlich auch unterschiedliche IP-Subnetze konfiguriert) sind prima. Dieser Transferraten Test wurde NICHT via SSL-VPN gemacht sondern stink normal über Ethernet. heißt also Daten kopieren über einen Router hinweg. Ich erreiche hier beim kopieren von Daten Transferraten die dem FW internen Routing-Durchsatz und Firewall-Durchsatz entsprechen. Aktiviere ich auf dem entsprechenden VLAN1-Interface der Firewall, dass es auf HTTPS und damit gleichzeitig auch aufs SSL-VPN antworten soll und verbinde mich anschließend mit dem SSL-VPN Client auf die FW über das LAN liegt die transferrate beim kopieren von daten bei ca. 1,5Mbyte/sec. Das ist (ich rechne jetzt einfach mal mit den Brutto-Werten des Herstellers) gerade mal 1/266 der möglichen gesamt VPN-Leistung und somit absoluter shit.

Ich weiß nicht genau weshalb Dich das mit dem IPSec-VPN im Gegensatz zum SSL-VPN Vergleich durcheinander bringt... Ich habe oben lediglich beschrieben, dass diese wahnsinning niedrige Transfergeschwindigkeit einzig und allein im SSL-VPN auftritt. Teste ich von außen via IPSec-VPN (Dieses ist auf der FW ebenfalls konfiguriert) komme ich auf Durchsatzwerte, welche der Herstellerbeschreibung entsprechen.

Heißt also:

IPSec-VPN: Alles ist wunderbar
SSL-VPN: grotten schlecht

Auf Deinen Ratschlag hin habe ich jetzt noch einen Test mit JPerf gemacht. Die Ergebnisse sind, dass ich in beide Richtungen durchschnittlich bei ca. 0,8MBit liege. getestet habe ich via UDP. Das kann bei einer 10MBit syncronen Leitung nicht sein.

Die FW ist auch nicht als Router-on-a-Stick konfiguriert. Jedes VLAN als auch der WAN-Link sind dedizierte Interfaces.

Die Angaben wie ich sie oben gemacht habe sind zum Teil in Kbyte/sec. und zum teil in MBit/sec. bzw. KBit/sec angegeben und entsprechen auch der Wahrheit (Ich habe als Systemadministrator keine Probleme damit mit dem Faktor 8 Werte entsprechend umzurechnen. Das bedeutet wenn eine bestimmte Wertangabe dort steht meine ich sie auch so wie sie dort steht).

Weshalb ich mich an das Forum hier wende wenn ich doch schon alles ausprobiert habe was in meiner Macht steht? Weil ich hoffe, dass jemand hier schon ähnliche Huddeleien mit USGs von ZyXEL hatte und mit entsprechenden Troubleshooting zur lösung des problems gekommen ist.

Um nochmal zusammen zu fassen...

Ich habe eine USG 110 Firewall welche einen WAN-Link besitzt der an einer 100/40MBit Leitung hängt. Auf einem bestimmten Port ist VLAN1 tagged konfiguriert, welcher auf einem Switch endet, dessen Port ebenfalls in VLAN1 getagged ist. Ein Client aus dem internen Netzwerk hängt zum testen auf einem Access-Port des Switches in VLAN1. Der Switch ist ein NETGEAR GS100E Gigabit Switch. Der SSL-VPN-Tunnel ist in einem seperaten Subnetz welches sich vom LAN-Subnetz unterscheidet und somit über die Routing und FW-Engine der USG hindrüber muss.

Ich hoffe die Dinge sind jetzt verständlicher...

Grüße

Benjamin

PS: Mit der MTU auf dem Client (SSL-VPN Client mit entsprechend virtuellem Netzwerkadapter fürs SSL-VPN) habe ich ebenfalls schon viel herumgespielt. Alles ohne Erfolg....

Ich schmeiße mal noch eine Netzwerktopologie hinterher....

Ich habe gerade noch einen Test von meinem stinknormalen Desktop Rechner aus gemacht. Ich habe mich via Dateifreigabe zur VPN-IP des derzeit verbundenen Clients verbunden und eine Vieodatei vom Rechner aus zum VPN-Client auf die lokale Festplatte kopiert. Ich erreiche hier Transferraten von der tatsächlich gegebenen Leitungsgeschwindigkeit (Siehe Bild). Kopiere ich die selbe Datei anschließend wieder zurück habe ich eine Transferrate von rund 75KByte/sec.... Da kann doch wirklich was gewaltig nicht stimmen....

Moin...

Ich habe gerade noch einen Test von meinem stinknormalen Desktop Rechner aus gemacht.

was ist für dich ein "stinknormalen Desktop Rechner" ?
für dich kann das ein Intel i3 sein, Win XP, 4GB ram... für mich ist das ein Intel I9 mit 64 GB Ram.... Win10...

IPSec-VPN: Alles ist wunderbar

was für einen VPN Client nutzt du eigentlich?

SSL-VPN: grotten schlecht

wie baust du den das SSL VPN auf? Browser wenn ja, welcher?
hast du dir dabei mal die CPU last auf deinem Client angesehen?
auf dem Router?
hast du auf deinen Clients ein AV lösung mit Browser plugin? wenn ja, schon mal Deinstalliert? abschhalten reicht meist nicht!

Frank

Grüße! Ich machs jetzt mal stichpunktartig, da ich mit Handy im Bus sitz...

Desktop Rechner: Core i5 6600, 16GB DDR4 2133, System-SSD, Windows 7 Pro x64

VPN-Client SSL: Zyxel Zywall SecuExtender v 4.0.2.0 (Neuste)

VPN-Client IPSec: Windows eigener

Aufbau des SSL-VPNs wird in Full-Tunnel-Mode realisiert. Das heißt kein Browser sondern, keine Plugins, kein AV (noch nicht mal auf Rechner. Ich verwende keine Virenscanner). Aufbau lediglich über SSL-VPN-Client als volle netzwerkseitige Lösung.

Die CPU-Last auf dem Client ist sehr niedrig. Was mir jedoch aufgefallen war ist, dass er beim senden von Daten von Außen nach innen auf dem VPN-Client sehr viel in das Logfile der SSL-VPN-Clientsoftware schreibt. Was er rein schreibt sieht mir nach Übertragungssequenzen aus. Ich schicke gleich noch einen Sreenshot. Der logfile wächst dann MB weise an. Daran, dass die Platte dadurch zu viel Last hat und zu wenig übrig bleibt um die Nutzdaten zu lesen, kann es auch nicht liegen. Die gleiche Symptomatik gibts beim Kopieren von Netzlaufwerken ebenfalls...

Die CPU-Last auf der USG liegt bei ca. 3-5% (Wegkopieren von Client zu Remote-Seite). Beim hinkopieren von Daten zum Client mit der vollen Geschwindigkeit der Leitung, liegt die CPU-Last der USG bei 9%.

Hier die Screenshots:

1. cpu-last_hinkopieren_(remote_zu_client)
2. geschwindigkeit_hinkopieren_(remote_zu_client)
3. geschwindigkeit_wegkopieren_(client_zu_remote)
4. infos_im_logfile_wegkopieren_(client_zu_remote)
5. cpu-last_wegkopieren_(client_zu_remote)

geschwindigkeit_wegkopieren_(client_zu_remote)

infos_im_logfile_wegkopieren_(client_zu_remote)

geschwindigkeit_hinkopieren_(remote_zu_client)

Das heißt also wenn der Client Daten von Remote empfängt ist die Geschwindigkeit gut und normal. Wenn der Client Daten sendet ist die Geschwindigkeit sehr schlecht und es wird wie blöde in den Logfile geschrieben (Festplatte hat dabei viele sequenzielle Zugriffe). Dieses Verhalten ist bei jeden Client so. Egal ob Desktop-Rechner auf Arbeit, VM auf Arbeit oder Laptop daheim mit LTE-Verbindung. Allerdings haben alle Clients Windows 7 Professional x64. Kann mir aber schlecht vorstellen, dass das das Problem ist...

Guten Morgen
Was hast du für Firmwarestände?

adminst

Grüße!

Firmwareseiting habe ich schon unterschiedliche durchprobiert. Zum einen das offiziell neuste Release von der Herstellerwebseite und zum anderen ein inoffizielles Weekly-Release vom FTP-Server des Herstellers. Das Gesamtverhalten gleicht exakt dem, das ich mit der vorgänger USG-Serie (ZyXEL ZyWALL USG 100) ebenfalls hatte... Und diese haben ja auch deutlich ältere Firmware releases. Heißt im Umkehrschluss: Keine einzige Firmware hat an diesem Problem jemals etwas geändert...

Benjamin

Die Kopiergeschwindigkeit im 2. Screenshot ist so übrigens perfekt, da die 10MBit syncrone Leitung, hinter der ich als Client sitze es, hier limitiert...

Hier noch ein Paar Screenshots vom vituellem Netzwerkadapter auf dem Client. Die Häkchen, welche zum Teil fehlen, habe ich zu Testzwecken entfernt. Verhalten ändert sich jedoch nicht. Die MTU ist eine herstellerseitige Angabe. Ich habe hier ebenfalls schon mit unterschiedlichsten Werten getestet. Bringt alles nichts....

habe gerade eine Wahnsinns Entdeckung gemacht... Ich dachte mir ich teste es jetzt mal unter Windows 10. Hier funktioniert es in Full-Speed. Auch das Log-File des SecuExtenders wird nichtmehr befeuert ohne ende. Die Datei bleibt klein. Das kann doch nur ein Problem mit einer Windows 7 seitigen Treibergeschichte oder sonstewas sein. Ich habe keine Ahnung wo ich hier ansetzen soll Werte zu verändern... o_O

Ja, das ist es auch wenn du IPsec mit AES 256 betreibst. Dazu musst du in der Win 7 Registry etwas "rumfummeln".
Siehe dazu auch diesen Thread:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
bzw.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
und auch
https://wiki.strongswan.org/projects/strongswan/wiki/Windows7
Auf der Zyxel werkelt ja zu 99% ein Linux mit StrongSwan im Hintergrund dafür.

Ich kann es nur noch mal sagen (Was übrigens in meinen Beschreibungen schon 200x erwähnt wurde...). ES GEHT HIER NICHT UM IPSEC-VPN !!!

Es geht ums SSL-VPN (TLS, HTTPS, Port 443).

OK sorry, übersehen oben, vergiss den Kommentar ! Allerdings geht es bei dem Win 7 Registry Eintrag generell um das Cipher Handshaking der Crypto Suite. Es ist nicht primär auf IPsec bezogen sondern generell wo AES 256 ein Thema ist.
Dann hast du letztlich ein MTU Problem oder ein Treiber Problem, das liegt ja dann auf der Hand.

Ja nur, dass der ZyXEL SecuExtender auf Windows 7 und Windows 10 theoretisch mit den gleichen Attributen installiert wird, da es ja auch ein und das selbe Installer-Paket ist. Auch die MTU auf Windows 10 unterscheidet sich in den Einstellungen des virtuellen Netzwerkadapters nicht von der auf Windows 7... Bei beiden wird die MTU 1370 eingetragen.

Auf jedenfall liegt die Ursache schon mal nicht an der Appliance selbst...

Windows 7

Windows 10

Windows 7

Windows 10 (Die Übertragungsrate ist normal noch höher. es gibt aber gerade noch anderen Internet-Traffic)

Windows 7

Windows 10

Gut zu erkennen, dass hinter dem SSL-VPN eine OpenVPN-Engine steckt...

The dialogs in Windows say nothing usefull, use iperf or netio and start Wireshark!
And also adjust the autoscaling appropriately with netsh before starting the vpn connection.

netsh int tcp set global autotuninglevel=disabled

Best regards.

Btw. why are you writing hundrets of comments and not breakdown the information at once?? That's not very clearly arranged

because of that these forum is not sorting screenshots in a cronological line when iam using many screenshots in one comment. after i posted it i have to rearrange the sorting of the screenshots combined to point 1 to x headlines regarding to the screenshots...

Zitat von @vanfeuchtsing:

because of that these forum is not sorting screenshots in a cronological line when iam using many screenshots in one comment.

Use the + Button beneath the picture to paste the pictures into you text in the right order!

Okay dude thanks for your advice

But unfortunately the netsh-command did nothing to solve it....

Its all the same like before in Win7

Fire up wireshark, like i said. normally this will show you lot's of retransmits if there's problem with window sizes.

So there is the result of copying a movie-file to my server @ home via SSL-VPN. Its a log over about 20 seconds or something like that...

http://dl-fnet.dyndns.org/_misc/wireshark.txt

maybe you can read something out of it....

thanks

Benjamin

OK, try disabling LargeSendOffload on the server side NIC settings.
VPN - Upload langsam

On the servers Ethernet-NIC which is receiving the data?

Yes.

but i think that would not explain why it will work fine when iam using a Windows 10 VM behind the same line like the Windows 7 machine is. The values on the serversides NIC havend changed in this case...

...But I tried it and it is the same shit....

Zitat von @vanfeuchtsing:

but i think that would not explain why it will work fine when iam using a Windows 10 VM behind the same line like the Windows 7 machine is. The values on the serversides NIC havend changed in this case...

I said first test with netio or iperf, because you are using the SMB protocol and this could be the problem here!

.But I tried it and it is the same shit....

Did you restart the machine?

OpenVPN based VPNs using TCP instead of UDP is, by the way, bullshit ...

I rebooted the machine and testet with UDP and a line-speed of 20MBytes/sec (just for the testscenario). The server receives 0,55MBit/sec average -_-

I tested with JPerf.

I think I have to search for the reason at the clientside. that will describe why it works fine when Iam using a Windows 10 machine. I think there is a driver-issue on every Windows 7 machine. But I dont know what and where...

A fried said that it can be because windows 7 is using an older and outdated cryptographic-provider than windows 10 is using it. but iam no cryptoman and i have more rudimentary knownledge in this case. He is one he's having much knownledge in the mathematic procedures and such things. But now I dont know if that will be real and if the next step is to convert to win 10 with all my computers or maybe if there will be another option in win 7 to change some settings, etc....?!

outdated cryptographic-provider

When this would be the case the OpenVPN tap drivers Zyxel is using could be the reason, because I have a running OpenVPN client on a W7 Machine which has a throughput of 1,19MB/s on a 10MBit Link!

I wouldn't like to rely on these proprietary zyxel clients, better use the original ones.

fukcing yes!!! it was the reason. the last hours i figured out with an IT-friend that someone says "i have problems with older TAP driver version in transfering data via OpenVPN". he changed his TAP driver version to 9.9.2 and the issue was done... ive done the same and rebooted... and what i should say: it was the reason! the transferspeed now is in this direction it should be. thanks for all your help brothers and sisters!

In the older version UDP was the used transfering-protocol and they switched it to TCP and since that time it works!

Sorry, but that is not really true ! All networkers know that TCP had a much higher overhead and is more resource consuming than UDP. Also it increases the trouble with MTU mismatches.
Even from a logical networking standpoint its totally clear that TCP encap is always a bad choice cause of the above mentioned points and netto data transfer drops dramatically.
Hence OpenVPN itself strongly recommends in its how to's to keep the client encapsulation on UDP basis and only use TCP if you have to.
If you dont face any MTU problemes or driver issues OpenVPN nearly runs wirespeed on apropriate hardware with UDP.

Yes. Simply youre right. But maybe there is an issue in implementing the UDP-protocol using OpenVPN. I dont know it but its possibe...

...And I was happy to soon about the much better performance... I just could fix it on my client PC @work. On all other PCs I tried it the issue is resistant. It is a fucked up problem... -_-

But then its definitely an issue from Zyxel or buggy Zyxel code !
"Normal" OpenVPN installations or hardware that has the Open Source code on it like pfSense firewalls etc. never face this issue of course !

But then I do not understand why it will work fine on Windows 10.... Maybe it is because of the different SMB-versions (SMB2 in Windows 7 and SMB3 in Windows 10)

Vermutlich....denn das nutzt sehr kleine IP Paketgrößen, weshalb SMB immer denkbar ungeeignet ist für Performance Tests wie man als Netzwerker weiss..
Es kann eigentlich nicht wirklich ein OpenVPN Problem sein.
Das sieht man ja auch schon daran das es auf zig anderen Platformen mit zig anderen Clients mit ganz unterschiedlichen Betriebssystemen dieses "Problem" inexistent ist.
Vermutlich eine unglückliche Kombination deiner Komponenten in dieser Konstellation.

Aber egal wenns nun erstmal einigermaßen rennt dann können wir den Case ja nun auch schliessen:
How can I mark a post as solved?

Ja nur ist die Gegenstelle immer ein Srv. 2008 R2 mit SMB2.1. Das SMB nicht das glücklichste Protokoll für Performancetests ist, ist mir schon bewusst. Im Falle: Win10 zu Srv. 2008 R2 wird sich ja am Ende auch auf den kleinsten gemeinsamen Nenner geeinigt. Das wäre also SMB 2.1. Zu der ungeeignetheit von SMB zum testen: JPerf hat via UDP den gleichen extrem schlechten Durchsatz von einer Win7 Kiste aus. Und wenn man davon ausgehen kann, dass sich auf SMB 2.1 geeinigt wird und die Transferrste unter Win10 bei 9,5MBit bei einer 10MBit Standleitung liegt, würde ich SMB als Verursacher ausschließen. Ich habe gestern einen Test mit zwei VMs gemacht. Die eine W7, die andere W10. Habe gleichzeitig und nochmal abwechselnd Übertragungen gestartet. Auch da das selbe Ergebnis... W7 schlecht, W10 perfekt. Hardware war ein Hasswell Xeon. Beide VMs hatten gleich viele CPU Kerne und RAM. Citrix XenServer Tools waren installiert. Dieses Thema macht mich wahnsinnig....

Kommt dann wohl doch eher ins große Buch der unerklärlichen Winblows (SMB) Phänomene.
Tests hier mit Linux und Mac OS-X Clients auf diversen OVPN Serverplattformen mit diversen OSen (pfSense, RasPi, Ubuntu, OpenWRT usw.) zeigen immer Wirespeed bei UDP Encapsulation.
Was mal spannend wäre ob Win 7 auch bei anderen VPN Protokollen solche Zicken macht...?!

Ja es wird wohl ins große Buch der nicht erklärlichen Phänomene kommen. Naja ZyXEL selbst ist in dieses Thema schon seit einigen Wochen involviert. Dort ist es vor einiger Zeit schon in die Entwicklungsabteilung vorgedrungen, in welcher Test mit der Konfig meiner USG Firewall gemacht werden.

Das mit Wirespeed wäre wirklich wunderbar ja. Ich habe heute mal ein Troubleshooting-Video für die Entwicklung bei ZyXEL gemacht um denen mal direkt vor augen zu führen wie es ausschaut. Den Link zum Video würd ich glatt auch mal hier posten. Wie im Video schonmal erwähnt... Bitte verzeiht meinen mäßigen gesprochenen Englisch-Skill

Sowas mach ich vllt. 1x im Jahr. ...Wenn überhaupt^^

Zum Video: http://dl-fnet.dyndns.org/_misc/troubleshooting_slowly_ssl_vpn.mp4

Grüße

Benjamin

Wirespeed minus Encapsulation Overhead natürlich

Bitte verzeiht meinen mäßigen gesprochenen Englisch-Skill

No Problem der Forenuser hat sich so oder so schon gleich am 21.12. wieder abgemeldet

https://administrator.de/userid/134998

Hi. @aqui: Den letzten Satz verstehe ich nicht ganz.

Ich habe von dem Entwickler von Zyxel jetzt eine Antwort bezüglich des Logfiles, von einem Windows 7 Rechner, auf dem es nicht ordnungsgemäß funktioniert.

Dies schrob er:

"
Thanks for providing video capture. from this video, we can see desktop windows 7 generate many "unlock read procedure" log. the SecuExtenderHelper.log size expand 1 Kb per sec , it's abnormal.
The log was caused by unable to sending TLS packets to server(USG) in time. it was caused by network delay or other issue.
I guess customer already try on many windows 7 os on their site, right? In order to narrow down this issue,
If so, please help us to check those windows 7 OS with delay issue log(C:\SecuExtenderHelper.log.)
Did it have large amount "unlock read procedure" log on those windows 7 os same as video windows 7 testing pc?

Video error log.
~~~
[ 2017/12/18 19:01:50 ][SecuExtender Agent][DEBUG] unlock read procedure
[ 2017/12/18 19:01:50 ][SecuExtender Agent][DEBUG] Res-Enc: 229, Res-Pln: 0
[ 2017/12/18 19:01:51 ][SecuExtender Agent][DEBUG] plain: 0
~~~
"

Vielleicht hat von Euch jemand eine neue Idee wo man hier ansetzen könnte...

Grüße

Benjamin

German Question Networks