[Vadim Smirnov]

Regretfully, #11993 has the same problem with the first handshake. Please test the one below, I hope I have fixed all places where it could come from:

https://1drv.ms/u/s!AqMWR3uDO7eagdpkWfB_aQsCvk66Tg?e=idzeGj

[Vadim Smirnov]

Here is the build which sends only handshake over SOCKS5 but does not allow handshake to go out until SOCKS session is not ready.

https://1drv.ms/u/s!AqMWR3uDO7eagdpiKKoUYwslX2XG_A?e=6COUAa

[Vadim Smirnov]

However, may be the problem in the first handshake which I have passed over before the SOCKS connection was ready:

It could result in DPI logging the WireGuard connection attempt and subsequent blocking of incoming packets. I will make another build to fix this.

[Vadim Smirnov]

Please try this build

https://1drv.ms/u/s!AqMWR3uDO7eagdphxyLoAnh77tB0UQ?e=H3q4Xf

Please note to reduce WireGuard MTU by 10 bytes. It can be a little noisy on -log-level all producing numerous messages from SOCKS:

2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075
2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603
2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075
2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603
2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075
2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603
2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075
2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603
2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075
2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603
2021-12-21 21:58:39 [SOCKS5]: S2C_BEFORE: 132.226.194.27 : 43603 -> 192.168.1.26 : 58615
2021-12-21 21:58:39 [SOCKS5]: S2C_AFTER: 152.70.176.114 : 59075 -> 192.168.1.26 : 58615

[Vadim Smirnov]

Yes, there is a problem, but it is not about the DNS…

Handshake works fine over the UDP proxy and packets are sent out over the tunnel. However, only very few packets come back from WireGuard server. I can see only the following incoming packets:
counter(258):session(1902), counter(199-204):session(1904), counter(250):session(1905). According to the counters, WireGuard server is sending packets to you, but most of them are dropped on the way. I wonder why refreshing the network connection resolves the issue, but it looks that not only handshake can be blocked…

We could try to pass all WireGuard traffic over the UDP proxy to see if it improves the behavior.

[Vadim Smirnov]

Could you collect PCAP files with disabled adguard and non-working DNS? I will check what can be wrong with DNS queries.

[Vadim Smirnov]

Hmm, could you try to disable Adguard and check if the problem with DNS persists?

[Vadim Smirnov]

I’ve looked through the captures, and basically, it looks ok. Although, there are some TCP sessions which were already active at the moment you activated Wiresock VPN client and packets from these sessions can be still received from outside the tunnel. At the same time, outgoing packets are forwarded over the tunnel and such sessions naturally die after retransmit attempts. So, the general recommendation is restarting the browser after activating the tunnel to avoid these session artifacts.

Besides this, the approach with forwarding Wireguard handshake through the SOCKS5 proxy seems working as expected. Have you tried to test Wiresock VPN client with Wireguard service other than warp+?

[Vadim Smirnov]

When started with -log-level all wiresock stores the traffic into pcap files which can be analyzed in Wireshark. If you are interested I could take a look at these captures to understand what is wrong with them.

P.S. Also it might be reasonable to test the fresh Windows setup.

[Vadim Smirnov]

This is confusing, I have tested these URLs with my configuration posted above, which actually less restrictive than yours and tunnels only Google Chrome and only for non-local addresses. And all the web-sites from your list report the VPN address.

Anyway, IP leak should have an explanation. What browser have you been using? I would also try to test on the system without any other low-level networking software installed for the cleanliness. May be one of these VPNs/tunnels you have tested with causes the leak. Besides this, I could create the configuration on my VPN server to test for the case if the problem in VPN server.

[Vadim Smirnov]

So, it probably was incorrect configuration of your SOCKS proxy.

What is your configuration and what sites have you tested with? Something like https://www.speedtest.net and https://www.whatismyip.com?

[Vadim Smirnov]

I have added 197.36.2.166 to the allow list. You can try

Socks5Proxy = 132.226.194.27:1080

[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

[Author]

Posts