Cant access web interface over vpn (SOLVED)

Expected Behaviour:

When connecting to a VPN with pihole installed I should be able to access my NAS, local server and other web interfaces.

Actual Behaviour:

I'm getting no connection to the device on the network I'm vpn'd into. Even when I disable ad blocking it doesn't work. The only way to get it to work it change the DNS of the router to a normal google dns or similar..

Debug Token:

smas94pgpd

What is the output of iptables -L -n -v -t nat on your pihole ?

Chain PREROUTING (policy ACCEPT 107K packets, 16M bytes)
pkts bytes target prot opt in out source destination

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

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

Chain POSTROUTING (policy ACCEPT 12319 packets, 803K bytes)
pkts bytes target prot opt in out source destination

I'm not very familiar with IPTables, forewarning

this shows that there is no masquerading performed from your VPN server into your local network.

You need to have a rule that masks your VPN ip into a local IP so that the packets know where to return.

run an ifconfig to find out your interfaces.

default one for vpn is tun0

this should help you:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

where eth0 is your network interface, if different, change to what you have (from the output of ifconfig)

make sure

net.ipv4.ip_forward=1

is un-commented in /etc/sysctl.conf

More info:

Is this true even if I run my vpn on a different client?

I think I may be misunderstanding this. I ran the iptables and I believe I'm getting the same results

Chain PREROUTING (policy ACCEPT 2487 packets, 342K bytes)
pkts bytes target prot opt in out source destination

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

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

Chain POSTROUTING (policy ACCEPT 820 packets, 51882 bytes)
pkts bytes target prot opt in out source destination

A client get's it's IP assigned from the VPN server.
The VPN server runs as a dedicated DHCP server for any client that connects to it.

A default setting (with openVPN) is to asing an IP from the 10.8. range.

The VPN server via iptables, performs (or should) a masquerade (internally) where it masks all the packets that go outside the realm of the VPN server, into packets that are masked with the LAN facing Ip of the server.

In order for the communication to go back and forth.

If the masking is not performed, let's say your client that has the IP assigned by the VPN server, upon connection of 10.8.0.2 sends out a query into the network originating from that IP (that's nowhere else defined in your LAN, except in the VPN server), never receives a response packet because the LAN is defined on a diferent range of private IPS. and i will never work without the masquerade.

The receiving end will see a packet originating from 10.8.0.2 and it will try to send a response packet back to that IP but because the routing within the LAN is on a different class of IPS, it will never make it back.

The local router does not know where to send it since it does not know what 10.8.0.2 is (since it's not part of it's routing table).

All your clients (connecting to the VPN server) are funneled and pushed into the network with the LAN IP of the VPN server.

I think your issue there is a conflicting/bad VPN configuration setup..

Follow these guides and you should be up and running in no time:

https://github.com/pi-hole/pi-hole/wiki/Pi-hole---OpenVPN-server

This is possibly where I'm running into issues. I am using a commercial router with VPN built in. It assigns an IP address for each user that has the same network prefix. If I remove the pihole IP address from the DNS servers on the router I have no issue at all .

How does your Settings/DNS look like on the pi-hole interface?

Enable it on Listen on all Interfaces, permit all origins.

See if that fixes your DNS issue.

Make sure you don't have port 53 open to the public (outside your internal network).

That can turn really bad really quick :slight_smile:

I changed that setting. It was either that was the fix or the different network I was on. Thanks!

1 Like

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