Hi @DanSchaper ,
This is a tough one to crack. I've spent the past hour trying to make some sense of the data I got from the Wireshark trace but I am a bit lost currently. I think there are multiple issues with my Pi-hole(s), so I'll try to seperate them. I apologize, in advance, for the wall of text.
DNS requests over IPv6 not working
This issue is rather 'interesting'. So according to test-ipv6.com and digwebinterface.com, my Pi-holes are not responding to IPv6 queries. However, if I do a nslookup ipv6.google.com my Pi-hole responds nicely:
C:\Users\Freek>nslookup ipv6.google.com
Server: pihole-nl
Address: 2a00:1ca8:17:3c9::7384
Non-authoritative answer:
Name: ipv6.l.google.com
Address: 2a00:1450:4001:81b::200e
Aliases: ipv6.google.com
But if I run dig locally, the operation times out:
D:\Downloads\BIND9.12.1.x64>dig -t MX google.com
; <<>> DiG 9.12.1 <<>> -t MX google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
However, if I force/specify the resolver when using dig, the Pi-hole responds:
D:\Downloads\BIND9.12.1.x64>dig -t MX google.com @2a00:1ca8:17:3c9::7384
; <<>> DiG 9.12.1 <<>> -t MX google.com @2a00:1ca8:17:3c9::7384
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49229
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11
<Removed for readability>
;; Query time: 76 msec
;; SERVER: 2a00:1ca8:17:3c9::7384#53(2a00:1ca8:17:3c9::7384)
;; WHEN: Fri May 11 17:23:27 West-Europa (zomertijd) 2018
;; MSG SIZE rcvd: 367
I find this to be very confusing; why does remote dig not work and why does local dig only work when I force/specifically point it to my Pi-hole, even though it's setup as default DNS server within my connection?
The WireShark trace shows 'Destination Unreachable (Port unreachable)' multiple times for the ICMPv6 protocol, with the source being my Pihole and the destination being my PC, followed by a 'Packet too big'. I have no clue what to make of this to be honest: https://i.imgur.com/RpuNefb.png
Web-interface unreachable if ufw is disabled
This leaves me stumped. As soon as I disable ufw, the Pi-hole's webinterface does not load anymore. With ufw enabled, it works like it should.... Ufw has no rewrite rules so this should have nothing to do with reverse proxy stuff or anything related. Odd thing is that on the server side (Pi-hole) the lighttpd, ufw and/or Pi-hole logs show nothing relevant regarding a blocked/dropped/incoming connection or request.
However, the Wireshark trace shows a lot of re-transmissions answered by a connection reset after which eventually the browser gives up: https://i.imgur.com/V2qDaJb.png
Do you have any idea what could this be causing?
Very slow DNS resolution over IPv4
While troubleshooting the issues above, I encountered another issue. Apparantly DNS resolution over IPv4 is 18 times slower than over IPv6:
D:\Downloads\BIND9.12.1.x64>dig -t MX google.com @185.187.240.11
; <<>> DiG 9.12.1 <<>> -t MX google.com @185.187.240.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22394
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11
<Removed for readability>
;; Query time: 1371 msec <----------- <----------- <-----------
;; SERVER: 185.187.240.11#53(185.187.240.11)
;; WHEN: Fri May 11 17:23:06 West-Europa (zomertijd) 2018
;; MSG SIZE rcvd: 367
D:\Downloads\BIND9.12.1.x64>dig -t MX google.com @2a00:1ca8:17:3c9::7384
; <<>> DiG 9.12.1 <<>> -t MX google.com @2a00:1ca8:17:3c9::7384
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49229
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11
<Removed for readability>
;; Query time: 76 msec <----------- <----------- <-----------
;; SERVER: 2a00:1ca8:17:3c9::7384#53(2a00:1ca8:17:3c9::7384)
;; WHEN: Fri May 11 17:23:27 West-Europa (zomertijd) 2018
;; MSG SIZE rcvd: 367
I have no experience with troubleshooting this particular issue. Do you have any tips on how to proceed?
Again, sorry for the wall of text...
Thank you very much in advance for the trouble to be taken.
Kind regards,
Freek
