Need guinea pigs for -K/--prevent-idle-timeouts about vpn-slice HOT 5 CLOSED

I'd be happy to test, but I receive the following error when I add in "--prevent-idle-timeout" with vpn-slice 0.11 on Ubuntu 18.04.3:

Traceback (most recent call last):
  File "/usr/local/bin/vpn-slice", line 10, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.6/dist-packages/vpn_slice/__main__.py", line 451, in main
    do_post_connect(env, args)
  File "/usr/local/lib/python3.6/dist-packages/vpn_slice/__main__.py", line 241, in do_post_connect
    if args.verbose > 1:
TypeError: '>' not supported between instances of 'NoneType' and 'int'

from vpn-slice.

Thanks @soaringswine. I just fixed a dumb mistake that was causing this, in 2269a4a.

from vpn-slice.

I definitely think I fall into category 2 as I received this: Received server disconnect: b0 'Max time exceeded'

which is definitely an improvement from getting kicked off for idle time, so it looks like the idle preventer works!!

from vpn-slice.

Ok, historically the VPN I connect to kicks me off after 20 or something hours even when running a ping to something on the VPN subnet.. I've just connected now and will see if I get kicked off. it's entirely possible I reach a max time exceeded or something instead of an idle timeout so this new option may not make a difference.

from vpn-slice.

@soaringswine, let me know if it makes any difference.

Most VPNs (certainly at least GlobalProtect, and I think AnyConnect too) differentiate between…

1. A disconnect-if-idle time: the VPN gateway will drop the connection (and invalidate the session authentication cookie) if there's no “real” traffic after that period of time. What vpn-slice -K tries to do is generate some “real-looking” traffic (not entirely repetitive, but low volume) to prevent such a drop.
2. A total session lifetime: the VPN gateway will drop the connection and invalidate the session authentication cookie after this period of time, no matter what. Client software can't do anything about this.
3. (possibly) A key lifetime: the VPN will need to be re-keyed with new encryption keys (for ESP, TLS, DTLS, etc.) after a certain period of time. Fully-implemented client software should handle this automatically; OpenConnect does for AnyConnect, GlobalProtect, and Juniper NC at least.

If your 20-hour limit is indeed caused by the disconnect-if-idle time, and not the total session lifetime, then it should do the trick. 🤞

from vpn-slice.