[Vadim Smirnov]

WireSock uninstall removes all components, but under some circumstances, a reboot may be required afterward. For example, some components may be marked for deletion but not immediately removed.

[Vadim Smirnov]

Thank you for the detailed explanation. I will conduct a more thorough analysis. However, I have a hypothesis. It seems the system might prefer using IPv6 DNS over IPv4, which could be causing the behaviour you’re observing. Could you please perform a quick test? Disable the IPv6 protocol on your network interface in the Control Panel connection properties and check if it makes a difference.

[Vadim Smirnov]

I apologize for the delay; I’ve been quite overloaded these past few weeks. Could you please provide a detailed description of the issue? In the logs I previously reviewed, I did not notice any problems. However, I suspect that sending DNS queries to different DNS servers could cause issues with CDN-based services. I need a detailed description, preferably with screenshots or a video recording of the problem, as well as the WireSock textual log and PCAP files. This will allow me to conduct a thorough analysis.

[Vadim Smirnov]

Could you please disable Windows Firewall (or any other firewall you might have) and check if the issue persists?

[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?

[Author]

Posts