Alternatives of localRedirectContext in Win7 ?

NTDEV
1

Hey guys, Im developing a WFP callout driver for redirecting traffic to my user-mode local proxy application.

But FWPS_CONNECT_REQUEST0->localRedirectContext unaccessible at Windows 7, it’s available at Win8 and later.

The document of WFP describe it’s Store original destination IP/Port information use for local proxy service (user-mode).

The definition of FWPS_CONNECT_REQUEST0 in fwpsk.h is:

typedef struct _FWPS_CONNECT_REQUEST0
{
   //
   // Read-Write fields on a writable copy of the structure.
   //
   /* IN OUT */ SOCKADDR_STORAGE localAddressAndPort;
   /* IN OUT */ SOCKADDR_STORAGE remoteAddressAndPort;
   /* OUT */ UINT64 portReservationToken;

   //
   // When redirecting a connection to localhost, the callout must supply
   // the PID of the process that will be accepting the redirected connection.
   //

   /* OUT */ DWORD localRedirectTargetPID;

   //
   // Modification History. (Read-Only)
   //
   struct _FWPS_CONNECT_REQUEST0* previousVersion;
   UINT64 modifierFilterId;
#if (NTDDI_VERSION >= NTDDI_WIN8)
   //
   // Handle created using the FwpsRedirectHandleCreate0 function.
   //
   /* OUT */ HANDLE localRedirectHandle;

   //
   // Arbitrary callout supplied context allocated using the
   // ExAllocatePoolWithTag function.
   //
   /* OUT */ void* localRedirectContext;
   /* OUT */ SIZE_T localRedirectContextSize;
#endif // NTDDI_VERSION >= NTDDI_WIN8
} FWPS_CONNECT_REQUEST0;

Is there any solutions instead of it at win7 ?

My idea is:

  1. Store { local addr and port : original destination } pairs in hash table in my driver when a new connection is being to be redirected.
  2. Whenever each new connection connected to my local proxy application, application pends the connection (sync) or buffer its traffic data (async), then send a IOCTL with the local addr and port of new connection to driver.
  3. Driver received the IO request, then query original destination in hash table by the local addr and port in inputBuffer from application.
  4. Write original destination to outputBuffer and complete the IO request.
  5. After application receive the original destination, further redirect to original destination.

Will this solution cause any performance issues ?