Hi there. I own a brume 2 with firmware 4.5.16 (also tried snapshot 4.6.0 with same result)
So here's what I'm doing. I have the brume 2 as the only router in my setup. ISP Modem (bridge mode) > brume 2 (router) > managed switch > Access Points for WiFi
When I setup my brume I imported a wireguard VPN client, France in this case (different country) I then select "VPN Policy Based on the Client Device" I chose "Traffic from Following Device" to "Use VPN" and assign a device to the list. The device that is policy routed shows correct VPN IP and their custom DNS server on dnsleaktest, so that's correct.
I then go to dnsleaktest on a device that is NOT in the listed to use the VPN second and I see the device IP is correct (my WAN ISP IP is listed) however, I then do the dnsleak test and it shows me the DNS country flag (France) next to each result as the DNS, this leads me to believe that any DNS queries are going via the VPN and not the WAN.
This all happens when the settings on the "Network > DNS page are set to encrypted.
If I go to network > DNS and choose mode "Manual DNS" then select cloudflare for example then the results work as expected but then I am not using any encryption. If I chose any of the encrypted DNS settings the NON Routed clients all get their DNS via the VPN.
I don't want this behaviour as if I was to have say "India" as my VPN server then all my DNS hits would route via Indian servers causing all my non policy routed VPN clients to have a slight delay.
I also enable adguard as that's a feature I want to use. If however I use adguard and enter the basics 1.1.1.1 (not encrypted) in adguard upstream and go back to dnsleak then I also get the VPN country flag in the wrong region.
So how can I get policy routing (when my VPN client is always online and DNS on brume 2 is to set to use DoT - cloudflare) to use my current location for DNS when the device is not routed via VPN, which is what I would expect
I have read posts regarding that VPN DNS will take priority but then if that's the case, why does selecting "Manual DNS" and work correctly / as expected but the other options don't?
by the way I clear browser cache etc - consistent results.
So on latest snapshot (v4.6.0) which I tried, the devices are working in a fashion.
So under the UI > Network > DNS settings on both 4.5.16 and latest snapshot 4.6.0 the "Encrypted DNS" settings cause the NON policy routed DNS over the VPN interface. I have checked this multiple times with the same results.
On v4.5.16 if you enable adguard home (which then makes the Network > DNS settings disabled) whatever upstream servers you set in adguard home, be it encrypted or not they will all go out via the VPN interface.
On v4.6.0 snapshot with adguard home enabled and the upstream set to non / encrypted DNS, the NON policy routed devices are going out via WAN DNS (local servers) which is correct (both IP and DNS are located in the same country).
With v4.6.0 you can override the VPN DNS settings on the Network Page, all though it's says "Adguard Home is enabled and the router will use the DNS servers produced by Adguard..." You can still toggle on "Allow custom DNS to override VPN DNS" which actually then can cause leaks on the VPN as ipleak will show a mixture of DNS results from wan and VPN - so it might be best if the toggles are greyed out and not allow to be toggled.
So just to sum up
V4.5.16 - current stable. Both gui Network > DNS and adguard home will bypass wan DNS and use the VPN DNS gateway for devices that should NOT be going via VPN if a wireguard client is running (if using encrypted DNS settings on the gui or using either settings on adguard) resulting in a ISP WAN address but a VPN DNS results * using policy based device routing
V4.6.0 snapshot (05.06.24 version DD/MM/YY) will do the same as 4.5.16 in regards to the Network > DNS settings (so still buggy), if they are set on encrypted DNS then devices that should NOT be policy routed vis VPN will have a WAN IP but a VPN dns result. If however you turn on adguard home (which disables the gui Network > DNS) then the policy routing works correctly, just like it does if the Network > DNS is set to manual. I can then add DoT DNS (or unencrypted servers) on adguard home and can confirm that DNS is going via DoT and via the correct interface for NON routed clients. Any client going via the VPN shows the correct VPN IP and DNS country flag.
All these apply to the VPN client * using policy based device routing
That's indeed an issue for firmware 4.5 and older firmware. The manual DNS(including adguardhome and encrypt DNS) has impact on DNS for non-VPN clients. This issue is addressed in firmware 4.6.
Thanks for pointing out the encrypted DNS bug for non-VPN clients, @teleney will try to patch it.
I think I may have found a few more bugs in firmware 4.6.0 (snapshot brume 2)
When adguard is enabled (with / without adguard client handling enabled) and a wireguard client is running an error occurs - the error occurs when you reboot the router AFTER you have enabled the options I mentioned.
I notice in my logs that ddns records couldnt update and the plugins list wouldn't update in the GUI or via Luci. I found a busybox ns error and searching posts on here I found that it's was discovered there was some DNS issues at play, after some testing I turned off adguard home which then gives me the "DNS Server Settings" back inside the Glinet GUI, I switch between the modes so that the apply button becomes enabled and select the mode: "Automatic" and hit apply. Turn back on adguard and the Wireguard client and now I can pull the software updates in the GUI / Luci and the ddns works. I can replicate this error by rebooting and then doing the same "fix" So basically if adguard is enabled and wireguard client is enabled / running after rebooting the router you will find that the router itself can't then get DNS to perform the said tasks. * I am again using the policy based routing via client device, with the USE VPN option. I have tested without the VPN client and it works correctly so the key thing here is that you must be running the Wireguard client to replicate the bug.
^ there was a post reported similar to what I've mentioned above: 'opkg update' fails with custom DNS server set - #9 by Happi
2nd bug - When inside Luci and clicking restart firewall I noticed that ALL my clients (even ones that shouldnt be going via VPN) then get routed over the VPN and my policy based routing via devices (Use VPN) doesn't kick in. After restarting the firewall inside Luci I then need to head over to the Wireguard Client GUI, click on the "define by MAC address" to bring my list of clients up and hit apply again. Once done, I then visit ipleak test and see my NON routed clients again work over WAN and my policy based clients going back over VPN, so it would seem some kind of rule / check should be made if the firewall has restarted for whatever reason - I was installing a plugin that required a firewall restart which is when I then noticed that all clients appeared to then go over VPN regardless (wireguard client)
The 3rd bug is a DNS leak when using "Enable VPN Cascading " over a different network (LTE in this case)
With VPN Cascading enabled my DNS leak test reports the correct external VPN DNS and country VPN IP of my external wireguard client but it also reports the DNS that are used in my wireguard server / client config which appear to be going out over WAN and are coming from my clearnet country location NOT that of my VPN resulting in a DNS leak.
I hope that by reporting these bugs here and not creating another thread is okay, the bugs I've reported are all DNS related anyway so they still fit under the umbrella of this topic.
With that said, may I ask where I can post future bugs / suggestions? There doesn't seem to be many categories on the forum. I would have presumed there to have been a dedicated section for bug reporting or suggestions, firmware version(s) sub forum, sub forum categories for each released model of router (brume2 section) for example.
Hi, I'm having similar issues with DNS leaks using MT-2500, Mullvad Wireguard, drop in gateway. When I enable AdGuard it seemed to fix the leaks but then after some time, test show leaks again (this time using Mullvad DNS but ALSO ISP's DNS).
I tried to repeat the mistake you mentioned, but failed. Here's what I did :1. Upgrade without saving Settings. 2. Run the wireguard client(in global proxy mode). 3. Enable adguard. 4. ping www.google.com. 5. Run the opkg upgrade command. Everything seems normal. Then, I executed reboot, it is also normal. Is there something wrong with what I did? I couldn't reproduce it.
This phenomenon does exist. Some rules are created when the VPN policy is saved. However, they are not written into the configuration file and are only temporary rules.
I think it's not working because you selected global policy mode, select policy based routing based on client device and choose USE VPN, add one client but also leave one client to route via clearnet.
So try this. Clean install. Make sure DNS is selected as auto and all options toggled off in the DNS settings gui, now go to adguard tab and Enable adguard home (you can leave handle clients off) and use
tls://1dot1dot1dot1.cloudflare-dns.com
As the upstream DNS inside adguard.
Use an external Wireguard VPN provider and ensure it's running. Go to your VPN policy and ensure its on policy based routing via devices and add a Mac address to the list, choose "To Use VPN" Now reboot, when you have rebooted visit the plugins pages inside the GUI and you should see the router will fail to load any packages.
Regarding my last post about the DNS / plugins failure, I have just tested on the latest 4.6.0 stable and the bug is still persistent.
I would also like to point out that 4.6.1 beta1 for the brume 2 is completely broken. I tested it out real quick to see if the VPN / DNS leak had been fixed like we mentioned in this post
When enabling wireguard client all rules are ignored. All traffic will go out via the VPN regardless and even with "use custom DNS for VPN" disabled all DNS settings are used, router and VPN - done with a clean install and keep settings OFF - still a broken release.
We think the problem you pointed out is important and we need to test it carefully. I didn't expect the new beta to be released so quickly that I didn't have time to merge it to release branch. That was my fault. I'm so sorry.
Acording to what you said, I reproduced it. Then,I use command "tcpdump -i wgclient port 53 -XXnn" to capture dns packets. I noticed that the DNS response did not appear. So, I tried to change the DNS server address of wireguard client. I got response packet. And, the subnet client (use VPN) will parse the domain correctly (via the wgclient interface).
So are you saying you have a found the bug and going to fix it? Also why would the Wireguard client affect the routers own DNS as that shouldn't be going out via wireguard should it? Again, policy based routing via client mode.