A network scenario using winpkfilter

[b00tkitism]

I’m trying to do some proxying stuff on UDP packets of a specific process using winpkfilter and ndisapi.
I used simple_packet_filter though.

The simplified logic is like this:
1. With any UDP outgoing packet, I’ll try to send another UDP packet to my own proxy server which contains real destination IP and port, and then responds with a 32-byte token for each destination address.
2. Then for each outgoing packet that’s going to that destination, I change the destination IP and port to my proxy server, but with 32 byte token appended at first of the UDP payload
3. For incoming packets, if the source IP and port was my proxy server ip I’ll lookup the real IP and port in the token-addr table and change those to real source IP and port.

This works fine, but there are some problems I’ll mention here:
1. When I try to register the real destination address on my proxy server, the packet, to my own proxy server will come to the filter so I should skip and pass many packets without proxying until the packet I sent to my proxy server reach my server.
2. If the payload size was bigger than 1472(maximum UDP payload size in a single Ethernet Frame) – 32, it exceeds the maximum MTU (1500) so we can’t proxy that.

Also I don’t know if this logic is a good idea for proxying packets or not, if it’s not I’ll be happy to know why and what’s the better logic to use.

[Vadim Smirnov]

Your logic, while different in implementation, resembles the way SOCKS5 handles UDP ASSOCIATE and generally looks okay. It follows a similar encapsulation approach: sending metadata to a proxy server, receiving a token, and prepending that token to future packets.

It does have similar limitations, particularly:

1. MTU constraints – As you noted, prepending a 32-byte token reduces the usable payload size, which can lead to issues with packets near the 1500-byte MTU threshold. This is a common limitation in encapsulation-based proxy schemes.

2. Race condition on registration – Instead of skipping and passing packets until the proxy replies with the token, consider queuing outgoing packets per destination and only releasing them once authorization is complete and the token is available. This would reduce packet loss and make the logic cleaner.

Overall, the approach is valid for certain scenarios, just be mindful of these trade-offs.

[b00tkitism]

Thanks for your reply.

Can you give me more details on how to queue outgoing packets? Also based on your answer there is no way to proxy near 1500 bytes packets using this scenario. Am I right?

[Vadim Smirnov]

You’re not required to return the packet to the stack immediately — you can queue it and process it later if needed.

If you’re adding a custom header, keep in mind the extra overhead. However, instead of processing each UDP packet individually, consider implementing a session-like approach similar to TCP. For example, send an initial “initiate” packet to set up forwarding for all subsequent UDP packets from a specific IP and port to a designated destination. This reduces per-packet processing and handles large payloads more efficiently, since you don’t need to modify each UDP payload.

[Author]

Posts