Source port 0 for UDP connect data while doing connect redirect FWPM_LAYER_ALE_CONNECT_REDIRECT_V4

NTDEV
1

Hi,

I’m using WFP to do connection redirect to a local proxy.
I’m using the WPM_LAYER_ALE_CONNECT_REDIRECT_V4 layer for this purpose.
in TCP everything is working fine.
In UDP the callout function is getting called, I’m doing the same redirect steps, but the packet is not getting to the application that is waiting on the local redirected port.
redirecting to a different port, but on a remote server is working fine also in UDP.
while debugging I saw that the local port in the connection parameters that the redirect callout get is zero.
I’m using iperf to run the test and to further analyze the issue, I wrote a small test client that does bind and sendto to some IP and port that is configured to redirect.
I saw that while using this test app, the local port had a non zero number and the redirect worked fine.
I saw in several forums that other people had the same issue, but didn’t find a solution.
Any help will be very helpfull.

Regards,
Sagi

2

You’re in luck. ~6 years ago this would have bluescreened for you. I worked with Microsoft to get the blue screens fixed and also encountered the udp.srcport == 0 issue. Their stance on it back then was that it was by design. IIRC there is no reason why redirection of this flow into a local proxy would fail, I had it working once.

The exact scenario udp.srcport == 0 occurs is when the flow is a “connected” udp flow. I.E connect() has been called on the socket in userland s.t subsequent calls to send() will now work. (where one would normally not do a connect() and just use sendto())

Jason

1 Like
3

thanks for the reply.
I’m using the WFPSampler as my base code and while redirect to local proxy works for me in TCP or in unconnected UDP (srcport !=0), it doesn’t work in connected UDP (srcport=0).
should the callout function that perform the connection redirect do something special in this case?
should it set the srcport to the port the connected UDP is using? if so, from where it should take it?
does the fact that the user did connect() on this UDP socket effect the WFP flow and the driver should handle something differently?
Thanks,
Sagi

4

IMHO UDP source ports are not generally very significant and can be introduced at different levels in the stack, so why do you care?

PS it seems that we have a lot of network related questions just at the moment?

5

I don’t need to know the UDP source port. its just that the UDP connection redirection to local proxy doesn’t work at this situation. one of the differences that I saw between a UDP connection redirection that can be proxied to a local port and one that doesn’t, is the fact that when it doesn’t work, the source port is “0”. Jason wrote that the connection with zero source port is a connected UDP connection (user called connect). maybe this is what causing the failure to redirect the connection.

6

should the callout function that perform the connection redirect do something special in this case?
does the fact that the user did connect() on this UDP socket effect the WFP flow and the driver should handle something differently?
I’ve left the company I wrote this for and therefore don’t have access to the code but i’m 99% sure there was no special handling of connected udp in my driver after MS fixed their bug. Yes the fact connect() was called means things are very slightly different in the kernel but it’s nothing you (should) need to worry about

should it set the srcport to the port the connected UDP is using? if so, from where it should take it?
No, you don’t need to touch the source port. IIRC by the time the flow is indicated at the AUTH_CONNECT layer the source port will have been assigned.

Turn on auditing and find out what is discarding your packets (https://docs.microsoft.com/en-us/windows/win32/fwp/auditing-and-logging).
Maybe you need to register at AUTH_CONNECT and approve the redirected flow.
Jason

7

Hi,
I just found the following document from Microsoft with the following title: “Failed to redirect connected UDP traffic to a local proxy service”
https://docs.microsoft.com/en-us/troubleshoot/windows-hardware/drivers/redirection-connected-udp-traffic-local-proxy-fail
According to Microsoft this is a bug in the WFP framework itself.
Their suggested workaround is not relevant. They suggest to change the client so it will not use connected UDP sockets. well, as the developer of the callout driver, I don’t control the client side and I wish to support all clients.
Anyone have an idea how to really workaround this issue?
Thanks,
Sagi

8

Very strange, I’m certain I had this working many years ago, but the article you reference indicates it cant be done (any longer?).
I’d still do the auditing step i mentioned above and see what it throws up.

Worst case scenario just perform the redirection on a per packet basis at another layer.
Jason