The mechanism of tracert is document e.g. at:
or
http://www.visualware.com/resources/tutorials/tracert.html
Tracert uses the icmp type 11, code 0 icmp message (time exceeded: http://www.networksorcery.com/enp/protocol/icmp/msg11.htm) and needs for doing so to allow both echo request (outbound) and echo reply (note that echo request and reply might be blocked by your router as an anti-ping tool).
These echo icmp procedures are by default blocked by numerous firewalls (including windows firewall and cis), because echo is a potential entry for Denial of Service (altough DoS adresses to web servers, and not to your single computer…).
In order to allow tracert, you must as a consequence, and altough it is a potentially dangerous behavior, allow echo request and echo reply in your firewall global rules (or at least not forbid them: my traceroute requests works altough, since my last crash, i didn’t take the time to write such explicit rules except block echo request IN, but we are here speaking of OUT).
Globally speaking in peculiar situations like yours, global rules are lousy, of course because as their name tells they are global, but also because they don’t have the same precedence over firewall applications rules for inbound and outbound communications: you should better write individual applications rules for tracert, and the less global rules is the best if your application rules are correct.
But now, let’s make the test again.
I have a shortcut for cmd.exe in one of my folders, and i am running xp pro sp3.
Opening cmd.exe: cis request to allow explorer.exe for cmd.exe; answer is allow, don’t remember.
Typing the command line: “tracert comodo.com”; cmd.exe asks for tracert, answer is allow, don’t remember.
Now tracert ask for dns: answer is allow, remember (only for testing purposes, DON’T do that).
The result is a new defense+ rule for tracert.exe, only allowing dns control.
Next, tracert.exe asks to connect to 91.199.212.132, icmp: let us, again for testing purposes, allow and remember; we know have a new firewall rule with the usual stupid CIS behavior in this regard, as ALL icmp outbound requests are allowed to the said ip, whereas only the useful one(s) should be.
The only solution is trial and error: set various icmp details until it works.
Conclusion:
There’s no trick, excepting maybe the sandbox behavior, but i can’t speak of that as i use, as i said, cis v3.
My idea of such a situation is that everyone should set cis firewall to proactive, but custom, in order to make the firewall ask you for whatever you want to do, and not to rule in your back.
Defense+ is not relevant here since, even in paranoid mode with everything checked but image execution settings normal, it doesn’t block you but always asks.