Comodo is Blocking my ftp client

I am using SmartFTP and Comodo 3 is blocking it. Comodo 2 did not. How do I configure v3 to allow my ftp Client (uses port 21)

You need to add a rule to allow passive ftp to your default rules for an ftp client.


Active FTP mode will not work with the default ftp client rules either. PORT command is successful, but after that, nothing. Comodo will log a blocked incoming connection with remote port 20, though the rule to allow it is there and the application(s) are defined as “ftp client”. Tried Filezilla and Windows command line ftp client.

I use CuteFTP Pro and set it as a trusted application. It seems to work fine. Is this OK?

Yes, that will work fine. Only problem is if you use the Comodo ftp client ruleset-which many people do, just because it’s there.

Thanks, I don’t need no stinkin’ rules! (:WIN)

ruoja, what are your global rules? They are executed first for incoming connections, and if there is a “block incoming” there it would take precedence over the CuteFTP Pro rules. What is your OS and Comodo version? I just used Filezilla to connect to the same site with and without the PASV and it worked fine-I also have the Passive FTP rule in the client ruleset, but nothing in the global rules.

I’ve not defined any global rules myself, they are as set during installation. I chose to not ask about incoming connections.

Allow All Outgoing Requests If The Target Is In [LAN adapter]
Allow All Incoming Requests If The Sender Is In [LAN adapter]
Block And Log IP Any To IP Any Where Protocol Is Any

Firewall in “Custom Policy” mode

Comodo version
Windows XP Professional SP2

If this is not the correct configuration, how can I set up Comodo to block all by default but allow my custom per-app rules to override?


You need to remove the “block and log” from the global rules. You can put it at the end of the Application rules, and it should block all incoming and outgoing not specifically allowed.

Okay, that works. Thank you.

It would seem more intuitive to allow application rules to override by default and not needing to specifically create a “deny all” application rule.

Service alerts about opening listen sockets to respond to would be a nice option to have also.

Does removing the “Block ang Log” command from the end have any implications for the general firewall, like leaving it wide open?

I put the block and log at the end of all the application rules, just in case it is not already implicit. If there is an incoming connection request, its destination will get a shot at allowing it (via rules) before it is blocked and logged. But I allow very few incoming connection requests (active ftp happens to be one of them). If you leave it in the global ruleset, which is scanned first for incoming connections, you should never get an incoming connection. So I don’t see any security implications, since you desire to allow limited incoming connections.

Thanks - I’ve just done the same - putting a catch-all “Block and Log” rule for all incoming traffic qt the bottom of the Network Security Policy list. This seems to be working fine for Filezilla at least. Would it be better to set this for both incoming and outgoing traffic or would this impact learning?

I like the concept of “if all the above fails, then block and log the event” type of rule. Makes me feel safe :slight_smile: Now the logic seems to make sense. Firstly execute the global rules (allowing the trusted traffic from my LAN) then work down the list of rules for the WAN, hitting the “block and log” if it gets that far.

for active ftp add a global rule allow tcp in where source port is 20

I’m also trying to do some FTPing right now, and according to what you say, to the Wikipedia, and to my experience, CFP’s “FTP client” predefined policy is not enough for a FTP client, global rules aside. ??? What gives?

Outgoing only policy can handle passive ftp.
For active ftp (ftp clients policy) a global rule is needed. What I could say. Maybe an entry in the help file could help to decrease these help requests.

Usually default settings don’t add any inbound to global rules.
Anyway members that dont have any block all rule in global policy are not affected by this issue.

I think part of the confusion is that the FTP Client rule entitled “allow outgoing FTP connects” actually only allows connections to port 21. You can change that to “any”, but I have been adding a separate passive rule with “any” that can be omitted by those actually using active FTP. And as Girbran points out, you can add all of the allowed inbounds to the global rules instead and leave the global block all in place. I prefer to do it at the lower level instead and eliminate the block all, but I was a Kerio user for some time and got used to creating rulesets that way. :wink:

Indeed, I can’t download anything with the browser via ftp with the “allow outgoing FTP requests” rule because there are connections outside port 21 (always from 1024 up) that get blocked:

Actually I think that each first connection is always through one of these ports. ??? So I’ve modified the rule, now instead of port 21 it says “FTP Ports” set, which I’ve defined as {21, 1024 ~ 65535}, and now it works.

When using not just the browser but a FTP client to upload and modify the files in the server, the same rule seems to be enough without any inbound connections, since I have a “block ip in from ip any to ip any protocol any” at the top of the global rules. All these were outbound:

By the way I’m using Windows Explorer (explorer.exe) as FTP client, :o is there some good reason not to do this?

Depends on what you are doing with ftp. Something like Filezilla (free) allows restarts, multiple downloads, … etc and maintains a library of passwords, site characteristics, etc. so you can download regularly used items very effectively. If you are downloading something large, using a program like Free Download Manager breaks the job up into a bunch of pieces, downloads the pieces as fast as your network will allow, works around the stalls that sometime occur with ftp, and puts it all back together for you at the end. Along with all the other ftp client features. It can really speed up downloading, especially if you have something like a noisy wifi link. If you just download files you find with your browser that allow either http or ftp, it is more convenient to do it from your browser. I use them all, depending on the site, and use a dedicated ftp client to maintain my own website.

Okay thanks, I figured it would be about features. I really don’t need any more at the moment, only the very basics that Windows Explorer provides. Obviously when I just want to download something via FTP I stick with the browser. I started to fiddle with this because I’ve been thinking about starting a website with the space my ISP offers me (and which I haven’t used in almost two years, it was about time). For the kind of things I’m doing right now I won’t install anything additional for the moment, but thanks for your recommendations, I had already heard about Filezilla.