IPSEC Performance
-
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.51kich 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.
-
@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 :)
-
Hmm, ja stimmt.
Aber es ist auch bei WireGuard möglich Hostname.domain einzutragen anstatt IP und dann über DNS failover zu machen?
-
@digitalcomposer Suboptimal. Soweit ich weiß - wenn ichs noch komplett zusammen bekomme - geht das nur recht halbgar, da die URLs nicht ständig neu eingelesen werden. Dadurch kann dir der DNS Cache dazwischenspringen. Zudem macht DNS round robin, das heißt es ist unzuverlässig welche Leitung genutzt wird, du kannst ja nicht eine IP priorisieren, die der DNS ausliefert, sondern nur 2 A/AAAA Records hinterlegen und DNS liefert mal so und mal so rum aus. Daher ist Failover via DNS eher schlecht.
Wenn es nur eine Instanz auf jeder Seite ist, ist MultiWAN noch ganz OK'ish zu lösen, indem man 2 Tunnel auf beide Endpunkte mit WG baut und dann darüber ne Route via OSPF legt die dann zwischen den beiden GWs hin und her schwuppt. Aber bei CARP wirds wieder unschön, weil du das abgehende Interface nicht definieren kannst, weil WG IF-less arbeitet und sich nicht an eine IP/Interface binden lässt. Da ist OVPN dann wesentlich einfacher zu handhaben.
Wäre interessant, was du an OVPN Power hättest zwischen den beiden Locations, ob also nur IPsec so kaputt ist oder ob es auch OVPN betrifft. Da OVPN ja selbst OpenSSL und AES-NI anspricht ohne spezifisch das Kernel Modul zu brauchen, sollte das eigentlich nicht betroffen sein. Seltsam.
-
Ich glaube irgendwo habe ich wenigstens für IPsec gelesen, dass die DNS-Abfrage jetzt immer stattfindet. Bei wireguard bin ich nicht sicher ehe nicht.
Meine Idee ist DNS Made Easy zu benutzten, da hier die Option gibt, Endpoints zu überwachen und pro DNS-Eintrag Failover IP's zu hinterlegen. Ist die erste IP nicht mehr erreichbar, wird die zweite als DNS Antwort gegeben. OSPF habe ich 2006 zuletzt gebrauch :), muss ich schauen.Momentan bin ich froh, dass es mit Wireguard sehr gut funktioniert und müde um OpenVPN zu Testen, da alles in Production ist, heißt nur nach 20:00 Uhr und vor 06:00 Uhr.
Danke für die interessante Diskussion.
