Hey @zach can you give us some more input from your side?
The version you recommended is working so far, but we do not want to stay on this version forever, therefore we need a fix for the current and future versions regarding this issue.
I have been reviewing the code looking for issues but I haven’t found any problems or been able to reproduce the issue.
@zach So what is your idea then? We are paying for pritunl and we cant just stick to the old client version forever. Something is broken and it needs a fix
I’ve been running several configurations trying to reproduce the issue. I haven’t seen any other reports of the same issue. I think there is possibly some compatibility issues that started when WireGuard was bundled with the client but that started in v1.3.4051.36. If you have a working release after that it’s a different issue. Also have you tried installing v1.3.4099.99 to verify the issue still occurs and it wasn’t something else that fixed the issue?
Hey @zach you are sure, wireguard is bundled with pritunl? From what i can see, in the client ui aswell as the github repo, wireguard is only bundled with macos. Also i uninstalled wireguard and pritunl version v1.3.4026.10 and installed the newer v1.3.4099.99. So far its working, but from the logs i can see, that it is using openvpn (obviously, i do not have the wireguard button anymore) and openvpn had no problems from the beginning, other than latency and performance problems that come from openvpn and not from pritunl. But i will now try and install wireguard again and will try it again with wireguard, but i wanted to let you know that for now.
Ok, even with the newest version and wireguard installed, i keep getting random disconnects
I believe I found the cause, the rewritten connection code was not retrying on failed ping requests. When the code was refactored the retry was left out from service/profile/profile.go. If you still have the full Watch connection error with the stack trace I should be able to confirm this was the cause. I’ve added some additional code to retry for longer and on all errors except 400 responses which the server sends to instruct the client to disconnect. This will be included in the next release sometime in the next few weeks.
This would indicate your connection is unstable, if it is needing to retry pings every 5-10 minutes. You may want to relocate the server to a better location.
This is the service.logs file for my client that had a reconnect about 20 minutes ago
Yes that was the cause, it should be retrying on that error.
Do you happen to have a test build maybe that i could try to verify if this is really the problem?
There isn’t a test build and it may be a few weeks before the release is available. But it’s clear from the stack trace in the error. The retry in service/profile/profile.go was left out when the code was copied to the new connection code in service/connection/wg.go.
Hello!
In my country, pritunl began to be actively blocked and at some point I was forced to look for alternative solutions. Tell me, is it possible to enable obfuscation to bypass blocking? How to do it?
Thanks in advance