Wildcard for bypass VPN based on domain

Hi @bruce

I have some IoT devices connected to Beryl AX - Firmware 4.7.0-op24 09/Dec/2024)

When the VPN Client (surfshark) is ON, all IoT devices keep changing the status to online/offline frequently.

The solution for this is bypassing the VPN based on domain, but your firmware doesn't support wildcards.

Could you please evaluate to add this feature?

I tried adding coolkit.cc on the Policy Mode, but it doesn't bypass the VPN when the domain is eu-apia.coolkit.cc (for example)

@admon, is the user above a bot?
It seems she posted the same question as mine, but rewriting it via AI :thinking:

1 Like

I would like to agree, but can't tell for 100% sure.

I'll continue monitoring it.

2 Likes

Hello,

GL firmware supported the wildcards domain, including the op24 firmware you mentioned.

I tested but seems the issue did not reproduce:

MT3000 with 4.7.0-op24, VPN Policy Mode is Based on the Target Domain or IP and Do Not Use VPN, the domain list configured like this:

When I add the "coolkit.cc":

It goes to the WAN of router, it is normal:


When I remove the "coolkit.cc":


It goes to the VPN of router, it is normal:

Verify the accessible:

Compare test another domain (on the list, not use VPN):

Note: as office has multiple ISP connection, it has done some special split by different WAN IP, and only focuses on whether there are hops. If there are hops, it will go to the router's WAN, and if the hop * * *, it will go to the router's VPN.
(The ICMP package is actually accessing the walk to VPN interface. There is no hop because there is a known problem with the VPN client software design, which is known and is expected may to improve on v4.8.)

1 Like

Hi @bruce

On your screenshot I noticed you are using OpenVPN.

I'm using Wireguard, Adguard Home is enabled and the VPN Policy Mode Based on the Target Domain or IP ("Do not use VPN") is not working.

Side note: 100.64.0.0/10 is the IP range from Tailscale (it isn't bypassing too)

As you can see, the coolkit.cc is on the policy above, but it's resulting in "Request Timeout" as Google (that isn't in the list), so both are going to VPN.

Can you confirm that your device is using the router as DNS server? AGH isn't allowed to handle client requests directly in this scenario, for example.

2 Likes

DNS Servers are set on "Upstream DNS Servers" on AdGuard Home and the clients are using those DNS.

If I set VPN Policy "Based on the client device", it's bypassing the VPN as supposed to.

Hmm what does dnsleaktest.com say or ipleak.net?

have you flushed dns with ipconfig /flushdns, is ipv6 off?

also a very sneaky one is this i observed with chromium browsers:

If the browser runs 'secure dns', even if set to follow up OS dns settings, and in windows you have explicity disabled DoH/DoT.

Chromium still goes on with a hardcoded list and prefers DoH on 'known resolvers', if DoH was not present it uses DoT, best is to fully disable secure dns.

So the dns overridable setting often in the gl ui gets ignored due to the evasion of the browser, even in unexpected terms if set to follow system dns.

If I test on computer, it shows the DNS I set on AdGuard Home.

But my problem is on IoT devices (they are "smart light switch").

If I set the VPN to bypass based on domain, they instantly lost connection with the servers (*.coolkit.cc)

Even IPs (100.64.0.0/10) from Tailscale are not been bypassed, so I guess the problem is not on the domain resolution.

If I set the VPN to bypass based on devices, all smart light switches connect back to the servers (but I need to bypass based on domains).

Does the disconnection say something about refused to connect?

If so what happens if you try:

in cli you type ip rule, copy this fwmark for the wan policy.

then in luci you go to network->firewall->traffic rules.

Make src any, dest wan, click on advanced settings and set here this fwmark.

I had issues with this in much older firmware.

I don't know. The smart light switch just starts flashing the LED connection and all of them became offline.

The vendor says I need to turn off the VPN or bypass all domains *.coolkit.cc

Another subject: On Tailscale, bypassing the IP range 100.64.0.0/10 also doesn't work.
The connection becomes extremely slow (like 30 seconds just to load a login page of my device). If I bypass based on device, it works perfectly with normal speeds.

It seems this firmware (4.7.0-op24), on Beryl AX, is not bypassing based on domains, when the VPN is Wireguard.

Do you enable this option? @Renato

1 Like

Hi @hansome
Yes, it was enabled.

When the VPN Policy is based on client device, it's bypassing the VPN as expected:

When the VPN Policy is based on Target Domain or IP, it isn't working:

Disabling Adguard Home also didn't help:

You need to turn AdGuard Home Handle Client Requests off.
As described in the tool tip there.

On my previous comment I also tested with Adguard Home disabled.

But, here is the result with Adguard Home enabled and Adguard Home Handle Client Requests off: It isn't working either

Also running the traceroute directly from Beryl AX:

Domain based policy routing relies on dnsmasq to do domain name resolution. If the dns query resolution bypasses the router, it will not work. Please try this:

nslookup coolkit.cc 192.168.8.1
tracert coolkit.cc

Do you access tainet by ip or domain?
My test shows traffic goes as expected when I ping tailnet host on a router lan client.

root@GL-MT3000:~# tcpdump -i eth0 -s0 -n port 51820
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@GL-MT3000:~# 
root@GL-MT3000:~# tcpdump -i wgclient -s0 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wgclient, link-type RAW (Raw IP), snapshot length 262144 bytes
22:49:18.790409 IP 10.0.0.4.38866 > 64.6.64.6.53: 28313+ A? config.extension.grammarly.com. (48)
22:49:18.904400 IP 64.6.64.6.53 > 10.0.0.4.38866: 28313 5/0/0 CNAME d27xxe7juh1us6.cloudfront.net., A 13.33.183.75, A 13.33.183.15, A 13.33.183.83, A 13.33.183.125 (155)

^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@GL-MT3000:~# 
root@GL-MT3000:~# tcpdump -i tailscale0 -s0 -n icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tailscale0, link-type RAW (Raw IP), snapshot length 262144 bytes
22:49:30.241038 IP 100.113.201.25 > 192.168.8.183: ICMP echo reply, id 10583, seq 138, length 64
22:49:30.241264 IP 100.113.201.25 > 192.168.8.183: ICMP echo reply, id 10583, seq 139, length 64
22:49:30.384244 IP 100.113.201.25 > 192.168.8.183: ICMP echo reply, id 10583, seq 140, length 64
22:49:30.615882 IP 192.168.8.183 > 100.113.201.25: ICMP echo request, id 10583, seq 141, length 64
22:49:30.905878 IP 100.113.201.25 > 192.168.8.183: ICMP echo reply, id 10583, seq 141, length 64
22:49:31.616140 IP 192.168.8.183 > 100.113.201.25: ICMP echo request, id 10583, seq 142, length 64
22:49:31.913463 IP 100.113.201.25 > 192.168.8.183: ICMP echo reply, id 10583, seq 142, length 64
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel
root@GL-MT3000:~# 
root@GL-MT3000:~# 

Rebooting the GL-MT3000 did the job!
I guess it loaded the list of domains only after rebooting.

Google is not by-passing the VPN, as expected:

coolkit.cc is by-passing, as expected:

Thanks! :+1::+1:

It mostly loads the list while restarting the VPN.

It should load when we click on "Apply":