[Vadim Smirnov]

Yes, simple_packet_filter is single threaded. And yes, you can declare the table and mutex outside and pass a refences into simple_packet_filter inbound packets processing lambda function.

[Vadim Smirnov]

I’m afraid there is no ready-to-use sample like this… But it is quite easy to do. And sure, if your IP address table is accessed from two or more concurrent threads then some of synchronization is required. For example, you could use std::shared_mutex for this. Packet filtering routine could lock it in shared mode (read lock) and “update table” routine could lock it exclusively.

[Vadim Smirnov]

Well, you could create the filter table using your IP list and load it into the driver.

Alternatively you can implement any kind of filtering logic in user space using one of the packet filtering samples as a base.

[Vadim Smirnov]

Hi

If you are looking for a simple filter table then you could use built-in filters. Please check the filter sample.

[Vadim Smirnov]

Hi,

• There is a socksify sample on GitHub which demonstrates how to forward selected TCP sessions via SOCKS5 proxy.
• With Developer license:
  • You will get the re-branded winpkfilter custom driver build from us. In two words custom build allows to avoid potential software conflicts. You can find more details here.
  • You are allowed to distribute winpkfilter drivers as a part of your software.
  • You get 1 year of free update and support which may include more advanced/extended sample code. For example, socksify sample mentioned above supports only TCP, but for your purposes you probably also need UDP (e.g., Fortnite uses UDP as a transport) and I could help you with it.

[Vadim Smirnov]

Hi and thank you for the feedback!

Currently released version of wg-quick-config can’t show the QR code for the specified configuration. However, it is very easy to fix. Here is an updated wg-quick-config binaries with an extra command line parameter qrcode.

Example: wg-quick-config -qrcode 1 should show QR code for the first existing configuration. Please note that this command line parameter is not compatible with other ones. I will add this option (maybe in a slightly different form) to the next Wiresock update.

[Vadim Smirnov]

Configuration file is named config.json and it is stored in the folder from which you executed wg-quick-config for the first time as well as server and clients configurations. In you case if server and client configs are in the System32 folder then just find the config.json there and delete it.

[Vadim Smirnov]

There are actually two ways to filter with ProcessID or ProcessName:

• The easy one is IP Helper API. You can find the details in process_lookup.h
• More complicated one is creating WFP callout driver to track network connections (sockets) creation/termination

The LSP is deprecated and I’m not sure if it is supported on Windows 10.

[Vadim Smirnov]

As for the TCP MSS option you can check CsnatDlg::CheckMTUCorrelation in snatDlg.cpp

I don’t have an open source sample using ICMP fragmentation needed option, but if packet size exceeds MTU and DF flag is set then you can use the function below to convert it to ICMP type 3 code 4 (“fragmentation needed but don’t fragment set”) and forward back to the host.

void convert_to_icmp_unreachable(INTERMEDIATE_BUFFER& buffer) const
{
	auto* eth_header = reinterpret_cast<ether_header_ptr>(buffer.m_IBuffer);
	auto* ip_header = reinterpret_cast<iphdr_ptr>(buffer.m_IBuffer + ETHER_HEADER_LENGTH);

	// 1. Copy IP header and 8 bytes of payload after icmp header
	auto* const next_header = reinterpret_cast<PCHAR>(ip_header) + sizeof(DWORD) * ip_header->ip_hl;
	const auto payload_length = static_cast<unsigned short>(next_header - reinterpret_cast<char*>(ip_header) + 8);
	memmove(
		reinterpret_cast<char*>(eth_header) + ETHER_HEADER_LENGTH + sizeof(iphdr) + sizeof(icmphdr),
		ip_header,
		payload_length
	);

	// 2. Swap MAC addresses
	std::swap(eth_header->h_dest, eth_header->h_source);

	// 3. Swap IP addresses
	std::swap(ip_header->ip_dst, ip_header->ip_src);

	// 4. Initialize IP header
	ip_header->ip_hl = 5;
	ip_header->ip_v = 4;
	ip_header->ip_tos = 0;
	ip_header->ip_len = htons(sizeof(iphdr) + sizeof(icmphdr) + payload_length);
	ip_header->ip_off = htons(IP_DF);
	ip_header->ip_ttl = 30;
	ip_header->ip_p = IPPROTO_ICMP;

	// 5. Initialize ICMP header
	auto* const icmp_header = reinterpret_cast<icmphdr_ptr>(ip_header + 1);
	icmp_header->type = 3;
	icmp_header->code = 4;
	icmp_header->seq = htons(config_.default_adapter->get_mtu());

	// Recalculate checksum
	RecalculateICMPChecksum(&buffer);
	RecalculateIPChecksum(&buffer);

	buffer.m_Length = ETHER_HEADER_LENGTH + sizeof(iphdr) + sizeof(icmphdr) + payload_length;
}

[Vadim Smirnov]

Yes, this option modifies the MTU for local network adapters. You can’t affect the remote system MTU value directly but you can use the TCP MSS option or/and ICMP fragmentation needed to affect the effective MTU between hosts.

[Vadim Smirnov]

Hi!

There is a sample https://github.com/wiresock/ndisapi/tree/master/examples/cpp/socksify which redirects specified local application to the local TCP proxy and then to the specified SOCKS proxy. If I understood you right then this is what you doing in your application. I have also used similar approach in a couple of commercial projects and I can confirm that this works just fine.

To figure out what is going wrong in your case I would capture and save the traffic to analyze. May be the packet you modified has incorrect checksum or length and thus dropped by the stack.

[Vadim Smirnov]

Regretfully I don’t have TB adapters to test with, but probably TB somehow differs from the ‘normal’ Ethernet. Technically it is emulation of 802.3 media over TB bus, so I would not be surprised if TB adapter simply ignores any network packets having MAC address from another TB adapter.

In some approximation this could be similar to the situation when bridge works between wired Ethernet and WiFi where I had to translate wired Ethernet MAC addresses to WiFi and vice versa so that packets from the wired segment would not be rejected by an Access Point.

But these are just raw ideas based on my previous experience, I don’t have the relevant hardware to test with.

[Vadim Smirnov]

P.S. BTW, if you don’t need the SMB traffic to be processed in user mode then you could load the filter into the driver to pass it over without redirection.

[Vadim Smirnov]

I think 3 threads are good to go:

1. ReadPackets thread which forms re-injection lists, signals re-inject threads and waits the re-inject to complete or even better proceeds to read using secondary buffers set
2. SendPacketsToMstcp thread waits for ReadPackets signal, re-injects, notifies ReadPackets thread and returns to wait
3. SendPacketsToAdapter thread waits for ReadPackets signal, re-injects, notifies ReadPackets thread and returns to wait

[Vadim Smirnov]

Here is the CPU breakdown of SMB download:

Function Name Total CPU [unit, %] Self CPU [unit, %] Module Category
|||||| – CNdisApi::SendPacketsToMstcp 2858 (56.58%) 3 (0.06%) dnstrace.exe IO | Kernel
|||||| – CNdisApi::SendPacketsToAdapter 1495 (29.60%) 2 (0.04%) dnstrace.exe IO | Kernel
|||||| – CNdisApi::ReadPackets 349 (6.91%) 6 (0.12%) dnstrace.exe IO | Kernel

As you may notice splitting reading and re-injection does not make much sense, but splitting SendPacketsToMstcp and SendPacketsToAdapter over two threads definitely will have an effect.

I can’t see how the OSR post can be related, the author problem is about repackaging packets due to the reduced MTU.

[Author]

Posts