[Vadim Smirnov]

Hey! Great to hear you’ve got WireSock working for per-app tunneling!

What you’re seeing with DNS is actually expected behavior on Windows due to how the system handles DNS resolution. Here’s a quick breakdown:

How DNS works on Windows:

• Windows uses a system service called DNS Client Service (also known as dnscache), which acts as a central resolver.
• All applications send their DNS queries to this service, which performs the actual DNS resolution on behalf of all apps.
• Because of this, the DNS request isn’t directly tied to the application that originally needed it — once it’s handed off to dnscache, the link to the original app is lost.

Why it’s hard to isolate DNS per app:

• Since dnscache is the one making the DNS queries, any per-app VPN filtering based on the source application doesn’t apply to those DNS packets — they all appear to come from the system service.
• That’s why, even if you route only one app through the VPN, its DNS request (handled by dnscache) might still go through the VPN if the system DNS is set to use the VPN interface.

[Vadim Smirnov]

You’re not required to return the packet to the stack immediately — you can queue it and process it later if needed.

If you’re adding a custom header, keep in mind the extra overhead. However, instead of processing each UDP packet individually, consider implementing a session-like approach similar to TCP. For example, send an initial “initiate” packet to set up forwarding for all subsequent UDP packets from a specific IP and port to a designated destination. This reduces per-packet processing and handles large payloads more efficiently, since you don’t need to modify each UDP payload.

[Vadim Smirnov]

Your logic, while different in implementation, resembles the way SOCKS5 handles UDP ASSOCIATE and generally looks okay. It follows a similar encapsulation approach: sending metadata to a proxy server, receiving a token, and prepending that token to future packets.

It does have similar limitations, particularly:

1. MTU constraints – As you noted, prepending a 32-byte token reduces the usable payload size, which can lead to issues with packets near the 1500-byte MTU threshold. This is a common limitation in encapsulation-based proxy schemes.

2. Race condition on registration – Instead of skipping and passing packets until the proxy replies with the token, consider queuing outgoing packets per destination and only releasing them once authorization is complete and the token is available. This would reduce packet loss and make the logic cleaner.

Overall, the approach is valid for certain scenarios, just be mindful of these trade-offs.

[Vadim Smirnov]

Thank you for the update — I’m glad to hear that the integration is running stably and that you’ve already achieved a noticeable reduction in CPU usage.

Performance tuning is a nuanced and context-dependent task. To explore further optimization opportunities, I would recommend using a tool like the Visual Studio Profiler to analyze where the application is spending the most CPU time. This will provide valuable insights into any remaining bottlenecks that could be addressed.

That said, if the goal is to reduce CPU usage to near-zero levels, it’s worth noting that some processing overhead is inevitable — even with relatively modest network loads such as 20Mbps uplink and 30Mbps downlink. Still, profiling should give us a clear picture of what’s realistically achievable in your setup.

[Vadim Smirnov]

Packet retransmissions, lost packets, and significant delays on the WireSock interface are clear signs of an issue affecting performance. Since WireSock itself does not introduce artificial delays or excessive packet processing overhead, I suspect that some external network component is interfering with its operation.

Packet reordering and loss at this scale can be caused by third-party network software (such as antivirus, firewall, or another filtering driver) that intercepts traffic before it reaches WireSock. This can disrupt the expected flow, leading to degraded speeds.

To investigate, I recommend:

• Testing on a clean machine with a well-known WireGuard profile (e.g., Cloudflare Warp) to rule out external software conflicts.
• Testing against Cloudflare Warp to ensure that the issue is not related to the server side of your current WireGuard configuration.
• Temporarily disabling any third-party security software or VPN-related network filtering drivers to see if performance improves.
• Monitoring CPU and network adapter utilization to ensure that the system isn’t bottlenecked at the hardware or driver level.

If you can gather more details from these tests, it will help narrow down the issue. Let me know what you find!

[Vadim Smirnov]

Packet reordering is a bad sign, as it significantly impacts performance, leading to unnecessary retransmissions and degraded throughput. If you’re seeing frequent out-of-order packets and retransmissions in Wireshark logs, it suggests that something in your network stack is interfering with WireSock’s packet flow.

Since there are no signs of IP fragmentation, I suspect that some network component—such as an antivirus, a firewall, or another network filtering driver—is manipulating packets before they reach WireSock. This interference could be introducing delays or reordering packets, leading to the performance drop you’re experiencing.

I recommend testing WireSock on a clean machine with a well-known WireGuard profile (e.g., Cloudflare Warp) and temporarily disabling any third-party network-related software to isolate the cause. Let me know what you find, and I’d be happy to help troubleshoot further.

[Vadim Smirnov]

Yes, I’ve tested WireSock on a 10Gbps connection, and it has demonstrated decent performance, even outperforming the official WireGuard client in my tests.

Regarding high-load traffic, while WireSock processes packets before forwarding them to WireGuard, it is designed for efficiency. In practice, it handles substantial traffic loads well without becoming a bottleneck.

However, I recommend testing WireSock on a clean machine with a well-known WireGuard profile—such as Cloudflare Warp—to rule out any potential software conflicts at the low network level that might impact performance.

[Vadim Smirnov]

WireSock CLI includes a built-in feature for capturing traffic and saving it as PCAP files.

Certain components of WireSock are open source, such as BoringTun and NDISAPI, while others are proprietary but available for commercial licensing.

[Vadim Smirnov]

Normally, you would see the errors in the log. However, please avoid using debug logging during performance measurements.

[Vadim Smirnov]

I have a 400/400 Mbps connection. Here are the test results using WireSock with a Cloudflare Warp configuration and an MTU set to 1280:

WireSock Virtual Adapter Mode
WireSock Transparent Mode

I recommend checking your MTU settings. Unlike the official WireGuard client for Windows, WireSock does not defragment fragmented WireGuard UDP packets for performance reasons. Therefore, it is crucial to use an appropriate MTU to avoid connectivity issues.

[Vadim Smirnov]

Thank you for pointing that out. I made an incorrect assumption about the parameters, but I believe you understood the main idea correctly—when there are no packets to read, the packet events should be reset, and the thread should wait on them. I appreciate the clarification!

[Vadim Smirnov]

The high CPU usage is likely due to the fact that the packet event is never reset. This causes the thread to continuously poll the driver without pausing.

Solution:
You need to reset the AutoResetEvent or ManualResetEvent in waitHandlesManualResetEvents after processing packets. This ensures the thread properly waits for new packets instead of running in a tight loop.

Fixed Code:

private static unsafe void PassThruUnsortedThread
(
    NdisApi filter,
    WaitHandle[] waitHandles,
    IReadOnlyList<AutoResetEvent> waitHandlesManualResetEvents)
{
    const int bufferSize = 32;
    var buffers = new IntPtr[bufferSize];

    for (int i = 0; i < buffers.Length; i++)
    {
        buffers[i] = (IntPtr)filter.CreateIntermediateBuffer();
    }

    while (true)
    {
        int eventIndex = WaitHandle.WaitAny(waitHandles);  // Wait for an event to be signaled

        uint packetsSuccess = 0;

        while (filter.ReadPacketsUnsorted(buffers, bufferSize, ref packetsSuccess))
        {
            for (int i = 0; i < packetsSuccess; i++)
            {
                EthernetPacket ethPacket = buffers[i].GetEthernetPacket(filter);
                if (ethPacket.PayloadPacket is IPv4Packet iPv4Packet)
                {
                    if (iPv4Packet.PayloadPacket is TcpPacket tcpPacket)
                    {
                        // Console.WriteLine($”{iPv4Packet.SourceAddress}:{tcpPacket.SourcePort} -> {iPv4Packet.DestinationAddress}:{tcpPacket.DestinationPort}.”);
                    }
                }
            }

            if (packetsSuccess > 0)
            {
                filter.SendPacketsUnsorted(buffers, packetsSuccess, out uint numPacketsSuccess);
            }
        }

        // Reset the event to allow proper waiting
        if (eventIndex >= 0 && eventIndex < waitHandlesManualResetEvents.Count)
        {
            waitHandlesManualResetEvents[eventIndex].Reset();
        }
    }
}

Explanation:

• Wait for an event: WaitHandle.WaitAny(waitHandles); ensures the thread only runs when a packet event is signaled.
• Process packets normally: The loop reads packets, processes them, and sends them back.
• Reset the event: After processing packets, waitHandlesManualResetEvents[eventIndex].Reset(); is called to prevent continuous polling.

This should significantly reduce CPU usage.

[Vadim Smirnov]

Great! Thank you for the update! 👍

[Vadim Smirnov]

I’m excited to announce that AmneziaWG support is now available in WireSock Secure Connect v2.1.4!

🔗 Download WireSock Secure Connect

[Vadim Smirnov]

Thank you for your message! Let me clarify a few points:

Interface Name in Commands
Instead of using the placeholder %i, you can safely rely on the WIRESOCK_TUNNEL_NAME environment variable in your scripts and commands. This variable provides the actual Wiresock tunnel name at runtime, ensuring proper command execution.

Table = off Setting
Currently, Table = off is not supported by Wiresock. Could you let us know where you found this setting mentioned in the Wiresock documentation? If it’s listed somewhere, we’d like to correct that reference to prevent confusion.

If you have any additional questions or need further assistance, feel free to let me know!

[Author]

Posts