OPNsense Forum
International Forums => German - Deutsch => Topic started by: superwinni2 on June 28, 2019, 12:11:39 pm
-
Hallo zusammen
habe hier einen OpenVPN Server auf meiner OPNsense welche meiner Meinung nach unzureichende Leistung im Upload bringt....
Kurze Eckdaten:
Serverseitig:
100 Mbit Down / 100 Mbit Up Leitung
CPU: Xeon E-2136 @3.30 GHz (12 cores)
RAM: 32 GB
Storage: SSD
Clientseitig:
100 Mbit Down / 20 Mbit Up Leitung
Laptop mit i7-4700MQ
16 GB RAM
M.2 SSD
Performancetechnische Probleme sollte es somit meiner Meinung nach keine Geben.
Serverconfig:
Remote Access (SSL/TLS + User Auth)
UDP
tun
DH Parameter: 4096 bit
Verschlüsselung: AES-256-CBC
Authentifizierungs-Digestalgorithmus: SHA512 (512-bit)
Komprimierung deaktiviert (hat bereits etwas mehr gebracht als auf default)
Wenn ich eine dicke Datei von der Serverseite zu mir lokal kopieren möchte zeigt mir Windows eine Geschwindigkeit von ~28 Mbit/s an.
Wenn ich diese zurück kopiere lande ich bei ~16,8 Mbit/s.
Dann habe ich mal mit iperf3 getestet:
Ich bekomme durchschnittlich ~29,6 Mbit/s im Download und ~17,6 Mbit/s im Upload hin.
Somit mal identische Werte...
Upload finde ich in Ordnung, da der Clientanschluss so oder so nur maximal 20 Mbit/s im Upload hinbekommt.
Jedoch sollte beim Download meiner Meinung nach mehr anliegen...
Jemand ne Idee warum dem so ist?
Hardwaretechnisch langweilt sich die OPNsense und der Rechner.... Zumindest so weit ich das auf den "ersten" Blick sehe....
Danke und Gruß
EDIT am 01.07.2019: MByte werte auf Mbit angepasst ;)
-
Ist deine OPNsense nativ installiert? Oder hast du es als vm laufen? Wenn es nativ installiert ist sollte da definitiv mehr gehen.
Gesendet von iPhone mit Tapatalk Pro
-
Läuft direkt auf dem Blech ;)
Gesendet von meinem LG-H815 mit Tapatalk
-
> CPU: Xeon E-2136 @3.30 GHz (12 cores)
OpenVPN ist immer noch sehr stark single-core-bound. 12 Kerne sind hübsch, bringen aber nichts. Die 3,3GHz sollten aber die 100 MBit/s ausreizen können.
MB/s Werte bei Mbps ist natürlich doof zum Vergleichen. Aber egal.
Deine Werte:
DH Parameter: 4096 bit
Verschlüsselung: AES-256-CBC
Authentifizierungs-Digestalgorithmus: SHA512 (512-bit)
Komprimierung deaktiviert (hat bereits etwas mehr gebracht als auf default)
sind aber sehr suboptimal. Sicherheit ist natürlich toll, aber alles einfach hochzudrehen bringt oft wenig. Erster Punkt ist sicher: ist AES-NI konfiguriert in den Advanced Options der Firewall. Wird also überhaupt die Crypto Beschleunigung genutzt. Was ist da eingestellt?
Zweitens die OVPN Einstellungen. Die gehen, da Userspace, mehr auf CPU und Co. Da wären angepasste Settings, die besser mit Crypto harmonieren besser. Empfohlen sind da ja u.a. die sog. NSA Suites B (B-128 oder B-256) - bitte Aluhut eingepackt lassen :D Nur weil da NSA steht, sind das keine schwachen Cryptos ;)
Empfohlen wäre dann bspw. für OVPN:
* AES-GCM 256 (128)
* Kein RSA DH statt dessen elliptische Kurven (secP384r1 oder secP521r1)
* SHA-384 (256)
Leider kann OPNsense im OpenVPN Setup noch kein "ECDH only" Setup bei den DH Parametern, vielleicht kann man sich das mal bei pfSense abschauen, genauso wie NCP und vielleicht die Unterstützung von Connection Profilen. Und mal "Subnet Topology" Mode zum Standard machen statt dem recht nervigen alten Default immer eine Adresse für den Server selbst zu nutzen.
Ich würde dein Setup aber mal auf AES256-GCM und SHA-384 mit 4k RSA ändern. Das ist tough genug ohne das Crypto-Rädchen zum Qualmen zu bringen. Und dann schau mal, was du an Performance rausholst beim Daten übertragen. GCM hatte in unseren Tests definitiv einiges mehr rausgeholt als CBC.
Grüße
-
Hi JeGr
Danke für die Info
Habe mich bisher noch nicht super sonderlich mit der VPN config befasst...
Werde am Montag versuchen die Einstellungen umzusetzen und mal schauen ob es was bringt.
Gesendet von meinem LG-H815 mit Tapatalk
-
Der größte Schub sollte aus GCM vs CBC kommen und du solltest nachsehen, wie/ob AES-NI Unterstützung geladen ist. Wenn du IPSEC nicht laufen hast, muss das AESNI Kernel Module m.W. nicht geladen sein und Cryptodev wird theoretisch auch nicht gebraucht. Der VPN Server sollte m.W. auch auf "none" stehen, weil OpenSSL selbst aktiv die Crypto ermittelt und das im Userland Kontext dann selbst nutzt. Aber da kann man auch mal mit oder ohne Cryptodev rumspielen.
Grüße
-
Hallo JeGr
habe mal alles auf Mbit editiert.
also habe IPSec mit Verbindungen aktiv.
Unter System: Settings: Miscellaneous Hardware acceleration habe ich "AES-NI CPU-base Acceleration (aesni)" aktiv.
Habe mal im VPN Server
die Verschlüsselung auf "AES-256-GCM 128" und
die Auth Digest Algorithm auf "SHA384 (384-bit)" geändert.
Download: 26 Mbit/s (hin und wieder mal einzelen verbidnungen mit ~30 Mbit/s)
Upload: 18,2 MBit/s
Bei Hardware Crypto ist "No Hardware Crypto Acceleration" eingestellt... Hier könnte ich auf "Intel RDRAND engine - RAND" umstellen. Ist dies empfehlenswert?
Wie stelle ich zudem diese epileptischen Kurven ein?
Danke und Gruß
Nachtrag:
Habe mal spaßeshalber den Server auf folgendes geändert:
DH: 1024 bit
Encryption: None
Auth Digest Algorithm: SHA1 (160-bit)
D: ~23,4 Mbit/s
U: ~18,2 Mbit/s
Dann mal diese "Intel RDRAND engine - RAND" aktiviert:
D: ~10,5 Mbit/s
U: ~18,3 Mbit/s
Dann mal
DH:4096bit
Encryption: AES-128-GCM
Auth: SHA384(384-bit)
Hardware: No
D: ~11 Mbit/s
U: ~18,3 Mbit/s
Dann nochmals alles auf Reset:
DH:4096
Encryption: AES-256-GCM
Auth: SHA384
hardware: No
D: ~23,8 Mbit/s
U: ~18,2 Mbit/s
-
> Bei Hardware Crypto ist "No Hardware Crypto Acceleration" eingestellt... Hier könnte ich auf "Intel RDRAND engine - RAND" umstellen. Ist dies empfehlenswert?
IMHO nicht. OpenSSL sollte selbst AES-NI bemerken und nutzen wenn verfügbar.
> Wie stelle ich zudem diese epileptischen Kurven ein?
Geht leider - sofern überhaupt - nur per advanced Options, hoffe dass hier ggf. noch ein wenig Parameter Pflege betrieben wird und ein paar Optionen zB. von pfSense übernommen.
> D: ~23,8 Mbit/s
> U: ~18,2 Mbit/s
Also allein, dass bei 256-GCM die Verbindung annähernd gleich ist wie ohne Encryption sagt eigentlich schon, dass AES-NI genutzt wird. Warum 128 allerdings so schwach ist verwundert mich, das müsste theoretisch mehr kommen.
Insgesamt aber OHNE Enc auch die gleichen Werte zu haben spricht eher für deine Leitung oder deine Art zu messen als Problem. Berücksichtige auch, dass ggf. der Tunnel via UDP/TCP anders performt und dein Protokoll durch den Tunnel mal mehr mal weniger gut ist. SMB/CIFS bspw. ist da meist schlechter als bspw. SCP/SFTP/Rsync von der Performance. Und IPerf sollte man immer mit Geräten hinter den Endpunkten des VPNs messen, also von Client zu Server bspw. - die beiden Router/VPN-Endpunkte selbst raus lassen.
Dass ein Weg bei 20Mbps capped ist wie du schreibst ja richtig. Der Andere Weg sollte aber etwas mehr bringen, wobei da die Frage ist, ob da nicht zur Messung ggf. was parallel läuft?
-
Okay danke schonmals soweit....
Habe ehrlich gesagt keine Lust den Server für meine Kollegen "zu verbasteln" wenn ich die advanced options benutze...
Daher habe eben noch einen kleinen Testaufbau gemacht...
Ich habe zwar keine genauen Werte mehr, aber als ich damals eine OpenVPN Peer-to-Peer Verbindung für eines unserer Aussenbüros gemacht habe, habe ich extra ein paar Speedtests mitlaufen lassen. Diese Verbindung habe ich dann (aufgrund der grandiosen Ergebnisse) auch so ins Produktive übernommen.
(Leider sind die Tests nicht mehr möglich, da dass Büro mit einer 2/0.5 MBit Leitung gerade noch so fließend Wasser hat. Willkommen in der Zukunft ::) [size=78%])[/size]
Hier lauten die Einstellugen wie folgt:
Server:
TLS: enabled
DH: 4096
Encryption: AES-256-CBC
Auth: SHA512 (512-bit)
Hardware: No
Die andere Seite läuft Hardwaretechnisch mit einer ausgemusterten CheckPoint U20.
Performancetechnisch werkelt da drin nen Celeron M SingleCore mit 1.5 GHz. Monsterhaften 1 GB RAM und ne normale Comsumer HDD.
Da ich genau solch eine U20 noch hier habe, habe ich eben mal OPNsense (aber mit SSD) darauf installiert und ebenfalls eine Peer-to-Peer Verbindung mit den gleichen Parametern aufgebaut. Ebenfalls wieder an die Client Leitung.
Verbindung steht und nach Erstellen von ein paar Firewall und NAT Regeln sehen sich der Server und die Firewall ebenfalls.
Also genau das gleiche wieder mit iperf3 gemacht.
Der Server ist noch immer der gleiche. Ist eine Maschine die im "Servernetzwerk" steht.
Also auf der Firewall iperf3 installiert und mal getestet:
D: ~54,4 MBit/s
U: ~17,3 MBit/s
Dann gedacht: Okay und wie sieht es mit nem Client hintendran aus? (Intel i5-430M@2,27 GHz)
Also nen Windows Laptop geschnappt, den an die LAN Seite der Firewall gehängt, wieder geschaut das die Verbindung klappt und via iperf3 gemessen.
D: ~70 MBit/s
U: ~17,4 MBit/s
Dann noch den Text unten geschrieben und gedacht: Teste es doch mal mit speedtest.
Also speedtest.net via FireFox geöffnet und mit dem testen losgelegt.
D: ~74,7 MBit/s
U: ~17,87 MBit/s
Die VPN routet alles an unsere HauptFirewall weiter. Somit geht dann auch der Traffic von speedtest.net über unsere Hauptleitung.
Dann mal noch mit einem öffentlichen iperf3 Server getestet:
D: ~50 MBit/s
U: ~15,9 MBit/s
Dann auch mal via WindowsFreigabe eine 1 GB große Datei von links nach rechts kopiert und wieder zurück:
D: ~55 MBit/s
U: ~16 MBit/s
Somit habe ich über die Peer-to-Peer Verbindung "volle" oder zumindest zufriedenstellende Geschwindigkeit aber bei einem Remote Access nicht?
Parrallel läuft auf der Clientleitung gar nichts. Da hängt nun aktuell genau ein Gerät dran... Meins...
Das die Serverleitung nicht ausgelastet ist, sehe ich aufgrund von der Routerauslastung die mein Provider macht. Hier sehe ich dies im PRTG Monitor dass diese im Normalfall so mit ~10 MBit/s im Download und ~2 MBit/s im Upload ausgelastet ist.
Vielleicht kommen wir ja so der sache näher ob ich da irgendwas falsch habe...
Werde vielleicht auch nochmals einen weiteren RemoteAccess VPN Server konfigurieren und dann sehen wie es dort aussieht. Vielelicht hast du auch noch ne Idee?
Meine Messungen mit iperf3 führe ich immer über 5 Minuten aus und dann bekommt man ja den Mittelwert welchen ich dann hier schreibe.
Grüßle
-
> Also auf der Firewall iperf3 installiert und mal getestet:
IPerf immer testen von HINTER der Firewall da die Firewall selbst nicht für solchen Traffic optimiert ist.
> Somit habe ich über die Peer-to-Peer Verbindung "volle" oder zumindest zufriedenstellende Geschwindigkeit aber bei einem Remote Access nicht?
Evtl. ist doch der Client dein Problem?
Und ja die RA Variante war in unseren Tests auch etwas weniger performant als Peer2Peer.
> Meine Messungen mit iperf3 führe ich immer über 5 Minuten aus und dann bekommt man ja den Mittelwert welchen ich dann hier schreibe.
Da reichen eigentlich auch schon so 30-60s maximal. :)
-
Ich weiß dass man iperf3 hinter der FW installieren soll... Habe es trotzdem einfach mal gemacht :P
Evtl. ist doch der Client dein Problem?
Und ja die RA Variante war in unseren Tests auch etwas weniger performant als Peer2Peer.
Gibt es irgendwelche Clientempfehlungen?
Aktuell ist immer der aktuellste OpenVPN Client installiert....
Hardwaretechnisch sollte es ja wohl weniger ein Problem sein oder?
Selbst wenn die RA Variante etwas unperformanter ist... Halb so schlimm... Nur 20 MBit/s sind wohl einfach zu wenig....
Nachtrag:
Habe nun mal den Pritunl Client installiert.
Bei diesem bekomme ich zufriedenstellende Geschwindigkeiten hin...
D: ~80 MBit/s
U: ~18,2 MBit/s
Nachtrag1:
Habe mir mal ne Linux Maschine geschnappt und erneut getestet.
D: ~73 MBit/s
U: ~18.6 MBit/s
Somit denke ich mal, dass dies wirklich an der kompilierten Clientsoftware von OpenVPN liegt....
Gibt es einen guten alternativen Client der auch für nicht technische Endanwender gedacht ist und welcher zudem Benutzernamen und Passwort speichert? Letzteres macht der Pritun Client nicht....
Danke und Gruß
-
OK mit dem anderen Client gibts mehr? Ist die Frage: hast du am aktuellsten OVPN Client mal die Verbosity hochgesetzt und geschaut mit was der sich verbindet? Gegenüber dem Pritunl Client bspw.?
Verb 3 sollte da helfen. Eventuell verbinden sich die Clients unterschiedlich. OVPN 2.4 unterstützt ja NCP, vielleicht fällt der Client auf nen anderen Standard zurück. Oder der eine nutzt kein/kaum Crypto Beschleunigung?
Welches OS/Client ist es denn?
-
Du könntest dir die Implementierung von Softether anschauen, die spricht viele Protokolle: https://www.softether.org/
Oder testweise mal den VPN-Client von Securepoint probieren, der basiert aber zu Teilen auch auf OpenVPN: https://www.securepoint.de/produkte/utm-firewalls/vpn-client.html
-
Jops.. Also wenn ich direkt Linux (Debian 9) die VPN herstelle bekomme ich volle Leistung. Ebenso bei der Peer-to-Peer mit einer zweiten OPNsense.
Nur wenn ich windows nehme bin ich bei ~20 MBit/s.
Habe mal die Verbository auf 3 gestellt. (Nachdem ich endlich mal Verstanden habe was du mit Verb 3 meinst :o )
Die unterschiede habe ich aml am ende mit xxxxxx markiert. sind aber nur insgesamt 3 Stück. 2 bei OpenVPN und eine bei Pritunl.
Dass die IP unterschiedlich ist, habe ich einfach mal vernachlässigt. Ist ja irrelevant.
OpenVPN:
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 TLS: Initial packet from [AF_INET]<clientIP>:55963, sid=64020537 d55106c3
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 VERIFY SCRIPT OK: depth=1, <Zertifikatspfad>, CN=OPNsense-RootCA
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 VERIFY OK: depth=1, <Zertifikatspfad>, CN=OPNsense-RootCA
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 VERIFY SCRIPT OK: depth=0, <Zertifikatspfad>, CN=TestUser
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 VERIFY OK: depth=0, <Zertifikatspfad>, CN=TestUser
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_VER=2.4.7 xxxxxx
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_PLAT=win
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_PROTO=2
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_NCP=2
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_LZ4=1
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_LZ4v2=1
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_LZO=1
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_COMP_STUB=1
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_COMP_STUBv2=1
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_TCPNL=1
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 peer info: IV_GUI_VER=OpenVPN_GUI_11 xxxxxx Fehlt bei Pritunl komplett
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn: user 'TestUser' authenticated using 'LDAP-IT DC005'
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 TLS: Username/Password authentication succeeded for username 'TestUser' [CN SET]
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:55963 [TestUser] Peer Connection Initiated with [AF_INET]<clientIP>:55963
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 MULTI_sva: pool returned IPv4=10.100.130.6, IPv6=(Not enabled)
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 MULTI: Learn: 10.100.130.6 -> TestUser/<clientIP>:55963
Jul 2 10:25:50 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 MULTI: primary virtual IP for TestUser/<clientIP>:55963: 10.100.130.6
Jul 2 10:25:51 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 PUSH: Received control message: 'PUSH_REQUEST'
Jul 2 10:25:51 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 SENT CONTROL [TestUser]: 'PUSH_REPLY,<Routenconfigs etc>ifconfig 10.100.130.6 10.100.130.5,peer-id 0,cipher AES-256-GCM' (status=1)
Jul 2 10:25:51 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul 2 10:25:51 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:55963 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Pritunl:
Jul 2 10:27:51 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 TLS: Initial packet from [AF_INET]<clientIP>:51399, sid=b373918f d4eeeea8
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 VERIFY SCRIPT OK: depth=1, <Zertifikatspfad>, CN=OPNsense-RootCA
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 VERIFY OK: depth=1, <Zertifikatspfad>, CN=OPNsense-RootCA
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 VERIFY SCRIPT OK: depth=0, <Zertifikatspfad>, CN=TestUser
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 VERIFY OK: depth=0, <Zertifikatspfad>, CN=TestUser
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_VER=2.4.6 xxxxxx
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_PLAT=win
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_PROTO=2
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_NCP=2
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_LZ4=1
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_LZ4v2=1
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_LZO=1
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_COMP_STUB=1
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_COMP_STUBv2=1
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 peer info: IV_TCPNL=1
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn: user 'TestUser' authenticated using 'LDAP-IT DC005'
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 TLS: Username/Password authentication succeeded for username 'TestUser' [CN SET]
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: <clientIP>:51399 [TestUser] Peer Connection Initiated with [AF_INET]<clientIP>:51399
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 MULTI_sva: pool returned IPv4=10.100.130.10, IPv6=(Not enabled)
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 MULTI: Learn: 10.100.130.10 -> TestUser/<clientIP>:51399
Jul 2 10:27:52 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 MULTI: primary virtual IP for TestUser/<clientIP>:51399: 10.100.130.10
Jul 2 10:27:53 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 PUSH: Received control message: 'PUSH_REQUEST'
Jul 2 10:27:53 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 SENT CONTROL [TestUser]: 'PUSH_REPLY,<Routenconfigs etc>ifconfig 10.100.130.10 10.100.130.9,peer-id 1,cipher AES-256-GCM' (status=1)
Jul 2 10:27:53 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul 2 10:27:53 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<clientIP>:51399 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Du könntest dir die Implementierung von Softether anschauen, die spricht viele Protokolle: https://www.softether.org/
Oder testweise mal den VPN-Client von Securepoint probieren, der basiert aber zu Teilen auch auf OpenVPN: https://www.securepoint.de/produkte/utm-firewalls/vpn-client.html
Danke für die Vorschläge.
Also das Softether hatte ich testweise früher mal... Gefällt mir mal so gar nicht.... Viel zu überladen und unübersichtlich meiner Meinung nach....
Das Securepoint probiere ich gleich mal aus :)
Nachtrag:
SecurePoint sieht gar nicht mal so schlecht aus...
Habe hier jedoch einen anderen "Fehler".. Bekomme in unregelmäßigen Abständen "verbindungsabbrüche"...
Hier wäre die Log mit dem Securepoint... Vorallem dass um 11:14:58 der Server meint die Verbindung gibts nicht mehr?!? Ping geht durchgehen ohne Probleme durch?!?
Zudem bricht beim Iperf3 die Verbindung am ende ab und es komtm ein "Connection reset by peer"
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 TLS: Initial packet from [AF_INET]<ÖffentlicheClientIP>:58026, sid=c874de59 ebb786dc
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 VERIFY SCRIPT OK: depth=1, <Zertifikatspfad>, CN=OPNsense-RootCA
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 VERIFY OK: depth=1, <Zertifikatspfad>, CN=OPNsense-RootCA
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 VERIFY SCRIPT OK: depth=0, <Zertifikatspfad>, CN=TestUser
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 VERIFY OK: depth=0, <Zertifikatspfad>, CN=TestUser
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_VER=2.4.6
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_PLAT=win
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_PROTO=2
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_NCP=2
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_LZ4=1
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_LZ4v2=1
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_LZO=1
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_COMP_STUB=1
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_COMP_STUBv2=1
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 peer info: IV_TCPNL=1
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn: user 'TestUser' authenticated using 'LDAP-IT DC005'
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 TLS: Username/Password authentication succeeded for username 'TestUser' [CN SET]
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: <ÖffentlicheClientIP>:58026 [TestUser] Peer Connection Initiated with [AF_INET]<ÖffentlicheClientIP>:58026
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 MULTI_sva: pool returned IPv4=10.100.130.6, IPv6=(Not enabled)
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 MULTI: Learn: 10.100.130.6 -> TestUser/<ÖffentlicheClientIP>:58026
Jul 2 11:14:28 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 MULTI: primary virtual IP for TestUser/<ÖffentlicheClientIP>:58026: 10.100.130.6
Jul 2 11:14:29 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 PUSH: Received control message: 'PUSH_REQUEST'
Jul 2 11:14:29 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 SENT CONTROL [TestUser]: 'PUSH_REPLY,<Routenconfigs etc>,ifconfig 10.100.130.6 10.100.130.5,peer-id 0,cipher AES-256-GCM' (status=1)
Jul 2 11:14:29 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul 2 11:14:29 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:58026 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul 2 11:14:58 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 11:14:58 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'status 2'
Jul 2 11:14:58 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'quit'
Jul 2 11:14:58 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client disconnected
Jul 2 11:16:03 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 11:16:03 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'status 2'
Jul 2 11:16:03 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'quit'
Jul 2 11:16:03 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client disconnected
Jul 2 11:16:12 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:51989 [TestUser] Inactivity timeout (--ping-restart), restarting
Jul 2 11:16:12 SRVHTOPNSENSE002 openvpn[73738]: TestUser/<ÖffentlicheClientIP>:51989 SIGUSR1[soft,ping-restart] received, client-instance restarting
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: TCP/UDP: Preserving recently used remote address: [AF_INET]<ÖffentlicheClientIP>:30383
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: Preserving previous TUN/TAP instance: ovpns9
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: TCP/UDP: Preserving recently used remote address: [AF_INET]<ÖffentlicheClientIP>:30383
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: UDPv4 link local (bound): [AF_INET]<ÖffentlicheServerIP>:7223
Jul 2 11:16:33 SRVHTOPNSENSE002 openvpn[79711]: UDPv4 link remote: [AF_INET]<ÖffentlicheClientIP>:30383
Jul 2 11:17:08 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 11:17:08 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'status 2'
Jul 2 11:17:08 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'quit'
Jul 2 11:17:08 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client disconnected
Jul 2 11:17:33 SRVHTOPNSENSE002 openvpn[79711]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 2 11:17:33 SRVHTOPNSENSE002 openvpn[79711]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 2 11:18:13 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 11:18:13 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'status 2'
Jul 2 11:18:13 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: CMD 'quit'
Jul 2 11:18:13 SRVHTOPNSENSE002 openvpn[73738]: MANAGEMENT: Client disconnected
-
Ahoi,
könntest du im Server und/oder Client mal mit
tun-mtu
mssfix
spielen? Da gabs in der Vergangenheit schon häufig ziemliche Verbesserungen. Bspw. mssfix 1400 mal auf beiden Seiten testen ob sich dann was verändert oder tun-mtu mit 1500/1492 noch hinzufügen.
Gab mal einen Fall wo tun-mtu 1500; mssfix 1400 auf Server und 1492/1400 auf Clientseite das ziemlich verbessert hatte.
Auch sndbuf und rcvbuf mal auf 2000000 setzen um den Puffer zu vergrößern könnte was tun. Vielleicht ist da der ein oder andere Client für optimiert und macht das selbst ohne Anpassung der Konfiguration.
Gruß
-
Hi JeGr
also ich gehe davon aus das du willst, dass ich dies mit dem Standart OpenVPN Client teste.
Also im OpenVPN Server unter Advanced mal folgendes eingestellt:
tun-mtu 1500
mssfix 1400
sndbuf 2000000
rcvbuf 2000000
und im Client
tun-mtu 1500
mssfix 1400
sndbuf 2000000
rcvbuf 2000000
Dann mal den test mit iper3 gemacht und siehe da...
D: ~80 Mbit/s
U: ~18,2 Mbit/s
Jedoch bricht beim Downloadtest der iperf3 bei der letzten Übertragung ab mit der Meldung "Connection reset by peer" (egal ob 10 sec test oder 30 sec etc...)
Uploadtest funktioniert ohne Probleme.
Braucht lange bis die Download Übertragung beginnt.
Dann getestet mit Server
tun-mtu 1492
mssfix 1400
sndbuf 2000000
rcvbuf 2000000
Client:
tun-mtu 1492
mssfix 1400
sndbuf 2000000
rcvbuf 2000000
D: ~73 Mbit/s
U: ~18,2 Mbit/s
Hier bekomme ich die Fehlermeldung [/size][/font]WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)Bricht ebenfalls beim Letzten Downloadtest wie oben ab.
Braucht ebenfalls lange bis die Download Übertragung beginnt.
Puffer deaktiviert mit mtu 1500 und mssfix1400auf Server und Client: keine Veränderung
Puffer deaktiviert mit mtu 1492 und mssfix 14000 auf Server und Client: Downloadtest will gar nicht, rest unverändert
-
Was mir ebenfalls gerade eben aufgefallen ist:
Sobald ich den VPN Server aktiv schalte erhalte ich regelmäßig foglendes in der Log:
Jul 2 13:40:01 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 13:40:01 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: CMD 'status 2'
Jul 2 13:40:01 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: CMD 'quit'
Jul 2 13:40:01 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: Client disconnected
Jul 2 13:40:15 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 13:40:15 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: CMD 'status 3'
Jul 2 13:40:15 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: Client disconnected
Jul 2 13:41:05 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jul 2 13:41:06 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: CMD 'status 2'
Jul 2 13:41:06 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: CMD 'quit'
Jul 2 13:41:06 SRVHTOPNSENSE002 openvpn[41266]: MANAGEMENT: Client disconnected
Obwohl sich weder ein client an noch abmeldet?!?
Laut netgate ist dies normal... Kommt wohl von der erhöhren Verbosity...
Hier Nachzulesen (https://forum.netgate.com/topic/64120/client-connected-disconnected-from-var-etc-openvpn-server1-sock-every-62-sec/6)
-
Nö die MANAGEMENT Zeilen sind von der GUI die die Daten ausliest. Alles normal.
Ich meinte: Konfiguriere mal am Server die tun-mtu 1500 und auf dem Client 1492. Also unterschiedlich. Ansonsten beide mssfixe auf 1400. Bescheuert aber ich hatte noch jemand im Kopf bei dem es damit funktioniert hat, liegt aber wohl auch an der Gegenstelle wegen DSL oder nicht etc. etc.
Aber was ich dem entnehmen würde ist, dass mit Tuning im Standard Client anscheinend auch bis zu 80Mbps erreichbar sind wenn man die richtigen Optionen für sich findet?
-
Also habe nun beim Server nur den MTU auf 1500 gestellt und beim Client auf 1492.
Bekomme in der Log folgende Warnungen:
Tue Jul 02 16:05:56 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1550'
Tue Jul 02 16:05:56 2019 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1492', remote='tun-mtu 1500'
D: ~ 79 Mbit/s
U: ~ 18,3 Mbit/s
Uploadtest ging ohne Probleme.
Downloadtest startet erst wieder mit Verzögerung und am Ende kommt wieder das "Connection reset by peer"
MTU komplett gelöscht und nur "mssfix 1400" auf Server und Client hinzugefügt.
Geschwindigkeiten sind wieder in Ordnung.
D: ~79 MBit/s
U: ~ 18,3 MBit/s
Upload ging wieder ohne Probleme
Downloadtest hatte diemal ne Verzögerung von 79 Sekunden und am Ende wieder das "Connection reset by peer"
Mal spaßeshalber ne Datei via WindowsFreigabe von A nach B und zurück geschoben...
D: ~ 70 MBit/s
U: ~ 16 MBit/s
Genau. Man kann die gewünschte Geschwindigkeit mit den passenden Einstellungen wohl erreichen.. Nur gilt es nun herauszufinden wie diese am besten sind....
Da ich mich mit dem Thema MTU noch nie befasst habe...
Hast du noch weitere Ideen?
-
Puh schwierig. Es gibt glaube ich auf Serverseite mtu-test noch was man setzen kann dann macht er bei Verbindung(?) nen Test im Log aber da wirds dann ziemliches Raten auf Distanz ;)
-
Okay danke schonmals soweit für deine Hilfe ;)
Dann werde ich mal schauen wie schnell ich das mit der MTU Geschichte verstehe :o 8)