USG3: Provisionierungs-Loop nach Wireguard Installation

Es gibt 17 Antworten in diesem Thema, welches 3.912 mal aufgerufen wurde. Der letzte Beitrag () ist von razor.

  • Liebe Leute,


    ich bin hier ganz neu und hoffe auf Eure Hilfe! Habe nach dieser Anleitung von razor Wireguard auf meinem USG3 installiert. Anschließend config.gateway.json ins Controler-Verzeichnis /var/lib/unifi/sites/default auf mein Linux NUC kopiert und Provisionierung angestoßen. Die bleibt dann immer bei 95 oder 96% stehen.

    Ich habe die Wireguard Installation vom USG wieder entfernt und Schlüssel gelöscht und nach Reboot des USG alles nochmal neu installiert, leider ohne Erfolg. Die Provisionierung bleibt wieder hängen.


    Was kann ich tun? :thinking_face:


    USG-3P : 4.4.57.5578372

    Controler: Aktuelle Version 7.4.156 (Build: atag_7.4.156_21011)


    Ich hänge die config mal an...


    Vielen Dank


  • Ein Bootloop nach einspielen einer config.gateway.json deutet meistens darauf hin das ein formatierungs Fehler in der Json ist, Komma falsch gesetzt oder Semikolon an falscher stelle ect. ect.

    Daher Json nochmals prüfen oder es gibt online Tools welche es machen können.

  • Hallo martinbln ,


    das schaffe ich vor dem Kino nicht mehr zu lösen. Falls Du aktuell via USG nicht ins Internet kommen solltest: Datei umbenennen und Provisioning forcieren (über den Controller "auf" dem USG). Dann sollte erstmal alles wieder laufen. Es kann sein, dass Du im Anschluss noch einen Reboot machen musst - falls nötig.


    Gruß aus 1234*.

  • Hallo martinbln ,


    die richtige WireGuard-Version hast aber geladen, oder? Die unterscheiden sich.


    Nur, um sicher zu gehen. :winking_face:

  • ugw3-v1-v1.0.20220627-v1.0.20210914.deb sollte für eine USG3 richtig sein?


    Ich habe mal diese config versucht, die frisst das USG anstandslos...


    Bei meiner (ersten, fehlerhaften?) config von oben ist eigtl. nur eine Firewall-Einstellung zusätzlich dabei, die wird nach dem Hochladen (und dem Dauer-Provisionieren...) auch in der GUI angezeigt.


    Was bei beiden configs übrigens nicht in der GUI erscheint nach Provisionierung ist der Eintrag zu "remote_user_vpn_network". Soll das so sein? Bzw. wo würde das auftauchen?


    Im Ergebnis hätte ich gerne eine WireGuard-config um mittels S2S (von einem 2. USG3) und RoadWarrior-Geräten auf mein eines USG zugreifen zu können. Vielleicht hat ja jemand eine passende config rumliegen?

  • Bei meiner (ersten, fehlerhaften?) config von oben ist eigtl. nur eine Firewall-Einstellung zusätzlich dabei, die wird nach dem Hochladen (und dem Dauer-Provisionieren...) auch in der GUI angezeigt.

    Könnte / wird schon der Grund sein. Als ich noch stolzer USG-Nutzer war war das System extrem empfindlich, wenn du über

    die json (oder auch von Hand auf dem Device) Änderungen vorgenommen hast, die das UniFi-System selber verwaltet.

    Unifi checkt die config dann, merkt halt "Stop, da ist in meiner Datenbank aber nicht Regel Drölf für die Firewall" und

    Provisioniert neu. Merkt sich dabei aber nicht den extra Kram aus der json und das Spiel beginnt von vorne.


    Merksatz war quasi: Nur Dinge anfassen, die das UniFi-System nicht anfasst.

  • ugw3-v1-v1.0.20220627-v1.0.20210914.deb sollte für eine USG3 richtig sein?

    Jupp, UGW3 klingt vertraut.

    Was bei beiden configs übrigens nicht in der GUI erscheint nach Provisionierung ist der Eintrag zu "remote_user_vpn_network". Soll das so sein? Bzw. wo würde das auftauchen?

    Jupp, ist bei mir auch so.

    Im Ergebnis hätte ich gerne eine WireGuard-config, um mittels S2S (von einem 2. USG3) und RoadWarrior-Geräten auf mein eines USG zugreifen zu können. Vielleicht hat ja jemand eine passende config rumliegen?

    Das (S2S, auch mit AVM, & RoadWarrior) ist auch mein Endausbau. Allerdings bin ich davon auch noch etwas entfernt. :frowning_face:

  • OK, vielen Dank für die Infos! Falls Du razor Deine Endausbau-Baustelle erfolgreich abgeschlossen hast in der Zukunft, freue ich mich natürlich über Hinweise, was dann letztendlich zielführend war :smiling_face: Ich suche dann mal weiter nach einer passend config für dieses setup.

    Gruß zurück!

  • Hallo martinbln ,


    wie steht es denn an der "Front"? Immer noch alles "doof" oder hast Du Dich mal wieder an das Thema gewagt? Ich bin mit dem aktuellen Aufbau (USG-4-Pro mit PPPoE hinter 165er Vigor (siehe Signatur) <-> USG-3 per DHCP hinter FRITZ!Box 7590) ganz zu frieden. Auch nach einem IP-Wechsel bekomme ich das S2S-VPN via WireGuard wieder hin - jetzt, wo ich verstanden habe, wie das mit der WG-Config funktioniert. Auch einen Reboot und ein Update des USGs klappt hervorragend.


    Ich bekomme leider noch keine Verbindung zu einer Stock-FRITZ!Box hin, nur zu meinem Entwickler, da AVM einen wichtigen Punkt via GUI nicht konfigurieren lässt: ein Transfer-Netz.


    Melde Dich gern, wenn Du hier noch einmal starten / einsteigen möchtest.

  • Danke der Nachrage razor ! Mein S2S läuft mittlerweile auch.

    Was war denn am Ende die Lösung oder die Ursache, welche es zu beheben galt? :thinking_face:

    Wie hast Du das denn hinbekommen, den IP-Wechsel des Providers zu überleben? Das haut bei mir noch nicht hin...

    Das will ich gern verraten - schreibe ich auch gleich noch ins wiki:


    Ich versuche jede Minute per CRON einen Client - in meinem Fall die Gateway-IP auf der anderen Seite - per ping zu erreichen. Falls das nicht erfolgreich war "schiebe" ich die WG-Interface-Config erneut auf eben jenes WireGuard-Interface:

    Code
    sudo /bin/ping -c 4 192.168.179.6 || wg setconf wg0 /config/wireguard/wg0.conf

    Eine solche Datei habe ich für alle meine VPNs erzeugt. Den CRON-Job habe ich über die config.gateway.json erzeugt. So sieht er aus:

    Code: /config/scripts/reconfigvpn.sh
    #!/bin/vbash
    #PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    /usr/bin/find /config/scripts -name "wg*.sh" -exec {} \;

    Mit Zeile 3 finde ich unter /config/scripts alle Dateien mit dem Namensmuster wg*.sh und führe sie aus:

    Code
    root@USG:/# /usr/bin/find /config/scripts -name "wg*.sh"
    /config/scripts/wg2.sh
    /config/scripts/wg1.sh
    /config/scripts/wg0.sh

    Damit wird dann die Verbindung wiederhergestellt.

    Keine Ahnung, wie die UniFi-Lösung (auf UDM o.ä.) funktioniert, aber das klappt bei mir - auch mit AVM als "Partner".

  • Danke razor !


    Hat ein bißchen gedauert, aber ich greife das mal auf :smiling_face: Das könnte eine Lösung sein für mein DDNS-Reconnect-Problem... Ich kapiere es nur noch nicht so ganz, vielleicht helft Ihr mir auf die Sprünge?


    Funktioniert das auf einem USG-3?


    Ich bastel mir dann einfach ein passendes wg0.conf und schiebe das in ein Verzeichnis meiner Wahl auf dem USG? Oder auf dem Cloud Key? Und wenn ich die Wireguard Konfiguration dann über ein solches Config-File (wg0.conf) mache, dann brauche ich doch die config.gateway.json nicht mehr, oder? Kommen die sich nicht ins Gehege?


    Würde eine Provisionierung der USG auch den WG-Tunnel neu aufbauen? Ließe sich nicht einfach bei erfolglosem Ping an die Gegenseite mittels Skript auch eine Provisionierung erzwingen? Oder lässt sich vielleicht sogar dieses "Original"-Skript verwenden auf einer USG-3?

    Einmal editiert, zuletzt von martinbln ()

  • Hi martinbln ,


    schön von Dir zu hören.


    Hier nun meine Antworten auf Deine Fragen - soweit ich das testen konnte:

    Funktioniert das auf einem USG-3?

    Ich weiß zwar nicht genau, was dieses "DAS" ist, aber alles aus dem nächsten Linkt klappt auch beim "kleinen" USG:

    Ich bastel mir dann einfach ein passendes wg0.conf und schiebe das in ein Verzeichnis meiner Wahl auf dem USG? Oder auf dem Cloud Key? Und wenn ich die Wireguard Konfiguration dann über ein solches Config-File (wg0.conf) mache, dann brauche ich doch die config.gateway.json nicht mehr, oder? Kommen die sich nicht ins Gehege?

    Ja, das passiert alles auf dem USG und nicht auf dem CloudKey.

    Ich habe das auf die beiden Configs wg*.conf und config.gateway.json aufgeteilt, da sie zu anderen Zeitpunkten im Boot-Prozess des USGs wirken: Firewalling und initiale Verbindung in config.gateway.json und DSL-Reconnect "beheben" in wg*.conf.

    Würde eine Provisionierung der USG auch den WG-Tunnel neu aufbauen? Ließe sich nicht einfach bei erfolglosem Ping an die Gegenseite mittels Skript auch eine Provisionierung erzwingen? Oder lässt sich vielleicht sogar dieses "Original"-Skript verwenden auf einer USG-3?

    Ich hatte mir auch angesehen, ob man das USG einfach neu provisionieren könnte. Das hat aber bei meinen Tests auf "beiden" USGs ("klein" wie "groß") die WireGuard-Verbindung zur Gegenstelle nicht wie erwartet aufgebaut. Da sich der Inhalt nicht widersprechen sondern max. ergänzen sollte kommen sich die Configs nicht ins Gehege. :smiling_face:

    Oder lässt sich vielleicht sogar dieses "Original"-Skript verwenden auf einer USG-3?

    Du kannst gern dieses Script verwenden. Das macht, wenn ich es richtig verstanden habe, nichts anderes als ich oben. Ich habe es aber nicht 100%ig verstanden.

    Wahrscheinlich wird das auch noch - trotz folgendem - funktionieren:

    This repository has been archived by the owner on Dec 27, 2019. It is now read-only.

    Viel Spaß & lass' gern wieder von Dir hören.

  • Hi razor !

    Danke für Deine Antwort! Gucke ich mir mal in Ruhe an.


    Im Augenblick habe ich folgendes erfreuliches, aber mir unverständliches Phänomen: Der WireGuard-Tunnel baut sich nach nächtlicher Zwangstrennung durch den DSL-Anbieter von selber neu auf. Auch ein manuell angestoßener WAN-IP-Wechsel (z.B. Neustart der Fritzbox oder einfaches Neuverbinden) stört den WG-Tunnel nicht, der ist gleich wieder da, nachdem ich eine neue IP-Adresse am WAN-Interface der Fritte bekommen habe. Wie kann das denn sein???

  • Hi razor !

    Danke für Deine Antwort! Gucke ich mir mal in Ruhe an.


    Im Augenblick habe ich folgendes erfreuliches, aber mir unverständliches Phänomen: Der Wiregurard-Tunnel baut sich nach nächtlicher Zwangstrennung durch den DSL-Anbieter von selber neu auf. Auch ein manuell angestoßener WAN-IP-Wechsel (zB Neustart der Fritzbox oder einfaches Neuverbinden) stört den WG-Tunnel nicht, der ist gleich wieder da, nachdem ich eine neue IP-Adresse am Wan-Interface der Fritte bekommen habe. Wie kann das denn sein???

    Warum sollte er das nicht machen? Sobald die Verbindung getrennt wird, baut er die Verbindung wieder auf.

  • Warum sollte er das nicht machen? Sobald die Verbindung getrennt wird, baut er die Verbindung wieder auf.

    Ich sehe es wie martinbln . Das war ja mein Problem, für das ich eine Lösung gesucht habe: das Ändern der IP-Adresse bei einem der VPN-Teilnehmer.


    Entweder wurde in dem Fall die Verbindung von der Gegenseite wiederhergestellt, die eine neue IP ehalten hat oder die IP hat sich vielleicht auch nicht gewechselt - habe ich auch schon von gehört. Dann könnte das klappen. Mit meiner Lösung klappt es in jedem Fall: ich versuche jeweils Wechselseitig auf der anderen Seite einen Host zu erreichen. Geht das nicht mehr wird einfach die Config neu auf das Interface geschoben und schon geht es wieder - meiner Erfahrung nach.


    Was mich aber interessiert: wie hast Du denn das gelöst??? :thinking_face:

    Ich bekomme leider noch keine Verbindung zu einer Stock-FRITZ!Box hin, nur zu meinem Entwickler, da AVM einen wichtigen Punkt via GUI nicht konfigurieren lässt: ein Transfer-Netz.

    Oder benutzt Du keine VLANs im UniFi-Umfeld? :face_with_open_mouth: