SD-WAN – Moderne Standortvernetzung

Warum SD-WAN gerade jetzt ein Thema für dein KMU ist

Stell dir ein Schweizer KMU mit Hauptsitz in Zürich und drei Filialen in Bern, Basel und St. Gallen vor. Klassisch würdest du jeden Standort per MPLS-Standleitung an den Hauptsitz anbinden – zuverlässig, aber teuer, langsam bestellt (Lieferzeiten von 8 bis 16 Wochen sind bei Schweizer Carriern keine Seltenheit) und mit fixer Bandbreite, die du für viel Geld nachbestellen musst, sobald eine Filiale wächst. Gleichzeitig läuft immer mehr Business-Traffic gar nicht mehr über den Hauptsitz, sondern direkt in die Cloud: Microsoft 365, Salesforce, ein ERP-SaaS. Der klassische Hub-and-Spoke-Ansatz mit zentralem Internet-Breakout zwingt diesen Cloud-Traffic auf einen Umweg über die Zentrale – nur um dort wieder ins Internet zu wollen.

SD-WAN (Software-Defined Wide Area Network) löst genau dieses Problem: Es abstrahiert die physische Anbindung (MPLS, Internet-Breitband, 4G/5G) in eine Software-Schicht, die selbstständig entscheidet, über welchen Weg welcher Verkehr läuft – basierend auf Anwendung, Priorität und aktueller Leitungsqualität. Für ein KMU heisst das konkret: günstigere Internetleitungen statt teurer MPLS-Kreise, zentrale Policy-Verwaltung über eine Cloud-Konsole und automatisches Failover, wenn eine Leitung ausfällt oder schlecht wird.

SD-WAN vs. klassisches MPLS

Wie MPLS funktioniert

MPLS (Multiprotocol Label Switching) ist eine Carrier-Technologie, bei der dein Provider dir eine private, ihm gehörende Leitung mit garantiertem Service Level Agreement bereitstellt. Pakete werden anhand von Labels statt IP-Adressen durch das Provider-Netz geswitcht, was niedrige und vor allem konstante Latenz ermöglicht. Der grosse Vorteil: Der Carrier garantiert dir vertraglich Bandbreite, Verfügbarkeit (oft 99.9 % oder höher) und maximale Latenz zwischen deinen Standorten.

Der Nachteil: Du bezahlst für diese Garantie. Eine MPLS-Anbindung mit 20 Mbit/s kostet in der Schweiz je nach Anbieter und Standort schnell mehrere hundert Franken im Monat – eine vergleichbare Glasfaser- oder Kabelanbindung mit 500 Mbit/s oft weniger. Zusätzlich ist MPLS pro Design ein Stern- oder Vollvermascht-Netz zwischen deinen eigenen Standorten; direkter, performanter Zugriff auf Cloud-Dienste ist nicht vorgesehen, weil MPLS-Netze historisch für Rechenzentrums-zu-Rechenzentrums-Verkehr gebaut wurden, nicht für SaaS.

Wie SD-WAN das Problem angeht

SD-WAN ersetzt MPLS nicht zwingend, sondern stülpt eine Software-Steuerungsebene über beliebige Transportmedien. Ein Standort kann gleichzeitig eine güns­tige Internetleitung, eine bestehende MPLS-Leitung und eine 4G/5G-Backup-Karte haben – SD-WAN entscheidet in Echtzeit, welcher Pfad für welche Anwendung am besten geeignet ist, und baut bei Bedarf verschlüsselte Overlay-Tunnel zwischen den Standorten selbst auf.

Architektur: Underlay und Overlay im Detail

Das Verständnis von Underlay und Overlay ist der Schlüssel zu SD-WAN – und der Punkt, an dem viele Admins in Interviews oder beim Design ins Schwimmen geraten.

Underlay ist die physische, “dumme” Transportschicht: die tatsächliche Internetleitung, die MPLS-Leitung, die 4G/5G-SIM-Karte. Der Underlay weiss nichts von Anwendungen oder Policies, er transportiert einfach IP-Pakete von A nach B. Jeder Underlay-Link hat eigene Charakteristika: Bandbreite, Latenz, Jitter, Paketverlust, Kosten.

Overlay ist die logische Schicht, die SD-WAN über einen oder mehrere Underlays legt. Dabei baut jedes SD-WAN-Edge-Gerät (typischerweise eine Firewall-Appliance wie eine FortiGate, ein Cisco-Router mit vEdge/Catalyst-SD-WAN-Software oder eine VMware-VeloCloud-Edge-Appliance) verschlüsselte Tunnel – meist IPsec, teils mit proprietären Erweiterungen – zu allen anderen relevanten Standorten oder zu einem Hub auf. Auf dieser Overlay-Ebene laufen dann die eigentlichen Routing-Entscheidungen: Welche Anwendung nutzt welchen Tunnel, basierend auf Echtzeit-Messwerten des jeweiligen Underlays.

Standort Bern                          Standort Zürich (Hub)
┌─────────────────────┐               ┌─────────────────────┐
│  FortiGate Edge      │               │  FortiGate Hub       │
│                       │               │                       │
│  Underlay 1: Init7    │─IPsec Tunnel─▶│                       │
│  Glasfaser 100 Mbit/s │               │  SD-WAN Overlay       │
│                       │               │  (VPN-Zonen, Rules,   │
│  Underlay 2: 5G       │─IPsec Tunnel─▶│   Performance-SLA)    │
│  Swisscom Backup      │               │                       │
│                       │               │                       │
│  Underlay 3: MPLS     │─Legacy VPN───▶│                       │
│  (Restlaufzeit)       │               │                       │
└─────────────────────┘               └─────────────────────┘

Wichtig für die Praxis: Overlay-Tunnel werden zwischen SD-WAN-Zonen (bei Fortinet: SD-WAN-Interfacemitgliedern innerhalb einer Zone) organisiert, und die eigentliche Pfadwahl passiert über sogenannte Performance-SLA-Checks. Diese senden kontinuierlich Sondierungspakete (ICMP, TWAMP oder HTTP) über jeden Link zu einem Zielserver und messen Latenz, Jitter und Paketverlust in Echtzeit – nicht nur beim Verbindungsaufbau, sondern permanent im laufenden Betrieb.

Zero-Touch-Provisioning (ZTP)

Einer der grössten operativen Vorteile von SD-WAN gegenüber klassischem Router-Rollout ist Zero-Touch-Provisioning: Ein neues Gerät wird beim Hersteller vorregistriert (per Seriennummer), an der Filiale von einer beliebigen Person eingesteckt (Strom + Internet-Uplink), und zieht sich seine komplette Konfiguration automatisch aus der zentralen Management-Plattform – ganz ohne dass ein IT-Techniker vor Ort sein oder sich per CLI einloggen muss.

Ablauf am Beispiel Fortinet (FortiGate + FortiManager)

1. Vorbereitung im FortiManager: Ein Admin legt ein “Model Device” mit der Seriennummer des neuen Geräts an und verknüpft es mit einer Konfigurationsvorlage (Device Blueprint) für den Standorttyp “Filiale klein”.
2. Versand: Das Gerät wird unkonfiguriert an die Filiale geschickt – kein Vorab-Staging im Zentrallager nötig.
3. Einstecken vor Ort: Jemand vor Ort schliesst WAN-Port ans Internet und LAN-Port ans lokale Netz an, steckt Strom rein.
4. Callback: Die FortiGate meldet sich automatisch bei FortiDeploy (Fortinets Cloud-Broker-Dienst) und bekommt die Adresse des zuständigen FortiManagers mitgeteilt.
5. Tunnel + Config-Pull: Das Gerät baut einen sicheren Management-Tunnel zum FortiManager auf, authentisiert sich per Seriennummer oder Pre-Shared Key, und zieht sich automatisch die hinterlegte Konfiguration inklusive SD-WAN-Zonen, Firewall-Policies und VPN-Tunneln.

# FortiManager CLI: Model Device für ZTP anlegen (Beispielausschnitt)
config device-manager device
    edit "FGT-Bern-Filiale"
        set sn "FGT60F1234567890"
        set device_blueprint "Filiale-Klein-Template"
        set os_ver 7.4
    next
end

Ablauf bei Cisco Catalyst SD-WAN (ehemals Viptela)

Cisco nutzt das Plug and Play (PnP)-Portal und den vBond-Orchestrator: Das Gerät kontaktiert beim ersten Boot den PnP-Connect-Dienst, erhält die Adresse des vBond-Orchestrators, authentifiziert sich über Zertifikate und wird danach automatisch dem richtigen vManage-Controller zugeordnet, der die Konfiguration ausrollt.

Ablauf bei VMware VeloCloud

Bei VeloCloud (heute Teil von Broadcom) wird ein Edge-Gerät über einen Activation Key aktiviert: Der Techniker vor Ort (oder ein Ersteinrichtungs-Assistent per E-Mail an den Endkunden) gibt beim ersten Boot lediglich diesen Key ein, das Gerät kontaktiert den VeloCloud Orchestrator (VCO) in der Cloud und zieht sich sein Profil.

Application-aware Routing: Das Herzstück von SD-WAN

Application-aware Routing (auch “Application Steering” genannt) ist die Fähigkeit, den Datenverkehr nicht nur nach Ziel-IP, sondern nach erkannter Anwendung zu klassifizieren und pfadspezifisch zu behandeln. Der Klassiker: Microsoft-Teams-Traffic soll immer über die Leitung mit der niedrigsten Latenz und geringstem Jitter laufen (Sprache/Video reagiert empfindlich auf Jitter), während ein Backup-Job zur Cloud auch über die günstigste, aber langsamere Leitung laufen darf.

Wie die Erkennung funktioniert

Moderne SD-WAN-Lösungen nutzen Deep Packet Inspection (DPI) und/oder SSL-Zertifikats-Metadaten (SNI), um Anwendungen zu klassifizieren – oft mit vorgefertigten Signaturdatenbanken (bei Fortinet z. B. die Application-Control-Signaturen aus FortiGuard, bei Cisco die integrierte Application Recognition, NBAR2). Für verschlüsselten Traffic wie Microsoft 365 wird meist nicht der Inhalt entschlüsselt, sondern anhand von SNI, IP-Reputation-Listen und bekannten Microsoft-Endpunktbereichen klassifiziert.

Beispiel: Fortinet SD-WAN-Regel für Microsoft Teams

config system sdwan
    config service
        edit 1
            set name "Teams-Priority"
            set mode sla
            set dst "all"
            set internet-service enable
            set internet-service-name "Microsoft.Teams"
            set priority-members 1 2
            config sla
                edit 1
                    set health-check "SLA-Internet-Latency"
                    set id 1
                next
            end
            set tie-break cfg-order
        next
    end
end

config system sdwan
    config health-check
        edit "SLA-Internet-Latency"
            set server "8.8.8.8"
            set protocol ping
            config sla
                edit 1
                    set latency-threshold 100
                    set jitter-threshold 30
                    set packetloss-threshold 1
                next
            end
        next
    end
end

Diese Konfiguration sagt sinngemäss: “Erkenne Microsoft-Teams-Verkehr, prüfe kontinuierlich Latenz/Jitter/Paketverlust auf den priorisierten Links, und route den Traffic automatisch über den Link, der die SLA-Schwellenwerte (hier: unter 100 ms Latenz, unter 30 ms Jitter, unter 1 % Paketverlust) einhält.” Fällt ein Link unter diese Werte, schaltet SD-WAN transparent auf den nächstbesten Link um – ohne dass die Teams-Session abbricht, sofern der Wechsel schnell genug erfolgt (typisch innerhalb weniger Sekunden, abhängig vom Health-Check-Intervall).

Praxisfalle: Verschlüsseltes SaaS und QUIC

Ein Punkt, der in der Praxis oft übersehen wird: Viele moderne Cloud-Dienste (unter anderem Microsoft 365 und Google-Dienste) nutzen zunehmend QUIC/HTTP3 statt klassischem TCP. Ältere DPI-Engines erkennen QUIC-Traffic teils nicht korrekt und klassifizieren ihn als generischen UDP-Verkehr, wodurch die Application-Steering-Regel nicht greift. Prüfe bei jedem SD-WAN-Rollout, ob deine Firmware-Version und Signaturdatenbank aktuelle QUIC-Erkennung unterstützt – sonst läuft dein “priorisierter” Teams-Verkehr am Ende über den falschen Link.

Anbietervergleich: Fortinet, VMware/Broadcom, Cisco

Der SD-WAN-Markt wird laut aktuellen Marktanalysen von einer Handvoll Anbietern dominiert, wobei Fortinet, Cisco und Broadcom (ehemals VMware) regelmässig in den Leader-Segmenten der einschlägigen Marktanalysen (z. B. Gartner Magic Quadrant für SD-WAN) auftauchen. Für die Auswahl im Schweizer KMU-Kontext sind aber andere Kriterien oft wichtiger als die reine Marktposition.

Entscheidungsleitfaden für ein Schweizer KMU

Start
  │
  ├─ Bereits FortiGate-Firewalls im Einsatz?
  │     ja → Fortinet Secure SD-WAN prüfen (kein Zusatzgerät, ein Vendor)
  │     nein ↓
  │
  ├─ Starker Fokus auf Multi-Cloud (AWS/Azure/GCP direkt anbinden)?
  │     ja → VMware VeloCloud / Broadcom evaluieren
  │     nein ↓
  │
  ├─ Bereits grosse Cisco-Umgebung (Catalyst-Switches, ISE, etc.)?
  │     ja → Cisco Catalyst SD-WAN prüfen
  │     nein ↓
  │
  └─ Kein bestehender Vendor-Lock-in, < 10 Standorte, kleines IT-Team
        → Fortinet oder ein Managed-SD-WAN-Angebot eines Schweizer Providers
          (z. B. Init7, Swisscom, Opensystems) evaluieren – reduziert
          Betriebsaufwand für kleine Teams erheblich

Kostenoptimierung bei Multi-Standort-Szenarien

1. Breitband statt MPLS für Nicht-kritischen Verkehr

Der grösste Hebel: Bestehende teure MPLS-Leitungen durch Kombinationen aus Glasfaser/Kabel-Internet plus 4G/5G-Backup ersetzen. Ein Standort mit 2x Internet (Primär + Backup) statt 1x MPLS ist in den meisten Fällen sowohl günstiger als auch ausfallsicherer, weil zwei unabhängige physische Zugänge (idealerweise von unterschiedlichen Providern und über unterschiedliche Trassen) eine höhere Verfügbarkeit bieten als eine einzelne, wenn auch garantierte, MPLS-Leitung.

2. Lokaler Internet-Breakout statt zentralem Backhauling

Statt dass jede Filiale ihren gesamten Internet-Traffic über den Hauptsitz zur zentralen Firewall schickt (klassisches Hub-and-Spoke), erlaubt SD-WAN “Local Internet Breakout”: Cloud-/SaaS-Traffic (Microsoft 365, allgemeines Surfen) verlässt die Filiale direkt lokal ins Internet, während nur sicherheitskritischer oder interner Traffic zur Zentrale getunnelt wird. Das spart Bandbreite auf der teuren Zentrale-Leitung und reduziert Latenz für die Endanwender massiv, da der Umweg über die Zentrale entfällt.

3. Bandbreiten-Pooling und Load Balancing

Mehrere Underlay-Links können nicht nur für Failover, sondern gleichzeitig für Lastverteilung genutzt werden (“SD-WAN Rule: Load Balance” statt “Best Quality”). So lässt sich z. B. ein günstiger 200-Mbit/s-Glasfaseranschluss mit einem bestehenden 50-Mbit/s-Kupferanschluss kombinieren, ohne dass Letzterer brachliegt.

4. Lizenzmodell genau prüfen

Viele SD-WAN-Anbieter lizenzieren nicht (nur) nach Durchsatz, sondern nach Anzahl Geräten, Standorten oder als Subscription mit Security-Bundle (SASE). Rechne bei der Kalkulation nicht nur die Hardware, sondern die Total Cost of Ownership über 3-5 Jahre inklusive Support- und Feature-Lizenzen (z. B. FortiCare + FortiGuard-Bundles bei Fortinet, oder VeloCloud-Subscription-Tiers).

Sicherheitsaspekte und Fallstricke in der Praxis

Overlay-Segmentierung nicht vergessen: SD-WAN-Zonen sollten mit VLANs/Firewall-Zonen intern konsistent segmentiert werden. Ein Gastnetzwerk in der Filiale darf nicht denselben SD-WAN-Tunnel wie das interne Produktivnetz nutzen, sonst hebelst du deine Netzsegmentierung über die Hintertür aus.

Zertifikatsverwaltung bei SSL-Inspection: Wenn du SSL/TLS-Inspection auf den SD-WAN-Edges aktivierst, musst du ein internes CA-Zertifikat auf allen Clients verteilen (z. B. per Group Policy Object oder Intune-Konfigurationsprofil). Vergisst du das bei neuen Geräten, bekommen Nutzer Zertifikatswarnungen im Browser.

Internetausfall am Hauptsitz mit lokalem Breakout an Filialen: Wenn dein Hauptsitz als zentraler Identitäts- oder DNS-Anbieter fungiert (z. B. Active Directory, interner DNS-Server), aber Filialen ihren Internet-Traffic lokal rausschicken, kann bei einem Hauptsitz-Ausfall die Filiale zwar noch ins Internet, aber keine internen Ressourcen mehr auflösen. Plane redundante DNS-/AD-Standorte oder zumindest funktionsfähige Fallback-DNS-Einträge ein.

Firmware-Patch-Management für Edge-Geräte: SD-WAN-Edges sind exponierte, internetfacing Geräte – genauso patch-kritisch wie jede Firewall. Fortinet, Cisco und andere veröffentlichen regelmässig Security-Advisories für SD-WAN/FortiOS-Komponenten; ein verzögertes Patchen von Filial-Edges ist ein unterschätztes Einfallstor, weil Filialen im Betrieb oft weniger Aufmerksamkeit bekommen als der Hauptsitz.

Monitoring der Overlay-Performance, nicht nur der Verfügbarkeit: Ein Link kann technisch “up” sein, aber durch hohe Jitter-Werte für VoIP/Video unbrauchbar werden. Nutze die eingebauten SLA-Dashboards (FortiManager SD-WAN Monitor, vManage Application-Aware Routing-Übersicht, VeloCloud Orchestrator Edge-Health) aktiv und richte Alerts auf SLA-Verletzungen ein, nicht nur auf komplette Ausfälle.

# Beispiel: Einfacher externer Latenz-/Jitter-Check von einem Windows-Client
# zur groben Voreinschätzung eines Standort-Uplinks (kein Ersatz für SD-WAN-SLA-Messung)
1..20 | ForEach-Object {
    Test-Connection -ComputerName "8.8.8.8" -Count 1 |
        Select-Object -ExpandProperty ResponseTime
} | Measure-Object -Average -Maximum -Minimum

Migrationsschritte in der Praxis (Kurzübersicht)

1. Bestandsaufnahme: Aktuelle WAN-Links, Bandbreiten, Verträge und Kündigungsfristen pro Standort erfassen.
2. Anwendungsanalyse: Welche Anwendungen brauchen wirklich niedrige Latenz (VoIP, Terminalserver-Sessions) vs. welche sind unkritisch (Backup, E-Mail-Sync)?
3. Proof of Concept: Einen Pilotstandort (idealerweise eine kleinere Filiale, nicht der Hauptsitz) mit SD-WAN-Hardware ausstatten und parallel zur bestehenden Anbindung testen.
4. Zonen- und Regel-Design: SD-WAN-Zonen, Performance-SLAs und Application-Steering-Regeln zentral in der Management-Plattform definieren, bevor der Rollout in der Fläche beginnt.
5. Rollout per ZTP: Weitere Standorte per Zero-Touch-Provisioning ausrollen, jeweils mit kurzer Verifikationsphase (SLA-Dashboard prüfen, Sprachqualität testen).
6. Alte Leitungen terminieren: Erst nach stabiler Betriebsphase (empfohlen: mindestens 4-6 Wochen) alte MPLS-/Legacy-Leitungen kündigen.

Weiterlernen

• Fortinet: SD-WAN Architecture for Enterprise (offizielle Doku)
• Fortinet: Zero Touch Provisioning – FortiGate Cookbook
• Cisco: Catalyst SD-WAN Quick Start Guide
• Fortinet: SD-WAN vs. MPLS – Key Differences
• Gartner Peer Insights: SD-WAN Marktvergleich
• Open Systems: MPLS vs. SD-WAN im Detail (deutsch)

Verwandte Themen im Wiki: Routing-Grundlagen · Firewall-Grundlagen · VPN – Grundlagen · Zero-Trust-Architektur im KMU · Cloud-Migrationsstrategien

Videos

YouTube

YouTube