QoS über IPSec: DSCP Copy, Outer Header Marking und Policer

QoS über IPSec ist eine der häufigsten Baustellen in WAN- und Provider-Designs, weil IPSec zwar Sicherheit liefert, aber QoS-Signale leicht „unsichtbar“ macht. In der Praxis sieht das so aus: Im LAN sind Voice/Video korrekt mit DSCP (z. B. EF/AF) markiert, doch sobald Traffic durch einen IPSec-Tunnel läuft, greifen Prioritäten nicht mehr – oder sie greifen nur sporadisch. Die Ursache liegt fast immer in drei Bereichen: DSCP Copy (wie wird das innere Marking in den Outer Header übertragen?), Outer Header Marking (welches DSCP sieht das Underlay tatsächlich?) und Policer (wo werden Profile durchgesetzt, und droppen sie ausgerechnet Echtzeitpakete?). Ein professionelles Design für QoS über IPSec betrachtet den Tunnel als eigene Congestion Domain: Sie definieren Trust Boundaries am Tunnel-Endpunkt, setzen eine klare Strategie für DSCP Copy/Mapping, planen Bandbreitenbudgets inklusive IPSec-Overhead, platzieren Shaping so, dass die Queue im eigenen Einflussbereich liegt, und konfigurieren Policer so, dass sie Missbrauch verhindern, ohne Echtzeitqualität zu zerstören. Nur so wird IPSec nicht zum „QoS-Blackout“, sondern zu einem sicheren Transport, der weiterhin planbare Latenz, geringen Jitter und minimale Loss-Spitzen für kritische Anwendungen liefert.

Warum IPSec QoS erschwert: Inner vs. Outer Header und „blinde“ Underlays

IPSec kapselt (oder verschlüsselt) Pakete, sodass das Underlay primär den Outer IP-Header sieht. Genau dieser Outer Header entscheidet in Routern und Provider-Netzen über Queueing und Scheduling – nicht der innere DSCP, der im Originalpaket steckt. Wenn DSCP nicht in den Outer Header kopiert oder sinnvoll gemappt wird, wird im Underlay alles als Best Effort behandelt, selbst wenn der innere Traffic sauber markiert ist. Zusätzlich kann IPSec Overhead die effektive Paketgröße erhöhen, wodurch MTU-Probleme und Fragmentierung auftreten – beides wirkt wie Packet Loss und trifft Echtzeit hart.

• Inner DSCP: ursprüngliche Serviceklasse (Voice/Video/Business) im verschlüsselten Verkehr.
• Outer DSCP: einzig sichtbares QoS-Signal für das Underlay (Provider/Internet/Metro).
• Overhead: zusätzliche Header erhöhen effektive Bitrate und MTU-Anforderungen.
• Konsequenz: QoS muss „tunnelfähig“ sein, nicht nur innerhalb des LANs.

DSCP Copy: Die zentrale Stellschraube für Underlay-QoS

DSCP Copy bezeichnet die Regel, wie DSCP-Werte vom inneren (verschlüsselten) Paket auf den Outer IP-Header übertragen werden. In der Praxis gibt es drei Varianten: Copy (1:1 übernehmen), Map (auf ein internes Klassenmodell übersetzen) und Rewrite (Outer DSCP unabhängig vom inneren DSCP setzen, z. B. anhand von VRF/Interface/Policy). Für QoS über IPSec ist „Copy“ nur dann sinnvoll, wenn die Marking-Quelle vertrauenswürdig ist. In gemischten Umgebungen ist „Map“ meist der beste Kompromiss: Sie erhalten End-to-End Semantik, verhindern aber Klassenexplosion und Missmarking, indem Sie nur wenige, definierte Klassen nach außen geben (z. B. Realtime, Interactive, Business, Best Effort, Bulk).

• Copy: einfach, transparent – aber anfällig für Missmarking und Premium-Queue-Flutung.
• Map: übersetzt inner DSCP auf wenige Outer-Klassen – operativ beherrschbar und sicherer.
• Rewrite: maximale Kontrolle – sinnvoll, wenn Markings im Inneren nicht zuverlässig sind.

Pragmatische Empfehlung für IPSec-Tunnel

• Managed/Trusted Endpoints: Copy oder Map, je nach Governance.
• Untrusted/Multi-Tenant: Map oder Rewrite, plus strikte Limits für Realtime.
• Internet-Underlay: Outer DSCP ist dennoch nützlich für lokale CPE-Queues, auch wenn das Internet DSCP oft ignoriert.

Outer Header Marking: Was das Underlay wirklich sieht – und warum das zählt

Outer Header Marking ist der DSCP-Wert im Outer IP-Header des IPSec-Tunnels. Dieser Wert entscheidet über die Underlay-Behandlung, sofern das Underlay QoS respektiert (z. B. MPLS, Carrier Ethernet, gemanagte Internet-Backbones). Selbst wenn DSCP im öffentlichen Internet häufig genullt oder ignoriert wird, bleibt Outer Marking wertvoll: Es steuert die erste Queue am eigenen WAN-Edge (wo Bufferbloat oft entsteht) und kann in kontrollierten Segmenten Wirkung entfalten (Metro, Provider Access, Interconnects). Wichtig ist, dass Outer Marking netzweit konsistent in Queues gemappt wird – sonst entsteht ein QoS-Loch, bei dem Markings zwar gesetzt sind, aber falsch bedient werden.

• Underlay-Queueing: basiert auf Outer DSCP, nicht auf inner DSCP.
• Interconnects: Übergänge sind häufig Engpässe; Outer Marking plus Shaping macht Congestion sichtbar.
• Consistency: Outer DSCP muss zu Ihrem Klassenmodell und Ihren Queue-Profilen passen.

Trust Boundary am IPSec-Endpunkt: Markings akzeptieren oder normalisieren

Der IPSec-Endpunkt (CPE, SD-WAN Edge, Firewall, Router) ist funktional ein Provider Edge: Er entscheidet, welche Markings vom LAN in den Tunnel „exportiert“ werden. Ohne Trust Boundary kann jede Anwendung Premiumklassen nutzen, wodurch Echtzeitqueues wachsen und instabil werden. Eine robuste Trust Boundary nutzt eine Allowlist zulässiger DSCP-Werte, normalisiert unbekannte Werte auf Best Effort und setzt Budgets pro Klasse durch. Besonders kritisch ist EF/Realtime: Wenn Realtime im Underlay strikt priorisiert wird, muss sie strikt limitiert sein.

• Allowlist: nur definierte DSCP-Werte dürfen in Premiumklassen gelangen.
• Normalization: alle anderen Werte werden auf DSCP 0 (Best Effort) gesetzt.
• Budgets: pro Klasse (Realtime/Video/Business) Grenzen definieren und überwachen.
• Audit: Remarking- und Policer-Zähler zeigen Missmarking und Policy-Wirkung.

Policer im IPSec-Kontext: Schutzmechanismus oder QoE-Killer?

Policer sind im Provider- und Enterprise-Betrieb wichtig, weil sie Profile durchsetzen und Missbrauch verhindern. Im IPSec-Kontext sind sie jedoch besonders heikel, weil harte Drops in Echtzeitklassen sofort hörbar oder sichtbar sind. Deshalb gilt: Policer gehören an Trust Boundaries, aber sie müssen mit realistischen Budgets arbeiten und idealerweise Überschreitungen degradieren (ummarkieren) statt droppen – zumindest für Echtzeitnahe Klassen, wenn das Serviceziel es erlaubt. Für Bulk/Scavenger kann Drop dagegen durchaus sinnvoll sein, um das Netz zu schützen.

• Ingress Policing: schützt Premiumklassen vor Missmarking aus dem LAN.
• Egress Policing: kann Profile am Tunnel-Ausgang erzwingen, ist aber riskant für Echtzeit.
• Degrade statt Drop: Überschreitungen in niedrigere Klassen ummarkieren, um QoE weniger hart zu treffen.
• Realtime Limits: strikt, aber ausreichend dimensioniert; zu knapp = hörbare Drops.

Shaping: Der wichtigste Hebel gegen Bufferbloat bei IPSec

Viele QoS-Probleme bei IPSec sind keine Marking-Probleme, sondern Queueing-Probleme. Besonders im Upstream (Upload) füllen sich Provider- oder CPE-Queues, RTT steigt, Jitter steigt, Voice/Video leidet. Egress Shaping knapp unter der realen Upstream-Rate ist deshalb oft der größte Gewinn: Es holt die Queue in den eigenen Einflussbereich, macht Congestion kontrollierbar und reduziert Drop-Bursts. Im IPSec-Kontext ist Shaping zudem wichtig, weil IPSec-Overhead die effektive Rate erhöht – ohne Shaping werden Engpässe schneller erreicht als erwartet.

• Egress Shaping: kontrolliert die Abflussrate und verlagert Congestion in lokale, steuerbare Queues.
• HQoS: Parent-Shaper für Gesamtprofil, Child-Queues für Realtime/Video/Business/BE/Bulk.
• Queue-Limits: Echtzeitqueues kurz halten, Best Effort mit AQM/ECN stabilisieren.

MTU/MSS und IPSec-Overhead: Die stille Ursache für Drops

IPSec erhöht die Paketgröße. Wenn MTU nicht sauber geplant ist, entstehen Fragmentierung oder Drops. Für QoS ist das besonders kritisch, weil Fragmentierung Jitter und CPU/ASIC-Last erhöhen kann und Drops wie „mysteriöser Paketverlust“ wirken. Zusätzlich erhöht Overhead die effektive Bitrate: Besonders bei kleinen Echtzeitpaketen (RTP) ist der relative Overhead groß. Das muss in Bandbreitenbudgets, LLQ-Limits und Shaper-Raten berücksichtigt werden, sonst entstehen Policer-Drops oder Queue-Overflows genau dort, wo Sie eigentlich schützen wollten.

• MTU-Standard: End-to-End MTU für Tunnelpfade definieren und validieren.
• MSS-Clamping: TCP-Fragmentierung vermeiden, insbesondere für SaaS/HTTPS.
• Overhead-Budget: Realtime-Budgets und Shaper-Profile an effektive Rate anpassen.

Designmuster: „Copy, aber nur für erlaubte Klassen“

Ein bewährtes Muster für QoS über IPSec ist ein kontrolliertes DSCP Copy: Inner DSCP wird erhalten, aber Outer DSCP wird nur für eine Allowlist von Klassen gesetzt. Alles andere wird im Outer Header normalisiert. Gleichzeitig werden Premiumklassen budgetiert, und Überschreitungen werden degradiert statt gedroppt, sofern das Produkt es zulässt. So bleiben Realtime- und Business-Anforderungen erfüllbar, ohne dass Sie Premium-Queues für beliebigen Traffic öffnen.

• Allowlist Copy: EF und ausgewählte AF/Control-Werte werden in Outer DSCP propagiert.
• Normalize Outer: unbekannte/unerwünschte Markings → DSCP 0 im Outer Header.
• Class Budgets: LLQ/Realtime strikt limitiert, Video/Business gewichtet, Bulk nachrangig.
• Degradation: bei Überschreitung ummarkieren, nicht blind droppen.

Messbarkeit: Wie Sie DSCP Copy, Outer Marking und Policer-Wirkung nachweisen

Damit QoS über IPSec nicht zur Glaubensfrage wird, brauchen Sie Telemetrie auf drei Ebenen. Erstens Marking-Integrität: Vergleich inner DSCP vs. outer DSCP am Tunnel-Ingress und Tunnel-Egress. Zweitens Queue-Health: Queue-Delay und Drops pro Klasse am WAN-/Tunnel-Interface, idealerweise in kurzen Zeitfenstern und mit Perzentilen. Drittens Policy-Enforcement: Policer- und Remarking-Zähler zeigen, ob Budgets überschritten werden und ob Missmarking stattfindet. Ergänzend sind QoE-KPIs für Echtzeit hilfreich (RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen), um Nutzerimpact zu belegen.

• DSCP-Distribution: inner vs. outer – stimmt die Copy/Map-Regel?
• Queue-Delay p95/p99: Frühindikator für Jitter und bevorstehende QoE-Probleme.
• Class Drops: Drops in Realtime/Control sind kritisch; Best Effort Drops anders interpretieren.
• Policer/Remarking Counters: zeigen Profilüberschreitungen und Policy-Wirkung.

Typische Failure Patterns bei QoS über IPSec

Wenn IPSec-QoS nicht funktioniert, sind die Ursachen oft schnell einzugrenzen: Outer DSCP wird nicht gesetzt, Underlay ignoriert DSCP, Policer sind zu knapp, Shaping fehlt oder MTU passt nicht. Diese Muster lassen sich systematisch prüfen, ohne „blind“ am QoS herumzuschrauben.

• Alles ist Best Effort: Outer DSCP bleibt 0 oder wird genullt; Underlay sieht keine Klassen.
• Premium-Queues überlaufen: Copy ohne Trust; Allowlist und Limits fehlen.
• Voice leidet bei Upload: Bufferbloat am Upstream; Shaping/AQM fehlen.
• Unerklärliche Drops: MTU/Fragmentierung durch IPSec-Overhead; MTU/MSS prüfen.
• Policer-Drops in Realtime: Budgets zu knapp oder Overhead nicht eingerechnet; degrade statt drop prüfen.

Blueprint: QoS über IPSec als wiederholbares Design

Ein robustes Design beginnt mit einem schlanken Klassenmodell und klaren SLOs pro Klasse (Realtime, Video/Interactive, Business, Best Effort, Bulk plus Control). Danach definieren Sie am IPSec-Endpunkt eine Trust Boundary: Allowlist, Normalisierung und ein Mapping von inner DSCP auf outer DSCP. Realtime wird strikt limitiert und überwacht. Shaping wird an den echten Engpässen platziert (meist Upstream), sodass Congestion lokal und messbar wird, während Best Effort mit AQM/ECN gegen Bufferbloat stabilisiert wird. MTU/MSS wird end-to-end geplant, damit Overhead keine versteckten Drops erzeugt. Abschließend bauen Sie Monitoring auf, das DSCP Copy, Outer Header Marking, Policer-Ereignisse und Queue-Health korreliert. So wird QoS über IPSec zu einem planbaren, auditierbaren Mechanismus, der Sicherheit und Echtzeitqualität zuverlässig zusammenbringt.