There was a large VPN vulnerability that was reported on in August. Did this vulnerability affect Gl.iNET and was it patched or did it never impact GL.iNET and GL.iNET firmware or software?
This depends kinda how the firewall rules are configurated.
from what I understand how tunnelcrack orginates is that a isp or mitm attacker can add routes to actually âleakâ your vpn.
So the awnser is⌠No, unless the firewall zone direction is configurated wrong.
A good configuration is from source (lan)->wgclient and not src->wgclient,wan.
Now the difficult part is⌠the firewall zone direction look wrong in luci, but that does not say what gl-inet internal kill switch does via iptables, nftables etcetera.
If a isp does something fancy like this it will be no internet on a good configuration.
I choosed the latter and fixed the firewall zones myself even though I think the killswitch works also very well.
I could have understood the vulnerability wrong though but I think I got a good idea of what it is.
Could you please provide instruction upon how you changed the firewall zones manually and ideally in a smooth brain friendly format. I too would like to ensure my no leak kill switch works as intended.
Sure!,
If you have enabled the vpn, then just go to system ->advanced to get into luci.
From there you click on tab network and then firewall
for a real generic example even though I recommend using a new firewall zone due to scripts automaticly adding wan againâŚ
Click on zone lan edit, and remove wan from Allow forward to destination zones:
In my case it looks like:
for you is pcnet lan.
But maybe you donât need this if a GL developer can confirm the killswitch blocks it, I just did it as being double paranoidđ
1 Like
@lizh can you confirm please?
That vulnerability doesnât impact GL.iNET firmware(4.4.6 and onwards).
As xize11 says, we have lan-wan traffic blocked if the VPN client is on.
I will add: thatâs true even when âBlock Non-VPN Trafficâ global option is off.
I checked the vulnerability details
and do some tests, and I conclude that the router provides an extra layer for such an attack.
Let me explain:
- LocalNet attack: - immunited by all GL.iNET firmware.
For Windows, after enabling wireguard client locally, we have routes from Interface 10.0.0.3.
I set the gateway to IP 1.2.3.4/24, the same as LocalNet attack.
While the âkill-switchâ option is off, Windows doesnât block the traffic from Non-VPN interface to 1.2.3.0/24 target network, thatâs how leak happens.
For GL.iNET firmware, we have firewall rules distinguishing the local traffic(OUTPUT) and LAN-WAN traffic(FORWARD).
When VPN client is on, OUTPUT is allowed but FORWARD is not. The latter rule protects all the LAN clients.
- ServerIP attack - immunited by GL.iNET firmware 4.4.6 onwards
The core idea is that the adversary spoofs the IP address of the VPN server.
Moreover, the victim will add a routing rule so that all traffic to 1.2.3.4 is sent outside the VPN tunnel.
From firmware 4.4.6, GL.iNET firmware doesnât maintain a direct route to VPN server.
We had fw mark to avoid route loop, so the traffic to the server is also through the tunnel except for the 1194/51280 traffic.
3 Likes