UniFi: Standorte per Site-to-Site-VPN verbinden
Auf einen Blick
| Gilt für | UniFi Cloud Gateways und UniFi-Gateways mit UniFi Network 9.0.108 oder neuer (Stand 10.x); Gegenstellen UniFi, OPNsense, Sophos, FortiGate u. a. |
|---|---|
| Bereich | Netzwerk-Hardware |
| Dauer | ca. 15 Minuten (SD-WAN) bis 1 Stunde (IPsec zu Fremdgeräten) |
| Rechte | Besitzer des UI-Kontos (für SD-WAN), Administrator in UniFi Network |
| Stand | Oktober 2026 |
Standorte per Site-to-Site-VPN mit UniFi verbinden heißt, die Netze von Zentrale, Filialen oder Rechenzentrum über verschlüsselte Tunnel durch das Internet zu koppeln, sodass Server und Drucker an allen Standorten erreichbar sind. UniFi bietet dafür zwei Wege: SD-WAN (früher Site Magic), das Tunnel zwischen UniFi-Gateways über den Site Manager automatisch aufbaut, und klassisches IPsec bzw. OpenVPN für die Verbindung zu Firewalls anderer Hersteller. Dieser Artikel zeigt beide Wege, die passenden Topologien und die typischen Fehlerquellen.
Welcher Weg?
| Variante | Gegenstelle | Einrichtung | geeignet für |
|---|---|---|---|
| SD-WAN Hub-and-Spoke | nur UniFi-Gateways | Site Manager, wenige Klicks | Zentrale mit Filialen; bis 1.000 Tunnel am Hub, Failover-Hub möglich |
| SD-WAN Mesh | nur UniFi-Gateways | Site Manager | bis zu 20 gleichberechtigte Standorte, die direkt miteinander sprechen |
| IPsec | UniFi oder Fremdhersteller, Cloud (AWS, Azure) | pro Gateway manuell | Anbindung von Firewalls anderer Hersteller und Cloud-Netzen |
| OpenVPN Site-to-Site | UniFi oder Fremdhersteller | pro Gateway manuell | Sonderfälle, wenn IPsec nicht möglich ist |
Grundregel: Adressplan
Jeder Standort braucht eigene, nicht überlappende Netze, z. B. Zentrale 10.10.0.0/16, Filiale 1 10.11.0.0/16, Filiale 2 10.12.0.0/16. Haben alle Standorte noch das Werksnetz 192.168.1.0/24, vorher umstellen. SD-WAN Hub-and-Spoke kann Überschneidungen zwar per NAT überbrücken, dann sind aber nur Verbindungen von der Filiale zur Zentrale möglich.
Variante 1: SD-WAN zwischen UniFi-Gateways
Voraussetzungen
- UniFi Network 9.0.108 und Gateway-Firmware 4.1.3 oder neuer.
- Alle Gateways gehören demselben UI-Konto (Besitzer) bzw. derselben Fabric. SD-WAN kann nur der Besitzer verwalten.
- Hub: öffentliche IP-Adresse und ein dafür vorgesehenes Modell (u. a. UDM Pro, UDM SE, UDM Pro Max, UCG Fiber, EFG). Spokes: fast alle Cloud Gateways.
- Mesh: mindestens ein Gateway mit öffentlicher IP-Adresse.
- Das klassische USG wird nicht unterstützt, IPv6 im Tunnel noch nicht.
Hub-and-Spoke einrichten
- Im Site Manager (unifi.ui.com) Settings › SD-WAN öffnen, Hub & Spoke wählen, Gruppe benennen.
- Hub-Topologie: Single (ein Hub), Failover (zweiter Hub als Reserve) oder Distributed (Spokes auf mehrere Hubs verteilt).
- Tunnel-Architektur:
- Max Resiliency – bis zu 4 Tunnel pro Spoke (jede WAN-Kombination), keine Unterbrechung bei Ausfall eines Anschlusses,
- Redundant – 2 Tunnel, ebenfalls unterbrechungsfrei,
- Scalable – 1 Tunnel, kurze Unterbrechung bei Failover.
- Am Hub die Netze auswählen, die den Filialen bekannt gemacht werden; ggf. zusätzliche Routen (z. B. Netze hinter einem weiteren VPN).
- Für die Spokes die freizugebenden Netze wählen. Optionen:
- Isolate Spokes – Filialen erreichen nur die Zentrale, nicht einander (setzt die zonenbasierte Firewall voraus),
- Auto-Scale and NAT Spoke VPNs – nur bei überlappenden Netzen.
- WAN-Anschlüsse für VPN und Failover festlegen und speichern. Die Tunnel bauen sich automatisch auf.
Mesh einrichten
Settings › SD-WAN › Mesh, bis zu 20 Standorte auswählen, je Standort die freizugebenden Netze markieren, Connect. Jeder Standort hat dann einen direkten Tunnel zu jedem anderen; die Firewall-Regeln müssen an jedem Standort gepflegt werden.
Gut zu wissen
- Die Gateways tauschen ihre Routen per OSPF im Tunnel aus. Sind Netze trotz aktivem Tunnel nicht erreichbar, blockiert oft eine eigene Firewall-Regel der Zone VPN zum Gateway den OSPF-Verkehr.
- Ändert sich die öffentliche IP eines Standorts, passen sich die Tunnel automatisch an.
- Fällt die Cloud aus, bleiben bestehende Tunnel aktiv; Änderungen sind dann aber nicht möglich.
- Eine Übertragung der Besitzerschaft eines Gateways trennt dessen SD-WAN-Verbindungen.
Variante 2: IPsec zu einer Fremd-Firewall
Beispiel: Filiale mit UniFi-Gateway an eine Zentrale mit OPNsense.
Schritt 1: Parameter abstimmen
Beide Seiten müssen exakt übereinstimmen:
| Parameter | Empfehlung | UniFi-Standard |
|---|---|---|
| VPN-Typ | route-based (VTI) auf beiden Seiten | route-based |
| IKE-Version | IKEv2 | – |
| Phase 1 (IKE) | AES-256, SHA-256, DH-Gruppe 14 oder höher, Lifetime 28800 s | AES-128, SHA1, 28800 s |
| Phase 2 (ESP) | AES-256, SHA-256, PFS mit DH-Gruppe 14, Lifetime 3600 s | AES-128, SHA1, 3600 s |
| Authentifizierung | langer Pre-Shared Key (wird automatisch erzeugt) | – |
| Modus | Main Mode | nur Main Mode, kein Aggressive Mode |
UniFi bezeichnet DH-Gruppen mit Nummern; andere Hersteller schreiben z. B. „MODP 2048“ – das entspricht Gruppe 14. Die UniFi-Standardwerte AES-128/SHA1 funktionieren, für neue Verbindungen sind stärkere Verfahren zu empfehlen.
Schritt 2: Tunnel auf UniFi anlegen
- Settings › VPN › Site-to-Site VPN › Create New, Protokoll IPsec.
- Pre-Shared Key übernehmen oder eintragen.
- Local IP: WAN-Adresse des Gateways; Remote IP / Hostname: öffentliche Adresse der Gegenstelle.
- Remote Networks: die Netze der Zentrale (bei route-based werden dafür statische Routen angelegt; mit OSPF None wählen und eine Tunnel-IP vergeben).
- Unter Advanced von Auto auf Manual und die abgestimmten Parameter eintragen.
- Speichern. Firewall-Regeln und Routen für den Tunnel legt UniFi automatisch an.
Die Gegenseite auf OPNsense beschreibt OPNsense - IPsec Site-to-Site route-based.
Hinter NAT
Hat das UniFi-Gateway keine öffentliche Adresse (Provider-Router davor), schlägt der Aufbau oft fehl, weil die Gegenstelle eine andere Absenderadresse erwartet. Abhilfe: auf der UniFi-Seite die öffentliche Adresse als Local Authentication ID eintragen – oder auf der Gegenseite die private Adresse als Remote Authentication ID. Neben IP-Adressen sind auch Hostnamen und E-Mail-Adressen als ID möglich.
Policy-based nur, wenn nötig
Manche Geräte beherrschen nur policy-based IPsec. Dann auf UniFi ebenfalls policy-based wählen; lokale und entfernte Netze müssen auf beiden Seiten exakt gleich eingetragen sein. Bricht der Tunnel mit IKEv2 und mehreren Netzen ab, hilft das Aufteilen der Netze oder IKEv1.
Firewall für Standortverkehr
Tunnel-Verkehr läuft über die Zone VPN. Ab Werk darf ein Standort alles im anderen erreichen. Für eine Trennung (z. B. Filialen nur auf Warenwirtschaft und Fileserver der Zentrale) Richtlinien von der Zone VPN zu Internal bzw. eigenen Zonen anlegen, siehe UniFi: Zone-Based Firewall konfigurieren.
Kontrolle und Fehlersuche
- Tunnel kommt nicht hoch: öffentliche Adressen, Pre-Shared Key, IKE-Version und Verschlüsselungsparameter vergleichen; liegt ein Gateway hinter NAT, Authentication ID setzen.
- Tunnel steht, aber kein Verkehr: zwischen zwei Clients testen, nicht vom Gateway aus; Windows-Firewall lässt Ping oft nicht zu; eigene Firewall- oder Traffic-Regeln prüfen.
- Nur ein Teil der Netze erreichbar (policy-based): Netzlisten auf beiden Seiten vergleichen.
- Domänencontroller am anderen Standort: Ist der Inhaltsfilter aktiv, braucht die interne Domäne eine DNS-Weiterleitung – siehe UniFi: IDS/IPS und CyberSecure einrichten.
Hinweise
- Bandbreite: Der VPN-Durchsatz hängt vom Gateway-Modell und den Anschlüssen beider Standorte ab; die Werte stehen auf techspecs.ui.com.
- Zweiter Anschluss: Für Filialen mit kritischen Anwendungen einen zweiten Internetzugang (z. B. LTE/5G) als Failover einplanen.
- Bei Planung und Betrieb Ihrer Standortvernetzung unterstützt Sie die Managed Firewall von m.a.x. it.
Siehe auch
- Ubiquiti UniFi – Überblick und alle Artikel der Reihe
- UniFi: VPN für den Fernzugriff einrichten
- UniFi: Mehrere Standorte mit dem Site Manager verwalten
- OPNsense - IPsec Site-to-Site route-based
- IPsec
- SD-WAN
- OSPF
Links und Quellen
- Ubiquiti Help Center: Setting Up SD-WAN with UniFi Site Manager and Fabrics
- Managed Firewall von m.a.x. it
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
