Forums

[Vadim Smirnov]

Can you give more info about it?
How I must install driver?
What version of Kerio has conflict with WinPKFilter?

Actually the only requirement for WinpkFilter driver is starting between NDIS.SYS and TCPIP.SYS, but some hooking drivers(like the case with Kerio) may add additional conditions (like start before or after these drivers). In case with Kerio the conflict was detected when WinpkFilter driver strats before Kerio driver, but the problem gone if WinpkFilter starts after Kerio. Thats why we had changed load order to “Streams Drivers” Start:1. However, the situation may change from release to release (by the date of the post mentioned the problem was with the newest Kerio release, and there were no problems with previous releases).

[Vadim Smirnov]

You can create PASS ALL rule for the interface you want to disable NeT Firewall at. This rule should have highest priority(an example ID=1).

[Vadim Smirnov]

Could you please e-mail the screenshot of the log with blocked packets and the screenshot of the rules list to [email protected].

[Vadim Smirnov]

By default only fragmented packets are dropped in low security mode, others are passed.

What the reason is speciifed for blocked packets? Is it a rule or just General Security Policy?

[Vadim Smirnov]

You can start from PASSTHRU sample from WinpkFilter package and extend it to the firewall by adding packet analises routines.

[Vadim Smirnov]

At the NDIS level program context is not available for the packet but you can limit bandwidth by IP-address/IP-protocol/port information. So, an example you can limit HTTP bandwidth and etc… In order to limit bandwidth for certain application you would also need application level filter (LSP, TDI filter) in order to match application name to IP/protocol/port information extracted from the packet at the NDIS level.

Hope it helps…

[Vadim Smirnov]

WinPkFilter can send it ?

Yes

if WinPkFilter can send the packet, How can i send them ?

Using SendPacketToAdapter function.

[Vadim Smirnov]

I am not touching the ACK/SYN at all, I am modifying the ip_len and the payload only. that too, if the packet has payload then only i am modifying the packet.

If you change length of the TCP packet then you should modify SYN/ACK fields.

Is there any way I can drop the old packet? How can I remove it from the local stack?

Actually you already drop the original packet, but system generates it again and again (because your invalid packet is droped by remote system).

[Vadim Smirnov]

Probably you modify TCP packet and do this wrong. Destination system drops your packet and don’t send ACK for it, thats why your local stack sends packet again after some timeout.

[Vadim Smirnov]

You can try using MSTCP_FLAG_LOOPBACK_BLOCK for the adapter you work over. It drops incoming packets if source MAC is the same as local MAC. Regretfully there is no way to prevent packet indication on NT4 at all.

[Vadim Smirnov]

Personally I use this one

//
// Function recalculates IP checksum
//
VOID
RecalculateIPChecksum (
iphdr_ptr pIpHeader
)
{
unsigned short word16;
unsigned int sum = 0;
unsigned int i = 0;
PUCHAR buff;

// Initialize checksum to zero
pIpHeader->ip_sum = 0;
buff = (PUCHAR)pIpHeader;

// Calculate IP header checksum
for (i = 0; i < pIpHeader->ip_hl*sizeof(DWORD); i=i+2)
{
word16 = ((buff<<8)&0xFF00)+(buff[i+1]&0xFF);
sum = sum+word16;
}

// keep only the last 16 bits of the 32 bit calculated sum and add the carries
while (sum>>16)
sum = (sum & 0xFFFF)+(sum >> 16);

// Take the one’s complement of sum
sum = ~sum;

pIpHeader->ip_sum = htons((unsigned short) sum);
}

[Vadim Smirnov]

#define NDIS_FLAGS_DONT_LOOPBACK 0x00000080

[Vadim Smirnov]

NDIS_FLAGS_DONT_LOOPBACK and NDIS_FLAGS_SKIP_LOOPBACK prevents the packet from being indicated back. However, these flags are OS/NDIS specific. You can see some details here http://www.ndis.com/papers/loopback.htm

[Vadim Smirnov]

Could you please post the rule you have created and short description what it is supposed to do, probably there is something wrong with it.

[Vadim Smirnov]

Why only TCP/IP adapters can be filtered?

It is by driver design. However, driver can be extended to work below other protocols in addition to TCP/IP.

For example, you can add some flag to internal structure of packet in driver code and when program try send non TCP/IP packet to stack, driver can detect this by flag and just drop this packet…

TCP/IP is the primary protocol in the meantime and WinpkFilter main purpose is modification of it’s behaviour on different ways (firewall, NAT, VPN and etc…). Filtering absolutely all protocols on the system would cause a real mess and perfomance degradation (protocols can be joint into the stacks in the form of IM drivers, like the bridge you have mentioned).

[Author]

Posts