Are Glinet mobile router protected against CVE-2024-3661 (tunnelvision)?

You claimed through the entire posts countless times, this is no issue at all.

That was not what I meant. I argued you should include a toggle option in the Glinet web interface to revert this if needed. Just add a classlessroute on/off toggle in the Glinet web interface. Not everyone has ssh / telnet access to revert it back via uci command or edit network config file.

That means the entire logic of the Glinet devices is questionable and not properly done. There should be iptables rules to include filtering through wg0 / tun0 devices as extra mechanism for routing, or mangle / mark / flag packets properly. Wonder if there might also be some leaks happening for some second or so, if the tun/wg interface are opened/closed for a second or so, if there is no extra mechanism.

I would say this is the case.

DNS is a different story because some people don't want to route DNS through the VPN.
But we will see what @hansome tells us later.

"Block Non-VPN Traffic" is for this purpose. Which can also prevent the case with tunnelvision causing DNS leak.

1 Like

Check these posts as you seem to have missed them @mkdr.

Nothing in this issue is not working as designed. Note, I have been adamant that this is not a vulnerability. Want to protect your identify - you should already be using things like https, ssh, secure dns. All of these things protect your traffic. Want to remain anonymous, have additional controls to prevent leaks. If you don't do these things, you are asking for trouble anyway.

Outside of privacy concerns (why would you be in or around a Starbucks browsing stuff you wouldn't want to be associated with by the way), there is not vision into the tunnel. Event he name of this issue is a misnomer. What vision do you have inside the tunnel? None.

1 Like

@mkdr you are creating “holy war”. Why just not to add toggle to GUI that will be opt-in (not opt-out !!)? Is someone wants to be hacked (or understand risk) he will simply toggle it on. But I think there should be a warning that opting it in will harm your security.

@packetmonkey it is CVE still. And on travel routers it is serious problem. If you are travelling in some countries with censored internet, it becomes critical. So idea of @alzhao to disable it by default is more than enough. If you really want this option - just run enable command or click on gui toggle (if will be).

I vote for a toggle :+1:

Because some users very much rely on voip and iptv, they actually depend on routes given by isp.

But it is fine to make a user attend such option exist this can be done by using a checkbox.