Forum Replies Created
-
AuthorPosts
-
August 26, 2022 at 12:04 pm in reply to: [WireSock] Can’t tunnel cmd or powershell using AllowedApps #12320
I just did a quick powershell test with the command line below, and it was correctly intercepted and redirected through the tunnel:
Invoke-WebRequest "http://www.wiresock.net/downloads/wiresock-vpn-gateway-x64-1.0.31.1.msi" -OutFile "wiresock-gateway-x64.msi"
I suspect you are expecting child processes launched from cmd or powershell to be tunneled. Note, however, that these child processes have different names and are therefore skipped by the filter. Of course, it is possible to extend the filter for child processes, but initially, I had no such intention.
August 16, 2022 at 1:24 pm in reply to: WinpkFilter detecting missed traffic and internal queue size #12312I wanted to ask about that for a while now, would you say Fast I/O should be faster than events-based approach?
Fast I/O is not about being faster than events-based approach. The main idea of Fast I/O is to guarantee minimum latency, i.e. the time interval between the arrival of a packet on the network adapter and the moment it begins to be processed.
Secondly, is there any way to figure out why ReadPacketsUnsorted fails (returns FALSE)?
Normally, it returns FALSE when there are no packets in the queue.
I also don’t see ReadPacketsUnsorted being used in the fastio_packet_filter class from the cpp examples.
It is not really necessary in you have the sufficient number of shared memory sections.
Also, slightly off-topic, but is there any way to get the packet timestamps out of the captured traffic? I find that getting it from std::chrono for every piece of captured traffic is having an impact on how well it performs and was wondering if I’ve just missed it. So far I’ve moved it out so that the timestamp is generated once for every batch of traffic and I wonder how inaccurate that will be.
The timestamp is not implemented in kernel mode, but if it is needed, then adding it to a custom build is not a big deal.
PS.: Just wanted to let you know that AddSecondaryFastIo is not in the documentation, but I saw how it’s used in the examples.
Thanks for the point. Since this was an experimental API, I postponed its documentation until later. And then I completely forgot about it.
Great! Thanks for the update! And yes, the comma “,” is the only delimiter. Quotes are not needed even if path has spaces.
Here it is. Please let me know how it goes 😉
https://www.wiresock.net/downloads/wiresock-vpn-client-x64-1.2.11.1.msi
https://www.wiresock.net/downloads/wiresock-vpn-client-x86-1.2.11.1.msi
Hi,
Yes, that’s right. Both application name and full path name are available in the same context. E.g. “chrome.exe” and “C:\Program Files\Google\Chrome\Application\chrome.exe”. The code simply checks if the application name contains the string specified in AllowedApps/DisallowedApps. If you are interested, then I can change the application name to application full path name in the code and create the software build for you to test.
July 15, 2022 at 8:42 am in reply to: WinpkFilter detecting missed traffic and internal queue size #12285Hi,
The standard driver builds for Windows Vista and later pre-allocate (for performance reasons) 2048 packets of 1514 bytes each (9014 bytes for a jumbo-frame-enabled build). And this is the upper limit for the packet queue. There is no special event to signal when the queue limit has been reached, but if you are reading packets from the driver, providing 2048 INTERMEDIATE_BUFFERS, and getting all the 2048 packets returned, there is a good chance that some packets have passed by in listening mode.
It is not a big problem to increase the internal driver packet pool and/or add an extra event (note that signaling an event comes at a cost) in a custom build of the driver. However, if you need to capture vast amounts of data from a high-speed network, you might want to consider using the experimental Fast I/O API instead. It allows up to 16 shared memory sections to be allocated to deliver packets from the kernel to user space instead of using the driver’s internal packet queue and the ReadPacket API.
Hope it helps!
Note that Fast I/O is an experimental API and is only useful under certain conditions. For example, when you need minimal packet capture latency, and you can dedicate one (or more) CPU cores to poll packets from the driver. Historically, I added it at the request of a user who needed it for an arbitrage trading platform. And it is generally focused on server applications, where you manage and control all available resources. For client-side solutions, I would recommend using traditional I/O.
Regarding your questions, please note that only one driver file object (one instance of CNdisApi) is allowed to use Fast I/O. And once you no longer want to use Fast I/O, just close the corresponding driver file object (destroy the CNdisApi instance) and the driver will do all the necessary cleanup. If you only want to pause packet capture, simply clear the adapter mode flags. To re-enable packet capture, just set appropriate flags back again.
Please let me know if you have any further questions.
Hmm, there are two main cases where a service can temporarily stop filtering the network (and thus allow AllowedApps to bypass the VPN):
1. If the primary WireGuard server is down and a secondary server configuration
-fallback-config
is available, the tunnel will attempt to restart using it.2. When changing the configuration of network adapters (Wi-Fi/LAN switch, disconnecting/reconnecting the Wi-Fi network), the tunnel is also reconfigured and restarted.
Could you please check if v.1.2.9 meets your expectations?
Hmm, yes, I think it makes sense. I will create an update over the weekend.
Thanks, I have added a validation for these fields.
Have you tried to run any of the test binaries? For example, dnstrace?
Could you share the config file you are having trouble with? Another question, did you test adapter (
-lac
) or adapterless mode?Regarding mysqld, do you mean that it initiates an outgoing connection? Because otherwise, i.e. mysqld listen for the incoming connections and needs to be reachable through the tunnel, binding to the address of the VPN adapter will probably suffice.
I use DisallowedIPs to exclude my LAN (192.168.1.0/24) for Chrome:
AllowedApps = chrome DisallowedIPs = 192.168.1.0/24
Hi!
Have you installed Windows Packet Filter driver?
-
AuthorPosts