Forum Replies Created
-
Posts
-
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.
Of course, you’re welcome to proceed. However, acquiring the Source Code could significantly streamline the process. Should resource limitations arise, please feel free to reach out to me privately. We can discuss a more favorable price for the Source Code to accommodate your needs.
Hello,
Certainly, you can rename the driver binary. However, it’s important to be aware that this change will not affect the device’s name, which will remain unchanged.
As of now, WireSock is designed to support only one active tunnel at a time, regardless of the mode. I am aware of the growing need for the ability to operate multiple tunnels simultaneously and am contemplating adding this feature in future releases. However, my availability for this project is significantly limited due to my full-time job that often extends into weekends, alongside my family obligations. Additionally, working through the night is no longer a viable option for me, as it might have been previously.
However, I am hopeful that my schedule will soon allow me to devote additional time to this endeavour.
When you connect to a VPN, it usually routes all your traffic, including LAN traffic, through the VPN tunnel by adding a default route. However, setting
0.0.0.0/1and128.0.0.0/1on your VPN adapter creates specific routes that prioritize external traffic through the VPN, while excluding local network addresses. This means local network traffic, which typically uses private IP ranges like192.168.x.x, doesn’t match these VPN routes and instead uses the default local routing. This setup allows direct access to LAN devices without routing their traffic through the VPN.The Wiresock VPN client in NAT mode operates differently from typical VPN configurations. It doesn’t set up a virtual VPN network interface or alter your routing table. Instead, it selectively routes traffic based on specified parameters like AllowedIPs, DisallowedIPs, AllowedApps, and DisallowedApps. For those seeking functionality akin to the original WireGuard for Windows, the Wiresock VPN Client can be executed with the
-laccommand line option. This mode enables Wiresock to configure a virtual network interface and modify the routing table, similar to traditional VPN clients. However, it’s important to note that while the NAT mode permits usage by non-admin users, the mode involving a virtual network interface necessitates administrative privileges or needs to be run as a Windows service.Are you operating Wiresock in adapter mode (using the -lac command line option) or in adapterless mode? The former mode closely resembles the behavior of the original Wireguard client. Are you encountering this issue exclusively in one of these modes, or does it occur in both? A more detailed description of your network setup would be immensely helpful for further analysis.
If your Wireguard server is located within your LAN, it’s possible to access local devices via the tunnel. However, if this isn’t applicable in your scenario, you will need to add the addresses of these devices to the ‘DisallowedIPs’ section of your configuration.
Could you please let me know the details of your AllowedIPs configuration? If your intention is to keep your LAN outside the scope of the Wireguard tunnel, you have the option to incorporate ‘DisallowedIPs’ into your configuration file. As an example, in my setup, I utilize the following configuration:
DisallowedIPs = 192.168.3.0/24, 10.10.1.0/24
