[Vadim Smirnov]

Hi,

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!

[Vadim Smirnov]

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.

[Vadim Smirnov]

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.

 

[Vadim Smirnov]

Could you please check if v.1.2.9 meets your expectations?

[Vadim Smirnov]

Hmm, yes, I think it makes sense. I will create an update over the weekend.

[Vadim Smirnov]

Thanks, I have added a validation for these fields.

[Vadim Smirnov]

Have you tried to run any of the test binaries? For example, dnstrace?

[Vadim Smirnov]

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.

[Vadim Smirnov]

I use DisallowedIPs to exclude my LAN (192.168.1.0/24) for Chrome:

AllowedApps = chrome
DisallowedIPs = 192.168.1.0/24

[Vadim Smirnov]

Hi!

Have you installed Windows Packet Filter driver?

[Vadim Smirnov]

I will add a proxy option. This can be really useful.

Wiresock VPN Client is standalone, you don’t need the official Wireguard client to make it work.

WireSock VPN Gateway needs an official Wireguard client and allows it to act as a WireGuard server.

 

[Vadim Smirnov]

The problem was parsing a configuration that expected the Address parameter to have a specified netmask, e.g. Address = 10.10.0.4/32, 2001:dc8:a260::4/128 while in your configuration the Address parameter looked like Address = 10.10.0.4 , 2001:dc8:a260::4.

I have fixed the configuration parser in 1.2.8. Please give it a try.

[Vadim Smirnov]

Please check if you have received my reply email.

[Vadim Smirnov]

Problems with -lac options are caused by insufficient user privileges, please note that Wiresock should be run as administrator.

You can email PCAP files directly to support@ntkernel.com. We can continue to review the issue privately, after which I will post the final solution here. Unfortunately, without anti-spam, I would have to delete too many users/spam daily…

[Vadim Smirnov]

Hello, could you please provide the generated PCAP files in addition to the application log? Also, could you check if using-lac makes a difference? With the latter option, Wiresock works closer to the stock client. One more question, do you have DNS specified in the config file (‘server not found’ points to DNS problem)?

Currently, only the process name is checked, the path is ignored. It’s easy to change the check to a fully qualified pathname, but in the current implementation with a config file, this can lead to unwanted collisions. I plan to add an advanced configuration that will allow this.

You definitely read in my mind! I really was considering adding a proxy (as a dedicated process) that would be connected and intercepted by Wiresock. I implemented a similar thing for one side project.

[Author]

Posts