locked
WFP VPN Client RRS feed

  • Question

  • Hi All,

    I am exploring possibility of creating a VPN client for Wireguard using WFP framework. I see many example of VPN client developed using NDIS library. I am interested doing the same using WFP. But i am not sure of the possibility and couldn't find any sample code using WFP . Could you please give some clear direction.

    WFP is a wrapper on top of NDIS library?

    Thanks,


    • Edited by Boomi.s Monday, February 3, 2020 11:21 PM
    Monday, February 3, 2020 10:53 PM

All replies

  • No, WFP is not an NDIS wrapper. WFP allows access to all the layers of the network stack, incoming and outgoing, and allows you to insert, modify, or delete packets/streams at each layer. As such, it really isn't suitable to use in creating a VPN. I suppose that it could be done, but I wouldn't do it that way, because I suspect that it would consume more CPU resources than an NDIS miniport.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog


    Tuesday, February 4, 2020 12:17 AM
  • Thanks Brian. Basically i am trying to implement Wintun VPN client using the WFP. The Wintun driver https://www.wintun.net/ acts as NDIS miniport driver. Wintun runs at layer 3 sending OID requests and other stuff. I am wondering all these stuff avialable in the Wintun driver can be implemented using WFP.

    Tuesday, February 4, 2020 3:25 PM
  • Why do you think that using WFP will provide any benefit?

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Tuesday, February 4, 2020 7:18 PM
  • Tuesday, February 4, 2020 7:28 PM
  • No, WFP isn't. Just to be sure, I contacted the NDIS architect, and this is what he wrote:

    "I can imagine certain kinds of encapsulation making sense with WFP.  E.g., we do IPsec via a WFP callout.  But a VPN interface probably has a lot more going on than just encapsulation, so you’ll probably get stuck if you try to do it all in WFP.  E.g., I’m not sure how you’d report connection up down state to the user.  An NDIS <g class="gr_ gr_40 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="40" id="40">miniport</g> makes more sense to <g class="gr_ gr_71 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-del replaceWithoutSep" data-gr-id="71" id="71">me,</g> since it comes with those states.  It’s also worth noting that most of the inbox VPN drivers are NDIS <g class="gr_ gr_164 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" data-gr-id="164" id="164">miniports</g> and the one that <g class="gr_ gr_203 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar multiReplace" data-gr-id="203" id="203">isn’t plugs</g> into the bottom of TCPIP via a private channel that’s a peer of NDIS.

     The other edge of the VPN varies.  A layer-2 protocol, like L2TP, would naturally want to be an NDIS protocol driver.  But a layer-4 protocol, like SSTP, would naturally fit as a WSK client."

    However, there is another <g class="gr_ gr_11 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" data-gr-id="11" id="11">way</g> using some new APIs. One of the devs from that team (Peter) will be jumping into this thread to explain it


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog











    • Edited by Brian Catlin Wednesday, February 5, 2020 1:19 AM Tried to get the HTML crap out, but to no avail
    Wednesday, February 5, 2020 1:10 AM
  • Have you considered using the UWP VPN APIs? Using these APIs, you

    • specify the VPN parameters (split tunnel, full tunnel, etc)
    • create a tunnel socket to the VPN server
    • get callbacks to encapsulate just the packets that ought to be encapsulated

    The system will also handle retries for you. Note that the app will be a UWP app only; you would distribute it via the store. The VPN APIs require the networkingVpnProvider capability in order to ship (but you can ask for that ahead of time). 

    Wednesday, February 5, 2020 1:12 AM
  • Thanks Brian for the detailed information.
    Wednesday, February 5, 2020 6:55 PM
  • Are there any working samples for the UWP VPN APIs yet? Last year when I/we tried to use them it was a significant effort to get something that _almost_ sorta worked.

    If there's some new doc on UWP VPN API's - I'd be very interested! 

    Tuesday, February 25, 2020 5:19 PM
  • @PeterSmithRedmond - I am so very close to being able to use the UWP VPN APIs but there's one limitation that isn't well documented anywhere (i've seen). I can use the VPN plugin to talk to a remote server but i'm not able to use the VPN plugin to talk to a vpn 'server' running locally. I need to implement my own protocol and tcp handling and i'd like to bake everything into the plugin. We're taking a zero-trust model here so each connection is tied to a given machine.

    Is there _any way_ whatsoever to use the VPN Plugin, feeding it a transport that resolves to "localhost"/"127.0.0.1" etc? As soon as I move my "VPN Server" in process - when i invoke "AssociateTransport" the plugin framework somehow taints the socket... Example:

    HostName tcpHostname = new HostName("127.0.0.1");
    string tcpPort = "9000";
    tcpTransport = new StreamSocket();
    tcpTransport.ConnectAsync(tcpHostnametcpPort).AsTask().Wait(); //this will succeed... proving you CAN connect...
    tcpTransport.CancelIOAsync().AsTask().Wait();
    tcpTransport.Dispose(); //close/dispose of the connection it worked - yay...
     
    tcpTransport = new StreamSocket(); //now do the same thing all over again but let the VPN framework use the tcpTransport
    channel.AssociateTransport(tcpTransport, null);
    tcpTransport.ConnectAsync(tcpHostnametcpPort).AsTask().Wait(); //fails with "no host is known". AssociateTransport is 'doing something'
    

    I know - i know... "VPN problems require microsoft support" - fine... but c'mon throw the community (or me) a bone???  :) 

    Please

    Wednesday, April 1, 2020 4:51 PM