Can I select the default interface when using WireSock VPN client on win10

[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+?

[Mustafa.Mah]

Wiresock works fine with other services other than warp+ and there is no ip leaks so far, but there is still a minor issue that after connecting the tunnel works (according to logs) but no website load (DNS address could not be found) until I disable/enable the wifi.

[Vadim Smirnov]

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

[Mustafa.Mah]

Actually I’ve done this but the problem still present, According to the log the dns requests are forwarded but there is no dns respons until I disable/enable wifi.

[Vadim Smirnov]

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

[Mustafa.Mah]

Here are PCAP files with adguard not running: https://easyupload.io/23402w

[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.

[Mustafa.Mah]

People working at ISP in my country are doing a really good job at messing up everything.

I also wonder why resetting wifi connection seems to fix this issue, We can give it a try and pass all traffic through proxy too but I think it will hit the performance and speed will be reduced (which won’t be a problem with my 12Mbps adsl connection).

[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]

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]

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

[Mustafa.Mah]

I tried the build in #11988 and it works well, as for the build in #11993 still having same issue unfortunately, It only starts working only after wifi reset.

I’ve uploaded PCAP file and a copy of log for this session: https://upload1.easyupload.io/unw33c

You can see in log starting from line 411 it is working and no more dns issues and websites load normally.
I can try another router (old one) if you want so that I can eliminate router problems but my ip will change probably.

[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

[Mustafa.Mah]

Thank you so much for your work. Now it is working really good. I’ve noticed that keep-alive packets are sent over socks (correct me if I’m wrong) so was that the problem, ISP router blocks keep-alive packets too?

Edit: keep-alive packets sent every 20 sec (and sometimes ~60 sec) not 25 sec like set in config.

[Mustafa.Mah]

I’ve noticed inconsistency in sending keep-alive packets, sometimes sent every 20 sec or every 60 sec or even up to 120 sec (2min) which led to close of connection by ISP router and connection drops and client is trying to send keep-alive packets every 5 sec and no more handshake responses.

This is a log for a session when only one app uses the tunnel it works fine until I close it and tunnel idle for a few minutes which causes what described above.
https://upload1.easyupload.io/09ovbp

[Author]

Posts