@ITV Hi Will, if I understand you correctly, you are asking if a remote client machine which is (Open)VPN'd into your router can be forced to use a specific local DNS server?

Should be easiest to simply spec the DNS servers for all local clients, whether VPN'd or not?  You should be able to do that by defining manually the DNS servers to be used for your WAN interface (Settings->Wired Networks->Internet->WAN(x)->IPv4->Advanced).  Those DNS IPs should ripple down to the inbound VPN clients as I don't think split-tunnel is supported, so there'd be no point using the DNS addresses at the client site.

  @ITV 

Just an additional note: Full Tunnel is not currently supported by OpenVPN.

  @d0ugmac1 

Thank you for your suggestions.

However, this doesn't make sense as it reflects the config on the WAN-site.

All clients - including the VPN-ones - connect to the LAN-site.

It receives an IP-address and the DNS-servers from the LAN and OpenVPN-config - not from the WAN-site.

Any other suggestions?

With warm regards - Will

@Virgo 

Thank you for the response.

Yes - OpenVP supports full tunnel.

This is done by adding the following to the OVPN-file (for my local network):

=====

dhcp-option DNS 192.168.139.235
register-dns
block-outside-dns
route-gateway 192.168.139.240

=====

However, to make this resilient, there should be no other DNS-servers added.

Which is what happens when a device connects via the VPN.

It works as expected when connecting via the LAN and adding 192.168.139.235 as DHCP and DNS server.

Suggestions?

With warm regards - Will

  @ITV 

Almost every router I've come across simply takes the DNS server IP's provided by the ISP on the WAN side and includes them as the DNS servers for DHCP clients on the LAN side.  Since I'm pretty sure your ISP didn't include 8.8.8.8 as one of its DNS server, it had to have come from the TPlink router...not a bad move on their part because if there's a problem with the carrier DNS services...you can fall back on Google.  My assumption is that by allowing 'Auto DNS', the router includes 8.8.8.8 and my suggestion was to disable the Auto function and instead manually configure the IP's to be used by LAN clients to be the specific one you require.  Again, the DNS servers defined on the WAN interface are propagated to LAN clients via DHCP.

Now it's always possible that TPlink has hardcoded something in the OpenVPN implementation, but, it would take all of a minute to try my suggestion, right?

  @d0ugmac1 

d0ugmac1 wrote

  @ITV 

 

Almost every router I've come across simply takes the DNS server IP's provided by the ISP on the WAN side and includes them as the DNS servers for DHCP clients on the LAN side.  Since I'm pretty sure your ISP didn't include 8.8.8.8 as one of its DNS server, it had to have come from the TPlink router...not a bad move on their part because if there's a problem with the carrier DNS services...you can fall back on Google.  My assumption is that by allowing 'Auto DNS', the router includes 8.8.8.8 and my suggestion was to disable the Auto function and instead manually configure the IP's to be used by LAN clients to be the specific one you require.  Again, the DNS servers defined on the WAN interface are propagated to LAN clients via DHCP.

 

Now it's always possible that TPlink has hardcoded something in the OpenVPN implementation, but, it would take all of a minute to try my suggestion, right?

Yes - and I did. In fact - since about a year I run DNS and DHCP outside of the TP-link router.

Meaning that DHCP is disabled on the Omada router. And the field indicated as "Legal DHCP servers" is pointing to the Pihole-system.

Pihole relies on dnsmasq for serving DHCP and DNS requests. Within these DHCP-requests, the Omada router is returned as the default gateway.

However, the part that I cannot control is the OpenVPN-config and the way these connection are handled since both are hardcoded.

I tried doing a manual override by editing the downloaded OVPN-file. Unfortunately, the original DNS-values stayed => being the gateway IP adress on the LAN-side and the famous 8.8.8.8 from Google. 

I don't see a way of preventing this from happening.

  @ITV Since you aren't using the ISP DNS settings anyways, could you, in the name of science, humour me and try the manual DNS settings for the WAN?  If nothing else you get 《I Told You So》 bragging rights :)

In my personal setup I do the reverse, ie LAN client tunneled to remote site and using remote site DNS.  Manual settings got rid of the 8.8.8.8 DNS leak I had been seeing.  Hoping the same might apply in reverse.

d0ugmac1 wrote

  @ITV Since you aren't using the ISP DNS settings anyways, could you, in the name of science, humour me and try the manual DNS settings for the WAN?  If nothing else you get 《I Told You So》 bragging rights :)

 

In my personal setup I do the reverse, ie LAN client tunneled to remote site and using remote site DNS.  Manual settings got rid of the 8.8.8.8 DNS leak I had been seeing.  Hoping the same might apply in reverse.

@d0ugmac1 :

I would prefer me saying "yup - you are right" as that would solve my problem.... :-)

However (see screenshot below)... these are the full IPv4 details on the Internet/WAN-connection of the TP-link router.

What is your view after seeing this?