[Vadim Smirnov]

It’s really weird. It looks like you have a firewall in between that is blocking SOCKS5. Web browsers use SOCKS4 by default, and maybe that matters. To clarify, could you please capture the Dante traffic on the server side? For example, for my test machine in Oracle cloud:

ubuntu@instance-20211213-2206:~$ sudo tcpdump -D
1.ens3 [Up, Running]
2.lo [Up, Running, Loopback]
3.any (Pseudo-device that captures on all interfaces) [Up, Running]
4.bluetooth-monitor (Bluetooth Linux Monitor) [none]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
ubuntu@instance-20211213-2206:~$ sudo tcpdump -vv -i ens3 -w file.pcap port 1080
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
11 packets captured
11 packets received by filter
0 packets dropped by kernel

The resulted capture in Wireshark:

[Vadim Smirnov]

Well, Dante resets the connection immediately after processing the packet with authentication methods:

This is confusing if your browser connects fine… Could you please double-check if [CLIENT EXT IP]/32 in Dante configuration file matches your external IP? It behaves like you have a wrong IP address there.

You could try to change it to 0.0.0.0/0, restart Dante and check if it helps. For the security reasons, you could consider enabling username/password authentication.

[Vadim Smirnov]

Hmm, a little confusing. However, when you start the application specifying debug level “all” it also creates PCAP files with traffic captures. Could you please share the wiresock_ext.pcap? It should contain something like on the screenshot below:

[Vadim Smirnov]

Good evening, Dziadek!

I think the problem is with Dante server:

[SOCKS5]: associate_to_socks5_proxy: Failed to receive socks5_ident_resp:: 10054

Error code 10054 (WSAECONNRESET) means that connection was reset by the remote peer (Dante). How have you configured the Dante server? According to the log, it does not use username/password authentication, right? How have you limited access to it? By an IP address?

[Vadim Smirnov]

Hi,

Sorry, this is my fault, I had not tested the installer on Windows 7. I’ve just updated the installer, please re-download and try to install.

-Vadim

[Vadim Smirnov]

Thanks for pointing this out, I have fixed it in 1.0.32.

[Vadim Smirnov]

Socksify is just sample demo code to illustrate the approach. It is not supposed to be an end-user application. Also, please note that it does not support UDP, it is TCP only. However, it can be extended to socksify UDP.

[Vadim Smirnov]

I’m sorry, this is my fault. I was so keen about the new SOCKS5 feature that had not tested the latest build without it. The handshake without SOCKS5 was broken in v.1.0.47 and v.1.0.48.

Please download v1.0.49 and give it a try.

[Vadim Smirnov]

From what I can see, your WireGuard server at google.com:2408 does not respond. Handshake Initiate packets are sent out, but a Handshake Response is never received.

BTW, does Google provide WireGuard service?

[Vadim Smirnov]

Thanks for your reply, I dont understand that you said dont specify, i try to delete “AllowedApps” line and restart wiresock service and there is no connection over VPN, i also try leave blank AllowedApps = “blank” , it doesnt work too.

Since I’m usually running WireSock VPN Client for the Chrome browser app, it was straightforward to test. I have commented out AllowedApps and restarted service. Now, Firefox/Edge also show the VPN address on https://www.whatismyip.com/. Here is the resulted configuration file (key and passwords are stripped out):

[Interface]
PrivateKey = PRIVATE_KEY=
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 94.140.14.14, 94.140.15.15
MTU = 1420

[Peer]
PublicKey = PUBLIC_KEY=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = oracle.sshvpn.me:50812
#AllowedApps = chrome
DisallowedIPs = 192.168.1.0/24
Socks5Proxy = oracle3.sshvpn.me:1080
Socks5ProxyUsername = SOCKS5_USER
Socks5ProxyPassword = SOCKS5_PASSWORD

Can you share your config file? Also, if you experience any problems, then try running Wiresock VPN Client as a console application with -log-level all and share the output.

About Socksify sample, can you support it tunnell all apps, not only selected apps ?

This is relatively easy to do, just remove the application name check, and it will tunnel every new TCP connection via the SOCKS5.

 

[Vadim Smirnov]

I don’t think I understand your question. If you want Wiresock VPN Client to tunnel all the applications over WireGuard tunnel, then just don’t specify AllowedApps parameter in the configuration file.

Socksify sample serves a different task, it forwards the selected application via the SOCKS5 proxy server. I will consider making the background service based on the Socksify sample code.

 

[Vadim Smirnov]

I have finally released v.1.0.48 of WireSock VPN Client with SOCKS5 support for WireGuard handshakes. This build supports username/password authentication. If you have a chance to test it, then please update me on how it works in your environment.

Here is the short guide on setting up free SOCKS5 server with UDP ASSOCIATE support in Oracle Cloud: https://www.ntkernel.com/wireguard-and-socks5/

 

[Vadim Smirnov]

I’ve just set a nested WireGuard tunnels setup to test and provide you with some examples. Regretfully, there is one problem, the last version of WireGuard for Windows I have tested nested wireguard/wiresock tunnels was v0.5, and it looks one of the more recent updates has broken this setup (internal handshake packet sent by wiresock can’t reach the destination).

However, recently, I have added a new feature to Wiresock which allows sending a handshake packet through the SOCKS5 server. Please see the related post on bypassing Egypt’s WireGuard ban here. And surprisingly, this allows to resolve the issue, handshake packet is not recognized by stock Wireguard and reaches its destination.

The Wireguard for Windows configuration (external tunnel):

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

[Peer]
PublicKey = PUBLIC_KEY_HERE
AllowedIPs = 0.0.0.0/0
Endpoint = WIREGUARD_EXTERNAL_SERVER_IP:50812
PersistentKeepalive = 25

Wiresock VPN Client configuration(internal tunnel for Chrome browser only):

[Interface]
PrivateKey = PRIVATE_KEY_HERE
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 8.8.8.8, 1.1.1.1
MTU = 1332

[Peer]
PublicKey = PUBLIC_KEY_HERE
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = WIREGUARD_INTERNAL_SERVER_IP:50812
AllowedApps = chrome
DisallowedIPs = 192.168.1.0/24
Socks5Proxy = SOCKS5_PROXY_ADDRESS:1080
Socks5ProxyUsername = SOCKS5_USERNAME
Socks5ProxyPassword = SOCKS5_PASSWORD

SOCKS5 handshake feature is not released yet, but if you’re interested in testing it, then you can download binaries here. Just copy these over the installed ones in C:\Program Files\WireSock VPN Client\bin.

[Vadim Smirnov]

I had not tested nested tunnels with Open VPN Client, but I have tested the official Wireguard VPN Client along with Wiresock VPN Client to organize nested VPN tunnels:

WireSock VPN Client is compatible and can be used with official WireGuard for Windows to organize nested WireGuard tunnels completely on the client side. In such configuration, the official client organizes the external tunnel (to the first WireGuard Server instance) and WireSock VPN Client the internal one (to the second WireGuard Server instance). You only need to remember to adjust MTU parameter for the internal tunnel accordingly to avoid fragmentation and throughput degradation.

However, I can’t see why it could not work a similar way with Open VPN Client… But please note to use the Wiresock VPN Client instead of the official Wireguard for Windows.

[Vadim Smirnov]

I don’t have Windows 7 Enterprise X64 under hand, but I’ve tested 3.2.32 on Windows 7 x64 retail with all latest updates, and it works ok.

However, there is one key difference in driver signing between 3.2.7 and 3.2.32:

3.2.7 drivers for Windows 7 are signed using SHA-1 Code Signing certificate, while 3.2.32 with SHA-256 EV Code Signing certificate.

Please note, that SHA-1 code signing certificates are no more available for ordering and the latest Windows Packet Filter version signed with SHA-1 Code Signing certificate was 3.2.29. You can get this version using the links below:

Windows Packet Filter 3.2.29.1 x64.msi

Windows Packet Filter 3.2.29.1 x86.msi

Alternatively, you could install the required update from the list below to add SHA-256 support to your OS:

• For Windows Vista, install SP1 and SP2 sequentially and then install the KB4090450 update.
• For Windows 7, install SP1 and then KB3033929 or KB4474419 or KB4054518.
• For Windows Server 2008, install SP1 and SP2 sequentially and then install update KB4474419 or KB4039648 or KB3033929.
• For Windows Server 2008 R2, install SP1 and then KB4474419.

[Author]

Posts