Opened 6 years ago

Last modified 7 months ago

#815 new Feature Wish

UUID via environment for each session

Reported by: Eric Crist Owned by: David Sommerseth
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: scripting, status



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

UserSourcePrivate AddressReceivedSentStartEnd
jdoe44. 08:00:00 --
jdoe44. 08:03:00 2017-01-04 08:05:01
jdoe172.78.31.13410.0.8.396935723857672017-01-04 09:19:44 --

Change History (6)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by 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).

comment:5 Changed 6 years ago by 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

comment:6 Changed 7 months ago by 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?

Note: See TracTickets for help on using tickets.