Hi,
Please help me to understand how it works this new VPN feature in 4.8.0 Beta.
I have 2 tunnels in this priority order:
All devices > Wireguard Mexico > Specified Domain / IP List. And here I have whatismyipaddress.com
All clients > Wireguard Germany > All Targets
Now when I go to whatismyipaddress.com it shows the Germany IP instead of Mexico.
Did I miss anything? Should I configure it somehow different?
What you've likely discovered is that whatismyipaddress.com causes your browser to query a large number of other domains that don't appear in your URL bar. For example, I see all of the following domains queried when I visit whatismyipaddress.com:
fusebox.fm
omappapi.com
onesignal.com
whatismyipaddress.com
whatismyipaddress.info
I'd guess that the IP address detection is being done by a domain other than whatismyipaddress.com and you would need to add that to your domain list for the IP address detection to work.
I actually covered a similar use case in this thread.
whatismyipaddress.com actually was just an simple example for what’s going on.
What I try to do is exactly what you have described in your other thread. But with the same problem, instead of being directed to area specific content, I receive local specific content.
So I've had an issue with this since having to restore the firmware. I'm now on 4.8.0.
When setting up a VPN I'm finding the Travelling to 'Exclude/Include' list is being ignored.
The VPN is routing to the selected country.
But whatever domains I type into the 'Exclude' list are ignored and still route via VPN.
Whatever I type into the 'Include' only list - all targets are still router via VPN.
This was working - so no ideas why it has stopped.
So the 'Travelling to:' list is actually now being totally ignored all ALL is the default. True both 'Excluding' and 'Specified' targets.
So it’s not just me, it seems to be a general issue.
Maybe will be fixed in future releases 
I will try a snapshot version maybe it is already fixed 
Hello,
May I know if the 'Travelling to:' list works well in beta firmware (Jun 14)?
No - it is still not working in that new version.
Make sure you've disabled local DoH or DoT policies that may cause your LAN devices to route DNS queries to WAN instead of your router. That caused trouble for me. Many browsers now use DoH by default, and this would cause the VPN config based on destination domain to fail to pick up the traffic.
Where would that be? It isn't something I've changed from memory - and the VPN was working until recently.
Cloudflare has a doc that covers where these settings live in each browser. You would not want to follow their configuration instructions, but this shows you where you'd need to go to change those settings: Configure DoH on your browser · Cloudflare 1.1.1.1 docs
Also, you may have DoH configured by a third-party app or MDM profile such as NextDNS's Apple profile generator or client application. You may also be using a program like YogaDNS or Little Snitch which can also hijack your system's DNS settings.
All are pointing at my providers settings - which seems to end up at Cloudflarenet 162.158.199.70
OK, you may want to check what your machines believe their DNS provider to be. On MacOS, run:
cat /etc/resolv.conf
On Windows run:
nslookup
You should see them report the IP of your GL.iNet router, not Cloudflare, etc. If they're reporting a WAN IP, then they are not using your router for DNS. You probably should enable "Encrypted DNS" in your GL.iNet router's DNS settings as well and choose one of the provider options that works best for you (I use NextDNS, but it's paid). That way your router will handle the WAN-side DNS encryption for you.
Even with router dns set up the VPN will fail to load the Domain List
Sorry you're still having issues. All I can say is that I've had the domain-specific VPN routing set up on the beta (and some of the snapshot builds, but currently the beta6/2025-06-14 build) and working now for around a month, and it's been consistently working for me during that time. Maybe your router configuration is somehow corrupted? I don't know. At this point, I'd see if GL.iNet support can help you. Maybe there's a bug that's impacting you and not me.
Besides what @pie mentioned — when DoH or DoT is enabled in the device’s browser and bypasses the router’s dnsmasq.
Enabling "AdGuard Home Handle Client Requests" will cause domain policies to stop working.
I don't have adguard loaded - tried it once and one of my main sites would not load.
my nslookup is the same ip as the router displays - which is my ISPs own DNS.
Hello everyone,
I need a little help with Policy Routing.
How do I automatically add a destination domain or IP to the Policy Routing exclusion list?
I have several hundred subnets that I'd like to automate (cron?) being added to the VPN exclusion list so that they are routed via the WAN interface.
The subnets can be obtained online: http://www.ipdeny.com/ipblocks/data/countries/ke.zone using wget. How to append them to the PBR exclusion list and ensure that the relevant daemon is given the signal to reread the specific file is the issue.
A little progress - after playing with some DNS settings I now find that Edge is working with the 'Specified Address' setting - but Firefox is not.
So it would seem it is incorrect DNS/IPs being used.
I recently tested PBR, as it’s a similar solution to our 4.8 with multiple VPN and policy implementations.
Currently PBR is more powerful and extensible, but the advantage of our VPN policy is that it’s simpler, providing a unified configuration entry to manage both policy and VPN instances.
Additionally, DNS traffic handling follows the policy as well — DNS policy is not handled separately from other traffic policies.
I think 4.8 VPN policy with domain/ip URL subscription URL can fit your needs:
If you're still using pbr, example command to set up PBR (for reference):
wget https://www.ipdeny.com/ipblocks/data/countries/ke.zone -O /tmp/ke.zone
uci set pbr.@policy[-1].dest_addr="$(cat /tmp/ke.zone|tr '\n' ' ')"
/etc/init.d/pbr restart
You could also consider adding the target addresses to a separate IP rule and routing table if not touching pbr settings.
The Policy Routing by GL.iNet is still looking quite primitive as compared with the PBR implementation in Vanilla OpenWrt. I get to know what I am doing in PBR because I can label the rules by name. In your 4.8 BETA, it's a blind input. In PBR, I can order the rules.
I looked at the VPN Policy on 4.8 BETA and it looks more like the one I saw long ago in dd-wrt.
URL subscription will not work especially where in cases where a URL resolves to multiple IPs.
There is a time my bank was blocking me from accessing its Internet Banking website, and I had to find what IPs the FQDN resolved to and route those via WAN.
I believe many GL.iNet users (including me who has just migrated to your firmware) will be happy with an implementation that mimics PBR implementation by Stan Grisham (pbr+luci-app-pbr).
As regards the hundreds of the subnets I was asking about, there is a script I use with PBR:
https://forum.openwrt.org/t/policy-based-routing-pbr-package-discussion/140639/127
And in my /etc/config/pbr, I have this rule:
config include
option path '/usr/share/pbr/pbr.user.ke.lst'
option enabled '1'
It works flawlessly.
However, in the 4.8 Policy Routing, I had to append these 300+ lines to the GUI window.
Appending them to the file the destination IPs/domains are written to did not work as I couldn't figure out what process to reload/restart.
Please bring the equivalent of pbr/luci-app-pbr to GL.iNet firmware.
