Forum Replies Created
-
Posts
-
Hello Roelof,
WinpkFilter drivers works on the bottom of the Windows network stack (below TCP/IP), but application layer of Windows XP firewall works on the top of network stack (otherwise it won’t be able to control applications network access). So I don’t think that there is any easy solution to this problem.
However, may be setting up the virtual network interface, disabling Windows firewall for it and bridging it to the real network interface using WinpkFilter can solve the problem. It’s just the first idea, may be some other tricks are also possible…
Hope it helps…
You can also use medium type. See parameters passed/returned to/from NdisOpenAdapter: SelectedMediumIndex, MediumArray.
There is also a chance that you system is heavily loaded and user mode application can’t read driver log fast enough. In this case driver’s internal packet log is overloaded and it may drop some data blocks.
When you set High Security level then only packets are passed only there is a corresponding allow rule exists. So there is no wonder that your packets were blocked.
If you server works as an Internet Gateway using 3rd Stealth Level for the external card would be enough, by default all outgoing connnections are allowed but all incoming packets are blocked unless they belong to one of the locally established connections. However, this mode is strict enough, so some complex protocols which use multiply streams may have problems with it. If you use any of them you’d better use Stealth Level 2 or even Stealth Level 1.
High Security level is the best mode for the stand alone server which provides some certain services, like HTTP, FTP, e-mail and etc..
What a problems do you have when configuring firewall through Terminal Server Client session? The only possible problem is running the multiply instances of MMC console, because only one instance can work normally with firewall engine.
For the server environment I would recommend to run firewall as a service, starting MMC console only when you need to make some connfiguration changes. This would save you a lot of system resources.
I’m not sure but I think the problem is that LeechFTP uses passive FTP mode (bot connections are established by client).
In this case:
1) client sends command PASV to server.
2) server start listening newly allocated port and responses with command PORT with its number.
3) client connects to this port => data channel is established.I would recommend you to try some other FTP clients to check this issue, an example integrated into Windows http://ftp.exe. If I remember fine then explorer and IE also uses passive mode by default, but http://ftp.exe does not.
Localhost Monitor works at TDI level, so there are no actual packets there, but blocks of data instead. Some blocks can be splitted or merged, probably this is what you’ve expirienced…
Could you please be a little bit more specific? What do you mean by stating “not always known”?
At the time of connection establishment the IP address was not specified explicitely. Just treat 0.0.0.0 as anyt local IP.
“IP Address 0.0.0.0” is just any local IP address (it’s not always known from which concrete IP the connection will work from at the time of connection establishment).
Hmm, don’t you think that if you could disable/uninstall firewall remotely then this firewall won’t provide any security at all? If you have the proprietary rights on the remote system (administrator) then you can disable/uninstall firewall remotely (if it is configured to allow the connections you use for administrative purposes, otherwise you won’t be able to connect) or locally. Otherwise this is not possible.
There should be no problems specific to Windows 2003 Server… You should use the same registry settings as for Windows 2000/XP. I would recommend to remove everything (driver and registry entries), reboot and reinstall everything from the scracth.
Hope it helps…
