OPNsense Multi-WAN: Failover für KMU richtig einrichten

Multi-WAN-Setups gehören zu den am meisten missverstandenen OPNsense-Themen. Im Datenblatt klingt es nach “doppelte Bandbreite, doppelte Verfügbarkeit”; in der Praxis ist das oft eine Vereinfachung, die teuer kommen kann. Dieser Artikel ordnet ein, wie man echtes Failover zwischen zwei WAN-Verbindungen — typischerweise Glasfaser plus LTE/5G-Backup — auf OPNsense sauber konfiguriert, und warum Load-Balancing für die meisten KMU nicht die richtige Wahl ist.

Das Szenario

Typisches KMU-Setup, das wir bei DATAZONE einrichten:

• WAN1: Glasfaser, symmetrisch 500/500 Mbit/s, fester ISP-Vertrag, statische IP
• WAN2: LTE- oder 5G-Backup, asymmetrisch, monatliches Datenkontingent (z.B. 100 GB), wechselnde IP
• Anforderung: Bei WAN1-Ausfall automatisch auf WAN2 schwenken, VoIP-Telefonie nicht unterbrechen, kritische Services (Mail, ERP, VPN-Einwahl) weiter erreichbar

Ziel: Failover-only, kein Load-Balancing. Begründung dafür unten.

Gateways konfigurieren

In OPNsense lebt Multi-WAN auf der Ebene der Gateways. Pro WAN-Interface ist ein Gateway definiert (System → Gateways → Single). Wichtige Felder:

• Monitor-IP: nicht die ISP-Standard-Gateway-IP nehmen, sondern eine echte Public-IP des ISP-Internets — z.B. 1.1.1.1 (Cloudflare) oder 9.9.9.9 (Quad9). Warum: Der ISP-Router antwortet oft auch dann auf Pings, wenn die Verbindung “down” ist (technisch erreichbar, aber kein Internet). Eine echte Public-IP ist ein verlässlicherer Health-Check.
• Latency Threshold: Default-Werte (500 ms warning / 1000 ms alarm) sind für Glasfaser zu großzügig. Wir setzen typischerweise 200 ms / 500 ms.
• Packet Loss Threshold: 10% warning / 20% alarm — bei kleinerem Schwellwert schlägt das Failover bei normalen Schwankungen an.
• Probe Interval: 1 Sekunde
• Time Period: 60 Sekunden — Gateway gilt erst nach 60 Sekunden über Schwellwert als “down”

Diese Einstellungen sind ein Kompromiss zwischen Fehlertoleranz (kein Flapping) und Reaktionszeit (Failover binnen ~1 Minute). Wer schnelleres Failover braucht, kann auf 30 Sekunden Time Period gehen — riskiert dafür False-Positives bei kurzfristigen ISP-Schluckaufs.

Gateway-Group anlegen

Die Gateway-Group ist die zentrale Konfiguration für die Failover-Logik (System → Gateways → Group). Beispiel-Konfiguration:

Name: WAN_FAILOVER
Gateway Priority:
  - WAN1_GW: Tier 1
  - WAN2_GW: Tier 2
Trigger Level: Packet Loss or High Latency

Tier 1 wird verwendet, solange es “up” ist. Fällt es aus, schwenkt OPNsense auf Tier 2. Mehrere Gateways auf demselben Tier würden Load-Balancing aktivieren — was wir hier bewusst vermeiden.

Firewall-Regeln auf die Gateway-Group umstellen

Der eigentliche Hebel: Firewall-Regeln, die ausgehenden Traffic erlauben, müssen den Gateway-Group als Gateway-Auswahl bekommen — nicht das einzelne WAN-Gateway.

In Firewall → Rules → LAN für die Standard-Outbound-Regel (“from LAN net to any”):

• Advanced features → Gateway: WAN_FAILOVER statt default

Wer das vergisst, hat zwar funktionierende Gateway-Health-Checks, aber der Traffic nimmt weiterhin die System-Default-Route — die nicht failen kann, weil OPNsense sie statisch eingetragen hat. Klassischer Konfigurations-Fehler.

Outbound-NAT pro WAN

OPNsense default-NAT macht source-NAT auf die jeweilige WAN-IP. Bei Multi-WAN muss das pro WAN sauber funktionieren — sonst gehen Pakete über WAN2 raus, aber mit WAN1-Source-IP, und das ISP-LTE-Gateway droppt den Verkehr.

In Firewall → NAT → Outbound:

• Modus auf Hybrid Outbound NAT umstellen (Default ist Automatic)
• Manuelle Regeln pro WAN: “Source LAN net → Translation interface address WAN1” und “Source LAN net → Translation interface address WAN2”
• Wichtig: Reihenfolge ist nicht entscheidend, weil OPNsense die NAT-Regel passend zum gewählten Outgoing-Interface anwendet

Health-Check mit Monitor-IP — der wichtigste Teil

Wir haben das oben kurz erwähnt, hier ausführlicher. Die Monitor-IP entscheidet, ob das Failover funktioniert. Häufige Fehler:

• ISP-Gateway-IP als Monitor: ISP-Router pingen sich selbst weiter, auch wenn ihr Internet-Uplink down ist. Failover schlägt nicht aus.
• Eigene öffentliche IP als Monitor: macht keinen Sinn — geht über das gleiche Interface, was wir prüfen wollen, plus ggf. Asymmetrie-Probleme.
• Nicht erreichbare IP: gleicher Fehler in die andere Richtung — Gateway wird permanent als down erkannt.

Gut bewährt:

• WAN1 Monitor-IP: 1.1.1.1 (Cloudflare)
• WAN2 Monitor-IP: 9.9.9.9 (Quad9) — oder gezielt eine andere Public-IP als WAN1, damit nicht beide Monitor-Targets gleichzeitig ausfallen können (z.B. bei großem DDoS auf Cloudflare)

Sticky-Connections für VoIP

Das ist der Punkt, an dem die meisten Multi-WAN-Setups in der Praxis scheitern. VoIP-Verbindungen (SIP, RTP) tolerieren kein Mid-Call-Failover. Wenn mitten im Telefonat das Gateway wechselt, ändert sich die Source-IP für RTP, der SIP-Provider lässt die Pakete fallen, und das Gespräch reißt ab.

Lösung in OPNsense:

• Reply-To-Mechanismus: In den Firewall-Regeln (Advanced → Reply-to) sicherstellen, dass etablierte Verbindungen über das ursprüngliche Gateway weiterlaufen, auch wenn die Default-Route mittlerweile gewechselt hat.
• Sticky Connections (Firewall → Settings → Advanced → Sticky Connections aktivieren): erzwingt, dass eine bestehende Verbindung auf demselben Gateway bleibt.

Mit Sticky aktiv schwenken nur neue Verbindungen auf WAN2. Aktive Telefonate bleiben auf WAN1 — und reißen ab, wenn WAN1 wirklich down ist. Das ist akzeptabel: ein abgebrochenes Gespräch ist besser als jede Sekunde Pakete im Nirwana zu verlieren.

Load-Balancing — warum wir es selten empfehlen

Multi-Tier-Gateway-Groups mit zwei Tier-1-Gateways aktivieren Load-Balancing. Klingt verlockend (“doppelte Bandbreite!”), hat aber harte Praxis-Probleme:

• Sessions reißen: TCP-Sessions, die einmal auf WAN1 gestartet sind, müssen dort bleiben — Sticky ist Pflicht, sonst kollabiert HTTPS regelmäßig.
• Asymmetric Routing: einige Web-Anwendungen reagieren empfindlich auf wechselnde Source-IPs (Cookies, Session-Token, Captcha).
• Cloud-Anwendungen mit Geo-IP: Microsoft 365 oder Google Workspace bemerken, wenn der Source-IP zwischen ISPs hin und her springt — Account-Sicherheitsalarme sind die Folge.
• VPN-Performance: WireGuard und IPsec brechen bei Source-IP-Wechsel die Tunnel ab.
• Asymmetrische WAN-Bandbreite (z.B. 500 Mbit/s Glasfaser + 50 Mbit/s LTE) profitiert wenig vom Load-Balancing — die schnelle Leitung wartet auf die langsame.

Für die meisten KMU ist Failover-only die richtige Wahl. Load-Balancing macht Sinn für Hochlast-Setups mit zwei gleichartigen Symmetrie-Leitungen und Workloads, die kein Sticky brauchen (z.B. Backup-Replikation, Bulk-Downloads).

Was beim Failover passiert — Erwartungs-Management

Auch ein sauber konfiguriertes Failover ist keine unterbrechungsfreie Verbindung. Was tatsächlich passiert:

• Aktive TCP-Sessions reißen ab: HTTPS-Verbindungen, RDP, SSH — alle bestehenden Sessions terminieren. Browser laden danach neu, RDP-Clients reconnecten — meistens innerhalb 5-15 Sekunden.
• VPN-Tunnel müssen neu aufbauen: WireGuard ist schneller als IPsec (typischerweise unter 5 Sekunden), aber es gibt eine Unterbrechung.
• DNS-Caches enthalten alte Public-IPs: ausgehende Verbindungen können in den ersten Sekunden falsche Routen wählen — Dynamic DNS für eigene Services kann das mildern.
• VoIP: laufende Gespräche reißen ab (siehe Sticky), neue Anrufe gehen über WAN2.

Ein guter Failover-Plan kommuniziert das nach innen: “Bei WAN-Ausfall wechseln wir automatisch auf LTE. Es kommt zu einer 15–30 Sekunden Unterbrechung. Telefonate können abreißen — neu wählen. ERP-Webclient lädt neu.”

Monitoring und Alerting

Nach der Konfiguration muss sichergestellt sein, dass ein Failover bemerkt wird. OPNsense kann:

• E-Mail-Alert beim Gateway-Wechsel (System → Settings → Notifications)
• Webhook-Alert für Integration in Slack, Mattermost oder MS Teams
• Zabbix-/Prometheus-Polling über das OPNsense-Plugin/API

Wichtig: Nach Wiederherstellung des WAN1 schwenkt OPNsense automatisch zurück. Auch dieser Switch ist eine Alarm-würdige Event.

Testing — vor dem Ernstfall

Failover ohne Test ist hoffnungsbasiert. Was wir bei DATAZONE-Einrichtungen immer machen:

1. Kontrolliertes WAN1-Abschalten: WAN1-Kabel ziehen (oder ISP-Modem deaktivieren), Stoppuhr starten. Wann erkennt OPNsense den Ausfall, wann routet der erste Traffic über WAN2?
2. VoIP-Test während Failover: Während des Tests aktives Telefonat halten. Erwartet: Gespräch reißt ab. Neuer Anruf über WAN2 funktioniert.
3. VPN-Reconnect testen: Heimarbeitsplatz-VPN während Failover prüfen — baut der Tunnel auf der neuen WAN-IP wieder auf?
4. Failback-Test: WAN1 wieder aktivieren, prüfen ob OPNsense automatisch zurückschwenkt.

Dokumentiert das Ergebnis. Wenn das Setup das nächste Mal getestet wird (in 12 Monaten beim Wartungstermin), hat man eine Baseline.

Realistische Empfehlung für KMU

Für den typischen Mittelständler unter unserer Beratung:

• Eine schnelle, stabile Leitung (Glasfaser, ggf. SDSL als Bündel) als WAN1
• LTE/5G-Backup als WAN2 — mit Vertrag mit ausreichend Datenkontingent (bei Failover-Heavy-Tagen kann das Backup mehrere hundert GB verbrauchen)
• Failover-only-Setup, kein Load-Balancing
• Sticky-Connections an, Health-Checks auf echte Public-IPs
• Outbound-NAT pro WAN sauber konfiguriert
• Alerting auf den IT-Verteiler

Das ist ein Setup, das im Notfall hilft, ohne im Alltag Probleme zu erzeugen. Wer ein komplexeres Setup mit Load-Balancing braucht, sollte das mit Workload-Analyse begründen — nicht weil “Multi-WAN” im Datenblatt steht.

DATAZONE-Empfehlung

OPNsense Multi-WAN mit Failover-only ist Standard-Repertoire bei unseren Firewall-Setups. Wir richten das typischerweise mit zwei Stunden Vorbereitung und einem 30-Minuten-Test ein — das Resultat hält Jahre, solange ISP-Verträge und Hardware nicht wechseln.

Wer von pfSense kommt oder von einer alten Sophos/Fortinet-Lösung migriert, findet die Multi-WAN-Konfiguration in OPNsense gut strukturiert — die UI ist klar, die Logik nachvollziehbar.

Quellen und weiterführende Artikel

• OPNsense Documentation — Multi-WAN — offizielle Doku
• OPNsense vs. pfSense — Grundsatzvergleich
• WireGuard Site-to-Site VPN in 30 Minuten — für Site-Verbindungen
• WireGuard vs. OpenVPN 2026 Benchmark — VPN-Wahl bei Multi-WAN
• OPNsense VLAN Routing Best Practices — Netzwerk-Segmentierung
• Sophos/Fortinet Migration auf OPNsense — Migrationspfad

Wer Multi-WAN-Setup vom OPNsense-Experten konfiguriert haben will: gerne Termin vereinbaren — wir richten das auch remote ein.