Page 1 of 1

Reconnect doesn't require Google Authenticator code

Posted: Fri Sep 13, 2019 3:44 pm
by bdolman
I just setup an Access Server instance (v2.7.5) and am using the OpenVPN Connect client for Mac (v 3.0.2). I have the VPN configured to require Google Authenticator codes and when I initially connect I do get the prompt as expected. What's strange though, is that if I close my laptop, drive home, and open it back up, it reconnects to the VPN without asking me for a Google Authenticator code. Same thing when I close my computer for the night, then drive into work the next morning. Why is the server allowing a reconnect without requiring a Google Authenticator code? I do not have auto login profiles enabled.

Note that if I manually disconnect and reconnect it does ask me for the code.

Also note that other VPN clients (such as Tunnelblick) do require the code on reconnect. It seems to only be when using the OpenVPN Connect Client. But the important question is why the server even allows that behavior.

Re: Reconnect doesn't require Google Authenticator code

Posted: Fri Sep 13, 2019 8:20 pm
by novaflash
Most likely because of the use of session tokens which are by default valid for a day. You don't want this behavior? You want to reauthenticate for any interruption?

Re: Reconnect doesn't require Google Authenticator code

Posted: Fri Sep 13, 2019 11:13 pm
by bdolman
To be clear, I like the idea of not having to type in that code for every reconnect, but I want to understand the security behind it and make sure that it's not somehow just ignoring the requirement for Google Authenticator tokens. I thought that perhaps it was due to session tokens but I read this on the page ( ... t-options/) about session tokens:

"The session token is locked to the client IP address of the successful authentication (cannot be used from another IP)"

But I've been moving between IP addresses (three different locations today) and did not have to type in an auth code when it reconnected on a different IP (I've verified in the logs that they were different IPs). I've also seen in that doc the ability to disable the client IP lock on a session token, but I haven't changed that value. Here's my current server config obtained by running "./sacli ConfigQuery"

Code: Select all

  "admin_ui.https.ip_address": "all", 
  "admin_ui.https.port": "943", 
  "aui.eula_version": "2", 
  "": "My LDAP servers", 
  "auth.ldap.0.ssl_verify": "internal", 
  "auth.ldap.0.timeout": "4", 
  "auth.ldap.0.use_ssl": "never", 
  "auth.module.type": "local", 
  "auth.pam.0.service": "openvpnas", 
  "auth.radius.0.acct_enable": "false", 
  "": "My Radius servers", 
  "cs.admin_only": "false", 
  "cs.cws_proto_v2": "true", 
  "": "true", 
  "cs.cws_ui_offer.autologin": "true", 
  "cs.cws_ui_offer.ios": "true", 
  "cs.cws_ui_offer.linux": "true", 
  "cs.cws_ui_offer.mac": "true", 
  "cs.cws_ui_offer.server_locked": "false", 
  "cs.cws_ui_offer.user_locked": "true", 
  "": "true", 
  "cs.https.ip_address": "all", 
  "cs.https.port": "943", 
  "cs.prof_sign_web": "true", 
  "cs.ssl_method": "SSLv3", 
  "cs.tls_version_min": "1.1", 
  "": "<redacted>", 
  "sa.compression_warning_shown": "displayed", 
  "sa.initial_run_groups.0": "web_group", 
  "sa.initial_run_groups.1": "openvpn_group", 
  "vpn.client.basic": "false", 
  "vpn.client.cipher": "AES-256-CBC", 
  "vpn.client.config_text": "", 
  "vpn.client.routing.inter_client": "false", 
  "vpn.client.routing.reroute_dns": "false", 
  "vpn.client.routing.reroute_gw": "false", 
  "vpn.client.routing.superuser_c2c_access": "false", 
  "vpn.daemon.0.client.netmask_bits": "20", 
  "": "", 
  "vpn.daemon.0.listen.ip_address": "all", 
  "vpn.daemon.0.listen.port": "443", 
  "vpn.daemon.0.listen.protocol": "tcp", 
  "vpn.daemon.0.server.ip_address": "all", 
  "vpn.general.osi_layer": "3", 
  "vpn.server.cipher": "AES-256-CBC", 
  "vpn.server.config_text": "", 
  "vpn.server.daemon.enable": "true", 
  "vpn.server.daemon.tcp.n_daemons": "1", 
  "vpn.server.daemon.tcp.port": "443", 
  "vpn.server.daemon.udp.n_daemons": "1", 
  "vpn.server.daemon.udp.port": "1194", 
  "vpn.server.duplicate_cn": "true", 
  "vpn.server.google_auth.enable": "true", 
  "vpn.server.group_pool.0": "", 
  "vpn.server.port_share.enable": "true", 
  "vpn.server.port_share.ip_address": "", 
  "vpn.server.port_share.port": "1234", 
  "vpn.server.port_share.service": "admin+client", 
  "vpn.server.routing.private_access": "nat", 
  "vpn.server.routing.private_network.0": "", 
  "vpn.server.tls_auth": "true", 
  "vpn.server.tls_version_min": "1.2", 
  "vpn.tls_refresh.do_reauth": "true", 
  "vpn.tls_refresh.interval": "360", 
  "xmlrpc.relay_level": "1"

I don't see any entry for "vpn.server.session_ip_lock" so I assume it's using the default (which the docs say is "true" by default).

There's also the question of why the 5 minute session token inactivity timeout doesn't kick in. According to the docs, "if the connection drops offline for longer than 5 minutes, then your session token will be considered unused as there is no active OpenVPN tunnel using that token, and so the session token has become invalid, and the user must reauthenticate."

But the behavior I'm seeing is that I close my laptop, drive for 30 mins to a different location with a different network, open it up and it happily reconnects without asking me for another Authenticator code. The docs explicitly call out this case too:

"For example if you log on at the office, put your laptop to sleep mode, and then take your laptop home and open it up again, the Internet connection and thus the public IP address will be different, and then it cannot use the session token to automatically get you connected again. Aside from having to alter the inactivity timeout to make such a scenario possible, you would also have to remove the IP lock on the session tokens. "

But this is most definitely not the behavior I am seeing.

Re: Reconnect doesn't require Google Authenticator code

Posted: Sat Sep 14, 2019 10:52 am
by novaflash
Well the client is in beta so it's possible something there is behaving not exactly as it was before with the old client. We'll take this report as an opportunity to look into this when we can. At the moment though it is clear that when you connect you need to enter google authenticator code so that part at least is working entirely as expected.