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.