IPSEC Performance

digitalcomposer

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.html

Ich habe das Gefühl, dass es erst mit Version 2.5 angefangen hat.

micneu

@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)

digitalcomposer

Mit Version 2.4... habe viel bessere Werte

Anbei die Werte von openssl:

openssl-gcm.txt

aes-256-cbc.txt

micneu

@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:

digitalcomposer

@micneu

In dem ersten Post sind die Werte von iperf Site to Site

micneu

@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.

digitalcomposer

@micneu

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.

micneu

@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)

digitalcomposer

@micneu

Danke für deine Hilfe.

Anbei Phase 1 und 2

Screenshot 2021-07-14 at 22.04.18.png

Screenshot 2021-07-14 at 22.05.00.png

digitalcomposer

@micneu

anbei auch speedtest-cli

Testing download speed................................................................................
Download: 931.97 Mbit/s
Testing upload speed......................................................................................................
Upload: 861.55 Mbit/s

JeGr

@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

digitalcomposer

@jegr

Das ist genau mein Problem, sobald ich auf AES-GCM wechsle bekomme ich noch weniger 20-30/Mbit.

AES-NI CPU Crypto: Yes (active)

2021-07-15 10_40_17-Window.jpg

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.

JeGr

@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.

digitalcomposer

@jegr

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.

digitalcomposer

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.

digitalcomposer

Jetzt hoffe ich, dass WireGuard stabil bleibt, da eine ganze Filiale über die VPN-Verbindung läuft.

JeGr

@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 :)

digitalcomposer

@jegr

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.

JeGr

@digitalcomposer Also von den ersten Durchläufen ist der Kram im Prinzip schon sehr stabil. Allerdings hat er im Clusterbetrieb einige Einschränkungen, so dass Dinge wie Failover/Fallback und Cluster/CARP noch nicht wirklich sinnvoll umsetzbar sind (bzw. nur mit etwas overhead) aber wenn der Tunnel steht und nicht ständig die Verbindung WAN-seitig abreißt, sollte das eigentlich sehr stabil laufen :)

digitalcomposer

@jegr

Hmm, ja stimmt.

Aber es ist auch bei WireGuard möglich Hostname.domain einzutragen anstatt IP und dann über DNS failover zu machen?