Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

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

sagi_zarsagi_zar Member - All Emails Posts: 32

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

Comments

  • Jason_StephensonJason_Stephenson Member Posts: 105

    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

  • sagi_zarsagi_zar Member - All Emails Posts: 32

    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

  • MBond2MBond2 Member Posts: 331

    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?

  • sagi_zarsagi_zar Member - All Emails Posts: 32

    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.

  • Jason_StephensonJason_Stephenson Member Posts: 105

    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

  • sagi_zarsagi_zar Member - All Emails Posts: 32

    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

  • Jason_StephensonJason_Stephenson Member Posts: 105

    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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online