- This topic has 2 replies, 2 voices, and was last updated 15 hours, 49 minutes ago by
.
-
Posts
-
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.
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.
- You must be logged in to reply to this topic.