OPNsense Forum
International Forums => German - Deutsch => Topic started by: Marcel_75 on March 06, 2019, 08:42:08 am
-
Hallo,
grundsätzlich funktioniert die Verbindung zum OpenVPN-Server gut und zuverlässig, soweit alles prima.
Nur die Geschwindigkeit macht mich wirklich stutzig – bei einem Kabel-Anschluss mit 400 MBit/s Down und 12 MBit/s Up (netto sind es eher 250 bis 380 MBit/s Down und 6 bis 9 MBit/s Up, je nach Zeit) komme ich nur auf folgende Werte, sobald die VPN-Verbindung steht (getestet per LTE-Hotspot mit knapp 150 MBit/s):
Download: 2,9 MBit/s
Upload: 4,1 MBit/s
Habe schon einiges gelesen (und auch versucht) – bisher leider keine Besserung … :-[
Encryption algorithm: umgestellt von AES-256-CBC (256 bit key, 128 bit block) auf AES-128-CBC (128 bit key, 128 bit block)
Auth Digest Algorithm: umgestellt von SHA512 (512-bit) auf SHA1 (160-bit)
DH Parameters Length: 2048 Bit (das sollte ja i.O. sein)
Im 'Advanced Bereich" habe ich zusätzlich zum Test noch folgendes eingetragen:
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
tun-mtu 1400
Aber auch das ändert erst einmal nichts bei meinem Setup vom Speed her.
OPNsense-Version: OPNsense 19.1.2-amd64, FreeBSD 11.2-RELEASE-p9-HBSD, LibreSSL 2.8.3
CPU: AMD GX-416RA SOC (4 cores)
Was mache ich falsch? Ist einfach nur der SOC zu lahm? Brauche ich für ordentlich Speed einen Xeon? ;)
PS: Mir ist klar, dass bei meinem Anschluss maximal 6 bis 9 MBit/s drin wären, aber davon schaffe ich ja aktuell gerade mal die Hälfte … irgendwo ist da doch der Wurm drin, oder?
Wie immer: Vielen Dank für Hilfe und input.
-
Wir haben hier eine OPNsense mit Xeon 1230, 16gig RAM und 100mbit symmetrischer Leitung.
openVPN ist von extern aber auch nicht so berauschend schnell, wir warten immer noch auf wireguard um das VPN für die MA anzubieten.
-
Ich stand mal vor einem Ähnlichen Problem. Ich konnte mir bei site2site Verbindungen behelfen indem ich auf IPSec umgestellt habe.
Ich weiß nicht, ob OpenVPN generell eher CPU intensiver ist, oder vom Protokoll her langsamer, aber bei IPSec fand ich den Unterschied schon deutlich.
-
Zum Vergleich:
Site-to-site-VPN mit OpenVPN-Konfiguration gemäss Handbuch (AES-256-CBC und SHA512) ohne irgendwelche Tweaks zwischen zwei Stück
PC Engines APU2 mit:
- Coreboot BIOS v4.9.0.2
- AMD GX-412TC SOC (4 cores) mit AES-NI
- OPNsense 19.1.2-amd64, FreeBSD 11.2-RELEASE-p9-HBSD, LibreSSL 2.8.3
Übertragungsrate: 36 Mbit/s (4.5 MB/s)
Unterstützt deine CPU AES-NI?
Falls jemand Tweaks für diese Konstellation kennt, dann gerne her damit.
-
Ich habe im Erweitert folgende Werte.
link-mtu 1492;
sndbuf 1048576;
rcvbuf 1048576;
Sowohl auf Server und Client Seite.
-
Moin, so wie ich es verstanden habe setzt du eine APU ein.
Die sind nicht so flott. Hast du wenn es eine APU ist soll sie ja auch AES-NI können hast du es aktiviert in deiner OpenVPN Konfig? Ich setze Intel Systeme ein ein ATOM, Core i3 und Core i7 und die sind alle sehr schnell. ich habe 5 VPŃs laufen und die CPU ist nur zu 20% ausgelastet. Kannst du mal ein bild deiner konfig posten (alle geheimen punkte kannst du ja schwärzen.
Gesendet von iPad mit Tapatalk Pro
-
Da stimme ich mic zu, das kommt mir selbst für die lahme APU doch zu wenig vor. Allerdings müsste der GX-412 der in der APU2 verbaut ist, AES-NI können, das sollte der 416 somit auch schaffen. Der Test via LTE mag aber auch ein wenig hakeln, da weiß man ja auch nicht unbedingt wieviel man vom theoretischen abbekommt. Vielleicht mal direkt von einer anderen größeren Leitung testen?
-
Vielen Dank schon mal für Eure Beiträge soweit.
Bei "Hardware Crypto" steht bei mir leider nur "No Hardware Crypto Acceleration" …
Hatte aber an anderer Stelle gelesen, dass das wohl trotzdem (automatisch?) aktiv sein sollte normalerweise?
Kann ich wahrscheinlich per SSH auf der OPNsense prüfen?
WireGuard https://www.wireguard.com/ (https://www.wireguard.com/) klingt wirklich sehr gut, nur ist das ja leider nach wie vor nicht finalisiert. Ist es denn geplant, das zukünftig auch in OPNsense zu implementieren?
PS: Werde es demnächst mal an einer echten 500er Glasfaser testen, das macht natürlich mehr Sinn als LTE.
-
@lewald: Danke, scheint bei mir keinen Unterschied auszumachen.
@micneu: Auf was für Übertragungsraten kommt Du mit einer Atom-CPU?
@Marcel_75: AES-NI aktiviert man unter System: Settings: Miscellaneous: Hardware acceleration
-
@Reiter der OPNsense: Ok, da ist unter Hardware acceleration "AES-NI CPU-based Acceleration ()aesni" aktiviert bei mir.
Dass ich es dann beim OpenVPN-Server trotzdem nicht explizit anwählen kann und dort nur "Hardware Crypto" … "No Hardware Crypto Acceleration" angezeigt wird, scheint also normal zu sein?
-
Ja, "No Hardware Crypto Acceleration" ist verwirrend aber normal.
Was geben folgende Befehle in einer Shell aus?
dmesg | grep -i aes
kldstat | grep -i aes
kldload aesni
-
dmesg | grep -i aes
Features2=0x3ed8220b<SSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard
kldstat | grep -i aes
45 1 0x0 7298 aesni.ko
kldload aesni
kldload: can't load aesni: module already loaded or in kernel
Klingt eigentlich auch erst einmal gut soweit, oder?
-
Ja, das sieht soweit gut aus.
Ich habe jetzt mal noch die Site-to-site-Verbindung gekappt und die Übertragungsrate mit einer Road-warrior-Verbindung gemessen. Macht keinen Unterschied, die Geschwindigkeit ist damit sogar noch eine Spur höher.
Hier endet mein Latein und ich kann nur noch spekulieren:
- Vielleicht liegt es an einer schlechten Internetverbindung/hohe Latenzen obwohl ich ~3-4 MBit/s gefühlsmässig für extrem mager halte, auch im Fall einer schlechten Verbindungsqualität.
- Vielleicht ist deine Box mit etwas anderem ausgelastet?
-
1. hast du ganz sicher keinen Proxy oder irgend welchen Dienste noch am laufen?
2. hast du mal die Kiste neugestartet?
Gesendet von iPhone mit Tapatalk Pro
-
Proxy oder so ist nicht aktiv, Neustart ändert auch nichts.
Es sind ganz normale Dienste aktiv:
configd System Configuration Daemon
dhcpd DHCPv4 Server
dyndns Dynamic DNS
login Users and Groups
ntpd Network Time Daemon
openssh Secure Shell Daemon
openvpn OpenVPN server: OpenVPN-UDP-1194
pf Packet Filter
syslog Syslog
unbound Unbound DNS
Die Last der CPU ist sehr gering ohne VPN-Verbindung. Wie es diesbezüglich mit aktiver OpenVPN-Verbindung aussieht, schaue ich noch einmal, sobald ich das per Glasfaser von außen teste (wird erst kommende Woche werden).
Bin schon am überlegen, den OpenVPN-Server, die VPN-User, die entsprechenden certs der CA und auch die Firewall-Regeln noch einmal komplett platt zu machen. Ob das was bringt?
Oder sogar ein weiteres mal OPNsense komplett frisch installieren? Also sogar ohne Config-Import?
Und dann würde ich mir vielleicht auch noch einmal dieses sehr ausführliche Tutorial zu Rate ziehen:
https://arstechnica.com/gadgets/2017/05/how-to-build-your-own-vpn-if-youre-rightfully-wary-of-commercial-options/ (https://arstechnica.com/gadgets/2017/05/how-to-build-your-own-vpn-if-youre-rightfully-wary-of-commercial-options/)
Viel schöner wäre es natürlich, wenn man die Ursache für diese doch sehr langsamen OpenVPN-Verbindungen finden könnte. Aber ehrlich gesagt bin ich hier mit meinem Latein am Ende – und auch von Eurer Seite her scheint ja prinzipiell alles i.O. zu sein mit meiner Config …
Dass ich den LibreSSL- statt OpenSSL-Build nutze sollte ja kein Problem sein eigentlich, oder?
Das einzige, was mir noch eingefallen war als mögliche Erklärung: Wenn mein Anschluss auf dem Papier sowieso nur schlappe 12 MBit/s im Upload bietet und das in der Praxis sich eher im Bereich von 6-9 MBit/s abspielt – sind die mageren Durchsatz-Werte dann vielleicht doch gar nicht sooooo ungewöhnlich?
-
Was ist den die "Standardmethode" den Durchsatz des Tunnels zu messen? Also wie bringst du Last auf die Leitung?
-
Ich teste so etwas eigentlich immer mittels iperf (iperf 3.6), da viele Online-Tests ja doch eher ungenau sind …
speedof.me und der Zack-Speedtest von AVM liefern meiner Erfahrung nach noch die verlässlichsten Ergebnisse.
Sollte ich es nicht per iperf testen? Gibt es etwas Besseres?
-
Ok, der Thread kann wahrscheinlich als 'gelöst' markiert werden:
Bin gerade an einem Glasfaseranschluss (per Ethernet), die Werte sind jetzt denke ich so wie sie sein sollten:
Mac:~ user1$ iperf3 -c 192.168.1.199 -w 2m
Connecting to host 192.168.1.199, port 5201
[ 5] local 10.23.8.2 port 56942 connected to 192.168.1.199 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 2.64 MBytes 22.2 Mbits/sec
[ 5] 1.00-2.00 sec 1.16 MBytes 9.69 Mbits/sec
[ 5] 2.00-3.00 sec 1.01 MBytes 8.47 Mbits/sec
[ 5] 3.00-4.00 sec 1015 KBytes 8.30 Mbits/sec
[ 5] 4.00-5.00 sec 1.01 MBytes 8.46 Mbits/sec
[ 5] 5.00-6.00 sec 1.01 MBytes 8.50 Mbits/sec
[ 5] 6.00-7.00 sec 1.03 MBytes 8.61 Mbits/sec
[ 5] 7.00-8.00 sec 1.02 MBytes 8.58 Mbits/sec
[ 5] 8.00-9.00 sec 1.01 MBytes 8.49 Mbits/sec
[ 5] 9.00-10.00 sec 1.02 MBytes 8.57 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 11.9 MBytes 9.99 Mbits/sec sender
[ 5] 0.00-10.21 sec 9.92 MBytes 8.15 Mbits/sec receiver
Das sieht nun so aus, wie ich es erwartet hätte. :)
Also kann man festhalten: Per LTE-Hotspot gern testen, ob die Verbindung überhaupt zustande kommt – Geschwindigkeitstests sollte man über LTE aber eher nicht machen … ;)
Ich muss dazu sagen, dass ich die Buffer-Werte und auch den MTU-Wert noch etwas angepasst habe (interne Tests brachten mich zu dem Schluss, dass diese Werte zumindest bei meinem Anschluss die besten Praxiswerte liefern).
sndbuf 44000
rcvbuf 44000
push "sndbuf 44000"
push "rcvbuf 44000"
link-mtu 1360
Komprimierung habe ich deaktiviert, cipher ist AES-128-CBC, auth SHA1. Und statt des UDP-Standardports 1194 benutze ich aktuell UDP Port 43210. Wobei der Port wahrscheinlich keinen Unterschied macht (wollte da nur prüfen, ob mein ISP eventuell Traffic-Shaping oder so etwas auf dem Standard-OpenVPN-Port macht).
Aus sicherheitstechnischer Sicht sollte das ja wahrscheinlich auch wumpe sein, ob ich nun wieder zurück auf Standard-UDP-Port 1194 gehe oder es bei UDP-Port 43210 belasse, oder?
In jedem Fall wie immer vielen Dank Euch allen für die tolle Unterstützung.
-
sndbuf 44000
rcvbuf 44000
push "sndbuf 44000"
push "rcvbuf 44000"
link-mtu 1360Bremst meine Verbindung aus. Wie ermittelt man hier die besten Werte?
Komprimierung habe ich deaktiviert, cipher ist AES-128-CBC, auth SHA1.
Bringt das bei dir einen Geschwindigkeitsvorteil? Bei mir nicht. Darum lasse ich hier lieber die stärkere Cipher drin.
Und statt des UDP-Standardports 1194 benutze ich aktuell UDP Port 43210. Wobei der Port wahrscheinlich keinen Unterschied macht (wollte da nur prüfen, ob mein ISP eventuell Traffic-Shaping oder so etwas auf dem Standard-OpenVPN-Port macht).
Auf die Übertragungsrate hat das keinen Einfluss. Aber allenfalls bist du froh, wenn die bösen Jungs deinen VPN-Server nicht gleich bei jedem Routineportscann finden.
-
@Reiter hier ich habe mal von 2 Systemen die mögliche Bandbreite getestet
Client: macOS 10.14.3, Server: Ubuntu Server 18.04
OHNE VPN
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 7] 0.00-10.00 sec 1.16 GBytes 1000 Mbits/sec 0.000 ms 0/863260 (0%) sender MacBook Pro 2018 ETH
[ 7] 0.00-10.00 sec 905 MBytes 759 Mbits/sec 0.084 ms 204636/859694 (24%) receiver Lanner NCA-1010B
mit OpenVPN AES256, iperf3 -c 10.0.0.1 -u -b 1G
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 1.16 GBytes 1000 Mbits/sec 0.000 ms 0/928670 (0%) sender MacBook Pro 2018 ETH
[ 5] 0.00-10.00 sec 200 MBytes 168 Mbits/sec 0.050 ms 772531/928670 (83%) receiver Lanner NCA-1010B
Client: macOS 10.14.3, Server: Debian 9
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 1.16 GBytes 1000 Mbits/sec 0.000 ms 0/863223 (0%) sender MacBook Pro 2018 ETH
[ 5] 0.00-10.00 sec 1.11 GBytes 956 Mbits/sec 0.007 ms 35627/861265 (4.1%) receiver Eglobal Intel Core i3-7100U
mit OpenVPN AES256, iperf3 -c 10.0.0.1 -u -b 1G
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 1.16 GBytes 996 Mbits/sec 0.000 ms 0/925423 (0%) sender MacBook Pro 2018 ETH
[ 5] 0.00-10.00 sec 346 MBytes 290 Mbits/sec 0.021 ms 653771/923376 (71%) receiver Eglobal Intel Core i3-7100U
-
Vielen Dank für die Messungen, micneu!
Der Intel Atom E3815 (TDP 5W) aus dem Jahr 2013 schafft 168 Mbits/sec? Das finde ich ganz ordentlich.
Und mit einer Core i3-7100U bekommt man Gigabit speed. Ist aber mit einer Verlustleistung von 15W ein kleiner Stromfresser. :)
Die APU2 verbraucht ca. 6-10W (komplett, nicht nur CPU).
-
> Also kann man festhalten: Per LTE-Hotspot gern testen, ob die Verbindung überhaupt zustande kommt – Geschwindigkeitstests sollte man über LTE aber eher nicht machen … ;)
Wie ich oben schon angemerkt hatte, BTW :P Ich hätte LTE zum Speedtest wirklich nicht getraut :)
@Atom CPU: Es gibt ja nicht "DIE" Atom CPU, aber die SOCs wie der E3000er oder eben die Netzwerk SOCs wie der C2000er oder jetzt Denverton C3000er sind durchaus flott dabei. Unsere letzten Tests waren bei einem
4-Kern C2558er (scope7 7525): IPSEC ~ 350Mbps bei AES-GCM, OpenVPN ~230Mbps bei Tunnel mit GCM, Einwahl und CBC bei rund 160Mbps was immer noch flott ist.
4-Kern C3558er (scope7 1510): IPSEC ~ 550Mbps bei GCM, OVPN bei 280-380 Mbps bei Einwahl bzw. CBC und Tunnel bei ~460Mbps.
Mehr als 200 bzw. knapp 500Mbps encrypted zu schieben finde ich da bei der Leistung bei ~8-10W völlig angemessen :)
Bezüglich sowas hier:
> Komprimierung habe ich deaktiviert, cipher ist AES-128-CBC, auth SHA1.
Sollten wirklich alle inzwischen die aktuellen Mindestgrößen von Cipher und Security aktivieren. Dazu gehört auch, kein SHA-1 mehr zu nutzen und entsprechend höhere/hohe DH Werte oder besser gleich elliptische Kurven zu nutzen wie sec256r1, sec384r1 oder die Brainpool Kurven 256r1, 384r1 oder 512r1. RSA < 2048 geht genausowenig wie SHA1 nicht mehr.
Wenn die Hardware recht leistungsarm ist, sollte man zumindest die Suite-B 128 Ciphersuite nutzen, bei modernerer Hardware ist die Suite-B-256 empfohlen.