WireGuard Handshake-Probleme: UDM Pro/SE hinter FritzBox (Exposed Host) – Schlüssel- und DNS-Problematik

    Hallo zusammen,

    ich brauche eure Hilfe bei einem hartnäckigen WireGuard-Problem. Ich versuche, von unterwegs (Android App) per VPN auf mein Heimnetz (UDM) zuzugreifen.

    Mein Setup:

    • Anschluss: htp Glasfaser (echtes Dual-Stack, öffentliche IPv4 vorhanden).
    • Modem/Router: FritzBox 7560 (IP: 192.168.0.xxx).
    • Gateway: UniFi Dream Machine Pro (UDM), angeschlossen an FritzBox.
    • Konfiguration: UDM ist in der FritzBox als Exposed Host eingetragen (feste IP 192.168.0.xxx).
    • DynDNS: DuckDNS (Status in FritzBox: "angemeldet").

    Das Problem: Ein Handshake kommt nur sporadisch oder gar nicht zustande. Wenn ich die Config in der WireGuard-App importiere, beobachte ich folgendes seltsames Verhalten:

    1. Schlüssel-Chaos: Nach dem Erzeugen eines neuen Users in der UDM scheint es oft so, als wären der Public Key im [Interface]-Bereich der App und der Public Key im [Peer]-Bereich identisch. Oder in der Coonfic Datei und im Client stimmen nicht mehr überein. Dadurch findet kein Handshake statt. (aktuell geht es in den letzten 24 Stunden)
    2. DNS-Abhängigkeit: Ein Handshake wird oft erst dann ausgelöst, wenn ich den DNS in der App manuell von der UDM-IP (192.168.xx.x) auf einen öffentlichen DNS (z.B. 8.8.8.8) ändere. Nach einem Trennen der Verbindung schlägt der nächste Aufbau meist wieder fehl.

    Ergänzung zum Problem ( "DNS-Abhängigkeit"):

    Ich habe jede Stunde versucht, die VPN-Verbindung über das Mobilfunknetz aufzubauen. Das funktionierte tadellos – bis heute Morgen. Ging es nicht mehr.

    Jetzt kommt das völlig bizarre Verhalten, das ich mir nicht erklären kann:

    1. Die Verbindung schlägt fehl (keine Antwort auf den Handshake).
    2. Ich gehe in der WireGuard-App auf den Stift (Bearbeiten).
    3. Ich ändere absolut nichts an der Konfiguration.
    4. Ich klicke einfach nur auf Speichern.
    5. Sofort danach funktioniert der Handshake und die Verbindung steht.

    Es wirkt so, als würde die WireGuard-App (oder das Android-System) die IP-Adresse hinter xxxxx.duckdns.org "einfrieren". Erst durch das "Abspeichern" der Config scheint die App gezwungen zu werden, den DNS-Namen komplett neu aufzulösen und die Verbindung mit der neuen IP frisch zu initialisieren.

    Hat jemand eine Idee, warum die App nicht von selbst merkt, dass die IP hinter der Domain nicht mehr stimmt? Gibt es eine Einstellung in der UDM oder in der App (z.B. Persistent Keepalive), die dieses Verhalten beeinflusst oder den DNS-Cache erzwingt?

    LG

    Quote from Kai202

    Es wirkt so, als würde die WireGuard-App (oder das Android-System) die IP-Adresse hinter xxxxx.duckdns.org "einfrieren". Erst durch das "Abspeichern" der Config scheint die App gezwungen zu werden, den DNS-Namen komplett neu aufzulösen und die Verbindung mit der neuen IP frisch zu initialisieren.

    Vorweg ich habe keine Ahnung von Android und dessen Aufsatz für WG Verbidungen.

    Aber das verhalten ist 100% das gleiche bei einem 08/15 WG das auf Linux läuft. WG erkennt von alleine nicht das die IP hinter dem DNS
    Eintrag eine andere ist und macht nur einmalig beim starten des tunnels eine abfrage. Genau dafür gibt es im Wireshark Packet ein Script
    das über Cron gestartet alles x Minuten schaut ob der Tunnel noch gut ist sonst den Halt mit der neuen IP startet.

    Wenn deine Android Aufsatz das gleiche macht... keine Ahnung.. andere APP ? (wie gesagt keine Ahnung von Android)

    Aber warum ändert sich die öffentlich IPv4 denn so oft am Anschluss?!?

    Und das Verhalten ist gar nicht so bizarr, denn durch das Speichern (ohne Änderung) startet der Tunnel neu und macht dann natürlich eine neue DNS Auflösung, wie von gierig schon beschrieben, ist es das Standardverhalten. Statt nix zu editieren, sollte theoretisch deaktivieren und anschließendes aktivieren des Tunnels in der App auch zu einer funktionierenden Verbindung führen.

    Auf Client Seite gibt es im Peer Abschnitt der Config folgenden optionalen Parameter. Der hat aber nix mit der Namensauflösung zu tun. Da geht es eher darum den Tunnel am Leben zu halten durch regelmäßiges Senden von "pings". Ist selten wirklich erforderlich und eher im Bereich NAT offen halten angesiedelt.

    Code
    PersistentKeepalive = 25

    Du kannst den Parameter aber gerne mal ausprobieren, da der Client seinen gegenüberliegenden Endpoint auch ohne DNS aktualisieren kann, wenn er nämlich ein Paket vom Wireguardserver von der neuen IP erhält. Allerdings dürfte das Paket den Client nicht erreichen, da das NAT bzw. die Firewall des Routers auf Clientseite das Ganze als neue eingehende Verbindung erkennen sollte und somit droppen müsste.

    Welche Wireguard App nutzt Du eigentlich? Und löst der DDNS nur auf IPv4 auf oder auch auf IPv6?


    Was das Schlüssel Chaos angeht - hab ich so noch nie gesehen.

    So, hier mal ein Update:

    1. App-Wechsel: Ich bin testweise auf die App WG Tunnel gewechselt. Interessanterweise funktioniert der Handshake hier nach einem IP-Wechsel deutlich zuverlässiger als mit der WireGuard-App. Ich habe es auf dem Handy (Androit, Mobilfunk) und Tablet (Android, WLAN) getestet. Wenn es mal hakt, reicht ein einfacher Reconnect.

    Bei der WireGuard-App ( aktuellste Version) musste ich oft die Config bearbeiten und speichern, damit sie wieder "aufwacht".

    2. DNS-Anpassung: bei einem Client habe ich testhalber im Bereich [Interface] beim DNS jetzt den Google DNS (8.8.8.8) vor die interne UDM-IP (192.168.xx.xxx) gesetzt. Das scheint die Auflösung der DuckDNS-Domain beim Tunnelstart zu stabilisieren.

    3. Das Schlüssel-Rätsel (Die eigentliche Anomalie): Hier brauche ich eure Expertise. Ich habe 4 Clients in der UDM Pro erstellt und die Config-Dateien verglichen. Dabei ist mir etwas völlig Unlogisches aufgefallen.

    Nehmen wir an, der Public Key der UDM (der in der App unter [Peer] stehen muss) lautet: DCeSms=

    • Client 1: [Interface] PrivKey = A | [Peer] PubKey = DCeSms= (Korrekt)
    • Client 2: [Interface] PrivKey = B | [Peer] PubKey = FJwrgtzh= (Falsch! Woher kommt dieser Key?) (aber er kann die Verbindung herstellen )
    • Client 3: [Interface] PrivKey = C | [Peer] PubKey = DCeSms= (Korrekt)
    • Client 4: [Interface] PrivKey = D | [Peer] PubKey = DCeSms= (Korrekt)


    Zusätzlich: In der UDM-Benutzeroberfläche werden mir für die Clients ganz andere Public Keys angezeigt als in den heruntergeladenen .conf-Dateien stehen. Warum generiert die UDM für Client 2 einen völlig fremden Peer-Public-Key, der gar nicht zum WireGuard-Server der UDM passt?

    LG

    Mein Netzwerk: FritzBox7560 - UDM PRO - USW 16-Port Gen2 - 2 x nanoHD - QunapNAS

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login