Probleme mit Abfragen von Unbound durch VPN-Tunnel

[Shutterfly]

Moin moin,

ich benötige mal einen schlauen Tipp, sonst drehe ich noch am Rad. Folgendes Szenario: Ich habe auf meiner Firewall ein VPN-Tunnel aktiv, welcher dedizierte lokale IP-Adressen komplett durch den VPN-Tunnel schickt. Dies funktioniert soweit korrekt.

Nun wollte ich einmal etwas mit pi-hole spielen, habe mir eine VM aufgesetzt, statische IP zugewiesen und ebenfalls durchs VPN geschickt. Somit geht der komplette Traffic (UPD, TCP usw.) komplett durch den Tunnel. Möchte ich nun pi-hole mit unbound als Resolver betreiben, dann funktioniert dies nur, wenn ich den Traffic nicht durch den VPN-Tunnel schicke. Sobald der VPN-Tunnel genutzt wird kann unbound keine DNS-Anfrage korrekt auflösen. Folgendes Beispiel an www.heise.de, der Auszug des Logs ist von unbound.

Anfrage wurde gestellt mit dig www.heise.de @127.0.0.1 -p 5335

Ohne VPN-Tunnel:

[1617134347] unbound[157:0] info: resolving www.heise.de. A IN
[1617134347] unbound[157:0] info: response for www.heise.de. A IN
[1617134347] unbound[157:0] info: reply from <.> 199.7.83.42#53
[1617134347] unbound[157:0] info: query response was REFERRAL
[1617134347] unbound[157:0] info: response for www.heise.de. A IN
[1617134347] unbound[157:0] info: reply from <de.> 194.146.107.6#53
[1617134347] unbound[157:0] info: query response was REFERRAL
[1617134347] unbound[157:0] info: resolving ns2.pop-hannover.net. A IN
[1617134347] unbound[157:0] info: response for www.heise.de. A IN
[1617134347] unbound[157:0] info: reply from <heise.de.> 212.19.40.14#53
[1617134347] unbound[157:0] info: query response was ANSWER
[1617134347] unbound[157:0] info: validated DS de. DS IN
[1617134347] unbound[157:0] info: resolving de. DNSKEY IN
[1617134347] unbound[157:0] info: response for ns2.pop-hannover.net. A IN
[1617134347] unbound[157:0] info: reply from <net.> 192.43.172.30#53
[1617134347] unbound[157:0] info: query response was REFERRAL
[1617134347] unbound[157:0] info: response for ns2.pop-hannover.net. A IN
[1617134347] unbound[157:0] info: reply from <pop-hannover.net.> 62.48.67.66#53
[1617134347] unbound[157:0] info: query response was ANSWER
[1617134347] unbound[157:0] info: response for de. DNSKEY IN
[1617134347] unbound[157:0] info: reply from <de.> 77.67.63.105#53
[1617134347] unbound[157:0] info: query response was ANSWER
[1617134347] unbound[157:0] info: validated DNSKEY de. DNSKEY IN
[1617134347] unbound[157:0] info: NSEC3s for the referral proved no DS.
[1617134347] unbound[157:0] info: Verified that unsigned response is INSECURE

Mit VPN-Tunnel:

[1617134453] unbound[166:0] info: resolving www.heise.de. A IN
[1617134453] unbound[166:0] info: response for www.heise.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 198.41.0.4#53
[1617134453] unbound[166:0] info: query response was nodata ANSWER
[1617134453] unbound[166:0] info: response for www.heise.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 192.112.36.4#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: resolving ns.plusline.de. A IN
[1617134453] unbound[166:0] info: resolving ns2.pop-hannover.net. A IN
[1617134453] unbound[166:0] info: resolving ns.s.plusline.de. A IN
[1617134453] unbound[166:0] info: response for ns.plusline.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 202.12.27.33#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: resolving ns.txx.plusline.de. A IN
[1617134453] unbound[166:0] info: response for ns.s.plusline.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 192.36.148.17#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: response for ns.txx.plusline.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 192.5.5.241#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: resolving ns.txx.plusline.de. A IN
[1617134453] unbound[166:0] info: response for ns2.pop-hannover.net. A IN
[1617134453] unbound[166:0] info: reply from <.> 198.41.0.4#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: resolving ns.pop-hannover.de. A IN
[1617134453] unbound[166:0] info: response for ns.txx.plusline.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 192.112.36.4#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: resolving ns.s.plusline.de. A IN
[1617134453] unbound[166:0] info: response for ns.pop-hannover.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 199.7.91.13#53
[1617134453] unbound[166:0] info: query response was REFERRAL
[1617134453] unbound[166:0] info: response for ns.s.plusline.de. A IN
[1617134453] unbound[166:0] info: reply from <.> 192.33.4.12#53
[1617134453] unbound[166:0] info: query response was REFERRAL

Es fällt auf, dass mit VPN-Tunnel kein Query-Response vom Typ "ANSWER" existiert und daher keine Antwort geliefert werden kann. Einzig "nodata ANSWER" finde ich manchmal.

Nun habe ich gedacht, dass der VPN-Tunnel keine DNS-Anfragen durch lässt, z.b. weil UDP 53 geblockt ist oder so. Wenn ich aber während aktivem VPN-Tunnel einen öffentlichen DNS-Server anfrage, dann erhalte ich eine Antwort:

root@pi-hole:~# dig www.heise.de @8.8.8.8 www.heise.de

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> www.heise.de @8.8.8.8 www.heise.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62851
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d4654787e26c08f48606d73760639c68d7a5140f5bd69b5b (good)
;; QUESTION SECTION:
;www.heise.de.            IN    A

;; ANSWER SECTION:
www.heise.de.        6523    IN    A    193.99.144.85

;; AUTHORITY SECTION:
heise.de.        6523    IN    NS    ns.pop-hannover.de.
heise.de.        6523    IN    NS    ns.s.plusline.de.
heise.de.        6523    IN    NS    ns.heise.de.
heise.de.        6523    IN    NS    ns2.pop-hannover.net.
heise.de.        6523    IN    NS    ns.plusline.de.

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Mar 30 21:47:20 UTC 2021
;; MSG SIZE  rcvd: 211

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12421
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.heise.de.            IN    A

;; ANSWER SECTION:
www.heise.de.        86400    IN    A    193.99.144.85

;; Query time: 70 msec
;; SERVER: 10.0.1.200#53(10.0.1.200)
;; WHEN: Tue Mar 30 21:47:20 UTC 2021
;; MSG SIZE  rcvd: 57

Daher würde ich nun vermuten, dass die DNS-Anfragen grundsätzlich durch den Tunnel funktionieren, sonst hätte ich auch hier Probleme erwartet.

Nun verstehe ich jedoch nicht wo das Problem liegen kann, dass unbound mit und ohne VPN-Tunnel so unterschiedliche und nicht funktionierende Ergebnisse liefert, wenngleich DNS-Anfragen per VPN funktionieren.

Hat hier irgendwer einen klugen Tipp?

 

[sch4kal]

Meistens ist sowas ein MTU Problem, schau mal in Wireshark am Unbound wie groß die Antwortpakete sind und validiere das mit ICMP Echos mit entsprechendem Payload.
DNS ist aufgrund seines Aufbaus dafür bekannt, größere Antwort- als Anfragepakete zu senden. Deswegen wird DNS bei bösen Jungs auch gern mittels Amplification als Attacke missbraucht.

 

[Shutterfly]

Uff, danke für den Tipp @sch4kal. Keine Ahnung wie ich das unterm Strich hinbekomme aber ich werd es in die Richtung mal versuchen.

 

[TCM]

Mach mal ein dig www.heise.de +trace durch den Tunnel.

 

[drigga]

Habe leider genau das gleiche Problem. Ich habe lediglich noch pihole zwischengeschaltet.
unbound mit einem public dns funktioniert problemlos, wenn es aber lokal auf aufgelöst werden soll, steht im pihole die Meldung servfail