Project

General

Profile

Actions

Bug #13243

open

OpenVPN status for multi-user VPN shows info icon to display RADIUS rules when there are none to display

Added by Jim Pingle 2 months ago. Updated about 2 months ago.

Status:
Pull Request Review
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
22.11
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

When a user authenticates to an OpenVPN instance the OpenVPN status shows an info "i" icon in the actions to display ACLs obtained from RADIUS, even if there are none to display.

Eventually the icon goes away, after ~1hr presumably when the client reauthenticates.

There is a file in /tmp for this user, /tmp/ovpn_ovpns5_jimp_54352.rules, and it's showing as 1 byte and that one byte appears to be a newline. There is probably some value not being trimmed or a missing check that should be skipping when the returned list is empty.

Actions #1

Updated by Reiner Keller about 2 months ago

Additional to this "informal" bug the ruleset given by Radius parameter isn't stored and when the renegiotion is done by parameter

--auth-gen-token [lifetime]
After successful user/password authentication, the OpenVPN server will with this option generate a temporary authentication token and push that to client. On the following renegotiations, the OpenVPN client will pass this token instead of the users password. On the server side the server will do the token authentication internally and it will NOT do any additional authentications against configured external user/password authentication mechanisms.

all routes and IP assignments are gone and initially pushed routes were actively removed by client.

Actions #2

Updated by Marcos M about 2 months ago

This fixes the original issue:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/821

Reiner Keller wrote in #note-1:

Additional to this "informal" bug the ruleset given by Radius parameter isn't stored and when the renegiotion is done by parameter
all routes and IP assignments are gone and initially pushed routes were actively removed by client.

Tested on 22.05.r.20220609.1919 with a Windows client.
I cannot reproduce this. I added auth-gen-token 60 to the server, and reneg-sec 25 to the client. After each reneg-sec interval, the client kept the static IP assignment from FreeRADIUS along with the pushed routes, and the server /tmp/*.rules file remained the same with the correct ciscoavpair rules. After the token expired, the client correctly re-connected and re-added the routes.

If you can re-create the issue, please open a new redmine issue report and provide exact steps to replicate the issue.

Actions #3

Updated by Marcos M about 2 months ago

  • Status changed from New to Pull Request Review
  • Assignee set to Marcos M
Actions #4

Updated by Jim Pingle about 2 months ago

  • Plus Target Version changed from 22.09 to 22.11
Actions

Also available in: Atom PDF