Site icon bintorosoft.com

QoS bei NAT und Firewalls: Wo Markierungen verloren gehen

Red Snapper

QoS bei NAT und Firewalls ist einer der häufigsten Gründe, warum Voice & Video trotz sauberer Markierung im LAN plötzlich an Qualität verlieren – und zwar oft genau an der Stelle, an der Unternehmen und Telcos aus Sicherheitsgründen am strengsten sind. In vielen Netzen wird DSCP (EF für Voice, AF für Video) korrekt gesetzt, die WAN- oder Backbone-Queues sind sauber konfiguriert, und trotzdem ruckeln Videokonferenzen oder Voice knackt zu Peak-Zeiten. Der Grund liegt häufig nicht in fehlender Bandbreite, sondern darin, dass Markierungen an NAT-Gateways, Firewalls, Session Border Controllern (SBC), Proxies oder Security-Stacks verändert, entfernt oder schlicht nicht weitergegeben werden. Zusätzlich können Firewalls durch Inspection, TLS-Termination oder Policy-Layer Latenz und Jitter erhöhen, selbst wenn Markierungen erhalten bleiben. Professionelles QoS in Netzen mit NAT und Firewalls bedeutet daher: genau wissen, wo Markierungen verloren gehen, Trust Boundaries bewusst setzen, QoS-Regeln auf den Security-Geräten korrekt implementieren (inklusive DSCP-Preservation oder kontrolliertem Remarking) und das Scheduling an den echten Engpässen so gestalten, dass Echtzeittraffic auch dann stabil bleibt, wenn Security-Funktionen Last erzeugen. Dieser Artikel erklärt praxisnah, wo NAT und Firewalls QoS-Markierungen typischerweise beschädigen, wie Sie das vermeiden und wie Sie Voice & Video durch Security-Zonen bringen, ohne Qualität zu opfern.

Warum NAT und Firewalls QoS so oft „entwerten“

QoS funktioniert über zwei Dinge: Markierung (DSCP/CoS/TC) und Behandlung (Queues, Scheduler, Shaping). NAT und Firewalls sitzen häufig an genau den Stellen, an denen Engpässe entstehen: Internet-Uplinks, Edge-Router, VPN-Gateways, Interconnects, DC-Edges. Wenn dort Markierungen verloren gehen, sieht das Underlay oder der nächste Hop nur noch Best Effort – selbst wenn der Rest des Netzes perfekt gebaut ist.

Zusätzlich kommt hinzu: Selbst wenn DSCP erhalten bleibt, kann Security-Processing die Paketlaufzeit variabler machen (Jitter), weil CPU und Session-State unter Last schwanken.

DSCP bleibt DSCP – aber Security-Geräte handeln oft „policy-driven“

Technisch ist DSCP ein Feld im IP-Header. NAT ändert IP-Adressen und Ports, nicht DSCP. Warum geht DSCP dann trotzdem verloren? Weil viele Security-Plattformen DSCP als Teil ihrer Policy- und Sicherheitslogik behandeln:

Für Voice & Video ist das kritisch, weil Echtzeit nicht nur „irgendein DSCP“ braucht, sondern eine konsistente End-to-End-Behandlung an Engpässen.

Typische Stellen, an denen Markierungen verloren gehen

In der Praxis gibt es wiederkehrende „Hotspots“, an denen DSCP/CoS häufig beschädigt wird:

Diese Punkte sind meist zugleich Engpasspunkte. Das macht DSCP-Verlust dort besonders schädlich.

NAT und QoS: Was NAT verändert und was es indirekt auslöst

NAT verändert Quell-/Zieladressen und häufig Ports. DSCP wird dabei nicht zwangsläufig geändert – aber NAT führt zu zwei indirekten QoS-Problemen:

Best Practice ist deshalb, QoS möglichst über DSCP und Trust Boundary zu steuern – nicht über fragile Portlisten, die NAT und moderne Applikationen (SRTP, QUIC, dynamische Ports) schnell aushebeln.

Firewalls und QoS: Markierung erhalten ist nicht genug

Viele Teams freuen sich, wenn „DSCP nicht genullt wird“. Das ist aber nur die halbe Miete. Denn wenn die Firewall selbst ein Engpass wird, muss sie QoS auch intern anwenden: Queueing, Scheduling und ggf. Shaping am Egress.

In der Praxis sind Firewalls bei Peak-Events oft congested: DDoS-Filterung, TLS-Inspection, Log-Spitzen, große Updates. Genau dann braucht Echtzeit eine Low-Latency-Behandlung – sonst knackt Voice „trotz QoS im Netz“.

Inspection, TLS und App-Control: Wie Security Jitter erzeugt

Auch ohne DSCP-Verlust kann eine Firewall Voice & Video verschlechtern, weil Deep Packet Inspection und Verschlüsselung/Entschlüsselung die Laufzeit variiert. Typische Ursachen:

Das erklärt typische Symptome: Voice ist meist ok, aber knackt kurz bei Peak-CPU oder bei aktivierten Security-Profilen. In solchen Fällen ist QoS-Feintuning allein nicht genug – Sie brauchen Performance- und Kapazitätsmanagement der Security-Schicht.

SBCs und NAT in Echtzeitdiensten: Markierung muss oft neu gesetzt werden

Bei Voice/UC ist ein wichtiger Sonderfall der Session Border Controller (SBC) oder Media Relay. Diese Systeme terminieren Signalisierung und oft auch Medien. Dadurch entstehen neue Flows, und DSCP muss bewusst neu gesetzt werden.

Wenn Voice hinter einem SBC knackt, prüfen Sie nicht nur WAN-QoS, sondern auch, ob der SBC DSCP korrekt setzt und ob die Firewall/Edge diese Markierungen akzeptiert oder überschreibt.

QoS in Richtung Internet: Realistische Erwartungen

Ein häufiger Irrtum ist, dass DSCP über das öffentliche Internet zuverlässig wirkt. Viele Netze neutralisieren DSCP an Übergängen. Deshalb sollten Sie zwei Dinge trennen:

Für UC/Cloud-Video kann es daher sinnvoll sein, private Interconnects (PNI) oder optimierte Cloud-Edges zu nutzen, statt auf DSCP im offenen Internet zu hoffen.

Designregeln: So verhindern Sie DSCP-Verlust an NAT/Firewalls

Diese Regeln sind vor allem dann wichtig, wenn mehrere Security-Funktionen kombiniert sind (Firewall + IPS + VPN + NAT), weil jede Stufe Markierungen beeinflussen kann.

Typische Fehlerbilder und schnelle Checks

Der schnellste technische Indikator ist meist: DSCP vor der Firewall messen, DSCP nach der Firewall messen, dann Queue-Drops und Queue-Depth am Firewall-Egress anschauen.

Monitoring: Markierungen und Congestion an Security-Edges sichtbar machen

Ohne Monitoring bleiben DSCP-Probleme an Firewalls oft unsichtbar. Sinnvolle Messpunkte sind:

Ein bewährter Betriebssatz lautet: Drops in der Voice-Klasse sind ein Incident – und bei Security-Edges ist die erste Frage, ob DSCP erhalten bleibt und ob die Firewall selbst QoS-behandelt.

Praxis-Blueprint: QoS durch NAT und Firewalls stabil betreiben

Häufige Fragen zu QoS bei NAT und Firewalls

Ändert NAT DSCP automatisch?

Technisch muss NAT DSCP nicht ändern, aber viele NAT-/Firewall-Plattformen setzen DSCP policy-basiert neu oder neutralisieren es aus Sicherheitsgründen. Verlassen Sie sich nicht auf „Default-Verhalten“ – konfigurieren und messen Sie es.

Warum ist QoS nach außen oft „wirkungslos“?

Weil viele Netze DSCP an Übergängen neutralisieren und das öffentliche Internet keine garantierte QoS-Domäne ist. Ihr Ziel sollte sein, QoS bis zur definierten Netzgrenze sauber umzusetzen und Interconnect-/Kapazitätsstrategien für stabile Pfade zu nutzen.

Was ist der häufigste Fehler bei Echtzeit über Firewalls?

DSCP wird entweder genullt oder die Firewall wird unter Last selbst zum Engpass ohne aktive QoS-Queues. Dann hilft das beste Backbone-QoS nicht, weil Voice und Video bereits am Security-Egress in Best Effort warten oder gedroppt werden.

Exit mobile version