Breaking change in FWPM_LAYER_ALE_CONNECT_REDIRECT_V4

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

I’m quite surprised this has ever worked to be honest. I would have thought that after the callouts at BIND_REDIRECTION completed the source interface would be “locked in” (the new behavior you’re seeing).

Have you Audited WFP to see what drops the packets?

You could try raising a service request through the Partner centre.
Jason

Thanks,

There’s actually no “lock in” all through the redirection layers. Consider that a client socket can be implicitly or explicitly bound to 0.0.0.0. This is presented as 0.0.0.0 in both of the redirection layers. Then, at some later point in time, regular routing kicks in and an appropriate source interface is chosen.

Packets aren’t actually being dropped. The issue is that packets aren’t being modified, but instead allowed to pass unmodified. Windows discards the suggested source address change.

I’ve now spent a considerable amount of time trying to navigate the “Partner Center” portal. Much like all their other portals, this too is an endless maze of dead-ends and loops. Seemingly the main reason the portal is even there is to force you onto Azure/SaaS.

Oh wait, being logged on as a business, I can also sign up for “Support for business” and enter all my details again. No that’s also a dead-end. The subscription ID is rejected at about step 50 in the process.

If anyone has the faintest idea how to break through the maze, please advise.

/ows

In the ‘Partner Center’ (where I submit builds for signing) I have a’ Support’ section on the bottom left. I can then raise a ‘Service Request’ against different areas. Maybe ‘Product Support > Microsoft Product Support > Device and Hardware’ would do the job?
Jason