Wireguard - FritzBox <-> UDM

Es gibt 39 Antworten in diesem Thema, welches 11.161 mal aufgerufen wurde. Der letzte Beitrag () ist von turtle1987.

    Zitat von schraubl

    Ich kann dein Aussage nicht ganz nachvollziehen. Aber machen wir das mal konkret. Auf der UDM bekommt das wg-interface z.B. die 192.168.2.201 und auf der Fritz!Box wird es schon automatisch die 192.168.2.1 - die IP der Fritzbox - auf dem wg-interface sein. Somit sehe ich beim Routing keine Problem. Aber wie gesagt, ich habe das selber so noch nicht umgesetzt. Und ich nutze einen EdgeRouter.


    Nun… 2 gleiche Netze, das eine in der FRITZ!Box (meinetwegen 192.168.178.x) und das gleiche in der UDM? Ich denke da missverstehen wir uns.

    Gruß, Carsten


    ---------------

    Zitat von BlackSpy

    Mal in der Client Konfig, unter Peer den

    Code
    PersistentKeepalive = 25

    Eingefügt?

    Der ist nur für den automatischen Verbindungsaufbau bzw. damit die Verbindung bei Nichtaktivität nicht abbricht, der Parameter ist schon drin und funktioniert auch und ist sinnvoll gerade bei dem NAT der FRITZ!Box. Ich werde mir mal unabhängig von dem Ganzen eine Testumgebung aufbauen. WireGuard wird nicht das Problem sein, eher die „harmlose“ Konfiguration der FritzBox oder der UDM. Wenn ich die Route in das Netz der FritzBox konfiguriere verhält sich die FRITZ!Box abnormal, als wenn diese das Netz der UDM nicht kennt (ist aber in der Konfiguration drin).

    Gruß, Carsten


    ---------------

    Zitat von Loomis

    Nun… 2 gleiche Netze, das eine in der FRITZ!Box (meinetwegen 192.168.178.x) und das gleiche in der UDM? Ich denke da missverstehen wir uns.

    Du hast dein Netz hinter der UDM, die UDM hat per WG ein Bein im Netz hinter der FB (178.x)....

    Zitat von schraubl

    Du hast dein Netz hinter der UDM, die UDM hat per WG ein Bein im Netz hinter der FB (178.x)....

    Nein, die UDM ist ein Standort - die FB ist in meinem Wohnmobil und somit ein anderer Standort.

    Gruß, Carsten


    ---------------

    Zitat von Loomis

    Nein, die UDM ist ein Standort - die FB ist in meinem Wohnmobil und somit ein anderer Standort.

    Die FB bindet an das WG-Interface die ..178.1.

    wg0 auf der UDM bekommt z.B. die ..178.2.


    Die Implementierung von AVM ist hier wohl etwas eigen.

    Zitat von schraubl

    Die FB bindet an das WG-Interface die ..178.1.

    wg0 auf der UDM bekommt z.B. die ..178.2.


    Die Implementierung von AVM ist hier wohl etwas eigen.


    Allerdings …


    Aber hier ist es umgekehrt. WG wurde auf der UDM konfiguriert. Der Tunnel 192.168.4.0 mit .1 und .2 auf der FB Gegenstelle. Hier ist die FB auch von den Netzen der UDM erreichbar. Nur komme ich nicht auf das Netz, was die FB an Ihren Ports aufspannt. Die Netze sind in Konfiguration hinterlegt, müssen also nicht noch in der FB hinterlegt werden (geht auch nicht -> Fehlermeldung).


    Ich sehe keinen Fehler in der Konfiguration, die in der FB eingespielt wird:


    Code
    [Interface]
PrivateKey = xx
Address = 192.168.4.2/32
DNS = 192.168.4.1

[Peer]
PublicKey = xx
AllowedIPs = 192.168.4.2/32,192.168.4.1/32,10.8.8.0/24,10.2.2.0/24,10.4.4.0/24,10.10.10.0/24,10.11.11.0/24,10.200.200.0/24
Endpoint = xyzdomain:6688
PersistentKeepalive = 25

    Gruß, Carsten


    ---------------

    Schau dir mal die tatsächlich konfigurierten Parameter unter "WireGuard®-Einstellungen anzeigen" an.

    Zitat von schraubl

    Ich denke nicht, dass das einen Einfluss hat. Ich vermute mal, dass die FB im 192.168.4.0/24 Netz auch von der UDM-Seite erreichbar ist.

    DS-Liste ist nicht vorhanden, die FB ist von UDM Seite erreichbar, mehr aber auch nicht. Ich kann heute abend schauen, was auf der FB unter den Einstellungen eingetragen ist.

    Gruß, Carsten


    ---------------

    Zitat von razor

    Als ich die VPN-Verbindung zwischen mir und meinem AVM-Spezi konfiguriert habe, da hatte er noch eine Einstellung in der Config manuell vorgenommen, welche nicht via GUI vorzunehmen ging - meine ich mich erinnern zu können. Die Verbindung war aufgebaut, aber ich konnte nicht auf sein NAS zugreifen, er aber via FRITZ!Box auf meines.

    Mist ey, Hirn wie Sieb. :frowning_face:

    Ich versuche es noch einmal mit ihm...


    Ich koennte mir vorstellen, dass das Problem von Professed75 daran liegt, dass die UDM das lokale Netz hinter der Fritzbox nicht kennt. Das laesst sich aber loesen und ist wahrschienlich die manuelle Config, die du (razor) hier ansprichst.


    Dazu muss man sich per SSH auf die UDM verbinden und der wg Konfiguration als allowed-ip das lokale Netz hinter der Fritzbox mitgeben:


    Erstmal nur wg eingeben. Da sollte die Verbindung zur Fritzbox angezeigt werden (inkl. PUBLIC_KEY).


    Dann wg set wgsrv1 peer <PUBLIC_KEY> allowed-ips 192.168.9.0/24,192.168.2.0/24


    Ggf. wgsrv1 durch den Interfacenamen ersetzen, den die UDM vergeben hat. Der Befehl fuegt der wg Konfiguration das lokale Netz hinter der Fritzbox hinzu. Falls ein PING in das lokale Fritzbox Netz danach immer noch nicht funktioniert, dann kann es sein, dass noch eine statische Route noetig ist. Das geht wieder ueber die UI der UDM. Da das loakle Netz der Fritzbox ueber als uber das Wireguard Interface erreichbar eintragen.

    Zitat von turtle1987

    Muss man danach die Verbindung neu starten? Ich habe das eingefügt aber es ändert sich nichts

    Eigentlich nicht. Ist ja nur eine lokale Routing Info fuer die UDM. Hast du probiert zusaetzlich eine statische Route einzurichten?

    Falls ein PING in das lokale Fritzbox Netz danach immer noch nicht funktioniert, dann kann es sein, dass noch eine statische Route noetig ist. Das geht wieder ueber die UI der UDM. Da das loakle Netz der Fritzbox ueber als uber das Wireguard Interface erreichbar eintragen.

    Ich bekomme es leider nicht zum Laufen. Habe jetzt folgendes:

    Netz der UDM Pro 192.168.3.0, Netz der FritzBox 192.168.12.0

    Von der FritzBox ist alles hinter der UDM erreichbar aber ich komme von der UDM nicht auf das 192.168.12.0 Netz der FritzBox. Egal ob mit oder ohne statische Route, die ich so eingerichtet habe:


    Vielleicht siehst du ja noch einen Fehler von mir....

    Hallo turtle1987 ,


    kurz vorab: mit der Funktion Code (Symbol oben links, wenn Du einen Beitrag hinzufügst: </>) geht zwar leider die Farbe aus Deinem 2. Screenshot verloren, aber immerhin kann man den Text durchsuchen, das Bild leider nicht. :winking_face:


    Meine Annahme: Hinter der FRITZ!Box gibt es nur das LAN 192.168.12.0/24, und hinter der UDM nur 192.168.3.0/24. Was machen die Adressen 192.168.6.1/32 & 192.168.6.2/32, welche in der FRITZ!Box zu sehen sind? :thinking_face: Ist das ein / das Transfer-Netz oder was?


    Versuche doch bitte mal folgendes zur Klärung vorab, denn die statische Route in der UDM irritiert mich etwas:

    • Dauerping von einem Client hinter der FRITZ!Box (aus UDM-Sicht) zu einem Client im UDM-LAN
    • auf der Console der UDM den Befehl route (oder entsprechend) ausführen und das Ergebnis posten - vor allem die VPN-Interfaces interessieren mich / uns dabei.
      So sieht es bei mir aus: siehe unten
    • auf der Console der UDM den Befehl tcpdump -p icmp -n ausführen:
      tcpdump könnte Dir vielleicht etwas sagen, sonst siehe z.B. HIER, -p icmp zeigt nur ICMP-Paket (ping) an und -n zeigt die IP-Adressen anstatt namen an (kannste ja zum Test mal weglassen)
    • dann mal ping von einem Client aus dem (einem?) UDM-LAN auf einen Client hinter der FRITZ!Box
    • Ergebnisse posten
    Code
    root@USG:~# tcpdump -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:17:19.191676 IP 10.10.105.102 > 192.168.69.60: ICMP echo request, id 1, seq 11, length 40
14:17:20.206173 IP 10.10.105.102 > 192.168.69.60: ICMP echo request, id 1, seq 12, length 40
14:17:40.581552 IP 10.10.105.102 > 192.168.69.60: ICMP echo request, id 1, seq 13, length 40
14:17:41.601065 IP 10.10.105.102 > 192.168.69.60: ICMP echo request, id 1, seq 14, length 40
14:17:42.608836 IP 10.10.105.102 > 192.168.69.60: ICMP echo request, id 1, seq 15, length 40
14:17:43.623688 IP 10.10.105.102 > 192.168.69.60: ICMP echo request, id 1, seq 16, length 40
    Code: tracert von einem Windows-Client aus meinem LAN zu einem entfernten NAS
    C:\Users\Razor>tracert 192.168.*.60

Routenverfolgung zu 192.168.69.60 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  10.10.105.1
  2     7 ms     7 ms     7 ms  192.168.69.60
  3     7 ms     7 ms     7 ms  192.168.69.60

Ablaufverfolgung beendet.

    Hier ist zu erkennen, dass das Transfer-Netz für wg2 (192.168.179.12/30) hier nicht auftaucht.

    Zitat von Quatchi

    Ich koennte mir vorstellen, dass das Problem von Professed75 daran liegt, dass die UDM das lokale Netz hinter der Fritzbox nicht kennt. Das laesst sich aber loesen und ist wahrschienlich die manuelle Config, die du (razor) hier ansprichst.

    Ich kann mich wieder erinnern: auf der FRITZ!Box mussten noch meine LANs zugelassen werden, aus denen ich auf Resourcen hinter der FRITZ!Box zugreifen will. Deswegen kam ich wzar von meinem USG (172.30.1.1/24) auf Systeme hinter der FRITZ!Box, aber weder von meines Clients (10.10.105.0/24) noch von einem meiner NASe (10.10.101.0/24).

    Danach ging es dann auf magische Weise. :grinning_squinting_face:

    Zitat von razor

    Meine Annahme: Hinter der FRITZ!Box gibt es nur das LAN 192.168.12.0/24, und hinter der UDM nur 192.168.3.0/24. Was machen die Adressen 192.168.6.1/32 & 192.168.6.2/32, welche in der FRITZ!Box zu sehen sind? :thinking_face: Ist das ein / das Transfer-Netz oder was?

    Deine Annahmen sind alle korrekt. Das 192.168.6.2 legt die UDM bei Wireguard automatisch an:


    Hier das gewünschte Ergebnis der Route:

    Wie komme ich denn an die Ergebnisse der tcpdump, sorry aber bin kein Linux-Sehender. Bekomme nach dem Ausführen folgendes angezeigt:

    Code
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth8, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    Zitat von turtle1987

    Deine Annahmen sind alle korrekt. Das 192.168.6.2 legt die UDM bei Wireguard automatisch an:


    Hier das gewünschte Ergebnis der Route:

    Wie komme ich denn an die Ergebnisse der tcpdump, sorry aber bin kein Linux-Sehender. Bekomme nach dem Ausführen folgendes angezeigt:

    Code
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth8, link-type EN10MB (Ethernet), snapshot length 262144 bytes

    Wenn Du tcpdump wie ich beschrieben habe ausführst, dann siehst Du erst etwas, wenn Du auch den ping startest, siehe der Punkt danach. Diese Pakete solltest Du vor allem auf dem Gateway sehen.

    Das Bild, welches Du beschreibst, sieht erstmal OK aus. Ich habe allerdings zwischendurch auch immer die pings meiner Controller gesehen.

    Zitat von razor

    Wenn Du tcpdump wie ich beschrieben habe ausführst, dann siehst Du erst etwas, wenn Du auch den ping startest, siehe der Punkt danach. Diese Pakete solltest Du vor allem auf dem Gateway sehen.

    1. Also habe einen Dauerping von einem Client hinter der FritzBox zu einem Client hinter der UDM, der klappt auch.
    2. Dann im Putty tcpdump -p icmp -n ausgeführt
    3. Auf einem Client hinter der UDM einen Ping zu einem Client hinter der FritzBox ausgeführt --> kommt immer Zeitüberschreitung der Anforderung.

    Ergebnis ist leider, das nichts passiert. Habe das dann mal mit STRG+C gestoppt:

    Code
    0 packets captured
0 packets received by filter
0 packets dropped by kernel

    Ist dabei auch egal, ob die statische Route aktiviert oder deaktiviert ist. Heißt, dass die UDM den Ping gar nicht bekommt?!


    Ergänzung: habe mal die Route verfolgt:

    FritzBox Client zu UDM Client:

    Code
    Routenverfolgung zu 192.168.3.60 über maximal 30 Hops

  1     1 ms     2 ms     1 ms  fritz.box [192.168.12.1]
  2     *      102 ms   107 ms  192.168.6.1
  3   110 ms   107 ms   112 ms  192.168.3.60

    UDM Client zu FritzBox Client

    Code
    Routenverfolgung zu 192.168.12.99 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  unifi.localdomain [192.168.3.1]
  2    47 ms    60 ms    46 ms  192.168.6.2
  3     *        *        *     Zeitüberschreitung der Anforderung.

    Einmal editiert, zuletzt von turtle1987 ()