DNS leak via OpenVPN and policy based routing

Do you have any solution for this case, or can you specify a keyword for me?
I have no idea with this stuck

Please, comment string containing 'ula_prefix' in /etc/config/network

Add corresponding 'ipv6' string to 'lan' section also.

Give also output of ip a s

we got the same error (I restarted the router)

Here is the out put of ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP group default qlen 1000
    link/ether 50:64:2b:12:30:b4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5264:2bff:fe12:30b4/64 scope link 
       valid_lft forever preferred_lft forever
3: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 50:64:2b:12:30:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.222/24 brd 192.168.0.255 scope global wan
       valid_lft forever preferred_lft forever
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
    link/ether 50:64:2b:12:30:b4 brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
    link/ether 50:64:2b:12:30:b4 brd ff:ff:ff:ff:ff:ff
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 50:64:2b:12:30:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fe80::5264:2bff:fe12:30b4/64 scope link 
       valid_lft forever preferred_lft forever
9: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 50:64:2b:12:30:b6 brd ff:ff:ff:ff:ff:ff
10: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 50:64:2b:12:30:b5 brd ff:ff:ff:ff:ff:ff
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1551 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.8.0.2/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::c35d:e0c5:3cd3:2af9/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

OK, and final attempt: please, make ONE correction:
make default route via tun, adding
redirect-gateway def1
to OpenVPN-client configuration.

Give also output of cat /etc/hosts

I think we are not lucky today. Anyway, thank you very much for helping me.
If you have a new idea, please give me a reply

OK, and final tip for current configuration:

ip r
ip route show table all
traceroute 8.8.8.8

Here are the outputs. I hope that you will find smt

ip r
0.0.0.0/1 via 10.8.0.1 dev tun0 
default via 192.168.0.1 dev wan proto static src 192.168.0.222 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 
103.231.188.87 via 192.168.0.1 dev wan 
128.0.0.0/1 via 10.8.0.1 dev tun0 
192.168.0.0/24 dev wan proto kernel scope link src 192.168.0.222 
192.168.10.0/24 dev br-lan proto kernel scope link src 192.168.10.1
ip route show table all
default via 192.168.0.1 dev wan table pbr_wan 
192.168.10.0/24 dev br-lan table pbr_wan proto kernel scope link src 192.168.10.1 
default via 10.8.0.2 dev tun0 table pbr_openvpn 
192.168.10.0/24 dev br-lan table pbr_openvpn proto kernel scope link src 192.168.10.1 
0.0.0.0/1 via 10.8.0.1 dev tun0 
default via 192.168.0.1 dev wan proto static src 192.168.0.222 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 
103.231.188.87 via 192.168.0.1 dev wan 
128.0.0.0/1 via 10.8.0.1 dev tun0 
192.168.0.0/24 dev wan proto kernel scope link src 192.168.0.222 
192.168.10.0/24 dev br-lan proto kernel scope link src 192.168.10.1 
local 10.8.0.2 dev tun0 table local proto kernel scope host src 10.8.0.2 
broadcast 10.8.0.255 dev tun0 table local proto kernel scope link src 10.8.0.2 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.0.222 dev wan table local proto kernel scope host src 192.168.0.222 
broadcast 192.168.0.255 dev wan table local proto kernel scope link src 192.168.0.222 
local 192.168.10.1 dev br-lan table local proto kernel scope host src 192.168.10.1 
broadcast 192.168.10.255 dev br-lan table local proto kernel scope link src 192.168.10.1 
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
anycast fe80:: dev eth0 table local proto kernel metric 0 pref medium
anycast fe80:: dev br-lan table local proto kernel metric 0 pref medium
anycast fe80:: dev tun0 table local proto kernel metric 0 pref medium
local fe80::5264:2bff:fe12:30b4 dev eth0 table local proto kernel metric 0 pref medium
local fe80::5264:2bff:fe12:30b4 dev br-lan table local proto kernel metric 0 pref medium
local fe80::e2b7:fbb1:ad76:b3fc dev tun0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev br-lan table local proto kernel metric 256 pref medium
multicast ff00::/8 dev tun0 table local proto kernel metric 256 pref medium
traceroute 8.8.8.8
 1  10.8.0.1 (10.8.0.1)  38.091 ms  38.820 ms  37.818 ms
 2  mx1882.vhost.vn (103.231.188.2)  39.024 ms  39.748 ms  37.673 ms
 3  *  *  *
 4  google.sgix.sg (103.16.102.64)  40.841 ms  as15169.singapore.megaport.com (103.41.12.7)  38.521 ms  198.32.141.140 (198.32.141.140)  40.319 ms
 5  108.170.254.225 (108.170.254.225)  41.975 ms  108.170.240.161 (108.170.240.161)  41.915 ms  *
 6  142.251.241.3 (142.251.241.3)  39.597 ms  142.251.240.255 (142.251.240.255)  39.774 ms  209.85.245.51 (209.85.245.51)  41.833 ms
 7  dns.google (8.8.8.8)  41.544 ms  39.536 ms  38.524 ms

OK, and in current configuration for device you are running terminal, run the command from device itself, not router:
ping medium.com

It has a similar error as inside router

OK, it is very strange. Now I can only recommend to start from scratch, initially setting OpenVPN-connection with default route without PBR-package.

1 Like

You are not running a local adblock package by any chance?

@egc I only install pbr openvpn, and do not install any different packages.

@ulmwind I just reinstalled Openwrt and only installed OpenVPN. I still got the same error.
P/s I import the same OpenVPN profile to my iPhone, after that I can access medium.com. I am sure that the error does not come from the OpenVPN profile.

Try this (ugly) workaround to see if it makes a difference.

echo "162.159.153.4 medium.com" >> /etc/hosts
echo "162.159.152.4 medium.com" >> /etc/hosts
echo "2606:4700:7::a29f:9804 medium.com" >> /etc/hosts
echo "2606:4700:7::a29f:9904 medium.com" >> /etc/hosts
/etc/init.d/dnsmasq restart
/etc/init.d/pbr restart

It would be simpler to send all Internet usage through VPN first, and confirm that tunneled DNS and access to medium.com works. Then try to make it fancy with PBR.

1 Like

OK, please, set static IP, and public DNS on your device, and try to ping medium.com from it.

@pavelgl @ulmwind I edited in file /etc/hosts and now I can access medium.com but lose some media and js files due to subdomains of medium (I can find these domains and add them to hosts later).

Is there some reason you need to use the ISP DNS at all? The only one I can think of is that there are TV or phone services that are only accessible from inside the ISP. That could be handled by adding those domains to the dnsmasq configuration and static routes to the ISP DNS via wan, and PBR to the actual services.

If you don't need any of that, just tunnel all DNS through the VPN.

Are you using 'stock' OpenWRT from official site?

1 Like

Disable DNS caching, disable peer DNS and configure public resolvers:

You need to circumvent DNS hijacking performed by the ISP.
Each of the configured resolves must be routed to the VPN.
PBR requires the correct DNS replies to create the proper rules.
Dnsmasq may cache wrong replies due to ISP DNS hijacking.
This makes PBR depend on OpenVPN and Dnsmasq.
Be sure reconnect your LAN clients and clear their DNS caches.


You should also consider DNS encryption as a workaround:
https://openwrt.org/docs/guide-user/services/dns/start#encryption

3 Likes

The issue is, that dns queries have been sent via tun interface, and nothing changes.