v3 not allowing a tracert

Help for v3
1

I just upgraded to v3.0.13.268 today. Auto-configure/learning is going smoothly.

However, I cannot seem to run a tracert through the command prompt / cmd.exe as where I had no problem with this in the previous release.

When running a tracert, the only response I get are the CMTS router (10.x.x.x) which I’ve whitelisted and the terminating IP address of the tracert, usually Google or Yahoo, and nothing in between.

I’ve attempted to define c:/windows/system32/cmd.exe and [same]/tracert.exe as trusted applications by calling them out as specific paths to the programs and as ‘running programs’ while letting the tracert run. I attempted to do this through “Define a New Trusted Application”.

Also, I attempted this through “Network Security Policy” on both the Application Rules and Global Rules tabs. I tried defining the Global Rules as, first allowing all outgoing ICMP traffic, and second allowing all ICMP traffic, neither of which worked.

I tried defining this through “Predefined Firewall Policies” again to no avail.

I tried defining this through “Computer Security Policy” in the Defense+ menu. No luck.

At this point, I don’t know what to do.

2

What are your rules under “System” and “global”? Tracert and Ping both work for me. 3.0.0.13, 32x Vista Ultimate.

3

I thought I did this before but maybe not. In Global Rules, I changed the direction setting for ICMP from Out to In/Out. That did the trick.

I apologize for the waste of bandwidth but it seems I literally just fixed the problem. I seriously thought I already tried this…

Thanks for the help.

4

There is a learning curve to this firewall. Your post isn’t a waste of bandwidth as you posted a solution that someone else might need to get their tracert working.

thanks,

jasper

5

Well, I certainly appreciate the kind words.

I will say for the record that so far I really like Comodo v3 more than the previous release (v2.4?) and certainly much better than ZA - free or pro.

Keep up the good work!

6

Enjoy

jasper

7

What is/are the global rules that you define for IMCP? When I create a global rule (to block inbound pings), tracert won’t work. I tried:

Block IMCP In from IP Any to IP Any for Echo Request

which I thought would block unsolicited inbound ping requests. I also thought that it would not interfere with an outbound ICMP ping that I sent to another host (and also not interfere with the Echo Reply that comes back). However, when I define this rule, tracert does not work. When I delete this rule, tracert works.

UPDATE

Well, I guess it wasn’t the rule that caused the problem. I deleted the Block ICMP rule noted above and tracert still failed. Only when I right-click on the tray icon to disable the firewall does tracert work. I checke the firewall event log but it is absolutely worthless for determining WHAT caused the block; i.e., the rule that generated the block is not specified. How are users expected to monitor and manage their rules if they can’t see which one was used in which event? Geez.

I did find an app rule for tracert.exe that was:

Allow IP Out From IP Any to IP Any where Protocol is Any

I deleted that rule figuring that running tracert.exe again would issue the alert popup to have me okay the connect request. Nope, although the same above rule got recreated - any without any prompt to me - tracert did not work. Since I didn’t get promped, I’m assuming that tracert.exe is in Comodo’s pre-defined safe list. I tried changing the rule from “Allow IP In …” to “Allow IP In/Out …” but that did not help. I even deleted this app rule and created one that used the Trusted Application predefined policy that allows all incoming and outgoing requests and still tracert.exe would not work.

If I disable the firewall, tracert works. If I enable the firewall, tracert gets blocked despite the app rule to let it connect out for any IP protocol but the event log is worthless for determine which app or global rule caused the block (there are no IDs assigned to the rules so the event log can’t show you which one was used in the block event).

8
If I disable the firewall, tracert works. If I enable the firewall, tracert gets blocked despite the app rule to let it connect out for any IP protocol but the event log is worthless for determine which app or global rule caused the block (there are no IDs assigned to the rules so the event log can't show you which one was used in the block event).

Having the same problem here. Ping works fine but tracert is a no-no.

I don’t have my thinking head on today and the more I read the more confused I’m getting. ;D

9

You need to make a rule in Global Rules to allow ICMP in/out. This should let it thru the firewall. You might also have to go to the Application Rules tab and add it there also for tracert.exe. Mine works fine with the two rules this way. Be sure to allow logging for the rules so you can see it working.

jasper

Edit: If you want to limit what ICMP types come in you can google "IMCP type and it will tell you what the type refers to such as type 11 is a Time Exceeded message. You can then go to the Details part of the rule and pick the type from there. I just enable the firewall rule when I want to use it and disable it when I don’t want to allow it in. You can also write rules for each type to make it more specific.

10

Do you get any “blocked” firewall log entries when you run tracert? Should show blocked incoming. Works fine for me, 3.0.0.13 Vista Ultimate 32. Take a look at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/tracert.mspx?mfr=true for how tracert works in windows. You need to allow inbound “time exceeded” and “echo reply” as well as outbound “echo request”. Or allow ICMP in both directions. You can create an explicit rule for tracert in the Network Security Policy if you don’t block it in the global rules or in a rule earlier in the Policy list.

11

According to the help (which you need to open the .chm file separately to avoid CPF3 from crashing), the app rules take precedence over global rules. That is, app rules are ran first. Since there is an app rule that get auto-generated (probably because it is in Comodo’s certified safe list) when tracert.exe is executed then that rule should fire and be used without ever rolling into the global rules.

I defined the following global rule and tracert then worked:

Allow ICMP In/Out to IP Any from IP Any

(that is my writeup of the rule since another of my posts mentions that the Description field is not getting properly populated when making changes in a rule).

Okay, so the help is wrong. Global rules take precedence [in this case] over app rules. This is arse backwards. App rules are specific rules on specific executables/processes and should always take precedence over global rules. Global rules are, after all, global and provide coverage when no app-specific rule applies. Well, that’s how it should be for outbound connects. The help file says:

  • For Outgoing connection attempts, the application rules are consulted first then the global rules.

  • For Incoming connection attempts, the global rules are consulted first then application specific rules.

The firewall should see tracert.exe is making an outbound connection so the app-specific rule should apply, which is:

Allow IP Out From IP Any To IP Any Where Protocol is Any

Due to stateful packet inspection, the return (inbound) packet should be allowed back to tracert.exe. Changing Out to In/Out for the app rule doesn’t help. With stateful packet inspection (Stateful firewall - Wikipedia), an app rule set for both directions (In/Out) shouldn’t have to rely on a global rule (to complete the connection for the inbound traffic). Something is wrong with rules in CFP3.

By the way, the rule you mention to allow in/out for ICMP means anyone can ping my host and get a response. Other firewalls, even the prior version of this one, let me block inbound ICMP echo requests but they didn’t stop tracert from working. When I changed your global rule to:

Allow ICMP In from IP Any to IP Any Where ICMP Message is ECHO REPLY

the tracert failed again. The outbound echo request from tracert should’ve been handled by the app rule. The inbound echo reply to tracert should’ve been handled by this global rule (but then the return packet should’ve been handled by the app rule using stateful packet inspection because Out was changed to In/Out for the app rule).

The auto-generated app rule created by CPF because tracert.exe is a certified app seems wrong. It shouldn’t be just Out but In/Out for direction since it needs to send the echo request and wait for the echo reply. Yet the change doesn’t get this app rule to work. I’ve never had to separately define global rules to cover what the app rule should cover. Rules aren’t working properly in CFP3.

Did you have to define any other rule after okaying tracert.exe to get a connection back in CFP 2.4? Nope. Looks like I’ll be reverting back to the prior version of CFP.

12

Comodo seem to be like most other firewalls in terms of rules. Rules are a hiearchy: global rules are executed first for inbound, last for outbound. Besides “echo reply”, you need to allow “time exceeded” in for tracert to work-see reference above.

13

On tracert I allow all ICMP out in Application rules under tracert.exe and in the Global rules.
I also only allow ICMP Type11(Time Exceeded) in in Application rules under tracert.exe and in the Global rules.

Tracert needs to allow Type 11(Time Exceeded-IN) and Type 8(Echo Reply-OUT) to work. Since I allow all ICMP out in both sections then I am covered on Type 8 so all I need it to allow is (Type 11-Time Exceeded-IN) for it to work and all other ICMP is blocked because I am not allowing it in with any of these rules.

As far as how the firewall does its business, it first checks the Application rules to see if the application has the necessary rule in place to allow it to communicate on the port with the needed protocol then it goes to the Global rules to see if a rule is there to allow the same. Either section can block a program if there are no rules in place to allow them.

Global rules has the final say so when any kind of traffic going out. When traffic is coming in Global rules is the first thing the outside world sees and if the traffic is approved there then whatever application the traffic is going to is checked in Application rules to see if the app has a rule to allow traffic. If you notice in the log on the left side it will tell you what application the entry pertains to.

This is a general explanation but it pretty well covers the operation of CFP3

jasper

jasper

14

I think we all need to halt the analysis on how to get the appropriate rules defined and remember that CFP3 is going to be used by those that haven’t even heard of ICMP or know how to dig into its spec to determine what are the various connect/action types defined for it.

The whole point of enabling the certified list of predefined known good applications is to have CFP3 create the rule instead of relying on the user to manually figure it all out. If an app requires both an application and global rule to get it working properly then CFP3 should’ve defined both for that certified app. This firewall shouldn’t only be targeting ubergeeks for its users.

15

[Vista Ultimate 32/Avast!] I don’t have any rules for ICMP or explicitly for Tracert or Ping and both of them work fine. The discussion above looks like people having some problems with the first release of Comodo (under XP?) and revising the firewall ICMP rules and needing help to fix it. For example, if you have heard that blocking ICMPs is a good thing for a firewall to do and add a rule to do it, probably you will block ping and tracert unless you do a little research or ask here. I don’t know why Ping and Tracert don’t work right out of the box for everyone-they did for me. And probably a bunch of others who didn’t address this thread. I didn’t use version 2, so don’t know how much the way V2 works added to peoples confusion on v3-I’m on Vista. Good luck and keep posting, I have some broken stuff too, :wink:

16

Funny. I woke up this morning and realized that if I allow all ICMP in and out then I will be visible at least when it comes to ping.

I came back to this thread and noticed my thoughts this morning weren’t too far off apparently.

All I can say is that with the previous release, I had no problems running a tracert. Now, saying that I cannot say if I was pingable because I never pinged myself until the issue being kicked around here came up.

I’ve tried the various options given out here. The results are this: if I make the rules to allow for tracert then I can ping my own IP; if I erase the rules then I cannot ping myself but tracert doesn’t work.

Maybe I’m paranoid, but I personally don’t like my PC being visible even if it is by tiny little insignificant ping. So I guess the only thing I can do in the meantime is delete all rules for ICMP and tracert and adjust ICMP rules when I need to run a tracert. I’ll also be experimenting with the rules and see if I can figure something out.

17

I am running under Windows XP. I did NOT have any rules (app or global) defined for ICMP. I had defined global rules for the Echo Request and Echo Reply (but forgot the Timeout) but decided there was not point. My NAT router’s firewall has an option to block inbound pings and I don’t care about any of my intranet hosts pinging each other. So I deleted those global ICMP rules.

When I run tracert.exe, CFP3 auto-generates an app rule for it because apparently it is a certified application. The rule it defines lets it connect out to any host. I even tried changing the connect direction from Out to In/Out but that did not help.

At this point, the only way I get tracert to work (and without defining gobs of extra global rules which should not be required, especially since app rules are used first for outbound connects so the tracert app rule should be used) is to disable CFP3. However, after finding out that the HIPS in CFPs is missing the most critical feature of a HIPS - that of regulating what can load into memory (regardless of what access rights it may be given thereafter) - it looks like CFP3 is something of a bastadarized HIPS-enabled product. Every HIPS product that I’ve used will let me block specified programs from loading but not CFP3; see my other post. I consider blocking of programs a critical feature of HIPS and without it means I really don’t care what else of HIPS is supported in CFP3.

Online Armor is looking more promising as the upgrade from CPF 2.4. And no problems with tracert, either, with Online Armor.

18

Well I still can’t get tracert to work and that is on an XP machine and a Vista machine.
I know Comodo 3 is different but I have used many a firewall over my long computing years and never had a situation when tracert wouldn’t work as it should.

This could be a bad thing in my view and please bear with me while I explain why.

Let’s say that my broadband connection is really poor, you know the one where pages won’t load, speed is as slow as being on a 26k modem. What’s the first thing a normal user will do ? Get on the phone to their ISP tech line. The conversation could go as follows:-

Hello Tech Support.

(User) My broadband is not working properly.

(tech) Can you do a tracert for me sir/madam.

(user) Yes how do I do that ?

(tech) Run the CMD and type in tracert www.google.co.uk

(user) OK

(tech) can you tell me the result.

(user) Yes it says

      Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\User Name>tracert www.google.co.uk

Tracing route to www.l.google.com [64.233.183.147]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms www.routerlogin.com [xxx.xxx.x.x]
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 163 ms 172 ms 184 ms nf-in-f147.google.com [64.233.183.147]

Trace complete.

(tech) Do you have a firewall ?

(user) Yes I use Comodo v3

(tech) Can you turn off your firewall please and run the tracert again ?

(user) Yes Ok… … Oh it works now !!! I get this.

C:\Documents and Settings\User Name>tracert www.google.co.uk

Tracing route to www.l.google.com [64.233.183.104]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms www.routerlogin.com [xxx.xxx.x.x]
2 * * * Request timed out.
3 184 ms 169 ms 167 ms popl-t3core-1a-ge-110-0.inet.ntl.com [62.255.81.
81]
4 146 ms 143 ms 151 ms pop-bb-a-so-210-0.inet.ntl.com [213.105.174.234]

5 174 ms 181 ms 185 ms nth-bb-b-so-010-0.inet.ntl.com [213.105.172.13]

6 177 ms 179 ms 179 ms tele-ic-1-as0-0.inet.ntl.com [62.253.184.2]
7 173 ms 195 ms 204 ms 212.250.14.66
8 223 ms 222 ms 210 ms 209.85.252.42
9 232 ms 251 ms 249 ms 209.85.248.80
10 241 ms 230 ms 258 ms 72.14.232.141
11 250 ms 202 ms 158 ms 72.14.233.83
12 206 ms 222 ms 242 ms 216.239.43.34
13 206 ms 193 ms 190 ms nf-in-f104.google.com [64.233.183.104]

Trace complete.

(tech) I think it could be your firewall, I would suggest using a different one.

(user) Yes you may be right, I will thank you for your help

(tech) No problem have a nice day.

See what would happen there ?
Lots of a potential user base who try Comodo 3 will uninstall and use something else.

Not something we want really is it. :o

19

Please add your suggestions in the Wishlist V6 thread. Comodo does like to see what features the users want and they do listen.

jasper

20
Please add your suggestions in the Wishlist V6 thread. Comodo does like to see what features the users want and they do listen.

jasper

Done though I wouldn’t call it a wish more a necessity. :wink: