windows doen't answer on encapsulated ping (NDIS6 LWF based VPN solution)

Good day everyone!

My tunneling solution consists of helper application and LWF.

App adds ip (AddIPAddress) to create a virtual network, sends encapsulated
packets over the tunnel, extracts encapsulated packets and make filter to
indicate them as if they came right from the wire

Filter completes NBLs that has to be rerouted with success status and send
this packet to the applcation, also filter indicate packets that came over
tunnel with NdisFIndicateReceiveNetBufferLists.

I’m testing this with ping. Problem is that overlying protocol never
answers to ICMP packet that i indicate with
NdisFIndicateReceiveNetBufferLists.

Here is a little log of what happens on pingee.
First - ping on the real network:
************************************************************************************
recv operation

this is arp packet
src mac address 0.c.29.f7.6f.82
src ip4 address 172.20.1.234 request from pinger to resolve target
address
dst mac address 0.0.0.0.0.0
dst ip4 address 172.20.1.233
packets passing through

send operation

this is arp packet
src mac address 0.c.29.e3.cd.7e
src ip4 address 172.20.1.233 answer to pinger with address
resolution
dst mac address 0.c.29.f7.6f.82
dst ip4 address 172.20.1.234
packets passing through

recv operation

this is ip4 packet
source address is 172.20.1.234
dest address is 172.20.1.233 incoming ping
transport level protocol is 1
packets passing through

send operation

this is arp packet
src mac address 0.c.29.e3.cd.7e
src ip4 address 172.20.1.233 request to pinger to resolve
target address
dst mac address 0.0.0.0.0.0
dst ip4 address 172.20.1.234
packets passing through

recv operation

this is arp packet
src mac address 0.c.29.f7.6f.82
src ip4 address 172.20.1.234 answer from pinger with address
resolution
dst mac address 0.c.29.e3.cd.7e
dst ip4 address 172.20.1.233
packets passing through

send operation

this is ip4 packet
source address is 172.20.1.233
dest address is 172.20.1.234 answer to incoming ping
transport level protocol is 1
packets passing through
**************************************************************************************

and here what happens on virtual network

**************************************************************************************

recv operation

this is arp packet
src mac address 0.c.29.f7.6f.82
src ip4 address 10.10.1.2
dst mac address 0.0.0.0.0.0
dst ip4 address 10.10.1.3
packets passing through

address resolution

send operation

this is arp packet
src mac address 0.c.29.e3.cd.7e
src ip4 address 10.10.1.3
dst mac address 0.c.29.f7.6f.82
dst ip4 address 10.10.1.2
packets passing through

recv operation

this is ip4 packet
source address is 172.20.1.234
dest address is 172.20.1.233
this is udp packet encapsulated ping
source port is 62607
dest port is 1333
packets passing through

indicating operation

this is ip4 packet
source address is 10.10.1.2 extracted packet that my application tells
me to indicate
dest address is 10.10.1.3
transport level protocol is 1

!!! here no response from overlying protocol

recv operation

this is arp packet
src mac address 0.c.29.f7.6f.82
src ip4 address 172.20.1.234
dst mac address 0.c.29.e3.cd.7e
dst ip4 address 172.20.1.233
packets passing through

send operation

this is arp packet
src mac address 0.c.29.e3.cd.7e
src ip4 address 172.20.1.233
dst mac address 0.c.29.f7.6f.82
dst ip4 address 172.20.1.234
packets passing through

**************************************************************************************

I don’t know maybe i’ve made some sort of obvious mistake in concept (i’am
FS guy actually, it’s just no one else here knows how to develop windows
drivers at all)

Any ideas will be greatly appreciated.
Thanks