Site-to-Site VPN mit Unifi hinter einem Router o. Bridge-Modus, Sunrise mit DMZ

Karreng

Ausgangslage

Ich habe mich die letzten zwei Tage damit herumgeschlagen, eine VPN Verbindung zwischen zwei Standorten herzustellen, wobei an einem Standort eine Sunrise Internet-Box einem Unifi Gateway Fiber vorgeschaltet ist. Aufgrund des fehlenden Bridge-Modus bei Sunrise, konnte der Unifi Gateway die öffentliche IP nicht direkt auslesen. Es gibt zwar verschiedene Hinweise im Forum, die konnten das Problem jedoch nicht definitiv lösen. Ich habe nun mit claude.ai (sehr zu empfehlen) das Problem lösen können. Da ich davon ausgehe, dass auch andere User sich immer wieder mit diesem Problem befassen, habe ich Claude gebeten, eine kurze Anleitung zur Lösung des Problems zu schreiben.

Dieses Setup löst das Problem, wenn:

Beide Standorte betreiben ein UniFi Gateway (z.B. UXG-Fiber, UDM, UDM-Pro)
Standort A ein Modem/Router hat, der die öffentliche IP direkt weitergibt (kein NAT-Problem)
Standort B einen ISP-Router hat (z.B. Sunrise), der keinen Bridge-Modus unterstützt – nur DMZ ist möglich
Hinter dem ISP-Router auf Standort B steht das UniFi Gateway (Double-NAT)
Ziel ist ein Site-to-Site IPsec VPN zwischen beiden UniFi Gateways

—

Netzwerk-Übersicht

Standort AStandort BÖffentliche IP1.2.3.4 (via Modem)5.6.7.8 (hinter ISP-Router)ISP-Router / DMZ–192.168.2.0/24, DMZ auf 192.168.2.22UniFi WAN IP1.2.3.4 (direkt)192.168.2.22 (private DMZ-IP)UniFi LAN192.168.1.0/24192.168.3.0/24DDNShome-vpn.example.orgoffice-vpn.example.org

Wichtig: Beide LAN-Subnetze müssen verschieden sein!

—

Schritt 1: Kein CGNAT beim ISP

Auf Standort B sicherstellen, dass der ISP kein CGNAT verwendet. Bei CGNAT teilen sich mehrere Kunden eine öffentliche IP – eingehende Verbindungen sind dann unmöglich. In diesem Zusammenhang kann man bei Sunrise beantragen, dass die IPV4 freigeschaltet und CGNAT deaktiviert wird.

Prüfen: Die WAN-IP im ISP-Router muss identisch sein mit der IP auf whatismyip.com. Falls nicht, beim ISP eine dedizierte IPv4-Adresse ohne CGNAT anfragen.

—

Schritt 2: DMZ auf Standort B einrichten

Im ISP-Router auf Standort B:

DMZ aktivieren
DMZ-Zieladresse: 192.168.2.22 (WAN-IP des UniFi Gateways)

Damit wird aller eingehender Traffic ungefiltert an das UniFi Gateway weitergeleitet – inkl. IPsec (UDP 500 und UDP 4500).

Achtung: Einen allfällig konfigurierten VPN auf dem ISP-Router deaktivieren oder löschen. Dieser belegt sonst Port 500/4500 und blockiert den Traffic zur DMZ.

—

Schritt 3: DDNS einrichten

Da beide Standorte keine statische IP haben, brauchen wir DDNS. UniFi unterstützt verschiedene Anbieter nativ (z.B. Dynu, NoIP).

Auf beiden UniFi Consoles:

Settings → Internet → Dynamic DNS → Create

FeldWertServicedynu (oder anderer Anbieter)Hostnamez.B. home-vpn.example.orgUsernameDynu-BenutzernamePasswordDynu API Passcode (nicht das Login-Passwort!)Serverapi.dynu.com

Bei Dynu: Der API Passcode findet sich unter Control Panel → API Credentials – es ist die lange Zeichenkette, nicht das maskierte Passwort.

Prüfen: In Dynu unter DDNS Services nachschauen ob die angezeigte IP mit whatismyip.com übereinstimmt.

—

Schritt 4: Site-to-Site VPN einrichten

Auf Standort A (UniFi Console):

Settings → VPN → Site-to-Site VPN → Create

FeldWertNameStandort-BRemote IP/Hostnameoffice-vpn.example.orgVPN MethodRoute BasedTunnel IP10.0.0.1/30Remote Networks192.168.3.0/24Pre-shared KeyGenerieren und notieren

Advanced Settings:

FeldWertKey ExchangeIKEv2IKE EncryptionAES-128IKE HashSHA1IKE DH Group14IKE Lifetime28800ESP EncryptionAES-128ESP HashSHA1ESP DH Group14ESP Lifetime28800Local Authentication ID1.2.3.4 oder home-vpn.example.orgRemote Authentication ID5.6.7.8 oder office-vpn.example.org

—

Auf Standort B (UniFi Console):

Settings → VPN → Site-to-Site VPN → Create

FeldWertNameStandort-ARemote IP/Hostnamehome-vpn.example.orgVPN MethodRoute BasedTunnel IP10.0.0.2/30Remote Networks192.168.1.0/24Pre-shared KeyGleicher Key wie Standort A

Advanced Settings: Identisch wie Standort A, ausser:

FeldWertLocal Authentication ID5.6.7.8 oder office-vpn.example.orgRemote Authentication ID1.2.3.4 oder home-vpn.example.org

Kritisch: Der Pre-shared Key muss auf beiden Seiten exakt identisch sein. Am besten kopieren (Cmd+C / Ctrl+C) und auf der anderen Seite einfügen.

Warum die öffentlichen IPs als Authentication IDs? Das UniFi Gateway auf Standort B sieht als seine WAN-IP nur 192.168.2.22 (DMZ). Ohne explizite Local ID würde es sich mit dieser privaten IP authentifizieren – Standort A erwartet aber 5.6.7.8. Das führt zu AUTH_FAILED.

DDNS als Authentication ID: Anstelle der öffentlichen IPs können auch die DDNS-Namen (home-vpn.example.org / office-vpn.example.org) als Local und Remote Authentication ID eingetragen werden. Das hat den Vorteil, dass bei einem IP-Wechsel keine manuelle Anpassung nötig ist – der DDNS-Dienst übernimmt die Aktualisierung automatisch. Wichtig: Beide Seiten müssen konsistent entweder IPs oder DDNS-Namen verwenden, nicht gemischt.

—

Schritt 5: Verbindung prüfen

Via UniFi Console:

Settings → VPN → Site-to-Site VPN – Status sollte Online/Established sein.

Via Terminal (SSH oder UniFi Device Debug):

$$
ipsec status
$$

Erwartete Ausgabe:

$$
Security Associations (1 up, 0 connecting):
tunnel-name[1]: ESTABLISHED …
$$

Verbindung manuell starten (falls nötig):

$$
ipsec up <connection-name>
$$

Erreichbarkeit testen:

$$
ping 192.168.3.1 # Gateway Standort B
ping 192.168.3.x # Gerät auf Standort B (z.B. NAS)
$$

—

Häufige Fehler

ProblemUrsacheLösungAUTH_FAILEDKeys nicht identisch oder falsche Authentication IDsKeys neu setzen, IDs auf öffentliche IPs setzen0000000000000000_r (kein Responder)Traffic kommt nicht durchDMZ prüfen, VPN auf ISP-Router deaktivierenTunnel CONNECTING aber nie ESTABLISHEDBeide Seiten initiieren gleichzeitigEine Seite pausieren, dann neu startenDDNS zeigt falsche IPDouble-NAT, Synology meldet private IPDDNS direkt im UniFi Gateway einrichten

—

Hinweise

CGNAT muss beim ISP ausgeschlossen sein, sonst sind eingehende Verbindungen unmöglich
VPN auf ISP-Router deaktivieren – belegt Port 500/4500 und blockiert IPsec
Die Local IP im UniFi VPN-Formular wird automatisch gesetzt und zeigt bei Double-NAT die private DMZ-IP – das ist normal und kein Problem
IKEv2 explizit setzen – “Automatisch” wählt manchmal IKEv1, was zu Inkompatibilitäten führt
Bei dynamischen IPs: DDNS im UniFi Gateway einrichten (nicht auf Synology oder anderen Geräten), damit UniFi seine eigene IP korrekt meldet

oli-h

Dieses UniFi-Site-to-Site-Setup basiert wohl auf IPsec (Hinweis ist “…IKEv2…”).
Ich empfehle inzwischen (bzw. seit Jahren) “Wireguard” (anstatt “IPsec”). Jeder möge selber googlen nach “wireguard vs. ipsec” und sich eine eigene Meinung bilden.

Zudem sollte es auch mit CGNAT möglich sein ein Site-to-Site-VPN aufzubauen sofern eine Seite via Public-IP erreichbar ist. Zumindest mit Wireguard ginge das.

Es braucht aus meiner Sicht auch kein DynDNS auf beiden Seiten. Eine Seite genügt (die mit der Public-IP). Die andere Seite kann dann die Verbindung aufbauen.

Karreng

Hoi Oli

1. WireGuard statt IPsec

Da hast du natürlich recht. WireGuard ist moderner, schlanker, schneller und einfacher zu konfigurieren. IPsec habe ich gewählt, weil Unifi für Site-to-Site kein Wireguard anbietet. Aber es ist meines Wissens für Server-Client Umgebung möglich. .

2. CGNAT mit WireGuard lösbar

Da gebe ich dir auch recht. WireGuard sollte auch hinter CGNAT funktionieren, vorausgesetzt eine Seite eine erreichbare Public IP hat. Die andere Seite initiiert die Verbindung aktiv. Bei IPsec scheint das Protokoll bidirektionale Erreichbarkeit zu bevorzugen.

3. DDNS nur auf einer Seite nötig

Das kann gut sein. Ich hatte Mühe eine Verbindung herzustellen und habe es dann mal so versucht und es funktionierte.

Du scheinst dich in diesem Thema sehr gut auszukennen. Allenfalls könntest du ja eine Anleitung für das Aufsetzen mit Wireguard zur Verfügung stellen.

Xydocq

CGNAT ist Gift für eine Site2Site-VPN-Verbindung.

Im besten Fall funktioniert eine Client2Site-VPN-Verbindung. Dies kann eine Site2Site-VPN-Verbindung simulieren, solange nur zwei Orte miteinander verbunden werden sollen. Sobald man 3 oder mehrere Orte verbinden will, funktioniert dies nicht mehr. Ein wahres Site2Site-VPN benötigt feste IP Adressen oder zumindest DDNS an jedem Endpunkt. Ausgenommen davon sind nur Clients. In vielen Fällen bietet der Router-Hersteller eine eigene Lösung für DDNS an. Bei Fritz! ist es myFritz!, bei Zyxel ist es x.d2ns-nbl.com wenn man Nebula verwendet. Man kann natürlich auch seine eigene Lösung basteln mit eigener Domain.

Was die Sicherheit angeht, IKEv2 ist vermutlich gleich sicher, wenn nicht sicherer, als Wireguard. Wie jedes Protokoll haben beide ihre Schwachstellen.
Wireguard ist ein relativ einfach einzurichtendes Protokoll. IKEv2 ist da deutlich aufwendiger. IKEv1 oder IPsec/L2TP ist ein älteres Protokoll und gilt als eher unsicher. Jedoch gibt es immer noch Szenarien in denen dieses Protokoll verwendet wird.

Karreng

Dies ist eine Ergänzung zu meinem früheren Beitrag über das Einrichten eines Site-to-Site IPsec VPN zwischen zwei Standorten, wobei Standort B hinter einem ISP-Router (Sunrise) ohne Bridge-Modus steckt. Das IPsec Setup funktioniert, aber der Durchsatz auf dem UCG-Fiber ist auf ~900 Mbit/s begrenzt. Ich wollte WireGuard für bessere Performance ausprobieren.

—

Hardware

Beide Standorte: UniFi Cloud Gateway Fiber (UCG-Fiber)
Standort A: Modem im Bridge-Modus → UCG-Fiber (direkte öffentliche IP, kein Double-NAT)
Standort B: ISP-Router (Sunrise) im DMZ-Modus → UCG-Fiber (Double-NAT)
Beide Standorte unter demselben Ubiquiti-Konto verwaltet

—

Was nicht funktioniert hat: WireGuard VPN Server/Client

Mein erster Versuch war, den eingebauten WireGuard VPN Server auf Standort A zu nutzen und Standort B als VPN Client zu verbinden. Nach der Konfiguration erschien der Server in der UI als aktiv, aber auf dem Gerät wurde kein WireGuard-Interface erstellt. Habe verschiedenes probiert, aber nicht zum Laufen gebracht.

—

Was funktioniert hat: Site Magic SD-WAN (Mesh)

Da beide UCG-Fiber unter demselben Ubiquiti-Konto verwaltet werden, habe ich Site Magic SD-WAN ausprobiert.

Wichtig: Hub-and-Spoke Topologie hat nicht funktioniert, da Standort B eine Blackhole-Route für das übersetzte Subnetz erhält. Mesh-Topologie funktioniert korrekt mit den echten IP-Adressen.

Einrichtung

unifi.ui.com → oben links Site Manager
Oben rechts → SD-WAN → Create
Einstellungen:
- SD-WAN Name: beliebig
- Topology: Mesh ← wichtig, nicht Hub and Spoke
- Isolate Spokes: deaktivieren
Standort A auswählen → Networks: 192.168.1.0/24
Standort B auswählen → Networks: 192.168.3.0/24
Save

UniFi richtet den WireGuard-Tunnel automatisch ein – kein manuelles Konfigurieren nötig.

Verifikation

bash

$$
wg show
$$

Erwartete Ausgabe:

$$
interface: wgsts1000
public key: …
listening port: 20000
peer: …
endpoint: [öffentliche IP Standort B]:20000
latest handshake: X seconds ago
transfer: X KiB received, X KiB sent
$$

Site Magic verwendet Port 20000 (UDP) – nicht den üblichen WireGuard Port 51820.

Erreichbarkeit testen

bash

$$
ping 192.168.3.XX # NAS auf Standort B
$$

Mit Mesh-Topologie sind die echten IP-Adressen direkt erreichbar – keine Subnet-Translation nötig.

—

Hinweise

Double-NAT kein Problem: Site Magic funktioniert auch wenn Standort B hinter einem ISP-Router mit DMZ ist – Ubiquiti verwaltet die Verbindung automatisch über die Cloud
DDNS nicht nötig: Site Magic benötigt keine DDNS-Konfiguration – die Verbindung wird über den Ubiquiti-Account verwaltet
Hub-and-Spoke vermeiden: Bei dieser Topologie erhält der Spoke eine Blackhole-Route für sein eigenes übersetztes Subnetz, was die Verbindung blockiert
IPsec als Fallback: Das bestehende IPsec Site-to-Site kann parallel aktiv bleiben als Fallback