IPSEC Performance
-
@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.
-
@digitalcomposer said in IPSEC Performance:
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.
Ich meinte damit auch nicht den produktiven Tunnel offline zu nehmen, aber vielleicht kann man einen OVPN Tunnel zusätzlich aufbauen und dort dann bspw eine Art Testnetz drüberrouten - oder einfach nur von Punkt zu Punkt mit IPerf durchtesten via policy rules. Aber klar, dass man die Produktion nicht abschalten will und keine Lust darauf hat, ständig herumzuschrauben :)
