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.
- Markierung wird entfernt: DSCP wird auf 0 gesetzt („clear DSCP“), häufig als Sicherheitsstandard.
- Markierung wird überschrieben: Geräte setzen pauschal einen DSCP-Wert für „trusted“ oder „untrusted“ Zonen.
- Markierung wird nicht übernommen: NAT erstellt neue Flows/Packets und übernimmt DSCP nicht automatisch.
- Behandlung ist nicht QoS-aware: Firewall hat zwar DSCP, mappt es aber nicht auf eigene Queues oder hat keine LLQ/CBWFQ-Äquivalente aktiv.
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:
- Default-Sicherheitsprofil: „Markierungen nicht vertrauen“ – daher wird DSCP auf Default gesetzt.
- Zonenlogik: Übergang von „Inside“ zu „Outside“ triggert ein Rewrite (z. B. alles nach außen Best Effort).
- QoS-Feature nicht aktiviert: DSCP wird zwar durchgelassen, aber nicht in QoS-Queues übersetzt; unter Last wirkt es nicht.
- Offload/ASIC vs. CPU-Pfad: Manche Flows laufen über Hardware, andere über CPU; Markierungsbehandlung kann unterschiedlich sein.
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:
- Edge-Firewalls am Internet-Uplink: hier werden DSCP-Werte oft neutralisiert, insbesondere in Richtung Internet.
- Carrier-Grade NAT (CGN) / Enterprise NAT-Gateways: DSCP wird manchmal nicht übernommen oder pauschal gesetzt.
- VPN-Gateways (IPsec/SSL): Outer-Header-Markierung wird neu gesetzt; inneres DSCP ist im Underlay unsichtbar.
- SBC/Media-Relays: Medienpfade werden terminiert und neu aufgebaut; DSCP muss bewusst neu gesetzt werden.
- Proxies/Load Balancer: Termination/Reuse von Sessions kann DSCP verändern oder ungleich behandeln.
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:
- Flow-Neubildung: NAT führt neue Session-States; Policies werden häufig pro Flow neu bewertet und DSCP kann dabei neu gesetzt werden.
- Port-basierte Klassifizierung wird unzuverlässig: Wenn Sie QoS über Port/5-Tuple klassifizieren, kann NAT das Matching erschweren (insbesondere bei PAT).
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.
- Wenn die Firewall nicht congested: DSCP-Preservation kann reichen, weil der nächste Hop die Priorisierung übernimmt.
- Wenn die Firewall congested: Ohne eigene QoS-Queues wird Voice/Video im gleichen Puffer wie Best Effort verzögert oder gedroppt.
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:
- CPU-Pressure: Stateful Inspection, IPS/IDS und TLS-Inspection sind CPU-lastig; Scheduling schwankt, Jitter steigt.
- Fast Path vs. Slow Path: Manche Pakete laufen im Hardware-Fastpath, andere im CPU-Slowpath; das erzeugt Laufzeitvariationen.
- Logging/Telemetry-Spitzen: Log-Drops oder Log-Backpressure können indirekt Paketverarbeitung verzögern.
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.
- Signalisierung vs. Medien: SIP/Control in einer Control-Klasse, RTP/Audio in EF/LLQ.
- Innerhalb des SBC: Medien werden neu aufgebaut; „DSCP übernehmen“ ist nicht automatisch gegeben.
- Provider-/Enterprise-Policies: Viele Betreiber setzen DSCP am SBC bewusst, weil er der kontrollierte Trust-Punkt ist.
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:
- QoS im eigenen Netz: hier können Sie End-to-End innerhalb Ihrer Domäne garantieren, inklusive Firewall/NAT.
- QoS außerhalb: über Peering/Transit ist DSCP oft nicht verlässlich; Stabilität kommt eher durch Kapazität, Pfadwahl, Peering-Strategie und geringe Congestion.
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
- Trust Boundary definieren: Markierungen nur aus kontrollierten Quellen akzeptieren (Managed CPE, SBC, UC-Server); untrusted Quellen remarken.
- DSCP-Preservation explizit konfigurieren: nicht davon ausgehen, dass Geräte DSCP automatisch durchlassen.
- Normalisierung statt „alles durch“: Kundenmarkierungen auf wenige Klassen mappen (Voice, Video, Control, BE, Background).
- QoS auf dem Security-Gerät aktivieren: Wenn die Firewall der Engpass sein kann, braucht sie eigene Queues (LLQ für Voice, gewichtete Video-Klasse).
- Policing auf Echtzeit vermeiden: Drops auf EF erzeugen Knacken; Oversubscription lieber durch Profile und Shaping abfangen.
- Shaping an rate-limitierten Links: Bursts glätten, Drop-Cluster reduzieren – besonders am Internet-Uplink.
- Segmentierung von Echtzeitpfaden: Wenn möglich, Echtzeit durch weniger Inspection/Proxy-Layer führen (selektiv), ohne Sicherheit zu kompromittieren.
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
- Voice knackt nur bei Internet-Calls: DSCP wird am Edge genullt oder der Engpass ist der Uplink/Firewall; Queue-Drops und Shaping prüfen.
- Video ruckelt bei aktivierter TLS-Inspection: CPU-Pressure und Slowpath; Performance-Profile und Bypass-Regeln prüfen.
- IPv6 besser/schlechter als IPv4: Policies matchen nur einen Stack; DSCP-Handling für v4/v6 vergleichen.
- Nach VPN schlechter: Outer-DSCP nicht korrekt gesetzt; Tunnel-Propagation-Strategie prüfen.
- QoS wirkt intern, nicht extern: Peering/Transit neutralisiert DSCP; Interconnect-Kapazität und Pfadstrategie prüfen.
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:
- DSCP-Ingress/Egress: wird EF/AF unverändert übernommen oder remarkt?
- Traffic pro Klasse: wie viel Premium läuft über die Firewall? Premium-Inflation erkennen.
- Queue-Drops pro Klasse: Drops in Voice sind kritisch; Video-Drops deuten auf Bursts/Weights hin.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko, besonders am Uplink.
- CPU/Session-Health: Security-CPU, Fastpath/Slowpath-Quoten, Session-Table-Auslastung – korreliert mit Jitter.
- QoE-KPIs: MOS/R-Faktor, Jitter/Loss aus RTP/RTCP, Video-Freeze-Events.
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
- Klassenmodell festlegen: Voice EF, Video AF, Control, Best Effort, Background – wenige, klare Klassen.
- Trust Boundary an Security-Edges: untrusted/conditional trust; Markierungen normalisieren.
- DSCP-Preservation/Remarking definieren: pro Zone und Richtung (Inside->Outside, Outside->Inside) klare Regeln.
- QoS auf der Firewall aktivieren: LLQ für Voice mit Limit, Video gewichtet, Best Effort fair.
- Shaping am Uplink: Bursts glätten, Drop-Cluster reduzieren; besonders bei rate-limitierten Links.
- Inspection selektiv planen: Echtzeitpfade so designen, dass Security-Ziele erreicht werden, aber Jitter nicht unnötig steigt.
- Monitoring etablieren: DSCP vor/nach NAT/Firewall, Queue-Drops/Depth, CPU/Session-KPIs, QoE-Korrelation.
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.
