Forum Replies Created
-
Posts
-
Here is another test build. Please give it a try.
1. For ARM64 systems: Download WireSock VPN Client ARM64 Version 1.2.39.1
2. For 64-bit systems: Download WireSock VPN Client x64 Version 1.2.39.1
3. For 32-bit systems: Download WireSock VPN Client x86 Version 1.2.39.1P.S. It seems that you’re experiencing a type of NAT collision when the SOCKS protocol is passing through the NAT. I’ll take some time to think this through.
I’ve just realized that the IP addresses in the log entries are also inconsistent. The Wireguard server IP was wiped in the first log, and I initially missed it. Could you sketch out your network setup for me? Understanding your network configuration will help me figure out why the SOCKS proxy is behaving this way. Also, I’ll create a version of the build that doesn’t consider the source IP address and share it here for testing.
2024-03-03 07:02:56 [SOCKS5]: C2S_BEFORE: 192.168.1.156:63538 -> 100.222.101.186:13231
2024-03-03 07:02:56 [SOCKS5]: C2S_AFTER: 192.168.1.156:63538 -> 100.222.101.186:55564
2024-03-03 07:02:56 [SOCKS5]: S2C_BEFORE: 100.222.101.186:55564 -> 192.168.1.156:63538
2024-03-03 07:02:56 [SOCKS5]: S2C_AFTER: 100.2.3.111:63538 -> 192.168.1.156:63538I’ve developed a test build that omits the source port consideration when the SOCKS5 feature is enabled. To evaluate this build, kindly download the appropriate version from the links below and test it:
1. For ARM64 systems: Download WireSock VPN Client ARM64 Version 1.2.38.1
2. For 64-bit systems: Download WireSock VPN Client x64 Version 1.2.38.1
3. For 32-bit systems: Download WireSock VPN Client x86 Version 1.2.38.1Your feedback after trying out this version would be greatly appreciated.
Side note: If I configure proxy settings in any browser, I’m able to browse the internet without an issue.
When browsing the internet, most activities typically operate using the TCP protocol, making this point less relevant. Additionally, numerous UDP-based applications often overlook the source port value, thus remaining unaffected. However, an exception to this is WireSock, which verifies the source port to ensure it aligns with the Wireguard server endpoint. It’s also significant to note that UDP support was introduced exclusively in version 5 of the SOCKS protocol. Importantly, not all SOCKS5 proxies provide UDP support, and among those that do, the level of support can vary significantly.
Thank you for providing the log. It has greatly enhanced my understanding of the situation. Below is an example of how a log should appear when a handshake is conducted via a SOCKS5 proxy:
2024-03-03 09:44:29 [SOCKS5]: associate_to_socks5_proxy: USERNAME/PASSWORD authentication SUCCESS 2024-03-03 09:44:29 [SOCKS5]: associate_to_socks5_proxy: SOCKS5 ASSOCIATE SUCCESS port: 41205 2024-03-03 09:44:30 [SOCKS5]: C2S_BEFORE: 192.168.3.134 : 49666 -> 158.255.61.227 : 59876 2024-03-03 09:44:30 [SOCKS5]: C2S_AFTER: 192.168.3.134 : 49666 -> 158.101.212.135 : 41205 2024-03-03 09:44:30 [TUN]: Sent handshake packet to the WireGuard server at 158.255.51.217:59999 2024-03-03 09:44:30 [MGR]: Tunnel has started 2024-03-03 09:44:30 Wireguard tunnel has been started. 2024-03-03 09:44:30 [SOCKS5]: S2C_BEFORE: 158.101.212.135 : 41205 -> 192.168.3.134 : 49666 2024-03-03 09:44:30 [SOCKS5]: S2C_AFTER: 158.255.61.227 : 59876 -> 192.168.3.134 : 49666 2024-03-03 09:44:30 [TUN]: Handshake response received from 158.255.61.227 : 59876Please focus on the last three lines. Here, it’s indicated that the UDP packet was received from the SOCKS5 proxy at [158.101.212.135 : 41205]. The genuine IP address and port of the Wireguard server, which are retrieved from the SOCKS5 header [158.255.61.227 : 59876], are then applied to the packet. This process results in a successful Wireguard handshake response, accurately incorporating the source IP address and port.
Now, examining the corresponding lines in your log:
2024-02-26 17:21:19 [SOCKS5]: C2S_BEFORE: 192.168.1.166 : 63811 -> x.x.x.x : 13231 2024-02-26 17:21:19 [SOCKS5]: C2S_AFTER: 192.168.1.166 : 63811 -> x.x.x.x : 53186 2024-02-26 17:21:19 [SOCKS5]: S2C_BEFORE: x.x.x.x : 53186 -> 192.168.1.166 : 63811 2024-02-26 17:21:19 [SOCKS5]: S2C_AFTER: 70.104.137.21 : 63811 -> 192.168.1.166 : 63811Assuming 70.104.137.21 is your Wireguard server address, the last line should actually be:
2024-02-26 17:21:19 [SOCKS5]: S2C_AFTER: 70.104.137.21 : 13231 -> 192.168.1.166 : 63811It appears that the SOCKS5 header contains an incorrect source port. Consequently, the handshake response is not recognized, and the connection fails to establish. Technically, I could implement a workaround for this issue, but the behavior of your SOCKS5 proxy doesn’t seem right.
I suspect this might be a bug in the SOCKS5 proxy implementation. In my tests, I used Dante, which worked correctly. Do you know which SOCKS5 proxy implementation is being used in your case?
I’ve recently added a Cygwin demonstration, providing Makefile for building the static version of the NDISAPI library as well as several basic examples. Hope it helps!
I apologize for any earlier confusion. My advice is to start by building NDISAPI with Cygwin, which should streamline the process and address ABI compatibility issues. Although I haven’t personally built it using Cygwin, I consider it a viable option. The driver interface is well-documented, and the C++ code can be compiled using various Microsoft compilers, ranging from Visual C++ 6.0 to the latest Visual Studio 2022. Previously, I used C++ Builder for building it and it also worked just fine.
Regrettably, I haven’t had enough spare time to dedicate to implementing this feature. Nonetheless, I’ll certainly consider adding support for local addresses in the future. Thank you for bringing it to my attention.
Is there a document describing how to compile and run ndisapi or ndisapi based apps ( dnstrace etc. ) on Cygwin?
Unfortunately, no, and I haven’t attempted that myself. However, I believe it should be feasible to build NDISAPI with Cygwin or invoke the NDISAPI.DLL C interface from a Cygwin application. Thus, I’m somewhat puzzled by your error code. Kindly verify that you’ve compiled the code against the appropriate platform, ensuring, for instance, that you’re calling a 64-bit DLL from 64-bit code.
The log excerpt appears to be good. Could you supply some extra lines? It would also be helpful to review the generated pcap files.
Have you clicked “Save” after modifying the settings? Alternatively, you can start the WireSock client from the command line; it will print the log directly to the console.
Could you please try running WireSock with logging enabled and share the log? It may provide insights into what went wrong.
What method do you employ to measure throughput? Although it’s commonly acceptable to gauge bandwidth using Speedtest.net or Fast.com, relying solely on internet-based services for throughput testing may lack precision. For more accurate results, I suggest setting up another device within your network, ideally connected directly to your wireless router via cable. Configure this device to run iperf3 in server mode. Then, on your laptop, utilize iperf3 in client mode, conducting tests in both direct and reverse orders with a minimum of 8 simultaneous TCP sessions. This approach will yield more reliable and trustworthy results.
i guess that was a typo?
Yes, my fault. I have fixed it.
i do have a DNS (ipv4 and ipv6, though i’m not sure what the ipv6 is for) specified in the config, in the [Interface] section. so in that case my DNS queries should be going to that specified server, but they’re not…?
Your queries may not be directed to the Wireguard DNS if the default DNS server is included in the DisallowedIps list, or if DNSCACHE is part of the DisallowedApps. For instance, if you add your LAN subnet to DisallowedIps and your DNS server resides within this subnet, then DNS queries will be routed to your LAN DNS server instead Wireguard one.
my config does not have an MTU specified
I assume you’re referring to DNS, correct? If your Wireguard configuration lacks a DNS server, then all DNS queries will default to your regular DNS settings. Consequently, if a website is restricted in your country, by your Internet Service Provider (ISP), or through parental controls, access to these sites may be blocked at DNS level.
