level=error msg="authenticate: failed to save account data with error record already exists\n"

[schwichtgit]

Thank you for your work on this!

After initial struggle to get this working (as designed), I made some progress on

• openvpn-2.6.9-2.1.el7
• freeradius-utils-3.0.13-15.el7 (providing /usr/bin/radclient)

against a

• freeradius-3.0.21-40.el9_4
• openldap-servers-2.6.6-3.el9 (for auth)
• mariadb-10.5.22-1.el9_2 (SQL DB for accounting)

as I needed to enable class support on the freeradius side.
in ./sites-available/default

        #  Insert class attribute (with unique value) into response,
        #  aids matching auth and acct records, and protects against duplicate
        #  Acct-Session-Id. Note: Only works if the NAS has implemented
        #  RFC 2865 behaviour for the class attribute, AND if the NAS
        #  supports long Class attributes.  Many older or cheap NASes
        #  only support 16-octet Class attributes.
        insert_acct_class

it would be useful to check for empty class and write a log message hinting for that.
I should add that we use TLS client certificates plus ldap user/password validation as 2FA.
New (!) openvpn tunnel requests get processed as intended, auth works and the tunnel get established - great!

however after some time the TLS certificate gets renegotiated (as intended - (note the TLS: soft reset in the openvpn tunnel log below)) and openvpn re-runs the authentication.
and as we are still in the same session, the ovpn-radius client errors the session with

   level=error msg="authenticate: failed to save account data with error record already exists\n"

The tunnel log shows

2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 TLS: soft reset sec=3496/3496 bytes=10634000/-1 pkts=20710/0
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 VERIFY OK: depth=1, CN=vpn.acme.com
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 Validating certificate extended key usage
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 VERIFY EKU OK
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 VERIFY OK: depth=0, CN=myusername@acme.com
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_VER=2.6.9
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_PLAT=mac
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_TCPNL=1
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_MTU=1600
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_NCP=2
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_PROTO=990
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_LZ4=1
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_LZ4v2=1
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_LZO=1
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_COMP_STUB=1
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_COMP_STUBv2=1
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_GUI_VER="net.tunnelblick.tunnelblick_5971_4.0.1__build_5971)"
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 peer info: IV_SSO=webauth
2024-08-13 11:07:01 myusername@acme.com/1.2.3.4:63316 TLS Auth Error: Auth Username/Password verification failed for peer 

---

on a side note, I noticed that ovpn-radius uses random session ids.
as we invoke the ovpn-radius program on auth / start / update / stop
we do not properly fill the radius backend account db properly.
each call of ovpn-radius creates a new row.
it would be preferable to have one row for each session and proper start, last update, stop time stamps ...

---

minor:
please note the typo at

authenticate: Autentication(sic) using filepath