after successful sso authentication the pritunl-client try to send a http post request to pritunl, but it does not use the proxy address anymore. instead it try to connect to the vpn host ip. thats why it run into a timeout. also older client versions does it wrong since a week (since sso re-authentication was required). at least this happen on two linux (debian and ubuntu) workstations until now. there was not much changes on server and client site. just regular system updates except pritunl itself. and no config changes so far. i tried updating than, but no changes. now i am on latest stable versions on server and client. reconfiguring the sync-adrress doesnt help as well. at least this change is recognized by the client - so config sync somehow works. so i run out of ideas what could be the problem. i am currently unable to connect with both ovpn and wireguard. the failing post request looks like this: https:///key/ovpn/66d9c518a90abc3869732e66/66d9c522a90abc5669732e79/66d9cf18a90abc56697334a
i am thankfull for any kind of help.
Below are all the addresses and how to configure them. These may need to be adjusted for that configuration, specifically the Connection Single Sign-On Domain. Connection single sign-on is not required it can be disabled in the server settings by unchecking Single Sign-On Authentication.
Hosts Tab
Host Public Address: The public IPv4 address or domain of the Pritunl host. This should always be the public IP of the host for all configurations even when using a load balancer.
Host Public IPv6 Address: The public IPv6 address or domain of the Pritunl host. This should always be the public IP of the host for all configurations even when using a load balancer.
Host Sync Address: In the advanced host settings. The public address or domain that the web server of the Pritunl servers can be accessed from. If a load balancer is configured that address should be set here.
Top Right Settings
Connection Single Sign-On Domain: Only shown when using single sign-on connection authentication. The public address or domain that is used to validate single sign-on requests through the Pritunl web server for a new VPN connection. If a load balancer is configured that address should be set here.
thank you for your answer.
that was everything set up in the right way and wasnt change before. i changed it now and changed it back to force the settings to be saved (public address was correct auto-detected, but i set it explicit). no changed behavior. i am still unable to connect.
my colleagues seems to have no issues so far. maybe only linux clients are affected. i am wondering why also older versions did not work anymore which did before. affected systems on client side here are debian testing (trixie) and ubuntu noble; server is on ubuntu noble. because both openvpn and wireguard did not work it cant be related to openvpn or wireguard-tools updates.
what is that post request for which is failing? config updates seems to work through the proxy.
i could temporary allow https traffic to pritunl-node directly, but than the ssl cert wouldnt match.
was there code-changes in the last client releases which could cause proxy issues on linux?
A POST to /key/ovpn is a request for a OpenVPN connection with additional authentication or /key/wg for WireGuard connections. For OpenVPN connections it can be any combination of connection single-sign, device authentication or dynamic firewall. The request will always occur for any WireGuard configuration due to the temporary key design.
than this request happen all the time a user start a connection. so not maybe only when a sso re-auth is required. than i am pretty sure, that only the linux clients are affected, because my mac-colleagues have no issues to connect. is the linux client using beside from ovpn and wireguard-tools any other local tools, which maybe could have changed in debian based distributions? i assume code-wise the mac client is identical to the linux version, right?
That request happens before any usage of OpenVPN or WireGuard, those packages would have no effect. The request is sent from Golang code in the background service process.
hmm, new infos regarding this issue. on mac this specific request also timed out, but clients still able to connect (wireguard in this case). maybe this request is not the root cause of the connection issues.
is it possible that the client did not get feedback from browser, that sso login is done and it should proceed on linux? how this communication is working? than maybe a browser update is breaking the setup on linux. i see this issue with ff and chrome. cant drop sso auth easily to verify it.
The client background service creates a polling web request to the server then opens the browser. This is a POST to /key/ovpn_wait/<org_id>/<user_id>/<server_id> or /key/wg_wait/<org_id>/<user_id>/<server_id>. Once the authentication is completed in the browser the server completes the request from the client background service. There is no communication between the browser and client.
The key/ovpn or /key/wg is the initial request from the background service requesting to initiate an authentication sequence.