Kein WG VPN Zugriff mit Linux Client

    Hi liebe Ubiquity-Gemeinde,

    ich habe aktuell ein Problem vor mir, das ich mir nicht erklären kann.

    Aktuell betreue ich ein brandneu aufgesetzte UDM-Pro. Im Private VLAN befindet sich eine Homematic CCU3. Neben dem einen VLAN gibt es auf der UDM-Pro noch einen Wireguard-Server. An der Firewall wurde noch nichts Individuelles eingestellt.

    Von extern, über den Wireguard-Server, möchte nun jemand die CCU3 programmieren.

    Nun kommt das Problem, das ich mir nicht erklären kann. Mit einem Windows-Client funktioniert die WG-Verbindung, mit einem Linux-Client kommt nur eine Verbindung zustande, aber der Zugriff auf die CCU3 klappt nicht.

    Gibt es bei der Wireguard-Einstellung irgendwelche Fallstricke, um mit Linux auf das Netzwerk zugreifen zu können?

    Nein, irgendwelche Client OS bedingt Einstellungen gibt es nicht. Entweder steht die Wireguard VPN doch nicht wirklich (Wird der Client bei Verbindung bei den Clients angezeigt, gibt es gesendeten und Empfangenen Traffic am Linux Client auf dem wg Interface) oder da ist auf den Linux ggf. was faul beim routing, völlig unpassender Tunnel MTU oder ähnlichem.

    Die WG Konfiguration hast Du mit Windows schon mal gegengecheckt?

    Genau mit Windows hat der Zugriff funktioniert.

    Mittlerweile klappt die Verbindung nun auch mit dem Linux Client. Aber erklären kann ich es mir nicht. Nun bin ich auf der Suche warum.

    Auf Wunsch hatte ich mal versucht, eine „statische Route“ vom Privaten VLAN ins Wireguard-Netz einzustellen.
    Kann das der Grund sein?
    Ich habe auch festgestellt, dass mit aktiver IPv6 Einstellung ein Problem gegeben kann. Aber ich verstehe dann nicht, warum es mit Windows klappt.

    Für mich klingt das nicht nach einem UDM Problem, oder?

    Hallo,

    da ich an der Lösung auch interessiert bin und vielleicht auch was beitragen kann, hab ich mich hier auch mal angemeldet ;)
    Also ich bin die "Gegenstelle", also derjenige der nicht ins VPN kam.

    Aber es jetzt tut... und das lag im wesentlichen an 2 Sachen: ein ganz wichtiger Punkt: Die Wireguard-Konfig hatte als Host eine dyndns-Adresse die auch eine IPv6 verteilt hat, welche Linux bevorzugt verwendet (Windows komischerweise die IPv4). IPv6 ist anscheinend in der UDM nicht oder nicht richtig konfigruiert. Das alleine war noch nicht die Heilung, wir hatten jetzt ja auch noch einen 2. VPN-User angelegt. Der erste User sah so aus:
    [Interface]
    PrivateKey = ...........=
    Address = 192.168.3.2/32
    DNS = 192.168.3.1

    [Peer]
    PublicKey = ...........=
    AllowedIPs = 192.168.3.1/32, 192.168.3.2/32, 0.0.0.0/1, 128.0.0.0/1
    Endpoint = XYZ1234.ipv64.de:51821

    mit dieser Konfig funktioniert es auch jetzt noch nicht mit einem Linux-Client. Mit dem Windows-Client geht es.

    Mit dem 2. User und dieser Konfig:
    [Interface]
    PrivateKey = ......=
    Address = 192.168.3.3/32
    DNS = 192.168.3.1

    [Peer]
    PublicKey = .......=
    AllowedIPs = 0.0.0.0/0

    Endpoint = ####.####.####.####:51821 (also direkte IP-Vorgabe im IPv4-Format)
    PersistentKeepalive = 25

    funktioniert es. 2 wesentliche Unterschiede in der Konfig: AllowedIPs und IPv4 erzwungen durch von Hand vorgabe der IP-Adresse statt dyndns-Adresse.

    Die Aussage meines NW-Techniker war, dass die Route von 192.168.1.x auf 192.168.3.x nicht gesetzt war, jetzt aber mit AllowedIPs 0.0.0.0/0 alles über das VPN gezwungen wird, deswegen auch Antwort-Pakete ankommen (vorher war zwar auch 0.0.0.0 drin, aber /1 ).

    Zur Absicherung der Funktionalität: Der Linux-Client hat auch mit anderen VPNs problemlos auf anhieb funktioniert, mit der Konfig 1 oben hat er zwar auch eine Connection hergestellt die valide war (u.a. geprüft, dass ein falscher PublicKey nicht akzeptiert wurde) aber es kamen keine Antwortpakete.

    Also es funktioniert jetzt, aber ich hätte schon gerne gewusst was man hätte richtig machen müssen, wie also die richtigen IP-Routes in der UDM hätten aussehen müssen, damit man nicht 0.0.0.0/0 vorgeben muss, das ist ja auch nicht der richtige Weg.

    Hallo Andre,

    schön, dass du auch hier bist, ich denke vielleicht können wir das Problem hier auch für andere lösen.

    Das IPv6 in Bezug auf VPN etwas buggy ist, kann ich bestätigen. Zumindest bei meinen bisherigen OpenVPN Versuchen. Daher habe ich auch gleich die WAN-Konfiguration geprüft. Dort ist IPv6 wieder deaktiviert.

    Aber ich habe die Befürchtung, dass beim DDNS-Provider noch die „alte“ IPv6 neben der IPv4 hinterlegt ist. Die läuft natürlich nun ins Leere, wenn aktuell am WAN IPv6 deaktiviert ist. Falls der alte AAAA-Eintrag noch hinterlegt ist, werde ich ihn mal rausnehmen. Dann würde zumindest DDNS sauber funktionieren.

    Moin,

    ach ja wo fangen wir denn mal an und wie Strukturieren wir das ? Einfach nummern und drauf Los ? Reihenfolge egal ? Gut :-)


    1.) UniFI unterstützt aktuell keine eignenden Verbindungen via IPv6 bei WG Server. Warum auch immer. Der WG Server kann es und lauscht auch auf ALLEN Interfacs und kann auch IPv6.. aber das UniFi System macht den Laden nur für IPV4 auf

    Code
    iptables  -n -L UBIOS_WAN_LOCAL_USER
Chain UBIOS_WAN_LOCAL_USER (1 references)
target     prot opt source               destination
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            ctstate NEW icmptype 8 /* 00000001095216670480 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED /* 
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID /* 00000001095216690481 */
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            match-set UBIOS_wireguard_ports dst 
DROP       all  --  0.0.0.0/0            0.0.0.0/0            /* 00000001097364144127 */

    im match-set UBIOS_wireguard_ports stehen das die Ports drinnen die reingelassen werden. Gibt es für IPv6 einfach nicht...(ip6tables -n -L UBIOS_WAN_LOCAL_USER). Das weshalb währe dan mit UI selber zu klären.. ich denke das die da Weltweit nur einen haben der IPv6 kann und will :-) ne "WAN zu Gateway" reglen mit den Nötigen Port UDP auf Ipv6 könnte das aber umschiffen... aber nie getestet...


    2.)

    Quote from Andre_S

    AllowedIPs = 192.168.3.1/32, 192.168.3.2/32, 0.0.0.0/1, 128.0.0.0/1

    Das ist sagen wir es mal INteresant.. warum "0.0.0.0/1, 128.0.0.0/1" 0.0.0.0/0 hätte den gleichen Effekt einfach ALLES über das VON zu Routen. Nun ja, die Lokale 192.168.3.2/32 gehört da auch nicht Wirklich rein... Hier nur die Netze eintragen die erreicht werden sollen. nicht mehr nicht weniger.


    3.)

    Linux linux Linux.Ein Gattungsbegriff den ich Akzeptiere anderen aber Sauer aufstößt ist das schließlich nur der Kernel :-) Wundere mich das bei die IPv6 als erstes zurückkommt, ich kenn das nur andersrum... Was für ne Distro ist das in welcher Version ?

    evt hilft ne Modifikation der /etc/gai.conf um "ipv4" zu forcieren.

    Code
    #
#    For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96  100

    Wahrscheinlich besser währe ganicht erst nen AAAA im DNS zu haben für den Hostnamen....

    zu 1) das ist doof und unerwartet für so ein System...

    zu 2) das kam (leider) so aus der VPN-Konfig der UDM (denke ich zumindest oder ?) , angefasst habe ich zumindest nichts

    zu 3) Debian 12 "Bookworm"


    ein Tipp gab mir mein NWer noch: Windows macht wohl auch erst IPv6, bekommt damit aber keine funktionierende Verbindung und macht dann Fallback auf IPv4, Debian sagt andererseits das der Tunnel steht und probiert deswegen nicht weiter... das passt leider zu zu deiner 1) ... denn auch mit IPv6 hat er ja einen Tunnel initiiert, nur funktioniert hat er ja nicht.

    Hi,

    Klasse, ich glaube, wir grenzen das Problem langsam ein.:)

    Zu 1) Jupp, IPv6 ist noch nicht durchgängig umgesetzt. Ich habe das Gefühl, es wird zunehmend besser. Daher ist es am WAN auch wieder abgeschaltet. Ich vermute aber, der DDNS-Server hat vom ersten einrichten den ersten AAAA-Eintrag noch nicht gelöscht. Da habe ich nur aktuell keinen Zugriff. Das kläre ich aber noch.

    Ich vermute IPv6 als den Problem Verursacher in der Geschichte.^^

    Zu 2) So kam es aus der Config in meinem WG-Client an.

    192.168.3.1/32, 192.168.3.2/32, 0.0.0.0/0

    zu 3) :saint: hast ja recht


    [Update 7:21] AAAA Eintrag im DDNS war noch gesetzt obwohl der WAN keine IPv6 mehr hatte. AAAA ist nun gelöscht. Andre_S du müsstest jetzt im WG client auch wieder DDNS verwenden können.

    Edited once, last by crash80 (April 16, 2025 at 7:23 AM).

    So, dann update ich auch mal:
    Ich fange mit Konfig 2 an: Auch ohne feste IP und mit dyndns geht jetzt die Verbindung, das war erfolgreich! Kann also meinen manuellen Workaround raus nehmen.

    Konfig 1: Da der Full-Tunnel ja eigentlich nicht unsere Absicht war hab ich den "Müll" der ersten Konfig ignoriert und sauber das eingetragen was logisch wäre: AllowedIPs = 192.168.3.1/24,192.168.1.1/24

    und kaum macht man es sauber funktioniert es. Warum /32 und nur die IPs 3.1 und 3.2 in der Original-Konfig standen... k.A. aber ohne 1.1/24 war halt schlecht. Damit wäre das Thema wohl gelöst, es war ne KOmbi aus IPv6 und falscher AllowedIPs-Konfig

    Quote from crash80

    Zu 2) So kam es aus der Config in meinem WG-Client an.

    192.168.3.1/32, 192.168.3.2/32, 0.0.0.0/0

    Mhhh welche Controller Version ? Seit einiger zeit sollte er nur "AllowedIPs = 0.0.0.0/0" vorgeben, genauer sei 9.0.114 weil irgend ein win10 update da nun anders reagiert.. und nun ja die eigne IP hat in AllowIP auch nicht zu suchen auch wenn geht und meist einfach ignoriert wird.

    Quote from gierig

    immer noch ganz leicht dreckig :-) "192.168.3.0/24,192.168.1.0/24" währen die korrekten Sauberen Netzangaben.

    U are right... war auch nur "falsch" aus dem Kopf getippt... war zu schnell damit eben :D ist natürlich .0 ... und vor allem /24 in der Original-Konfig war /32 was natürlich dann der Gau war.

    192.168.3.1/32 würde auch in Ordnung sein wenn das die Wirguard Server IP der UDM ist und man nicht vor hat über die UDM mit weiteren VPN Clients zu kommunizieren. Beim entfernten LAN sollte natürlich das korrekte Subnet angegeben werden also mit .0/24 ansonsten wird es auf keinen Fall etwas.

    Es müsste mit Allowed IPs 0.0.0.0/1, 128.0.0.0/1 oder 0.0.0.0/0 oder eben den expliziten Remote LANs funktionieren. Windows legt entsprechende Routen beim Start des Tunnels an. Wie gesagt ist die Frage, ob Linux das auch tut. Bei Windows ist der Unterschied zwischen 0.0.0.0/1, 128.0.0.0/1 und 0.0.0.0/0 dann der, dass man mit 0.0.0.0/0 sein lokales LAN nicht mehr erreicht. Im Windows Client gibt es einen Haken Notaus oder ähnlich, der genau das umändert.

    Ich vermute mal, dass der Hauptgrund erstmal das IPv6 auf eine nicht mehr von der UDM benutzten IPv6 war. Das Routenproblem wird man vermutlich bei den unterschiedlichen Linux Distris immer genauer untersuchen müssen.

  • crash80 April 17, 2025 at 12:51 PM

    Set the label from offen to erledigt

Participate now!

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

Register Yourself Login