You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
create an OpenVPN server in V2 using the /api/v2/vpn/openvpn/server endpoint. keep the "authmode" field set to the default value - ['Local Database'].
the following error is returned:
{
"code": 404,
"status": "not found",
"response_id": "FOREIGN_MODEL_FIELD_VALUE_NOT_FOUND",
"message": "Field `authmode` could not locate `authentication server` object with `name` set to `Local Database`",
"data": []
}
To try and examine the phenomenon further, I created a fictive radius server using the API v2/user/auth_server endpoint. I created it with the name "Local Database".
Afterwards, I tried creating the OpenVPN server, which worked this time. In practice, the code creates the tag "authserver" with the value "Local Database" in the pfSense configuration. But in practice, the OpenVPN ended up using the actual Local Database authmode, and not the fictive radius server I created!
In addition, when creating this fictive radius server, it doesn't exist in the GUI, probably because it has the same name as the original "Local Database". It is being created as an authserver in the pfsense config XML.
When creating another fictive radius server named "Local Database2", it does appear in the GUI and the pfsense config XML.
Expected behavior
The OpenVPN code will recognize the "Local Database" as an authmode
Root Cause
in the pfsense code
foreach ($authmodes as $authmode) {
$authcfg = auth_get_authserver($authmode);
if (!$authcfg && $authmode != "Local Database") {
continue;
}
the authentication server is inferred from the authentication mode. Also, the "Local Database" auth mode doesn't have authentication servers, for it stands by itself.
Currently, you are using the AuthServer model for the authmode value
$this->authmode = new ForeignModelField(
model_name: 'AuthServer',
model_field: 'name',
default: ['Local Database'],
many: true,
conditions: ['mode' => ['server_user', 'server_tls_user']],
help_text: 'The name of the authentication server to use as the authentication ' .
'backend for this OpenVPN server',
);
I suggest you make the same distinction in your code: create an AuthMode model that will have the same logic, and from its value reach the auth server.
Affected Endpoints:
/api/v2/vpn/openvpn/server
The text was updated successfully, but these errors were encountered:
The authmode field just needs its allowed_keywords property set to ['Local Database'] to recognize it as a valid option even if it's not an existing AuthServer object. I'll get patch out for this today.
To Reproduce
To try and examine the phenomenon further, I created a fictive radius server using the API v2/user/auth_server endpoint. I created it with the name "Local Database".
Afterwards, I tried creating the OpenVPN server, which worked this time. In practice, the code creates the tag "authserver" with the value "Local Database" in the pfSense configuration. But in practice, the OpenVPN ended up using the actual Local Database authmode, and not the fictive radius server I created!
In addition, when creating this fictive radius server, it doesn't exist in the GUI, probably because it has the same name as the original "Local Database". It is being created as an authserver in the pfsense config XML.
When creating another fictive radius server named "Local Database2", it does appear in the GUI and the pfsense config XML.
Expected behavior
The OpenVPN code will recognize the "Local Database" as an authmode
Root Cause
in the pfsense code
the authentication server is inferred from the authentication mode. Also, the "Local Database" auth mode doesn't have authentication servers, for it stands by itself.
Currently, you are using the AuthServer model for the authmode value
I suggest you make the same distinction in your code: create an AuthMode model that will have the same logic, and from its value reach the auth server.
Affected Endpoints:
/api/v2/vpn/openvpn/server
The text was updated successfully, but these errors were encountered: