issue with wiresock

[AlKhalifaaa]

Describe the issue Whenever I try to use TunnLTO with custom rules or default rules I cant fully connect to game server. I do connect to server but when I join game - connection being lost (you can see it in logs). I dont have this issue if I would use same conf on wireguard. This issue only persist with TunneLTO. logs.txt

Tested on official WireGuard client Is the tunnel working on the official Windows WireGuard client? - yes

Tunnel Config

Starting WireSock directly

I tried, absolutely same issue.

[brendanosborne]

I've had to remove your screenshot as it had your keys. Can you post up screenshots of the following:

• TunnlTo config with the keys and endpoint removed
• More details about the game you're trying to route
• The VPN server provider

[AlKhalifaaa]

DayZ. Amazon AWS

The thing is that without TunnLTO on just basic default wireguard everything works perfect. I tried to use same conf but without any rules (just completely default) and still having issue with tunnlto

[wiresock]

Could you kindly add the MTU setting to your configuration file and initially set it to 1280? If this configuration is successful, you can gradually increase the MTU value until you encounter any issues.

[AlKhalifaaa]

(MTU = 1280) I saw your recommendation on your website in one of the similar to my problem topics but unfortunately its not the case. MTU 1280 and 1380 has drops. The problem exist only with DayZ. Any other games are fine

MTU 1480

[wiresock]

Could you attempt running the same configuration using WireSock CLI in virtual adapter mode by employing the -lac command line switch, and then observe if the issue continues? Alternatively, if utilizing WireSock CLI proves to be inconvenient, you have the option to download WireSockUI, which also accommodates this mode.

[AlKhalifaaa]

I tried to run:

wiresock-client.exe run -config C:\Users\pc\AppData\Local\TunnlTo\tunnel.conf -lac and wiresock-client.exe run -config C:\Users\pc\AppData\Local\TunnlTo\tunnel.conf -log-level all -lac

that's what i had New Text Document.txt

I tried WireSockUI with tunnLTO config (allowed and disallowed apps lists), default conf and after that default with virtual network adapter mode enabled. Absolutely same issue, nothing helped unfortunately.

[wiresock]

Considering the attached screenshots, I note that the packet loss rate of 32% is significantly high. In such scenarios, my usual approach is to first try reducing the MTU (Maximum Transmission Unit) size. If this doesn't alleviate the issue, then the problem might be associated with your Wireguard server or the route leading to it.

[AlKhalifaaa]

Official wireguard works well for me without any problems, I can connect and play where I want, 0 issues. Only when I try to use TunnLTO it's not fully connecting me to the game server. Problem with TunnLTO. 32% packet loss it's because it was trying to connect but couldnt and was spamming this wireguard_read returned: result = 2 size = 9 If there would be problem with my wireguard server I couldnt be able to connect either way through official wireguard, right?

[wiresock]

Could it be possible that you are simultaneously running the same configuration with both the official Wireguard client and WireSock? The symptoms you're experiencing are very reminiscent of such a scenario.

[AlKhalifaaa]

I always make sure that everything is disabled before try to use something. If I would do that in such case I wouldnt be able to play any game. if you want i can show you how exactly it looks like from my side in discord (al_khalifa) for example or if you want to keep everything here I can understand.

[wiresock]

Alright, I have another question for you: If you remove all WireSock extensions (AllowedAps and etc..) from the configuration, does it function properly? Please conduct tests in both modes - with the -lac option and without it - to see how it performs.

It's important to mention another aspect: I advise against using both AllowedApps and DisallowedApps in the same configuration. Including AllowedApps implies tunneling only those specific applications and letting everything else bypass the tunnel, whereas using DisallowedApps means tunneling everything except the specified applications. This could lead to conflicting behaviors in your configuration.

[AlKhalifaaa]

Same issue. New Text Document (2).txt New Text Document (3).txt

[wiresock]

I have concerns about these entries:

2024-01-13 16:55:31 [TUN]: wireguard_read result = 2 size = 9

Such entries typically indicate an error, often suggesting an issue with the tunnel. Commonly, this occurs when multiple Wireguard clients are connected to the server using the same key, which is a scenario that should be avoided.

If you are absolutely certain that multiple clients using the same key is not the issue, then capturing and recording the network traffic could be beneficial for further analysis.

[AlKhalifaaa]

Documents.zip first capture is only TunneLTO with default conf (no custom rules) second capture is wireguard

[wiresock]

I appreciate your efforts, but the traffic data collected through Wireshark for Wiresock is not quite relevant for our current issue. Instead, you should use Wiresock's own traffic collection feature. This process will generate four pcap files. Please provide these files along with the text log for further analysis. For comprehensive instructions and effective troubleshooting strategies, kindly refer to the following page: Effective Troubleshooting for Wiresock VPN Client.

[AlKhalifaaa]

wiresock_enc_ext_log.zip wiresock_lcl.zip wiresock_tun.zip

[wiresock]

Thank you for reaching out and providing the necessary information regarding the connectivity issues you've been experiencing. After a thorough review of the data and packet captures you've provided, I've identified the primary cause of the problem.

The issue appears to be related to the MTU (Maximum Transmission Unit) settings and the inherent nature of packet fragmentation. Specifically, WireSock, which is designed with a focus on performance efficiency, does not support the defragmentation of fragmented Wireguard datagrams. This is a crucial aspect of the problem.

In WireSock's operational model, packets are read and injected directly, bypassing the conventional TCP/IP stack. This approach leads to the first fragment of a Wireguard datagram being processed as if it were a complete packet. However, since this fragment does not contain the entire packet, it results in an error. Moreover, any subsequent fragments of the datagram are not processed and are silently dropped. This behavior is a direct consequence of the lack of defragmentation support in WireSock.

Interestingly, your captures show similar fragmented packets being handled successfully by the standard Wireguard client. This difference in behavior is due to the fact that in a typical setup, fragmented packets undergo defragmentation via the TCP/IP stack, which is not the case with WireSock.

Additionally, based on the patterns observed in the packet captures, it seems likely that the game you are using utilizes UDP protocols. In such scenarios, datagrams often reach their maximum size and thus, when wrapped by Wireguard, require fragmentation. WireSock's inability to handle these fragmented packets adequately is at the heart of the connectivity issues you're facing.

To address this, I would recommend exploring the possibility to adjust the game MTU settings to prevent packet fragmentation.

[AlKhalifaaa]

I wanted to say that I appreciate your effort and time, thank you so much for trying to help me out in this situation. I honestly fall in love with this tool, it's unique piece of hard work that I really want to make work.

With info provided by you I did research and tried to use your advice but unfortunately it didn't helped. MTU packet drops or usual process of losing packets all the time at any MTU value I put (-10 offset from 1500 up to 1280). But I found something interesting and this behavior is strange. If I setup MTU at 1472 and keep lowering it by offset -10 (in TunnlTo app) to 1452 and try to ping game server while adjust MTU to -60 in cmd line it will eventually stop packet fragmentation. If I try to set MTU value at 1392 in TunnelTo and try to ping again throught cmd game server I start experience packet fragmentation in cmd and game with no MTU change (same 1392). If I try with MTU set to 1392 and throught cmd ping game server again but lower MTU value there -30 it will stop packet fragmentation again. If I put 1362 MTU again to TunnelTo same thing will happen as stated before. And if you try it again and again (same steps) same issue will be faced. mtu_research.txt

Another similar behavior I found by setting up MTU at 1280 and try to lower it in cmd with -10 offset, packet defrag was gone at 1250 value but what happens then? :) mtu_research2.txt

What can be the issue from my understanding is default MTU 1420 in TunnelTo. Why? 28 bytes is reserved for IP/ICMP overhead in default Windows MTU value (without reservation it's 1472), so if you offset it from current TunnelTO 1420 default value it will become 1392 and that's when packet defrag is gone. But if you put successful value it becomes unsuccessful.

Wireguard and openvpn utilizes 1500 MTU by default and everything works alright. My suggestion by all of this stated above is to add more options like:

1. Let user just use split tunneling feature without wiresock utitizing wireguard packets to make sure there is no packet fragmentation.
2. Add troubleshooting feature as using MTU value which being provided by wireguard server.
3. Set default MTU value to 1500? (I'm not sure how it works, maybe 1420 is ideal value for wiresock to work)

P. S. I'm not a technician or it specialist who understands networking in general, just an average user. Everything I explained here can be absolutely wrong and issue might be somewhere else or I'm just unlucky and forced to use wireguard only.

[AlKhalifaaa]

I tried to use different VPS server in same region as my first one is. Same thing but without error spam. Maybe it would be useful. wiresock-vpn-client.log wiresock_enc.zip wiresock_ext.zip wiresock_tun.zip wiresock_lcl.zip

[brendanosborne]

I'm going to close this for now. WireSock is aware of the issue and can re-open if required.