Hey, wegen des Fritzbox Problems wurde unter dem YouTube Video eine Lösung erwähnt,. Ist dies hier gemeint?
Bin aber nicht 100% sicher ob ich das verstanden habe.
Das werde ich mal testen, obwohl wenn der Interface Part weggelassen wird, dann gibt es ja keine Tunnel IP mehr. Dann wird einfach blind ein Paket in ein Loch geworfen. Klingt alles sehr komisch. Ist das Loch IPv4? IPv6 ? Sehr sehr komisch.
Die FritzBox erstellt das Interface selber für sich. Habe es selber auch mal versucht mit einem eigenen Interface, jedoch auch nur mit Problemen.
Mir scheint so, als würde die FritzBox nur korrekt mit einem Interface arbeiten, bei dem die Interface-IP gleich der eigenen IP ist.
Moin, mir ist in meinen Tests heute noch etwas aufgefallen.
Seid dem „reset“ für die neuen Funktionen, habe ich nur noch 8MBits Bandbreite, obwohl ich in der Supporter Klasse bin und das auch so auf der Seite angezeigt wird.
Denke mal da ist nur eine Zeile verrutscht 
Um es nochmal etwas Bildlicher dar zu stellen:
Bei einer S2S Verbindung will man ja 2 Netzte via VPN Tunnel zu vernetzen, jeder hat also sein eigenes Subnetz.
Was du in dem Video versucht hast, ist quasi bei einer S2S Verbindung der FritzBox eine Client IP aus dem Netz vom CloudRouter zu geben, was eigentlich nicht Sinn einer S2S Verbindung ist.
Der CloudRouter hat das Netz 10.7.0.0/24
Meine FritzBox das Netz 192.168.10.0/24
Für eine S2S Verbindung geht man, so wie ich es aus der Wireguard Doku verstehe lediglich hin und gibt jeweils eine Konfig in dieser Art:
CloudRouter:
[PEER]
PublicKey: von FritzBox
Endpoint: xxxxxx
AllowedIp: 192.168.10.0/24
FritzBox
[PEER]
PublicKey: von CloudRouter
Endpoint: xxxxxx
AllowedIp: 10.7.0.0/24
Die Interface IP ist dabei jeweil die IP vom jeweiligem Router:
CloudRouter: 10.7.0.1
FritzBox: 192.168.10.1
Die FritzBox setzt entsprechend dann auch die passende Route zum CloudRouter, die unter AllowedIP angegeben wurde
Kann das sein das du noch das „alte“ Premium hast und nicht das Supporter ?
Also für mich und mein Wissen ist das nicht eine valide WireGuard config. Ich werds mal probieren, aber hintergrund wird sicher ein Tunnelnetzwerk entstehen.
Und bei Cloud-Router steht bei dir 8 Mbit/s obwohl supporter? Screenshot!
Dann sag das doch auch. Und sag nicht bei mir steht aber 8 Mbit/s… da steht 50mbit.
Geh mal bitte hin und ändere 1x die IP vom Gateway und dann wieder zurück.
Er sollte dann die Queue erneut setzen.
Oder leg mal innerhalb des Router ein neues VPN Gateway an und lösch es wieder.
1 „Gefällt mir“
Das hat geholfen. 
Danke für die schnelle Hilfe.
Warum meckert das Unifi-Gateway, wen ich die wg-config von Dir übernehme?
[Interface]
Address = 10.7.0.3/32,fd64::3/128
…
ist lt. unifi ungültig, will er nicht
[Interface]
Address = 10.7.0.3/32
ohne ipv6 geht es dann. - Kann der VPN-Client auf dem unifi-Gateway nur IPv4 und nicht beides gleichzeitig?
Unifi… IPv6… WireGuard…
UniFi ist noch nicht so weit. Die Config stimmt, aber unifi lebt halt im jahr 1991 IPv4 only
… ok, dann warten wir mal, bis sie 2025 ankommen… aber ipv4 läuft, klappt auch. 
…danke für das Neue Feature!
Moin,
also ich bin da so eher der visuelle Typ. Fand die Videos immer super wenn du Bilder gemacht/gezeigt hast.
Beide Tunnel stehen. Jetzt für mich nur nicht ganz klar an welchen Stellen überall Routen installiert werden müssen.
So sieht das aus, wenn der Cloud Router Traffic verbraucht ist. Die Bandbreite wird sofort für alle Router auf 2M gedrosselt, funktioniert aber weiter uneingeschränkt.
Also ich hab jetzt hin her und zurück… Bei mir geht das nicht. Klingt mir auch alles sehr komisch.
Für meine Begriffe braucht WireGuard richtige Tunnel IP um kommunizieren zu können.
hast du es mittlerweile hinbekommen, auf die Geräte hinter der UMD Pro zu kommen? Ich komme mittlerweile auch auf die UDM Pro aber nicht auf den Debian Server oder die Synology NAS danach.
Neben der Dinge auf ipv64 + UDM Pro habe ich auch noch an die Firewall der Geräte an sich gedacht. Also die NAS bzw. Debian Server