Site icon bintorosoft.com

Performance-Engineering für NGFW: Throughput, CPS und Session Tables

Red Snapper

Performance-Engineering für NGFW ist heute eine Kernkompetenz im Network Security Betrieb, weil moderne Next-Gen Firewalls nicht nur „Ports filtern“, sondern Applikationen erkennen, TLS entschlüsseln, Threat Prevention ausführen, Logs erzeugen und oft auch VPN- oder ZTNA-nahe Funktionen bereitstellen. In vielen Projekten wird Performance dabei zu spät betrachtet: Das neue Regelwerk ist sauber, die Security-Profile sind aktiv, TLS/SSL Inspection ist eingeschaltet – und plötzlich steigen Latenzen, Sessions brechen ab oder die Dataplane läuft in die Begrenzung. Häufig liegt das nicht an einem einzelnen Fehler, sondern an einem Missverständnis der wichtigsten Leistungskennzahlen: Throughput (wie viel Datenvolumen pro Zeit), CPS (Connections per Second, also neue Sessions pro Sekunde) und Session Tables (wie viele gleichzeitige Sessions der State-Table). Wer das Hauptkeyword „Performance-Engineering für NGFW“ professionell umsetzt, arbeitet deshalb nicht mit Marketing-Durchsatzwerten, sondern mit belastbaren Lastprofilen, klaren Messpunkten und einem Design, das Security-Features dort einsetzt, wo sie den höchsten Nutzen bringen. Dieser Artikel erklärt, wie Throughput, CPS und Session Tables zusammenhängen, welche Engpässe in der Praxis wirklich zählen und wie Sie NGFW-Performance planen, testen, überwachen und optimieren – ohne Sicherheitsziele zu verwässern.

Warum NGFW-Performance anders ist als „klassischer Firewall-Durchsatz“

Bei einer NGFW ist der Paketpfad nicht mehr nur „Match auf 5-Tuple und forward“. Je nach Policy kann eine Session zusätzliche Schritte durchlaufen: App-ID, User-ID, URL-Filter, IPS, Malware-Scanning, SSL-Inspection, DLP oder Decryption-Bypass-Logik. Jeder zusätzliche Schritt kostet CPU, Speicher, ggf. ASIC/NP-Ressourcen und erhöht die Latenz. Deshalb ist ein hoher „Max Throughput“-Wert aus dem Datenblatt nur bedingt aussagekräftig: Er gilt oft unter idealisierten Bedingungen (große Pakete, wenige Sessions, keine oder minimale Inspection).

In der Praxis müssen diese drei Größen gemeinsam betrachtet werden, sonst entstehen Designs, die „auf dem Papier“ passen, aber unter Realtraffic instabil sind.

Die drei Hauptkennzahlen: Throughput, CPS und Session Tables

Throughput: Volumen pro Zeit

Throughput wird meist in Gbit/s angegeben. Er hängt stark von Packet Size und Feature Set ab. Ein System kann bei großen Paketen (z. B. 1518 Byte) sehr hohe Werte erreichen, bei kleinen Paketen aber deutlich einbrechen. Wichtig ist außerdem, ob Throughput „Firewall only“, „Threat Prevention on“, „TLS Decryption on“ oder „App-ID/URL Filtering on“ gemessen wurde.

CPS: Connections per Second

CPS ist die Anzahl neuer Sessions pro Sekunde. Moderne Anwendungen erzeugen viele kurzlebige Verbindungen: Webbrowser, APIs, Service Mesh, Cloud-Native Anwendungen, Telemetrie und DNS-over-HTTPS. CPS belastet vor allem den Sessionaufbau: Policy Lookup, NAT-Entscheidung, App-ID-Initialphase, ggf. TLS Handshake, Logging-Entscheidungen. Ein CPS-Engpass zeigt sich oft als sporadisches „Alles wird langsam“ oder als Session-Setup-Failures, obwohl Throughput noch niedrig ist.

Session Tables: Concurrent Sessions

Die Session Table hält Zustandsinformationen für stateful inspection (z. B. TCP state, NAT mapping, timers, ggf. App-ID state). Wenn die Tabelle voll läuft oder stark fragmentiert, werden neue Sessions abgewiesen oder alte aggressiver geaged. Typische Symptome sind scheinbar zufällige Verbindungsabbrüche oder intermittierende Probleme bei großen Nutzerzahlen.

Wie die Kennzahlen zusammenhängen

Ein hilfreiches mentales Modell: Throughput ist das „Wasser“, CPS ist die „Anzahl der Wasserhähne“, und die Session Table ist die „Anzahl der gleichzeitig offenen Hähne“. Sie können viel Volumen mit wenigen, langen Flows erreichen (hoher Throughput, niedriger CPS), oder sehr viele kurze Sessions mit wenig Volumen (hoher CPS, niedriger Throughput). NGFWs müssen beides können – aber meist nicht gleichzeitig am Maximum.

Lastprofile statt Datenblatt: So bestimmen Sie Ihre reale NGFW-Last

Performance-Engineering beginnt nicht auf der Firewall, sondern bei der Beschreibung des Traffics. Ohne Lastprofil werden Kapazitäten geraten. Ein pragmatisches Vorgehen:

Flow-Daten (NetFlow/IPFIX), Firewall-Statistiken und Applikationsmetriken ergänzen sich hier ideal. Wenn Sie nur „Bandbreite“ betrachten, unterschätzen Sie CPS typischerweise massiv.

Feature-Kosten verstehen: Was Performance wirklich frisst

In NGFWs sind einige Funktionen besonders „teuer“. Das heißt nicht, dass man sie nicht nutzen sollte – aber man muss sie bewusst platzieren.

Ein bewährtes Prinzip ist „selektive Tiefe“: maximale Inspection auf riskanten Pfaden (DMZ, Admin, kritische Egress-Targets), minimale notwendige Inspection auf High-Volume-Pfaden (z. B. internes Streaming oder große Backups) – aber immer mit klaren Egress- und Segmentierungsregeln.

Policy- und Architekturentscheidungen mit Performance-Wirkung

Zonenmodell und Rule Order

Ein sauberes Zonenmodell reduziert unnötige Policy Checks und vereinfacht Troubleshooting. Innerhalb von Zonenpfaden hilft eine sinnvolle Rule Order, häufige Pfade früh zu matchen. Das ist nicht nur Wartbarkeit, sondern Performance, weil weniger komplexe Matches nötig sind.

NAT und Session-Design

NAT kann Session Tables stark belasten, insbesondere bei PAT (Port Address Translation) mit vielen Clients. Wenn ein NAT-Gateway sehr viele kurze Sessions erzeugt, kann CPS schneller zum Engpass werden als Bandbreite. Planen Sie NAT-Pools, Port-Allocation-Strategien und Monitoring der NAT-Exhaustion bewusst ein.

Asymmetrie vermeiden

Stateful Firewalls mögen symmetrische Pfade. Asymmetrischer Traffic (Hinweg über Firewall A, Rückweg über Firewall B) erzeugt Drops oder erfordert komplexe Designs. Performance-Engineering umfasst daher auch Routing- und HA-Design.

Session Tables im Detail: Timer, Aging und typische Engpässe

Viele Performanceprobleme entstehen nicht durch „zu wenig CPU“, sondern durch Session-Table-Druck. Drei Mechanismen sind in der Praxis entscheidend:

Best Practice ist, Timeout-Profile an den tatsächlichen Use Case anzupassen, statt Standardwerte unangetastet zu lassen. Das muss jedoch sorgfältig getestet werden, weil zu aggressive Timeouts legitime Anwendungen stören können.

CPS-Engineering: Wenn Verbindungsaufbau der Flaschenhals ist

CPS-Probleme sind oft schwerer zu erkennen, weil Throughput-Metriken „gut aussehen“, während Nutzer trotzdem Timeouts erleben. Typische CPS-Treiber:

Performance-Engineering heißt hier häufig: Decryption selektiv einsetzen, teure Security-Profile auf CPS-intensiven Low-Risk-Pfaden minimieren, und vor allem die Plattform so dimensionieren, dass Peak-CPS nicht in die Nähe der Obergrenze kommt.

Throughput-Engineering: Wenn Volumen dominiert

Bei Throughput-lastigen Workloads (Backups, große Downloads, Replikation) sind andere Faktoren entscheidend:

Ein häufiger Fehler ist, High-Volume-Traffic durch die NGFW zu zwingen, obwohl er nicht an einer Trust Boundary liegt. Segmentierungsdesign und Routing-Architektur sind damit Teil des Performance-Engineerings.

Testing: Wie Sie NGFW-Performance realistisch testen

Labor-Tests können sehr hilfreich sein, wenn sie realistische Profile abbilden. Reine „iperf“-Tests mit großen Paketen sagen wenig über CPS und Session Tables aus. Ein robustes Testdesign umfasst:

Wichtig ist, dass Sie Tests nicht nur auf „Maximalwerte“, sondern auf stabile Betriebsbereiche ausrichten: Ein Design ist gut, wenn es bei Peak-Last stabil bleibt und Reserven hat.

Observability: Welche Metriken Sie im Betrieb dauerhaft brauchen

Performance-Engineering ist nicht abgeschlossen, wenn die NGFW live ist. Workloads ändern sich, SaaS-Endpoints wechseln, neue Applikationen kommen hinzu. Sie brauchen daher ein Monitoring-Set, das frühzeitig Trends zeigt:

Performance-Tuning ohne Sicherheitsverlust: Praktische Stellschrauben

Wenn Engpässe auftreten, ist die beste Reaktion selten „Feature aus“. Besser ist ein geordnetes Tuning entlang von Risiko und Traffic-Klasse.

Decryption selektiv und kategoriebasiert

Logging richtig dimensionieren

Policy Hygiene: weniger Komplexität, weniger Fehler

Dimensionierung: Reserven einplanen statt „auf Kante nähen“

NGFWs sollten nicht dauerhaft nahe an Grenzwerten betrieben werden. Peak-Reserven sind entscheidend, weil Lastspitzen oft mit Sicherheitsereignissen zusammenfallen (z. B. Scans, Incident Response, DDoS-nahe Muster). Ein pragmatischer Ansatz:

HA und Skalierung: Active/Passive, Active/Active und Cluster

High Availability beeinflusst Performance und Verhalten bei Failover. In Active/Passive-Designs läuft die Last meist auf einem System; das zweite ist Reserve. In Active/Active- oder Cluster-Designs kann Last verteilt werden, aber State-Synchronisation und Asymmetrie müssen sauber gelöst sein.

Typische Fehlerbilder und schnelle Diagnosepfade

Praktische Checkliste: Performance-Engineering für NGFW im Alltag

Outbound-Quellen für Standards und vertiefende Grundlagen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version