PiHole via OpenVpn on a Digital Ocean droplet - dig works, browser does not

Help
1

Please follow the below template, it will help us to help you!

Expected Behaviour:

Browse to macworld.com and the webpage should come up

Actual Behaviour:

Time out, nothing loads

Debug Token:

h7hgbyint6

I have setup PiHole & OpenVPn following the instructions at Redirecting... on a Digital Ocean droplet (Debian 9.7 x64 - tried both 1GB and 2GB of RAM)

OpenVPN is connecting and setting up correctly from what I can see

On my Macbook Pro I can run "dig macworld.com" and it shows that 10.8.0.1 is answering my DNS query and gives me the IP addresses, but if I try going there with my browser (Safari or Firefox) I get an eventual time out, tailing the pihole.log it is like I see no traffic from the web browser.

If I "dig doubleclick.net", and IP address of 0.0.0.0 is returned by the PiHole.

With wireshark I can see a pile of traffic going to the OpenVPN server and the DNS queries are being routed there, but web browsing, mail, iMessage, etc all stop working.

I have found that the only webpage I can open is the PiHole Admin console when connected to the VPN/PiHole Server.

I can see that the DNS is getting set correctly from the OpenVPN server:

goldenrod/2xx.xxx.xxx.73:12336 SENT CONTROL [goldenrod]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.8.0.1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.3 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)

My gut feel here is that something is off in the iptables rules from Redirecting... as the IPv4 rules are created, but in their listing, there are a number of rules with the 10.8.0.0/24 source that I do not get created when running the same statements, the listing I have is closer to the IPv6.

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere
2    ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
3    ACCEPT     all  --  anywhere             anywhere
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
5    ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
6    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
7    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
8    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:openvpn
9    ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
10   REJECT     udp  --  anywhere             anywhere             udp dpt:80 reject-with icmp-port-unreachable
11   REJECT     tcp  --  anywhere             anywhere             tcp dpt:https reject-with tcp-reset
12   REJECT     udp  --  anywhere             anywhere             udp dpt:443 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
2

Since you can do a manual dig, the firewall is likely not the issue.

Double check that your DNS servers are actually set correctly on the device.

Are you reaching it via http://pi.hole/admin? If so, then that means that it is using Pi-hole for DNS and all other domains should be using Pi-hole. Make sure the only DNS server you are using is Pi-hole.

3

From the OpenVPN connection log:

6/20/2019, 8:22:42 AM SetupClient: transmitting tun setup list to /var/run/ovpnagent.sock
{
	"config" : 
	{
		"iface_name" : "",
		"layer" : "OSI_LAYER_3",
		"tun_prefix" : false
	},
	"tun" : 
	{
		"adapter_domain_suffix" : "",
		"block_ipv6" : true,
		"dns_servers" : 
		[
			{
				"address" : "10.8.0.1",
				"ipv6" : false
			}
		],
		"layer" : 3,
		"mtu" : 1500,
		"remote_address" : 
		{
			"address" : "157.xxx.xxx.xxx",
			"ipv6" : false
		},
		"reroute_gw" : 
		{
			"flags" : 307,
			"ipv4" : true,
			"ipv6" : false
		},
		"route_metric_default" : -1,
		"session_name" : "pihole.xxxxxxxxxx.xxx",
		"tunnel_address_index_ipv4" : 0,
		"tunnel_address_index_ipv6" : -1,
		"tunnel_addresses" : 
		[
			{
				"address" : "10.8.0.2",
				"gateway" : "10.8.0.1",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			}
		]
	}
}

Some dig requests after connection:

[~ 08:26:20] $ dig pi.hole

; <<>> DiG 9.10.6 <<>> pi.hole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29482
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi.hole.			IN	A

;; ANSWER SECTION:
pi.hole.		2	IN	A	10.8.0.1

;; Query time: 77 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Thu Jun 20 08:28:26 MDT 2019
;; MSG SIZE  rcvd: 52


[~ 08:28:26] $ dig google.com

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32300
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		137	IN	A	172.217.9.238

;; Query time: 68 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Thu Jun 20 08:28:37 MDT 2019
;; MSG SIZE  rcvd: 55

ssh from the command line to my droplet by configured DNS (A name record) works.

Originally I omitted the iptables -P INPUT DROP item so I could connect directly to the web server via the defined DNS that I have configured, both that and http://pi.hole/admin worked while connected to the VPN.

I installed telnet, and without the VPN:

[~ 10:00:35] $ telnet -d google.com 80
Trying 216.58.193.78...
Connected to google.com.
Escape character is '^]'.
^C
Connection closed by foreign host.

With the VPN active:

[~ 10:00:46] $ telnet -d google.com 80
Trying 172.217.10.142...
telnet: connect to address 172.217.10.142: Operation timed out
Trying 2607:f8b0:4006:801::200e...
telnet: connect to address 2607:f8b0:4006:801::200e: Network is unreachable
telnet: Unable to connect to remote host

So far this is what I have determined:

  • ping - works
  • dig - works
  • ssh - works
  • telnet (port 80) - does not work
  • http/https - does not work
  • mail - does not work
  • iMessage - does not work
  • Keybase - does not work

It is very odd.

4

After disabling the PiHole, but still running the OpenVPN connection, the symptoms are the same. I did some digging and some one had suggested the command:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

It made no difference, in some more digging I found references to the /etc/syscntl.conf file an uncommenting the net.ipv4.ip_forward=1 line.

Tried both separately and together, no change in the symptoms with either or both.

Traceroute seems to die at the pihole box:

[~ 13:27:45] $ traceroute google.com
traceroute to google.com (172.217.9.238), 64 hops max, 52 byte packets
 1  pihole (10.8.0.1)  65.620 ms  65.257 ms  65.497 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *

I also found these on an OpenVPN question about iptables:

iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

They made no difference.

5

I'm not familiar enough with VPN internals to help further, but @RamSet may be able to help.

6

See if this one helps:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to LOCAL.IP.OF.DROPLET

7

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

9

Thanks RamSet, that did the trick.

I also found what looks like a "default" POSTROUTING the persists on the droplet:

Chain POSTROUTING (policy ACCEPT 38 packets, 2633 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        9   576 SNAT       all  --  *      *       10.8.0.0/24         !10.8.0.0/24          to:10.8.0.1

This was also blocking the traffic, once removed it all started working.

Thanks again.

1 Like