WFP vs LWF for VPN Tunnel

NTDEV
1

Hi!

I’m new to WFP and wanted to know the pros/cons of using it instead of a LWF
for a VPN tunnel project. As far as I can see, what I’d need to do on the tx
path is the following:

  1. Inspect the packet at the IP layer and determine if it needs to be
    tunneled.
  2. If so, clone and drop/block the packet.
  3. After it is prepared for the tunnel, reinject it into the tx path.

#2 concerns me. The only way I can see to drop the packet is to return
FWP_ACTION_BLOCK. However, what does the stack do in this case? Does that
break the flow at all? In the LWF approach, the filter would complete the
send and reinject it’s cloned and modified copy into the driver stack, so
the stack would think the original packet has been sent.

#3 also concerns me. I suppose all I need to do is call
FwpsInjectNetworkSendAsync0, but that seems like it injects the packet back
into the filter engine when all I want to do is send it down the driver
stack to the underlying miniport driver. Again, I can see how I can do this
with a LWF.

Again, I’m a newbie to WFP, so I’m sure there’s a lot of bad assumptions I’m
making. My preference is to go with the LWF approach, but can someone tell
me whether it makes more sense to use WFP?

Thanks!

2

“Absorbing” a packet in WFP is straight forward.

See FWPS_CLASSIFY_OUT_FLAG_ABSORB

Good Luck,
Dave Cattley

3

Thanks, David! That will do it for me.

What about my concern about packet injection?

“I suppose all I need to do is call
FwpsInjectNetworkSendAsync0, but that seems like it injects the packet back
into the filter engine when all I want to do is send it down the driver
stack to the underlying miniport driver. Again, I can see how I can do this
with a LWF.”

“David R. Cattley” wrote in message news:xxxxx@ntdev…

“Absorbing” a packet in WFP is straight forward.

See FWPS_CLASSIFY_OUT_FLAG_ABSORB

Good Luck,
Dave Cattley

4

I think you should consider whether what you think you want really makes
sense.

Your VPN presumably takes an IP packet and encapsulates in some other IP
packet. At the very least you probably change the destination IP address
and thus potentially invalidate any interface selection, etc. that might
have occurred prior to your callout receiving the packet.

So now you go create a new packet. And let’s face it, it is a new packet.
Well all of that outbound processing, including other filters, callouts,
etc. really *should* be applied to this new packet. And WFP ensures that
that occurs in a rational way.

And what exactly makes you conclude that the packet as you have created it
will even get to a ‘underlying miniport driver’ (I presume you mean
interface/NIC)?

Suppose the outbound interface for your resulting packet is another VPN
interface?

This was the problem with the disaster of building VPN encapsulation logic
in IM drivers (and yes, the same problem exists for LWFs). There is no
sanity when it comes to multiple VPNs. WFP provides a means to rationalize
that by saying that injection outbound always passes through a predefined
set of layers (depending on the injection layer) and that injection inbound
always passes through a predefined set of layers (again, depending on the
injection layer).

Your VPN lower edge is a ‘client’ of the local network stack, not a protocol
bound to an interface. IM and LWF (layer 2) based IPSec VPNs have untold
complexity and nonsense in them to undo, the redo, the fact that they are at
L2. WFP liberates the VPN implementation from that nonsense.

So go with it. You will be much happier.

But I do have one question: Does your notion of ‘VPN’ introduce a interface
when connected? For example, a “virtual adapter”? Because if so, why do
you need to intercept & process packets at WFP (L3) or LWF (L2)?

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of SoquelDude
Sent: Tuesday, January 15, 2013 8:08 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WFP vs LWF for VPN Tunnel

Thanks, David! That will do it for me.

What about my concern about packet injection?

“I suppose all I need to do is call
FwpsInjectNetworkSendAsync0, but that seems like it injects the packet back
into the filter engine when all I want to do is send it down the driver
stack to the underlying miniport driver. Again, I can see how I can do this
with a LWF.”

“David R. Cattley” wrote in message news:xxxxx@ntdev…

“Absorbing” a packet in WFP is straight forward.

See FWPS_CLASSIFY_OUT_FLAG_ABSORB

Good Luck,
Dave Cattley

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Thanks, David!

That clarifies things very nicely.

“David R. Cattley” wrote in message news:xxxxx@ntdev…

I think you should consider whether what you think you want really makes
sense.

Your VPN presumably takes an IP packet and encapsulates in some other IP
packet. At the very least you probably change the destination IP address
and thus potentially invalidate any interface selection, etc. that might
have occurred prior to your callout receiving the packet.

So now you go create a new packet. And let’s face it, it is a new packet.
Well all of that outbound processing, including other filters, callouts,
etc. really *should* be applied to this new packet. And WFP ensures that
that occurs in a rational way.

And what exactly makes you conclude that the packet as you have created it
will even get to a ‘underlying miniport driver’ (I presume you mean
interface/NIC)?

Suppose the outbound interface for your resulting packet is another VPN
interface?

This was the problem with the disaster of building VPN encapsulation logic
in IM drivers (and yes, the same problem exists for LWFs). There is no
sanity when it comes to multiple VPNs. WFP provides a means to rationalize
that by saying that injection outbound always passes through a predefined
set of layers (depending on the injection layer) and that injection inbound
always passes through a predefined set of layers (again, depending on the
injection layer).

Your VPN lower edge is a ‘client’ of the local network stack, not a protocol
bound to an interface. IM and LWF (layer 2) based IPSec VPNs have untold
complexity and nonsense in them to undo, the redo, the fact that they are at
L2. WFP liberates the VPN implementation from that nonsense.

So go with it. You will be much happier.

But I do have one question: Does your notion of ‘VPN’ introduce a interface
when connected? For example, a “virtual adapter”? Because if so, why do
you need to intercept & process packets at WFP (L3) or LWF (L2)?

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of SoquelDude
Sent: Tuesday, January 15, 2013 8:08 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WFP vs LWF for VPN Tunnel

Thanks, David! That will do it for me.

What about my concern about packet injection?

“I suppose all I need to do is call
FwpsInjectNetworkSendAsync0, but that seems like it injects the packet back
into the filter engine when all I want to do is send it down the driver
stack to the underlying miniport driver. Again, I can see how I can do this
with a LWF.”

“David R. Cattley” wrote in message news:xxxxx@ntdev…

“Absorbing” a packet in WFP is straight forward.

See FWPS_CLASSIFY_OUT_FLAG_ABSORB

Good Luck,
Dave Cattley

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer