RamSet
June 25, 2019, 5:16pm
6
This is because you setup your Pi-hole to work on the tun0 with it's parameters (gateway and all).
What i would recommend is running a pihole -r and your your eth0 interface with your LAN ip information (not your VPN ip).
At this point you miss configured Pi-hole as a whole and you isolated Pi-hole from the whole network.
PIHOLE_INTERFACE=tun0
IPV4_ADDRESS=10.8.0.1/24
[i] Default IPv4 gateway: 192.168.1.1
* Pinging 192.168.1.1...
[✗] Gateway did not respond.
[✓] IPv6 address(es) bound to the tun0 interface:
fe80::34fc:8c4f:9807:b9f0 does not match the IP found in /etc/pihole/setupVars.conf
The reason I've been hesitant to reconfigure entirely is because it's in a working state for VPN, and it was previously working on LAN before I added a new router (putting my existing modem/router in bridge mode). If it's configured only to work on tun0 then I don't know why it was previously working on LAN. The only concrete change to the network I know of is that the gateway changed from 192.168.0.1 to 192.168.1.1, which I updated on the Pi afaik. Do you know if there's any additional change I would need to make as a result? If not, I'll go ahead with the reconfigure.
RamSet
June 25, 2019, 5:44pm
8
A logical and working setup would be like this:
Router has 192.168.1.1 as it's LAN IP
OepnVPN server is pushing either 10.8.0.1 and/or 192.168.1.IPofPi-Hole to it's clients as the DNS server.
Hopefuly your IPTABLES are clean and they work.
This is pretty stable from a VPN standpoint of view and it's independent of the IP of Pi-hole (especially if it only uses 10.8.0.1 as the DNS).
I use it like this on 4 separate, standalone devices.
In case of a network shift, all i would have to do is to update the IP on Pi-hole and everything else would be seamless.
Maybe your clients are pointing to the old IP of Pi-hole as the DNS ?
What's the result of nslookup flurry.com on a client ?
I ran pihole -r to set the interface to eth0 and no dice.
Here's the new tricorder link: https://tricorder.pi-hole.net/h4xonsp91g
Result of your suggested query:
~ $ nslookup flurry.com 192.168.1.31
;; connection timed out; no servers could be reached
And here are the iptables rules (I believe the modification was part of setting up openvpn):
pi@raspberrypi:~ $ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
pi@raspberrypi:~ $ sudo iptables -t nat --list
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 10.8.0.0/24 anywhere
SNAT all -- 10.8.0.0/24 !10.8.0.0/24 to:10.8.0.1
I wonder if this is at all related? Clients not connecting, not blocking - #13 by RamSet
The solution was to nuke everything on the Pi, which I'm hoping to avoid. It really just feels like the router is blocking DNS traffic, but I can't verify it or figure out why/how.
Below one is a useful one.
pi@noads:~ $ nslookup -type=txt -class=chaos version.bind 10.0.0.2
Server: 10.0.0.2
Address: 10.0.0.2#53
version.bind text = "dnsmasq-pi-hole-2.80"
Or Quad9 public DNS 9.9.9.9:
pi@noads:~ $ nslookup -type=txt -class=chaos version.bind 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
version.bind text = "Q9-P-5.2"
Not all DNS server software will reply or they are blocked displaying version for security reasons.
And check for below or similar setting on your router:
countermeasure to an attack on your network . So in many cases, it's ac…
The 9.9.9.9 query resolves as you've written. The query to my Pi LAN IP returns just ;; connection timed out; no servers could be reached
I indeed made sure that dns rebind protection is not enabled.
Are you double natted? Make sure you check your forwarding rules
As in on the router check that firewall
I made sure to disable the gateway function on my modem/router.
I went back to the single modem/router setup for testing purposes, and I still have the same problem, so maybe it's a problem with the Pi that happened to coincide with changing my network configuration?
Do the same nslookup query on Pi-hole eg:
pi@noads:~ $ nslookup -type=txt -class=chaos version.bind $(hostname -I)
Server: 10.0.0.2
Address: 10.0.0.2#53
version.bind text = "dnsmasq-pi-hole-2.80"
If its replying, most likely its the router blocking.
If not, check if pihole-FTL is listening on all IP's 0.0.0.0:
pi@noads:~ $ sudo netstat -nltup | grep "Proto\|:53 "
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 2957/pihole-FTL
tcp6 0 0 :::53 :::* LISTEN 2957/pihole-FTL
udp 0 0 0.0.0.0:53 0.0.0.0:* 2957/pihole-FTL
udp6 0 0 :::53 :::* 2957/pihole-FTL
And if interface/IP configured correctly:
pi@noads:~ $ grep 'IPV[4,6]_ADDRESS\|PIHOLE_INTERFACE' /etc/pihole/setupVars.conf
PIHOLE_INTERFACE=eth0
IPV4_ADDRESS=10.0.0.2/24
IPV6_ADDRESS=
Your last two commands check out, but it still can't resolve names through its LAN IP:
pi@raspberrypi:~ $ nslookup -type=txt -class=chaos version.bind $(hostname -I)
;; connection timed out; no servers could be reached
pi@raspberrypi:~ $ sudo netstat -nltup | grep "Proto\|:53 "
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 26487/pihole-FTL
tcp6 0 0 :::53 :::* LISTEN 26487/pihole-FTL
udp 0 0 0.0.0.0:53 0.0.0.0:* 26487/pihole-FTL
udp6 0 0 :::53 :::* 26487/pihole-FTL
pi@raspberrypi:~ $ grep 'IPV[4,6]_ADDRESS\|PIHOLE_INTERFACE' /etc/pihole/setupVars.conf
PIHOLE_INTERFACE=eth0
IPV4_ADDRESS=192.168.1.31/24
IPV6_ADDRESS=
Whats output for below three?
pi@noads:~ $ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:68:35:17 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::2113:33ca:4a85:5fb/64 scope link
valid_lft forever preferred_lft forever
pi@noads:~ $ ip r
default via 10.0.0.1 dev eth0 src 10.0.0.2 metric 202
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 metric 202
pi@noads:~ $ sudo traceroute -n 8.8.8.8 | tail -1
9 8.8.8.8 22.983 ms 22.683 ms 22.703 ms
You can run last one without the "| tail -1" bit to see where route breaks.
And try flush iptables for diagnosing:
Below ones seems to do the trick:
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t nat -L -n -v
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
Check afterwards with:
pi@noads:~ $ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source …
EDIT: ow the upstream servers you configured:
pi@noads:~ $ grep PIHOLE_DNS_ /etc/pihole/setupVars.conf
PIHOLE_DNS_1=62.58.153.220#53
PIHOLE_DNS_2=62.58.48.30#53
Can you do a nslookup against them too to see if they respond ?
pi@raspberrypi:~ $ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:88:aa:fe brd ff:ff:ff:ff:ff:ff
inet 192.168.1.31/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd00:f81d:f9e:7c32:e441:7820:b86:b663/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 535421sec preferred_lft 401564sec
inet6 2607:fea8:71f:f29e:c6ad:9534:ea3e:5ef1/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 603345sec preferred_lft 171345sec
inet6 fe80::8e15:18c8:7020:fc1d/64 scope link
valid_lft forever preferred_lft forever
pi@raspberrypi:~ $ ip r
default via 192.168.1.1 dev eth0 src 192.168.1.31 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.31 metric 202
pi@raspberrypi:~ $ sudo traceroute -n 8.8.8.8 | tail -1
8 8.8.8.8 15.769 ms 108.170.226.217 15.281 ms 8.8.8.8 15.636 ms
pi@raspberrypi:~ $ grep PIHOLE_DNS_ /etc/pihole/setupVars.conf
PIHOLE_DNS_1=208.67.222.222
PIHOLE_DNS_2=208.67.220.220
pi@raspberrypi:~ $ nslookup 208.67.222.222
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
222.222.67.208.in-addr.arpa name = resolver1.opendns.com.
Authoritative answers can be found from:
pi@raspberrypi:~ $ nslookup 208.67.222.220
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
220.222.67.208.in-addr.arpa name = resolver3.opendns.com.
Authoritative answers can be found from:
You used nslookup the wrong way.
nslookup pi-hole.net 208.67.222.222
Above one will try to query the DNS server 208.67.222.222 to resolve the name pi-hole.net to an IP address.
Although you used nslookup the wrong way, it indicates pihole-FTL is working properly.pihole-FTL recevied the query to do a reverse lookup for 208.67.222.222,pihole-FTL forwarded the query to its upstream configured DNS server (208.67.222.222 or 208.67.220.220),
I suspect iptables not configured properly and blocking.
My Pi's iptables didn't have many rules in the first place, but I tried flushing them and rerunning nslookup -type=txt -class=chaos version.bind $(hostname -I) with the same result.
Just to be sure, do you get reply with below one on Pi-hole ?
nslookup pi.hole 192.168.1.31
And what about below one ?
nslookup pi.hole 127.0.0.1
EDIT: and could you post output for below one to check for rouge config files that hold settings that might mess things up ?
sudo grep -v '^#\|^$' -R /etc/dnsmasq.* | sort
pi@raspberrypi:~ $ nslookup pi.hole 192.168.1.31
;; connection timed out; no servers could be reached
pi@raspberrypi:~ $ nslookup pi.hole 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: pi.hole
Address: 192.168.1.31
pi@raspberrypi:~ $ sudo grep -v '^#\|^$' -R /etc/dnsmasq.* | sort
/etc/dnsmasq.conf:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.old:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.d/00-openvpn.conf:interface=tun0
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/black.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/gravity.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/local.list
/etc/dnsmasq.d/01-pihole.conf:cache-size=10000
/etc/dnsmasq.d/01-pihole.conf:dhcp-ignore-names=tag:wpad-ignore
/etc/dnsmasq.d/01-pihole.conf:dhcp-name-match=set:wpad-ignore,wpad
/etc/dnsmasq.d/01-pihole.conf:localise-queries
/etc/dnsmasq.d/01-pihole.conf:local-service
/etc/dnsmasq.d/01-pihole.conf:local-ttl=2
/etc/dnsmasq.d/01-pihole.conf:log-async
/etc/dnsmasq.d/01-pihole.conf:log-facility=/var/log/pihole.log
/etc/dnsmasq.d/01-pihole.conf:log-queries
/etc/dnsmasq.d/01-pihole.conf:no-resolv
/etc/dnsmasq.d/01-pihole.conf:server=208.67.220.220
/etc/dnsmasq.d/01-pihole.conf:server=208.67.222.222
Thats the culprit.
sudo mv /etc/dnsmasq.d/00-openvpn.conf ~
Restart:
sudo service pihole-FTL restart
And test again:
nslookup pi.hole 192.168.1.31
nslookup pi.hole 127.0.0.1
And from Windows client if above looks good:
nslookup pi.hole 192.168.1.31