PiVPN Verbindung nicht möglich "pivpnHOST=REDACTED" (Pi-hole auf FritzBox mit DS-lite)

Help Deutschsprachige Hilfe
1

Moin zusammen.
Ich habe mir zuhause Pi-hole auf meinem Pi 3B eingerichtet was auch mittels der guten Doku von Pi-hole funktioniert. Anschließend bin ich über deren Doku Punkt "Router Setup" noch meine Einstellungen auf meiner FritzBox durchgegangen. Folgendes ist aktuell auf meiner FritzBox eingestellt:

  • Lokaler DNS Server ist unter IPv4 die IP vom pi-hole
  • Der DNSv4 Server ist ebenfalls der pi-hole
  • Um DNS Loop zu vermeiden ist im Pi-hole als Upstream Quad 9 ausgewählt, sowohl IPv4 als auch IPv6
  • Conditional Forwarding ist auch auf die FritzBox eingestellt
  • Mittels eigenem ULA-Präfix hat der Pi auch eine IPv6 Adresse bekommen, die ist im lokalen DNSv6-Server hinterlegt

Der Pi-hole an sich funktioniert wunderbar, jetzt woltle ich noch eine VPN Verbindung mittels Wireguard über PiVPN einrichten. Port forwarding ist in der Fritzbox beim Pi eingerichtet unter dem Standardport 51820, eine DynDNS Adresse habe ich mir über ipv64.net besorgt. Die DynDNS-Adresse ist sowohl in der Fritzbox als auch bei der PiVPN Einrichtung angegeben worden. Clients wurden hinzugefügt aber die bekommen keine Verbindung, folgende Fehler habe ich per debug gesehen:

  1. pivpnNETv6 ist "fd11:5ee:bad:c0de::", den Fehler habe ich auch mehrfach in Posts gesehen
  2. pivpnHOST ist REDACTED
  3. In den Client Configs ist der Endpoint auch REDACTED:51820

Ich bin nicht so tief im Thema DNS und IP-Adressen drin aber wenn ich die Fehler richtig verstehe gibts ein Problem mit der DNS Auflösung unter IPv6 beim DynDNS?
Sobald PiVPN eingerichtet wurde wird ja auch ein neues Interface erschaffen "wg0", das heißt im Pi-hole Interface muss ich unter DNS Interface auch "Permit all origins" ankreuzen, sehe ichb das richtig? Weil ja sonst alles nur bei eth0 durchgelassen wird.

Noch kurz was zu den Einstellungen: Beim Einrichten wundere ich mich ein bisschen über etwas, denn ich habe in mehreren Posts und in Tutorials zwei Einstellungsvarianten gesehen:

  1. Upstream DNS im Pi-hole UI die FritzBox IP Adressen und auf der Fritzbox unter Upstream zB. Quad 9 oder Cloudflare
  2. Upstream DNS im Pi-hole Quad9 und in der FritzBox die Pi-hole Adressen

Wo genau ist der Unterschied ob der Pi-hole den Upstream selber regelt oder ob die FritzBox das macht und Pi-hole das nur weitergibt? Ist das sicherheitsrelevant?

Mir raucht aktuell der Kopf weil ich schon über die Problematik von IPv6 und piVPN gelesen habe, die Posts sind jedoch schon älter daher vermute ich es gibt fixes dazu. Vielleicht kann mir jemand von euch Klarheit darüber schaffen, ich nehme jede Hilfe dankend an! :smile:

2

Just a suggestion. Try running pivpn -d for troubleshooting.

3

Hey smurf.
I've already run the command pivpn -d and it didn't find any problems. After reading through the log, I could find some problematic lines, like pivpnHOST=REDACTED or the client endpoints, which are also REDACTED. I don't know what's exactly misconfigured and whether it's my router (Fritzbox) or my Pi-hole.

4

I thought the pivpn -d would help identify any errors or misconfigurations.

5

Well, there must be some misconfigurations with IPv6 sections and DNS resolving, but I don't know where to fix these problems.

6

Kannst Du bitte genauer erklären, warum Du diese 3 Meldungen als Fehler einstufst?

7

Nun die IPv6 Adresse fd11:5ee:bad:c0de:: sieht nacht leet speak aus "See bad code", deswegen vermute ich es in ne Art Fehlercode.
Der Endpoint der Clients sollte ja auch nicht Redacted mit dem Wireguard Port 51820 sein, sondern die IPv6 meines Pihole bzw. die Dynamische DNS Adresse mit Zugruff über den Port sein oder verstehe ich das falsch? Wieso sollte an den Stellen REDACTED stehen und nicht eine Adresse? Immerhin werte ich das Log als User aus, da sollte doch alles in Klarheit stehen oder nicht?
Zudem funktioniert die VPN Verbindung nun mal nicht, so leite ich mir das her.

8

Sofern Du das nicht bei der Einrichtung von PiVPN geändert hast, ist das einfach das von PiVPN vorgegebene IPv6-Prefix für interne Wireguard-Adressen.

PiVPN unterdrückt die Ausgabe potentiell sensitiver Informationen in seinem Log.
REDACTED bedeutet ganz einfach redigiert oder geschwärzt.

Dementsprechend handelt es sich also nicht um Fehler.

Da es sich bei wg0 auch um ein lokales Interface handelt, ist hier im allgemeinen die Standardeinstellung Allow only local requests nach wie vor ausreichend.

Können sich entfernte Wireguard-Peers denn überhaupt mit Deinem Wireguard im Heimnetz verbinden?
Werden auf wg0 Peers gelistet? Was gibt sudo wg zurück?

9

Ah okay, interessant dass genau diese Kombi gewählt wurde haha.

Okay, dann habe ich es missverstanden. Ich dachte ich müsste auch die klare Adresse sehen können und vermutete irgendwo Fehleinstellungen wodurch diese nicht aufgelöst werden kann.

Okay gut zu wissen, danke für die Klärung dazu :+1:

sudo wg zeigt mir sowohl das Interface mit listening Port und public + private key, meine zwei angelegten Peers tauchen hier mit dem hidden preshared key und den erlaubten IPs auf. Sonst nichts, weder endpoint, noch handshake noch transfer.
pivpn -c zeigt beide peers ohne Remote IP an (none), ein peer ist mein Smartphone welches über die Wireguard App eine Verbindung versucht. Ebenfalls tauchen beide peers nicht bei last seen auf. Sieht also nicht danach aus.

10

Da überhaupt keine Verbindung zustande kommt, ist Pi-hole nicht beteiligt.
Du solltest also in Betracht ziehen, Dein Anliegen zusätzlich auch in PiVPN- und/oder Wireguard-Foren zu platzieren.

Da anzunehmen ist, dass PiVPN zumindest korrekte Wireguard-Konfigurationen erzeugt, wird Dein Problem eher in der Verbindung zwischen der PiVPN-Maschine, Deinem Router und dem Wireguard-Client liegen.

Du solltest Daher zunächst einmal in den Wireguard-Logs Deiner Clients nach Hinweisen auf die Ursache Ausschau halten.

Da Du außerdem an einem DSLite-Anschluss sitzt, können Verbindungen in Dein Heimnetz über IPv4 regelmässig nur zustande kommen, wenn Dein ISP die entsprechenden Ports durchleitet.
Zu diesem Zweck kann Dein ISP Dir einen bestimmten Bereich von Ports zuteilen, die Dein Router über PCP in Erfahrung bringen kann. Oft liegt der Port, den Du selbst verwenden möchtest, aber gerade nicht in diesem Bereich, so dass Du Deine Konfiguration entsprechend anpassen müsstest.
FritzBoxen unterstützen PCP - wird Dir ein solcher Portbereich für IPv4 zugeteilt?

Und welche IPv6-Adresse hast Du bei Deinem DynDNS-Anbieter hinterlegt?
Die Deines Routers oder die Deines Pi-hole-Rechners?

11

Hm okay, werde den Beitrag dann mal parallel posten. Immerhin kann ich dann eine Fehlerquelle ausschließen.

Das kann ich dir nicht sagen. Ich habe mal recherchiert ob ich PCP selbst prüfen kann, anscheinend funktioniert das aber nicht so. Man kann Geräten die "Selbstständige Portfreigabe" ermöglichen, so können Geräte im Heimnetz dann PCP nutzen um sich ihre Ports freizuschalten.
Da die Fritzbox mir aber auch sonst in keinem Graph oder EInstellungen Infos über Portbereiche gibt würde ich vermuten dass ich keine habe.

DIe IPv6 Adresse meiner Fritzbox wurde bei meinem DynDNS Anbieter hinterlegt, das wurde auch automatisch beim Erstellen der DynDNS Domäne gemacht.

12

Es geht in Deinem Fall nicht um die Kommunikation zwischen Client und Router, sondern um die zwischen Router und ISP.
Die Fritzbox versucht ggf., für die von Dir konfigurierten Portfreigaben die entsprechenden externen Ports beim AFTR-Gateway Deines ISPs über PCP zu registrieren. Wenn Dein ISP PCP unterstützt, wird er ggf. andere Ports zurückmelden, als von Dir gewünscht. Dies gilt insbesondere für häufig genutzte Ports (z.B. Port 80 (HTTP) oder 443 (HTTPS)), die bei DSLite in der Regel nicht für IPv4 verfügbar sind.
In der Fritzbox ist dies daran erkennbar, dass für die betreffende Portfreigabe ein Warnhinweis unter Port extern vergeben IPv4 erscheint.
In einem solchen Fall solltest Du erst die Freigabe ändern (damit der Port fix bleibt), wobei Dir die Fritzbox dann auch den für sie verfügbaren Port-Bereich anzeigt, und anschliessend die Software auf den in der Fritzbox-Portfreigabe gewählten Port anpassen.

Sofern Du keinen solchen Hinweis erhältst, war entweder der von Dir angeforderte Port zufällig bei Deinem ISP verfügbar, oder aber Dein ISP unterstützt PCP nicht.
Letzteres würde bedeuten, dass über IPv4 eingehende Verbindungen in Dein Heimnetz technisch grundsätzlich unmöglich sind.

Genaue Informationen dazu solltest Du bei Deinem ISP erfragen.

13

Ich bin nochmal meine ganzen Einstellungen durchgegangen und habe erneut diverse Posts und Tutorials zur Verwendung von IPv6 und PiVPN durchgelesen. Zum einen habe ich meine Einstellungen mit folgendem Tutorial abgeglichen: https://blog.helmutkarger.de/raspberry-pi-v…-trotz-ds-lite/. Dieses verweist auf einen anderen Teil zur Vorbereitung von IPv6 und PiVPN: https://blog.helmutkarger.de/raspberry-pi-v…vpn-unter-ipv6/. Die dhcpcd.conf hatte ich zum Beispiel gar nicht, also habe ich dhcpcd5 nachinstalliert. Mittels auskommentieren slaac private habe ich dann meine IPv6 Adresse bzw. die Interface ID statisch gemacht, was vorher gar nicht der Fall war. Ich habe mittels ifconfig -a dann nochmal meine IPs gecheckt und die haben dieselbe Interface ID. Ich habe nach den Einstellungen aus dem ersten Link auch den DynDNS auf meine globale IPv6 des Pi verwiesen, in der Fritzbox meine Adressen zum Pi angepasst und den Port 1194 unter IPv6 freigegeben. PiVPN habe ich nun nochmal neu installiert mit den neuen Einstellungen.
Tatsächlich kann ich mich endlich sowohl mit meinem Desktop PC als auch mit meinem Smartphone mit dem VPN Tunnel verbinden. Mit meinem Smartphone kann ich über mobile Daten sowohl auf den Pihole als auch die Fritzbox zugreifen endlich :sweat_smile:
Stand jetzt ist folgender:

  • DynDNS zeigt auf globale IPv6 des Pi
  • Wireguard Port 1194 in der Firtzbox für den Pi unter IPv6 fregegeben
  • Pi-hole ist lokaler DNv4 und DNv6 Server
  • Pi-hole läuft einwandfrei und blockiert

Wenn ich mich über meinen Desktop PC mit dem Tunnel verbinde klappt das laut WG Programm auch, jedoch habe ich hier gar kein Internet. Egal welche Seiten ich aufrufe ich bekomme keine Verbindung. Habe ich hier zu der Nutzung des VPN etwas falsch verstanden? Zum einen wollte ich mit meinem Smartphone das Adblocken nutzen, zum anderen wollte ich auch meinen Internettraffic etwas privater machen, wie als wenn ich Proton nutzen würde (was auch nur Wireguard nutzt). Ist das hier gar nicht gegeben?

14

Schön, dass es funktioniert.
Setzt Du denn auch den in den Blogs erwähnten vServer mit socat ein, oder funktioniert die Portfreigabe mit Deinem ISP?

Damit das jedenfalls auch dauerhaft funktioniert, solltest Du die IPv6-Adresseinstellungen auf Deinem RPi aber noch einmal genauer hinterfragen.

Bei den meisten Distros werden IPv6 IIDs standardmässig nach EUI-64 oder nach RFC 7217 erzeugt. So erzeugte IIDs sind bereits stabil und ändern sich nicht über die Zeit, sondern höchstens bei Änderung des Präfixes.
Zusätzlich(!) dazu erzeugen die meisten Distros auch eine temporäre IPv6-Adresse nach RFC 8981 zur Nutzung für ausgehende Verbindungen, die sich regelmässig ändern.

dhcpcd's slaac private sorgt dabei bereits dafür, dass eine stabile IID für IPv6 nach RFC 7217 erzeugt wird.
Diese Änderung wäre also einerseits überhaupt nicht nötig gewesen, im Gegenteil: Die standardmässig erzeugten EUI-64-IIDs enthalten die MAC-Adresse, wodurch Dein Gerät leicht zu tracken ist und gleichzeitig Deine Hardware identifizierbar wird, selbst wenn das Präfix sich ändern sollte.
Wenn man schon auf temporäre IPv6-Adressen verzichtet, wäre eine IPv6 nach RFC 7217 also die bessere Wahl, da so zumindest die MAC-Adresse nicht exponiert wird.

Anderseits lässt sich das Verfahren für die Erzeugung stabiler IIDs im allgemeinen auch in den jeweils vom OS verwendeten Netzwerktools einstellen. Bei den aktuellen RaspberryPi OS Releases ist das NetworkManager, und die zugehörige Variable im Connection-Profil ist addr-gen-mode.
Es wäre also aus mehreren Gründen nicht nötig gewesen, dhcpcd zu installieren.

Sofern NetworkManager immer noch aktiv ist, könnte es hier außerdem zu Konflikten bei der Adressvergabe kommen.
Ich würde vielleicht überlegen, dhcpcd zu deinstallieren und NetworkManager passend zu konfigurieren.

Egal, wie die stabile IID erzeugt wird:
Die IPv6-Adresse Deines RPi wird sich ändern, sobald Deinem Router ein neues IPv6-Präfix zugeteilt wird.

In einem solchen Fall musst Du also bei Deinem DynDNS-Anbieter die aktuelle IPv6-Adresse Deines RPi hinterlegen.
Dazu brauchst Du einen DynDNS-Client auf dem RPi.
Und wenn der installiert ist, werden geänderte IPv6-Adressen grundsätzlich an Deinen DynDNS-Anbieter gemeldet, egal ob die IIDs stabil sind oder nicht. :wink:

Ein VPN-Zugriff auf Dein Heimnetz ist es etwas anderes als ein VPN-Service-Anbieter.

Letzterer betreibt eine Infrastruktur, über die er Deinen Datenverkehr verschlüsselt leitet, in der Regel mit verschiedenen Exit-Knoten in verschiedenen Ländern, über die er Deine eigentliche IP und damit Deine Herkunft verschleiern kann.

Der VPN-Zugriff auf's Heimnetz erlaubt Dir auch von unterwegs, DNS-Anfragen über den heimischen Pi-hole zu filtern und mindestens Deinen DNS-Verkehr zu verschlüsseln, oder auch sämtliche Kommunikation (wobei das meist auf Kosten der Geschwindigkeit geht, weil ein Heimanschluss im Upload meist langsamer ist).
Die Verschleierung Deiner IP vor den Zielservern ist damit nicht möglich - es bleibt ja immer Dein Router, über den der Verkehr läuft (also sozusagen immer derselbe Exit-Knoten).

Steht der Desktop bei Dir im Heimnetz?
Taucht ein nslookup in Pi-hole unter der WireguardIP des Desktops auf, wenn Du es bei aktivierter Wireguard-Verbindung absetzt?

15

Nein den vServer nutze ich nicht, allein die Portfreigabe hat gereicht.

Hm okay, teilweise meine MAC Adresse zu hinterlegen finde ich wirklich nicht gut. Das heißt entweder die Kommentierung wieder rausnehmen oder über Networkmanager alles einstellen?

Da könnte ich den ddclient nehmen oder? Davon habe ich auch schon gelesen. Dann muss ich mich mal mit dem auseinander setzen.

Ja okay verstehe wo mein Denkfehler liegt, schade drum da man bei Proton im free tarif nur ein Gerät nutzen kann.

Desktop steht im Heimnetz ja, das mit nslookup werde ich mal testen.