Firewall-Leistungstests mit Xena VulcanBay

In diesem konkreten Testfall nutzten wir eine Xena VulcanBay mit 2x 40 Gbps QSFP+ Schnittstellen, um einige Next-Generation Firewalls hinsichtlich ihrer Performance zu testen. Konkret interessierten uns folgende Testszenarien:

• Reiner Durchsatz
• Hohe Anzahl an Verbindungen (Sitzungslast)
• Verwendung von NAT
• Realistischer Verkehr
• Längere Testperioden, in denen wir neue Firewall-Regeln eingeführt haben, um potenzielle Durchsatzverletzungen zu erkennen

In diesem Artikel zeigen wir, wie wir die Xena VulcanBay inklusive Management, dem VulcanManager, und einen Cisco Nexus Switch zur Anbindung der Firewall-Cluster eingesetzt haben. Wir listen unsere Testszenarien auf und geben Hinweise auf mögliche Stolpersteine.

Für unsere Tests stand uns eine Xena VulcanBay Vul-28PE-40G mit Firmware-Version 3.6.0, Lizenzen für beide 40G-Schnittstellen und den vollen 28 Packet Engines zur Verfügung. Der VulcanManager lief auf Version 2.1.23.0. Da wir nur eine einzige VulcanBay (und nicht mehrere an verteilten Standorten) nutzten, konnte der einzige Admin-Benutzer die vollen 28 Packet Engines gleichmäßig auf diese beiden Ports verteilen.

 

Für Tests mit bis zu 80 G Durchsatz waren zwei QSFP+ Module (links) sowie die Verteilung der Packet Engines auf diese Ports (rechts) ausreichend.Verdrahtung

Um die VulcanBay mit den jeweiligen Firewall-Clustern zu verbinden, nutzten wir einen einzelnen Cisco Nexus Switch mit ausreichend QSFP+-Modulen und entsprechendem Durchsatz. Da wir alle Firewall-Cluster sowie die VulcanBay gleichzeitig an diesen Switch angeschlossen hatten und für die Tests stets dieselben IPv4/IPv6-Adressbereiche nutzten, konnten wir rein über das „Abschalten/Nichtabschalten“ einzelner Schnittstellen entscheiden, welchen Firewall-Hersteller wir testen wollten. Somit war das gesamte Labor aus der Ferne steuerbar. Sehr praktisch für den typischen Fall eines Homeoffice-Mitarbeiters. Darüber hinaus war es so einfach, die VulcanBay „mit sich selbst“ zu verbinden, um aussagekräftige Referenzwerte für alle Tests zu erhalten. Dazu wurden die beiden 40G-Schnittstellen zur VulcanBay temporär im selben VLAN konfiguriert.

 

Mit jeweils zwei Leitungen für Client und Server waren alle Firewall-Cluster an einen zentralen Switch angeschlossen. Auch die VulcanBay von Neox Networks.

Es gibt Switches mit QSFP+ Modulen, die allerdings als 4x 10G und *nicht* als 1x 40G ausgelegt sind. Für die Anbindung der VulcanBay mit ihren 40G Schnittstellen ist Letzteres unumgänglich.

 

Dank moderner QSFP+ Steckplätze mit 40G Schnittstellen kann mit nur zwei Anschlüssen ein Duplex-Durchsatz von 80 Gbit/s erreicht werden.IP-Subnetze

In unserem Fall wollten wir verschiedene Firewalls im Layer-3-Modus testen. Um dieses „Testgerät“ (DUT)-Routing zu integrieren, erstellten wir entsprechende Subnetze – sowohl für das veraltete IPv4-Protokoll als auch für IPv6. Die von VulcanBay simulierten IP-Subnetze werden dann direkt an die Firewall angebunden. Im Fall eines /16 IPv4-Subnetzes… network, genau dies /16 network Die Konfiguration muss auch an der Firewall erfolgen. Besonders wichtig ist das Standardgateway, beispielsweise 10.0.0.1 für die Client-IPv4-Adresse. networkWenn Sie zusätzlich die Option „ARP verwenden“ (rechte Seite) aktivieren, brauchen Sie sich keine Gedanken über die angezeigten MAC-Adressen zu machen. VulcanBay löst diese automatisch auf.

 

Damit die durchgeführten Tests nicht einem MAC-Flooding gleichkommen, muss der Adressbereich angepasst werden.

Dasselbe gilt für IPv6. Hier die network Die Eingabe erfolgt nicht in der üblichen Schrägstrichnotation, sondern es werden lediglich Gateway und Adressbereich ermittelt. Über „NDP verwenden“ löst VulcanBay die Layer-2-MAC-Adresse automatisch in die Layer-3-IPv6-Adresse auf.

 

„Use Gateway“ teilt VulcanBay mit, dass für die Tests ein Zwischenrouter/eine Zwischenfirewall verwendet werden soll.

MAC-Flooding! Abhängig von den verwendeten Testszenarien kann VulcanBay Millionen von IPv4/IPv6-Adressen im Client- oder Server-Segment simulieren. Dies entspricht einer wahren Flut von MAC-Adressen für jeden zwischengeschalteten Switch oder jede Firewall. Gängige High-End-Gewichte können maximal 128 MAC-Adressen in ihrer MAC-Adresstabelle speichern. Belässt man den von Xena Networks standardmäßig festgelegten Bereich von 16 Millionen (!) IPv4-Adressen bzw. 1.8 x 10^19 IPv6-Adressen, sind die Testergebnisse bedeutungslos. Wir empfehlen daher dringend, die Adressbereiche von Anfang an auf realistische Werte zu reduzieren, wie im obigen Screenshot zu sehen (gelb markiert: 65 Adressen).

Zum Vergleich wurde die VulcanBay für alle Tests auch „mit sich selbst verbunden“. IPv4 erlaubte die Verwendung derselben „Subnetze“. networkBei IPv6 waren Subnetze innerhalb des *gleichen* /64-Präfixes erforderlich, da hier unterschiedliche Adressbereiche verwendet wurden.Testfälle

1) Reiner Durchsatz: Im ersten Testszenario ging es uns rein um den Durchsatz der Firewalls. Dazu wählten wir das Szenario „Pattern“, einmal für IPv4 und einmal für IPv6, wodurch das Verhältnis automatisch auf 50:50 eingestellt wurde. In den Einstellungen haben wir zusätzlich „Bidirektional“ ausgewählt, um Daten in beiden Fällen in beide Richtungen, also Duplex, durchzudrücken. So konnten wir mit den 80x 2G-Schnittstellen den maximalen Durchsatz von 40G erreichen. Um die Bandbreite auf mehrere Sitzungen zu verteilen (was in der Praxis der realistischere Testfall ist), wählten wir 1000 Benutzer aus, die von 100 Quellports aus Verbindungen zu jeweils 10 Servern aufbauen sollten. Macht jeweils 1 Million Sitzungen für IPv4 und IPv6. Bei einer Ramp-up-Zeit von 5 Sekunden, also einem sanften Anstieg der Verbindungen statt der sofortigen Volllast, lief der reine Test anschließend 120 Sekunden durch, bevor er ebenfalls eine Ramp-down-Zeit von 5 Sekunden hatte.

 

Testszenario „Pattern“ mit einer 50:50-Verteilung von IPv4 und IPv6. Das „Load Profile“ (rechts) zeigt die zu simulierenden Benutzer über der Zeitachse.

Während des Tests zeigt der VulcanManager bereits einige nützliche Daten an, wie beispielsweise TCP-Verbindungen oder Layer-1-Durchsatz. Anhand der Grafiken im oberen Bereich erhält man auf einen Blick einen guten Eindruck. Im folgenden Screenshot ist zu erkennen, dass die Anzahl der aktiven Verbindungen weniger als die Hälfte der geplanten beträgt (schlecht), während der Layer-5-7-Goodput zu Beginn des Tests einen unschönen Knick aufweist. Beide Probleme stellten sich als Fehler in der IPv6-Implementierung des getesteten Geräts heraus.

 

Obwohl theoretisch 2 Millionen Sitzungen mit einem Durchsatz von 80 G die Firewall hätten passieren sollen, kam weniger als die Hälfte davon problemlos durch.

Die Grafik „Aktive Sitzungen“ zeigt nicht die tatsächlich aktiven Sitzungen, sondern die Anzahl der simulierten Benutzer in der Live-Ansicht während des Tests sowie im späteren PDF-Bericht. Während die Grafik für die 2000 Benutzer korrekt ist, gab es während des Tests tatsächlich 2 Millionen Sitzungen.

2) Hohe Verbindungsanzahl (Session-Last): Auch für IPv4 und IPv6 wurden im Rahmen dieses Tests 20 Millionen parallele TCP-Sessions aufgebaut und aufrechterhalten. Nicht nur die Summe der Sessions war relevant, sondern auch die kurze Hochlaufzeit von nur 30 Sekunden, was einer Aufbaurate von 667,000 Verbindungen pro Sekunde entsprach! Die Sessions blieben 60 Sekunden lang bestehen, ohne jedoch Daten zu übertragen. Über weitere 30 Sekunden wurden sie, TCP-typisch, per FIN-ACK wieder beendet. Ziel war, dass die zu testenden Firewalls die Verbindungen einerseits sauber passieren lassen und andererseits auch sauber abbauen (und so ihren Speicher freigeben) konnten.

Vor jedem Test löschten wir die MAC-Adresstabelle auf dem Switch sowie die Session-, ARP- und NDP-Caches auf den Firewalls. Somit wurde jeder Test von Null auf Null durchgeführt.

3) NAT-Szenarien: Es wurde der gleiche Test wie unter 1) durchgeführt, mit dem einzigen Unterschied, dass die IPv4-Verbindungen vom Client aus erfolgten. network an den Server network Den Firewalls wurde Source-NAT zugewiesen. Ziel war es herauszufinden, ob dies zu einer Leistungsverschlechterung der Firewalls führen würde.

4) Realistischer Datenverkehr: Mit einem vordefinierten „Datacenter Mix“ konnten wir den Datenverkehr von zwei HTTPS-, SMB2-, LDAP- und AFS-Verbindungen (via UDP und TCP) für mehrere tausend Benutzer mit wenigen Klicks simulieren. Dabei ging es nicht um einen Volllasttest der Firewalls, sondern um die Auf- und Abbaugeschwindigkeiten sowie die Anwendungserkennungen. Je nachdem, ob die App-IDs der Firewalls aktiviert oder deaktiviert waren, gab es hier große Unterschiede.

5) 10 Minuten Dauerfeuer mit Commits: Dieser etwas spezifischere Test bestand aus den Szenarien 1 und 4, also Volllast (1) mit ständigem Session-Auf- und -Abbau (4) gleichzeitig. Dies lief 10 Minuten lang konstant, während wir auf jeder Firewall zusätzlich 500 Regeln installierten. Hiermit wollten wir herausfinden, ob dieser Prozess einen messbaren Durchsatzeinbruch auf den Firewalls verursacht, was teilweise der Fall war.Testergebnisse

Am Ende jedes Tests zeigt VulcanManager die Statistik- und Berichtsseite mit allen möglichen Details an. Über „Bericht erstellen“ lässt sich ein PDF erstellen, das neben allen Details auch Informationen zum gewählten Testszenario sowie zum getesteten Gerät enthält. Die Herausforderung besteht darin, die relevanten von den weniger relevanten Zahlen zu unterscheiden und in den richtigen Kontext zu setzen, um aussagekräftige Ergebnisse zu erhalten. Bei unseren Vergleichen verschiedener Next-Generation-Firewalls beschränkten wir uns auf den „Layer 1 stabilen Durchsatz (bps)“ für den Durchsatztest bzw. die „Erfolgreichen TCP-Verbindungen“ für den Verbindungstest. Im Vergleich zu den Referenzwerten, bei denen die VulcanBay mit sich selbst verbunden war, ergab dies bereits aussagekräftige Vergleichsergebnisse, die sich sowohl tabellarisch als auch grafisch gut darstellen ließen.

 

Die Seite „Statistik und Reporting“ bietet einen groben Überblick (Mitte) und die Möglichkeit, Testwerte aus allen OSI-Schichten und den ausgewählten Testszenarien abzulesen (Links, ausklappbare Reiter).

 

Ausschnitt eines PDF-Berichts mit allen Einzelheiten.

Die verschiedenen bestehenden „Application Mix“-Szenarien von Xena Networks dienen nicht dem direkten Vergleich der Firewall-Leistungswerte, sondern der angestrebten Generation von network Auf diese Weise können Anwendungserkennungen überprüft oder andere parallel ausgeführte Szenarien etwas stärker belastet werden.Weitere Funktionen

Beachten Sie, dass VulcanManager über weitere interessante Funktionen verfügt, die wir in dieser Fallstudie nicht verwendet haben, wie z. B. TLS Traffic (zum Testen von TLS-Interception) und Packet Replay (zum Testen benutzerdefinierter und spezifischerer Szenarien, die aus hochgeladenen PCAPs extrahiert wurden). Außerdem haben wir viele anwendungs- oder protokollorientierte Testszenarien wie Dropbox, eBay, LinkedIn oder HTTPS, IMAP und NFS nicht verwendet. Dies liegt an unseren Testzwecken, die stark auf reinen Durchsatz und Sitzungsanzahl ausgerichtet waren.Fazit

Die VulcanBay von XENA Networks ist das ideale Testgerät für den Vergleich verschiedener Next-Generation-Firewalls. Innerhalb kürzester Zeit hatten wir verschiedene Testszenarien konfiguriert und getestet. Lediglich die Fülle der Testergebnisse war zunächst überwältigend. Die Kunst bestand darin, sich auf die relevanten Informationen zu konzentrieren.