No internet when “Block Non-VPN Traffic” enabled under customized routing rules

I'm using two VPN client instances with customized routing rules. The first one uses Wireguard to access my home network, and the second one uses OpenVPN for everything else (default route). I set up 1st one and activated it first:

Then set up the 2nd VPN client:

Initially, I had no issue connecting to the internet or home network. After “Block Non-VPN Traffic” was enabled, my computer had no internet connection but no issue on access to the home network. Any help is greatly appreciated.

My router is MT3000 with the latest firmware V4.7:

Does it seem to have something to do with DNS? I'm able to ping 9.9.9.9 from my laptop, but none of the domain names can be resolved. Also, the internet is good if I change my laptop's DNS server to 8.8.8.8 (instead of automatic from router). The router's DNS setup has all default values and Adguard Home is not enabled.

Hello,

  1. In v4.7.x firmware, generally OpenVPN Client and WireGuard Client cannot run at the same time. How do you run dual VPN?

  2. Generally there is no need to configure the routing rule 0.0.0.0/0.

  3. Execute nslookup www.google.com on router SSH and PC and it will return the results. Please share the content or screenshot of the results.

When I chose "Customize Routing Rules", I'm able to run both VPN clients at the same time by following the directions from Multiple VPN Client. The lower metric value is used for Wiregurad route so it would have higher priority for the home network (192.168.10.x). Everything else needs to pass through OpenVPN (default route).

I used tracert command from my laptop and confirmed both VPN paths are working (when "Block non-VPN traffic" not enabled):


When "Block non-VPN traffic" is enabled, my PC can't resolve any domain name but no issue is observed on the router (ssh). The results of running nslookup command on the router (ssh) and my laptop are:

1 Like

Hello,

Please PM me the issue syslog, while enabled the Killswitch.

Hello,

We checked the cause of the issue:
In the case of custom routing mode, if there is a default routing, the DNS traffic is not correct directed to dnsmasq.

Workaround method, in Port Forwarding, establish a rule to LAN zone 53 -> 1653:

We will fix this issue as soon as possible.

1 Like

The workaround works. Thanks a lot.

1 Like