WireGuard VPN mit Pi-hole DNS funktioniert nicht: Keine Internetverbindung trotz bestehender VPN-Verbindung

androidin

New member
Hallo, kürzlich habt ihr mir schonmal bei der Inbetriebnahme geholfen. Ich habe nun einige Veränderungen vorgenommen und komme einfach nicht mehr weiter.

Ich habe einen WireGuard VPN-Server auf einem Raspberry Pi eingerichtet, der in meinem Heimnetzwerk hinter einer Fritzbox läuft. Mein Ziel ist es, den gesamten Traffic meiner mobilen Geräte über den VPN-Tunnel zu leiten und dabei Pi-hole zur DNS-basierten Werbung- und Tracker-Blockierung zu verwenden.

Setup:
  • Server: Raspberry Pi mit Pi-hole und WireGuard.
  • Router: Fritzbox mit aktivierter Firewall und DoT (DNS over TLS).
  • Client: Smartphone (Android/iOS).
  • WireGuard: Aktuelle Versionen auf Server und Client.
Konfiguration:
  • WireGuard Server (/etc/wireguard/wg0.conf):
    INI:
    [Interface]
    Address = 10.8.0.1/24, fd01::1/64
    ListenPort = 51820
    PrivateKey = <Server Private Key>
    PostUp = iptables -A FORWARD -i %i -o eth0 -j ACCEPT; iptables -A FORWARD -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380; ip6tables -A FORWARD -i %i -o eth0 -j ACCEPT; ip6tables -A FORWARD -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    PostDown = iptables -D FORWARD -i %i -o eth0 -j ACCEPT; iptables -D FORWARD -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380; ip6tables -D FORWARD -i %i -o eth0 -j ACCEPT; ip6tables -D FORWARD -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
    SaveConfig = true
    
    [Peer]
    PublicKey = <Client Public Key>
    AllowedIPs = 10.8.0.2/32, fd01::2/128


  • WireGuard Client:
    INI:
    [Interface]
    PrivateKey = <Client Private Key>
    Address = 10.8.0.2/32, fd01::2/128
    DNS = 192.168.178.19, fd00::5ae5:15b3:47b9:7cd5 # Pi-hole IP-Adressen
    MTU = 1400
    
    [Peer]
    PublicKey = <Server Public Key>
    AllowedIPs = 0.0.0.0/0, ::/0
    Endpoint = <Fritznetadresse>:51820
    PersistentKeepalive = 25

  • Fritzbox:
    • Lokaler DNS-Server (IPv4): 192.168.178.19 (Pi-hole)
    • DNSv6-Server: fd00::5ae5:15b3:47b9:7cd5 (Pi-hole)
    • Upstream-DNS-Server: AdGuard und AdminForge (mit aktivierter DoT-Verschlüsselung).
  • Pi-hole:
    • Upstream-DNS-Server: Fritzbox (192.168.178.1 und fd00::eadf:70ff:feca:5880).
    • "Allow only local requests": Aktiviert
    • "Never forward non-FQDN A and AAAA queries": Deaktiviert
    • "Conditional Forwarding": Deaktiviert
Problem:

Nach dem Starten des WireGuard-Clients besteht zwar eine Verbindung (der Tunnel wird als aktiv angezeigt), aber es ist kein Internetzugriff möglich. Weder Webseiten noch Apps können eine Verbindung herstellen.

Bisherige Fehlersuche:
  • Grundlegende WireGuard-Verbindung wurde durch Pings und direkten Zugriff auf IP-Adressen getestet (funktioniert).
  • Firewall der Fritzbox wurde überprüft (Portfreigabe für WireGuard ist eingerichtet).
  • DynDNS-Konfiguration wurde überprüft.
  • Verschiedene Konfigurationen der Pi-hole Upstream-DNS-Server wurden getestet (direkt mit öffentlichen DNS-Servern, mit der Fritzbox als Upstream).
  • MTU/MSS wurde angepasst.
  • tcpdump auf dem Server wurde durchgeführt.
  • Wenn im Client temorär Google-DNS-Server hinterlegt werden funktioniert der Internetzugriff ohne Probleme
Aktueller Stand:
  • Die WireGuard-Verbindung scheint zu bestehen, aber es gibt keinen Internetzugriff.
  • Die direkte Verbindung über IP-Adressen funktioniert (glaube ich, denn z. B. bei der http://1.1.1.1 wird mir angezeigt, dass es eine unsichere Webseite wäre
  • DNS funktioniert nicht.
Fragen an das Forum:
  • Hat jemand ähnliche Probleme mit dieser Konfiguration gehabt und eine Lösung gefunden?
  • Gibt es spezifische Einstellungen in der Fritzbox, die beachtet werden müssen?
  • Gibt es weitere Möglichkeiten, das Routing oder die Firewall-Regeln auf dem Raspberry Pi zu überprüfen?
Zusätzliche Informationen:
  • ip a Ausgabe vom Raspberry Pi:
Bash:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.19/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
        valid_lft 862671sec preferred_lft 862671sec
    inet6 fd00::5ae5:15b3:47b9:7cd5/64 scope global dynamic noprefixroute
        valid_lft 6832sec preferred_lft 3232sec
    inet6 2003:xxxx:xxxx:xxxx::/64 scope global dynamic noprefixroute
        valid_lft 6832sec preferred_lft 1412sec
    inet6 fe80::195a:1ed9:2ded:3b1b/64 scope link noprefixroute
        valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.8.0.1/24 scope global wg0
        valid_lft forever preferred_lft forever
    inet6 fd01::1/64 scope global
        valid_lft forever preferred_lft forever
  • tcpdump-Ausgaben können auf Anfrage bereitgestellt werden.


Ich bin für jede Hilfe und jeden Hinweis dankbar.
 
Moinsen,
Ich denke, @Barungar liegt da ganz richtig mit seiner Vermutung...
Ich mache schon länger nix mit pihole...kannst du da ggf auch statt "all" den Zugriff mittlerweile auch für einzelne Netze erlauben (also LAN und WG Netzwerk > allow)?
 
In einer solchen Konstellation muß der pi-hole mit einer der “unsicheren” Einstellungen betrieben werden:
IMG_2075.jpeg
Entweder mit eth0 (wenn der Pi über den LAN-Anschluß an der Fritzbox hängt) oder mit “all origins”.
Local requests antwortet nur bei Entfernungen von maximal einem hop. Hier vermutlich eher mit “all origins”, weil die Anfrage über wg0 hereinkommt.
 
In einer solchen Konstellation muß der pi-hole mit einer der “unsicheren” Einstellungen betrieben werden:
Anhang anzeigen 9561
Entweder mit eth0 (wenn der Pi über den LAN-Anschluß an der Fritzbox hängt) oder mit “all origins”.
Local requests antwortet nur bei Entfernungen von maximal einem hop. Hier vermutlich eher mit “all origins”, weil die Anfrage über wg0 hereinkommt.
Das hatte ich auch schon ausprobiert. Leider kein Erfolg. Sogar nicht, wenn ich Permit all origins zulasse. Auch dann nicht, wenn ich PiHole komplett deaktiviere. Gestern hatte ich es ja schonmal am Laufen, aber das System war zu instabil und als es lief war auch nur Allow only local requests aktiv. Kleine Änderungen, die ich nicht mehr nachvollziehen kann haben diesen Zustand bewirkt. Aber was ich sagen kann: stelle ich in der Client WG Config öffentliche DNS-Server ein, so funktioniert der Internetzugriff auf dem Client. Sobald ich auf den Pihole verweise nicht mehr.

Edit: das hier sind übrigens die relevanten Firewall-Regeln:

Bash:
sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), allow (routed)
New profiles: skip


To                         Action      From
--                         ------      ----
53/tcp                     DENY IN     Anywhere
53/udp                     ALLOW IN    192.168.178.0/24
51820/udp                  ALLOW IN    Anywhere


53/tcp (v6)                DENY IN     Anywhere (v6)
53/udp                     ALLOW IN    fd00::/64
51820/udp (v6)             ALLOW IN    Anywhere (v6)


Anywhere on wg0            ALLOW FWD   Anywhere on eth0
Anywhere on eth0           ALLOW FWD   Anywhere on wg0
Anywhere (v6) on wg0       ALLOW FWD   Anywhere (v6) on eth0
Anywhere (v6) on eth0      ALLOW FWD   Anywhere (v6) on wg0

Und hier die Weiterhleitungen:

Bash:
bernd@raspberrypi:~ $  sudo sysctl -p
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
sysctl: cannot stat /proc/sys/net/ipv6/ip_forward: No such file or directory
net.ipv6.conf.all.forwarding = 1

Und hier die Weiterleitungsregeln:
Bash:
bernd@raspberrypi:~ $ sudo iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 110K 6978K MASQUERADE  all  --  any    eth0    anywhere             anywhere
bernd@raspberrypi:~ $ sudo iptables -L FORWARD -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   65  3900 TCPMSS     tcp  --  any    any     anywhere             anywhere             tcp flags:SYN,RST/SYN TCPMSS set 1380
  547 72544 ufw-before-logging-forward  all  --  any    any     anywhere             anywhere
  547 72544 ufw-before-forward  all  --  any    any     anywhere             anywhere
    0     0 ufw-after-forward  all  --  any    any     anywhere             anywhere
    0     0 ufw-after-logging-forward  all  --  any    any     anywhere             anywhere
    0     0 ufw-reject-forward  all  --  any    any     anywhere             anywhere
    0     0 ufw-track-forward  all  --  any    any     anywhere             anywhere
    0     0 ACCEPT     all  --  wg0    eth0    anywhere             anywhere
    0     0 ACCEPT     all  --  any    wg0     anywhere             anywhere             ctstate RELATED,ESTABLISHED

Edit2: schalte ich die ufw temporär ab, dann funktioniert alles wie erwartet: Der Client kann Domains auflösen - es muss also an den Firewalleinstellungen liegen

Edit3: Leider helfen diese Befehle nicht, das Problem zu lösen - was mach ich denn falsch?

Bash:
sudo ufw allow in on wg0 to 127.0.0.1 port 53 proto udp from 10.8.0.0/24
sudo ufw allow in on wg0 to 127.0.0.1 port 53 proto tcp from 10.8.0.0/24


sudo ufw allow in on wg0 to ::1 port 53 proto udp from fd01::/64
sudo ufw allow in on wg0 to ::1 port 53 proto tcp from fd01::/64
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
6.054
Beiträge
58.837
Mitglieder
6.069
Neuestes Mitglied
baliuser
Zurück
Oben