We’re currently testing our software on the latest Windows version available through the Insider Program, Dev track. The exact version number is 10.0.21390.1000.
We’ve noticed what appears to be a breaking change in the processing that occurs after callout(s) are invoked.
It used to be possible (still is on Windows 7, 8, 8.1, current 10) to update only the source address of a connection in this layer. You’re supposed to apply source-only updates in FWPM_LAYER_ALE_BIND_REDIRECT_V4, but there are times when you need the destination address to have enough context to make a qualified decision for a specific connection.
Here’s an MSDN document that explicitly says this is forbidden: https://docs.microsoft.com/en-us/windows-hardware/drivers/network/using-bind-or-connect-redirection
“Changing the local address and port of a flow is only supported in the bind-redirect layer. This is not supported in the connect-redirect layer.”
Here’s a different MSDN document, which admittedly is somewhat confused, but still clearly states that this is supported: https://docs.microsoft.com/en-us/windows/win32/fwp/management-filtering-layer-identifiers-
“For TCP, the local address and/or local port as well as the remote address and/or remote port can be modified.”
What we’re seeing in the test version of Windows, is that callouts are being activated as they should, but if we rewrite the source address it has absolutely no effect. What’s also concerning is that because FwpsApplyModifiedLayerData0() doesn’t return a status code, this becomes a silent error which is very difficult to detect.
The functionality in itself is a great way to select the source interface WITHOUT all the overhead of running a local proxy. There are dozens of commercial applications that depend on this feature and I’ve briefly tested a handful of these. They all fail in the way described above.
Either this semi-supported feature is over due for being dropped, and that’s what finally happened. In which case everyone should be drafting a design to integrate local proxying in their products.
Or, someone made an honest mistake that accidentally broke the feature. If this is indeed the case, what’s a suitable channel to provide qualified feedback to Microsoft?
TIA