Connected to tunnel, but no traffic works

[adamater]

The tunnel connects, the handshake is working, but no connection is working OR it is EXTREMELY slow, like 10 minutes to load google. On normal wireguard client, it works with the exact same config. Windows 10 x64. Log below.

PS C:\Program Files\WireSock VPN Client\bin> wiresock-client.exe run -config pc.conf -log-level all
2024-02-20 06:33:35 WireSock WireGuard VPN Client Service 1.2.37
The service is starting using pc.conf WireGuard client configuration.

WireSock WireGuard VPN Client 1.2.37 is running as a regular process.
2024-02-20 06:33:35 WireSock Service has started.
2024-02-20 06:33:35 [MGR]: Using WireGuard server: 1×8 : 51820
2024-02-20 06:33:36 [TUN]: Detected default interface {7495E4E8-x-7908F939782B}
2024-02-20 06:33:36 [TUN]: Using local IPv4 = 192.x.2 for the {7495E4E8-x-7908F939782B}
2024-02-20 06:33:36 [TUN]: Using local IPv6 = 2×726 for the {7495E4E8-x7908F939782B}
2024-02-20 06:33:36 [TUN]: Sent handshake packet to the WireGuard server at 1×8:51820

2024-02-20 06:33:36 [MGR]: Tunnel has started
2024-02-20 06:33:36 Wireguard tunnel has been started.
2024-02-20 06:33:36 [TUN]: Handshake response received from 1×8 : 51820
2024-02-20 06:33:37 [FILTER]: C:\Program Files\Firefox Nightly\firefox.exe : TCP : 19x.2:50229 -> 54.x.48:443
2024-02-20 06:33:37 [FILTER]: C:\Program Files\Firefox Nightly\firefox.exe : TCP : 1x.2:50230 -> 54.x.48:443
2024-02-20 06:33:38 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:38 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:38 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:38 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:39 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:39 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:40 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:41 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:42 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:44 [TUN]: wireguard_read result = 2 size = 9
2024-02-20 06:33:48 [FILTER]: Dnscache : DNS : 19x.2:58930 -> 64.6.64.6[19x.1]:53
2024-02-20 06:33:48 [TUN]: DNS request to 19x.1 forwarded to 64.6.64.6
2024-02-20 06:33:48 [FILTER]: PROTOCOL 58 : fe80::d49a:e7x5:33ff:fee0:c0ff

• This topic was modified 2 months, 1 week ago by adamater.

[Vadim Smirnov]

Typically, these errors occur in the case of packet fragmentation. Could you please try reducing the MTU and also check if using virtual adapter mode (-lac) makes a difference?

[adamater]

lowering the mtu seems to fix it, though the normal client uses a mtu of 1420

• This reply was modified 2 months, 1 week ago by adamater.
• This reply was modified 2 months, 1 week ago by adamater.

[Vadim Smirnov]

The official Wireguard client employs a UDP socket and relies on the TCP/IP stack for packet reassembly. In contrast, WireSock, prioritizing performance, directly retrieves packets from the NDIS layer, bypassing the TCP/IP stack. The current version of WireSock does not reassemble fragmented Wireguard packets, operating under the assumption that the MTU is appropriately chosen to prevent fragmentation. While this approach is optimal for performance, it can be confusing for users. Recognizing this, I plan to address and rectify this issue in WireSock when time allows.

[Author]

Posts