Kill switch?

Got a problem with Viscosity or need help? Ask here!

gooey

Posts: 4
Joined: Fri Nov 03, 2017 12:31 am

Post by gooey » Mon Jan 28, 2019 11:35 am
Hi,

I recently had Viscosity unexpectedly disconnect from my VPN and so my IP address was exposed, which is not a good thing. Obviously, I'd like to prevent this from happening again in the future.

I found this thread from 2015, where Eric says a kill switch is in the making.

viewtopic.php?f=9&t=1778

Is there any news on this?

I am also aware that there is a script solution to prevent network leaks:

https://www.sparklabs.com/support/kb/ar ... fic-leaks/

Unfortunately, this isn't really useful for me, as I only use Viscosity occasionally. I would need something that only kicks in when the network connection drops, but not when I terminate it manually.

Last but not least, I am posting log from when I was disconnected. No idea if "no usable connection profiles" points at a problem with the VPN or something with Viscosity, but if its the latter, maybe it hints at some software bug that can be fixed. Thanks!

Jan 24 23:38:07: Status changed to connected
Jan 25 00:24:24: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #392846 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jan 25 00:24:24: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #392847 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jan 25 00:24:24: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #392848 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jan 25 00:24:24: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #392849 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jan 25 00:24:24: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #392850 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jan 25 00:26:55: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #575096 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jan 25 04:22:27: [VPN] Inactivity timeout (--ping-restart), restarting
Jan 25 04:22:27: SIGUSR1[soft,ping-restart] received, process restarting
Jan 25 04:22:27: Status changed to connecting
Jan 25 04:22:28: Checking remote host "***vpn.com" is reachable...
Jan 25 04:22:37: Checking remote host "***vpn.com" is reachable...
Jan 25 04:22:46: No usable connection profiles are present
Jan 25 04:22:46: Exiting due to fatal error
Jan 25 04:22:46: Exiting due to fatal error
Jan 25 04:22:46: Status changed to disconnected

Eric

User avatar
Posts: 969
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Tue Jan 29, 2019 6:58 pm
Hi gooey,

A kill switch like feature is still on our list, I'm afraid it hasn't been the highest priority as we don't get that much feedback about implementing it, especially with scripting support available. Alternatively, you can also add rules to Windows Firewall to only allow certain applications to send traffic through the network interface for your VPN connection as the network interface is persistent between connections.

In regards to your dropout, as you're using Full DNS, there are no DNS servers to resolve the hostname when a dropout occurs. To work around this, edit your connection and go to Options, here tick Persist Remote IP. This will reuse the same IP address you initially connected with instead of trying to resolve the address again. It will also mean that the VPN adapter will be kept alive so traffic shouldn't leak if you get this type of dropout again.

We do plan to handle this scenario better in a future update though.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

gooey

Posts: 4
Joined: Fri Nov 03, 2017 12:31 am

Post by gooey » Sun Feb 03, 2019 11:03 pm
Thanks for the reply. Like I said, since I don't use Viscosity 24/7, the script or permanent changes to my Firewall rules don't really seem like valid options.

Also, with my connection, Persist Remote IP was already checked - unfortunately, it didn't keep those problems from happening.

Aybee

Posts: 8
Joined: Sun Apr 12, 2020 7:21 am

Post by Aybee » Sun Apr 12, 2020 5:58 pm
Is there something new for the killswitch? The topic had already been raised in 2015 and still nothing 5 years later?

Why don't you install a function that deactivates the network and reactivates it when you connect?

This works wonderfully with AirVPN (EDDY)

Without a killswitch, the whole VPN won't work if the connection from the VPN is gone and the real IP is shown.

Eric

User avatar
Posts: 969
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Tue Apr 14, 2020 2:23 pm
Hi Aybee,

This is still something we'd like to do, however doing it properly is a far more complex task for us than simply enabling and disabling adapters. We have some documentation here using Viscosity's scripting system though that can achieve exactly this if you'd like to take a look - https://sparklabs.com/support/kb/articl ... ect-occurs

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

Aybee

Posts: 8
Joined: Sun Apr 12, 2020 7:21 am

Post by Aybee » Thu Apr 16, 2020 6:48 am
Such a script is not really an option as you describe it.

When the PC shuts down, Viscosity does not terminate the connection with the script. That means if the PC can start up again until Viscosity Connects some programs connect and you already have a leak.

I can understand that it is not easy, but this function has been wanted since 2015 and is actually an absolute must have function.

Eric

User avatar
Posts: 969
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Thu Apr 16, 2020 12:01 pm
Hi Aybee,

Unless your PC is setup to ignore services and applications shutting down gracefully, these scripts should still be run when the PC is shut down. The exception to this is if you forcefully shutdown/power off or bluescreen, of which case a kill script/switch will never work, I'd recommend looking at a firewall instead.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
7 posts Page 1 of 1