Post by Scott CrooksGreetings,
I was reading this documentation
(https://community.openvpn.net/openvpn/wiki/SWEET32) in order to
determine how one would go about writing an auth-user-pass-verify script
to account for using 2FA with OpenVPN. The new `auth-gen-token` works
nicely for renegotiation every hour (reneg-sec 3600), but we're wanting
to devise an `auth-user-pass-verify` script that, ideally, can know the
- When a user connects for the first time, and
- When a user gets accidentally disconnected, and is trying to reconnect.
So what you basically need is a few more scripts. The
--auth-uesr-pass-verify is the place to do the user/password
authentication. This script needs to save a state outside itself. This
state needs to be identifiable per connecting/connected client and needs
to contain a unique auth-token.
When a client does a renegotiation and have received the auth-token,
your auth-user-pass-verify script needs to check the client state and
retrieve the token if it exists. In this case the auth-script does the
authentication against the token; otherwise it needs to pass the
authentication further to whatever authentication back-end you are
integrating against. If auth-token authentication failures should cause
a failure or try the auth-backend before concluding is up to you and
what kind of policies you want to have. But if there is a mismatch
between the user provided password (which may contain either the users
password or an authentication token), that might be an indication if the
client was restarted or just reconnected.
This state file needs also to be accessible by the --client-conncect
script. This script is the place where you can generate dynamic
configurations for clients, somewhat similar to --client-config-dir but
much more flexible as it can generate the ccd config on-the-fly
according to the state. So the script needs to pick up the auth-token
generated by the auth-user-pass-verify script and put a 'push auth-token
$TOKENVALUE' into the file name provided to the
--client-connect script.
But there are also a few other places to gather information about
clients state. The --client-disconnect script is called when either the
client tells the server it is closing the connection (with UDP, you need
--explicit-exit-notify in the client config) ... or when the OpenVPN
server considers the connection lost and it disconnects the session
internally.
And you might find --learn-address valuable in some cases too.
To write scripts with client state handling across the various phases of
a client connection can be fairly tricky. In these cases writing a
plug-in can be somewhat easier to these challenges, as the plug-in APIs
allows storing this information in memory between the various calls,
with the memory buffers used being unique for each client.
Post by Scott CrooksThe use case is because in our company, the Wi-Fi is a bit spotty from
room-to-room, and walking over to another part of the building results
in disconnects.
How does the OpenVPN server know the difference between these two (if at
all)?
OpenVPN doesn't know why a client disconnects an established connection.
But "disconnect" can mean a few different things. It can be "OpenVPN
client disconnects from the OpenVPN server" ... or the local network
connection got disconnected. Or a combination, due to computer shutting
down or suspends.
OpenVPN does however not give up on a connection too easily if the local
network layer fails. As long as the OpenVPN client doesn't stop running
when the local network layer fails, the computer can even get a new IP
address and the OpenVPN server will in most cases accept that (that's
the newer peer-id support, enabled by default). AFAIR, there are no
script hooks which catches this state.
In other cases, that mostly causes a re-negotiation or a hard reset
which means re-establishing of the connection. Re-negotiation are
usually identifiable that the --client-disconnect script have not been
executed. On hard-resets, --client-disconnect and --learn-address
scripts will be run.
I hope this gets you some ideas at least.
--
kind regards,
David Sommerseth