Bug? not stealthing ports correctly

It seems that with CFP Firewall there are problems in stealthing the ports:

Choosing Stealth Ports Wizard - setting Block all incoming connections - pressing Finish:

  1. reopening the same panel (Stealth Ports Wizard) the setting goes back to standard option (Define a new trusted network) discarding previous selection

  2. ports are not stealthed (I can check this for example on port 53 on my system) - you have to be careful as you are visible and some ports can be opened

Any similar experiences?

Thank you

  1. The display is a bit misleading. It always reverts to the first option-it is not intended to show status, just options. You can check under your global rules that the block has happened.
  2. Most common reason for non-stealthed ports if you run something like GRC Shields Up is if you are using a router. A router is often set up to respond to certain incoming, ahead of CFP Otherwise, CFP should not respond to unsolicited traffic from the internet with the stealth setting.

Thank you for answer.

point 1) it is something for a next minor bugs fix (misleading options can lead to dangers)

point 2) routers act mostly as additional firewall so they just dont do any harm to CFP! there is no traffic redirect of any kind, in my case

Anyhow stealthing has to be effective at client machine level.
How can I stealth my port 53 which is always reachable?

I am worried that without router any port would be not stealthed.
Where can I check my global rules as you mention?

I am new to CFP. please reassure this things works.
Please help!

Thank you

To check your global rules, go to firewall/advanced/network policy/global rules tab. The last rule should be a block and log all incoming requests. Port 53 should only be reachable if you have sent out a DNS query, unless your router is keeping it open to simplify itself by avoiding NAT. How do you verify it is open? To check your CFP protection: If you can, bypass the router and plug your ethernet cable directly into your modem from your computer. What kind of internet link do your have. eg cable or DSL, if DSL PPPOE or DHCP or static IP? Are you running Shields Up at www.grc.com?

Yes, I am using that GRC test. It can be that my router is answering to the GRC test packet, I just wonder how and why!

About those Global Rules I dont understand how they work:
DNS UPD out to any:53 allowed works ok
DNS UDP in from any blocked DOESNT WORK (at least if that is a DNS name server reply)

TCP OUT to any:80 allowed works ok, tcp request
TCP IN from any blocked DOES WORK and blocks my http request

Why the answer to the first UDP query is allowed superseding my user setup
and the answer to my TCP connection is blocked?
Should it not be the other way round as UDP is connectionless and TCP connection was started by my client?


The UDP request can only get the data requested by the destination sending back another UDP datagram. So CFP is smart enough to know that if you send out a DNS request, that you expect a DNS response back from the same destination. SPI is used to recognize this and keep the “block all in” global rule from inhibiting DNS, DHCP, a few other items that work like this.
TCP works differently and an outbound connection allows data to flow both ways. The connection does not use port 80 on your side, but a port assigned by a one-up-counter for each connection. HTTP will actually set up several TCP outs on port 80 if you look at the firewall/firewall tasks/view active connections display. This is because there is a separate TCP connection set up for each of the features on the page. There are no TCP in connections associated with http, so don’t know what you are blocking from your description. Maybe you can post a copy of your log?

I meant, I simply set a Network Control Rule in Global Rules

from any source address
to any destination address
source port: any
destination port: http ports (80,8080,443)
(Block all the rest)

This way my http browser connection doesnt work

If I modify the above with
then the http goes

why is TCP IN necessary?
We agree there is no TCP inbound connection necessary.

I thought it could be that the network rules are applicable to each single TCP packets, no matter if they are associated to a TCP outbound or TCP inbound connection but you seem to exclude this view.

Please help to understand.

It could be a good firewall but that there are too many feature not documented or out of user control - which experienced users dont like … intelligent enough can mean also intelligent enough to be a big trojan horse :smiley:


I don’t use global rules, but are you using the default “web browser” rules for your application? Would still like to see your whole set of global rules to see what is happening-maybe loopback? Does anything show up in your firewall log when http is blocked? One thing to do is make separate TCP in and TCP out rules, since the in/out sometimes confuses sources and destinations in CFP. Network rules are about connections, not tcp packets, and once you set up any tcp connection it is bidirectional in terms of data. You don’t need any global rules for http, just use the “web browser” default rules for your application.

Yep, you are right (I see that your title of Comodo’s hero is well deserved!!)

If browser (Firefox) loopback is enabled, then it will not connect if there is no TCP IN allowed as network global rule.
If loopback is disabled, it works correctly with TCP OUT allowed only.
At the moment I cannot figure out why, can you? whast the hell is browser doing with loopback?

Firefox communicates setup information with itself at initialization using TCP. The way that happens internal to a computer is to use (localhost) to send between two ports accessible to Firefox. Why Firefox communicates that way instead of other, ??? I use Opera. :slight_smile:

Thanks for technical explanation about Firefox!

By the way my problem has occured again:
I have changed location and updated my UDP rules to allow DNS resolution through a different router (

Firefox blocked again, logs say UDP DNS request by svchost.exe are blocked (despite all my rules allow it!)

only way out of it … allowing TCP IN in my network rules for a second, after that it works.

What is the relation between svchost.exe, UDP blocked and TCP in allowed?
I start to think Comodo is buggish …
I will report another problem in a different message.

Is your router set up to be acting as a DNS server? If it is, I am suspecting that there is router traffic in that is not being allowed. If not, you need to directly access an Internet DNS server like or My Web Browser rules are attached if that helps. The rules for svchost are usually buried under “Windows Updater Applications” and need to allow outgoing TCP and UDP. As mentioned in another post, upgrading to the firewall/D+ portion of CIS and not the AV/toolbar should fix some of the problems.

[attachment deleted by admin]

ya, some ports are not stealth by comodo

behaviour is erratic,

try checking your firewall by making a dialup connection to internet and then checking the shield up