OPNsense Forum
International Forums => German - Deutsch => Topic started by: Perun on August 02, 2018, 11:46:25 am
-
Hallo
ich möchte gerne meine Filme über einen IPsec Tunnel in meiner Ferienwohnung schauen. Ich habe soweit den IPsec Tunnel hergestellt und alles netzeitig tut soweit.
Leider ist die Performance nicht ausreichend um z.B. einen BR Film zu schauen. Ich mess die Bandbreite mit iperf zwischen den beiden Endpunkten und bekomme 32-35Mbit in eine Richtung und ca. 2Mbit ind die andere über den Tunnel.
Die Leitungen sind 100/40Mbit auf der Server Seite und 50/2Mbit auf der Client Seite.
Also soweit so gut für IPsec über die Leitung. (Obwohl ich da von der apu2c4 sogar ein bisschen mehr erwarten würde)
Die 35Mbit sollten eigentlich vollkommen aussreichend sein für die BR's.
Leider stockt die BR und lässt sich so nicht schauen.
Ich habe bereits MSS Größe auf der opnsense Kiste eingestellt (1390 gemessen mit ping ohne Fragmentiereung warens 1402 möglich und dann für TCP 12 Byte abgezogen).
Den Tunnel bau ich mit ner Linux Kiste (strongswan) auf. Muss ich auch dort MSS einstellen?
Beide CPU's (opnsense und der Linux Box) sind entspannt bei der Übertragung.
An welchen "Schrauben" kann ich noch drehen um die Performance zu verbessern?
Greetz
-
Mit welchem Protokoll streamst du den Film? https?
-
ich streame nicht, ich habe samba share gemountet und spiele die einfach über kodi ab
-
Hi,
für mein Verständnis sieht die Leitung auf der Client Seite etwas mager aus. Wo läuft den Kodi. Nicht etwa auf einem Rapsberry oder ?
MFG
Wayne
-
kodi läuft auf einem extra Gerät (wetek), dies kann ganz normal BR etc abspielen.
Der Endpunkt von dem Tunnel ist ein HP Microserver Gen8 also auch ausreichend CPU Power.
Naja wie gesagt gemessen mit iperf habe ich 35Mbit in Download Richtung, da sollte eine BR locker laufen.
Beim kopieren mit wget von der einen auf die andere Seite mit dem Tunnel bekomme ich 4.3MB/s
obwohl hmmmm 1x Datenrate BR ist 36Mbit, da wird es tatsächlich knapp...
Sollte ich aber mit ner 50mbit Leitung und apu2c4 mit opnsense nicht mehr hinkriegen als 34Mbit über den Tunnel?
Da der HP Server deutlich 'mächtiger' ist gehe ich davon aus dass die apu Box der Flaschenhals ist...
Vielleicht sind meine Tunnelsettings zu krass:
Phase1: AES-GCM 256 with 128 ICV + SHA256 + DH Group 20 (384 bit EC)
Phase2: aes256gcm16 + SHA256 + DH Group 20 (384 bit EC)
ich habe 2 solche Tunnel an der Opnsense dran (der andere wird aber sehr wenig genutzt)
AES-NI ist an und die CPU Belastung liegt so bei 50-60% wenn ich was durch den Tunnel schicke also IMHO alles im grünen Bereich...
oder sehe ich da was falsch?
-
Also wenn ich das richtig verstehe, hat der Server doch "nur" 40Mbit Upstream. Dann bist du doch mit 35Mbit über VPN doch recht nahe dran. Die Verschlüsselung könntest du ja mal zu Test etwas runterdrehen, aber ich glaube nicht das da noch viel geht.
-
AES128GCM ist schneller .. aber spürbar erst wenns über 1Gbit geht.
DH Group könnte theoretisch ganz raus, das unterstützt ja GCM an sich schon. Viele machen es trotzdem, da reicht dann auch DH14. Dann könntest du noch schauen ob Pakete fragmentiert werden .. aber eher unwahrscheinlich.
Ich gehe auch stark davon aus dass bei einer 40Mbit Leitung du auch ohne IPSec nicht mehr raus bekommst, allein der Protocol overhead von SMB ist ja recht groß.
-
stimmt! da sind ja nur 40mbit up... dies habe ich nicht bedacht und smb overhaed ist tatsächlich viel hmmmm ich habe aber in Kodi Auswahl an Protokollen... mal gucken ob es mit ftp/http/nfs besser ist...
-
wie könnte ich definitiv feststellen ob was fragmentiert wird? ich habe die MTU eingestellt auf beiden seiten aber würde es gerne prüfen...
auf der opnsense Seite habe ich nach Messungen mit ping 1390 eingestellt und auf der strongswan seite so:
(aus einem strongswan docu)
/usr/sbin/iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
/usr/sbin/iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
-
AES128GCM ist schneller .. aber spürbar erst wenns über 1Gbit geht.
DH Group könnte theoretisch ganz raus, das unterstützt ja GCM an sich schon. Viele machen es trotzdem, da reicht dann auch DH14. Dann könntest du noch schauen ob Pakete fragmentiert werden .. aber eher unwahrscheinlich.
Ich gehe auch stark davon aus dass bei einer 40Mbit Leitung du auch ohne IPSec nicht mehr raus bekommst, allein der Protocol overhead von SMB ist ja recht groß.
mit AES128 und DH14 gibt es tatsächlich die gleichen Ergebnisse.
Lustigerweise bekomme ich ohne IPsec Ergebnisse zwischen 15 und 35Mbit mit iperf vielleicht ist da noch was mit Netzwerk weil es so unstabil ist?
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 6.85 MBytes 57.4 Mbits/sec 52 368 KBytes
[ 4] 1.00-2.00 sec 6.09 MBytes 51.1 Mbits/sec 7 288 KBytes
[ 4] 2.00-3.00 sec 6.65 MBytes 55.8 Mbits/sec 0 317 KBytes
[ 4] 3.00-4.00 sec 5.84 MBytes 49.0 Mbits/sec 7 91.9 KBytes
[ 4] 4.00-5.00 sec 2.86 MBytes 24.0 Mbits/sec 3 96.2 KBytes
[ 4] 5.00-6.00 sec 2.86 MBytes 24.0 Mbits/sec 2 84.8 KBytes
[ 4] 6.00-7.00 sec 2.86 MBytes 24.0 Mbits/sec 0 107 KBytes
[ 4] 7.00-8.00 sec 2.86 MBytes 24.0 Mbits/sec 2 93.3 KBytes
[ 4] 8.00-9.00 sec 1.86 MBytes 15.6 Mbits/sec 7 41.0 KBytes
[ 4] 9.00-10.00 sec 954 KBytes 7.82 Mbits/sec 0 63.6 KBytes
man sieht bei grosseren 'Stücken' ist es deutlich schneller...
-
ich sehe aber auch das die Test BR die ich abspiele so zwischen 10-20MBit Datenrate schwankt (VLC zeigt die an).
Und schon da gibt es Artefakte und Unterbrechungen... irgendwas ist da noch nicht so wie es sein sollte... Ich denke selten schöpft ne BR die vollen 36Mbit Datenrate aus....
-
MSS auf LAN mal auf 1400 stellen?
-
auf beiden Endpunkten?
-
Einer reicht.
-
Ansonsten könnte aber tatsächlich ein Wechsel statt mit SMB via NFS z.B. eine Besserung bringen, weil weniger Overhead. Leider weiß ich nicht was es für ein Host ist, den die Kodi Kiste eingebunden hat (Linux? Windows?). Besser könnte es wie gesagt höchstens mit NFS werden und ggf. NFS je nach Gegenstelle via TCP.