WireGuard trotz DNAT

Es gibt 18 Antworten in diesem Thema, welches 3.227 mal aufgerufen wurde. Der letzte Beitrag () ist von Networker.

    Moin zusammen,


    folgendes Problem stellt sich derzeit.
    Die UDM sitzt hinter einem AudioCodes Router.
    Somit wird mir bei WAN die IP (192.168.0.20) angezeigt, die mir der AutoCodes (Telefonie) Router zugeteilt hat.


    Ein DDNS auf dem der UDM bewirkt, dass jetzt die IP vom WAN Anschluss (192.168.0.20) an den DDNS übermittelt wird, was natürlich Käse ist.

    Jetzt habe ich auf der Synology den DDNS aktiviert und bekomme darüber auch die richtige IP-Adresse zur DDNS Adresse hin.

    Ich habe nun blauäugig mal versucht den Wireguard Server über die Adresse anzusprechen, aber anscheinend interessiert sich die UDM relativ wenig dafür, denn ich bekomme keinen Handshake hin:

    Code
    2023-08-04 08:02:47.812: [TUN] [WireGuard-neu] Sending handshake initiation to peer 1 (xxx.xxx.xxx.xxx:51820)
2023-08-04 08:02:52.826: [TUN] [WireGuard-neu] Handshake for peer 1 (xxx.xxx.xxx.xxx:51820) did not complete after 5 seconds, retrying (try 2)


    Die FW Regeln setzt die UDM ja nach Einrichtung des Wireguard Servers selbst oder muss hier noch mehr erfolgen?

    Meine Client Config schaut wie folgt aus:

    Code
    [Interface]
PrivateKey = WH2kZCY+.....................
Address = 192.168.99.2/32
DNS = 192.168.99.1, 192.168.1.1, 192.168.10.30


[Peer]
PublicKey = hSjoEA0o..................
AllowedIPs = 192.168.0.0/24, 0.0.0.0/0
Endpoint = xxx.xxx.xxx.xxx:51820


    Über ein paar Lösungsvorschläge würde ich mich sehr freuen, würde schon ganz gerne den Wireguard Server der UDM nutzen als auf der Synology noch extra einen zu betreiben, da ich auf der UDM früher ins Netz gelangen würde und sollte die Synology mal die Grätsche machen, ich noch immer ins Netz komme.


    Beste Grüße

    Hallo h0mer, Wenn Deine UDM im vorgelagerten Router nicht als exposed host eingestellt ist oder es mindestens eine Portweiterleitung für alle von Wireguard benutzten Ports gibt, wird es nciht funktionieren. Dein Wireguard-Client kommt aus dem Internet ja nur bis zum ersten Router - und dieser weiß nichts von Wireguard.

    Ich habe gerade mal beide Varianten durchgespielt.

    • Port Weiterleitung auf dem AudioCodes mit 51820 auf die interne IP der FW
    • FW als Exposed Host in die DMZ gestellt


    Der Client quittiert mir in beiden Fällen den Anmeldeversuch mit:

    Code
    2023-08-04 11:09:48.574: [TUN] [WireGuard-neu] Sending handshake initiation to peer 1 (xxx.xxx.xxx.xxx:51820)

    Die IP zur DynDNS löst er richtig auf, aber das war es auch schon.

    Portweiterleitungen oder FW Einträge sind vermutlich nicht notwedig, wenn die FW die erste ist, die diese Anfragen annimmt, oder?

    Habt ihr ggf. noch eine Idee?
    Ansonsten muss ich wirklich mal eine Testinstallation einen Wireguard als Docker aufsetzen und schauen, ob er die Verbindung dann annimmt.

    Ich hab das ähnlich bei mir in Bezug auf WG bei mir am Laufen.

    Auf der UDx gibt es lediglich eine Portweiterleiterung auf die interne IP:51820 UDP worauf der WG läuft.

    Im Router (UDx) ist natürlich ddns aktiv um die ext IP auflösen zu können.

    Ist denn der Endpunkt in Deiner Config der ext. Name?

    Habe die Portweiterleitung von 51820 - 51822 eingetragen, da ich es zwischenzeitig mal den WG Dienst auf der UDM mit den Ports 51821 und 51822 versucht hatte.
    Beim Endpoint hatte ich es mit der IP als auch mit dem DDNS Namen versucht. Den DDNS Namen löst er im Protokoll ja direkt auf, also das passt und mit der externen IP sollte er mich ja ebenfalls zum richtigen Ziel lotsen.


    Meine Config sieht wie folgt aus:

    Code
    [Interface]
PrivateKey = 0Gjjb/6iQ..................
Address = 192.168.99.2/32
DNS = 192.168.99.1, 192.168.1.1, 192.168.10.30


[Peer]
PublicKey = hSjoEA0ozJlIPe.....................
AllowedIPs = 192.168.0.0/24, 0.0.0.0/0
Endpoint = externeIP_bzw_DDNSAdresse:51820


    Stehe bissel auf dem Schlauch :frowning_face:

    Zitat von metamorph81

    Sieht aus meiner Sicht nicht verkehrt aus.

    Irgendwelches anderweitiges Regelwerk welches evtl. den Rückweg blockt?

    Ich habe derzeit in der Kategorie Internet keine eigene drop Regel definiert (nur die vom System erstellten), so dass es da eigentlich zu keinem Problem kommen dürfte.


    Zitat von Networker

    Ich vermute dann, dass Du keine öffentliche IPv4-Adresse von Deinem Provider bekommst. Fängt sie mit 100.64. an?

    Sieht für mich schon nach einer öffentlichen IP aus. Sie fängt mit 89. an.

    Ok, dann wirst Du vermutlich nicht durch Deinen Provider GeNATtet. Schon mal gut.

    Dort nachzufragen kann natürlich aber auch nicht schaden, vielleicht filtert man dort ja providerseitig irgendwelchen Traffic. Wenn Du bei einem der deutschlandweit agierenden Provider bist, wird dies aber auch eher nicht der Fall sein.


    Ich hatte "Audiocodes" noch nie gehört, von daher habe ich leider auch keine Idee, was Du im Router noch prüfen könntest. Auf jeden Fall würde ich die UDM als exposed Host betreiben, oder ist Dein Netzwerk deutlich komplexer als diese Router-Kaskade?


    Ideal als Test wäre, wenn Du die UDM direkt an den Internetanschluss bekommst. So könntest Du klar bestimmen, ob Wireguard im Audiocodes-Router hängen bleibt oder (aus welchem Grund auch immer) in der UDM nicht funktioniert.

    Audicodes sind Business Router. Die sind aufgetaucht, als die Telefonie auf IP umgestellt wurde ... insbesondere Anlagenanschlüsse und Primärmultiplexer. Die können praktisch vor eine alte TK-Anlage gehängt werden und stellen dann die IP Telefonie in Form von diversen S0 oder S2M Schnittstellen zur Verfügung.


    Ich tippe mal auf eine nicht korrekt arbeitende Portweiterleitung. Ggf. musst Du im Audiocedes Router doch was in der Firewall konfigurieren. Manche Kisten machen das automatisch mit wenn man ein Portforward anlegt ... manche erfordern Handarbeit. Das sollte aber aus dem Handbuch ersichtlich sein, ob man selbst noch in der Firewall tätig werden muss.

    Habe auch WG auf der UDM Pro laufen, hinter einer Fritzbox und DNAT.

    Dort gab es keine Probleme, DDNS über MyFritz, Portweiterleitung in der Fritte zur UDM und alles geht.

    Dein Problem sollte also bei deinem vorgeschalteten Modem/Router liegen.

    Also ich habe heute mal die aktuelle öffentliche IP-Adresse beim Wireguard Server in der UDM eingetragen.
    Die Portweiterleitungen im AutoCodes habe ich so belassen, wie sie waren.
    Mit dem iPhone kann ich mich erfolgreich verbinden, mit dem Windows und MacClient nicht, dabei verwende ich denselben Benutzer und habe auch schon ausgeschlossen, ob es ggf. an meinem WLAN liegt und mich mitm Hotspot des Handys verbunden. Er bekommt da einfach keinen Handshake auf die Reihe.

    Wieso funktioniert es mit dem iPhone und nicht mit dem Windows Laptop oder dem Macbook?

    Also habe erneut mal den Wireguard Server neu aufgesetzt.

    Es ist und bleibt wie bisher. Mit dem iPhone kann ich mich problemlos connecten, sehe den User auch in den Devices in der UDM, mit Windows und MacOS laufe ich immer wieder in den Handshake der nicht zustande kommt. Habe es aus unterschiedlichen Netzen versucht, für Windows und MAC einen extra WG User verwendet, hilft alles nichts


    Hier meine aktuelle Config


    Fehler

    Code
    2023-08-25 16:45:42.383 [NET] peer(HUPI…rpko) - Handshake did not complete after 5 seconds, retrying (try 2)
2023-08-25 16:45:42.383 [NET] peer(HUPI…rpko) - Sending handshake initiation
2023-08-25 16:45:47.451 [NET] peer(HUPI…rpko) - Handshake did not complete after 5 seconds, retrying (try 2)
2023-08-25 16:45:47.451 [NET] peer(HUPI…rpko) - Sending handshake initiation
2023-08-25 16:45:52.650 [NET] peer(HUPI…rpko) - Handshake did not complete after 5 seconds, retrying (try 2)
2023-08-25 16:45:52.651 [NET] peer(HUPI…rpko) - Sending handshake initiation

    Verzweifle aktuell an der Nummer und verstehe nicht, wieso es unter iOS rund läuft und und MacOS und Windows dann auf nen Fehler läuft.