v3 not allowing a tracert

[Guest]

[john q private]

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.

[sded]

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

[john q private]

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.

[jasper2408]

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.

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

[john q private]

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!

[jasper2408]

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!

Enjoy

jasper

[VanguardLH]

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).

[Luxor]

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. 

[jasper2408]

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. 

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.

[sded]

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.

[VanguardLH]

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.

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 (http://en.wikipedia.org/wiki/Stateful_packet_inspection), 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.

[sded]

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.

[jasper2408]

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 a**e 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 (http://en.wikipedia.org/wiki/Stateful_packet_inspection), 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.

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

[VanguardLH]

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.

[sded]

[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, 

[Tags:]