IPSEC Performance
-
Hallo Zusammen
Folgendes Problem:
Ipsec Site to Site selbe Hardware und ISP, Site A 1Gbit und Site B 1Gbit.
Das Maximum, was ich kriege, ist mit AES, aber trotzdem zu wenig.
Wenn ich mich nicht irre, war mit 2.4.... viel besser.
Eine Idee, was ich noch testen kann?
Hardware Crypto ist aktiviert.
CPU Type Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
8 CPUs: 1 package(s) x 4 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No
Hardware crypto AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS.[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.04 sec 23.8 MBytes 191 Mbits/sec 0 177 KBytes
[ 5] 1.04-2.01 sec 23.1 MBytes 200 Mbits/sec 2 176 KBytes
[ 5] 2.01-3.00 sec 28.0 MBytes 237 Mbits/sec 0 192 KBytes
[ 5] 3.00-4.01 sec 27.2 MBytes 226 Mbits/sec 2 156 KBytes
[ 5] 4.01-5.01 sec 29.5 MBytes 247 Mbits/sec 0 208 KBytes
[ 5] 5.01-6.01 sec 29.3 MBytes 247 Mbits/sec 0 208 KBytes
[ 5] 6.01-7.00 sec 30.0 MBytes 254 Mbits/sec 0 208 KBytes
[ 5] 7.00-8.00 sec 30.3 MBytes 254 Mbits/sec 0 208 KBytes
[ 5] 8.00-9.00 sec 30.3 MBytes 254 Mbits/sec 0 208 KBytes
[ 5] 9.00-10.02 sec 31.3 MBytes 258 Mbits/sec 0 208 KBytes[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 283 MBytes 237 Mbits/sec 4 sender
[ 5] 0.00-10.02 sec 283 MBytes 237 Mbits/sec receiver -
@digitalcomposer Da steht ja jetzt genau gar nichts drin zur Diagnose. Wie sollen wir anhand davon denn jetzt wissen, was wo wie konfiguriert ist und wo man ggf. noch mehr Output raus bekommt?
-
Danke für die Rückmeldung.
Was soll ich genau prüfen oder hier zeigen. Sobald ich AES-GCM setze sind die Werte in iperf 23-24/mbit. Die Werte von oben sind nur mit AES.
Habe die Empfehlung hier auch probiert, ohne Erfolg.
https://docs.netgate.com/pfsense/en/latest/vpn/performance.htmlIch habe das Gefühl, dass es erst mit Version 2.5 angefangen hat.
-
@digitalcomposer hättest du mal auch den openssl befehl mit gepostet dann hätte man auch einen vergleich mit anderer hardware machen können.
vom gefühl her würde ich sagen das problem ist du benötigst nicht Core´s sonder GHz (2.2Ghz sind nicht gerade viel) -
Mit Version 2.4... habe viel bessere Werte
Anbei die Werte von openssl:
-
@digitalcomposer in deinem ersten post hast du aber ganz andere werte.
ich bin ganz stark davon überzeugt das es an der CPU liegt, ja die hat viele core´s aber einen geringen takt.
hier mal meine werte von meiner sense:/root: openssl speed -elapsed -evp aes-256-gcm You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-gcm for 3s on 16 size blocks: 124833978 aes-256-gcm's in 3.02s Doing aes-256-gcm for 3s on 64 size blocks: 82037717 aes-256-gcm's in 3.04s Doing aes-256-gcm for 3s on 256 size blocks: 44810387 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 1024 size blocks: 15320549 aes-256-gcm's in 3.02s Doing aes-256-gcm for 3s on 8192 size blocks: 2318616 aes-256-gcm's in 3.05s Doing aes-256-gcm for 3s on 16384 size blocks: 1165601 aes-256-gcm's in 3.02s OpenSSL 1.1.1k-freebsd 25 Mar 2021 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-gcm 660620.12k 1727642.62k 3823819.69k 5188875.97k 6218018.14k 6332752.51k
ich habe weniger cores aber dafür einen höheren takt (siehe footer)
ich hatte auch mal eine xeon d und ich war damals mit der aes performance sehr unzufrieden.ich habe mal ein paar cpu´s getestet alle unter linux:
-
In dem ersten Post sind die Werte von iperf Site to Site
-
@digitalcomposer also ich habe mir die CPU im ark mal angeschaut, die ist von 2015, also nicht mehr ganz aktuell, ich kann mir zwar vorstellen das linux etwas bessere werte liefern würde, nur trotzdem ist das keine rakete.
-
Beide Firewalls sind schon lange im Einsatz und als ich damals Site to Site aufgebaut habe waren die Geschwindigkeiten viel besser, leider habe ich keine werte von 2.4, ich habe per Zufall bemerkt als ich eine Iso-Datei von A nach B kopieren müsste.
-
@digitalcomposer bitte mal deine ipsec config als screenshot posten
nur ich bin trotzdem der meinung das die cpu´s nicht so schnell sein können
ich denke die wird nicht schneller als die Xeon D-2123IT sein.
du hattest ja die werte (text dateien) gepostet. das ist halt unter freebsd so, wie schon geschrieben unter linux kann ich mir vorstellen das da noch etwas mehr geht. aber viel mehr glaube ich auch nicht.prüfe mal ob sich nicht was aufgehängt hat, sind auf beide seiten die NIC´s wirklich im 1GBit/s verbunden (hatte mal bei meinem system nach einem reboot das die kiste nur mit 100mbit/s hochkam)
-
-
anbei auch speedtest-cli
Testing download speed................................................................................
Download: 931.97 Mbit/s
Testing upload speed......................................................................................................
Upload: 861.55 Mbit/s -
@micneu said in IPSEC Performance:
ich bin ganz stark davon überzeugt das es an der CPU liegt, ja die hat viele core´s aber einen geringen takt.
Sorry aber nö. Das ist nen Xeon-D 1518. Netgate selbst hat zwei davon im Angebot mit der XG-1537 und 1541. Die 1518 ist nur die schwächere Variante. Und bei der 1537 sind ~2.x Gbps Throughput bei IPsec angegeben. SO viel schwächer ist der 1518 auch nicht, als dass das nicht komplett aus dem Ruder wäre.
AES
Bei Xeon-D ist zudem AES nicht sinnvoll. AES-GCM ist IMMER schneller wenn AES-NI oder QAT vorhanden ist. Und dann bitte in beiden Phasen auswählen.
https://shop.netgate.com/collections/rack-appliances/products/1537-base-pfsense
-
Das ist genau mein Problem, sobald ich auf AES-GCM wechsle bekomme ich noch weniger 20-30/Mbit.
AES-NI CPU Crypto: Yes (active)
Und wie gesagt, es ist jahrelang sehr gut gelaufen, leider weiss ich nicht wegen was ist jetzt plötzlich so schwach. Die einzige Vermutung ist, dass es mit Version 2.5.... zu tun hat.
-
@digitalcomposer Dann liegt aber vielleicht was anderes im Argen. Wenn mit GCM WENIGER läuft als mit CBC hört sich das nicht so an, als würde die Crypto sauber angesprochen werden. Das macht keinen Sinn.
Ansonsten könnte man nur den Vergleich machen wenn das Kernel Modul definitiv disabled ist. Also Crypto auf none in den adv Settings und dann die Kiste neu starten. Das sollte definitiv schlechter sein als jetzt. Ansonsten ggf. auch mal den PowerD aktivieren und die CPUs auf dem HIAdaptive oder auf Max setzen, damit die auch wirklich mit voller Lotte laufen. Vielleicht hakts da im Power Management.
-
So, jetzt habe ich alles probiert.
Mit PowerD HiAdaptive und ohne PowerD HIAdaptive.
Crypto auf none, save und Neustart, wieder auf AES-NI save und wieder Neustart.
MSS clamping verschiedene Werten.Keine Veränderung, entweder ca. 300Mbit/s ohne crypto oder 23Mbit/s mit crypto GCM.
-
Ok, jetzt habe ich IPSEC-VTI deaktiviert und mit WireGuard ausprobiert.
Unglaublich ich bekomme 800Mbit/s über WireGuard Site to Site!!!
Es stimmt etwas mit IPSEC nicht.
-
Jetzt hoffe ich, dass WireGuard stabil bleibt, da eine ganze Filiale über die VPN-Verbindung läuft.
-
@digitalcomposer Eine Idee wäre noch gewesen, das mal testhalber mit P2 IPsec zu machen statt VTI. In VTI ist ja das ein oder andere Thema eh noch im Argen, vielleicht hat sich da auch was mit Crypto verklemmt, wäre mir aber aktuell nichts bekannt. Sehr merkwürdig, aber das Verhalten dann von Wireguard (und wahrscheinlich auch OpenVPN) zeigt dann eigentlich schon, dass es gehen müsste, was die HW angeht :)
-
Ja, ich war sicher, dass es nicht HW-Problem ist. VTI zu ersetzen mit P2 pro VLAN habe ich mir auch überlegt.
Ich bleibe jetzt so mit WireGuard und falls WireGuard net stabil ist, probiere ich mit P2 IP-SEC.
Trotzdem vielen Dank an allen.