SD-WAN vs. klassische VPN: Underlay/Overlay Design im Vergleich

SD-WAN vs. klassische VPN ist eine der zentralen Architekturfragen moderner Unternehmensnetze: Soll Standortvernetzung weiterhin über „klassische“ IPSec-Tunnel mit statischem Routing oder BGP/OSPF betrieben werden – oder liefert ein SD-WAN-Overlay mit zentraler Orchestrierung, App-Awareness und dynamischer Pfadsteuerung den besseren Gesamtwert? Die Diskussion wird oft verkürzt geführt („SD-WAN ist nur VPN mit Marketing“ oder „VPN ist alt“), dabei geht es technisch um etwas Fundamentales: das Zusammenspiel von Underlay (Transportnetz wie Internet, MPLS, LTE/5G) und Overlay (logische, verschlüsselte Verbindungen, Routing- und Policy-Logik darüber). Klassische VPNs können sehr stabil und sicher sein, wenn Standards, Failover-Tracking, MTU/MSS und Routing-Policies sauber umgesetzt werden. SD-WAN kann dagegen besonders dort punkten, wo viele Standorte, häufige Änderungen, mehrere Uplinks, Performance-SLAs und einheitliche Policies über Regionen hinweg gefordert sind. Dieser Artikel vergleicht Underlay/Overlay-Designs systematisch: Architekturbausteine, Failover-Mechanik, Security- und Governance-Aspekte, Observability sowie typische Fallstricke – damit Sie nicht nach Hype, sondern nach belastbaren Kriterien entscheiden.

Underlay und Overlay: Der wichtigste Denkrahmen

Bevor man SD-WAN oder klassische VPN bewertet, muss klar sein, was Underlay und Overlay bedeuten. Das Underlay ist das physische oder providergesteuerte Transportnetz: Internet, MPLS, Metro-Ethernet, Mobilfunk oder dedizierte Leitungen. Das Overlay ist die logische Verbindungsebene darüber: Verschlüsselung, Tunnel, virtuelle Topologien, Routing- und Policy-Entscheidungen.

• Underlay: Liefert Konnektivität, Bandbreite, Latenz, Jitter, Paketverlust, Provider-Failure-Domains.
• Overlay: Liefert Segmentierung, Verschlüsselung, logische Pfade, Failover-Logik, Applikationssteuerung, Governance.

Ein häufiger Fehler ist, Underlay-Probleme im Overlay „wegzukonfigurieren“. Ein gutes Design akzeptiert: Das Underlay ist nie perfekt. Das Overlay muss damit umgehen – aber nur innerhalb klarer Grenzen (z. B. Hysterese statt Flapping).

Klassische VPN-Architektur: Was „klassisch“ im Enterprise wirklich heißt

Klassische VPNs im Enterprise sind typischerweise IPSec-basierte Site-to-Site-Verbindungen (manchmal ergänzt durch GRE/DMVPN-ähnliche Konzepte oder TLS-basierte Varianten). Der Standardfall ist: Ein oder mehrere Tunnel zwischen Gateways, mit statischem Routing oder dynamischem Routing (oft BGP) über dem Tunnel. Die Sicherheitsarchitektur von IPsec ist in RFC 4301 (IPsec Security Architecture) beschrieben; IKEv2 als Control Plane in RFC 7296 (IKEv2).

• Overlay-Funktion: Tunnel aufbauen, Keys verhandeln (IKE), Nutzdaten schützen (ESP), Routen verteilen.
• Underlay-Abhängigkeit: Internet/MPLS-Qualität, NAT/Firewalls (NAT-T), MTU/PMTUD, Provider-Routing.
• Betriebsmodell: Konfiguration pro Standort/Peer, Templates möglich, aber oft vendor- und toolabhängig.

SD-WAN-Architektur: Was sich technisch wirklich verändert

SD-WAN ist kein einzelnes Protokoll, sondern ein Architektur- und Produktansatz: Ein Overlay, das Standorte über mehrere Underlays verbindet, zentral orchestriert wird und typischerweise zusätzliche Logik für Applikationslenkung, Pfadqualität, Segmentierung und Policy Enforcement mitbringt. Technisch sind viele SD-WAN-Overlays ebenfalls verschlüsselte Tunnel (häufig IPSec-ähnlich oder proprietär), aber der Unterschied liegt in der Steuerung und Automatisierung des Overlays.

• Orchestrierung: Zentrale Controller/Manager definieren Policies, die an Edges ausgerollt werden.
• Path Selection: Pfadwahl basierend auf Telemetrie (Loss/Latency/Jitter), oft per Applikationsklasse.
• Zero-Touch Provisioning: Standorte können mit minimaler lokaler Konfiguration in Betrieb genommen werden.
• Segmentation: Overlays/VRFs/„VPNs im SD-WAN“ als logische Mandanten oder Zonen.

Topologievergleich: Hub-and-Spoke, Full Mesh und hybride Patterns

Topologie ist ein Kosten- und Komplexitätsfaktor. Klassische VPNs werden in großen Umgebungen fast nie als echtes Full Mesh betrieben, weil die Tunnelanzahl schnell explodiert. SD-WAN kann Full-Mesh-ähnliche Overlays operational einfacher machen, weil das System Tunnels und Policies zentral verwaltet. Trotzdem gilt: Jede Topologie hat Pfad-, Security- und Troubleshooting-Konsequenzen.

• Klassische VPNs: Häufig Hub-and-Spoke oder Dual-Hub; Teil-Mesh nur für wenige kritische Standortpaare.
• SD-WAN: Oft logisches Full Mesh möglich, aber in der Praxis ebenfalls häufig mit Hubs/Transits (z. B. für zentrale Services, Inspection, Cloud On-Ramps).
• Guardrail: Egal ob SD-WAN oder klassisch: Transitivität (Spoke-to-Spoke) muss bewusst erlaubt oder verhindert werden.

Failover und Resilience: Tracking, SLA-basierte Pfadwahl und Flapping

Failover ist der Bereich, in dem SD-WAN häufig sichtbar „besser“ wirkt, weil Pfadqualität kontinuierlich gemessen und Traffic dynamisch umgelenkt wird. Klassische VPNs können das ebenfalls, benötigen dafür aber saubere Bausteine: IP SLA/Tracking, BFD, BGP-Preferenzen, Hysterese und ein gutes Service-Health-Modell.

Klassische VPN: Failover über Routing und Tracking

• Mechanik: Tunnel/Route wird bei Failure withdrawn oder entpriorisiert (z. B. BGP Local Preference).
• Stärke: Sehr deterministisch, wenn Policies sauber sind; gut auditierbar.
• Risiko: „Tunnel up, aber Service down“ ohne Service-Tracking; aggressives DPD/BFD erzeugt Flapping.

SD-WAN: Failover über kontinuierliche Pfadmetriken

• Mechanik: Overlay misst Pfadqualität (Loss/Latency/Jitter) und lenkt Applikationsklassen dynamisch.
• Stärke: Degradation-aware Steering (nicht nur up/down) ist häufig Standard.
• Risiko: Zu aggressive Policies können ebenfalls flappen; zusätzlich: Debugging erfordert Verständnis der Controller-Logik.

Applikationssteuerung: App-Aware Routing vs. „IP-Routen sind IP-Routen“

Ein zentraler SD-WAN-Mehrwert ist applikationsbasierte Steuerung: VoIP/Video bevorzugt Pfade mit niedrigem Jitter, große Transfers bevorzugen Bandbreite, kritische Anwendungen bevorzugen stabile Pfade. Klassische VPNs können ähnliche Ziele erreichen, aber meist mit mehr manueller Arbeit (QoS, PBR, separate Tunnels, statische Präferenzen).

• SD-WAN-typisch: App-Identifikation + Policy, z. B. „O365 über Internet-Path A, ERP über MPLS-Path B“.
• Klassisch möglich: Policy-Based Routing, QoS, mehrere Tunnels, aber oft weniger zentral und weniger dynamisch.
• Wichtig: App-Awareness muss mit Security und Logging harmonieren, sonst entstehen blinde Flecken.

Security: Verschlüsselung, Segmentierung und zentrale Controls

Viele Vergleiche reduzieren Security auf „beide verschlüsseln“. In der Praxis entscheiden jedoch Segmentierung, Policy-Konsistenz, Logging und Abhängigkeiten über das Sicherheitsniveau. Ein gut gebautes klassisches IPSec-VPN ist sehr sicher. SD-WAN bringt jedoch oft zusätzliche Sicherheits- und Governance-Mechanismen „out of the box“ (z. B. zentrale Policy-Verteilung, Mandantenfähigkeit, integrierte Zonen).

• Verschlüsselung: Klassisch IPSec/IKEv2; SD-WAN häufig ebenfalls IPSec-basiert oder proprietär – entscheidend sind Standardprofile und Rotation.
• Segmentierung: VRFs/Zonen/Overlays; in SD-WAN oft als „Segments“ zentral verwaltet.
• Inspection: Beide Ansätze benötigen eine klare Strategie: lokal am Edge, zentral im Hub, oder via Cloud-Security-Services.

Für Zero-Trust-Prinzipien als Architekturleitplanke ist NIST SP 800-207 (Zero Trust Architecture) eine sinnvolle Referenz, insbesondere wenn Sie Segmentierung und kontinuierliche Verifikation als Designziele setzen.

MTU/MSS und Underlay-Fallen: Warum „Overlay kann alles“ nicht stimmt

Unabhängig vom Ansatz bleiben MTU, MSS und PMTUD ein häufiges Problemfeld, weil Encapsulation Overhead erzeugt und viele Underlays ICMP unglücklich behandeln. SD-WAN kann Diagnostik erleichtern (z. B. Telemetrie), aber es kann physikalische Grenzen nicht wegzaubern. Klassische VPNs benötigen hier saubere Standards: Tunnel-MTU, MSS-Clamping und gezielte ICMP-Freigaben.

• PMTUD-Grundlagen: RFC 1191 (Path MTU Discovery für IPv4) und RFC 8201 (PMTUD für IPv6).
• Best Practice: Konservative, einheitliche Tunnel-MTU pro Profil; MSS-Clamping für TCP; ICMP nicht pauschal blocken.
• Failover-Falle: Dual-ISP-Setups können unterschiedliche effektive MTUs haben; ohne Standardisierung entstehen „nur manche Apps“-Ausfälle nach Umschaltung.

Routing und Policy-Patterns: BGP/OSPF vs. SD-WAN-Policy Fabrik

Klassische VPNs setzen für Skalierung häufig auf dynamisches Routing, insbesondere BGP über IPSec. Das ist ein sehr starkes Pattern, solange Prefix-Filter und Governance sauber sind. BGP-Grundlagen sind in RFC 4271 (BGP-4) beschrieben. SD-WAN kapselt Routing häufig hinter einer Policy-Schicht: Der Controller entscheidet, welche Routen/Segments wo sichtbar sind und wie Pfade bevorzugt werden.

• Klassisch: BGP-Policy (LocalPref, Communities, Summaries) ist mächtig, aber erfordert Routing-Expertise und Disziplin gegen Route Leaks.
• SD-WAN: Policy-Modelle sind oft „intent-based“; einfacher für Standardfälle, aber Debugging erfordert Tool- und Produktwissen.
• Gemeinsamer Nenner: Prefix- und Segment-Governance ist Pflicht, sonst wächst Reichweite unkontrolliert.

Operability: Provisioning, Change-Management und Drift

Der größte SD-WAN-Vorteil liegt oft im Betrieb: neue Standorte schneller anbinden, zentrale Templates, weniger manuelle Konfiguration. Klassische VPNs können das ebenfalls erreichen, aber meist nur mit konsequenter Automatisierung (Templates, IaC, Konfig-Management) und guter Governance.

• SD-WAN: Zero-Touch Provisioning, zentrale Policies, konsistente Rollouts, oft integrierte Telemetrie.
• Klassisch: Höhere Freiheit, aber mehr Verantwortung: Standards müssen aktiv durchgesetzt werden (Golden Profiles, Rezertifizierung, Drift Detection).
• Risiko SD-WAN: Vendor Lock-in und Produktkomplexität; Controller-Ausfälle oder Fehlkonfigurationen wirken breit.

Observability: Was Sie wirklich messen müssen

Viele Entscheidungen sollten datengetrieben sein: Paketverlust, Latenz, Jitter, Rekey-Fehler, Routing-Flaps, Session-Abbrüche. SD-WAN bringt häufig eine sehr gute End-to-End-Telemetrie mit, während klassische VPNs meist aus mehreren Quellen korreliert werden müssen (Gateway, Routing, Firewall, Flow-Daten). Beides kann hervorragend sein – wenn Sie es bewusst designen.

• Underlay Metriken: Loss/Latency/Jitter pro ISP, Verfügbarkeit, MTU-Indikatoren.
• Overlay Metriken: Tunnel up/down, Rekey/DPD, SA-Churn, Drops, Anti-Replay-Drops.
• Routing/Policy: Prefix-Counts, Withdraw/Announce-Events, Segment-Visibility, Policy-Hits.
• Service-Synthetics: DNS, TCP-Connect, HTTP-Checks zu kritischen Applikationen – nicht nur „Tunnel up“.

Entscheidungsmatrix: Wann SD-WAN typischerweise gewinnt

• Viele Standorte und häufige Changes: Zentrale Orchestrierung reduziert Aufwand und Fehlerquote.
• Mehrere Underlays pro Standort: Internet + MPLS + LTE/5G mit SLA-basierter Pfadwahl.
• App-Performance als KPI: VoIP/Video/VDI profitieren von Degradation-aware Steering.
• Standardisierung als Ziel: Einheitliche Segments, Policies, Templates, Rollouts und Telemetrie.
• Einheitliche Sichtbarkeit: Wenn Sie Observability über alle Standorte zentral brauchen.

Entscheidungsmatrix: Wann klassische VPN-Designs die bessere Wahl sind

• Kleine bis mittlere Umgebungen: Wenige Standorte, stabile Prefixes, klare Hub-Topologie.
• Starke Routing-Kompetenz im Team: BGP über IPSec mit sauberen Filtern kann sehr skalierbar und transparent sein.
• Maximale Kontrolle und Transparenz: Kein proprietäres Policy-Modell, direktes Debugging auf Routing- und Tunnel-Ebene.
• Vendor-Strategie: Wenn Lock-in vermieden werden soll oder eine bestehende Security-/Netzwerkplattform genutzt wird.
• Spezielle Security-Architekturen: Z. B. sehr spezifische Inspection-Ketten oder streng kontrollierte Transitivität.

Häufige Fallstricke in beiden Welten

• Overconfidence in Automatik: SD-WAN-Policies ohne Hysterese führen zu Flapping; klassische VPNs ohne Service-Tracking zu Blackholing.
• Asymmetrisches Routing: Active/Active und ECMP ohne State-Konzept brechen stateful Firewalls/NAT.
• MTU/PMTUD ignorieren: „Nur manche Apps“ ist oft kein App-Problem, sondern Encapsulation/ICMP.
• Drift und Ausnahmen: Egal ob SD-WAN oder klassisch: unbefristete Ausnahmen zerstören Standards und Audit-Readiness.
• Controller-/Management-Abhängigkeiten: SD-WAN benötigt robuste Management- und PKI/IdP-Abhängigkeiten, sonst leidet Provisioning und Betrieb.

Praxis-Blueprint: Vergleichbare Zielarchitekturen modellieren

Für eine belastbare Entscheidung lohnt es sich, beide Ansätze als Blueprint mit denselben Anforderungen zu modellieren. So vermeiden Sie Äpfel-und-Birnen-Vergleiche.

• Failure Domains: ISP, Region, Hub, Controller, DNS/IdP, Egress-Stack.
• Topologie: Single Hub vs. Dual-Hub vs. Multi-Region; Teil-Mesh für kritische Pfade.
• Steering: Up/down vs. Degradation-aware; Hysterese, Hold-down, Failback-Regeln.
• Segmentation: VRFs/Segments, Partner/OT/Admin getrennt, kontrollierte Transitivität.
• Observability: Standard-Dashboards, synthetische Checks, Korrelation von User/Device/Session/Region.
• Governance: Rezertifizierung, Ausnahmeprozesse mit Enddatum, Drift Detection, Change-Templates.

Checkliste: SD-WAN vs. klassische VPN anhand Underlay/Overlay entscheiden

• Skalierung: Wie viele Standorte heute und in 24 Monaten? Wie häufig ändern sich Prefixes und Policies?
• Underlay-Vielfalt: Ein ISP oder mehrere? MPLS + Internet + LTE/5G?
• Performance-KPIs: Welche Applikationen sind jitter-/latenzsensitiv, und wie wichtig ist dynamisches Steering?
• Security-Controls: Wo müssen Inspection und Logging greifen (zentral, lokal, cloudbasiert)?
• Betriebsmodell: Benötigen Sie Zero-Touch und zentrale Orchestrierung oder reicht IaC/Template-basierte VPN-Automatisierung?
• Observability: Können Sie Underlay/Overlay end-to-end messen und korrelieren?
• Governance: Können Sie Standards, Rezertifizierung und Ausnahmeprozesse langfristig durchsetzen?
• Risiko Lock-in: Wie wichtig ist Produktunabhängigkeit vs. integrierte Funktionalität?

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.