Forum Replies Created
-
Posts
-
This task is achievable, albeit requiring a bit of effort. Wiresock would need to intercept and decode all DNS responses, subsequently maintaining dynamic AllowedIps/DisallowedIps tables. I concur that this could be an intriguing feature. I will endeavor to allocate some spare time to work on its implementation.
Это возможно сделать, однако есть пара моментов и видимо придется несколько пересмотреть существующую архитектуру. В настоящее время при перехвате первого пакета для новой TCP сессии и непустом списке AllowedApps/DisallowedApps в обрабатывающем потоке через IP Helper API запрашивается таблица текущих соединений и выясняется контекст процесса. Результаты этих запросов кешируются, но само по себе это довольно дорогая операция, которая при большом количестве создаваемых соединений может замедлять сеть. Если добавить сюда еще и проверку переменных окружения, это может стать неприемлемо дорого. Так что пожалуй для начала надо будет добавить отложенную обработку пакетов для новых соединений, чтобы не тормозить сеть. Постараюсь найти время поработать над этим.
In the Windows Packet Filter v3.4.0, we’ve made a minor update to the structure layout for static filters in order to comply with ARM64 memory alignment requirements. To resolve any issues with your static filters, simply rebuild your code using the updated common.h file.
At present, the WireSock VPN Client is unable to detect processes operating within containers, including those on the Universal Windows Platform (UWP) and the Windows Subsystem for Linux (WSL). Consequently, you cannot configure the WireSock VPN Client to selectively tunnel applications running within WSL, such as Firefox in your particular situation.
I hope that IP leakage is not a common issue while using a VPN client, as it is designed to protect your privacy and maintain anonymity. However, if you have a proven case of IP leakage, I would be more than glad to analyze the situation and help find a solution.
No, setting directory prefix wildcards in allowed and disallowed apps is generally not supported. However, if you include “C:\Program Files (x86)\Steam\steamapps\common” in the list of allowed apps, it should grant access to all files within that folder.
Hey, I apologize for the delay in getting back to you. I’ve had very limited time recently, and I devoted most of it to preparing the ARM64 build. I understand the importance of adding support for your configuration, and I will do my best to allocate some time to address this issue soon. Thank you for your patience and understanding.
Thank you for the update; I’m pleased to hear that everything is working now. By the way, you might also consider using WireSockUI, as it provides support for the ARM64 platform.
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.
