[Enhancement] Provide option for excluding virtualized interfaces from kill switch.

[c4f3a0ce]

It would to be great to be able to exclude virtualized interfaces from kill switch.

I am running a number of virtual machines on the host using VirtualBox and host-only interfaces. When I enable kill switch with allow access to/from LAN these guest are no longer reachable. It is also impossible to exclude these using split tunneling (#74).

[Rafficer]

If you can tell me how to properly detect, without errors, what a virtual interface is and what isn't, that could be done.

[c4f3a0ce]

Thank you. I will investigate that and provide an update.

One thing that bothers me is that network is killed despite being in a private range. Before enabling kill switch:

4: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.1/24 brd 192.168.56.255 scope global vboxnet0
       valid_lft forever preferred_lft forever

and after

4: vboxnet0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.1/24 brd 192.168.56.255 scope global vboxnet0
       valid_lft forever preferred_lft forever

Shouldn't it be excluded with allow access to/from LAN?

[Rafficer]

The way the exclude works is that it detects the network of your default interface and only excludes that. Excluding the full private ranges may cause issues.

Since it's a Kill Switch, excluding less is better.

[c4f3a0ce]

Thanks, that's really helpful.

Since it's a Kill Switch, excluding less is better.

I guess that makes sense. So effectively if I'd wanted to patch the process (assuming I won't find robust way to handle this in general case) I'd have to plug-in somewhere here:

https://github.com/ProtonVPN/protonvpn-cli-ng/blob/95701b0bd5b4785da254f35165c9db943b26b950/protonvpn_cli/connection.py#L838-L853

VirtualBox Python SDK hasn't been updated in years, but it should be possible to just capture output of vboxmange:

$ vboxmanage list hostonlyifs
Name:            vboxnet0
GUID:            786f6276-656e-4074-8000-0a0027000000
DHCP:            Disabled
IPAddress:       192.168.56.1
NetworkMask:     255.255.255.0
IPV6Address:     
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Wireless:        No
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-vboxnet0

and generate additional rules.

Do you think that such patch is to localized to be included upstream?

[Rafficer]

Only for VirtualBox with external non-standard tools? No, sorry. This would result in really inconsistent behavior.

"It excludes virtual interfaces, but only from VirtualBox, no other software, and only when it's properly listed by vboxmanage"

However, I will see if it's possible to let the user set a list of network interfaces to exclude and skip the part with auto detection. This would only be possible if it's possible to proper sanitize the input from a file.

[c4f3a0ce]

Only for VirtualBox with external non-standard tools? No, sorry. This would result in really inconsistent behavior.

Sure, I understand. I'd give the same answer.

However, I will see if it's possible to let the user set a list of network interfaces to exclude and skip the part with auto detection.

That be great. I initially thought that problem is somehow related to VirtualBox, but I see that now that the issue is more generic, and affects any setup with multiple local networks.

Thanks again for your time. Much appreciated.

[loopified]

Also a problem when connecting to local Docker containers.

[cbdejavu]

How about having a advanced configuration file for the kill switch? So basically the current auto-detect works for most situations, however if people are using virtual machines, or docker containers the kill switch breaks them. If a configuration file could be created to manually add additional networks "local" and immune to the kill switch it would allow those with more advanced configuration to still benefit from the kill switch while not making the overall protonvpn client overly complicated trying to "figure out all the possible local networks".

[marc0der]

@cbdejavu It would be super useful. That way we can explicitly provide a list of interfaces to exclude. @Rafficer would that be a doable option?

[Rafficer]

This could work. I also want to try an entirely different way of using the kill switch (route based instead of iptables based) and see if that'd fix it entirely.

[cbdejavu]

Any update or progress on this issue?

This is a huge deal for my workflow personally and I know for others. While I've been a subscriber since protonvpn launched the "linux as a back burner side thought" is getting old. I realize you have to target windows OS first because it is the largest market for individual users but from a business users standpoint that is becoming less and less true now days. I'm going to give Zoarial94 fork a try and see if it works otherwise without a solution next June I won't be renewing my sub and instead move on to another vpn solution that supports a working kill switch for docker containers/virtual machines in a linux environment as this really is a CRITICAL must have feature for a VPN service. Hopefully you will have wireguard working by then as well as that is the 2nd most important feature for my use as a VPN user, the fact that it is "on the horizon" would be enough to get me to stay however the kill switch is a deal breaker at this point.

Is there a reason Zorial94 fork isn't listed as one of the active pull requests at this time? When I go into pull requests right now only 7 are shown and Zorial94's isn't one of the 7.