Forum Replies Created
-
AuthorPosts
-
April 9, 2023 at 1:02 pm in reply to: Lose internet connection after installing Wiresock client on Windows 11 VM #12971
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 forwarded an original e-mail. Please confirm.
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.
Thank you for providing the details. I will conduct some research and keep you informed.
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?
April 3, 2023 at 10:41 am in reply to: Seeking Assistance with DNS Suffix Configuration in WireSock Client #12928Hi 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.
I will look into adding support for your configuration when I have some free time, hopefully during the upcoming weekend.
It’s great to see that you’re testing the driver performance over a 10GB network.
Exploring multithreading is a good approach, as it can help distribute the load across multiple CPU cores and potentially improve performance. For example, in a project I encountered, packets were read by one thread, processed by two additional threads (one for incoming and another for outgoing), and injected into the stack by a fourth thread.
To provide more specific suggestions and help optimize your code, it would be helpful to see a code snippet demonstrating how you’re reading and re-injecting packets per operation. The more data you read from the driver in a single call, the better performance you can achieve. For instance, if you’re currently reading 256 packets per operation, you might try increasing this value to 1024 and see if it improves the results.
-
AuthorPosts