[Vadim Smirnov]

Just a small update on the topic. There are two options available to you for managing the client more easily:

TunnlTo: A Rust project that starts wiresock-vpn-client.exe in the background and provides it with configuration options.
EpexGUI: A C# project that functions similarly to TunnlTo. However, I have created a fork that includes significant modifications, such as directly calling wgbooster.dll instead of wiresock-vpn-client.exe and adding a Wiresock Client installer for x86 platforms. This fork also includes support for transparent (NAT) mode, which can simplify the user experience. While it’s uncertain whether the original author will accept these changes, you can download the latest release of this fork here.
Both options offer several convenient features, such as importing and editing Wireguard configurations and switching between tunnels, which can greatly simplify the user experience when using the WireSock VPN Client.

[Vadim Smirnov]

The term ‘wireguard.exe’ is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Based on this error message, it seems that WireGuard for Windows may either not be installed or hasn’t been added to the Path environment variable. It’s important to remember to restart the CMD or PowerShell console after installing WireGuard for Windows and before running wg-quick-config. This will ensure that any changes made during the installation process take effect and allow you to run the command without any issues.

[Vadim Smirnov]

Hi,

I apologize, but I don’t have one. However, I don’t believe it would be a significant issue to port the C++ code to C#. I’m not an expert in C# but it can be something like this:

        foreach (PFAST_IO_SECTION i in fast_io_section)
        {
            if (Interlocked.CompareExchange(ref i.fast_io_header.fast_io_write_union.union_.join, 0, 0) != 0)
            {
                Interlocked.Exchange(ref i.fast_io_header.read_in_progress_flag, 1);

                var write_union = Interlocked.CompareExchange(ref i.fast_io_header.fast_io_write_union.union_.join, 0, 0);

                uint current_packets_success = (uint)write_union.union_.split.number_of_packets;

                //
                // Copy packets and reset section
                //

                Buffer.BlockCopy(i.fast_io_packets, 0, packet_buffer_, (int)(fast_io_packets_success * Marshal.SizeOf<INTERMEDIATE_BUFFER>()), (int)(current_packets_success - 1) * Marshal.SizeOf<INTERMEDIATE_BUFFER>());

                // For the last packet(s) wait the write completion if in progress
                write_union = Interlocked.CompareExchange(ref i.fast_io_header.fast_io_write_union.union_.join, 0, 0);

                while (write_union.union_.split.write_in_progress_flag != 0)
                {
                    write_union = Interlocked.CompareExchange(ref i.fast_io_header.fast_io_write_union.union_.join, 0, 0);
                }

                // Copy the last packet(s)
                Buffer.BlockCopy(i.fast_io_packets, (int)(current_packets_success - 1) * Marshal.SizeOf<INTERMEDIATE_BUFFER>(), packet_buffer_, (int)(fast_io_packets_success + current_packets_success - 1) * Marshal.SizeOf<INTERMEDIATE_BUFFER>(), Marshal.SizeOf<INTERMEDIATE_BUFFER>());
                if (current_packets_success < write_union.union_.split.number_of_packets)
                {
                    current_packets_success = write_union.union_.split.number_of_packets;
                    Buffer.BlockCopy(i.fast_io_packets, (int)(current_packets_success - 1) * Marshal.SizeOf<INTERMEDIATE_BUFFER>(), packet_buffer_, (int)(fast_io_packets_success + current_packets_success - 1) * Marshal.SizeOf<INTERMEDIATE_BUFFER>(), Marshal.SizeOf<INTERMEDIATE_BUFFER>());
                }

                Interlocked.Exchange(ref i.fast_io_header.fast_io_write_union.union_.join, 0);
                Interlocked.Exchange(ref i.fast_io_header.read_in_progress_flag, 0);

                fast_io_packets_success += current_packets_success;
            }
        }

[Vadim Smirnov]

The NDISAPI is a lightweight layer over the driver’s interface, and it does not have its own threads. However, if you use the NDISAPI through the simple_packet_filter class, then this class is responsible for creating the underlying thread that reads and writes packets.

[Vadim Smirnov]

You can configure access to a desired domain over VPN if it consistently resolves to the same IP addresses. For instance, ntkernel.com resolves to 95.179.146.125. In this case, you can add this IP address to the AllowedIPs to access it via VPN. However, if the domain name resolves to varying IP addresses, such as with dynamic DNS or a CDN hosted site, this method is not supported.

[Vadim Smirnov]

There are two possible approaches to Ethernet bridge implementation:

1. Turn on promiscuous mode on both bridged interfaces and relay packets between these.
2. Do MAC address translation. This approach is similar to how IP address NAT implemented.

EBRIDGE sample implements the first, it is a bit slower (due to using promiscuous mode) but easier to understand. The only complex part is bridging Wi-Fi to wired LAN, where you still need the MAC address translation.

I would also recommend unchecking the IPv4/IPv6 protocols on the NIC’s you are bridging, especially if you are using MAC address translation because it tends to confuse some routers (two IPs on the same MAC).

Since both your network adapters are wired, the simple approach should work. Just forward packets received from one to another and vice versa without changing them.

[Vadim Smirnov]

You are right, only IP addresses are currently supported.

It is possible to monitor DNS queries and maintain a dynamic database of IP addresses translated to specified FQDNs. But this will only work for traditional DNS, if you are using DNS over HTTPS then these DNS requests cannot be intercepted and traffic routed correctly. I’m not sure if such a feature is in high demand, but I’ll consider adding it when I have some free time.

[Vadim Smirnov]

Thanks for reporting this. Hopefully I have fixed this in v1.2.16. Please give it a try.

[Vadim Smirnov]

Glad you finally solved it! ☺️

[Vadim Smirnov]

If this does not work only on a particular Wi-Fi, then the first thing I would do is check the MTU. Try to put 1380 or even 1280.

[Vadim Smirnov]

Thanks, I checked the log and it looks strange. The tunnel appears to be broken at the very beginning, immediately after receiving the response to the handshake. I also noticed that you are running a SOCKS proxy on the same host as the WireGuard Server. I’ve never tested this setup and can’t exclude some sort of network collision going on. Have you tried disabling the SOCKS5 proxy feature? Also could you update to the latest WireSock client 1.2.15? It will be easier if we use the same build.

[Vadim Smirnov]

Are you by any chance running two wireguard clients with the same configuration (keys, etc.)? In such a case, two (or even more) clients will compete for the same slot, causing tunnel errors from time to time.

If not then some logs could help to understand the problem.

[Vadim Smirnov]

В режиме прокси тоже не работает?

Можно запустить как приложение и посмотреть/записать логи. Должно стать понятнее.

[Vadim Smirnov]

Yes, you are right about ExitLag, it does indeed use WinpkFilter to intercept and process network traffic. However, I’m afraid the only way I can suggest for researching how it affects traffic flow is to create two winpkfilter-derived drivers and set one above and one below ExitLag in the stack. Thus, you can capture and record the traffic from these two drivers, save to a PCAP file, and analyze the difference in Wireshark.

[Vadim Smirnov]

Hmm, looks like the problem is in v2rayN. Perhaps his SOCKS5 implementation has issues with UDP support.

[Author]

Posts