VPN-Vergleich: WireGuard (RouterOS↔FritzBox) vs. Cloudflare Zero Trust / WARP

Recherche-Report · Stand 2026-06-15 · Kontext: Multi-Site-Heimnetz FM / BF / DW, je eine FritzBox; Standort BF zusätzlich MikroTik hAP ax² (RouterOS 7.23.1), der künftig BF-Router wird. CF Zero Trust + WARP bereits im Einsatz (siehe DNS-Infra-Projekt).

TL;DR / Empfehlung

Hybrid, kein Entweder-Oder. Für ein Mesh über drei FritzBox-Standorte, von denen zwei (FM, DW) nur eine FritzBox haben, ist der saubere gemeinsame Nenner:

Site-to-Site-Backbone via natives WireGuard auf den FritzBoxen (FRITZ!OS ≥ 7.50), mit BF als Hub (MikroTik hAP ax² als WG-Server, da statisch erreichbar / als künftiger BF-Router ohnehin Endpoint). FM und DW sind WG-Clients zum Hub → Hub-&-Spoke-Mesh.
Cloudflare WARP/Zero Trust bleibt für Remote-User-Zugriff (Laptop/Handy von unterwegs → Heimnetze) und als Identitäts-/Access-Layer. Das tut es heute schon und ist dafür die bessere Lösung als ein klassisches Road-Warrior-WireGuard.

Warum nicht WARP für Site-to-Site? WARP/WARP-Connector kann eine FritzBox nicht direkt ansprechen — es braucht an jedem Standort einen Linux-Host hinter der FritzBox (WARP-Connector / cloudflared). An reinen FritzBox-Standorten (FM, DW) ist dieser Host nicht vorhanden und müsste erst beschafft/betrieben werden. Das erhöht Betriebsaufwand und Hardware-Fußabdruck, während die FritzBox WireGuard out-of-the-box kann.

Wichtigste Einschränkung beim WG-Pfad: mindestens ein Standort muss öffentlich erreichbar sein (kein CGNAT, idealerweise statisch oder DynDNS). Das wird der Hub (BF/MikroTik). Liegt BF selbst hinter CGNAT, kippt die Empfehlung — dann ist der CF-/WARP-Connector-Pfad (der ausschließlich ausgehende Verbindungen nutzt) der robustere Backbone.

1. Kann WARP eine FritzBox direkt ansprechen?

Nein. WARP (der Client) bzw. der WARP-Connector koppeln Netze nicht mit einer FritzBox-Gegenstelle, sondern mit Cloudflares Edge.

Der WARP-Connector ist Software (der Cloudflare-One-Client warp-cli im Headless-Modus bzw. cloudflared), die auf einem Linux-Host läuft und als Subnet-Router das gesamte hinterliegende LAN zu Cloudflare bringt. (CF One Docs – WARP Connector, Site-to-Site)
Damit ein FritzBox-LAN/-Dienst über CF erreichbar wird, muss also hinter der FritzBox ein Linux-Host stehen (Raspberry Pi, NUC, VM, Container), der den Connector betreibt. Die FritzBox selbst kann weder WARP-Connector noch cloudflared ausführen.
OS-Anforderung: WARP/Connector läuft auf Linux (apt-/yum-basiert: Ubuntu, Debian, CentOS, RHEL), außerdem Windows/macOS für reine Clients — nicht auf FRITZ!OS. (WARP-Client Docs)
Port-Footprint: der Connector-Prozess (cloudflared MASQUE-Pfad) alloziert ~50.000 Ports auf dem Host — also ein dediziertes Gerät, kein „nebenbei".

Konsequenz für FM/DW (nur FritzBox): Ohne zusätzlichen Always-on-Linux-Host kein WARP-Site-to-Site. An BF wäre ein Linux-Host theoretisch vorhanden/möglich, aber die FritzBoxen in FM/DW bleiben das Problem.

2. WireGuard FritzBox ↔ MikroTik – Interop & Gotchas

Machbar und erprobt. FRITZ!OS unterstützt WireGuard ab 7.50, RouterOS v7 hat WireGuard nativ. Mehrere dokumentierte Real-World-Setups koppeln genau diese beiden. (Bouni Blog 2026, Shaw-IoT Blog, MikroTik-Forum)

Rollenverteilung

MikroTik = Server (LISTEN auf z.B. UDP 51820), FritzBox = Client. Die FritzBox importiert eine WG-Config-Datei (.conf) unter Internet → Freigaben → VPN (WireGuard) und gibt dort den Endpoint des MikroTik an (IP oder DynDNS-Hostname).
Diese Richtung ist robust, weil der MikroTik der stabil erreichbare Hub ist und die FritzBox als Client persistent rauswählt.

Kritische Gotchas

Keine IP-Adresse auf dem WireGuard-Interface (MikroTik-Seite) setzen. Wird dem WG-Interface eine Adresse zugewiesen, bricht das Routing zwischen den Sites. Adressierung/Routing nur über AllowedIPs + statische Routes. (Der häufigste Stolperstein in allen Anleitungen.)
AllowedIPs = Tunnelnetz + jeweilige LAN-CIDRs. Beide Seiten müssen die LAN-Subnetze der Gegenstelle in AllowedIPs führen, sonst kein Cross-Site-Routing.
MTU. FritzBox nutzt typ. 1412 (WireGuard + IPv6 + PPPoE-Overhead); WG-Default ist 1420. Bei PPPoE/IPv6-Pfaden MTU angleichen, sonst Fragmentierung/Hänger.
PersistentKeepalive = 25 auf der FritzBox-(Client-)Seite für NAT-Traversal/Handshake-Stabilität.
Firewall (MikroTik): Input-Regel für UDP-Listen-Port + Forward-Regeln für den Cross-Site-Traffic; ggf. kein NAT zwischen den getunnelten Subnetzen.

NAT / Endpoint-Erreichbarkeit (der entscheidende Punkt)

WireGuard braucht mindestens einen öffentlich erreichbaren Endpoint. Ausgehende Verbindungen funktionieren auch hinter CGNAT, eingehende nicht. (Firewalla-Community, IPv64-Forum (DE))
Dynamische IP ist kein Problem, CGNAT schon. Der Hub (BF/MikroTik) muss also eine public IP haben (statisch oder via DynDNS/MyFRITZ). Dynamische public IP → DynDNS-Hostname als Endpoint (FritzBox akzeptiert FQDN-Endpoints; in einem dokumentierten Fall kam der Handshake erst mit FQDN statt roher IP zustande).
Wenn der Hub hinter CGNAT liegt: Hub-&-Spoke über WireGuard ist dann nicht direkt machbar (keine Seite eingehend erreichbar). Optionen: ISP-Option „echte IPv4"/DS-Lite-Ausnahme, IPv6-only-Tunnel (nur wenn alle Sites stabiles IPv6 haben), oder Umstieg auf den CF-/WARP-Connector-Pfad (nur ausgehend → CGNAT-immun).

Kann der MikroTik-Hub den Container-Weg gehen statt nativem WG?

Nicht empfehlenswert auf dem hAP ax²: 1 GB RAM, aber nur 128 MB Onboard-Flash und kein USB. Container (cloudflared/WireGuard-Image) brauchen Netzwerk-Storage als Workaround — fragil. (MikroTik-Forum: hAP ax2 storage & containers) → Natives RouterOS-WireGuard nutzen, nicht containerisieren.

3. Pro / Contra im Direktvergleich

Kriterium	(A) WireGuard FritzBox↔MikroTik (Hub=BF)	(B) Cloudflare Zero Trust / WARP(-Connector)
Performance	Direkter Tunnel, kein Umweg über Edge → niedrigste Latenz, voller LAN-Speed (CPU/MTU-limitiert).	Traffic läuft über Cloudflare-Edge (Hairpin) → Zusatz-Latenz; auf Free-Plan Daten-Cap (10 GB Free, danach 15 GB/User; Mehrverbrauch $1/GB).
Admin-Aufwand	Einmalige WG-Config je Site; FritzBox-Import per `.conf`; keine zusätzliche HW an FM/DW. Gotchas (keine Interface-IP, MTU) müssen sitzen.	Linux-Host je Site nötig (Beschaffung + Betrieb + Updates), v.a. an reinen FritzBox-Standorten FM/DW. Zentrale Policy/Routes im CF-Dashboard.
NAT-Traversal	Braucht 1 public Endpoint (Hub). CGNAT am Hub = K.O.	CGNAT-immun — Connector baut nur ausgehende Verbindungen zur Edge auf. Stärke dieses Pfads.
Zuverlässigkeit	Sehr hoch, solange Hub erreichbar; keine Cloud-Abhängigkeit. SPOF = Hub-Site.	Abhängig von Cloudflare-Verfügbarkeit + Linux-Host je Site (mehr bewegliche Teile).
Kosten	0 €, Hardware vorhanden (FritzBoxen + hAP ax²).	Free-Plan bis 50 User, per-User-Modell, kein Bandbreiten-Preis — aber Daten-Cap + Bedarf an zusätzlicher Linux-HW/Strom je Site. (CF ZT Plans)
Observability	RouterOS-Logs/Torch/Traffic-Monitor (gut, lokal). FritzBox: spärlich. Kein zentrales Dashboard.	Zentrales CF Zero Trust Dashboard, Logs, Device-Posture, Access-Policies, Audit. Klar überlegen.
Fit zum Bestand (CF One/WARP)	Orthogonal — koexistiert problemlos mit CF-DNS-Filtering (CGPS) und WARP-Remote-Access.	Nutzt vorhandene CF-One-Tenant; konsistente Identität/Policy. Aber erzwingt HW-Ausbau an FritzBox-only-Sites.
Remote-User-Zugriff (unterwegs)	WG-Road-Warrior je Site separat zu pflegen.	Stärke von WARP — ein Client, Identitäts-basiert, Split-Tunnel, Posture. Bereits live.

4. Empfehlung für FM / BF / DW

Backbone = WireGuard, Remote-Access = WARP. Konkret:

Site-to-Site-Mesh über natives WireGuard.
- Hub = BF / MikroTik hAP ax² als WG-Server (nativ, kein Container). Setzt public IP an BF voraus (statisch oder DynDNS/MyFRITZ; kein CGNAT).
- FM und DW = FritzBox-WG-Clients zum BF-Hub (Hub-&-Spoke). Damit brauchen die reinen-FritzBox-Standorte keinen zusätzlichen Host.
- Gotchas beachten: keine IP aufs WG-Interface (MikroTik), AllowedIPs = Tunnelnetz + alle LAN-CIDRs, MTU 1412, PersistentKeepalive=25, MikroTik-Firewall Input/Forward.
- Optional FM↔DW direkt (full mesh) nachrüsten, sobald beide einen erreichbaren Endpoint haben — sonst läuft FM↔DW über den BF-Hub.
WARP / Zero Trust bleibt für Remote-User (Laptop/Handy von außerhalb → Heimnetze) und als Identitäts-/Access-/Observability-Layer. Kein Umbau des bestehenden CF-One-Einsatzes nötig; ergänzt das WG-Backbone statt es zu ersetzen.
Trigger zum Umschwenken auf den CF-WARP-Connector-Pfad als Backbone: Falls BF (oder kein Standort) eine eingehend erreichbare public IP hat (CGNAT/DS-Lite ohne Ausweg). Dann an jedem Standort einen kleinen Linux-Host (Pi o.ä.) mit WARP-Connector, weil dieser nur ausgehend verbindet und damit CGNAT-immun ist — zulasten von Zusatz-HW, Edge-Latenz und Daten-Cap.

Voraussetzung-Check vor Umsetzung: WAN-Anbindung jedes Standorts prüfen (public vs. CGNAT/DS-Lite, statisch vs. dynamisch, IPv4/IPv6). Das entscheidet zwischen Pfad A (mind. Hub public) und Pfad B (CGNAT-tolerant).

12 KiB Raw Permalink Blame History Unescape Escape