# Multi-WAN Deep Dive: Load Balancing & Failover in OPNsense

TL;DR / Management Summary Während wir in Artikel 551 primär den Ausfallschutz (Failover) betrachtet haben, nutzen wir beim Multi-WAN Load Balancing alle verfügbaren Internetleitungen gleichzeitig. OPNsense verteilt die Sessions der User statistisch über alle WAN-Ports. Ein Senior Admin kombiniert dies mit Policy-Based Routing, um z.B. VoIP über die stabile Glasfaser zu schicken und große Downloads über die günstige LTE-Leitung abzuwickeln.


# 1. Einführung & Konzepte

Session-basiertes Balancing.

Wichtig: Load Balancing in OPNsense erhöht nicht die Geschwindigkeit eines einzelnen Downloads (z.B. ein 10GB ISO), sondern die Gesamtbandbreite für viele parallele Anfragen.


# 2. Einrichtung in der Praxis

Vom Failover zum Balancing.

# Schritt 1: Gateways anlegen

Stellen Sie sicher, dass alle WAN-Interfaces korrekt konfiguriert sind und grüne Stati im Dashboard zeigen.

# Schritt 2: Balancing-Gruppe erstellen

System -> Gateways -> Group.

  1. Name: WANS_BALANCED.
  2. WAN1 (Fiber): Priority Tier 1.
  3. WAN2 (Cable): Priority Tier 1.

# Schritt 3: Sticky Connections (Kritisch)

Firewall -> Settings -> Advanced.


# 3. Deep Dive: Policy Based Routing (PBR)

Gezielte Verkehrssteuerung.

Manchmal wollen Sie das automatische Balancing umgehen.

  1. Erstellen Sie eine Firewall-Regel auf dem LAN-Interface.
  2. Source: Admin_Workstation.
  3. Gateway: Wählen Sie fest WAN1_Fiber (statt der Balancing-Gruppe).
  4. Ergebnis: Der Admin-PC nutzt immer die Glasfaser, während der Rest der Belegschaft über beide Leitungen balanciert wird.

# 4. Day-2 Operations: Weighting (Gewichtung)

Unterschiedliche Geschwindigkeiten kombinieren.

Was ist, wenn Leitung 1 (100 Mbit) schneller ist als Leitung 2 (50 Mbit)?


# 5. Troubleshooting & “War Stories”

Wenn die Sessions flappen.

# Top 3 Fehlerbilder

  1. Symptom: Webseiten melden ständig “Session Expired” oder fordern Login erneut an.

    • Ursache: Sticky Connections nicht aktiv oder Timeout zu kurz.
    • Lösung: Sticky-Timeout auf 3600s erhöhen.
  2. Symptom: Ein WAN-Port hat 100% Last, der andere 0%.

    • Ursache: Eine einzelne, langlaufende Verbindung (z.B. ein Backup-Stream) belegt ein Gateway. Neue Verbindungen werden zwar verteilt, fallen aber statistisch kaum ins Gewicht.
  3. Symptom: DNS-Fehler im Browser.

    • Lösung: Stellen Sie sicher, dass OPNsense DNS-Anfragen an beide WAN-Provider schicken kann. Nutzen Sie neutrale DNS-Server (8.8.8.8) und binden Sie diese fest an die jeweiligen WAN-Gateways.

# “War Story”: Der “Streaming” Kollaps

Ein Büro nutzte Load Balancing über Glasfaser und eine instabile Starlink-Leitung. Während Web-Browsing super funktionierte, brachen Teams-Konferenzen ständig ab. Die Entdeckung: Da Teams viele UDP-Ports nutzt, wurden die Voice-Pakete über WAN1 und die Video-Pakete über WAN2 geschickt. Der Microsoft-Server konnte die Streams nicht synchronisieren und trennte die Verbindung. Lösung: Wir erstellten eine Policy Route, die alle Microsoft-IP-Bereiche (via Alias, Artikel 555) zwingend über die stabilere Glasfaser (WAN1) schickt. Das Balancing blieb nur für den restlichen “Surf-Traffic” aktiv. Lehre: Realtime-Apps vertragen kein Load Balancing über verschiedene Provider. Nutzen Sie hierfür immer eine feste Leitung.


# 6. Monitoring & Reporting

Bandbreiten-Auslastung.

# Traffic Graphs

Reporting -> Health. Vergleichen Sie die Graphen von WAN1 und WAN2. Bei korrektem Balancing sollten die Kurven einen ähnlichen Verlauf zeigen (skaliert nach Gewichtung).


# 7. Fazit & Empfehlung

Multi-WAN Load Balancing ist der beste Weg, um günstige Consumer-Leitungen zu bündeln.


# Anhang: Cheatsheet

Modus Tiers Wirkung
Load Balancing Tier 1 / Tier 1 Gleichzeitige Nutzung
Failover Tier 1 / Tier 2 WAN2 nur bei Ausfall von WAN1
Partial Balancing Tier 1 (x2) / Tier 2 WAN1 & WAN2 balanciert, WAN3 Failover

# Referenzen