Configuring VPNDirector to forward to Pi-hole DNS

[AMomchilov]

I committed the cardinal sin of updating my RT-AC68U's firmware (to 386.4) without backing up the configuration. (I do have a backup, but it's a few months old, and I'd rather just roll-forward with a fix than roll-back.)

I only noticed and learned about the VPN Director after seeing my Pi-hole's DNS stop working. According to this thread, the old configuration should have been migrated via some auto-generated VPN director rules. This doesn't seem to have happened for me.

My Pi-hole was set up on a free-teir Google Cloud VM using these instructions. The Pi-hole's DNS server is not exposed publicly, instead, my router connects to a VPN server on the Pi-hole, and accesses its DNS server privately.

My router's subnet is 10.0.0.0/16.
My Pi-hole's VPN server assigned the Pi-hole itself to 10.8.0.1, and my router to 10.8.0.2.

On my router, I had 10.8.0.1 configured as the sole DNS server:

Here is my VPN client page. The only thing I changed after the update was "Redirect Internet traffic through tunnel" from "No" to "VPN Director (policy rules)", which I figured would be necessary to use the routing rules that I would need. A crispier image is available here:

https://imgur.com/a/9VxcoLh

Interestingly, note that it says "Connected (Local: 10.8.0.2 - Public: unknown)". Is that "unknown" indicative of a root cause, or just another symptom of being unable to connect to 10.8.0.1? I've confirmed from my OpenVPN server's logs that the client is connecting and hand-shaking successfully.

I tried my hand at making my own VPN director rule. Here's what I currently have:

I tried my best from what I could pick up from the wiki and various forum threads, but I haven't really found any end-user documentation. From what I can tell, most of these things were written with network professionals in mind. My best guess so far is that:

• If a particular IP (or range of IPs) is set as "Local IP", then all egress traffic from those gets routed via the listed interface (e.g. the VPN tunnel).
• If a particular IP (or range of IPs) is set as "Remote IP", then attempts to connect *to* those IPs happens by first routing via the listed interface (e.g. the VPN tunnel).

So I figured I should list 10.8.0.1 as the Remote IP, so that any device on my network can connect to 10.8.0.1 by going over OVPN1.

Attempts to ping 10.8.0.1 from my computer (or directly from my router) just time out.

Clearly I'm doing something wrong, could somebody please point me in the right direction?

 

[eibgrad]

Given how you're using this VPN, you shouldn't need to use routing policy at all. You could just as well leave it set to NO. Just so long as the router knows how to find 10.8.0.1, which it should know if in fact it's connected to it over the VPN!

It can get a bit tricky depending on whether you use net30 or subnet for the topology on your OpenVPN server. When using the former (which iirc, is the default), the remote IP is not necessary available due to virtualization of the local and remote IPs. That's why I recommend subnet (and so does OpenVPN, they will be removing net30 sometime down the road). Now 10.8.0.1 should be pingable and otherwise reachable.

IOW, add the following to the OpenVPN server's config file.

topology subnet

 

[eibgrad]

P.S. Another option would be to simply push the local IP on which the pihole is running on the VPS, rather than relying on the tunnel IP network. Or else add that IP directly to the OpenVPN client's custom config field as a route directive.

route 10.129.13.5 255.255.255.255 vpn_gateway

Or more simply ...

route 10.129.13.5

Of course I have no idea what the actual IP is used on that VPS, but you get the point.

IOW, the topology now becomes irrelevant since you're never referencing the tunnel's IP network anyway.

 

[SomeWhereOverTheRainBow]

I committed the cardinal sin of updating my RT-AC68U's firmware (to 386.4) without backing up the configuration. (I do have a backup, but it's a few months old, and I'd rather just roll-forward with a fix than roll-back.)

I only noticed and learned about the VPN Director after seeing my Pi-hole's DNS stop working. According to this thread, the old configuration should have been migrated via some auto-generated VPN director rules. This doesn't seem to have happened for me.

My Pi-hole was set up on a free-teir Google Cloud VM using these instructions. The Pi-hole's DNS server is not exposed publicly, instead, my router connects to a VPN server on the Pi-hole, and accesses its DNS server privately.

My router's subnet is 10.0.0.0/16.
My Pi-hole's VPN server assigned the Pi-hole itself to 10.8.0.1, and my router to 10.8.0.2.

On my router, I had 10.8.0.1 configured as the sole DNS server:

View attachment 38649

Here is my VPN client page. The only thing I changed after the update was "Redirect Internet traffic through tunnel" from "No" to "VPN Director (policy rules)", which I figured would be necessary to use the routing rules that I would need. A crispier image is available here:

https://imgur.com/a/9VxcoLh

View attachment 38650

Interestingly, note that it says "Connected (Local: 10.8.0.2 - Public: unknown)". Is that "unknown" indicative of a root cause, or just another symptom of being unable to connect to 10.8.0.1? I've confirmed from my OpenVPN server's logs that the client is connecting and hand-shaking successfully.

I tried my hand at making my own VPN director rule. Here's what I currently have:

View attachment 38651

I tried my best from what I could pick up from the wiki and various forum threads, but I haven't really found any end-user documentation. From what I can tell, most of these things were written with network professionals in mind. My best guess so far is that:

• If a particular IP (or range of IPs) is set as "Local IP", then all egress traffic from those gets routed via the listed interface (e.g. the VPN tunnel).
• If a particular IP (or range of IPs) is set as "Remote IP", then attempts to connect *to* those IPs happens by first routing via the listed interface (e.g. the VPN tunnel).

So I figured I should list 10.8.0.1 as the Remote IP, so that any device on my network can connect to 10.8.0.1 by going over OVPN1.

Attempts to ping 10.8.0.1 from my computer (or directly from my router) just time out.

Clearly I'm doing something wrong, could somebody please point me in the right direction?

I would check out wireguard manager on amtm, and turn your vps into using wireguard instead. Alot more simple to setup.

 

[AMomchilov]

Hey guys, thanks for your responses. I'm working through them, although almost all the concepts and acronyms here are flying right over my head. I'm reading up more, and I'll let you know when I have question.

Given how you're using this VPN, you shouldn't need to use routing policy at all. You could just as well leave it set to NO. Just so long as the router knows how to find 10.8.0.1, which it should know if in fact it's connected to it over the VPN!

I was confused by this. Clearly my Router knows enough about how to route these packets that it can start+handshake an OpenVPN session, but I don't understand why it won't route other traffic (ICMP, DNS requests) sent to 10.8.0.1 from it, or other machines on the network.

Could you explain what might be going on there?

It can get a bit tricky depending on whether you use net30 or subnet for the topology on your OpenVPN server. When using the former (which iirc, is the default), the remote IP is not necessary available due to virtualization of the local and remote IPs. That's why I recommend subnet (and so does OpenVPN, they will be removing net30 sometime down the road). Now 10.8.0.1 should be pingable and otherwise reachable.

IOW, add the following to the OpenVPN server's config file.

topology subnet

Looks like topology subnet is already set in my server's /etc/openvpn/server.conf.

P.S. Another option would be to simply push the local IP on which the pihole is running on the VPS, rather than relying on the tunnel IP network.

Could you please elaborate by what exactly you mean by "push" in this context?

Or else add that IP directly to the OpenVPN client's custom config field as a route directive.

Here's what I understood from the rest of that message, can you correct me if I'm wrong? You're suggesting that I can configure the VPN client on my router with route 10.129.13.5 255.255.255.255 vpn_gateway (assuming 10.129.13.5 is my Google cloud VM's public IP), which would define a new route that says that if the destination address is 10.129.13.5 (and only that one, hence the 255.255.255.255 mask), it'll be routed via the OpenVPN tunnel.

Then, I'm inferring that I could set my Router's DNS to 10.129.13.5, and that'll automatically route to my cloud VM, without needing to specifically rely on 10.8.0.1. Is that correct?


Having said all that, do you have any suspition as to why my DNS setup would have stopped working with this update? What changed?

Thanks for your help, and I appreciate your patience!

 

[eibgrad]

I was confused by this. Clearly my Router knows enough about how to route these packets that it can start+handshake an OpenVPN session, but I don't understand why it won't route other traffic (ICMP, DNS requests) sent to 10.8.0.1 from it, or other machines on the network.

Could you explain what might be going on there?

Did you NAT the tunnel? Also, is the pihole on that VM actually bound to 10.8.0.1? I don't use either Google Cloud or pihole, but if it's like any other VM and service being offered, the pihole is either configured for *all* network interfaces, or only a specific network interface, such as the public IP, or perhaps the local private network of the VM. In my experience, VMs typically are bound to a local private network, NOT just the public IP.

Looks like topology subnet is already set in my server's /etc/openvpn/server.conf.

Could you please elaborate by what exactly you mean by "push" in this context?

Being subnet is good. That should result in the router's routing table for the OpenVPN client having a route for that subnet (i.e., 10.8.0.0/24) that points to the VPN. You can confirm that by dumping the routing tables (I'm assuming OpenVPN client #1 below).

ip route show table main
ip route show table ovpnc1

As I suggested above, it's highly likely your VM is bound to a local private IP network, and NOT just a public IP (but you'd have to verify this using ifconfig). If that's the case, and assuming the pihole is bound to that network, then the pihole should be accessible by that private IP. But in order for it to be reachable by that IP, the OpenVPN server either has to push that IP to the OpenVPN client via the following directive in its config file ...

push "route 10.129.13.5"

Or the OpenVPN client needs to add this to its own configuration file.

route 10.129.13.5

IOW, presently your trying to use the tunnel's IP network to gain access to the pihole (10.8.0.1). That may or may not work depending on whether the pihole is even bound to that IP. But in most cases, it's better to bind services to the local, private IP on which the server is running. In fact, if the remote network of the VM was part of a larger private network, and the service being offered was on some other device, you'd *have* to use that private network. But sometimes we get lazy and assume the server's IP on the tunnel will suffice. Maybe, maybe not.

Here's what I understood from the rest of that message, can you correct me if I'm wrong? You're suggesting that I can configure the VPN client on my router with route 10.129.13.5 255.255.255.255 vpn_gateway (assuming 10.129.13.5 is my Google cloud VM's public IP), which would define a new route that says that if the destination address is 10.129.13.5 (and only that one, hence the 255.255.255.255 mask), it'll be routed via the OpenVPN tunnel.

I'm assuming10.129.13.5 is the local private IP on which the VM is running, NOT it's public IP. The public IP will be routed out the WAN of the router, but since (according to you) the pihole is NOT bound to its public IP (which makes me think it's also NOT bound to 10.8.0.1), this won't work.

Having said all that, do you have any suspition as to why my DNS setup would have stopped working with this update? What changed?

No idea. Let's get the pihole working first.

 

[AMomchilov]

Reading your messages now, and I notice that my vpn client magically reconnected itself, (Connected (Local: 10.8.0.2 - Public: <my pi's external IP>) and I can connect to it.

I literally didn't change anything, Idk what might have happened.

I'll use this opportunity to learn more about how the networking is set up here. We'll see if it cuts out again. Stay tuned I guess lol

 

[AMomchilov]

Soooo it looks like I can ping my VM, make DNS queries against it, access its web interface and all that, but only if I don't use it as a DNS server on my router (e.g. using my ISP's DNS instead with "Connect to DNS Server automatically: yes").

When this works, I have:

• Accept DNS Configuration: strict
• Redirect Internet traffic through tunnel: VPN Director (policy rules)
  • With a single rule that has Local IP: 10.8.0.1, Remote IP: 10.8.0.1, Iface: OVPN1

The moment I set that to "Connect to DNS Server automatically: no", and start using my 10.8.0.1 as a DNS server, I lose ping/DNS/http response.

---

To answer your other questions:

Did you NAT the tunnel?

Judging by the contents of my /etc/iptables/rules.v4, I think so:

# Generated by iptables-save v1.6.0 on Sat Nov 14 15:56:41 2020
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE
-A POSTROUTING -s 10.9.0.0/24 -o ens4 -j MASQUERADE
COMMIT
# Completed on Sat Nov 14 15:56:41 2020
# Generated by iptables-save v1.6.0 on Sat Nov 14 15:56:41 2020
*filter
:INPUT ACCEPT [619:2273272]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [623:119031]
COMMIT
# Completed on Sat Nov 14 15:56:41 2020

I don't use either Google Cloud or pihole, but if it's like any other VM and service being offered, the pihole is either configured for *all* network interfaces, or only a specific network interface, such as the public IP, or perhaps the local private network of the VM. In my experience, VMs typically are bound to a local private network, NOT just the public IP.

I'm not sure how exactly it's implemented, but it's configured to listen locally with pihole -a -i local. Here's what the docs say about that:

$ pihole -a -i --help
Usage: pihole -a -i [interface]
Example: 'pihole -a -i local'
Specify dnsmasq's network interface listening behavior

Interfaces:
  local               Only respond to queries from devices that
                      are at most one hop away (local devices)
  single              Respond only on interface eth0
  bind                Bind only on interface eth0
  all                 Listen on all interfaces, permit all origins

I'm don't know much about dnsmasq, so I don't know how exactly this binding works. Looking at sudo netstat -tulpn, it looks like openvpn and pihole are listening on all addresses for the most part:

$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name  
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      3405/pihole-FTL   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2088/lighttpd     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      3405/pihole-FTL   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      925/sshd          
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      579/openvpn       
tcp6       0      0 ::1:4711                :::*                    LISTEN      3405/pihole-FTL   
tcp6       0      0 :::80                   :::*                    LISTEN      2088/lighttpd     
tcp6       0      0 :::53                   :::*                    LISTEN      3405/pihole-FTL   
tcp6       0      0 :::22                   :::*                    LISTEN      925/sshd          
udp        0      0 0.0.0.0:1194            0.0.0.0:*                           580/openvpn       
udp        0      0 0.0.0.0:53              0.0.0.0:*                           3405/pihole-FTL   
udp        0      0 0.0.0.0:68              0.0.0.0:*                           656/dhclient      
udp        0      0 10.9.0.1:123            0.0.0.0:*                           770/ntpd          
udp        0      0 10.8.0.1:123            0.0.0.0:*                           770/ntpd          
udp        0      0 10.128.0.2:123          0.0.0.0:*                           770/ntpd          
udp        0      0 127.0.0.1:123           0.0.0.0:*                           770/ntpd          
udp        0      0 0.0.0.0:123             0.0.0.0:*                           770/ntpd          
udp6       0      0 :::53                   :::*                                3405/pihole-FTL   
udp6       0      0 fe80::7040:9ea5:f4f:123 :::*                                770/ntpd          
udp6       0      0 fe80::5dc3:a5b7:621:123 :::*                                770/ntpd          
udp6       0      0 fe80::4001:aff:fe80:123 :::*                                770/ntpd          
udp6       0      0 ::1:123                 :::*                                770/ntpd          
udp6       0      0 :::123                  :::*                                770/ntpd

That should result in the router's routing table for the OpenVPN client having a route for that subnet (i.e., 10.8.0.0/24) that points to the VPN. You can confirm that by dumping the routing tables (I'm assuming OpenVPN client #1 below).

I've redacted my home IP with Xs, and my ISPs DNS servers with Ys

# ip route show table main
xxx.xxx.xxx.x65 dev vlan2  proto kernel  scope link
yyy.yyy.yyy.yy5 via xxx.xxx.xxx.x65 dev vlan2  metric 1
yyy.yyy.yyy.yy2 via xxx.xxx.xxx.x65 dev vlan2  metric 1
xxx.xxx.xxx.x64/27 dev vlan2  proto kernel  scope link  src xxx.xxx.xxx.x76
10.8.0.0/24 dev tun11  proto kernel  scope link  src 10.8.0.2
10.0.0.0/16 dev br0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via xxx.xxx.xxx.x65 dev vlan2

# ip route show table ovpnc1
xxx.xxx.xxx.x65 dev vlan2  proto kernel  scope link
yyy.yyy.yyy.yy5 via xxx.xxx.xxx.x65 dev vlan2  metric 1
yyy.yyy.yyy.yy2 via xxx.xxx.xxx.x65 dev vlan2  metric 1
xxx.xxx.xxx.x64/27 dev vlan2  proto kernel  scope link  src xxx.xxx.xxx.x76
10.8.0.0/24 dev tun11  proto kernel  scope link  src 10.8.0.2
10.0.0.0/16 dev br0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via xxx.xxx.xxx.x65 dev vlan2

Here are those same routing tables after I turn off my ISP's DNS and switch to using 10.8.0.1 (and lose access to the vm over icmp/dns/http at the same time)

# ip route show table main
xxx.xxx.xxx.x65 dev vlan2  proto kernel  scope link
10.8.0.1 via xxx.xxx.xxx.x65 dev vlan2  metric 1
xxx.xxx.xxx.x64/27 dev vlan2  proto kernel  scope link  src 198.200.108.76
10.8.0.0/24 dev tun11  proto kernel  scope link  src 10.8.0.2
10.0.0.0/16 dev br0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via xxx.xxx.xxx.x65 dev vlan2
# ip route show table ovpnc1
10.8.0.1 via xxx.xxx.xxx.x65 dev vlan2  metric 1
xxx.xxx.xxx.x65 dev vlan2  proto kernel  scope link
xxx.xxx.xxx.x64/27 dev vlan2  proto kernel  scope link  src xxx.xxx.xxx.x76
10.8.0.0/24 dev tun11  proto kernel  scope link  src 10.8.0.2
10.0.0.0/16 dev br0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via xxx.xxx.xxx.x65 dev vlan2

 

[eibgrad]

When I referred to NAT'ing the tunnel, I meant from the router's perspective, NOT the VM. But when I thought more about it, I realized it's irrelevant anyway, since it's only the router that requires access to the pihole. NAT would only be necessary if clients on the LAN required direct access to the pihole.

Most everything else looks fine from those dumps.

As far as "Connect to DNS Server automatically" being set to No, the problem is you've created a chicken and egg problem. You can't connect to the VPN based on a DNS server that's only accessible when the VPN is connected! You need a public DNS server at least to get the router bootstrapped. Not unless you know everything necessary to boot the system does NOT rely on domain names, including the VPN.

Setting "Connect to DNS Server automatically" to Yes, while using Strict on the VPN *should* work, provided you are pushing that DNS server to the client in the OpenVPN server config file.

push "dhcp-option DNS 10.8.0.1"

However, I've discovered a bug in 386.4 where Strict doesn't work as expected. When the VPN connects, it's supposed to prepend the VPN's DNS server to the nameservers file (/tmp/resolv.dnsmasq).

10.8.0.1
<isp-dns-server>

But it doesn't. It appends it ...

<isp-dns-server>
10.8.0.1

... meaning the router will still default to the ISP's DNS server(s).

All things considered, I think your best option is to set "Connect to DNS Server automatically" to No, but specify 10.8.0.1 and 1.1.1.1, in that order. When the router boots, 10.8.0.1 won't be accessible, but 1.1.1.1 will. Once the OpenVPN client gets connected, and has Strict specified, it will append 10.8.0.1 to the nameservers file (which as I said, is a bug), but more importantly, it will add the strict-order directive to DNSMasq. So it will end up looking as follows.

10.8.0.1
1.1.1.1
10.8.0.1

Once DNSMasq is restarted by the OpenVPN client, you should have all your DNS sent to the pihole. And this does NOT require policy rules either. The only route to 10.8.0.1 is via the VPN, so adding policy rules is redundant.

 

[AMomchilov]

Hey again!

When I referred to NAT'ing the tunnel, I meant from the router's perspective, NOT the VM.

Ah yes, I don't think I'm doing that.

NAT would only be necessary if clients on the LAN required direct access to the pihole.

Actually, that would be nice to have back again. Sshing directly from my computer rather than going through the Google cloud console web UI was quite convenient. Would would I need to do to get that going?

Setting "Connect to DNS Server automatically" to Yes, while using Strict on the VPN *should* work, provided you are pushing that DNS server to the client in the OpenVPN server config file.

Indeed, my VM's OpenVPN config file specifies this.

But it doesn't. It appends it ...

Ah yes, I just confirmed it. 10.8.0.1 ends up at the end.

So in that case, it looks like the VPN works, but the DNS server is at the end of the list, so it never really gets used. Is that right?

As far as "Connect to DNS Server automatically" being set to No, the problem is you've created a chicken and egg problem. You can't connect to the VPN based on a DNS server that's only accessible when the VPN is connected! You need a public DNS server at least to get the router bootstrapped. Not unless you know everything necessary to boot the system does NOT rely on domain names, including the VPN.

That didn't seem to be a problem before. My OpenVPN client is configured to access the external IP of the cloud VM explicitly (not using a DNS name), so it doesn't need boot-strapping. As for the other components of the system (ddns, ntp, etc.)... they didn't seem to have any issue. Perhaps they fail initially, but retries recover automatically after the OpenVPN client connects and DNS comes up.

All things considered, I think your best option is to set "Connect to DNS Server automatically" to No, but specify 10.8.0.1 and 1.1.1.1, in that order. When the router boots, 10.8.0.1 won't be accessible, but 1.1.1.1 will.

Just to confirm: when multiple DNS servers are specified, are the latter ones only accessed if the first one couldn't be reached at all, right? Or are they queried everytime one of the earlier servers doesn't find a hit for a query? If it's the latter case, that would defeat the purpose of the Pi-hole

Thanks so much for your help, btw. Reading your answers has sent my down many rabbit holes, and I'm learning a ton about networking in the process!

 

[eibgrad]

Actually, that would be nice to have back again. Sshing directly from my computer rather than going through the Google cloud console web UI was quite convenient. Would would I need to do to get that going?

Just enable NAT on the OpenVPN client. You should be able to access the pihole's GUI @ 10.8.0.1 from any LAN client.

So in that case, it looks like the VPN works, but the DNS server is at the end of the list, so it never really gets used. Is that right?

Correct. Because you specified Strict, the router inserts the strict-order directive into the DNSMasq config file (/tmp/etc/dnsmasq.conf), then restarts DNSMasq. Now it will access the DNS servers in the order specified. But it's *supposed* to place the DNS server from the VPN at the top, NOT the bottom! So it ends up continuing to use the ISP's DNS server(s).

That didn't seem to be a problem before. My OpenVPN client is configured to access the external IP of the cloud VM explicitly (not using a DNS name), so it doesn't need boot-strapping. As for the other components of the system (ddns, ntp, etc.)... they didn't seem to have any issue. Perhaps they fail initially, but retries recover automatically after the OpenVPN client connects and DNS comes up.

It's still NOT a good idea. Let's suppose the time service is using domain names. If the time can't be set correctly, then the certs on the OpenVPN client and server can't be verified! They'll fail the start/expiry date checks! You're just asking for trouble (if not now, down the road) if you bootstrap the system based on a private IP. But that's up to you.

Just to confirm: when multiple DNS servers are specified, are the latter ones only accessed if the first one couldn't be reached at all, right? Or are they queried everytime one of the earlier servers doesn't find a hit for a query? If it's the latter case, that would defeat the purpose of the Pi-hole

Thanks so much for your help, btw. Reading your answers has sent my down many rabbit holes, and I'm learning a ton about networking in the process!

By default, DNSMasq will initially query ALL available DNS servers and use the one that responds first. It will mark that server as "preferred". It will continue to use it for some period of time (X amount of time and/or X number of queries) and then use ALL the DNS servers again to determine which responds fastest. That DNS server now becomes preferred until the servers get tested again. And on and on.

When the router adds the strict-order directive, that changes. Now DNSMasq accesses the servers in the order specified in /tmp/resolv.dnsmasq. And as long as the first server responds, it continues to use that server indefinitely. If it fails, it moves on to the next and sticks with it indefinitely, and so on. But if the use of Strict is placing 10.8.0.1 at the bottom of that list of nameservers, it's pointless.

 

[AMomchilov]

Just enable NAT on the OpenVPN client. You should be able to access the pihole's GUI @ 10.8.0.1 from any LAN client.

Hmmm I already have that on (you can see it on the screenshot of the OpenVPN client config page in my first post). I can access the services on the VM, but only until I set it as my router's DNS server, then I lose access, like I described in my earlier post. What could be causing that?

If the time can't be set correctly, then the certs on the OpenVPN client and server can't be verified! They'll fail the start/expiry date checks!

True! I'll fix that up.

When the router adds the strict-order directive, that changes. Now DNSMasq accesses the servers in the order specified in /tmp/resolv.dnsmasq. And as long as the first server responds, it continues to use that server indefinitely. If it fails, it moves on to the next and sticks with it indefinitely, and so on.

Ah yes, this sounds ideal (apart from the bug, which I'm sure will get fixed). If it tried both and used the faster response, it would probably pick 1.1.1.1 almost every time, defeating the DNS-based ad blocking feature of the Pi-hole, which is the whole point.

 

[AMomchilov]

I had a hunch, so I just set both of my router's DNS servers to blank so that my /tmp/resolv.dnsmasq

# cat /tmp/resolv.dnsmasq
server=10.8.0.1

Now my router uses this DNS server exclusively, successfully, will still allowing my LAN to access 10.8.0.1! When the DNS server ordering bug is fixed, I can throw in 1.1.1.1 as a backup.

I compared what my routing tables look like before and after, and it looks like the only difference was that this entry got removed, I suppose it must be what was preventing the rest of the LAN from connecting to 10.8.0.1

10.8.0.1 via xxx.xxx.xxx.xx5 dev vlan2 metric 1

 

[eibgrad]

I had a hunch, so I just set both of my router's DNS servers to blank so that my /tmp/resolv.dnsmasq

# cat /tmp/resolv.dnsmasq
server=10.8.0.1

So what you're telling me is, you have NO DNS capabilities until the OpenVPN client is connected?

The reason I suggested adding 10.8.0.1 and 1.1.1.1, in that order, was based on the assumption 10.8.0.1 would NOT be available until the OpenVPN client got connected, and until then, at least 1.1.1.1 would work. Once the OpenVPN client did get connected, and DNSMasq was restarted, now 10.8.0.1 would take over.

Now my router uses this DNS server exclusively, successfully, will still allowing my LAN to access 10.8.0.1! When the DNS server ordering bug is fixed, I can throw in 1.1.1.1 as a backup.

If you can get the router to boot and work normally w/ only 10.8.0.1 and no other public DNS server(s), why throw in 1.1.1.1, or any other public DNS servers? As I said, I suggested 1.1.1.1 under the belief it would be necessary to bootstrap the system. But if that's NOT the case for some reason (which baffles me), it's irrelevant.

I compared what my routing tables look like before and after, and it looks like the only difference was that this entry got removed, I suppose it must be what was preventing the rest of the LAN from connecting to 10.8.0.1

10.8.0.1 via <public-ip-redacted> dev vlan2 metric 1

Now I'm really confused. Why would the private IP of 10.8.0.1 on the remote end of the tunnel be bound to the WAN (i.e., vlan2)?!!! That makes no sense.

There's something here about how you have this configured that it NOT coming across in your descriptions so far. Something else about this is different than a normal OpenVPN client configuration, and I can't figure out what that would be. Again, 10.8.0.0/24 is bound to the *tunnel*! Assuming that's OpenVPN client #1, that should be tun11, NOT vlan2. Please explain.

P.S. 10.8.0.1, being a private IP, isn't even routable over the internet!

 

[AMomchilov]

So what you're telling me is, you have NO DNS capabilities until the OpenVPN client is connected?

Yep :/

The reason I suggested adding 10.8.0.1 and 1.1.1.1, in that order, was based on the assumption 10.8.0.1 would NOT be available until the OpenVPN client got connected, and until then, at least 1.1.1.1 would work. Once the OpenVPN client did get connected, and DNSMasq was restarted, now 10.8.0.1 would take over.

Yeah, I understood that, but given the ordering bug that exists with DNS strict mode, do I have any other way to make 10.8.0.1 be first *besides* doing what I did? (which was to remove every other DNS server, making it first as a result)

As I said, I suggested 1.1.1.1 under the belief it would be necessary to bootstrap the system. But if that's NOT the case for some reason (which baffles me), it's irrelevant.

It doesn't appear to be, but it is a little annoying in case there's ever a hiccup with the cloud VM. I'd like to have a backup eventually.

Now I'm really confused. Why would the private IP of 10.8.0.1 on the remote end of the tunnel be bound to the WAN (i.e., vlan2)?!!! That makes no sense.

This route was made automatically when I set `DNS Server 1: 10.8.0.1` on the router. I don't understand how to read these routing tables yet, still reading up on it.

There's something here about how you have this configured that it NOT coming across in your descriptions so far. Something else about this is different than a normal OpenVPN client configuration, and I can't figure out what that would be. Again, 10.8.0.0/24 is bound to the *tunnel*! Assuming that's OpenVPN client #1, that should be tun11, NOT vlan2. Please explain.

I bet, but I don't know what it would be. Is there anything I can post to provide more context, like the VPN server/client configs or something?

I don't think I did much beyond what's described in the instructions I followed.

P.S. 10.8.0.1, being a private IP, isn't even routable over the internet!

Yes, I believe that's intentional, since it's only meant to be accessed through the VPN. But I get your point, that `10.8.0.1 via xxx.xxx.xxx.xx5 dev vlan2 metric 1` rule was whack, lol

 

[eibgrad]

This route was made automatically when I set `DNS Server 1: 10.8.0.1` on the router. I don't understand how to read these routing tables yet, still reading up on it.

Now that I think about it, I seem to recall a recent post by @RMerlin in which he said ASUS is now binding the ISP's DNS servers (or those you use to override it) to the WAN for some reason. If I can find it, I'll post it.

So while you could possibly get away w/ specifying 10.8.0.1 on the WAN prior to 386.4, that's NOT the case anymore. Those DNS servers *must* be reachable over the WAN, even if they are bound to the VPN (or anywhere else) behind that WAN. So at least as far as that part of the installation instructions, it's no longer applicable and will actually fail.

Anyway, I suppose if specifying NO DNS servers on the WAN works as far as bootstrapping the router and VPN goes, and 10.8.0.1 eventually does become available when DNS is required, that'll work. But it does seem rather strange. Still seems strange that you can get past the cert start and expiry date checks though. Then again, I don't know what PiVPN is doing in this regard. It works just so long as nothing in the system needs DNS until the OpenVPN client gets connected. Personally, I don't find that a strategy or assumption I'm willing to bank on always being true.