[MikroTik RB750Gr3] OpenWrt 24.10.0. DNS leaks from net with VPN-access internet

Hi.
I am setting up a network with internet access via VPN. (openvpn-openssl package installed) The VPN provider provides .ovpn configuration files.

There are no DNS related options in .ovpn files.

I have openvpn installed, the router's ethernet ports are distributed using vlan:
br-lan.1 - network with access via vpn
br-lan.2 - without vpn

In luci, interfaces for br-lan.1, br-lan.2, tun were created on the Network -> Interfaces page
In Network -> Firewall, zones for them were created (br-lan.1, br-lan.2, tun), and Forwarding br-lan.1 was specified in tun.

As a result, the traffic of the br-lan.1 network goes through the VPN, but DNS requests go to 192.168.1.1 and then to the Internet provider (I see DNS-resolve requests on the WAN interface).

I went to the page Network -> Network -> Interfaces (name br-lan.1) -> Advanced settings
And set the server 8.8.8.8 in the field "Use custom DNS servers"

Rebooted the router, plugged the patch cord into the computer, but...
Openwrt in DHCP offer transmits option 6 "192.168.1.1", and when resolving names, requests go from the router bypassing the VPN. (This also happens without such a setting).

The next step was to return the value of the "Use custom DNS servers" field back to empty.

I try to edit the .ovpn file, adding there:

dhcp-option DNS 8.8.8.8
dhcp-option DNS 8.8.4.4

But this option has no effect: DNS requests continue to come from WAN

Maybe redirect using iptables?
Put over ssh:

#iptables -t nat -A PREROUTING -i br-lan.1 -p udp --dport 53 -j DNAT --to 8.8.8.8:53

return:

Warning: Extension DNAT revision 0 not supported, missing kernel module?
iptables v1.8.10 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

#iptables -t nat -L

iptables v1.8.10 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

I'm out of ideas.

What I want:

  1. The DNS server for br-lan.1 to be on 192.168.1.1, but DNS requests for this network to go only through VPN. (192.168.1.1 is highly desirable, but not necessary in principle)
  2. Install redsocks with authorization, through which you can access the Internet bypassing VPN from this network if necessary. And it should find out names not through VPN, but directly through DNS servers provided by the Internet provider. (to use if VPN does not work, or other)
  3. Ideally, if there is no dhcp-option option in the .ovpn config, then Google's over VPN servers are used, and if there are, then the VPN provider's servers are also over VPN. (optional). So that you can substitute the VPN provider's files without studying or editing them.
  4. The network without VPN (br-lan.2) and the openwrt router itself continued to use the DNS servers received via DHCP from the provider.

I read this page: https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#providing_custom_dns_with_dhcp
It didn't become any clearer: there are examples of replacing DCHP options with binding by client's mac.
But I need to make a binding to the br-lan.1 interface regardless of mac and ip addresses.

So, the question is: how to properly VPNize DNS requests in OpenWrt for a network that works with the Internet via VPN and only for it, without breaking anything necessary?

Or actually, create an IPv4 route for 8.8.8.8/32 and 8.8.4.4/32 via your VPN.

Iptables doesn't come by default in 24.10. It uses nftables.

1 Like

I don't like the decision to add a route via VPN to 8.8.8.8 for OpenWrt. Because the same router distributes the network without VPN and connects directly itself, and a proxy for direct access to the Internet will work on it. For these clients, it is advisable to leave the usual route to 8.8.8.8.

I was surprised by the lack of a "nat" table on the router. :sweat_smile:
I once thought that if the iptables package can be installed, then everything we are used to will work there.

Thanks for reply.