default IPSEC stack dropping ESP packets

Hi All,

I am getting problem while sending ESP packets in a VPN solution.
We are sending ESP by using RAW sockets.

On inbound connection the windows default stack is dropping packets and it
is increasing BadSPIPkt count.

by using wfpdiag i could see that the following default IPSEC wfp layers
are registered.


12

Further I could see
FWPM_CALLOUT_IPSEC_FORWARD_INBOUND_TUNNEL_V4

FWPM_CALLOUT_IPSEC_FORWARD_OUTBOUND_TUNNEL_V4

FWPM_CALLOUT_IPSEC_FORWARD_INBOUND_TUNNEL_V6

FWPM_CALLOUT_IPSEC_FORWARD_OUTBOUND_TUNNEL_V6

If anyone can suggest that how can I bypass this it will be helpfull.

I tried disabling firewall but it does not help.

Here netsh show the statistics.
IPsec Statistics
----------------

Active Assoc : 0
Offload SAs : 0
Pending Key : 0
Key Adds : 0
Key Deletes : 0
ReKeys : 0
Active Tunnels : 0
Bad SPI Pkts : 616
Pkts not Decrypted : 0
Pkts not Authenticated : 0
Pkts with Replay Detection : 0
Confidential Bytes Sent : 0
Confidential Bytes Received : 0
Authenticated Bytes Sent : 0
Authenticated Bytes Received: 0
Transport Bytes Sent : 0
Transport Bytes Received : 0
Bytes Sent In Tunnels : 0
Bytes Received In Tunnels : 0
Offloaded Bytes Sent : 0
Offloaded Bytes Received : 0

The Windows native IPSec engine sits between the NETWORK and TRANSPORT layers in the WFP architecture. All inbound IPSec traffic is absorbed by the native IPSec engine. Nothing passes up to ‘raw sockets’ on protocol AH or ESP. To process your return AH/ESP packets you must intercept them at the IPPACKET callout layer of WFP and divert them to your inbound IPSec engine processing.

There is some background material on WFP and IPSec here:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff546423(v=vs.85).aspx

While that is not exactly a blueprint for how it all works and what you need to do, it is about the totality of the ‘hints’ on how to add a third-party tunneling scheme into WFP.

Good Luck,
Dave Cattley

Hi Dave,

Thanks for your reply, I was looking if we could do some policy
configuration to bypass those packets from default IPSec engine.

Regards,
Ravish

On Tue, Jun 7, 2016 at 1:08 AM, Dave Cattley wrote:

> The Windows native IPSec engine sits between the NETWORK and TRANSPORT
> layers in the WFP architecture. All inbound IPSec traffic is absorbed by
> the native IPSec engine. Nothing passes up to ‘raw sockets’ on protocol
> AH or ESP. To process your return AH/ESP packets you must intercept them
> at the IPPACKET callout layer of WFP and divert them to your inbound IPSec
> engine processing.
>
>
>
> There is some background material on WFP and IPSec here:
>
>
>
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff546423(v=vs.85).aspx
>
>
>
> While that is not exactly a blueprint for how it all works and what you
> need to do, it is about the totality of the ‘hints’ on how to add a
> third-party tunneling scheme into WFP.
>
>
>
> Good Luck,
>
> Dave Cattley
>
>
>

Hi Dave,

can we use manual SA keying, but it will use the MS IPSEC engine.
https://msdn.microsoft.com/en-us/library/bb451820(v=vs.85).aspx

My understanding is Windows IPSEC will decrypt the ESP packet and discard
the inner IP header and inject into Transport layer and packets will reach
directly to the intended applications.

Please suggest!
Regards,
Ravish

On Thu, Jun 9, 2016 at 12:40 AM, Ravish Yadav
wrote:

> Hi Dave,
>
> Thanks for your reply, I was looking if we could do some policy
> configuration to bypass those packets from default IPSec engine.
>
>
> Regards,
> Ravish
>
>
>
>
>
> On Tue, Jun 7, 2016 at 1:08 AM, Dave Cattley wrote:
>
>> The Windows native IPSec engine sits between the NETWORK and TRANSPORT
>> layers in the WFP architecture. All inbound IPSec traffic is absorbed by
>> the native IPSec engine. Nothing passes up to ‘raw sockets’ on protocol
>> AH or ESP. To process your return AH/ESP packets you must intercept them
>> at the IPPACKET callout layer of WFP and divert them to your inbound IPSec
>> engine processing.
>>
>>
>>
>> There is some background material on WFP and IPSec here:
>>
>>
>>
>>
>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff546423(v=vs.85).aspx
>>
>>
>>
>> While that is not exactly a blueprint for how it all works and what you
>> need to do, it is about the totality of the ‘hints’ on how to add a
>> third-party tunneling scheme into WFP.
>>
>>
>>
>> Good Luck,
>>
>> Dave Cattley
>>
>>
>>
>
>

Hi Dave,

Another driver-user mode based scheme I am thinking

=>Get the ESP packets from FWPS_LAYER_INBOUND_IPPACKET_V4/V6 send it to
User Mode Service.
My question is does this layer receive whole IP packet or it can
be fragmented.
=>User Mode service decrypt the packet and send to virtual adapter and
virtual interface indicate the packets to NDIS.
=On send path we can use RAW socket.

Please suggest.

On Fri, Jun 10, 2016 at 7:55 AM, Ravish Yadav
wrote:

> Hi Dave,
>
> can we use manual SA keying, but it will use the MS IPSEC engine.
> https://msdn.microsoft.com/en-us/library/bb451820(v=vs.85).aspx
>
> My understanding is Windows IPSEC will decrypt the ESP packet and discard
> the inner IP header and inject into Transport layer and packets will reach
> directly to the intended applications.
>
> Please suggest!
> Regards,
> Ravish
>
> On Thu, Jun 9, 2016 at 12:40 AM, Ravish Yadav
> wrote:
>
>> Hi Dave,
>>
>> Thanks for your reply, I was looking if we could do some policy
>> configuration to bypass those packets from default IPSec engine.
>>
>>
>> Regards,
>> Ravish
>>
>>
>>
>>
>>
>> On Tue, Jun 7, 2016 at 1:08 AM, Dave Cattley wrote:
>>
>>> The Windows native IPSec engine sits between the NETWORK and TRANSPORT
>>> layers in the WFP architecture. All inbound IPSec traffic is absorbed by
>>> the native IPSec engine. Nothing passes up to ‘raw sockets’ on protocol
>>> AH or ESP. To process your return AH/ESP packets you must intercept them
>>> at the IPPACKET callout layer of WFP and divert them to your inbound IPSec
>>> engine processing.
>>>
>>>
>>>
>>> There is some background material on WFP and IPSec here:
>>>
>>>
>>>
>>>
>>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff546423(v=vs.85).aspx
>>>
>>>
>>>
>>> While that is not exactly a blueprint for how it all works and what you
>>> need to do, it is about the totality of the ‘hints’ on how to add a
>>> third-party tunneling scheme into WFP.
>>>
>>>
>>>
>>> Good Luck,
>>>
>>> Dave Cattley
>>>
>>>
>>>
>>
>>
>

I suggest you become very familiar with the public documentation on WFP call-out drivers.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff571068(v=vs.85).aspx
In that you will find explanations for what happens at the FWPS_LAYER_INBOUND_IPPACKET_V* with respect to fragments.
The short answer is you can get ‘both’ the IP fragments and the reassembled IP datagram.
As for your suggested architecture - sure, I don’t see any reason why that is not viable.
Are you targeting Win7? If not then have you considered just creating a VPN provider application? Many VPN vendors have done so.
Good Luck,Dave Cattley

Hi Dave,

Thanks for your input , I have done programming for WFP on other layer but
thanks for your input on IP layer fragmentation i will go through in
details.

Any comments for Manual SA keying of MS IPSEC.

Regards,
Ravish

On Fri, Jun 10, 2016 at 4:11 PM, Dave Cattley wrote:

> I suggest you become very familiar with the public documentation on WFP
> call-out drivers.
>
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff571068(v=vs.85).aspx
>
> In that you will find explanations for what happens at the
> FWPS_LAYER_INBOUND_IPPACKET_V* with respect to fragments.
>
> The short answer is you can get ‘both’ the IP fragments and the
> reassembled IP datagram.
>
> As for your suggested architecture - sure, I don’t see any reason why that
> is not viable.
>
> Are you targeting Win7? If not then have you considered just creating a
> VPN provider application? Many VPN vendors have done so.
>
> Good Luck,
> Dave Cattley
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

> Any comments for Manual SA keying of MS IPSEC.
Only that I have not found it particularly useful. It is not the equivalent of PFKEY. WFP IPsec API does really make it possible to truly add an alternate keying module for IPSec.
YMMV.
Good Luck,Dave Cattley