Forum Replies Created
-
Posts
-
I am grateful for your patience, regretfully the last few weeks were quite busy. However, I’m also interested in this feature, and I hope I will have time to work on this during the weekend.
First, thank you for your interest and valuable feedback, it is really appreciated.
1. Wiresock VPN client is based on WinpkFilter driver which has the registry parameter (can be set using https://www.ntkernel.com/docs/windows-packet-filter-documentation/ndisapi-c-2/setadaptersstartupmode/) and defines the default adapters filter mode. For example, if set this parameter to MSTCP_FLAG_SENT_TUNNEL | MSTCP_FLAG_RECV_TUNNEL then network traffic will be blocked by default and can be re-enabled only by the application.
So if you create a DWORD value named StartupMode under HTLM\CurrentControlSet\Services\ndiswgc\Parameters, assign to 3 and reboot, then it will result in the desired behavior. However, this is a global setting that affects all network interfaces, so it may result in undesired effects on other network interfaces (if you have more than one). I will consider adding this option in the next version in some more convenient form.
2. Meanwhile, the amount of data sent/received over the tunnel is not reported (although it is available). I think to add a simple tray icon-based application to report the tunnel stats. If you have other options in mind, then please let me know.
3. Current implementation is simple, the given name pattern is checked for being a substring in the process name. For example, ‘chrome’ covers any process which contains ‘chrome’ substring as a part of its name, e.g. WinChrome.exe, AxChromeAi.exe etc.
According to the command line, you run wiresock service as a console application. Please note that in NAT mode, the application has to enable built-in Windows routing and the related API function requires Administrator privilege. Please try to run CMD as Administrator and then execute
wiresock-service run -mode nat -interface mywgserver -log-level noneThe only thing you need is a couple of IPHELPER API functions, GetExtendedTcpTable and GetExtendedUdpTable. Then just match IP/port information against information extracted from the packet.
If you need to do that in C# then here is the sample code https://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G
Hi,
The only sample which demonstrates process lookup (using IP Helper API) is Socksify, and it is in C++:
https://github.com/wiresock/ndisapi/tree/master/examples/cpp/socksify
However, it is not a big deal to integrate process_lookup.h into .NET C++/CLI mixed class library (ndisapi.net) and use it there.
Socksify was designed to be easy to understand, and it implements only a limited number of features. SOCKS5 password authentication is not supported, but it is not a big deal to add it if needed.
Yes, sure, I can sign your custom drivers build and as well as generate and sign MSI installers for Windows 7 and higher.
You can send e-mail to support(at)ntkernel.com if you have any further questions.
An interesting idea, probably it would really be possible to use a SOCKS5 proxy (e.g. Dante which supports UDP) for this purpose.
I will try to make some tests or even working demo over the weekend.
But what if we try to get rid of windscribe at all and replace it with simple obfuscation service?
For example, I could add another parameter to wiresock config file:
HandshakeFwd = test.sshvpn.me:52220
If this parameter is present in the config file then:
1. Wiresock client instead of sending handshake packet to Warp server will obfuscate it (add random size header for example) and send to test.sshvpn.me:52220 instead Warp server.
2. Service listening test.sshvpn.me:52220 extracts original handshake and forwards it to Warp+ server. Here we have two options, if DPI blocks only handshake packets we can preserve source IP address and UDP port of the packet so that Warp+ server will send the handshake response directly to the wiresock skipping step 3.
3. If DPI also blocks handshake responses then service forwards handshake from its IP address, receives handshake response from Warp, obfuscates it and forwards to wiresock.
4. Wiresock receives handshake response, optionally de-obfuscates it and sets the tunnel up.
Building such a service application and extending wiresock to use it is not that difficult. If you’re interested, we can try this approach.
It is possible to bind to a specific network adapter, but in this case it will not be enough, because wiresock depends on handshake and response intercepted at the NDIS layer, and this will not happen if they are sent over a different network interface. I will think if I can change the design to avoid this dependency.
If I understand correctly, you have no server side control as it is a Warp server and therefore cannot use traffic obfuscation like https://github.com/dndx/phantun?
P.S. Just an idea and I’m not sure if it will work out of the box. But what if we configure another server/service to forward obfuscated handshake/response packets between wiresock and Warp+? This is what your secondary VPN service does…
Since Wiresock client is implemented very similar to Windows version of Warp then I think it should be feasible. But I need a better understanding on what is going on. Could you post a link to the wstunnel you have used? There are at least two different wstunnel projects on github…
Hmm, sounds interesting, however, could you provide some more details about your configuration? I’m not sure I understand how it works… For example, if first handshake packet is discarded by DPI then why the subsequent handshakes (sent every two minutes) are not? Or all outgoing handshakes are dropped, but once tunnel is established the subsequent handshakes sent by the remote peer while DPI does not expect this behavior?
Although, if it works, I think it is a matter of time before the DPI starts dropping handshakes in both directions. And maybe we could come up with a better way to avoid blocking…
Another possibility is that Windows tries to repair WiFi connection by disabling and re-enabling it. This operations effectively switch off filtering, so you have to monitor the network adapters changes by setting an adapter list change event and reconfiguring filtering.
I think it will be easier to discuss if you post your code here, may be you are doing something wrong.
Neither ndisapi nor the NDIS driver have no time limit.
Of course, I cannot guess what exactly happens on your PC, however, for example, it can happen if you have LAN and WiFi (or LTE, or etc..) network interfaces on your computer and both are connected to your router. My laptop is configured this way. Now lets assume that your application is filtering (and blocking packets) on wired network adapter only. By default, Windows uses a wired network adapter, so once you start blocking packets, it looses connectivity as expected. However, Windows detects that the Internet is not available through the default adapter, and after a while it switches to Wi-Fi Connection and you are able to browse Internet again.
