Forum Replies Created
-
Posts
-
The official Wireguard client employs a UDP socket and relies on the TCP/IP stack for packet reassembly. In contrast, WireSock, prioritizing performance, directly retrieves packets from the NDIS layer, bypassing the TCP/IP stack. The current version of WireSock does not reassemble fragmented Wireguard packets, operating under the assumption that the MTU is appropriately chosen to prevent fragmentation. While this approach is optimal for performance, it can be confusing for users. Recognizing this, I plan to address and rectify this issue in WireSock when time allows.
Typically, these errors occur in the case of packet fragmentation. Could you please try reducing the MTU and also check if using virtual adapter mode (-lac) makes a difference?
I don’t think it’d be because the virtual adapter setting also uses the same MTU I’m assuming.
Yes, you are correct, but the MTU is enforced using different techniques in adapter and adapterless modes.
It’s generally advisable to adjust the MTU on both the client and the server. Remember, changing MTU settings is often a process of trial and error, and what’s optimal can vary depending on your specific network conditions.
Hello,
The most notable distinction between WireSock’s virtual adapter mode and its default mode is that the former requires Administrator privileges to configure the virtual network adapter, while the latter does not. Regarding the throughput differences you’ve observed, this is intriguing. In my tests using WireSock in default mode on a 10 Gbps network and iperf3, the speeds reached 5.34 Gbit/sec, compared to 3.66 Gbit/sec for downloads when using the official WireGuard client. Could the MTU settings in your configuration be influencing this? What is the MTU value you are using? Additionally, have you tried reducing the MTU to 1380 to see if it impacts performance?The precise cause of the issue is unclear, but by using the
-log-level allcommand line option, Wiresock can capture and log all traffic (including both unencrypted and encrypted data) traversing the tunnel into PCAP files. Examining these PCAP files could provide valuable insights into what might have gone wrong in this particular situation. It is recommended to analyze these files for a more detailed understanding of the issue.An IP address in the range of 169.254.xxx.xxx is known as an Automatic Private IP Address (APIPA). This is assigned to a computer or network device when it’s configured to obtain an IP address automatically, but the device is unable to find a DHCP server (a network server that automatically provides and assigns IP addresses, default gateways and other network parameters) to give it an address.
This often happens when a device fails to obtain an IP address from a DHCP server, either because the server is not available, or because there’s an issue with the network connection. The 169.254.xxx.xxx address allows the device to communicate with other network devices that have similarly self-assigned IP addresses, but it won’t be able to communicate outside its local subnet. This is often a temporary state, until the device can properly obtain an IP address from a DHCP server.
There appear to be two potential scenarios: firstly, your VPN might be inaccurately assigning private IP addresses from inappropriate Internet realms; secondly, WireSock could be facing challenges in setting up the virtual network interface with the correct address. To resolve this, ensure that you operate WireSockUI as an Administrator, since it requires these elevated privileges to successfully configure the virtual network interface.
I’m sorry for the delayed response, just got some spare time and returned to this topic to check the required setup. I’m glad that you were able to find the combination which resolves the issue. The after install reboot is probably can be explained that Kerio uses the NDIS filter driver similar to the one utilized by wiresock and network stack can’t rebind dynamically without a reboot. If my assumptions are correct the conflict with Kerio probably can be also addressed by changing the order of NDIS filter drivers. Not sure if it’s worth spending time on this right now but if there will be more requests for compatibility with Kerio, then I will do the research.
It appears that there is a software conflict with Kerio. Could you please provide more detailed instructions on the setup needed for the test VM to replicate this issue?
К сожалению нет и сомневаюсь, что найду время посмотреть в эту сторону. Основа WireSock кросс-платформенный BoringTun, но интеграция в ОС сильно завязана на архитектуру Windows.
I believe the issue you’re encountering is indeed related to the nature of how Windows machines typically resolve network names and how VPNs, particularly those using NAT, handle network traffic.
In a standard Windows network, machine names are often resolved using NetBIOS or LLMNR (Link-Local Multicast Name Resolution). These protocols rely on broadcast or multicast packets, which are not designed to be routed across different networks, such as those segmented by VPNs.
When a VPN is used, especially with NAT (Network Address Translation), these broadcast packets do not traverse through the VPN tunnel. This is because NAT changes the network address information in the IP packet headers, and VPNs encapsulate these packets, making them unreadable to devices not part of the VPN network.
Therefore, the inability to resolve Windows machine names over your VPN setup is an expected behavior. For a solution, you might consider using DNS for name resolution, which can work across different networks when properly configured. Alternatively, setting up a WINS server could also address this issue.
Presently, Wiresock doesn’t support passing the private key in any way other than directly through the config file. While the core library technically allows for such functionality, it hasn’t been implemented in the current version of the software. However, it’s worth noting that this feature might be considered for future versions of Wiresock.
In the meantime, you may want to explore the configuration encryption method introduced in the “Encrypting/Securing the WireSock Config File” thread. This method involves encrypting the configuration file using LocalSystem credentials and storing it in a secure folder, offering a viable solution to protect your WireGuard network’s configuration until more flexible key handling options become available.
Привет!
В России пока трюк с SOCKS5-прокси вроде работает. У меня есть идея сделать этот механизм более гибким, например, добавив возможность использования локального SOCKS5 (shadowsocks). Также интересной выглядит идея использовать в этом качестве SSH3, но пока там отсутствует интерфейс для SOCKS5-прокси.
Regrettably, the locations for captured packets and log files in Wiresock are not configurable. This means that it’s not possible to direct Wiresock to save these files to a different drive or a specific location of your choosing.
It seems there might be an issue with the Wireguard server or the network route. Gathering additional log entries would be beneficial, particularly to see if any handshakes received responses. Note that VPN restrictions can vary based on your location. For instance, in certain countries like Russia, Wireguard protocols might be blocked, but using a SOCKS5 option for the handshake can circumvent these restrictions. Also, have you attempted to use the same configuration on both your phone and PC at the same time? Employing the same key (configuration) across multiple devices can lead to erratic behavior.
