Forum Replies Created
-
Posts
-
Hmm, it might be beneficial for you to consider utilizing the command line version of the WireSock VPN Client. This allows you the flexibility to start or stop the client either as a standalone application or as a service, directly from a PowerShell script.
Yes, you’re absolutely correct. The SOCKS5 proxy should indeed be remote, preferably residing on the same machine as the VPN server. This configuration ensures it is beyond the DPI (Deep Packet Inspection), thus facilitating pass-through.
Apologies for the oversight in our documentation update. The new log location is
C:\ProgramData\NT KERNEL\WireSock VPN Client. PCAP files are saved either to the working directory or within Windows\System32 when operating as a service.Thank you for your diligent efforts in troubleshooting the issue. I greatly appreciate your time and your willingness to try out different steps to diagnose the problem.
In order to assist us with a deeper analysis, I recommend starting the console version of the Wiresock client. Please use the “-log-level all” argument to collect detailed logs and capture network traffic during the times when the connection drops, which could shed light on what may be causing these disruptions.
Thank you once again for your cooperation.
Wiresock VPN Client implements this feature via additional parameters:
- Socks5Proxy – specifies SOCKS5 proxy endpoint, e.g. Socks5Proxy = socks5.sshvpn.me:1080 or Socks5Proxy = 13.134.12.31:1080
- Socks5ProxyUsername – specifies SOCKS5 username (optional)
- Socks5ProxyPassword – specifies SOCKS5 password (optional)
Wiresock operates by establishing a connection to the indicated SOCKS5 proxy. This involves associating a UDP endpoint and transmitting handshake packets through the SOCKS5 UDP tunnel. The handshake response emerges from the same tunnel. However, all subsequent data traffic is routed directly to the intended WireGuard endpoint.
Although the methodology is quite straightforward, it adds a layer of complexity to the WireGuard handshake and response process, making it more challenging to detect and subsequently block the tunnel.
Currently, that option is not available. However, I’m interested in understanding your perspective. Could you please share why you believe this feature would be beneficial?
Well, I’m afraid, it could prove to be somewhat complex and time-consuming. This would require you to install Visual Studio, clone the WiresockUI repository, and build the debug version of it. Next, you would need to run WiresockUI under Visual Studio debugger and use it until you encounter a hang. Subsequently, you would be required to examine the state of the application to identify the problem. The sequence of these actions could be intricate and demanding, so please consider your willingness to commit to this task carefully.
It’s feasible to adjust the initial settings for the network driver, a setup that would halt all inbound and outbound network traffic until the VPN client becomes active. This strategy, however, could have extensive repercussions on the overall system functionality, possibly obstructing even DHCP operations.
In light of this, I am considering developing a buddy Windows Service as an alternative. This service would be programmed to initialize with the system startup and manage network traffic in a more selective manner, permitting only certain types of traffic based on a pre-established rule set (e.g. allow DHCP/DNS or/and allow all for selected network interfaces).
Without explicit approval from this service, any other traffic would be strictly denied unless it’s funneled through the VPN client. There, the traffic would be processed according to the configuration settings of the Wireguard VPN, ensuring secure and efficient handling of network operations.
The most effective strategy to tackle this issue requires reproducing it under the examination of a debugger. I’m committed to attempting to replicate the situation this coming weekend. Could you please describe your typical use scenario with the VPN?
Thank you for the update. While I can’t state with certainty, it’s highly probable that the issue was related to MTU. I would recommend upgrading to version v1.2.26, as v1.2.25 has a known issue with the process context resolution feature for IPv6.
Is this a limitation by WireSock itself? or is it only the UI? is there a fix for this?
Thank you for your kind words. Currently, Wiresock does not support multiple tunnels. Nevertheless, this is not a fundamental constraint, and I am contemplating the inclusion of this feature in the future. Please understand that due to my limited capacity to dedicate time to this project, I’m unable to offer a precise timeline for this enhancement.
Thank you for bringing this matter to our attention. Unfortunately, the process of identifying and resolving issues of this nature can prove to be challenging, particularly when their replication is inconsistent. Regardless, I assure you that I will try allocating time to investigate and address this issue.
There could potentially be an issue related to address conflict. Could you please provide the subnets for both your Local Area Network (LAN) and Wireguard?
I sincerely apologize for not being able to take on this task sooner. Due to a considerable workload in the past few weeks, I was primarily focused on resolving bugs. However, I’m optimistic about finding time this upcoming weekend to address this matter. Thank you for your understanding and patience.
