ISSUE: paths containing non-ascii characters not supported

[Setsu-BHMT]

Describe the issue
Any paths set in allowed/disallowed sections that contain non-ascii characters (such as chinese, japanese) result in failure. The paths are correctly shown in the GUI but the desired functionality is not active. For example, if the path was specified in the allowed folders section, any app started in that folder are NOT tunneled.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Edit Tunnel'
2. Add a path to 'Allowed Folders' that contains chinese characters
3. Save and enable the tunnel
4. Observe that apps started in that folder are not tunneled.

Expected behavior
Any valid UTF16 path should be tunneled properly. (UTF16 is the default encoding for Windows paths)

Tested on official WireGuard client
No.

Tested on different VPN servers
VPN functions correctly if path doesn't contain chinese characters

Screenshots and GIF's
Not applicable

Tunnel Config
Not applicable. The tunnel works if path does not contain chinese characters

Logs
In Settings, change the "WireSock Log Level" to "Show All Logs". Copy/paste the logs here with any identifying information removed.

Starting WireSock directly

Microsoft Windows [Version 10.0.19045.4170]
(c) Microsoft Corporation. All rights reserved.

C:\Users\***>cd "C:\Program Files\WireSock VPN Client\bin"

C:\Program Files\WireSock VPN Client\bin>wiresock-client.exe run -config C:\Users\***\AppData\Local\TunnlTo\tunnel.conf -log-level all
2024-03-13 17:48:35 WireSock WireGuard VPN Client Service 1.2.37
The service is starting using C:\Users\***\AppData\Local\TunnlTo\tunnel.conf WireGuard client configuration.

WireSock WireGuard VPN Client 1.2.37 is running as a regular process.
2024-03-13 17:48:35 WireSock Service has started.
2024-03-13 17:48:35 [MGR]: Using WireGuard server: ***.***.***.*** : ***
2024-03-13 17:48:35 [TUN]: Detected default interface {00E1FAC3-B61F-4114-8DDE-F2C6A65E06D7}
2024-03-13 17:48:35 [TUN]: Using local IPv4 = 192.168.1.163 for the {00E1FAC3-B61F-4114-8DDE-F2C6A65E06D7}
2024-03-13 17:48:35 [TUN]: Local IPv6 address for the {00E1FAC3-B61F-4114-8DDE-F2C6A65E06D7} not available
2024-03-13 17:48:35 [TUN]: Sent handshake packet to the WireGuard server at ***.***.***.***:***

2024-03-13 17:48:35 [MGR]: Tunnel has started
2024-03-13 17:48:35 Wireguard tunnel has been started.
2024-03-13 17:48:35 [TUN]: Handshake response received from ***.***.***.***:***
2024-03-13 17:49:00 [TUN]: keep_alive_thread: Sending Keepalive packet to WireGuard Server success

2024-03-13 17:49:10 [FILTER]: Skipping C:\Users\***\Downloads\Temp�Local2\start.exe : TCP : 192.168.1.163:7185 -> ***.***.***.*** : ***
^C
C:\Program Files\WireSock VPN Client\bin>

The path is shown in the output corrupted (there should be chinese characters after Temp) and incorrectly skipped.

[brendanosborne]

Thanks for reporting this. I'm trying to replicate it for debugging but having some trouble. I've added "C:\测试文件夹\folder" as an allowed folder and it appears to be writing it correctly to the resulting tunnel.conf (stored in C:\Users[YOUR USERNAME]\AppData\Local\TunnlTo\tunnel.conf)

Can you check your tunnel.conf file to see if it contains the correct characters?

[Setsu-BHMT]

Thanks for following up on this issue. Yes, the TunnelTo app does write the path correctly to tunnel.conf.
It appears it is the underlying Wiresock CLI that is having trouble with the paths.

[brendanosborne]

I'll @wiresock as he may already be aware of this issue. Also closing this issue as it's unrelated to TunnlTo.

[wiresock]

This issue was fixed in WireSock VPN Client v1.4.5.