Brume - VPN Policy not working when using AdGuard Home on RPi

Hello. I have a problem which may be a bit long-winded, so I will try and explain my problem the best I can.

I have a Brume (version 3.203) and I have AdGuard Home that is installed on a Raspberry Pi 4. Furthermore, I have my VPN policy enabled and set to:

  • VPN for guest network - disabled
  • Use VPN for all processes - disabled
  • Domain/IP
  • Rules - do not use VPN for the following
  • list of websites that I don’t want to use the VPN

Using the GL.iNet GUI, if I set the custom DNS to (the IP for my Raspberry Pi), then it works, AdGuard Home deals with requests and the split tunnelling based on the VPN policy works. However, I only see one client shown on AGH - the router.

The other option I have tried, is using LuCI GUI - in Interfaces → I set DHCP option 6 to the Raspberry Pi IP on the LAN interface. And for the WAN interface, I unchecked Use DNS servers advertised by peer. The result is AGH can also handle requests, all the clients on the network are being shown on AGH, but the problem is that the VPN policy is not working.

So what I am trying to achieve is:

  • AGH on IP address to handle the DNS stuff
  • Show all the clients on the network on AGH instead of just the router.
  • Have the VPN policy working (for example: going through WireGuard but does not).

I thank you in advance for any help, whether I need to make custom firewall rules, a config change in dnsmasq, or anything else.

invert do not use VPN for the following

Thank you for your response.

I have inverted the setting, so it is Only allow the following use VPN and added Netflix domains and BBC, but the opposite effect happens - Netflix and BBC aren’t routed through the tunnel, so all the websites are going through the non-WireGuard interface. So this may suggest that there is an issue with the VPN policy feature.

This morning, I downgraded the router to 3.105, set the router settings like the 2nd settings I talked about in my OP, connected to my VPN and turned on VPN policy, and it is working fine (touch wood). So, to me, there may be a problem with something in the 3.203 firmware.