Site to Site VPN Performance sehr langsam

[pipen1976]

Hallo, ich habe 2 Standorte mit IPSec Site to Site verbunden. Die Verbindung ist stabil. Allerdings ist die Performance nicht gut. Dateien werden mit ca. 1 Mbit/s übertragen. An beiden Seiten ist ein 100 Mbit/s Telekom DSL Anschluss.

Standort A ist ein APU Bundle mit einem APU.2D4 Board und an Standort B ist eine Netgate SG-5100 verbaut. Der Tunnel ist auf beiden Seiten folgend konfiguriert:

Ich habe MSS clamping aktiviert und auf 1350 eingestellt und den IKEv1 auf auf Aggressiv gestellt. Beide Umstellungen brachten keine Besserung.

Was kann ich noch verändern um die Performance zu verbessern?

Gruß Christian

[denndsd]

Hi,

hast du mal eine geringere Verschlüsselung versucht ?
Die AES Krypto Mechanismen werden vom CPU unterstützt und sind aktiv ?
Bei Unitymedia habe ich es häufig dass es scheinbar mit dem DS Lite so gut wie garnicht geht.
Aber bei einem DSL und IPsec lief das eigentlich immer ganz ordentlich.

[NOCling]

Würde den Tunnel gleich als IKEv2 einrichten, v1 ist nicht mehr stand der Dinge.

256Bit AES-GCM ist für x86 Hardware schon gut, wenn die das in Hardware könne dauert das kaum länger als 128.

Mit OpenVPN hatte hier jemand durch Setzen der Empfangs und Sendebuffer viel Speed erzielt, 0 war bei ihm das schnellste.

Und sorry, die deutsche GUI geht gar nicht.

Mit "Asynchronous Cryptography" solltest du auch mal spielen, ich hatte mit der SG-1100 vor 2.4.5 Probleme, da hier der Treiber für den CESA noch nicht aktiv war und dann beim Win Client nur Paketsalat ankam, Hacken raus und Line Speed.

[pipen1976]

Ich habe mittlerweile den Tunnel als IKEv2 eingerichtet. Die Phase 1 Proposal (Encryption Algorithm) habe ich mittlerweile auf AES256-GCM mit 128bits Key length umgestellt. Auch bei Phase 2 Proposal (SA/Key Exchange) wurde der Encryption Algorthms auf AES256-GCM mit 128bits Key length umgestellt. Leider konnte ich keine Besserung feststellen.

Send/Receive Buffer kann ich ja nur bei OpenVPN angeben. Ich habe ja IPSec.

"256Bit AES-GCM ist für x86 Hardware schon gut, wenn die das in Hardware könne dauert das kaum länger als 128." verstehe ich leider nicht...
Auf beiden Seiten ist die Cryptographic & Thermal Hardware eingeschaltet. Die CPU`s beider Seiten unterstützen laut Datenblatt AES-NI. Auf dem Dashboard sieht es so aus.

CPU Standort A

CPU Standort B

Welche Einstellung ist unter Cryptographic & Thermal Hardware eigentlich richtig? Ist der Punkt Thermal Sensors auch von Bedeutung?

[pipen1976]

Ich habe ein wenig ausgetestet. Neue Konfiguration ist:

• IKEv2 eingerichtet
• Phase 1 Proposal (Encryption Algorithm) AES256-GCM mit 128bits Key length
• Phase 2 Proposal (SA/Key Exchange) Encryption Algorthms auf AES256-GCM mit 128bits Key length
• Asynchronous Cryptography Haken raus
• Enable Maximum MSS 1400

Standort A WAN ist Produktiv mit ca. 35 Clients, Standort B wird noch nicht gearbeitet.

Test mit iperf Standort A Server, Standort B Client: Bandwidth 36,5 Mbits/sec

Test mit iperf Standort B Server, Standort A Client: Bandwidth 16,5 Mbits/sec

[NOCling]

Hast du die MTU mal im Detail ermittelt oder einfach so mal was eingestellt?

Da könntest du ggf. noch mal tunen.

Für deine APU brauchst du nur die AES-NI CPU-Based Acceleration, wenn du beiden Einstellst würde das aber nicht schaden, da die einfach nicht aktiv angesprochen werden.

Ob jetzt 128bit AES oder 256bit verwendet werden, macht bei Hardware Support nur wenige Mbit aus.
So war das gemeint.
Dein x86 mit AES-NI kann AES-GCM sehr gut beschleunigen, so gut das deine APU2 die Leitung eigentlich auslasen sollte.

100Mbit DSL bei Telekom sind 40Mbit UP?
Dann ist 36 Mbit im Tunnel voll ok, denn du kannst 10% Overhead abziehen.
Ich habe hier Kabel mit 400/40, das provisioniert aber meist 10% höher und daher laufen bei mir 4MB/s durch den Tunnel.
Auf dem Rückweg ist der Upload schon 50 und da laufen auch wirklich konstant 50MBit im WAN ein, wenn ich per Client da hin verbinde und was lade.
MSS habe ich per Handy mit LTE ermittelt und da kamen 1332 bei raus, damit rennt es aber.

SG-5100 sollte jedenfalls weit mehr als die Leitung können, mein SG-1100 langeilt sich bei 50Mbit ja sogar noch, mein SG-3100 pennt dabei fast komplett, das SG-5100 dürfte im Monitoring Graph nicht mal zucken.

[JeGr]

@pipen1976 said in Site to Site VPN Performance sehr langsam:

Ich habe MSS clamping aktiviert und auf 1350 eingestellt und den IKEv1 auf auf Aggressiv gestellt. Beide Umstellungen brachten keine Besserung.

Mode 1 agressive ist veraltet und wird aus Sicherheitsgründen nicht empfohlen.

• IKE v2 statt v1 (alten Mist weg)
• AES-GCM statt AES -> wesentlich schneller mit weniger Overhead. Beachten: In System/Advanced muss die AES Beschleunigung auch an sein, damit IPsec sie nutzen kann! (wird auf dem Dashboard dann angezeigt)
• SHA256 ist OK
• DH Gruppe 31 mit ED25519 oder die mit secp384r1 (eine der 20er).

Wenn die Hardware etwas lasch ist (APU2), dann nutze meinetwegen AES128-GCM aber GCM schlägt gerade bei IPsec normales CBC/CFB AES um Längen. Oh und DH Group 14 ist eigentlich zu klein. DH <15 wird seit letztem Jahr schon nicht mehr wirklich empfohlen. Und dann erstmal Finger weg von manuellem MTU spielen und damit messen. Und bitte nicht messen AUF den Geräten, sondern dahinter, da sonst zu ungenau.

Gerade die SG5100 haben wir mit ~300-500Mbps (in Spitzen) und AES-GCM schon bei IPsec gemessen. An der liegt es definitiv nicht.

[A Former User]

Zwischen zwei PPPoE Verbindungen, mit einer Path-MTU von 1492 Bytes, bekommt man mit ESP und AES-GCM Verschlüsselung im Tunnel-Mode max. eine MTU von 1438 Bytes (1398 MSS) für die IPSEC-Verbindung hin. Sollte ESP in UDP verpackt werden müssen, z.B. aufgrund von finsteren Dual-NAT Konfigurationen, sind es entsprechend 8 Byte weniger.