Vergleichstest Security-Appliances – Firewall und VPN bilden häufig den Flaschenhals in modernen Netzen. Dies hat ein Vergleichstest der Real-World Labs von Network Computing ergeben.

« ZUM ERSTEN TEIL

Firewall-TCP-Messungen

In unserer dritten Messreihe haben wir die Connection- Setup-Rate, die Connection-Capacity sowie den maximal erreichbaren Durchsatz in MBit/s im Firewall-Betrieb gemessen. Die Connection- Setup-Rate gibt an, wie viele Verbindungen das System maximal pro Sekunde aufbauen kann. Die Connection-Capacity ist das Maß dafür, wie viele Verbindungen das System maximal gleichzeitig halten kann. Bei der Performance- Messung baut die Messtechnik Verbindungen durch die Firewall auf und generiert Datenströme.Dabei geht der Hauptdatenstrom vom Reflector zum Avalanche.Die generierte Last ähnelt insgesamt einer unidirektionalen Smartbits- Messung mit großen UDP-Paketen. Daher sind die Messergebnisse relativ gut. Die jeweilige Appliance wird über zwei Ports an die Messtechnik, den Spirent Avalanche und Reflector, angeschlossen.

Als Frame-Formate haben wir hier 512, 1024 und 1518 Byte verwendet. Die Messtechnik simuliert so die Kommunikation zwischen Client-Systemen im internen Netzwerk und Servern in der DMZ und protokolliert das Verhalten der Appliance. Astaros Security-Gateway-220 erreichte eine Connection-Setup-Rate von 8000 und eine Connection-Capacity von 432 369. Die gemessenen Durchsatzwerte lagen zwischen 96,3 MBit/s bei den 1518 Byte großen und 93,68 MBit/s bei den 512 Byte großen Frames.

Clavisters SG-3150 vermochte sogar 15 000 Sessions pro Sekunde aufzubauen.Mit einer Connection- Capacity von 126 210 liegt sie zwar deutlich unter dem Astaro-System, bietet aber absolut immer noch eine hohe Zahl an möglichen Verbindungen.Der maximal erreichbare Durchsatz liegt zwischen 96,23 und 93,67 MBit/s und erreicht somit fast die gleichen Werte wie Astaro.

Die Bintec-VPN-Access-250 schaffte eine Connection-Setup-Rate von 5000. Die Connection- Capacity des Funkwerk-Systems lag bei vergleichsweise geringen 16 734 Verbindungen. In der Durchsatzmessung vermochte die Bintec- Appliance mit Astaro und Clavister gleichzuziehen. Sie kam hier auf Werte zwischen 96,35 und 93,7 MBit/s.

Der Firewall-Server von Gateprotect erreichte eine Connection-Setup-Rate von 8000 und konnte so mit Astaro mithalten. Die maximale Connection-Capacity lag dagegen bei »nur« 64 416. In der Disziplin Durchsatz herrscht dagegen Gleichstand. Das Gateprotect-System schaffte je nach Frame-Format zwischen 96,36 und 93,67 MBit/s.

Lucents Brick-150 vermochte 10 000 Connections pro Sekunde aufzubauen und maximal 195 709 Verbindungen gleichzeitig zu halten. Im Durchsatz konnte das Lucent-System mit dem übrigen Mitbewerb mithalten.Die Brick erreichte hier Bandbreiten zwischen 96,3 und 93 MBit/s. Mit einer Connection-Setup-Rate von 3000 fällt OSST hinter dem Feld zurück. Die Connection- Capacity lag dagegen bei 236 270 Verbindungen, also noch über der Leistung des Lucent-Systems. Im Durchsatz konnte das OSST-System dagegen mit dem Feld mithalten; es schaffte Werte zwischen 96,26 und 93,6 MBit/s.

Rimapps Roadblock-CF401U liegt mit einer Connection-Setup-Rate von 9000 im Mittelfeld. Die Connection-Capacity von 627 778 Verbindungen ist dagegen der höchste Messwert in dieser Disziplin in unserem Testfeld.Und auch beim Durchsatz vermochte Rimapp dem Feld zu folgen. Das Rimapp-System erreichte Durchsatzwerte zwischen 95,87 und 93,2 MBit/s.

Telcotechs Liss-II erreichte mit einer Connection- Setup-Rate von 11 000 einen guten zweiten Platz im Testfeld.Mit einer Connection-Capacity von 130 912 liegt sie dagegen hinter dem Testfeld. In der Durchsatzmessung konnte die Liss-II dagegen mit dem Feld mithalten. Sie schaffte Werte zwischen 96,3 und 93,68 MBit/s.

Dass Zycels Zywall 5 gegenüber dem Testfeld zurück fällt, zeigen auch die TCP-Messwerte.Die Zywall erreichte eine Connection-Setup-Rate von 500 Sessions pro Sekunde und eine Connection- Capacity von 5999. Bei den Durchsatzmessungen blieb das System als einziges im Testfeld deutlich unter 90 MBit/s. Die Werte schwanken zwischen 49,47 und 21,43 MBit/s.

VPN-UDP-Durchsatz

In unserer vierten Messreihe haben wir den VPNUDP- Durchsatz ermittelt.Hierzu haben wir zwei identische Appliances miteinander verbunden. Dann haben wir den Smartbits-Lastgenerator/ Analysator über jeweils einen Port an beide Appliances angeschlossen, so dass wir erneut eine Zangenmessung durchführen konnten. Die Smartbits generierten dann Flows aus UDP-Paketen jeweils mit konstant 64, 512 und 1024 Byte Größe. Die Last beginnt auch hier wieder mit 10 Prozent und wird dann in 10-Prozent- Schritten bis auf 100 Prozent erhöht. Der Aufbau des VPNs erfolgt zwischen den beiden Appliances.

Standardmäßig wurde das VPN durch AES-256-Verschlüsselung realisiert. War das Testgerät entgegen unserer Anforderungen dazu nicht in der Lage, haben wir das VPN mit 3DES-Verschlüsselung realisiert, was bei den Teststellungen von OSST und Rimapp erforderlich war.Die Belastung des VPN-Systems erfolgte erst uni- und dann bidirektional, das heißt beide Ports sendeten und empfingen gleichzeitig maximal mit Wirespeed.

Gemessen haben wir wieder Frame-Loss, Latency und Jitter.Aus den ermittelten Frame-Loss- Werten errechnen sich die Werte für den maximalen Durchsatz. Dieser ist der maximal mögliche Durchschnittswert aller Flows bei einem Frame-Loss von kleiner 1 Prozent. Darüber hinaus bewerten wir hier das Verhalten der Systeme bei Volllast und im bidirektionalen Modus die Fairness, mit der die verschiedenen Flows behandelt werden.

Mit 95 MBit/s verfehlt Astaros Security-Gateway- 220 bei der unidirektionalen Messung mit 1024-Byte-Paketen nur knapp die Wirespeed.Bei der Messung mit 512 Byte großen Paketen schaffte das System dann noch 85 MBit/s. Schwierigkeiten hatte das Astaro-System dann wieder mit den kleinen 64-Byte-Paketen. Hier waren maximal 14 MBit/s möglich. Unter Volllast schrumpfte diese Bandbereite dann auf ganze 1,72 MBit/s zusammen.Verwendeten wir die größeren Frames, blieb das Gerät auch bei Volllast stabil und schaffte rund 95 beziehungsweise gut 82 MBit/s.Bidirektional gingen die pro Flow erreichbaren Bandbreiten dann weiter zurück.

So waren hier bei Verwendung des größten Frame- Formats noch maximal 71, beim mittleren Format 48 und bei den kleinen Frames noch 8 MBit/s möglich. Unter Volllast reduzierten sich die Durchsätze dann auf 48 beziehungsweise rund 19 MBit/s für die großen und die mittleren Frames. Bei der bidirektionalen Messung mit 64- Byte-Frames machte die Astaro dann praktisch ganz dicht.Hier war noch ein Durchsatz von 0,01 MBit/s messbar. Signifikante Unterschiede in der Fairness gab es zwischen den beiden Senderichtungen im bidirektionalen Betrieb nicht. Beiden Flows standen praktisch die gleichen Bandbreiten zur Verfügung.

Unidirektional und mit den großen Frames machte auch die Clavister-SG-3150 eine gute Figur und verfehlte die Wirespeed nur knapp.Auch sie erreichte hier einen maximalen Durchsatz von 95 MBit/s. Bei den mittelgroßen Frames reichte es dann im unidirektionalen Betrieb noch für 76 MBit/s. Sendeten wir 64-Byte-Frames schaffte das System noch einen maximalen Durchsatz von 17 MBit/s. Diese Bandbreiten standen dann aber auch noch bei Volllast zur Verfügung.

Im bidirektionalen Betrieb halbierten sich die möglichen Durchsätze nahezu. Standen bei der Messung mit den 1024-Byte Frames noch maximal 52 MBit/s zur Verfügung, so reduzierten sich die Werte bei 512-Byte-Paketen auf 37 MBit/s und bei 64-Byte-Paketen auf 8 MBit/s. Diese Durchsätze waren dann aber auch noch bei Volllast realisierbar.Bei der Beurteilung der Fairness fällt eine Benachteiligung der Senderichtung intern – remote auf. So war hier bei der Messung mit den großen Frames ein Frame-Loss von fast 52 Prozent zu messen, in der Gegenrichtung betrug der Frame-Loss dagegen nur gut 46 Prozent.

Etwas hinter dem Hauptfeld lag die Bintec- VPN-Access-250 von Funkwerk.Unidirektional schaffte sie mit den größten Frames einen Durchsatz von 85 MBit/s. Bei der gleichen Messung mit 512-Byte-Paketen stand dann noch eine Bandbreite von 67 MBit/s zur Verfügung.Verwendeten wir die kleinsten Pakete, reduzierte sich die Bandbreite auf 21 MBit/s. Diese Bandbreiten standen dann aber auch noch bei Volllast zur Verfügung.

Im bidirektionalen Betrieb reduzierte sich dann die verfügbare Bandbreite je Flow um ganze 50 Prozent, was eine maximale Bandbreite von 43 MBit/s bei den größten und von 10 MBit/s bei den kleinsten Frames bedeutet. Auch diese Bandbreiten waren unter Volllast noch nutzbar.

Weiterhin hat die Bintec-Appliance die verfügbare Bandbreite im bidirektionalen Betrieb immer sehr fair zwischen beiden Flows aufgeteilt. Nahezu Wirespeed erreichte Gateprotects Firewall-Server bei der unidirektionalen Messung mit den größten Flows, hier stand eine Bandbreite von 96 MBit/s zur Verfügung.Verwendeten wir 512-Byte-Frames, reduzierte sich die Bandbreite auf 91 MBit/s. Probleme hatte dann auch das Gateprotect-System mit den 64-Byte-Paketen. Hier ging die Bandbreite auf 26 MBit/s zurück.

Im bidirektionalen Betrieb schaffte der Firewall- Server bei der Messung mit den 1024-Byte- Frames gleichfalls 96 MBit/s. Verwendeten wir die 512-Byte-Pakete, reduzierte sich die Bandbreite auf 66 MBit/s je Flow.Und als wir die Messung mit 64-Byte-Paketen wiederholten waren nur noch 13 MBit/s möglich.Unter Volllast und mit 64-Byte-Paketen verringerte sich die Bandbreite dann nochmals, hier waren unidirektional noch rund 18 und bidirektional nur noch 0,33 MBit/s je Flow möglich.

Auch Lucents VPN-Firewall-Brick-150 kam unidirektional und mit größeren Frames recht gut zurecht. So schaffte die Brick-150 bei der Messung mit 1024-Byte-Paketen einen Durchsatz von 95 MBit/s, verwendeten wir 512-Byte-Pakete, betrug die Bandbreite noch 91 MBit/s. Bei den kleinsten Frames reduzierte sich die Bandbreite dann auf 37 MBit/s. Diese Bandbreiten standen dann auch noch unter Volllast zur Verfügung.

Der Wechsel in den bidirektionalen Betrieb reduzierte deutlich die verfügbaren Bandbreiten je Flow. Bei der Messung mit den größten Frames betrug die maximale Bandbreite noch 64 MBit/s, verwendeten wir 512-Byte-Frames, standen noch 51 MBit/s zur Verfügung und bei den kleinsten Frames verringerte sich die Bandbreite je Flow auf 17 MBit/s. Davon blieben unter Volllast dann nur noch 0,23 MBit/s übrig.Und auch bei den Messungen mit den größeren Frames verringerte sich die Bandbreite unter Volllast weiter. Waren die Frames 1024 Byte groß, blieb hier eine Bandbreite von gut 50 MBit/s übrig.Mit 51 MBit/s erreichte die OSST-Appliance bei der unidirektionalen Messung mit den größten Frames ihren Bestwert.Verwendeten wir die 512-Byte-Pakete, schaffte das System noch 26 MBit/s und bei den kleinsten Frames standen noch 3 MBit/s Bandbreite zur Verfügung.

Davon blieben dann unter Volllast noch 0,24 MBit/s übrig.Aber auch bei den Messungen mit den größeren Frames reduzierte sich die mögliche Bandbreite unter Volllast weiter. So schaffte das OSST-System bei der Messung mit den größten Frames noch gut 36 MBit/s. Der Wechsel in den bidirektionalen Betrieb reduzierte die verfügbare Bandbreite je Flow noch einmal deutlich.

So waren noch maximale Bandbreiten von 25 MBit/s bei den größten Frames und 2 MBit/s bei Verwendung der kleinsten Frames möglich. Unter Volllast blieben davon noch rund 19 beziehungsweise 0,2 MBit/s je Flow übrig.Mit der Fairness hat es das OSST-System dann auch nicht besonders genau genommen. So betrug der Frame-Loss im bidirektionalen Modus bei der Messung mit den 1024-Byte-Frames für den Flow intern – remote 63,47 Prozent, in der Gegenrichtung verlor das System zugleich 99,2 Prozent aller Daten.

Volle Wirespeed erreichte die Rimapp-Roadblock- CF401U bei der unidirektionalen Messung mit den 1024-Byte-Frames.Verwendeten wir 512- Byte-Frames, reduzierte sich die maximale Bandbreite auf 86 MBit/s und bei der Messung mit den 64-Byte-Paketen waren noch 21 MBit/s möglich.Unter Volllast blieben davon dann noch rund 3 MBit/s übrig.Haben wir größere Frames verwendet, kam die Rimapp-Roadblock auch bei Volllast deutlich besser zurecht. So schaffte sie bei der Messung mit 512-Byte-Paketen gut 95 MBit/s. Der Wechsel auf bidirektionalen Betrieb reduzierte auch hier die möglichen Bandbreiten.

So standen bei der Messung mit den größten Frames noch 80 MBit/s je Flow zur Verfügung.

Verwendeten wir 512-Byte-Pakete, schaffte das System noch 44 MBit/s und bei der Messung mit den kleinsten Frames betrug der maximal möglich Durchsatz 8 MBit/s.Unter Volllast reduzierte sich dann bei der Messung mit den kleinsten Frames der Durchsatz bis auf gut 1,5 MBit/s. Deutliche Probleme hatte das Rimapp-System mit der Fairness. So betrug der Frameloss bei der Messung mit 512-Byte-Paketen für den Flow intern – remote rund 19 Prozent, in der Gegenrichtung gingen zugleich gut 93 Prozent aller Daten verloren.

Wirespeed verfehlte Telcotechs Liss-II bei der uni- wie der bidirektionalen Messung mit den 1024-Byte-Paketen mit 96 MBit/s nur knapp.Waren die Frames 512 Byte groß, schaffte das System noch 91 MBit/s uni- und 90 MBit/s bidirektional je Flow. Erst bei den Messungen mit den kleinsten Frames war ein deutlicher Unterschied zwischen dem uni- und dem bidirektionalen Betrieb feststellbar.Hier stehen sich die Maximalbandbreiten von 26 MBit/s für unidirektional und 14 MBit/s für bidirektional gegenüber.

Unter Volllast reduzierten sich die Durchsätze bei den Messungen mit den kleinsten Frames dann noch mal.Hier waren unidirektional noch rund 4,7 und bidirektional nur noch 0,02 MBit/s möglich. Bei den Volllastmessungen mit größeren Frames hielt sich die Liss-II deutlich besser. So schaffte sie bidirektional mit 512- Byte-Paketen je Flow gut 75 MBit/s.Und bei der Messung mit den größten Frames blieb der Durchsatz je Flow bei rund 96 MBit/s.

Zycels Zywall 5 erwies sich auch in unserem VPN-Szenario als unterdimensioniert. So schaffte sie unidirektional bei der Messung mit den größten Frames gerade 22 MBit/s.Bidirektional stand noch eine Bandbreite von 12 MBit/s zur Verfügung.Bei den Messungen mit 512-Byte-Paketen waren dann noch 11 beziehungsweise 6 MBit/s möglich.Verwendeten wir die kleinsten Flows, gingen gerade noch rund 1 MBit/s je Flow über die Leitungen.Unter Volllast hat sich an diesen Bandbreiten dann auch nichts wesentliches mehr geändert.

Fazit

Das noch recht moderate Abschneiden der meisten Fast-Ethernet-Appliances in unserer Report- Card sollte nicht darüber hinweg täuschen, dass alle Systeme mehr oder weniger stark ausgeprägt ihr Ziel verfehlten.Auch wenn alle Testgeräte viele Connections aufbauen und halten können nutzt das nicht viel, wenn sie die anvisierten Bandbreiten nicht durchgängig für alle Frame- Formate bieten können.Früher oder später wird jede Security-Appliance zum Flaschenhals. Spätestens wenn es gilt, im Firewall- oder VPN-Betrieb viele kleine Frames unter hoher Last bidirektional zu verarbeiten, ist die theoretische Wirespeed und somit der Anspruch der Hersteller, Security-Appliances als transparente aktive Netzwerkkomponenten einzubinden, meist um Lichtjahre entfernt.

Generell gilt, dass die Security-Appliances umso stärker schwächelten, um so mehr Rechenarbeit sie leisten mussten.UDP-Ströme aus 64-Byte- Frames überforderten praktisch alle Systeme sowohl im Firewall- als auch im VPN-Betrieb. Aber auch größere Pakete wurden bei weitem nicht immer in Wirespeed verarbeitet. Insgesamt vermochte sich Telchotech mit ihrer Liss-II wenn auch relativ knapp vor dem Feld durchzusetzen und die Auszeichnung »Referenz« zu gewinnen.

Hervorzuheben ist noch Lucent, deren Brick-150 durch ihren günstigen Preis und ihren recht guten dritten Platz zu überzeugen, was ihr die »Preis-Leistungs-Empfehlung« sichert. Schließlich kostet diese Lösung nur knapp halb so viel, wie die erstplatzierte. Die letztplatzierte Zyxel- Zywall 5 war dagegen für unser Szenario schlicht unterdimensioniert und spielt auch preislich in einer anderen Liga als das übrige Testfeld. Für andere Einsatzzwecke kann sie durchaus eine attraktive Wahl sein.

Zur verbreiteten Performance-Schwäche kommt hinzu, dass Priorisierungsmechanismen in aktuellen Security-Appliances wenn überhaupt nur sehr rudimentär implementiert sind. Das macht den Einsatz in modernen Netzwerken, die Daten,Voice-over-IP und Video-over-IP zugleich transportieren sollen, problematisch. Schafft eine Security-Appliance keine Wirespeed und unterstützt sie auch die Priorisierungsmechanismen nicht ausreichend, dann ist die Integration der IP-Telefonie nicht machbar.Manche ITVerantwortliche leiten daher die Sprachanwendungen um die Security-Systeme herum und riskieren so ein neues, unkalkulierbares Sicherheitsloch.

Der Grund für die schlechte Performance aktueller Security-Appliances liegt darin, dass die Hersteller viel Funktionalität letztendlich in Software abbilden und die zu Grunde liegende Hardware dann häufig schlicht überlastet ist. So lange die Hersteller ihre Systeme nicht wirklich performant auslegen, ist es für einen reibungslosen Netzwerkbetrieb unerlässlich, dafür zu sorgen, dass die Systeme gar nicht erst an ihre Grenzen gelangen.Dies setzt die genaue Kenntnis der Leistungsfähigkeit der eingesetzten Systeme und der Lasten im Netz voraus.Nur dann ist ein intelligentes Bandbreitenmanagement möglich, das hilft, Performance-Probleme und somit Störungen im Netz zu vermeiden.Voraussetzung dafür ist aber, dass die Systeme auch ein entsprechendes Bandbreitenmanagement unterstützen.

Dieser Frage werden wir in unseren Labs weiter nachgehen.

Dipl.-Ing. Thomas Rottenau,
Prof. Dr. Bernhard G. Stütz,
dg@networkcomputing.de