- This topic has 17 replies, 2 voices, and was last updated 1 year ago by
.
-
Posts
-
The location of WireSock logs depends on the mode in which WireSock is operated. When running as a service, logs are stored at C:\ProgramData\NT KERNEL\WireSock VPN Client. For console application mode, logging happens directly in the console. In the case of WireSockUI, logs are only accessible in the specific tab where you attached your screenshot.
From the screenshot you’ve provided, it seems the Wireguard handshake isn’t being acknowledged, causing the tunnel to attempt restarts and continuously send new handshakes. Notably, if your VPN provider’s app connects without issue, it’s important to mention that VPN providers often use the reserved fields of the Wireguard protocol for specific purposes. Cloudflare, for instance, does this but still supports the standard Wireguard client. Without detailed information about your VPN provider, I cannot discount the possibility that they might be using similar techniques or subtly nudging users towards their own client software.
Hi Vadim!
I just contacted AirVPN support. They told me that they do not implement any kind of Wireguard customized solution, since compatibility was important to them.
And they also said this!
We can gladly provide information to WireSock developer to look into the issue. Even better, we can prepare an account to let him/her access our service and investigate the issue directly.
I thought that was really neat 🙂
My own issues with Wiresock only arise when it’s under very high stress when torrenting. Then, all connections fail, even those outside of the tunnel. This timing it a lil more complicated to troubleshoot.
Anyways, I hope this can work out! I understand if you’re busy and would want to take some time before taking on the endeavour.
Thank you for the update. The logs you provided clearly indicate that there’s no response from the WireGuard server, suggesting that the issue might stem from the VPN server itself. This lack of response could be unintentional, possibly due to the server being unable to handle the workload. It’s also possible that the native client is designed to switch to another server in such scenarios. Following your report, I conducted tests by downloading large files using qBittorrent, but I didn’t encounter the same issue. It’s worth noting, however, that I used my own VPN server for these tests. To further investigate, it might be helpful to increase the number of torrents and observe any changes.
Could you share your configuration details (excluding any keys)? Based on the logs, it seems you’re using a virtual adapter mode. I’m curious to know if this issue also occurs in adapterless mode.
- You must be logged in to reply to this topic.