[Vadim Smirnov]

The file tcp_local_redirect.h reroutes selected outgoing connections to a local proxy and can be modified to redirect these packets to a remote host. However, it does not incorporate any SOCKS5 protocol logic. I should note that I may not fully understand your requirements, as forwarding entire IP packets is typically utilized in various types of tunnels rather than in proxies.

[Vadim Smirnov]

Transmitting entire IP packets to a SOCKS5 server is theoretically possible, but SOCKS5 is inherently designed for TCP/UDP connections and does not natively support the transmission of raw IP packets. Modifying the protocol to handle IP packets would necessitate significant changes on both the client and server sides.

ProxiFyre consists of two components: a redirector that forwards connections to a transparent local proxy, and the transparent local proxy itself, which functions as a SOCKS5 client. The redirector has access to raw network packets (Ethernet frames), whereas the local proxy operates at the transport level (TCP, UDP). Therefore, technically, you can use the redirector component to intercept IP packets and send them to your proxy.

[Vadim Smirnov]

Hello Alex,

I have added an exception to CleanTalk anti-spam, hopefully you won’t run into this again.

[Vadim Smirnov]

Thank you for sharing the logs. While I don’t see any obvious problems in the DNS traffic, could you please remove the alternative DNS servers from the configuration, leaving only a single one, such as DNS = 1.1.1.1, and check if the problem persists? The issue might be that DNS queries are being redirected to alternative DNS servers using a round-robin algorithm. For example, three DNS queries originally destined for 10.0.0.1 are redirected as follows:

10.128.0.7 9.9.9.9 DNS 78 Standard query 0x1cc5 AAAA gateway.discord.gg
10.128.0.7 1.1.1.1 DNS 78 Standard query 0x94d7 A gateway.discord.gg
10.128.0.7 1.0.0.1 DNS 78 Standard query 0x5ceb HTTPS gateway.discord.gg

While all requests are properly responded to by the requested DNS servers, I suspect there might be some sort of collision with CDN-based services.

[Vadim Smirnov]

Configuring a virtual network interface requires elevated privileges; therefore, the answer is no. Transparent mode can be used without these privileges, but as you’ve observed, it may cause some issues. If you can replicate the problem and capture the traffic (log and pcap files) using the “log-level all” option, I can try to diagnose and fix the issue.

[Vadim Smirnov]

P.S. There is a non-public update you might consider trying:

https://www.wiresock.net/downloads/wiresock-vpn-client-x64-1.2.41.1.msi

https://www.wiresock.net/downloads/wiresock-vpn-client-ARM64-1.2.41.1.msi

https://www.wiresock.net/downloads/wiresock-vpn-client-x86-1.2.41.1.msi

[Vadim Smirnov]

In your nslookup output, you have an IPv6 address for the DNS server. In transparent mode, WireSock translates addresses in DNS requests, but it can only replace IPv6 with IPv6 and IPv4 with IPv4. Since your configuration lacks an IPv6 DNS server, nslookup requests to fd00::#### fail. Please consider using WireSock in virtual adapter mode. In this mode, WireSock adds DNS addresses to the virtual network adapter, similar to the standard WireGuard for Windows.

In the log DNS queries from Chrome do not seem to have any problems:

2024-05-15 15:56:48 [FILTER]: C:\Program Files\Google\Chrome\Application\chrome.exe : DNS : 10.0.8.71:61254 -> 9.9.9.9[10.0.0.1]:53
2024-05-15 15:56:48 [TUN]: DNS request to 10.0.0.1 forwarded to 1.0.0.1
2024-05-15 15:56:48 [TUN]: DNS response from 1.0.0.1 translated as from 10.0.0.1
2024-05-15 15:56:48 [TUN]: DNS response from 1.0.0.1 translated as from 10.0.0.1
2024-05-15 15:56:48 [TUN]: DNS response from 1.0.0.1 translated as from 10.0.0.1

[Vadim Smirnov]

To provide more accurate advice, I require additional details:

1. Are you operating in transparent or virtual adapter mode?
2. Could you please share your Wireguard configuration, omitting any keys?
3. Lastly, would it be possible for you to gather the logs and pcap files to aid in further analysis?

[Vadim Smirnov]

To give better advice on your network setup, it would help to see more of the configuration file. If you’re encountering conflicts between your local and remote network subnets, consider utilizing the 0.0.0.0/0 setting in conjunction with the AllowedApps feature for specific applications. This configuration ensures that only selected applications will utilize the VPN tunnel. However, it’s important to closely examine your network requirements to ensure this approach is suitable for your situation.

[Vadim Smirnov]

Are you running WireSock with administrator privileges? Additionally, are you utilizing it in transparent mode or using a virtual adapter mode?

[Vadim Smirnov]

One Wireguard endpoint generally suffices, as it can tunnel both IPv4 and IPv6 traffic, regardless of whether the underlying connection is over IPv4 or IPv6. Why would there be a need to establish separate tunnels for IPv4 and IPv6? Is it necessary to specifically tunnel IPv4 traffic over IPv4 and IPv6 traffic over IPv6?

[Vadim Smirnov]

Hello,

I will address both queries simultaneously. I can confirm that WinpkFilter is capable of handling 10Gbps networks. Unfortunately, I haven’t had the opportunity to test it on a 25Gbps network, so I am unable to provide any data for that. If you have a sufficiently fast CPU and do not require intensive CPU processing for the packets, you can manage packet reading and reinjection using a single thread (refer to the simple_packet_filter class for an example). Nonetheless, managing a 10Gbps bandwidth with complex packet processing can be challenging. For instance, in the transparent mode of Wiresock, I employed the queued_packet_filter, which utilizes four working threads per network interface: one for reading packets, another for processing, and two additional threads for reinjecting packets in each direction. While synchronization between 4 threads indeed has its costs, it’s important to note that the results have been remarkable, especially when compared to the official in-kernel implementation of WireguardNT.

[Vadim Smirnov]

Could you clarify if this behavior is unique to Virtual Adapter mode, or does it impact Transparent mode as well? Since these modes are implemented in distinct manners, their behaviors might vary.

[Vadim Smirnov]

In the 1.2.39 build, I’ve adjusted our approach slightly. Instead of extracting the real source IP and port from the SOCKS header, which in your instance contained incorrect data, I’ve opted to directly assign the Wireguard server’s IP and port. This tweak seems to be more reliable, especially since SOCKS is only involved for the handshake process. This modification has been effective for both your setup and mine, so I’m considering it for inclusion in the mainline implementation.

Additionally, I’m curious about the need for handshake masquerading in the US. It’s clearly beneficial in countries like Egypt, Russia, and probably Iran too, as indicated by high traffic from this region. But in the US context, is this a necessary feature, or is it more about having the option to bypass potential Wireguard blocks?

[Vadim Smirnov]

Here is another test build. Please give it a try.

1. For ARM64 systems: Download WireSock VPN Client ARM64 Version 1.2.39.1
2. For 64-bit systems: Download WireSock VPN Client x64 Version 1.2.39.1
3. For 32-bit systems: Download WireSock VPN Client x86 Version 1.2.39.1

P.S. It seems that you’re experiencing a type of NAT collision when the SOCKS protocol is passing through the NAT. I’ll take some time to think this through.

[Author]

Posts