VPN client - Kill switch IPs from all clients is applied to any active client, not only the client they are entered into.

Issue #324 wontfix
Sam created an issue

My use case. I have VPN client #1 and #2 populated with different server(s) info.
This makes it easy to switch servers if one is down.
I do not always have the same IPs listed in the kill switch area of client #1 and #2.

For this example lets say I have Client #1 kill switch listing 192.168.1.10 and 192.168.1.11, and 192.168.1.200. Client #2 has 192.168.1.10, 192.168.1.11, and 192.168.1.100.

I do not use client #1 and #2 at the same time.

If client #1 or #2 is enabled all the IPs from client #1 and #2 are loaded into the routing table.
The issue is that if Client #1 is enabled it does not have IP 192.168.1.100. This causes 192.168.1.100 to be subject to the kill switch, and can not get access to the internet.
The same thing happens if I enable Client #2. Because 192.168.1.200 is not in Client #2's IP lists it is subject to the kill switch and can not access the internet.

These are the lines I see in the log that back up my observation after I enabled Client #2. It shows both Client#1 and #2 rules being added.

Feb 27 18:30:23 user notice openvpn-vpnrouting.sh[28237][tun12] Starting routing policy for openvpn-client2 - Interface tun12 - Table 2560

Feb 27 18:30:24 user info preinit[1] Kill-Switch: added 3 rules to firewall for openvpn-client1

Feb 27 18:30:25 user info preinit[1] Kill-Switch: added 3 rules to firewall for openvpn-client2

I spent days trying to figure out why one of my static IPs could not get out to the internet. In my case the IP was added to Client #2's kill switch list, but I had Client #1 active (without that IP in the kill switch list) at the time.

I have not tested using all three clients at the same time, but I wouldn't be surprised if the issue was there too.

I would speculate that there needs to be a line of code to check which client(s) are active, and add only those rules to the firewall.
Someone might populate #1,#2,and #3, but have only #1 and #3 active. In that case you wouldn't want the info from #2 loaded into the firewall rules. Any combination of the 3 clients could exist.

Comments (2)

  1. pedro repo owner

    The OVPN Kill Switch is designed to be "strict" so there is nothing to fix here. If you want a "relaxed" version of Kill Switch where LAN clients can connect to the WAN when the OVPN client is down/disabled, you can always code it and add a PR.

  2. Sam reporter

    I am all about strict implementation of a kill switch, but how is a end user suppose to know that the kill switch IPs listed under client 2 or 3 will be implemented by client number one when client number 2 or 3 are not enabled?

    If you want to have a single universal kill switch enabled by all three clients would you consider adding some text indicating that? I would have never expected that the kill switch IPs of a of one client would be used in the kill switch of a separate client if the client was disabled. After all, none of the other settings from one client are used by any of the other clients. They don’t share certs, keys, or other custom settings. Why would the end user expect the kill switch settings to be different than any of the other client settings without some kind of warning?

  3. Log in to comment