February 26, 2026

QoS über VPN: DSCP Preservation, Marking und Policing

QoS über VPN ist eines der Themen, bei denen Theorie und Praxis besonders häufig auseinanderlaufen: Auf dem Papier sind Sprach- und Videopakete „priorisiert“, in der Realität ruckelt VoIP bei hoher Last, RDP fühlt sich träge an oder ein Backup-Job drückt alles andere weg. Der Grund ist selten „QoS funktioniert nicht“, sondern fast immer ein Design- oder Betriebsfehler entlang der Kette: DSCP wird beim Tunneln nicht korrekt übernommen, Markierungen werden auf einem Zwischenhop überschrieben, Verschlüsselung verhindert eine sinnvolle Klassifizierung hinter dem Gateway, oder Policing am WAN-Uplink schneidet genau die falschen Flows ab. Dazu kommen VPN-spezifische Effekte wie Encapsulation Overhead, MTU/MSS-Themen und eine oftmals zentrale Egress-Architektur (Full Tunnel), die sämtliche Traffic-Klassen auf wenigen Gateways bündelt. Wer QoS im VPN richtig umsetzen möchte, muss daher drei Dinge sauber beherrschen: DSCP Preservation (Markierungen erhalten bzw. bewusst kopieren), Marking (wo, wie und mit welchem Trust-Modell markiert wird) und Policing/Shaping (wie Bandbreite fair verteilt wird, ohne interaktive Anwendungen zu zerstören). Dieser Beitrag erklärt die wichtigsten Design Patterns, typische Fallstricke und ein praxistaugliches Vorgehen, um QoS über IPsec-, SSL/TLS- und Overlay-VPNs zuverlässig zu betreiben.

Table of Contents

Grundlagen: DiffServ, DSCP und warum QoS end-to-end gedacht werden muss

Im Enterprise-Alltag ist QoS meist DiffServ-basiert: Pakete werden in Klassen eingeteilt und über DSCP (Differentiated Services Code Point) markiert. Router, Firewalls und Gateways behandeln diese Klassen unterschiedlich, typischerweise über Queues, Priorisierung und Drop-Strategien. Entscheidend ist: QoS ist nur dann wirksam, wenn die Markierung konsistent über den gesamten Pfad interpretiert wird. Die formalen Grundlagen liefert das DiffServ-Modell (z. B. RFC 2474 und RFC 2475).

Marking: Wer setzt DSCP und nach welchen Regeln?
Trust Boundary: Ab welchem Punkt akzeptieren Sie Markierungen als „vertrauenswürdig“?
Per-Hop Behavior: Wie werden einzelne DSCP-Klassen in Queues abgebildet (z. B. EF für Voice)?
Congestion Point: QoS wirkt nur dort, wo Engpässe entstehen (typisch: WAN-Uplink, Wi-Fi, zentrale Gateways).

Warum VPNs QoS komplizierter machen

Ein VPN verändert nicht nur den Pfad, sondern auch die Sichtbarkeit des Traffics. Bei IPsec (ESP) sind nach der Verschlüsselung L4-Header nicht mehr sichtbar; bei TLS-VPNs ist zwar der Outer Flow sichtbar, aber die ursprüngliche Anwendungsklasse kann durch Encapsulation verschleiert werden. Dazu kommt, dass ein Tunnel zwei „Schichten“ hat: innerer (Originalpaket) und äußerer Header (Transport über das Internet/Underlay).

Inner DSCP: Markierung im Originalpaket (z. B. VoIP RTP als EF).
Outer DSCP: Markierung im Tunnel-/Transportpaket (z. B. ESP über IP oder UDP/4500 bei NAT-T).
Classify-before-encrypt: Viele QoS-Designs müssen vor der Verschlüsselung klassifizieren, weil danach Ports/Signaturen fehlen.
Overhead: Encapsulation erhöht Paketgröße und reduziert effektive Nutzbandbreite; das beeinflusst Shaping und Queue-Dimensionierung.

DSCP Preservation: Was genau muss erhalten bleiben?

„DSCP Preservation“ wird oft als „DSCP darf nicht verändert werden“ verstanden. In der Praxis ist die Frage differenzierter: Wollen Sie die inneren DSCP-Werte unverändert durch den Tunnel transportieren? Wollen Sie diese Werte auf den äußeren Header kopieren, damit das Underlay priorisieren kann? Oder wollen Sie Markierungen am VPN-Gateway neu setzen (remark), weil Sie dem Client nicht vertrauen?

Preserve Inner DSCP: Inneres Paket behält seine DSCP-Werte, sodass nach Entschlüsselung im Zielnetz die Klasse sichtbar bleibt.
Copy Inner→Outer: DSCP wird in den äußeren Tunnelheader übernommen, damit ISP/Underlay priorisieren kann.
Remark at Edge: DSCP wird am Gateway neu gesetzt, basierend auf Policy (User/Group/App), unabhängig vom Client.

Trust Model: Warum „Client darf DSCP setzen“ meist keine gute Idee ist

Das größte Risiko bei QoS ist nicht Technik, sondern Trust: Wenn jeder Client sich selbst als „EF/Voice“ markieren darf, ist Ihre Prioritätsqueue schnell voller Bulk-Traffic. Im VPN ist dieses Risiko besonders hoch, weil Remote-Clients außerhalb Ihrer physischen Kontrolle liegen. Ein robustes Trust-Modell setzt daher klare Grenzen:

Trust nur für Managed Devices: DSCP-Trust nur, wenn Device Posture/MDM/EDR ok ist und der Client aus verwaltetem Kontext kommt.
Trust nur für bestimmte Apps: Markierung wird server- oder gatewayseitig nach Applikation/Port/Policy gesetzt, nicht nach Client-Wunsch.
Privileged vs. Standard: Admin- und Business-critical Traffic kann bevorzugt werden, während Best-Effort für Unkritisches gilt.

Marking-Strategien im VPN: Wo markiert man am sinnvollsten?

In der Praxis gibt es drei sinnvolle Marking-Punkte. Welcher am besten ist, hängt von Ihrer Architektur ab.

Marking am Endgerät

Vorteil: Anwendung kennt ihren Bedarf (Voice/Video), frühe Markierung hilft im lokalen Netz/WLAN.
Nachteil: Remote-Clients sind schwer zu kontrollieren; Missbrauch ist möglich; Policies sind OS- und App-abhängig.
Empfehlung: Nur auf Managed Devices und mit klaren App-Policies (z. B. UC-Clients) nutzen.

Marking am VPN-Gateway (Edge Marking)

Vorteil: Zentrale Kontrolle, einheitliche Regeln, gute Auditierbarkeit.
Nachteil: Klassifizierung muss oft pre-encrypt erfolgen; bei TLS-VPNs ist App-Erkennung ggf. eingeschränkt.
Empfehlung: Für Enterprise meist der beste Default: Gateway setzt Outer DSCP nach Policy und erhält/überschreibt Inner DSCP bewusst.

Marking im Core oder an der WAN-Edge

Vorteil: Nah am Congestion Point; kann Provider-Policer/Queues direkt bedienen.
Nachteil: Im VPN sieht man ggf. nur Outer Header; falsch, wenn Outer DSCP nicht korrekt gesetzt ist.
Empfehlung: Ergänzend nutzen, aber nur, wenn Outer DSCP verlässlich ist.

Copy Inner→Outer: Wann es sinnvoll ist und wann nicht

Die Idee klingt perfekt: Die Anwendung markiert inner DSCP, der Gateway kopiert es in den Outer Header, und das Underlay priorisiert korrekt. In der Praxis müssen Sie zwei Bedingungen erfüllen:

DSCP-Integrität: Inner DSCP muss korrekt und vertrauenswürdig sein (sonst priorisieren Sie Missbrauch).
Underlay-Respekt: Ihr Provider/WAN muss DSCP tatsächlich weiterleiten oder zumindest nicht zerstören; viele Internetpfade remarken auf Best Effort.

Wenn Sie kein kontrolliertes Underlay haben, kann Copy-to-Outer trotzdem sinnvoll sein, weil wenigstens Ihre eigenen WAN-Edges und internen Links korrekt priorisieren. Für Managed WANs oder SD-WAN Underlays ist Copy-to-Outer oft ein wichtiger Baustein.

Policing vs. Shaping: Der häufigste Grund, warum Voice im VPN leidet

QoS scheitert oft nicht an Marking, sondern an der Engpassbehandlung. Besonders gefährlich ist Policing auf WAN-Uplinks: Policer droppen Pakete, und Drops sind für Echtzeittraffic (Voice/Video) verheerend. Shaping hingegen glättet, indem es Traffic in Queues puffert und kontrolliert ausgibt.

Policing: Hartes Limit, überschüssige Pakete werden verworfen oder remarkt. Gut zur Missbrauchsbegrenzung, schlecht für Burst-Traffic.
Shaping: Weiches Limit, Pakete werden verzögert statt gedroppt (bis Queue voll). Ideal am Egress-Interface vor einem Provider-Policer.
Best Practice: Am WAN-Egress meist shapen (knapp unter der realen Provider-Rate), damit Ihre eigenen Queues die Congestion kontrollieren.

Hierarchical QoS: QoS pro Tunnel und pro Klasse gleichzeitig

In VPN-Designs ist ein hierarchisches Modell häufig sinnvoll: Zuerst wird Bandbreite pro Tunnel (oder pro Standort) begrenzt, danach innerhalb des Tunnels nach Klassen verteilt. Dadurch verhindern Sie, dass ein einzelner Tunnel alle Ressourcen frisst, und sichern gleichzeitig Voice/Video innerhalb des jeweiligen Tunnels.

Parent Policy: Shaping pro Tunnel/Uplink (z. B. 200 Mbit/s für ISP1).
Child Policy: Klassen (EF/Voice, AF/Video, Business, Best Effort, Scavenger) mit eigenen Queues.
Policy pro Profil: Remote Access User vs. Vendor vs. Admin können unterschiedliche Klassen und Limits erhalten.

DSCP-Klassen in der Praxis: Wenige Klassen, klare Regeln

Ein verbreiteter Fehler ist eine zu feingranulare Klassentabelle. Im VPN-Betrieb bewährt sich ein kleines Set an Klassen, die tatsächlich operationalisierbar sind.

EF (Expedited Forwarding): Voice/RTP (geringe Latenz, geringe Jitter-Toleranz).
AF4x/AF3x: Video/Interaktiv (höherer Bedarf, aber nicht so strikt wie Voice).
AF2x/AF1x: Business Apps (stabil, aber nicht „Echtzeit“).
BE: Best Effort (Standard).
CS1/Scavenger: Bulk/Backups/Updates (darf gedrosselt werden).

QoS über IPsec: ESP, NAT-T und Klassifizierung

Bei IPsec (ESP) ist nach dem Encrypt häufig nur noch Outer sichtbar. Das zwingt zu einem sauberen pre-encrypt Klassifizierungs- und Markingmodell. Für den IPsec-Kontext sind die Architekturgrundlagen in RFC 4301 beschrieben; entscheidend in der Praxis ist jedoch die konkrete Implementierung Ihres Gateways.

Pre-encrypt classify: Klassifizieren Sie den Klartexttraffic an der Inside-Schnittstelle oder am Tunnel-Interface, bevor ESP angewendet wird.
Outer DSCP setzen: Damit Underlay/WAN-Edge priorisieren kann, DSCP in den Outer Header übernehmen oder neu setzen.
NAT-T beachten: Bei UDP/4500 wird ESP gekapselt; trotzdem bleibt DSCP im IP-Header relevant.
Fragmentierung vermeiden: QoS + Fragmentierung ist eine schlechte Kombination; MTU/MSS sauber designen, damit Echtzeitpakete nicht fragmentieren.

QoS über TLS/SSL-VPN und WireGuard: Unterschiede, die zählen

Bei TLS-VPNs (und auch bei WireGuard) ist der Tunnel häufig UDP- oder TCP-basiert. Das kann Konsequenzen haben:

Tunnel über TCP: TCP-in-TCP kann bei Loss/Jitter zu massiven Performanceproblemen führen; QoS hilft begrenzt, weil Retransmits verschachtelt wirken.
Tunnel über UDP: Besser für Echtzeit; Marking/Preservation bleibt aber relevant, weil Underlay weiterhin congested sein kann.
WireGuard: Sehr effizient, aber QoS hängt stark davon ab, wie Ihr Gateway Outer DSCP setzt und wie das Underlay Markierungen behandelt.

Policing richtig einsetzen: Schutz vor Missbrauch ohne Kollateralschäden

Policing ist nicht grundsätzlich schlecht. Es ist ein wirksamer Schutz gegen „Scavenger wird EF“. Der Trick ist, Policer dort zu platzieren, wo sie den Schaden minimieren:

In der Low-Priority-Klasse: Bulk/Scavenger darf hart begrenzt werden, damit es interaktiv nicht verdrängt.
Am Ingress mit Trust Boundary: Untrusted DSCP wird auf BE remarkt, bevor es in Prioritätsqueues gelangt.
Mit klaren Burst-Parametern: Zu strenge Burst-Werte erzeugen unnötige Drops, selbst wenn die durchschnittliche Rate ok ist.

DSCP Preservation testen: Wie Sie sicher nachweisen, was wirklich passiert

QoS-Debugging scheitert oft an fehlender Evidenz. Sie müssen verifizieren, ob DSCP wirklich erhalten bleibt und wo es ggf. überschrieben wird. Ein praxistauglicher Ansatz:

Capture pre-encrypt: Prüfen, ob inner DSCP korrekt gesetzt ist (z. B. am Client oder Inside-Interface des Gateways).
Capture auf dem Underlay: Prüfen, ob outer DSCP gesetzt/übernommen wird und ob es auf dem WAN sichtbar bleibt.
Capture post-decrypt: Prüfen, ob inner DSCP nach Entschlüsselung erhalten ist (wichtig für QoS im Zielnetz).
Queue Counters: Verifizieren, dass Pakete tatsächlich in die erwarteten Klassen/Queues fallen (Drops pro Queue sind besonders aussagekräftig).

QoS und Capacity Planning: Ohne Bandbreitenbudget keine stabile Priorisierung

QoS kann keine Bandbreite herbeizaubern. Wenn Ihr WAN regelmäßig überlastet ist, bleibt QoS nur ein Schadensbegrenzungswerkzeug. Für ein belastbares Design brauchen Sie Budgets pro Klasse, basierend auf realen Peaks.

Voice Budget: Anzahl gleichzeitiger Calls × Codec-Bandbreite + Overhead + Headroom.
Video Budget: Deutlich variabler; konservativ planen und ggf. adaptiv begrenzen.
Business Budget: Kritische Apps priorisieren, aber nicht in die Strict-Priority-Queue stecken.
Scavenger: Harte Grenzen setzen, damit Bulk nicht alles dominiert.

Ein bewährtes Monitoring-Modell ist, SLIs wie Latenz/Jitter/Loss pro Klasse zu messen und Drops pro Queue zu korrelieren, statt nur „Interface Utilization“ zu betrachten.

Häufige Anti-Patterns bei QoS über VPN

DSCP überall „trusten“: Unmanaged Clients können sich selbst priorisieren; Prioritätsqueue wird missbraucht.
Nur markieren, nicht queuen: DSCP ohne passende Queues am Congestion Point bringt wenig.
Policer am falschen Ort: Harte Drops auf Voice/Video zerstören Qualität; besser shapen und echte Queues nutzen.
Zu viele Klassen: Komplexität steigt, Betrieb verliert Übersicht, Fehlklassifizierung nimmt zu.
Kein Outer DSCP: Inner DSCP ist korrekt, aber Outer bleibt BE; Underlay priorisiert nicht, WAN-Edge kann nicht differenzieren.
MTU/MSS ignoriert: Fragmentierung erhöht Loss und Jitter; QoS kann das nicht „wegpriorisieren“.

Checkliste: QoS über VPN sauber umsetzen

Congestion Points identifizieren: WAN-Uplinks, zentrale Gateways, Wi-Fi, Proxy/SASE, Cloud Egress.
Trust Boundary definieren: DSCP nur von managed/validierten Quellen akzeptieren, sonst remark auf BE.
Marking-Strategie wählen: Client, Gateway oder WAN-Edge – bevorzugt Gateway mit Policy-basiertem Marking.
DSCP Preservation planen: Inner DSCP erhalten, Outer DSCP setzen (copy oder remark) je nach Underlay und Trust.
Shaping vor Policing: Am WAN-Egress shapen, damit Ihre Queues kontrollieren, nicht der Provider-Policer.
Hierarchische Policies: Per-Tunnel/Uplink shapen, innerhalb nach Klassen queuen.
Wenige Klassen: EF (Voice), AF (Video/Interaktiv), Business, BE, Scavenger.
Monitoring: Drops/Queue Depth pro Klasse, RTT/Jitter/Loss pro Klasse, DSCP-Mismatch-Detektion.
Verifikation: Captures pre-/post-encrypt, Underlay-Checks, Queue Counter und Testcalls unter Last.

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.