Connected to tunnel, but no traffic works

Home Forums Discussions Support Connected to tunnel, but no traffic works

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #13548
    adamater
    Participant

      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 ago by adamater.
      #13551
      Vadim Smirnov
      Keymaster

        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?

        #13552
        adamater
        Participant

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

          • This reply was modified 2 months ago by adamater.
          • This reply was modified 2 months ago by adamater.
          #13555
          Vadim Smirnov
          Keymaster

            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.

          Viewing 4 posts - 1 through 4 (of 4 total)
          • You must be logged in to reply to this topic.