Posts by Andre_S

Diese Webseite finanziert sich ausschließlich durch freiwillige Spenden. Dank der Unterstützung unserer Nutzer können wir die Inhalte werbefrei und unabhängig anbieten. Jetzt Unterstützen

    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

    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.

    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.