[Vadim Smirnov]

Гм, видимо до сих пор никому не понадобилось. Добавлю, это в общем несложно.

[Vadim Smirnov]

Below is my log to compare. If you can’t see “Handshake response”, then there are two possibilities:

1. Handshake is blocked despite the SOCKS5 wrap.
2. The socks5 proxy you use is not correctly configured for UDP (if the server is behind the NAT, like in my case in Oracle cloud, it requires some extra configuration for UDP).

If you share the IP you test from, then I could add you to the exceptions list so that you could test using my socks5 server.

D:\projects\winpkfilter\wiresock-client\bin\exe\x64\Release>wiresock-client run -config chk.conf -log-level all
2021-12-20 19:08:53 WireSock LightWeight WireGuard VPN Client Service
 The service is starting using chk.conf WireGuard client configuration.
WireSock LightWeight WireGuard VPN Client is running as a regular process.
2021-12-20 19:08:53 WireSock Service has started.
2021-12-20 19:08:53 [TUN]: Detected default interface {EBCAE00D-53EC-438F-92F4-0F470C0E1428}
2021-12-20 19:08:53 [TUN]: Using local IPv4 = 192.168.1.26 for the {EBCAE00D-53EC-438F-92F4-0F470C0E1428}
2021-12-20 19:08:53 [TUN]: Using local IPv6 = 2002:9eff:33d9:0:81c5:c4d3:f979:722e for the {EBCAE00D-53EC-438F-92F4-0F470C0E1428}
associate_to_socks5_proxy: SOCKS5 ASSOCIATE SUCCESS port: 41701
C2S: 192.168.1.26 : 53417 -> 195.135.213.87 : 50555
C2S: 192.168.1.26 : 53417 -> 132.226.194.27 : 41701
2021-12-20 19:08:54 [TUN]: Sent handshake packet to the WireGuard server at 195.135.213.87:50555

2021-12-20 19:08:54 [MGR]: Tunnel has started
2021-12-20 19:08:54 Wireguard tunnel has been started.
S2C: 132.226.194.27 : 41701 -> 192.168.1.26 : 53417
S2C: 195.135.213.87 : 50555 -> 192.168.1.26 : 53417
2021-12-20 19:08:54 [TUN]: Handshake response received from 195.135.213.87 : 43462
2021-12-20 19:08:54 [FILTER]: Skipping ignored IP: PROTOCOL 6 : 192.168.1.26 -> 192.168.1.166

[Vadim Smirnov]

Here is the link to the test build. Please try to test in your environment. If you have Wiresock VPN Client installed, then you can run these binaries from any folder on your machine.

https://1drv.ms/u/s!AqMWR3uDO7eagdpfVHFLOBkJ7Ai5hg?e=XUmJME

Below is the sample configuration, please note the extension parameter Socks5Proxy. If you don’t have a SOCKS5 proxy under hand, I can add your IP to allow access to one I have set at 132.226.194.27:1080.

[Interface]
PrivateKey = __REMOVED__
Address = 10.10.11.3/24
DNS = 8.8.8.8, 1.1.1.1
MTU = 1412

[Peer]
PublicKey = __REMOVED__
AllowedIPs = 0.0.0.0/0
Endpoint = __REMOVED__:50555
PersistentKeepalive = 25
AllowedApps = chrome
DisallowedIPs = 192.168.1.0/24
Socks5Proxy = 132.226.194.27:1080

[Vadim Smirnov]

OK, I will add the corresponding log entry on handshake response receive event.

Wiresock is not based on WFP, it is NDIS Lightweight Filter. I don’t think it will conflict with adguard.

[Vadim Smirnov]

FYI, I have finally created the client version which sends the handshake (and receives handshake response) through the configured SOCKS5 proxy server. Meanwhile, it does not support SOCKS5 authentication methods and I have tested it only with local Dante proxy, but it looks promising. I’m going to test it first with external SOCKS5 proxy and if it goes fine, we can check how it works for your environment.

[Vadim Smirnov]

I am grateful for your patience, regretfully the last few weeks were quite busy. However, I’m also interested in this feature, and I hope I will have time to work on this during the weekend.

[Vadim Smirnov]

First, thank you for your interest and valuable feedback, it is really appreciated.

1. Wiresock VPN client is based on WinpkFilter driver which has the registry parameter (can be set using https://www.ntkernel.com/docs/windows-packet-filter-documentation/ndisapi-c-2/setadaptersstartupmode/) and defines the default adapters filter mode. For example, if set this parameter to MSTCP_FLAG_SENT_TUNNEL | MSTCP_FLAG_RECV_TUNNEL then network traffic will be blocked by default and can be re-enabled only by the application.

So if you create a DWORD value named StartupMode under HTLM\CurrentControlSet\Services\ndiswgc\Parameters, assign to 3 and reboot, then it will result in the desired behavior. However, this is a global setting that affects all network interfaces, so it may result in undesired effects on other network interfaces (if you have more than one). I will consider adding this option in the next version in some more convenient form.

2. Meanwhile, the amount of data sent/received over the tunnel is not reported (although it is available). I think to add a simple tray icon-based application to report the tunnel stats. If you have other options in mind, then please let me know.

3. Current implementation is simple, the given name pattern is checked for being a substring in the process name. For example, ‘chrome’ covers any process which contains ‘chrome’ substring as a part of its name, e.g. WinChrome.exe, AxChromeAi.exe etc.

[Vadim Smirnov]

According to the command line, you run wiresock service as a console application. Please note that in NAT mode, the application has to enable built-in Windows routing and the related API function requires Administrator privilege. Please try to run CMD as Administrator and then execute wiresock-service run -mode nat -interface mywgserver -log-level none

[Vadim Smirnov]

The only thing you need is a couple of IPHELPER API functions, GetExtendedTcpTable and GetExtendedUdpTable. Then just match IP/port information against information extracted from the packet.

If you need to do that in C# then here is the sample code https://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G

[Vadim Smirnov]

Hi,

The only sample which demonstrates process lookup (using IP Helper API) is Socksify, and it is in C++:

https://github.com/wiresock/ndisapi/tree/master/examples/cpp/socksify

However, it is not a big deal to integrate process_lookup.h into .NET C++/CLI mixed class library (ndisapi.net) and use it there.

[Vadim Smirnov]

You can send your code to support(at)ntkernel.com

[Vadim Smirnov]

Socksify was designed to be easy to understand, and it implements only a limited number of features. SOCKS5 password authentication is not supported, but it is not a big deal to add it if needed.

[Vadim Smirnov]

Yes, sure, I can sign your custom drivers build and as well as generate and sign MSI installers for Windows 7 and higher.

You can send e-mail to support(at)ntkernel.com if you have any further questions.

[Vadim Smirnov]

An interesting idea, probably it would really be possible to use a SOCKS5 proxy (e.g. Dante which supports UDP) for this purpose.

I will try to make some tests or even working demo over the weekend.

[Vadim Smirnov]

But what if we try to get rid of windscribe at all and replace it with simple obfuscation service?

For example, I could add another parameter to wiresock config file:

HandshakeFwd = test.sshvpn.me:52220

If this parameter is present in the config file then:

1. Wiresock client instead of sending handshake packet to Warp server will obfuscate it (add random size header for example) and send to test.sshvpn.me:52220 instead Warp server.

2. Service listening test.sshvpn.me:52220 extracts original handshake and forwards it to Warp+ server. Here we have two options, if DPI blocks only handshake packets we can preserve source IP address and UDP port of the packet so that Warp+ server will send the handshake response directly to the wiresock skipping step 3.

3. If DPI also blocks handshake responses then service forwards handshake from its IP address, receives handshake response from Warp, obfuscates it and forwards to wiresock.

4. Wiresock receives handshake response, optionally de-obfuscates it and sets the tunnel up.

Building such a service application and extending wiresock to use it is not that difficult. If you’re interested, we can try this approach.

[Author]

Posts