Wireguard Server und iOS - finde den Fehler?!

    Hi zusammen,

    Ich bin offensichtlich mal wieder auf beiden Augen blöd, aber ich komme nicht weiter.

    Hab jetzt auch mal mein altes L2TP VPN gelöscht und ein neues Wireguard Profil angelegt.
    Wenn ich ALLES bei der Einrichtung auf „Automatisch“ lasse, funktioniert es auch tadellos, aber natürlich möchte ich im VPN auch meinen eigenen DNS aka Pi-Hole nutzen.

    Also habe ich mir gedacht, dass ich einfach bei Nameserver 1 die IP meines Pi-Hole (10.20.0.253) hinterlege - das gleiche im Wireguard-Profil auf dem iPhone mache - fertig.

    Dummerweise sieht das Wireguard anders. :/

    Sobald ich das mache, wird zwar die Verbindung zum VPN erfolgreich aufgebaut, aber ich hab kein Internetzugriff bzw die Namensauflösung klappt nicht.
    Wenn ich nur ne IP eingebe, komme ich immerhin bis zu etwaigen 403 Forbidden Seiten.
    Ergo muss mein Problem daran liegen, dass der PI nicht aus dem VPN erreichbar ist.

    In der FW ist der Wireguard-Server korrekt der Zone „VPN“ zugeordnet.

    In der FW habe ich bereits zur Fehlersuche eine Regel erstellt, die sämtlichen VPN Traffic in Richtung „HOME VLAN“ (in diesem VLAN befindet sich der Pi) erlaubt inkl. Rückkanal.
    Die Regel befindet sich in der Liste VOR allen Block-Regeln.

    Ich habe die Konfiguration des Netzes (in Unifi - VPN - Gateway/Subnetz) auch mal auf das VLAN gelegt, was vorher für das L2TP VPN genutzt wurde.

    Also vom Standard, den Wireguard automatisch setzt (192.168.3.1/24) zu VLAN (10.40.0.1/24). War auch keine Lösung ||

    Das einzige was mich wundert (aber vermutlich nur meiner Ahnungslosigkeit geschuldet ist) ist die Tatsache, dass mein iPhone bei den Details der VPN Verbindungbei „Serveradresse“ die localhost hinterlegt hat - also 127.0.0.1 - siehe screen.

    Preisfrage - wo hab ich nen Knoten im Kopf?!

    Wie immer - vielen Dank im Voraus für etwaige Ideen/Tipps/Lösungen.

    Anbei ein paar Screenshots - bitte nicht wundern, dass die IPs mal 192.168.3.x und einmal 10.40.0.x sind. Ich habe beim Testen nicht aufgepasst und einmal Screens gemacht, als alles auf Standard (192.168.3.x) + eigenen DNS (10.20.0.253) stand und einmal zum Test auf 10.40.0.x + eigenen DNS (10.20.0.253). Daher die Abweichungen in den Screens.

    Konfig Wireguard Generell

    Konfig Wireguard Client

    Firewall-Regel

    IPhone - VPN - Verbindungsdetails

    Update für die Nachwelt - Vertraut nicht der App :cursing:

    Sowohl auf iOS als auch auf iPadOS hat die App die o.a. FW-Regel VOR den Block-Regeln angezeigt.
    War gerade nur durch Zufall auf der Web-GUI und stelle fest - die FW-Regel ist HINTER den Block-Regeln.
    Ergo kurz die Reihenfolge angepasst - läuft.

    Eine Sache bleibt aber noch. Normalerweise habe ich meine FW Regeln, wenn möglich, entsprechend detailliert.
    Sprich kein Any:Any allowed to Any:Any, sondern auf konkrete Ziel-IPs (zb. Pi-Hole) oder auch konkrete Ports (53/853 für DNS/DOT)
    So eine Regel habe ich ja schon im Betrieb, damit alle VLANs aus der „Untrusted Zone“ auch zum Pi telefonieren können.
    In diesen Fällen klappt das auch, ABER
    Wenn ich die identische Regel erneut anlege, nur eben anstatt „untrusted Zone“ die „VPN-Zone“ hinterlege, kann ich wieder den PI nicht erreichen bzw findet keine DNS Auflösung statt.
    Anbei ein Screen, wo ihr sehen könnt, dass die Regeln bis auf die SOurce-Zone 100% identisch sind. Braucht es noch einen anderen Port innerhalb eines VPNs bzw speziell für Wireguard? Weil bei meinem vorherigen L2TP VPN Server, hatte die Regel ebenfalls tadellos funktioniert.

    Screenshot ist jetzt aus der WebGUI um Anzeigefehler zu eliminieren ;)

    Quote from Maddeen

    funktioniert es auch tadellos, aber natürlich möchte ich im VPN auch meinen eigenen DNS aka Pi-Hole nutzen.

    Sofern Du Pihole in der Standard Konfig verwendest, kannst Du Pihole auch weglassen und den integrierten Unifi Adblocker verwenden. Ich hatte meinen Pihole mal neu installiert, und hatte mich gewundert, das der Pihole keine "Treffer" in den Countern hatte.... yoa, hatte Unfi schon vorher alles weggefiltert 8)

    Lichtbringer :-)

    du hast:

    Ein iPhone 16 (und anderes Geraffel) macht aber bei einer DNS Abfrage aber das hier:

    Siehst du es ?

    Ok ok ok, Ich sagt ja schon:

    Deine Regeln sagen als SOURCE Port "DNS". Das machen viele Resolver auch genau so. Schön VON port 53 nach port 53.
    Müssen sie aber nicht. Den nach wie vor darf der Quellport Random sein (genauer >1024, noch genauer hat jedes
    OS seinen Ephemeral Ports Bereich den er als Source für Anfragen nach draußen nutzt.

    Du solltest (auch die andere reglen) anpassen und als "source any" antragen oder sowas wie 32768-65535
    (um Typische Linux / Apple / Win Kisten abzudecken)

    gierig - erst mal herzlichen Dank für das wärmende Licht in dieser dunklen Zeit ;)

    Und ja - ich sehe es. Interessant - warum sollte man auch Standardports definieren - Am Ende macht jeder Seins! Ganz stark ;)

    Aber danke für das Hintergrundwissen - again what learned ;)
    Ergo ändere ich diese "hart-definierten" Regeln jetzt einfach ab, in dem ich das bisherige DNS/DOT Object , was ich dafür angelegt habe, von den zwei festen Ports (53/853) auf die von dir erwähnte Ephemeral Ports Range (32768-65535) erweitere - und fertig?!?

    Hört sich ja schon fast zu einfach an, um wahr zu sein. Aber schön, wieder ein neues Thema fürs Wochenende.

    Dank dir!

    Quote from Maddeen

    warum sollte man auch Standardports definieren

    DAS der Source Port Random ist ist Definiert :-) Also mehr oder minder...Sollte er immer gleich sein könntest du z.B nicht auf zwei Webseiten
    gleichzeitig zugreifen. Ganz früher dann wohl einfach Stumpf Nächster Freier Port. Lange aber schon eher zufällig (RFC 6335)

    Quote from Maddeen

    und fertig?!?

    Im Grunde ja.. Das sollte dafür sorgen das deine Clients den DNS Server erreichen. Üblich Setzen man aber die Source Seite auf ANY
    dann irgendwelche IOT Kisten, andere Implementierungen halten sich ggf nicht daran sondern nutzen auch port 53 als source oder irgendwas
    anderes.

    Letzten Endes möchte man auch eher das Gerät definieren, welches auf ein Zielgerät mit einem Zielport Kontakt aufnimmt. Da spielt es doch keine nennenswerte Geige von welchem Port die Software die Verbindung aufbauen möchte. Wenn es böse Software geben sollte, dann kann die sicher auch so programmiert werden, dass sie einen definierten Port nutzt der in der Firewall frei ist ... macht also keinen echten Mehrwert aber mehr Arbeit :)

    So - jetzt läuft alles. Noch mal Danke an alle. Ich glaube übrigens, dass meine Objects beim Wechsel auf die neue FW irgendwie einen Klatsch bekommen haben. Es hat am Ende erst zu 100% funktioniert, als ich beim Target nicht mit „object = Raspberry (mit 10.20.0.253) sondern einfach IP = 10.20.0.253 hinterlegt habe. Sehr mysteriös - aber am Ende auch egal.

    Schönes WE zusammen.

Participate now!

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

Register Yourself Login