VPN bypass for specific clients not working anymore since 4.6.4

Technical Support for Routers
1

I use a Brume 2 with permanent WG VPN and defined this:

image

image

image

image
image799×365 10.6 KB

And have given the devices I want to use WAN (bypass VPN) a fixed IP and set this in /etc/config/firewall

config rule
option target 'ACCEPT'
option src 'lan'
option dest 'wan'
option name '165 allow mkdr-hue'
option src_ip '192.168.8.165'
option family 'ipv4'
option proto 'all'

config rule
option target 'ACCEPT'
option src 'lan'
option dest 'wan'
option name '12 allow mkdr-pc2'
option src_ip '192.168.8.12'
option family 'ipv4'
option proto 'all'

config rule
option target 'ACCEPT'
option src 'lan'
option dest 'wan'
option name '11 allow mkdr-v11'
option src_ip '192.168.8.11'
option family 'ipv4'
option proto 'all'

I want all traffic default go through VPN, and block all default traffic if VPN is down, EXCEPT clients I define per IP, which always dont use VPN and use WAN. This worked perfectly fine before 4.6.4. Since upgrading to 4.6.4 this is no longer working. Seems you have broken it.

In this case, I want to define for example

192.168.8.11
192.168.8.12
192.168.8.165

to not use VPN, use WAN, and not be blocked

The Glinet Web GUI also has no way to define this btw which is not acceptable if you have this way of VPN usage. It is really annoying, that the Glinet web interface lacks basic router settings, no firewall settings, no routing settings, no DHCP advanced settings for each client (set gw, dns).

Anyone have a solution for this?

Seems the issue is only DNS, if I do this on client 192.168.8.12:

Ping wird ausgeführt für 1.1.1.1 mit 32 Bytes Daten:
Antwort von 1.1.1.1: Bytes=32 Zeit=20ms TTL=53
Antwort von 1.1.1.1: Bytes=32 Zeit=19ms TTL=53
Antwort von 1.1.1.1: Bytes=32 Zeit=23ms TTL=53

Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 19ms, Maximum = 23ms, Mittelwert = 20ms
STRG-C
^C
C:\Users\maked>ping heise.de
Ping-Anforderung konnte Host "heise.de" nicht finden. Überprüfen Sie den Namen, und versuchen Sie es erneut.

Seems DNS is blocked this way, where it was working before 4.6.4

image

Also using AdGuard

image

I tried to change DHCP to use custom client DNS like this:

/etc/config/dhcp

config host
option mac 'xxxx'
option ip '192.168.8.165'
option tag 'mkdr-HUE'
option dhcp_option '6,8.8.8.8,1.1.1.1'

Still not working. Looking on client, it still gets 192.168.8.1 as DNS and option dhcp_option '6,8.8.8.8,1.1.1.1' is being ignored. This also worked in the past before 4.6.4.

Tries this option which did nothing:

image

Disable AdGuard also doesnt help. option dhcp_option '6,8.8.8.8,1.1.1.1' still being ignored.

2

Can you verify with the hops from tracert on the clients if they follow vpn or wan route?

Also: can you try with unchecking the checkbox block non vpn traffic?

3

You dont understand this topic it seems. Please read again, in its full form. Uncheck "block non vpn traffic" makes no sense. Of course it would work if unchecked.

4

I found a workaround so far myself to this. The syntax for pushing specific DNS via DHCP to specific clients is this via tagging, for some reason it doesnt work the other way (above):

config tag 'owndns'
list dhcp_option '6,1.1.1.1,8.8.8.8'

config host
option mac 'xxxx'
option ip '192.168.8.165'
option name 'mkdr-HUE'
option tag 'owndns'

This works and is a workaround for this issue. Would like to have an answer from Glinet staff for this what was changed in 4.6.4 so the previous method doesnt work anymore and how to resolve it.

I found another issue:

The Glinet web gui uses the "tag" syntax to put a name for DHCP clients, this is BAD and needs to be changed:

image

because I need the tag syntax for dhcp_option , Glinet needs to change this, to save the description internally into another file, or change tag to name instead:

config host
option mac 'xxxx'
option ip '192.168.8.165'
option name 'mkdr-HUE' <-- glinet web interface uses tag here, which is wrong
option tag 'owndns'

5

Well i'd understand the topic, but i'd take litterly what the block non vpn traffic means.

If it worked before with this setting and now not, then they actually fixed it as intended.

But your issue is something else but you have to disable this checkbox first.

They also made changes against dns leaking, but in a way it doesn't play nice with wan policies and the chances are that wan uses vpn internal dns instead of the dns which you supplied local aka adguard.

But expecting it to work with block non vpn traffic that is wrong, if it work that is a bug.