locked
Unexpected reauthorization at ALE connect (also, is there better documentation?) RRS feed

  • Question

  • I have a simple callout driver filter at the ALE connect layer that simply permits everything (it also calls FwpsQueryPacketInjectionState0, but that's it). However, for a small test program that just calls connect() to an IP address and then close(), it runs through this filter twice, and the second time the FWPS_INCOMING_VALUES0 has a FWPS_FIELD_ALE_AUTH_CONNECT_V4_FLAGS field with FWP_CONDITION_FLAG_IS_REAUTHORIZE set. Why is this happening?

    I never pended the connection, I never added/removed any other filters (never changed policy), and there's just one network interface. layerData is always NULL, so it's not a case of the SYN packet http://social.msdn.microsoft.com/forums/en-US/wfp/thread/c92fb71f-1a98-4e9b-8f16-385239fdcf22/. Also, each time the values specify the same local and remote IP addresses and ports.

    By the way, is there a coherent piece of documentation on these layers, what events to expect, when, how many of each, and whether there is a packet attached? There are various hints scattered throughout the current MSDN documentation under both the WDK callout drivers and the WFP Win32 API, but a comprehensive picture is lacking. Despite investing considerable time reading on and experimenting with WFP, its overall operation remains a mystery.
    Monday, October 5, 2009 10:30 PM

Answers

  • On Windows 7, you can look at FWPM_CONDITION_REAUTHORIZE_REASON @ ALE_AUTH_CONNECT to determine why the reauthorization occurred.  This value is a composite of 1 or more of the following values:

       FWP_CONDITION_REAUTHORIZE_REASON_POLICY_CHANGE
       FWP_CONDITION_REAUTHORIZE_REASON_NEW_ARRIVAL_INTERFACE
       FWP_CONDITION_REAUTHORIZE_REASON_NEW_NEXTHOP_INTERFACE
       FWP_CONDITION_REAUTHORIZE_REASON_PROFILE_CROSSING
       FWP_CONDITION_REAUTHORIZE_REASON_CLASSIFY_COMPLETION
       FWP_CONDITION_REAUTHORIZE_REASON_IPSEC_PROPERTIES_CHANGED
       FWP_CONDITION_REAUTHORIZE_REASON_MID_STREAM_INSPECTION
       FWP_CONDITION_REAUTHORIZE_REASON_SOCKET_PROPERTY_CHANGED
       FWP_CONDITION_REAUTHORIZE_REASON_NEW_INBOUND_MCAST_BCAST_PACKET

    Documentation for these are at http://msdn.microsoft.com/en-us/library/aa364002(VS.85).aspx

    As for WFP documentation, the main source is the SDK (http://msdn.microsoft.com/en-us/library/aa366510(VS.85).aspx) and the DDK (http://msdn.microsoft.com/en-us/library/ee206850.aspx)

    Hope this helps


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, October 7, 2009 12:56 AM
    Moderator
  • To access the FWPM_CONDITION_REAUTHORIZE_REASON, you would do the following:

    inFixedValues->incomingValue[FWPS_FIELD_ALE_AUTH_CONNECT_V4_REAUTHORIZE_REASON].value.uint32
    

     Note that this is available in Win7+

    FWP_CONDITION_REAUTHORIZE_REASON_CLASSIFY_COMPLETION means that a previously pended connection is now being allowed to complete.

     

    Hope this helps,

     

     

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Monday, October 3, 2011 6:47 PM
    Moderator

All replies

  • By the way, is there a coherent piece of documentation on these layers, what events to expect, when, how many of each, and whether there is a packet attached? There are various hints scattered throughout the current MSDN documentation under both the WDK callout drivers and the WFP Win32 API, but a comprehensive picture is lacking. Despite investing considerable time reading on and experimenting with WFP, its overall operation remains a mystery.

    Hi.

    I want to second this. Comparing WFP with other simplifying kernel API e.g. Filesystem's Filter-Manager, I am feeling uncomfortable with WFP. 
    Tuesday, October 6, 2009 8:29 AM
  • On Windows 7, you can look at FWPM_CONDITION_REAUTHORIZE_REASON @ ALE_AUTH_CONNECT to determine why the reauthorization occurred.  This value is a composite of 1 or more of the following values:

       FWP_CONDITION_REAUTHORIZE_REASON_POLICY_CHANGE
       FWP_CONDITION_REAUTHORIZE_REASON_NEW_ARRIVAL_INTERFACE
       FWP_CONDITION_REAUTHORIZE_REASON_NEW_NEXTHOP_INTERFACE
       FWP_CONDITION_REAUTHORIZE_REASON_PROFILE_CROSSING
       FWP_CONDITION_REAUTHORIZE_REASON_CLASSIFY_COMPLETION
       FWP_CONDITION_REAUTHORIZE_REASON_IPSEC_PROPERTIES_CHANGED
       FWP_CONDITION_REAUTHORIZE_REASON_MID_STREAM_INSPECTION
       FWP_CONDITION_REAUTHORIZE_REASON_SOCKET_PROPERTY_CHANGED
       FWP_CONDITION_REAUTHORIZE_REASON_NEW_INBOUND_MCAST_BCAST_PACKET

    Documentation for these are at http://msdn.microsoft.com/en-us/library/aa364002(VS.85).aspx

    As for WFP documentation, the main source is the SDK (http://msdn.microsoft.com/en-us/library/aa366510(VS.85).aspx) and the DDK (http://msdn.microsoft.com/en-us/library/ee206850.aspx)

    Hope this helps


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, October 7, 2009 12:56 AM
    Moderator
  • Hi All,

    Could you please let me know how can we retrieve FWPM_CONDITION_REAUTHORIZE_REASON value.

    I am pending the packet at ALE_AUTH_CONNECT layer, queue the work item and process the work item. After that I call FwpsCompleteOperation0. This causes the call to be classfied again at ALE_AUTH_CONNECT layer. I want to continue the callout in this case (only). In all other cases (that is re-auth due to other reasons eg:FWP_CONDITION_REAUTHORIZE_REASON_POLICY_CHANGE,FWP_CONDITION_REAUTHORIZE_REASON_NEW_ARRIVAL_INTERFACE,

    FWP_CONDITION_REAUTHORIZE_REASON_NEW_NEXTHOP_INTERFACE, FWP_CONDITION_REAUTHORIZE_REASON_PROFILE_CROSSING etc.), i want to pend the packet and do the processing. I have a couple of questions here

    1. Is 'FWP_CONDITION_REAUTHORIZE_REASON_CLASSIFY_COMPLETION' is the value getting for FWPM_CONDITION_REAUTHORIZE_REASON when we unpend the packet using FwpsCompleteOperation0?

    2. How can we retrieve the value for FWPM_CONDITION_REAUTHORIZE_REASON from ALE_AUTH_CONNECT layer.

    Is the below code a right one? This doesn't seem to work correctly.

    BOOLEAN IsPendCompletedReauth(
     IN const FWPS_INCOMING_VALUES0* inFixedValues
     )
    {
     UINT flagsIndex;

       GetFlagsIndexesForLayer(
          inFixedValues->layerId,
          &flagsIndex
          );

       if((flagsIndex != UINT_MAX) && ((inFixedValues->incomingValue\
          [flagsIndex].value.uint32 & FWPM_CONDITION_REAUTHORIZE_REASON) == FWP_CONDITION_REAUTHORIZE_REASON_CLASSIFY_COMPLETION))
       {
          return TRUE;
       }

       return FALSE;
    }
     

    3. Could you please give me a sample code to understand this. ( i have gone through the 'Inspect' sample in WDK, but it checks the pended packet from a list, since I don't maintain a list for that I cannot use that way of checking).

    Any help is much apppreciated. Thanks in advance.

    Thanks,

    Krishnanand
     


    Tuesday, September 20, 2011 11:25 AM
  • To access the FWPM_CONDITION_REAUTHORIZE_REASON, you would do the following:

    inFixedValues->incomingValue[FWPS_FIELD_ALE_AUTH_CONNECT_V4_REAUTHORIZE_REASON].value.uint32
    

     Note that this is available in Win7+

    FWP_CONDITION_REAUTHORIZE_REASON_CLASSIFY_COMPLETION means that a previously pended connection is now being allowed to complete.

     

    Hope this helps,

     

     

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Monday, October 3, 2011 6:47 PM
    Moderator