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

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).

• Throughput beschreibt vor allem Volumen – aber sagt wenig über Sessionrate und Feature-Last.
• CPS ist häufig der Engpass bei Web, Microservices und kurzlebigen Verbindungen.
• Session Tables begrenzen, wie viele gleichzeitige Zustände (States) gehalten werden können.

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.

• Hoher Throughput + niedriger CPS: Backups, große Downloads, Video-Streams.
• Niedriger Throughput + hoher CPS: API-Traffic, Web-Apps, Microservices, EDR/Telemetry.
• Hohe Concurrent Sessions: Viele Nutzer gleichzeitig, NAT-Gateways, IoT-Flotten, Chat/Collaboration.

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:

• Topologie festlegen: Welche Zonenpfade laufen über die NGFW (User→Internet, DMZ→App, App→DB, Partner, VPN)?
• Traffic-Klassen definieren: Web/SaaS, East-West, Backup, VoIP/RTC, Admin, IoT.
• Metadaten erfassen: durchschnittliche Paketgröße, Peak-Durchsatz, Peak-CPS, Peak Concurrent Sessions.
• Feature-Mix bestimmen: Welche Flows werden entschlüsselt? Wo läuft IPS? Wo wird geloggt?

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.

• TLS/SSL Inspection: Hoher CPU- und Speicherbedarf durch Handshake, Decryption, Re-encryption. Besonders spürbar bei hohem CPS.
• IPS/Threat Prevention: Deep packet inspection, Signaturmatching, ggf. File/Stream Reassembly.
• URL Filtering / CASB Inline: Zusätzliche Lookups, Klassifikation und Policy-Entscheidungen pro Request.
• Extensives Logging: Hohe Lograte belastet Control Plane/Management Plane und Logpipeline, nicht selten indirekt die Dataplane.
• App-ID und User-ID: Initiale Klassifikation kann bei CPS-lastigen Workloads relevant sein.

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:

• Timeouts pro Protokoll: TCP, UDP und ICMP haben unterschiedliche Idle-Timeouts. Zu lange UDP-Timeouts können die Tabelle füllen.
• Application Idle Patterns: Manche Apps halten viele „semi-idle“ Sessions offen (z. B. Chat, Collaboration, Push).
• Scanning/Noise: Internet-Noise, Portscans und Fehlkonfigurationen erzeugen viele kurze, nutzlose Sessions.

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:

• Web und HTTP/2/HTTP/3 Mischbetrieb: Viele parallele Streams, viele Domain-Auflösungen, viele neue Sessions bei kurzen Requests.
• Microservices: Service-to-Service Kommunikation, oft mit mTLS, erzeugt hohe Handshake-Last.
• Telemetry/EDR: Viele kleine Verbindungen, oft zu Cloud-Endpoints.
• DNS-over-HTTPS / DNS-over-TLS: Zusätzliche TLS-Sessions statt klassischer UDP-DNS.

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:

• Packet Size: Kleine Pakete senken effektiven Durchsatz drastisch; prüfen Sie MSS/MTU, Fragmentation und Tuning.
• Inspection-Placement: Müssen Backups wirklich durch IPS und Decryption? Häufig ist Segmentierung + strikte Ziele + Monitoring sinnvoller.
• Hardware Offload: Je nach Plattform können bestimmte Funktionen beschleunigt werden; aber Offload greift oft nicht bei Decryption.

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:

• Traffic-Mix: Mischung aus großen Flows und CPS-lastigen Web/API-Requests.
• Feature-Mix: Tests mit genau den Security-Profilen, die produktiv aktiv sein sollen (IPS, Decryption, URL Filtering).
• Long-Run Tests: Nicht nur 5 Minuten, sondern mehrere Stunden, um Table-Druck und Memory-Leaks zu erkennen.
• Failover-Tests: HA-Failover unter Last, um Session-Persistence und Recovery zu prüfen.
• Lograte-Tests: Simulieren Sie die echte Loglast; SIEM-Ingestion darf nicht zum Engpass werden.

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:

• Dataplane CPU/ASIC Utilization: getrennt nach Dataplane und Management Plane, wenn möglich.
• CPS aktuell und Peak: mit Trend (7/30/90 Tage) und Alarmierung nahe Grenzwerten.
• Concurrent Sessions: absolute Zahl und Auslastungsgrad der Session Table.
• Session Setup Failures: Drops, SYN cookies, resource drops, „no session available“.
• Decryption KPIs: Decryption Coverage, Failure Rate, Handshake Errors.
• Logpipeline Health: Ingestion Lag, Drops, Parser-Fehler (sonst verlieren Sie Evidence und Detection).

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

• Risk-basierte Kategorien entschlüsseln: File-Sharing, unbekannte Kategorien, nicht genehmigte SaaS.
• Streaming/Low-Risk gezielt ausnehmen: Wenn der Nutzen gering und die Last hoch ist, aber mit Governance (Expiry/Review).
• BYOD getrennt behandeln: Ohne Trust Enrollment eher keine Decryption, dafür restriktivere Zugriffe.

Logging richtig dimensionieren

• Risk-based Logging: Deny, Admin, DMZ, Ausnahmen immer loggen; High-Volume-Standardpfade selektiv.
• Sampling/Rate Limits: Wenn Plattform und Compliance es erlauben, um Log-Stürme zu vermeiden.
• SIEM-Pipeline skalieren: Logdrops sind nicht nur ein SOC-Problem, sondern oft ein Performanceproblem durch Backpressure.

Policy Hygiene: weniger Komplexität, weniger Fehler

• Shadow/Unused Rules entfernen: Reduziert operative Komplexität und verbessert Analyse.
• Objektmodell sauber halten: Vermeidet Mega-Gruppen und unklare Matches.
• Rule Order innerhalb von Sections optimieren: Häufige Regeln nach oben, aber ohne Security-Shadowing.

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:

• Headroom: Planen Sie je nach Kritikalität mindestens 30–50% Reserve auf CPS und Sessions, nicht nur auf Throughput.
• Feature-Reserve: Wenn Sie Decryption perspektivisch ausrollen möchten, dimensionieren Sie dafür, nicht nur für „Firewall-only“.
• Growth: Rechnen Sie mit Traffic-Wachstum durch mehr SaaS, mehr Telemetrie, mehr Verschlüsselung.

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.

• Active/Passive: Einfacher, gut vorhersagbar, aber Kapazität effektiv kleiner.
• Active/Active: Mehr Kapazität, aber höherer Designaufwand (Session ownership, symmetry, failover behavior).
• Scale-out: Sinnvoll bei sehr hohen CPS-Lasten, erfordert konsistentes Policy- und Logging-Design.

Typische Fehlerbilder und schnelle Diagnosepfade

• „Internet langsam, aber Bandbreite niedrig“: CPS-Engpass oder Decryption-Handshake-Last prüfen.
• „Random Disconnects“: Session Table Auslastung, aggressive Timeouts, Asymmetrie oder HA-State-Sync prüfen.
• „Bestimmte Apps brechen“: TLS-Inspection Exclusions/Pinning, QUIC/HTTP3 Handling, Zertifikatskette prüfen.
• „Logs fehlen“: Logpipeline Health, Rate Limits, Parser-Fehler – und ob Logging-Policy zu aggressiv ist.

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

• 1) Lastprofil erstellen: Peak Throughput, Peak CPS, Peak Sessions, Packet Size, Traffic-Klassen.
• 2) Feature-Mix definieren: Wo läuft Decryption, IPS, URL Filtering, Logging?
• 3) Zonenmodell und Policy-Patterns nutzen: Sections, Rule Order, klare Trust Boundaries.
• 4) Tests realistisch aufbauen: CPS + Throughput + Security-Profile + Long-Run + Failover.
• 5) Observability einrichten: CPS, Sessions, Dataplane Utilization, Decryption KPIs, Logpipeline Health.
• 6) Headroom planen: Reserven auf CPS und Sessions, nicht nur auf Durchsatz.
• 7) Tuning risikobasiert: Selektive Decryption, Logging-Strategie, Policy Hygiene.
• 8) Rezertifizierung und Clean-up: Unused Rules, Exclusions und Ausnahmen regelmäßig überprüfen.

Outbound-Quellen für Standards und vertiefende Grundlagen

• RFC 8446 (TLS 1.3) für Protokolldetails, die Decryption-Performance und Kompatibilität beeinflussen können.
• CIS Controls für praxisnahe Mindestkontrollen zu sicherer Konfiguration, Monitoring und Change-Management.
• NIST SP 800-207 (Zero Trust Architecture) als Referenz für kontextbasierte Policies und selektive Kontrollen.
• MITRE ATT&CK zur Strukturierung von Threat-Use-Cases (z. B. C2/Exfiltration), die Performance-Entscheidungen bei Decryption und Logging beeinflussen.

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.