[Vadim Smirnov]

If you look at the filter.cpp sample you can find the scenario which redirects only DNS packets to user mode and passes any other packets. Filters are defined as the following:

//**************************************************************************************

// 1. Outgoing DNS requests filter: REDIRECT OUT UDP packets with destination PORT 53

// Common values

pFilters->m_StaticFilters[0].m_Adapter.QuadPart = 0; // applied to all adapters

pFilters->m_StaticFilters[0].m_ValidFields = NETWORK_LAYER_VALID | TRANSPORT_LAYER_VALID;

pFilters->m_StaticFilters[0].m_FilterAction = FILTER_PACKET_REDIRECT;

pFilters->m_StaticFilters[0].m_dwDirectionFlags = PACKET_FLAG_ON_SEND;



// Network layer filter

pFilters->m_StaticFilters[0].m_NetworkFilter.m_dwUnionSelector = IPV4;

pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;

pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_UDP;



// Transport layer filter

pFilters->m_StaticFilters[0].m_TransportFilter.m_dwUnionSelector = TCPUDP;

pFilters->m_StaticFilters[0].m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_DEST_PORT;

pFilters->m_StaticFilters[0].m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = 53; // DNS

pFilters->m_StaticFilters[0].m_TransportFilter.m_TcpUdp.m_DestPort.m_EndRange = 53;



//****************************************************************************************

// 2. Incoming DNS responses filter: REDIRECT IN UDP packets with source PORT 53

// Common values

pFilters->m_StaticFilters[1].m_Adapter.QuadPart = 0; // applied to all adapters

pFilters->m_StaticFilters[1].m_ValidFields = NETWORK_LAYER_VALID | TRANSPORT_LAYER_VALID;

pFilters->m_StaticFilters[1].m_FilterAction = FILTER_PACKET_REDIRECT;

pFilters->m_StaticFilters[1].m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE;



// Network layer filter

pFilters->m_StaticFilters[1].m_NetworkFilter.m_dwUnionSelector = IPV4;

pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;

pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_UDP;



// Transport layer filter

pFilters->m_StaticFilters[1].m_TransportFilter.m_dwUnionSelector = TCPUDP;

pFilters->m_StaticFilters[1].m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_SRC_PORT;

pFilters->m_StaticFilters[1].m_TransportFilter.m_TcpUdp.m_SourcePort.m_StartRange = 53; // DNS

pFilters->m_StaticFilters[1].m_TransportFilter.m_TcpUdp.m_SourcePort.m_EndRange = 53;



//***************************************************************************************

// 3. Pass all packets (skipped by previous filters) without processing in user mode

// Common values

pFilters->m_StaticFilters[2].m_Adapter.QuadPart = 0; // applied to all adapters

pFilters->m_StaticFilters[2].m_ValidFields = 0;

pFilters->m_StaticFilters[2].m_FilterAction = FILTER_PACKET_PASS;

pFilters->m_StaticFilters[2].m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE | PACKET_FLAG_ON_SEND;



break;

Does this sample work for you?

[Vadim Smirnov]

Hi Ghita,

I can’t see the filters you have set, but I suspect that your filters for blocking TCP/UDP may be destination IP/MAC address specfic and therefore broadcast/multicast packets get passed (they have special broadcast/multicast MAC and IP adresses).

Hope it helps…

[Vadim Smirnov]

Thank you for the update. I’m glad that you have resolved the issue.

[Vadim Smirnov]

Could you provide more details?
1) ListAdapters output.
2) PassThru output. For this test ping one of other notebooks.
3) IPCONFIG output.

We are not aware about any issues with Windows 7, so it must be something about your configuration or usage.

[Vadim Smirnov]

To resolve an issue with DNS you can change all your filters from blocking to redirect and check filter ID in the DNS packets. So you can identify filter which selects DNS packets.

[Vadim Smirnov]

From what I can see filter 2 is supposed to block incoming packets on local port 80. If this is what you want to do and still incoming packets on port port 80 are not blocked then there is only one possibility – these packets are passed by filter 1.

[Vadim Smirnov]

I don’t have the filters code under hand at the moment but for the second filter I would add that it should be applied to TCP protocol.

[Vadim Smirnov]

Please clarify, are using an application build on top of WinpkFilter driver and this application reports that driver is missing?

[Vadim Smirnov]

Windows Packet Filter Kit 3.1.3 released:
– Changed approach to disable TCP task offload in NDIS LWF. Previous method had some known issues.

If you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:

1) Your order ID.
2) An approximate date of purchasing.

[Vadim Smirnov]

I’m not familier with IPSECVPN software you use, but yes, there are two possibilities:

1) IPSEC driver above WinpkFilter: in this case instead normal TCP/IP packets (all or only part of them depending on IPSEC policy) you intercept encrypted IPSEC packets. I’m not sure how your WinpkFilter software would deal with these packets (tries to tunnel or ignores).
2) IPSEC driver below WinpkFilter: in this case your UDP tunnel packets can be encrypted by IPSEC driver (depending on the policy).

I would check what packet you get in your WinpkFilter software and check what packet go out on the network media with network sniffer to discover the details.

[Vadim Smirnov]

Under Linux you can use http://www.netfilter.org/projects/libnetfilter_queue/

[Vadim Smirnov]

Windows Packet Filter Kit 3.1.2 released:
– Added Filter ID for the packets redirected by built-in filters
– Updated C# samples

If you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:

1) Your order ID.
2) An approximate date of purchasing.

[Vadim Smirnov]

Internet Gateway code simply treats all adapters with media different from NdisMedium802_3 as WAN. This is not correct of course, but works for most cases and good enough for the sample. I think your intrface reports media different from 802.3 and this causes described misbehave. NDIS_MEDIUM is defined as following:

typedef enum _NDIS_MEDIUM
{
NdisMedium802_3,
NdisMedium802_5,
NdisMediumFddi,
NdisMediumWan,
NdisMediumLocalTalk,
NdisMediumDix, // defined for convenience, not a real medium
NdisMediumArcnetRaw,
NdisMediumArcnet878_2,
NdisMediumAtm,
NdisMediumWirelessWan,
NdisMediumIrda,
NdisMediumBpc,
NdisMediumCoWan,
NdisMedium1394,
NdisMediumInfiniBand,
#if ((NTDDI_VERSION >= NTDDI_VISTA) || NDIS_SUPPORT_NDIS6)
NdisMediumTunnel,
NdisMediumNative802_11,
NdisMediumLoopback,
#endif // (NTDDI_VERSION >= NTDDI_VISTA)

#if (NTDDI_VERSION >= NTDDI_WIN7)
NdisMediumWiMAX,
NdisMediumIP,
#endif

There are too many things to improve in this sample to build a real NAT aplication suitable for different environments and it would take plenty of time to build a desired list. You’d better look at some solutions alreaddy available on market to see what features can be implemented.

[Vadim Smirnov]

Thank you for reporting this, but the more detailed network configuration would be appreciated. Like what network adapters do you have, what type and which of them are connected (ipconfig output?). And how Internet Gateway identifies these ones (may be screenshot?).

Although, I have to note that Internet Gateway is just a sample coded in a day to demonstrate usage of WinpkFilter driver for NAT solutions. And of course it does not pretend to be a well tested end user application.

[Vadim Smirnov]

Ndisrdmp is a miniport part of WinpkFilter NDIS IM driver. However, if you use one of the latest versions (starting 3.0.8) of WinpkFilter then it is supposed to install NDIS LWF driver on Windows Vista and later which does not have that part. Probably the WinpkFilter version you use is out-of-date.

[Author]

Posts