Forum Replies Created
-
Posts
-
Lets assume that you want to redirect user from IP1 to IP2. In order to do so you must do the following:
1) For the outgoing packet change destination IP from IP1 to IP2 and recalcuilate IP checksum. Save the connection state (IP’s, TCP ports).
2) For the incoming packet check if it is from IP2 and if yes also check port information (to be sure that this packet is associated with redirected connection). After this substitute source IP from IP2 to IP1 and recalculate IP checksum.
3) And so on… For the outgoing packets use 1) and use 2) for incoming.
WinpkFilter 3.0 released. This release introduces Windows XP x64 and Windows Server 2003 x64 support. Also includes few bugfixes and API extensions. Please refer WinpkFilter online documentation for the details. If you are eligible for a free update, please send the following details to support@ntkernel.com to receive an update instruction:
1) Your order ID.
2) An approximate date of purchasing.
Besides DeviceRawIp, is there any other way to inject a raw IP packet to TCP/IP protocol stack? Seems NDIS Intermediate Driver not usable, because the raw IP packet needs to be routed.
You can inject packet using NDIS IM or NDIS hook driver (up to the stack or down to the network interface) but you must know exactly what you are doing (to choose correct network interface and packet indication).
DeviceIp can’t be used for sending custom packets, in general it is used for managing TCP/IP protocol stack, not for communication (however, there is an IOCTL used for sending ICMP PING). However, I think you can use deviceRawIp. I have never tried it myself but I suppose it provides TDI transport interface for sending/receiving raw IP packets.
Other ideas look OK.
Thanks for choosing WinpkFilter. Actually 64 bit version of WinpkFilter driver is ready and we are running last series of tests with it. I hope it will be released in a week or two.
Few notes regarding new driver. Because of new Microsoft patching policy for 64 bit Windows (http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx) we created 64 bit version using NDIS intermediate driver as a base (instead NDIS-hooking one), however new driver exports same API’s and internally shares the common code (folder COMMON) with VxD and NDIS hooking 32 bit NT driver, so there should not be a problem to move your existing code to this new environment. The NDIS IM installation issue (unsigned driver installations warnings) can be easily resolved by run-time changing security policy, installing driver and restoring policy (it works well on the modern 64 bit systems).
I would start analyses of this problem with the simplest packet which expected to be replied by MSTCP – ICMP ping. It has simple structure, so it must be easy to verify that the packet which you indicate from the name of the WAN interface after decapsulation is OK.
I have one idea regarding problems with WAN you have, what MAC addresses do you have in the Ethernet header? If when operation over LAN it does not matter much, then over WAN you must use pair of MAC’s associated with particular WAN connection. In your case you must use MAC’s from the original (UDP?) packet received over WAN, but not the MAC’s that packet had before encapsulation or any other MAC’s. Otherwise NDISWAN fails to associate packet with the particular WAN connection and silently drops it.
May be this is not your case, but this is one of the common problems with WAN. If it does not help then please provide more details and I hope we will be able to figure out the exact reason.
You can install the full version over (into the same folder) the trial one and reboot (both trial and full use the same registry keys to keep you rules and settings). Don’t forget to shutdown the trial version before installing the full one (otherwise some files may fail to be replaced).
You can also export your rules to the file, uninstall trial, install full version, reboot and import rules from the file.
One note, log size is limited and after the maximum size reached MMC applet removes the oldest entries from the log to release place for the new entries. Also, in order to update log screen press “Refresh” button in the toolbar. hope it helps.
I had looked through the realization of VLAN in Linux and yes it can be implemented even on low cost adapters because all drivers are available in source code and you can easily increase the ethernet frame size in the NIC driver. But in Windows you can’t modify the source code of the driver for your network card and all packets will be truncated to 1514 bytes. You still can create VLAN for the cost of MTU (packets on the network will be still 1514 bytes but MTU will be decreased from 1500 to 1496 bytes). MUX sample driver from the DDK implements VLAN by this way. However, this implemetation won’t be compatible with Linux VLAN (which uses larger MTU), without additional tricks like decreasing MTU because any incoming packet over 1514 bytes will be truncated. So complete realization of VLAN in Windows is hardly possible without special NIC/drivers…
Just found here http://support.intel.com/support/network/sb/cs-005897.htm that
By default, Intel adapters strip the VLAN tag before passing it up the stack.
In this case WinpkFilter receives 802.3 frame without VLAN tag and there is no way to access it without additional efforts. Even if you do the modifications mentioned on that page to turn off stripping tag then I’m not sure that TCP/IP stack will be able to process these packets with extended header normally.
I assume you mean VLAN tagging (inserting 4 additional bytes into the ethernet header). Well, current version of WinpkFilter limits the size of Ethernet frame to 1514 bytes but there is no problem to extend it to 1518 (or even to 1522) bytes if network card supports such a frame size (does it?).
However, does Windows TCP/IP stack supports VLAN? I just suspect that even if VLAN used the tags are stripped before packet reaches the TCP/IP stack…
First of all I don’t think that there is any documented way to access ICS table.
However, if you filter on the internal interface(LAN) you can differentiate packets destined to the external network (Internet) from the packets destined to the ICS server by their destination IP address. It is hardly possible possible on the external interface (after NAT applied), however you still can use information gathered (build your own copy of NAT table) on the internal network card.
Windows XP firewall can be configured to do drop/pass the packets you want. On the other hand WinpkFilter driver processes packets before TCP/IP stack and built-in firewall so basically you can make routing yourself.
