WFP callout driver doesn't work properly with CISCO VPN client in Windows 7 OS RRS feed

  • Question

  • Hello all

    Recently I encounter the problem with WFP filter during the processing of CISCO VPN client ver 5.0.06 requests.

    Below I describe the workflow.
    1. My WFP callout driver adjusted handlers for connect, flow and datagram layers. Traffic is filtered by UDP protocol.
    2. CISCO VPN tries to establish UDP connection at remote port 62515. Connect handler gets called.
    3. Connect handler calls FwpsPendOperation0 API, so that first outbound UDP packet is processed at passive level IRQL by the system thread.
    4. In the system thread we make a decision and call FwpsCompleteOperation0. Only flow handler get called, but datagram handler doesn't. As a result, first send datagram packet (in our case UDP connect) is not indicated by my NDIS intermediate sniffer. Moreover, WFP API don't indicate any error, as operations were completed successfully.

    Please help me to solve the problem. Thanks in advance. 

    Monday, December 13, 2010 12:35 PM

All replies

  • Hello all

    I'd like to describe the situation more precisely.

    After the calling of FwpsCompleteOperation0 flow handler is called, than API returns control to my system thread. In turn packet is injected  using FwpsInjectTransportSendAsync0 or FwpsInjectTransportSendAsync1. Both the variants of API return success, but datagram handler doesn't get control, as a result, NDIS IM doesn't indicate packet. So I can make concequence, that CISCO VPN connection meets the failure. For all other packets this scheme works fine.

    P.S.  I tried to use connect redirect layer handlers instead of their connect counterparts, but unfortunately result is the same. I suppose this is hidden WFP/NPI bug.

    Tuesday, December 14, 2010 8:47 AM
  • I got same problem here. also port UDP 62515. it seems like such UDP packet will lost inside WFP when re-injected.

    In my case, I inspect it in datagram layer, block the oritinal UDP 62515 outgoing packet, then re-inject it back later. The re-injection is successfull, but the packet was not re-enter. Usually when a packet was injected, it will re-enter datagram layer with inject state indicated that it was re-injected. It does so for all other ports, but for 62515, it does not. The packet lost in WFP

    Tuesday, December 21, 2010 7:20 PM