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 (
https://openvpn.net/vpn-server-resource ... 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",
"auth.ldap.0.name": "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",
"auth.radius.0.name": "My Radius servers",
"cs.admin_only": "false",
"cs.cws_proto_v2": "true",
"cs.cws_ui_offer.android": "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",
"cs.cws_ui_offer.win": "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",
"host.name": "<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.client.network": "172.27.224.0",
"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": "172.27.240.0/20",
"vpn.server.port_share.enable": "true",
"vpn.server.port_share.ip_address": "1.2.3.4",
"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": "172.31.0.0/16",
"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.