Skip to main content

 none
How to force ALE Reauthorization of a exsiting UDP flow ? RRS feed

  • Question

  • I had register a Callout at `ALE_FLOW_ESTABLISHED` layer with a filter for a specific program(.exe) UDP traffic.

    And I had register a Callout at `ALE_AUTH_CONNECT` layer with a inspection filter for print the information when reauthorization occurs.

    First, I use the target program to send a udp packet to the test server. The `ALE_AUTH_CONNECT` callout ClassifyFn called, then `ALE_FLOW_ESTABLISHED` callout ClassifyFn called, this is expected.

    Now, I delete the filter of the target program, but the `ALE_AUTH_CONNECT` callout ClassifyFn not called, this is not expected.

    Also, I had try to call `FwpsFlowAssociateContext` at `ALE_FLOW_ESTABLISHED` ClassifyFn, then delete the target program filter(this trigger filter delete notify), then call  `FwpsFlowRemoveContext` at `ALE_FLOW_ESTABLISHED` NotifyFn when `notifyType` is `FWPS_CALLOUT_NOTIFY_DELETE_FILTER`, this trigger the ALE flow to be deleted. But it also not trigger reauthorization, at least the `ALE_AUTH_CONNECT` ClassifyFn not called.

    Then, I re-add the filter of target program and send a UDP packet to test server, both `ALE_FLOW_ESTABLISHED` and `ALE_AUTH_CONNECT` ClassifyFn not called,  this does not match the document description: Policy-Change Reauthorization (Sorry I dont know why I cant post link: Body text cannot contain images or links until we are able to verify your account. https://docs.microsoft.com/en-us/windows/win32/fwp/ale-re-authorization#policy-change-reauthorization)

    So, what's the correct way to force the UDP ALE flow reauthorization ?


    • Edited by Joke Huang Sunday, August 11, 2019 12:37 AM edit
    Sunday, August 11, 2019 12:03 AM

Answers

  • Hello Joke Huang,

    "A policy change is implemented as a filter addition or removal at an ALE layer. Once a policy change is detected, the first packet that traverses an ALE flow created at the affected layer will be specified for reauthorization to the layer. Therefore, for reauthorization it is entirely possible that an outbound packet is classified at the FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V{4|6} layer and that an inbound packet is classified at the FWPM_LAYER_ALE_AUTH_CONNECT_V{4|6} layer." Refer to "ALE Reauthorization".

    First, you need make sure the policy change is detected. Refer to Monitoring Filter Changes for sample implementation.

    Second, you can also check if the outbound connect is at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V{4|6} layer?

    "Because a policy change might require blocking previously allowed connections, ALE flows need to be reauthorized when a policy change occurs." Refer to "ALE Stateful Filtering".

    So you can add additional filter with FWP_ACTION_BLOCK to see if it can trigger the reauthorization.

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Monday, August 12, 2019 8:49 AM

All replies

  • Hello Joke Huang,

    "A policy change is implemented as a filter addition or removal at an ALE layer. Once a policy change is detected, the first packet that traverses an ALE flow created at the affected layer will be specified for reauthorization to the layer. Therefore, for reauthorization it is entirely possible that an outbound packet is classified at the FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V{4|6} layer and that an inbound packet is classified at the FWPM_LAYER_ALE_AUTH_CONNECT_V{4|6} layer." Refer to "ALE Reauthorization".

    First, you need make sure the policy change is detected. Refer to Monitoring Filter Changes for sample implementation.

    Second, you can also check if the outbound connect is at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V{4|6} layer?

    "Because a policy change might require blocking previously allowed connections, ALE flows need to be reauthorized when a policy change occurs." Refer to "ALE Stateful Filtering".

    So you can add additional filter with FWP_ACTION_BLOCK to see if it can trigger the reauthorization.

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Monday, August 12, 2019 8:49 AM
  • Hi Rita,

    Thank you for your detail answer. But I have further questions about your answer.

    Does the "ALE_FLOW_ESTABLISHED NotifyFn called" equivalent to "a policy change is detected" ? If the answer is yes, then I have already done.

    Even if I don't register any callouts (and filters) at ALE_AUTH_CONNECT and ALE_AUTH_RECV_ACCEPT, the ALE_FLOW_ESTABLISHED callout ClassifyFn should be called if reauthorization occurs (In my case, it did not called). Reference to the follow:

    UDP Connection Establishment

    ...

    Client (sender) performs Active Open

    • ...
    • sendto: FWPM_LAYER_ALE_AUTH_CONNECT_V4  // reauthorization occurs, but not register callout here, by default should pass traffics to next layer ALE_FLOW_ESTABLISHED
    • FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4
    • ...


    • Edited by Joke Huang Tuesday, August 13, 2019 5:55 AM edit
    Tuesday, August 13, 2019 5:51 AM