Die Kombination aus Proxmox, PiHole und Wireguard ist ein Traum für viele Heimnetzwerk-Enthusiasten. Sie ermöglicht es, einen leistungsstarken, werbefreien und sicheren DNS-Dienst bereitzustellen, der sowohl im lokalen Netzwerk als auch unterwegs über ein VPN zugänglich ist. Doch wie so oft bei komplexeren Setups können unerwartete Probleme auftauchen. Eines der frustrierendsten ist, wenn Ihr PiHole zwar grundsätzlich funktioniert, aber Anfragen über Wireguard von einer scheinbar „falschen” IP-Adresse beantwortet.
Dieses Phänomen kann zu Verwirrung, unerwartetem Verhalten oder sogar dazu führen, dass Clients die DNS-Antworten nicht korrekt verarbeiten. Wenn Ihr Wireguard-Client Anfragen an die PiHole-IP im VPN-Tunnel sendet, aber die Antwort plötzlich von der Proxmox-Host-IP oder einer anderen internen VM-IP zu kommen scheint, sind Sie hier genau richtig. Dieser Artikel führt Sie detailliert durch die Ursachen und Lösungen, um Ihr Setup wieder in den Griff zu bekommen.
Das Problem verstehen: Was bedeutet „falscher Absender”?
Bevor wir uns in die Fehlerbehebung stürzen, sollten wir genau definieren, was wir unter einem „falschen Absender” verstehen. Im Idealfall sendet Ihr Wireguard-Client eine DNS-Anfrage an die IP-Adresse des PiHole innerhalb des Wireguard-Tunnels (z.B. 10.0.0.1, wenn der PiHole der Wireguard-Server ist). Die Antwort sollte dann ebenfalls von genau dieser IP-Adresse des PiHole im Wireguard-Tunnel zurückkommen.
Ein „falscher Absender” liegt vor, wenn die Anfrage an 10.0.0.1 geht, die Antwort aber beispielsweise von 192.168.1.10 (der LAN-IP des PiHole-VM) oder sogar 192.168.1.5 (der LAN-IP des Proxmox-Hosts) stammt. Das bedeutet, dass die Pakete auf ihrem Rückweg umgeleitet oder durch Network Address Translation (NAT) so verändert wurden, dass die ursprüngliche Quell-IP des PiHole im Wireguard-Tunnel verloren gegangen ist oder überschrieben wurde. Dies ist häufig ein Indikator für eine Fehlkonfiguration im Routing, in den Firewall-Regeln (iptables) oder in der Netzwerkkonfiguration der virtuellen Maschine oder des Proxmox-Hosts selbst.
Häufige Ursachen für den „falschen Absender”
Die Ursachen für dieses Problem sind vielfältig, konzentrieren sich aber meist auf die Netzwerkebene. Hier sind die gängigsten Verdächtigen:
1. Fehlkonfiguration der Netzwerkbrücke in Proxmox
Die Art und Weise, wie die virtuelle Maschine (VM) für PiHole in Proxmox ihr Netzwerk nutzt, ist entscheidend. Wenn die VM nicht im Bridge-Modus (z.B. vmbr0) konfiguriert ist oder die Bridge selbst nicht korrekt eingerichtet ist, kann es zu Routing-Problemen kommen.
2. Inkorrekte Wireguard-Server-Konfiguration auf dem PiHole
Der Wireguard-Server auf Ihrer PiHole-VM benötigt spezifische PostUp/PostDown-Regeln, um den Traffic korrekt weiterzuleiten und gegebenenfalls zu maskieren (NAT). Fehlen diese Regeln oder sind sie fehlerhaft, werden Pakete möglicherweise nicht korrekt in den Wireguard-Tunnel zurückgeleitet.
3. Fehlende IP-Weiterleitung (IP Forwarding)
Damit Ihre PiHole-VM als Router für den Wireguard-Traffic agieren kann, muss die IP-Weiterleitung auf Systemebene aktiviert sein. Dies geschieht über sysctl-Parameter. Wenn dieser nicht gesetzt ist, kann die VM Pakete, die nicht für sie selbst bestimmt sind, nicht korrekt an andere Netze weiterleiten.
4. Falsche oder fehlende iptables/nftables-Regeln
Firewall-Regeln spielen eine zentrale Rolle. Insbesondere NAT-Regeln (MASQUERADE/SNAT) können dazu führen, dass die Quell-IP eines Pakets beim Verlassen eines Interfaces geändert wird. Ist eine solche Regel falsch gesetzt oder zu weit gefasst, kann sie die gewünschte Wireguard-Tunnel-IP durch eine andere, z.B. die LAN-IP des Hosts, ersetzen.
5. Routing-Probleme auf der PiHole-VM oder dem Proxmox-Host
Wenn die Routing-Tabelle nicht den korrekten Weg für die Pakete zurück zum Wireguard-Client über den Tunnel definiert, sucht das System einen alternativen, oft falschen Weg, der das Paket über die falsche Quell-IP sendet.
6. DNS-Server-Bindung im PiHole
Obwohl seltener, kann es vorkommen, dass PiHole (genauer gesagt dnsmasq) angewiesen wird, nur auf bestimmten Interfaces zu lauschen oder seine Antworten mit einer spezifischen Quell-IP zu versehen, was zu Problemen führen könnte.
Schritt-für-Schritt-Fehlerbehebung
Um das Problem zu beheben, gehen wir systematisch vor. Notieren Sie sich alle relevanten IP-Adressen, Subnetze und Konfigurationen.
Schritt 1: Bestandsaufnahme und Netzwerkcheck
Sammeln Sie Informationen über Ihre aktuelle Konfiguration:
- Proxmox Host: LAN-IP (z.B.
192.168.1.5), Netzwerkkonfiguration (/etc/network/interfaces), Firewall-Status (iptables -vnL). - PiHole VM: LAN-IP (z.B.
192.168.1.10), Wireguard-Tunnel-IP (z.B.10.0.0.1), Netzwerkkonfiguration (ip a,/etc/netplan/*.yamloder/etc/network/interfaces), Wireguard-Konfiguration (/etc/wireguard/wg0.conf), Firewall-Status (sudo ufw statusoderiptables -vnL),sysctl-Parameter (sysctl net.ipv4.ip_forward). - Wireguard Client: Wireguard-Tunnel-IP (z.B.
10.0.0.2), konfigurierte DNS-Server-IP.
Stellen Sie sicher, dass Ihre PiHole VM eine statische IP-Adresse im LAN hat und dass sie über die Proxmox-Bridge vmbr0 (oder eine ähnliche Bridge) mit dem physischen Netzwerk verbunden ist. Eine „Bridge” ist fast immer die beste Wahl für VMs, die direkten Netzwerkzugriff benötigen und als Server fungieren.
Schritt 2: Überprüfung der Proxmox-Netzwerkkonfiguration
Öffnen Sie auf Ihrem Proxmox-Host die Datei /etc/network/interfaces. Sie sollte in etwa so aussehen:
auto lo
iface lo inet loopback
auto eno1 # Oder wie Ihr physisches Interface heißt
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.1.5/24 # Ihre Proxmox-Host-IP
gateway 192.168.1.1 # Ihr Router
bridge-ports eno1
bridge-stp off
bridge-fd 0
Stellen Sie sicher, dass vmbr0 korrekt konfiguriert ist und die PiHole-VM dieses Bridge-Netzwerkinterface nutzt.
Schritt 3: Überprüfung der PiHole-VM-Netzwerkkonfiguration
In der PiHole-VM (z.B. Debian/Ubuntu):
Überprüfen Sie /etc/netplan/*.yaml oder /etc/network/interfaces. Die PiHole-VM sollte eine statische IP-Adresse im selben Subnetz wie der Proxmox-Host und der Router haben (z.B. 192.168.1.10/24) und als Gateway Ihren Router (192.168.1.1) nutzen.
Geben Sie ip a ein, um sicherzustellen, dass die PiHole-VM ihre LAN-IP und ihre Wireguard-Tunnel-IP korrekt zugewiesen hat. Das Wireguard-Interface (z.B. wg0) sollte die Tunnel-IP (10.0.0.1) haben.
Schritt 4: Wireguard-Server-Konfiguration auf der PiHole-VM
Die /etc/wireguard/wg0.conf auf Ihrer PiHole-VM (als Wireguard-Server) ist kritisch. Ein typisches Setup sieht so aus:
[Interface]
Address = 10.0.0.1/24 # Die Tunnel-IP Ihres PiHole-Servers
ListenPort = 51820
PrivateKey = <Ihr_privater_Schlüssel>
# WICHTIG: PostUp/PostDown Regeln für IP-Weiterleitung und NAT
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = <Öffentlicher_Schlüssel_des_Clients>
AllowedIPs = 10.0.0.2/32 # Die Tunnel-IP Ihres Clients
Beachten Sie die PostUp– und PostDown-Regeln. Insbesondere iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ist hier von Interesse. Diese Regel sorgt dafür, dass Pakete, die vom Wireguard-Tunnel kommen und über das eth0 (Ihr LAN-Interface in der VM) ins Internet gehen, mit der Quell-IP des eth0-Interfaces maskiert werden. Dies ist korrekt, wenn Wireguard als Gateway für das Internet fungiert. Wenn Wireguard nur für DNS dienen soll, müssen Sie hier präziser sein.
Die kritische Stelle: Wenn MASQUERADE zu aggressiv ist oder auf dem falschen Interface angewendet wird, kann es die Quell-IP der DNS-Antworten auf dem Rückweg über den Tunnel fälschen. Wenn der PiHole selbst der DNS-Server ist, braucht er in der Regel kein MASQUERADE für *seine eigenen* Antworten zurück zum Wireguard-Client über den Tunnel, da die IPs im Tunnel bereits bekannt sind. MASQUERADE ist eher für den Zugriff auf externe Netze durch den Wireguard-Tunnel gedacht.
Lösungsansatz #1 (Präzise MASQUERADE): Wenn der PiHole *nur* DNS-Anfragen beantworten soll und kein Full-Tunnel-VPN für den gesamten Traffic ist, dann ist es oft besser, MASQUERADE nur für den Traffic zu verwenden, der *nicht* für das Wireguard-Subnetz bestimmt ist. Oder, noch besser, es gar nicht zu verwenden, wenn die DNS-Antworten nicht ins Internet geroutet werden müssen, sondern nur zwischen PiHole und Client im Tunnel.
Die oben gezeigten Regeln sind für ein Szenario, in dem der Wireguard-Server als Gateway für den gesamten Client-Verkehr ins Internet dient. Wenn Wireguard *nur* für DNS-Zugriff auf PiHole genutzt wird, könnten diese Regeln das Problem verursachen. Ein DNS-Antwortpaket vom PiHole an den Client sollte im Tunnel bleiben und die Quell-IP des PiHole im Tunnel beibehalten.
Schritt 5: IP-Weiterleitung aktivieren (PiHole-VM)
Stellen Sie sicher, dass IP-Weiterleitung auf der PiHole-VM aktiviert ist. Überprüfen Sie dies mit:
sysctl net.ipv4.ip_forward
Wenn die Ausgabe net.ipv4.ip_forward = 0 ist, müssen Sie sie aktivieren:
sudo sysctl -w net.ipv4.ip_forward=1
Damit die Einstellung dauerhaft ist, bearbeiten Sie /etc/sysctl.conf und fügen Sie hinzu (oder entkommentieren Sie):
net.ipv4.ip_forward = 1
Speichern und anwenden mit sudo sysctl -p.
Schritt 6: Firewall-Regeln (iptables/nftables) prüfen
Überprüfen Sie sowohl auf dem Proxmox-Host als auch auf der PiHole-VM alle iptables-Regeln. Das ist oft die Hauptursache. Führen Sie aus:
sudo iptables -vnL
sudo iptables -vnL -t nat
Suchen Sie nach MASQUERADE– oder SNAT-Regeln, die den Quell-IP-Bereich des Wireguard-Tunnels betreffen könnten. Wenn Sie eine Regel wie iptables -t nat -A POSTROUTING -o vmbr0 -j MASQUERADE auf dem *Proxmox-Host* sehen, die den Traffic aller VMs maskiert, könnte dies eine Rolle spielen. Typischerweise ist dies aber nicht das Problem, da der Traffic durch den Tunnel geht, *bevor* er das Proxmox-Host-Interface verlässt.
Die wahrscheinlichere Ursache ist eine zu generische MASQUERADE-Regel auf der PiHole-VM selbst, die den Verkehr, der von wg0 kommt und über eth0 (oder die LAN-Schnittstelle der VM) gehen *könnte*, maskiert. Wenn das DNS-Antwortpaket, das eigentlich zum Wireguard-Client zurück in den Tunnel gehört, versehentlich über eth0 maskiert wird, bekommt es die Quell-IP von eth0.
Lösungsansatz #2 (Angepasste Wireguard PostUp/PostDown Regeln):
Wenn Ihr PiHole der Wireguard-Server ist und *nur* DNS über den Tunnel bereitstellen soll, ohne den gesamten Client-Traffic ins Internet zu routen, könnten die PostUp-Regeln vereinfacht werden. Die Grund-Forwarding-Regeln sind oft ausreichend:
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
Wenn Sie jedoch wollen, dass der Wireguard-Client über den PiHole auch ins Internet kommt (Full Tunnel VPN), dann brauchen Sie die MASQUERADE-Regel. In diesem Fall müssen Sie sicherstellen, dass die DNS-Antworten nicht davon betroffen sind. Eine Möglichkeit ist, die MASQUERADE-Regel so zu definieren, dass sie *nicht* für das Wireguard-Subnetz gilt:
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ! -d 10.0.0.0/24
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE ! -d 10.0.0.0/24
Diese Regel würde den Traffic maskieren, der über eth0 geht und *nicht* für das Wireguard-Subnetz 10.0.0.0/24 bestimmt ist. Das sollte die DNS-Antworten im Tunnel unberührt lassen.
Schritt 7: Routing-Tabelle überprüfen (PiHole-VM)
Führen Sie auf der PiHole-VM ip route show aus. Überprüfen Sie, ob es eine Route für das Wireguard-Client-Subnetz über das wg0-Interface gibt. Normalerweise wird dies automatisch durch die Wireguard-Konfiguration hinzugefügt.
# Beispielausgabe
default via 192.168.1.1 dev eth0 proto static
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
Die Zeile 10.0.0.0/24 dev wg0 ... ist wichtig und zeigt, dass Traffic für das Wireguard-Subnetz über wg0 geleitet wird.
Schritt 8: Paketanalyse mit tcpdump
Das mächtigste Werkzeug zur Fehlerbehebung ist tcpdump. Führen Sie es auf der PiHole-VM aus, um den Traffic zu beobachten:
# Auf dem Wireguard-Interface lauschen
sudo tcpdump -i wg0 port 53 -vvv
# Auf dem LAN-Interface lauschen
sudo tcpdump -i eth0 port 53 -vvv
Senden Sie von Ihrem Wireguard-Client eine DNS-Anfrage (z.B. dig google.com @10.0.0.1). Beobachten Sie, wo die Pakete ankommen und wo sie herkommen. Sie sollten sehen, wie die Anfrage des Clients auf wg0 eingeht (Quell-IP: Client-WG-IP, Ziel-IP: PiHole-WG-IP). Die Antwort sollte dann ebenfalls über wg0 zurückgehen (Quell-IP: PiHole-WG-IP, Ziel-IP: Client-WG-IP). Wenn die Antwort auf eth0 von einer anderen IP kommt, dann wissen Sie, dass dort eine Umleitung oder Maskierung stattfindet.
Schritt 9: PiHole-Konfiguration prüfen
Überprüfen Sie in der PiHole-Weboberfläche unter „Settings” -> „DNS”, ob PiHole auf allen Interfaces lauscht oder nur auf bestimmten. Normalerweise ist die Standardeinstellung „Listen on all interfaces, permit all origins” oder „Listen on all interfaces” die richtige Wahl für ein solches Setup, damit es sowohl auf eth0 als auch auf wg0 Anfragen empfangen kann.
Zusammenfassung und Best Practices
Das Problem des „falschen Absenders” bei PiHole/Proxmox/Wireguard ist fast immer auf eine Fehlkonfiguration im Netzwerk-Stack oder den Firewall-Regeln zurückzuführen, die die Quell-IP von DNS-Antwortpaketen verändert. Die häufigsten Ursachen sind:
- Zu generische
MASQUERADE/SNAT-Regeln auf der PiHole-VM, die Pakete maskieren, die eigentlich im Wireguard-Tunnel bleiben sollten. - Fehlende oder falsche IP-Weiterleitung.
- Inkorrekte Routing-Tabellen.
Die Lösung liegt oft darin, die PostUp/PostDown-Regeln in der wg0.conf auf der PiHole-VM genau auf Ihren Anwendungsfall abzustimmen. Wenn Sie *nur* DNS über Wireguard bereitstellen möchten, benötigen Sie möglicherweise gar keine MASQUERADE-Regel in der Wireguard-Konfiguration selbst, da DNS-Antworten nicht ins Internet geroutet werden müssen, sondern im Tunnel bleiben.
Best Practices:
- Statische IPs: Verwenden Sie immer statische IP-Adressen für Ihre PiHole-VM und die Wireguard-Tunnel-IPs.
- Dokumentation: Notieren Sie sich Ihre IP-Adressen, Subnetze und jede Konfigurationsänderung.
- Minimalismus bei Firewalls: Fügen Sie nur die benötigten Firewall-Regeln hinzu. Jede zusätzliche Regel erhöht die Komplexität und das Fehlerrisiko.
- Testen in Schritten: Aktivieren Sie Wireguard ohne komplexe
PostUp-Regeln und testen Sie die Konnektivität. Fügen Sie dann die Regeln schrittweise hinzu. - Paketanalyse:
tcpdumpist Ihr bester Freund bei Netzwerkproblemen. Lernen Sie, es effektiv zu nutzen.
Fazit
Die Behebung des Problems, bei dem Ihr PiHole über Wireguard von der falschen IP-Adresse antwortet, erfordert einen methodischen Ansatz zur Analyse Ihrer Netzwerkkonfiguration, insbesondere der Wireguard-Server-Einstellungen und der Firewall-Regeln (iptables) auf der PiHole-VM. Durch das Verständnis, wie Pakete geroutet und potenziell maskiert werden, können Sie die genaue Ursache lokalisieren und präzise Anpassungen vornehmen. Mit Geduld und den richtigen Werkzeugen wird Ihr PiHole in Proxmox bald wieder reibungslos und korrekt über Wireguard funktionieren, und Sie können die Vorteile eines sicheren, werbefreien Internets in vollen Zügen genießen.