I didn't understand your second requirement clearly.
Let me list the common functions, and you can see which one fits.
(1) Designate some devices to access the Internet through VPN channel, and designate some devices not to access the Internet through VPN channel, which are directly connected.
Do you remember updating the previous VPN configuration? We need your previous configuration to determine whether to keep the problems caused by the upgrade of the old configuration.
Or you can try to upgrade the firmware without keeping the old configuration, and then see if there are any problems with the new VPN.
When the vpn was disabled, those devices were still getting internet access. Strangely, everything works correctly now and I wasn't able to reproduce it again.
I have the same problem, and I understand your answer. We might need to input as many domain names as possible to "perfectly" cover these potential streaming media addresses. However, I found that when testing speed with fast.com, a large number of domains have addresses like ipv6-c066-hkg001-ix.1.oca.nflxvideo.net:443 or ipv6-c072-hkg001-ix.1.oca.nflxvideo.net:443. When setting VPN rules, is it possible to use wildcards like an asterisk, or regular expressions such as:
Otherwise, I can hardly imagine the enormous amount of work it would take to perfectly cover all the subdomains of these potential streaming media websites.
Killswitch is a property of Tunnel, which is to ensure that traffic is not leaked after the VPN connection is accidentally disconnected. When the Tunnel is actively closed, all the properties and rules related to the Tunnel will disappear.
In your usage scenario, you should close the Non-VPN Tunnel. The function of the Non-VPN Tunnel is to allow the packets that do not match any tunnel to be transmitted from the WAN. When it is closed, the packets that do not match any tunnel will be DROP.
The Pic I shared above is the configuration I wanted. So basically when the vpn is off, I wanted those 2 clients network to DROP.
It works as expected now, but it didn't when I first tried for some reason.
Anyway, I want to say that this beta has solved my performance issues with repeater mode. The stable version was causing terrible performance (.5mbps when the original wifi was 60+) as well as drops and disconnects. Across multiple hotels and countries.
But since upgrading to the beta it's been full speed and stable so far. So thank you team for that.
There needs to be an option to force the Adguard service traffic itself to be routed through the Wireguard tunnel, I think this is not the case so far, and Adguard will just normally use WAN and not tunnel device for its service.
Second, no, there is no option so far to do this. If oyu activate kill switch, even if you configure clients to not use VPN, all traffic is blocked on these clients, and you manually need to configure /etc/config/firewall to do this:
config rule
option target 'ACCEPT'
option src 'lan'
option dest 'wan'
option name '12 bypass killswitch'
option src_ip '192.168.8.12'
option family 'ipv4'
option proto 'all'
This needs to be included in the Glinet webinterface as I said.
Killswitch + donotusevpn list doesnt make any sense in the current way it is implemented. There needs to be a nother list or option to allow the donotusevpn list to bypass killswitch, ,thats the entire point of the donotusevpn list.
First:
You mean that the current routing function, only the DNS of Adguard Home is taken over by VPN, and the traffic of Adguard Home itself does not take VPN, is that right?
You need a switch to control whether the traffic of Adguard Home itself goes through VPN tunnel, right?
Second:
You need to make some devices refuse to connect to the network when VPN is not turned on, right? This function is currently managed on the client page. As for the function switch of donotusevpn, my understanding is that it is more like a blacklist and whitelist mode, such as whether all traffic that is not matched by VPN tunnel rules is allowed or denied.
I don't understand what you said: there needs to be another list or option to allow the donotusevpn list to bypass the Killswitch；;
Donotusevpn controls all the traffic that is not matched in the VPN tunnel, and Killswitch is the function of refusing to pass if the matched traffic in one VPN tunnel is not connected successfully. There is no correlation or intersection between them.
Not sure how I should otherwise explain it as I already did.
make Adguard traffic go through VPN, in the current implementation my understanding is Adguard traffic does not use VPN
like I said. the do not use VPN list is meaningless if you have kill switch on. the current implementation of kill switch means all traffic which does not go over vpn is blocked, even for clients you declare to not use VPN. this makes no sense. resulting in those clients to never have Internet, ever. so you need a whitelise from the kill switch function which is missing.
It is a kill switch on top of the wireguard kill switch, so with other words the gl kill switch is actually not really needed.
But wireguards kill switch only works if wireguard would go down not by ifup,ifdown events but litterly when the remote side is offline, if you turn off the interface or restart wan then the chances are wan takes over.
So yea... Wireguards version is more of a softer version of it.
On my vanilla OpenWrt I also use a killswitch on top by only forwarding the vpn to zone wgclient and not wan, it therefor only routes / forwards over wan if it had a wan mark which comes from Stangri's PBR package.
I guess GL-iNet could implement it this way too in their kill switch, then there is not really a need for this button
Exactly. Just give a simple client list where you can add per client option like use vpn/use not vpn. and also optional kill switch for vpn clients. meaning clients which use vpn with kill switch on, use vpn, if vpn down, theyre blocked to use wan. the other clients, you decline as not use vpn, always have access to wan/internet. the killswitch in this manner just makes sense for clients who use vpn, because you dont want theym to leak traffic outside from vpn. the clients you decline to not use vpn however you always want to work and have access to wan/internet, also if vpn is down.
the VPN tunnel of "Client list use VPN" and the VPN tunnel of "Client list use VPN" match the same device rules;
The VPN channel of "Client list use VPN" needs to turn off the switch of "Kill Switch";
The VPN channel of "All use VPN" matches the remaining equipment rules that you want to take the VPN channel, and turn on the switch of "Kill Switch";
The "Non-VPN Tunnel" channel is closed to ensure that non-VPN channel traffic is blocked.
With this setting, you can use direct connection when the VPN of "Client list use VPN" is unavailable, and block traffic when the VPN of "All use VPN" is unavailable.
I dont understand this. The translation sounds really weird. Even if I read it 10 times I still dont understand it. This is way made way too complicated, why? Who came up with this implementation? Why did you change it like this? All you had needed was implement a simple white list of kill switch, or just make 2 lists of which client use vpn, which client use wan and toggle option if vpn is down block traffic for client on vpn list. why that "client list use wan if vpn is down" list? that makes no sense. obviously a client which should use vpn always needs to use vpn and never use wan. thats the entire point behind it. but at the same time, you want clients to always use wan as exception where it is irrelevant if vpn link is down or not.
This setup seems to allow you to indicate a group of clients which prefer to use VPN, but will use WAN if the VPN is unavailable. I don't know if that's a huge use case, but I don't find this interface very confusing. I just hope they are able to fix it so I can correctly put in a rule where certain domains are always resolved through a VPN regardless of client.
You can clearly see that GliNet is responding to most of our comments and their staff is trying to understand our requirements. There is no reason to speak like this to people.
Hello. I am working with an X-3000 router and on firmware 4.7.4 and 4.7.1 (from the website from the esim section). In the case of 4.7.4, in the eSIM Management section, I received the error No eSIM Card Detected, and there was no way to select and configure the eSIM at all. And in 4.7.1, there is no eSIM Management section at all. Can you tell me which version to install to work with eSIM on your router? I also installed version 4.8.0 and there is the same error No eSIM Card Detected in the eSIM Management section. Maybe I'm doing something wrong?
