OpenVPN-Server trotz AES-NI schwacher Durchsatz

ShinigamiLY

Neuling
Thread Starter
Mitglied seit
13.11.2013
Beiträge
102
Hallo Leute,
vor paar Tagen kam mein QOTOM mit i5-7300u. Vorgesehen war es ihn mit Proxmox laufenzulassen jedoch merkte ich, dass pfSense über OpenVPN nur 90k durchließ trotz einer CPU-Auslastung von unter 6% :hmm:
Daraufhin habe ich pfSense direkt installiert (eigenständig ohne ProxMox) und ich habe genau daselbe Problem. Komischerweise erreicht mein Upload 200k aber Download ist bei 91k :hmm:

Lange Rede kurzer Sinn...

Verwendete Hardware:
dfgfdg.JPG
Mit AES-NI CPU Crypto: Yes (active)

pfSense Version: 2.4.4-RELEASE-p3 sowie 2.5.0-DEVELOPMENT

Umgebung:

--- [WAN]FritzBox[LAN] ---- [WAN Port 1] QOTOM [LAN Port 6] --- PC(Win10) [i7 6700k OC 4,8GHz]


- Die Ports laufen alle mit 1Gbit da ich über lang durch die QOTOM meine normale Leitung von 500k erreichen kann also daran liegt es schonmal nicht.
- OpenVPN sowohl über LAN als auch über WAN als Eingang getestet mit demselben Ergebnis.


Wenn ich "Hardware Crypto" auf "Intel RDRAND engine - RAND" setze, dann ist der Durchsatz noch geringer sprich 61k.

Ausgaben einiger Befehle:
Code:
[COLOR="#FF8C00"]Shell Output[/COLOR] - openvpn --show-engines

OpenSSL Crypto Engines

Intel RDRAND engine [rdrand]
Dynamic engine loading support [dynamic]

Code:
[COLOR="#FF8C00"]Shell Output[/COLOR] openssl engine -t -c

(rdrand) Intel RDRAND engine
 [RAND]
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]

Code:
[COLOR="#FF8C00"]Shell Output[/COLOR] dmesg | grep AESNI

 Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
 Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
 Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
 Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>


Code:
[COLOR="#FF8C00"]Shell Output[/COLOR] openssl speed -evp aes-256-gcm

Doing aes-256-gcm for 3s on 16 size blocks: 73271905 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 64 size blocks: 43419016 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 256 size blocks: 19236696 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 1024 size blocks: 7259618 aes-256-gcm's in 3.15s
Doing aes-256-gcm for 3s on 8192 size blocks: 1021731 aes-256-gcm's in 3.03s
OpenSSL 1.0.2o-freebsd  27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-gcm     389768.47k   923866.44k  1637267.67k  2361123.20k  2761243.83k

Code:
dev tun
persist-tun
persist-key
cipher AES-128-GCM
ncp-disable
auth SHA256
tls-client
client
resolv-retry infinite
remote 192.168.1.1 1197 udp
verify-x509-name "OpenVPN-Server" name
auth-user-pass
pkcs12 pfSense-UDP4-1197-vpn.p12
tls-auth pfSense-UDP4-1197-vpn-tls.key 1
remote-cert-tls server

Ich weiss nicht aber habe ich da irgendwas verpasst einzustellen oder sonstiges?
Hat da jemand eine Idee?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mal testen, ob UDP oder TCP eine bessere Performance bringen (eigentlich läuft UDP besser). Oder mal Wireguard testen. Die schlechte Performance von openVPN ist mir leider auch nicht unbekannt.
 
Nun.. UDP wird ja wie in der Config zu sehen ist bereits verwendet. Ich probiere schon den ganzen Tag verschiedene Einstellungskombinationen etc. nur leider ohne Erfolg.
Wireguard kenne ich nur ist mir dies noch zu unsicher da es weder auditiert wurde noch wirklich veröffentlicht wurde.
 
Dann weiß ich leider auch keine Lösung. Ich habe mit den Optionen wie MTU, MRU usw. herumprobiert, aber auch keine zufriedenstellende Kombination gefunden. Auch wurden bei mir settings diesbezüglich ignoriert. Warum das so ist, habe ich nicht verstanden. Fakt ist jedenfalls, dass openVPN auch bei mir vom Handy zum Server unter Performance-Problemen leidet.
 
Also es gibt jetzt verschiedene Problemursachen.

Entweder wirklich die Config des Servers / Client
Teste bitte mal aes-128-cbc als verschlüsselung mit sha1 auth mit deaktiverter kompression
aber normal sollte bei i3 und höher genügend leistung da sein.

Was ist die gegenstelle ? Wer ist dein Internet anbieter ? eventuell wird hier gedrosselt ?
Bitte mache einmal einen FTP Upload/Download auf einen Server mit einer Verbindung. Openvpn kann/hat auch nur eine Verbindung.

Willst du einfach nur auf deine lokale Installtion zugreifen oder willst du dort wieder Pakete nach draussen routen ?
 
Hi und danke für die Antworten.

Ich werde demnächst mal den aes-128-cbc testen. Komprimierung ist standardmässig deaktiviert.

Wie bereits erwähnt teste ich es derzeit aus dem lan sprich mein pc ist direkt an dem openvpn angeschlossen. Somit sollte meiner Meinung nach alle Zwischenstellen die ein Flaschenhals sein könnten entfernt werden.
Wenn ich somit über die normale Leitung also ohne VPN bei Speedtest z.B. die 500k Leitung packen, dann müsste es über den VPN genauso sein.

Die Pakete werden somit ja direkt an die OpenVPN aus dem LAN gehen und darüber direkt raus.
Mehrheitlich auf die lokalten Daten zugreifen. Nichtsdestotrotz benötige ich auch für meine Geräte wie Handy die Möglichkeit die Pakete nach draussen zu routen. Derzeit ist dies auch so eingerichtet.

Mein Asusrouter ist seit nem Jahr dafür zuständig nur reicht mir langsam die Leistung nicht mehr. Beim Asus Router kommen nur 40k durch und der Prozessor ist am Anschlag. Das er nicht mehr packt ist mir schon klar weshalb ich eben ein miniPC dafür gekauft habe nur geht da nicht mehr als 100k obschon die Leistung locker reicht und wie gesagt... CPU Auslastung von unter 8%. (SingleCore)

Hier noch ein Bild da es irgendwie nicht klar ist wie es aufgebaut ist. Ausserdem dient dies erst einmal nur zur Testzwecke damit ich sicher gehen kann, dass die Leistung ausreichen sollte und alle anderen Fehlerquellen ausgeschlossen werden können.
 

Anhänge

  • vpnm.JPG
    vpnm.JPG
    16 KB · Aufrufe: 78
Zuletzt bearbeitet:
Hast du dir mal den ASUS AC86U angeschaut ? der kann AES in Hardware.

500k beim TCP Speedtest heisst nicht das 500k beim einer einzelnen UDP Verbindung.

Kannst du mal direkt zum Server im Lan mit Cyberduck und SSH eine große Datei hin und her spielen, damit wir wissen, dass die Leistung erreicht wird ?

Es gibt auch noch mehr faktoren wie z.b. Puffergrößen des Lanadapters.


Kennst du das ? Gigabit_Networks_Linux – OpenVPN Community
 
Ich verwende seit Jahren den RT-AC87U mit Merlin und manchmal auch mit ddwrt. Sie verrichtet derzeit bzw. seit langem den OpenVPN Server. Leider erreicht sie ihre Grenzen @ 100% Auslastung eines Cores bei 40k
Dennoch habe ich so viele Router im Haus, das ich mir keine neuen kaufen möchte. Deswegen habe ich auch diese QOTOM gekauft mit dem i5 7300u.
Vorallem sollte für all mein Vorhaben diese CPU locker reichen. Ich bin selbst jetzt noch überrascht wie Leistungsstark die ist für eine 15W CPU. Und erstaunt... das ich eigentlich bei aliexpress mir die mit einem i5 7200u bestellt hatte und stattdessen die 7300 bekommen hab :lol:

Das mitm SSH stimmt... Wieso bin ich nicht auf die Idee gekommen... Ja, das sollte ich aufbauen können und testen. Werde ich mal die Tage versuchen.
Danke für den Link, kannte ich nicht.
 
Frage: ich nutze openVPN-Server unter Debian stable. Clients sind Android. In Server und Client wurde AES-128-CGM eingestellt, genutzt wird AES-256-GCM. Ich habe keinen blassen Schimmer, wieso mein Setting ignoriert wird, jemand eine Idee dazu?
 
Frage: ich nutze openVPN-Server unter Debian stable. Clients sind Android. In Server und Client wurde AES-128-CGM eingestellt, genutzt wird AES-256-GCM. Ich habe keinen blassen Schimmer, wieso mein Setting ignoriert wird, jemand eine Idee dazu?

Bitte config posten ... server + client
 
Gerne doch! Jetzt bin ich zu Hause, da geht das. Ich bin für jeden Hinweis auf Fehler dankbar!
Code:
 server-udp.conf:
port 1194
proto udp
dev tun0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/myserver.crt
key /etc/openvpn/easy-rsa/keys/myserver.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.1.0.0 255.255.255.0
push "route 192.168.4.0 255.255.255.0"
client-config-dir ccd
client-to-client
keepalive 40 90
tls-auth ta.key 0 # This file is secret
cipher AES-128-CBC   # AES
max-clients 10
persist-key
persist-tun
status openvpn-status.log
verb 3
topology subnet
push "topology subnet"
tls-server
remote-cert-tls client
script-security 2
auth-user-pass-verify /etc/openvpn/auth-new.pl via-file
link-mtu 1464
fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
Ohne die letzten vier Zeilen war eine Verbindung unerträglich langsam.

Config für einen Client:
Code:
client-udp.conf
dev tun
proto udp
remote netz.domain.org
client
ifconfig 10.1.0.59 10.1.0.1
cipher AES-128-CBC   # AES
auth-user-pass
persist-tun
persist-key
verb 3
remote-cert-tls server
ns-cert-type server
tls-client
fast-io
tun-mtu 1407
 
Ah, ok. Kannst Du mir auch erklären, warum mir das fehlt? Also natürlich nicht, warum ich das nicht eingetragen habe, sondern warum man das benötigt und was es macht... ;)
 
Naja eigentlich ist die Option überflüssig. Weil es geht darum das dein Client auch andere Verschlüsselungen aushandeln darf als die vorgegebene.

Wenn es dann immer noch nicht geht würde ich mir das TLS mal vornehmen. Dort kann soweit ich mich recht erinner auch die Verschlüsselung "eingetragen" werden.
 
Danke, laut Log funktioniert es! Ich erhoffe mir dadurch eine etwas höhere Netto-Datenübertragungsrate.
 
Sehr schön,
Was schafft dein setup ?
Was du noch machen kannst ist "auth sha1" verwenden.

Ich würde diese Werte nochmal auf den Prüfstand stellen :
fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

und den MTU
Woran hängt dein Server Kabel oder DSL ?
 
Was schafft dein setup ?
Ich habe keine aktuellen vergleichbaren Werte. Aber ein Familienmitglied war bis vor kurzem in Australien und Mexiko, es wurde nie mehr als 90kb/s erreicht. Deutsche Verbindungen waren zwar immer schneller, aber auch weit unter dem, was ich eigentlich für möglich gehalten habe.
Ich hatte 50/10 DSL. Jetzt bin ich bei 98/34 (beide Male ungefähr der reale Wert, Telekom), dazu gibt es noch gar keine aktuellen Ergebnisse. Ich hätte sehr gerne mehr uplink (mindestens die realen 40MBit), würde dafür sogar auf downlink-Geschwindigkeit verzichten, aber das kann ich wohl nicht beeinflussen.

Was du noch machen kannst ist "auth sha1" verwenden.
Auch nur in der Server-Config? Wobei: das nimmt er offensichtlich von selbst schon:
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Ich würde diese Werte nochmal auf den Prüfstand stellen :
Die Werte hatte ich durchgetestet. Ohne die oder mit anderen Werten (gibt da ja so Richtwerte, welche man im Netz findet) war es nur noch schlechter.

Die sind sowieso merkwürdig. Obwohl ich feste Werte vergebe, werden andere Werte verwendet:
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'

Woran hängt dein Server Kabel oder DSL ?
DSL, Erläuterung siehe oben.

Angeblich soll wireguard einen besseren Durchsatz bringen. Ich habe nur noch kein Tutorial gefunden, wie man das in Debian als server einrichtet. Und ich kenne auch leider niemanden, der damit experimentiert.
 
Zuletzt bearbeitet:
Mexiko und Australien, da hast du dir ja die besten Länder rausgesucht was peering betrifft.

Ich war selber schon in Mexiko und habe so über TCP von Deutschen Internetanbietern ca 2-6 Mbit konstant erreicht. Über UDP war alles ziemlich instabil.

Beim Setup muss man sich meiner meinung nach entscheiden ob man maximalen durchsatz oder auf hohen ping abstimmt. Im zweifelsfall 2 VPN Server laufen lassen.
Ich habe 2 instanzen laufen einmal mit TCP und einmal mit UDP.

Ein weiterer großer Faktor ist der MTU bei weiten oder schlechten Verbindungen ( UMTS LTE ) sollte man den MTU verringern.
Eigentlich solltest du Serverseitig die Maximale MTU Größe einstellen. Und beim Bedarf am Client auf einen funktionierenden Wert reduzieren.

Da gibt es ein sehr gutes Tuturial im Netz. Einfach mal danach Googlen.

Wireguard wird bessere Ergebnisse liefern aber du solltest deine 40 Mbit auch mit OpenVpn erreichen.

Welche Hardware hast du als Server ?

Mach mal eine Messung der Geschwindigkeit, dann können wir uns ans Optimieren machen.
 
Mexiko und Australien, da hast du dir ja die besten Länder rausgesucht was peering betrifft.
Du meinst damit die Verbindungen zum Rest der Welt?

Ich habe 2 instanzen laufen einmal mit TCP und einmal mit UDP.
Ja, ich auch. Der Datendurchsatz zu Mobile-devices (sprich Smartphones), auf die kommt es mir gerade an, ist selbst in Deutschland spürbar schlechter als via UDP.

Ein weiterer großer Faktor ist der MTU bei weiten oder schlechten Verbindungen ( UMTS LTE ) sollte man den MTU verringern.
Eigentlich solltest du Serverseitig die Maximale MTU Größe einstellen. Und beim Bedarf am Client auf einen funktionierenden Wert reduzieren.
Das habe ich mir gedacht, allein, es funktioniert nicht.

Da gibt es ein sehr gutes Tuturial im Netz. Einfach mal danach Googlen.
Ich habe dazu ziemlich intensiv gegoogelt, als das Problem akut war, aber nichts adäquates gefunden. Du könntest nettweise auch mal verlinken, welches tutorial Du genau meinst.

Welche Hardware hast du als Server ?
Irgendein Fujitsu-Siemens Rechner mit Doppelkern-Intel-Prozessor. Der idlet hier nur vor sich hin, auch mit aktiver VPN-Verbindung.

Mach mal eine Messung der Geschwindigkeit, dann können wir uns ans Optimieren machen.
Ich komme hoffentlich nach dem kommenden Wochenende wieder dazu, entsprechende Versuche zu machen. Diese Woche ist noch bis Sonntag pickepackevoll.
 
Ja Mexiko und Australien sind relativ schlecht zu erreichen für unsere Breitengrade.

Als kleine Spielerei am Rande. Geh mal auf Speedtest.net dort kannst du den Server selbst auswählen. Dann nimm mal Mexico & Australien dann wirst du sehen das du schwer über die 10 Mbit kommst. Zumindest mit Telekom / O2 etc.
Dem kannst du nur entgegenwirken, wenn du einen Server zwischenschaltest der ein Besseres Peering hat.

Schau dir das hier mal an : Optimizing OpenVPN Throughput | Hamy - The IT Guy
 
Mal wireguard angecshaut?

Mit nicht auditierter Codebase, sogar die Gründer selbst warnen davor, WireGuard produktiv einzusetzen:
WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.
WireGuard: fast, modern, secure VPN tunnel

Da wartet man lieber auf saubere Security-Audits und einer finalen Codebase anstatt seine Daten halbgarem, evtl. unsicherem Code anzuvertrauen.
Übrigens, versuch mal mit WG Keys auf Mobile-Geräten zu importieren...dazu brauchst du QR-Codes, bei OpenVPN importierst du einfach das .ovpn-Profile über USB.
 
Bringt aber auch nur was, wenn die .ovpn-Profil-Datei auf sicherem Weg auf das Mobile Gerät kommt, was z.B. bei iOS Geräten nicht möglich ist, alle Wege die Datei auf das Smartphone zu bekommen sind unsicher bzw. können mitgelesen werden. (Mail, iCloud, iTunes sync). Man könnte sich theoretisch mit einem alternativen Dateimanager der Netzlaufwerke unterstützt behelfen und so die Datei auf das Smartphone kopieren, diese Apps haben dann aber mit Sicherheit keine Security-Audits und sind somit wieder uninteressant. Lediglich mit Android Geräten kann man die Datei einfach per USB Verbindung draufkopieren und importieren.
Kann sein, dass die OpenVPN App für iOS da mittlerweile eine Möglichkeit bietet dies auf sicherem Weg zu machen, bis vor einem Jahr war das aber nicht bzw. nur mit extrem hohem Aufwand möglich.
 
Natuerlich ist das moeglich.
zB ueber Owncloud oder dessen Pendants
 
Bringt aber auch nur was, wenn die .ovpn-Profil-Datei auf sicherem Weg auf das Mobile Gerät kommt, was z.B. bei iOS Geräten nicht möglich ist, alle Wege die Datei auf das Smartphone zu bekommen sind unsicher bzw. können mitgelesen werden. (Mail, iCloud, iTunes sync). Man könnte sich theoretisch mit einem alternativen Dateimanager der Netzlaufwerke unterstützt behelfen und so die Datei auf das Smartphone kopieren, diese Apps haben dann aber mit Sicherheit keine Security-Audits und sind somit wieder uninteressant. Lediglich mit Android Geräten kann man die Datei einfach per USB Verbindung draufkopieren und importieren.
Kann sein, dass die OpenVPN App für iOS da mittlerweile eine Möglichkeit bietet dies auf sicherem Weg zu machen, bis vor einem Jahr war das aber nicht bzw. nur mit extrem hohem Aufwand möglich.

Ich hab dazu weder Mail, noch iCloud (was ich sowieso nicht nutze bzw. so weit es geht deaktiviert habe), noch iTunes gebraucht. USB an PC, .ovpn-Profil draufkopiert, per OpenVPN App gesucht und eingebunden.
 
Sind alle Probleme jetzt gelöst ?
Nein, danke für die Erinnerung!

Es hat sich einiges an den Vorgaben geändert. Die Verbindungsgeschwindigkeit hat sich durch eine Vertragsänderung (von 50/10 auf 100/40) erhöht, und die Gegenstelle ist nicht mehr im Ausland.
Mein Draytek Vigor 130 meldet folgende Verbindung: Down Stream : 98338Kbps / Up Stream : 34367Kbps
Ich habe für einen Test eine ca. 127MB große mp4-Datei genommen und kopiere die hin- und her.

Wenn ich die Datei von meinem Server auf das Handy kopiere (4G+-Verbindung):
Mein gkrellm auf dem Router sagt 1,1 - 1,3M; das openVPN auf dem Handy meint ca. 9MBit/s für die Datei.
Die Auslastung des DualCore-Prozessor meines Server liegt dabei auf unter 10% in der Spitze (beide Kerne), er macht sonst nix.

Wenn ich die Datei vom Handy zurück auf den Server kopiere:
Mein gkrellm auf dem Router sagt ca. 2,3M; das openVPN geht auf ca. 16-18MBit/s hoch, die Übertragung ist dementsprechend fast doppelt so schnell.
Die Auslastung des DualCore-Prozessor meines Server liegt hierbei unter 14% (beide Kerne), er macht sonst nix.

Hier noch ein paar Meldungen aus der syslog des Server:
Code:
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'

Vollständig:
Code:
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1343)
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 TLS: Initial packet from [AF_INET]80.187.101.2:26469
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 Validating certificate key usage
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 ++ Certificate has key usage  0080, expects 0080
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 Validating certificate extended key usage
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_VER=2.5_master
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_PLAT=android
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_PROTO=2
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_NCP=2
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_LZ4=1
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_LZ4v2=1
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_LZO=1
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_COMP_STUB=1
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_COMP_STUBv2=1
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_TCPNL=1
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.8
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Aug  5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 [note] Peer Connection Initiated with [AF_INET]80.187.101.2:26469
Aug  5 12:10:08 server ovpn-server-udp[19538]: note/80.187.101.2:26469 OPTIONS IMPORT: reading client specific options from: ccd/note
Aug  5 12:10:08 server ovpn-server-udp[19538]: note/80.187.101.2:26469 MULTI: Learn: 10.1.0.38 -> note/80.187.101.2:26469
Aug  5 12:10:08 server ovpn-server-udp[19538]: note/80.187.101.2:26469 MULTI: primary virtual IP for note/80.187.101.2:26469: 10.1.0.38
Aug  5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 PUSH: Received control message: 'PUSH_REQUEST'
Aug  5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 SENT CONTROL [gnote]: 'PUSH_REPLY,route 192.168.4.0 255.255.255.0,topology subnet,sndbuf 393216,rcvbuf 393216,route
-gateway 10.1.0.1,topology subnet,ping 40,ping-restart 90,ifconfig 10.1.0.38 255.255.255.0,peer-id 0,cipher AES-128-CBC' (status=1)
Aug  5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug  5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug  5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh