Forum Replies Created
-
AuthorPosts
-
Version 3.2.16 is over two years old and no longer supported. Could you try to reproduce the issue with a latest version (3.2.24)? If yes, then could you please collect full (or at least kernel) memory dump and e-mail to support?
Well, you can install winpkfilter the host or/and guest (if VM has Windows inside). It should work either way.
Do you mean Hyper-V virtual machine? Have you installed WinpkFilter inside VM or on the host? Try running ListAdapters, it should show you available network interfaces…
ARM64 drivers are available to the registered customers starting v.3.2.29.
where to download GRETunnel sample? i can’t find it on Github.
Yes, that’s right. GRETunnel and other old samples are included into the demo package
Windows Packet Filter demo package contains a sample named GRETunnel, which demonstrates how to attach/remove new headers to/from the network packets. Add GRE payload encryption and you get a simple VPN tunnel.
This another sample which with a different approach. It redirects selected TCP connections to the local proxy and then forwards theese through the SOCKS5 proxy. Just add an SSH client with SOCKS support (PuTTY, an example) and the result is VPN over SSH tunnel.
So, basically with winpkfilter you have everything needed to implement any type of VPN. The details depend on your concrete needs. An example, for Wireguard implementation you should insert/remove UDP headers (plus some protocol specific data) instead of GRE, but the idea is the same.
February 7, 2020 at 12:36 pm in reply to: Concurrency handling of ReadPackets and SendPackets #11262Yes, SendPacket/s return immediately.
February 7, 2020 at 10:19 am in reply to: Concurrency handling of ReadPackets and SendPackets #11260Yes, entire library is thread safe.
The only thing to note about it is that there is only one instance of each network interface (setting mode, event and etc..) and only one copy of each packet (if one thread taken packet others threads won’t be able to get it). Though for one customer we created a special build with multiply filtering layers (e.g. packet injected on one layer can be picked up again on the next layer).
From the experiments I did, the only way I found to redirect some packets and let everything else pass is to use MSTCP_FLAG_TUNNEL for the adapter mode and then specify 2 filters: the first with the action FILTER_PACKET_REDIRECT that intercepts the packets I’m interested in, and then a second filter with action FILTER_PACKET_PASS to let everything else pass through. Am I correct?
Yes, you are right! There is also an alternative approach, when adapter is in tunnel mode then REDIRECT is a default action, so you can load one or more filters to pass selected traffic over and everything else will be redirected to your application automatically.
Or is there a way for example to set the adapter mode in something like “let everything pass” and then use a single filter with the action FILTER_PACKET_REDIRECT?
No, it won’t work. Adapter mode defines if network interface is filtered or not (independently in each direction). If it is not then loaded filters are not applied and all the traffic is passed over.
Below sf assigned a copy of the ft.StaticFilters[0]
var sf = ft.StaticFilters[0];
and then the copy is initialized. So, you should assign it back after initialization or define sf as a reference to ft.StaticFilters[0]
ref var sf = ref ft.StaticFilters[0];
January 5, 2020 at 8:00 pm in reply to: Windows Packet Filter can not install on Windows 1809 1903 1913 #11244That depends of which installer you have downloaded. Two of them (MSI ones) install driver only (x64 or x86 depending on the platform), the third one contains more demo binaries and includes ndisapi.dll.
The source code for ndisapi can be found here. You can use as a static or dynamic library (or even .net class library) depending on your requirements.
January 3, 2020 at 7:19 am in reply to: Windows Packet Filter can not install on Windows 1809 1903 1913 #11242Support of NDIS 3.0 was removed from Windows 10 starting 1809, so the NDIS 3.0 of VirtNet can’t be used anymore. You can check this thread for the details and temporary NDIS 6.0 VirtNet driver replacement:
However, this problem is not related to Windows Packet Filter, so if you have experienced any problems about it then could please provide the details.
November 22, 2019 at 6:31 pm in reply to: Why is WinPkFlt a LWF and not an NDIS Intermediate Driver ? #11234No, in fact NDIS 6.x LWF is a direct replacement for NDIS 5.1 IM drivers.
November 20, 2019 at 6:03 pm in reply to: Why is WinPkFlt a LWF and not an NDIS Intermediate Driver ? #11232In two words, NDIS IM is a NDIS 5.1 driver (though, it can be used in Vista, but in fact this is a compatibility mode) while LWF is NDIS 6.x and has a native support.
Yes, sure!
-
AuthorPosts