Set inactive timeout

[dav3r]

Configure OpenVPN client connections to exit after a specified amount of time being inactive.

For details, see: https://www.sparklabs.com/support/kb/article/advanced-configuration-commands/#inactive and https://www.sparklabs.com/support/kb/article/advanced-configuration-commands/#push

[felddy]

I've test this with a client side configuration and was able to get a disconnect after inactivity. The next step is to test pushing this from the server.

2020-04-01 12:46:37: State changed to Authenticating
2020-04-01 12:46:42: [vpn.staging.cool.cyber.dhs.gov] Peer Connection Initiated with [AF_INET]3.226.239.92:1194
2020-04-01 12:46:42: Opened utun device utun11
2020-04-01 12:46:42: /sbin/ifconfig utun11 delete
2020-04-01 12:46:42: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-04-01 12:46:42: /sbin/ifconfig utun11 10.128.248.2 10.128.248.2 netmask 255.255.248.0 mtu 1500 up
2020-04-01 12:46:42: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-04-01 12:46:42: Initialization Sequence Completed
2020-04-01 12:46:42: DNS mode set to Split
2020-04-01 12:46:42: State changed to Connected
2020-04-01 12:47:02: Inactivity timeout (--inactive), exiting
2020-04-01 12:47:02: SIGTERM received, sending exit notification to peer
2020-04-01 12:47:03: SIGTERM[soft,exit-with-notification] received, process exiting
2020-04-01 12:47:03: State changed to Disconnected```

[felddy]

I was able to successfully push timeouts from the server to the client. I will be adding the following content to the openvpn config in the ansible, and terraform/cloudinit:

# The inactivity directive causes OpenVPN to exit after n seconds of inactivity
# on the TUN/TAP device. The time length of inactivity is measured since the
# last incoming or outgoing tunnel packet. The default value is 0 seconds, which
# disables this feature.  If the optional bytes parameter is included, exit if
# less than bytes of combined in/out traffic are produced on the tun/tap device
# in n seconds. In any case, OpenVPN’s internal ping packets (which are just
# keepalives) and TLS control packets are not considered “activity”, nor are
# they counted as traffic, as they are used internally by OpenVPN and are not an
# indication of actual user activity.

push "inactive 3600"

[felddy]

Issue moved to cisagov/openvpn-server-tf-module #22 via ZenHub