In light of the recent TunnelVision vulnerability I wanted to share a simple firewall that I wrote for wireguard VPNs.

https://codeberg.org/xabadak/wg-lockdown

If you use a fancy official VPN client from Mullvad, PIA, etc, you won’t need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad). This is if you use a barebones wireguard VPN like me, or if your VPN client has a poorly-designed kill switch (like NordVPN, more info here).

A firewall should mitigate the vulnerability, though it does create a side-channel that can be exploited in extremely unlikely circumstances, so a better solution would be to use network namespaces (more info here). Unfortunately I’m a noob and I couldn’t find any scripts or tools to do it that way.

  • delirious_owl@discuss.online
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    6 months ago

    You’re still right in 99% of all use cases.

    Nobody operates VPNs for privacy in split tunnel. So everyone running Linux that would be concerned about this is unaffected.

      • progandy@feddit.de
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        6 months ago

        A separate routing table that takes precedence over the one modified by DHCP should works as well I think. Oh, and of course you have to use a vpn that forces its own nameserver or set one manually to prevent redirections.

      • delirious_owl@discuss.online
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        It doesn’t apply to Linux unless you do split tunnel, which no commercial VPN configs use, because it doesn’t make sense to

        • xabadak@lemmings.worldOP
          link
          fedilink
          arrow-up
          1
          ·
          6 months ago

          why is a split tunnel relevant? I thought all VPNs are vulnerable unless they use a firewall like I do, or network namespaces.

          At least the way I understand it, a normal VPN redirects your internet traffic to instead go through a virtual network interface, which then encrypts and sends your traffic through the VPN. This attack uses a malicious DHCP server to inject routes into your system, redirecting traffic to the attacker instead of towards the virtual network interface.