UUID via environment for each session

[Eric Crist]

Problem

When writing scripts to parse the status log, there is no common unique identifier per OpenVPN client session. This makes tracking usage per-session difficult since we have no affirmative data that this is still the same VPN session when parsing a connection on update of the status file or --client-disconnect scripts.

Desired Feature

Expose a UUID or other unique identify that is static for the duration of a client session. This should be identical across re-keying operations or during --float changes. IDs should be unique per session so that simultaneous connections from the same CN would show as different sessions.

This allows for more accurate per-session tracking so that reports could be derived that show a detailed phone-bill type reporting could be generated. Without a unique ID, it may be difficult to determine when one session has ended and another has started. There are hints in the file, like remote address and process ID that can be used to help make a unique session indicator, but these are not foolproof.

Example Report

User	Source	Private Address	Received	Sent	Start	End
jdoe	44.44.44.2	10.0.8.2	49357	1687777	2017-01-04 08:00:00	--
jdoe	44.44.44.2	10.0.8.3	26777	29007	2017-01-04 08:03:00	2017-01-04 08:05:01
jdoe	172.78.31.134	10.0.8.3	969357	2385767	2017-01-04 09:19:44	--

[Selva Nair]

Sounds like the client id (CID) used in some management notifications like client-connect, bytecount notification etc. would be a good fit.

Anyway, accounting on the server would be much easier to do using the management interface than parsing the logs. For example, on the server bytecount notification is prefixed with the CID followed by bytes_in, bytes_out. The same client id is used in client-kill, client-auth etc and is unique per session. On rekeying, the key-id (KID) changes but CID remains the same.

[Eric Crist]

The status log and --client-disconnect scripts are specifically designed to catch ongoing and connection close statistics. The management interface is single threaded so does not allow for more than a single connection. This bars using it for other management tasks, like killing sessions.

[Selva Nair]

Not saying that a unique client id visible to scripts is not useful -- could be achieved using CID exported to the env.

What I have in mind is a UI for the server which can do client-auth and other client management.

[Gert Döring]

Exporting the client ID to the environment "should" not be complicated. Putting this in quotes because sometimes we hide stuff in structures that are not accessible where needed... (like, functions either having access to the client ID or to the environment set).

[Selva Nair]

In this particular case its easy:
In multi_client_connect_setenv() just add mi->context.c2.mda_context.cid to the env. And build without disabling MANAGEMENT or DEF_AUTH

[rgaufman]

Any solution for this? - I have a situation where client connects, for some reason it needs to connect again and then 2 minutes later original connection times out. It would be great to have a session ID as an ENV variable for --client-connect. Is there any solution for this?