Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 1,216 through 1,230 (of 1,391 total)
  • Author
    Posts
  • in reply to: conflict with Sygate Personal Firewall #5851
    Vadim Smirnov
    Keymaster

      Well, yes it looks that Sygate is a problem. Their NDIS driver makes a dirty hook by modifying TCPIP.SYS module image (ArpSend routine if I remember fine). The only possible work around I could find is re-patching TCPIP.SYS after Sygate driver, but I really don’t like this solution. You can try to explain Sygate that dirty hacking is no good but I don’t think they would listen.

      Latest WinpkFilter release also includes NDIS IM variant of WinpkFilter driver. Basically it was created to be used for Windows x64 (patching system is hardly possible there unless patching KeBugCheckEx in the kernel or something of this kind, see the notes from MS here http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx). However, you can also use this driver for the latest operating systems (Windows 2000/XP/2003). By design it can coexists with Sygate driver, so it’s also a variant.

      in reply to: WinpkFilter news/updates. #5506
      Vadim Smirnov
      Keymaster

        Internet Gateway 1.0 released. This is the first sample (even more than sample, it can be successfully used in the real environment) from the Advanced WinpkFilter Samples series which is targeted to demonstrate WInpkFilter libraries applicability. The source code for Internet Gateway is available to all registered WinpkFilter customers.

        in reply to: WinpkFilter news/updates. #5505
        Vadim Smirnov
        Keymaster

          WinpkFilter 3.0.1 released. This service release includes:

          1. Few improvements/bugfixes in legacy Windows 9x/ME driver.
          2. Slightly changed driver API structures. Please refer WinpkFilter online documentation for the details.
          3. All sample applications and API DLL now include Visual Studio 2005 projects. This greatly simplifies development under Windows XP/2003 x64.

          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.

          in reply to: Bandwidth limitation help needed #5850
          Vadim Smirnov
          Keymaster

            Determine all connections for the application (with LHMON) and limit bandwidth for these connections. Usually bandwidth limit is realized using packets queue and timer. An example, timer triggeres each 100 ms, in the timer routine you calculate how many ms passed since last timer (Windows is not RTOS) and calculate how many bytes you can process from the application associated packets queue. After this you should process as many packets from the queue as covered by these bytes.

            Hope it helps…

            in reply to: NeT Firewall rules #5848
            Vadim Smirnov
            Keymaster

              In general it’s hardly possible to create common rules, because these rules should contain your (or/and remote system IP’s). However, for the Internet user (not a server system) usually it’s more than enough to use one of the Stealth modes without setting any additional rules.

              in reply to: softice bugs? #5844
              Vadim Smirnov
              Keymaster

                Качни с Compuware последний osinfo.dat. Обычно помогает.

                in reply to: Redirect after filter on packets #5836
                Vadim Smirnov
                Keymaster

                  In case of proxy packet directed to IPproxy (where IPproxy is the proxy IP address). You still can redirect packets from IPproxy to your IP (I assume you fully control this system) and process it by your own proxy.

                  Another possible approach is parsing/modification of HTTP(DNS) packets payload but it’s a bit more complicated.

                  in reply to: Host name #5843
                  Vadim Smirnov
                  Keymaster

                    Sorry, but using hostname for the rule is not possible (actually it would be potentionally dangerous security hole). Making a work around depends from your configuration and security requirements so it is a bit difficult to advise.

                    in reply to: Redirect after filter on packets #5834
                    Vadim Smirnov
                    Keymaster

                      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.

                      in reply to: WinpkFilter news/updates. #5504
                      Vadim Smirnov
                      Keymaster

                        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.

                        in reply to: In-kernel IP-IP tunnel driver #5832
                        Vadim Smirnov
                        Keymaster

                          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).

                          in reply to: In-kernel IP-IP tunnel driver #5830
                          Vadim Smirnov
                          Keymaster

                            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.

                            in reply to: WinPkf for Windows 64 #5829
                            Vadim Smirnov
                            Keymaster

                              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).

                              in reply to: Modified packets sent from LAN to WAN across NAT (chcksm ok) #5827
                              Vadim Smirnov
                              Keymaster

                                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.

                                in reply to: trial to full version… How upgrade ? #5825
                                Vadim Smirnov
                                Keymaster

                                  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.

                                Viewing 15 posts - 1,216 through 1,230 (of 1,391 total)