Schwachstromblog.de

Vor einiger Zeit hab ich ja hier über ein Problem mit zu hoher Last bei LANCOM VPN-Gateways geschrieben. Das Problem wurde besser, war aber nicht gelöst.

Jetzt hatte ich die Tage wieder ein vergleichbares Problem. Nur haben sich die Filialen nicht neu verbunden, sondern hingen im Rekeying fest. Eins der Gateways lief über sehr lange Zeit in Vollauslastung, wodurch dann auch die Latenz weit in den Sekundenbereich hineinging. Nach einem Neustart und viel Warten ging es dann wieder, aber das konnte ja nicht der Sinn sein.

Ich hatte auch noch immer ein anderes Problem. Alle paar Sekunden hatte ich eine Latenzspitze. Von 4ms ging es hoch bis in die Dreistelligkeit. Mal 190ms, mal 320ms, aber immer nur einen Ping. Mal waren es auch nur 60, aber bei einer Glasfaser mit zwei Hops bis zum Ziel ist das nicht akzeptabel. Mit etwas Ruhe habe ich dann einfach mal geschaut, woran es liegt und habe dann entdeckt, dass die Latenzspitze immer dann da war, wenn die Diffie-Hellman-Berechnung lief.

Und da kam mir die Idee. Bei IPSec gibt es zwei Phasen. Phase 1 hat eine DH-Berechnung, Phase 2 aber genauso viele Berechnungen, wie es Netzbeziehungen (Security Associations) gibt. Da die automatische Regelberechnung bei LANCOM hingeht und anhand des Schnittstellentags, der IP-Schnittstellen und der Routingtabelle die Netzbeziehungen einzeln aufbaut, kam es bei uns zu 64 Netzbeziehungen, also 16 IP-Schnittstellen mit vier Routen, obwohl eine Defaultroute ebenfalls über die VPN-Verbindung läuft und alles beinhalten würde. Aus internen Designgründen muss ich aber die RFC1918-Netze gesondert eintragen. Da auch alle Netzbeziehungen immer aufgebaut werden, werden natürlich jedes mal alle 64 DH-Berechnungen gleichzeitig durchgeführt.

Mit Hilfe der manuellen Regelerzeugung, die mit Einführung von IKEv2 durch LANCOM für IKEv1 auch um einiges angenehmer wurde, habe ich dann aus 64 Netzbeziehungen zwei gemacht. Also einfach lokal die beiden /24-Netze gegen 0.0.0.0/0 verknüpft, an die VPN-Verbindung angehängt, Regelerzeugung auf manuell gesetzt und gespeichert. Der VPN-Tunnel wird dann sofort neu aufgebaut und fertig. Dies sollte man sowohl auf der Filial- als auch auf der Zentralseite machen.

Die Peaks sind jetzt scheinbar weg und bei einem Neustart des VPN-Gateways dauert es nur noch wenige Sekunden, bis es normal weiterläuft. Die Verbindung zwischen Zentrale und Rechenzentrum dauert jetzt mit am längsten.