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: 866
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.
3 posts Page 1 of 1