Forum Replies Created
-
Posts
-
Give the ARM64 build of WireSock VPN Client a try on your device! This version broadens compatibility and offers improved performance for devices with ARM64 architecture.
Тут проблема, так как DNS запросы от хрома идут в контексте DNSCACHE и отделить их в общем случае невозможно. Как вариант, можно убрать DNS настройки из конфига Wireguard, а в хроме включить DNS over HTTPS. Тогда DNS от хрома будут резолвится через HTTPS соединение, которое будет вложено в Wireguard туннель. А стандартные запросы через DNSCACHE пойдут на DNS сервер прописанный в системе.
Thank you for sharing your issue with the Wiresock client in your Windows 11 VM on VMWare Fusion running on a MacBook Air M1 host. It’s unfortunate to hear that you are experiencing connectivity issues upon installation. In order to better understand and assist with your problem, could you please confirm if you are using the ARM64 build of Windows 11?
allows WireGuard clients to connect to the server’s Internet/LAN
That’s correct; Wireguard clients can access the server’s Internet/LAN, but the reverse direction is not supported. In other words, it is not possible to access Wireguard clients via the server’s public interface. This limitation arises because, in order to establish a connection with a Wireguard client through the server’s public interface, a peer would need to know the client’s internal IP address. However, the client’s internal IP is not publicly known or advertised, which makes direct access to Wireguard clients unfeasible in this configuration.
While it is technically possible to map selected TCP/UDP ports on the external interface to Wireguard clients, the current version of WireSock VPN Gateway does not support port forwarding. This means that, as of now, direct access to Wireguard clients through the server’s public interface remains unfeasible using WireSock VPN Gateway.
However, when I try to reach LAN behind the Wiresock VPN Gateway Server, it does not route to local network.
NAT, or Network Address Translation, operates in a unidirectional manner. This means that it is not designed to route packets from the external interface to the internal network unless the connections associated with these packets were originally established from within the internal network. In other words, NAT allows internal devices to communicate with external networks, while simultaneously providing a layer of security by preventing unsolicited incoming traffic from directly accessing the internal network.
The message “Force routing DISABLED!” simply indicates that manual routing is not required for the internet interface in this case. While manual routing is necessary for some types of WAN connections, in this situation, the routing will be managed by the Windows TCP/IP stack.
In practice, the VPN Gateway implements Network Address Translation (NAT) from the WinTun/Wireguard virtual network adapter to the external network. This NAT functionality is unidirectional, meaning that a Wireguard client can access external resources, but an external host cannot establish a connection to the Wireguard client. If you encounter issues with VPN client communications, it is recommended to check the Windows Firewall settings to ensure proper connectivity.
I’ve sent you a download link via email for the recent source code corresponding to version 3.4.2. If you have any additional questions or require further clarification, please don’t hesitate to ask.
Microsoft Store Applications can be somewhat challenging to identify, as they operate within host processes. This makes pinpointing their activities more complex compared to traditional desktop applications.
When I have some spare time, I will conduct further research to explore potential methods for identifying these applications more effectively.
Apologies for any confusion. To clarify, the SendPacketToAdapter function provides the capability to send any arbitrary Ethernet frame to the network, regardless of its content or structure. This includes both well-formed packets and those that are malformed or contain pure garbage. If the adapter handle is correct, you can have confidence that the packet was successfully transmitted to the intended destination.
If the packet was not received by the destination host, it is recommended that you verify the packet’s correctness. Errors in the packet structure, content, or addressing information may cause it to be dropped or not processed by the receiving host. Ensure that the packet adheres to the relevant protocol specifications and that all required fields are correctly populated.
Hi Andrea,
Thank you for the update. I recently responded to your email. As mentioned, I want to further test several modifications, including the new driver registry parameter designed to expand the internal driver packet pool without rebuilding the driver.
I am also working on a project that necessitates the efficient transfer of packets over high-speed 10 Gbps interfaces. Consequently, I plan to rigorously assess this build in the coming days, confirming its reliability and compatibility before proceeding with an official release.
If you require the updated version urgently, I can supply you with the latest code snapshot from the repository.
Could you please test this experimental build?
P.S. Please note to download v3.4.2, I had to fix the link.
Have you confirmed whether your system utilizes jumbo frames when the Windows Packet Filter option is unchecked or the driver was uninstalled?
I have conducted tests on the Windows Packet Filter over a 10 Gbit network and did not observe any significant performance degradation solely from enabling the driver. It’s important to note that the test system was quite powerful, equipped with an E-2378G processor and Broadcom P210tep NetXtreme network interfaces. Furthermore, even when running a test packet filtering application with minimal output (such as dnstrace), the bandwidth was not substantially affected.
Would you mind sharing your hardware configuration, so we can make a rough comparison?
Hi there!
Firstly, I want to thank you for your kind words and appreciation of our work on WireSock! It’s always great to hear that our project is helpful to users like you. I understand that you are trying to use WireSock as a client to access your work’s internal network and need to configure a DNS suffix for the adapter.
From the information you’ve provided, it seems like you’ve managed to find a workaround using PowerShell. While this method works for now, I can see how having a more seamless integration with WireSock would be beneficial. I’ll be sure to do some research and look into potential solutions or improvements to better support the DNS suffix configuration in WireSock. In particular, in instances where it is available (Windows 10 and later), SetInterfaceDnsSettings could potentially be utilized. For earlier versions of Windows, similar functionality may be achievable by manipulating the Windows registry.
Again, thank you for your feedback and for sharing your experience with us. Your input is invaluable in helping us improve our project for all users.
