Outbound ICMP echo replies are not blocked if outbond ICMP echo requests are sent(V3.0.14 X32)[Fixed]

hello, my english is low:(
if block my PC1 to same PI adress of PC2, PC2 can ping PC1.
Во время пинга удаленной машины комп открывается для пинга снаружи, даже если правилами Comodo это запрещено.

[attachment deleted by admin]

Moscow, спасибо конечно, что перепостил мою схемку на оф. форум :slight_smile:

This scheme is drawn by me and bug has been found by me too
Discussion here http: // Ошибка :: Компьютерный форум Ru.Board? forum=5topic=17980start=1880*14 (for Russian-speaking users)

The problem consists in the following: your computer with Comodo opens for entering echo-request and sends echo-reply even if present the rule of blocking for them.
Such it is observed only provided that you also send echo request to remote PC
I.e. when both parties try ping each other.

Have you upgraded to 3.0.14 from the beta board? That seems to have fixed a previous Tracert problem, maybe ping too? What is your OS? I never had a ping or Tracert problem even with no global rules and no ping rules with Vista Ultimate. Also are you using a router? Many routers respond to pings by default independent of the attached computers unless you go through the effort of turning it off. You can add global rules to allow ICMP in and out and log and see if they are actually getting to your computer. My Russian is lower. :slight_smile:

I’ve try 3.0.14. Bug present. :frowning:
OS - WinXp pro SP2. I’m not using router.
My global rules
http://img217.imageshack.us/img217/9612/11ns7.jpg

Do You understand an essence of a problem? My english is bad, but I shall try to explain still time.
With these rules nobody can ping me. They receive time-out. We shall assume at present someone ping me. He receives time-out. But as soon as I shall try ping him, he at once instead of time-out will begin ping me, i.e. to receive echo-reply from me. On http: // forum.ru-board.com this experiment spent some persons the friend between the friend. They ALL have the same Results. Without exception.

Add “log” to your global rules and be sure the echo reply is coming from the computer, not the router. Add an application ruleset for ping with the same rules, with the log. Let us know the results and what your log says.

Done.
Try to ping myself from remote PC.
In log recive this

http://img80.imageshack.us/img80/8151/22cy3.jpg

All works fine. Incoming ICMP echo-request are blocked.
Now i try to ping the remote PC, and it this time it ping me.
The same picture. It start ping me (recive echo-reply).
In log only alowded my echo request to it. Any word about alowded echo-reply from me to it

P.S. When I use Outpost nobody can ping me in any case.
Its a real bug, not problem with routers or my PC i think.

I can confirm that too. I’ve seen this bug in 3.0.13, and it’s still there in 3.0.14.

At my workplace I have two PC’s, one is XP with Comodo installed (A), the other is a linux server ( B ). The other guy has an XP box too (C). They are all connected via the usual ethernet switch, and are all in the same IP subnet. B and C have no firewall.

With the same ruleset as valmont_al has provided, I tried to ping A from B. No replies. Then I pinged B from A, and it worked, as expected. Surprisingly, the moment I did that, B also started receiving echo replies from A. When I stopped pinging B from A, echo replies from A to B also stopped coming.

I also tried to ping A from C, while A was pinging B (to see whether it “opens up” to everybody). Didn’t work.

Same applied when I pinged C from A. C was able to ping A back at that time, B wasn’t able to ping A.

So the logic is: whoever I ping, can ping me too, while I’m doing it. Despite the Global Rules.

All my idea consisted in this suggestion. Thank you :slight_smile:

Did you try adding an application level ruleset for ping? I have some other concerns about the global rules and default (hidden) rulesets and don’t use them.
Is this isolated to the global rules or a more general problem.

Ping.exe - its a standalone programm for comodo. I can allow Any icmp in global rules but i’ll never recive echo-reply’s or send request till i allow ping.exe in Application rules.

Is this isolated to the global rules or a more general problem.
I not quite understood this phrase

Could you add the simple ping block rule to your global set as the first rule?
Block&log/ICMP/any/any/echo request? And then again in the application rules under “Windows Operating System”. Trying to understand whether the rules are ineffective only in the global rules or no matter where the rules exist.

Could you add the simple ping block rule to your global set as the first rule? Block&log/ICMP/any/any/echo request?
This rule block all request. No request to remote or from remote side. Too same takes place when its rule in App. rules

So when you try to block echo requests in both the global rules and the windows operating system rules, if you ping someone you will also respond to their pings. Is that correct?

This could be a SPI “passthrough” side effect but I expected it to work only for tcp/udp connections. Good catch guys

Seem to be some SPI inconsistencies in Comodo 3. I agree that here it looks like SPI is overriding the rules without checking that the ICMPs involved make sense. I also expected passive FTP to be facilitated by SPI, but it didn’t happen. Is there anything documented on the CFP3 SPI design? If you read the Help file and descriptions it looks like it is not there-except here it seems to pop up. ???

Maybe we could try to send some messengers in the dungeon. But so far no one returned alive :o

Well we have safe applications, which generate their own rulesets (which mostly seem to be “allow all out” for 3.0.14) but can override them with explicit application rules (I think in all cases). But SPI is a different animal, with its own functional “states” and associated rules that override the other rules-at least I don’t see any way to change the SPI rules in Comodo, or add new “states”. Maybe a list of recognized “states” and associated rules can be found. ???

Bug was fixed in version 3.0.15
Comodo block incoming echo-request in all cases.