My dsl provider was nice enough to come over just to check my connection and so he ran a trace route and so far he tested 5 sites and all of the results yield “Request Timed Out”. As usual they blame my router then he ran the test w/o the router and still the same thing. So it all went down the CFP 3 so I’m asking if CFP can cause this stuff? Since I’m a new CFP user, I haven’t learned everything yet so I have to show the tech guy proof that CFP doesn’t caused the problem.
If CFP is not the problem can anyone with experience give me some idea on why is this happening?
Actually… this could easily be CFP. Either on installation or the Stealth Ports Wizard, CFP often creates a Global Rule (Firewall - Advanced - Network Security Policy - Global Rules tab) that blocks inbound ICMP Echo Requests on anything but the LAN (if there is one) and… Trace Route uses ICMP Echo Requests. Why does it do this? Security. Allowing inbound Echo Requests will reveal your system’s existence to the Internet. Assuming you have this rule, edit it & change Block to Allow for the Trace Route test (remember to put it back afterwards).
I never added any rule and I never knew that this exist so like how do I know which one to turn off to run trace route? I was wondering does it also affect my ping on sites or my ping in general?
You probably never did create the rule (directly/intentionally), CFP probably did on your behalf (to protect you). See above.
Turn off? Open CFP, go to Firewall - Advanced button - Network Security Policy - Global Rules tab (just behind the visible Application Rules tab). Find the rule with “ECHO REQUEST” (probably the last rule). Right click it & select “Edit”. Change the “Action” from “Block” to “Allow” (drop down menu). Hit “Apply” & “Apply” (again). Job done… to put it back afterwards (which you should) - same process, but changing “Allow” to “Block”.
Ping? Yep, the very same Echo Request is also used for Ping.
For Ping you need to allow ICMP Echo Request out and ICMP Echo Response in. For Tracert, you also need to allow ICMP Time Exceeded in. Check your Global rules and Windows Operating System rules to make sure these are allowed.
sded’s right. But, by default the Application Rule for “System” probably has an IP Out from Any to Any & since you’ve not meddled with the Global Rules before it’s probably best if you just try it with the ICMP Echo Request block disabled (set to Allow). I suspect CFP will prompt you if it needs something else.
Possibly, but we cannot tell since not all the details of the rules are visible from the screen shot. sded would need to post the details… which now I’ve typed that, he probably will. ;D
But, as far as Ping & Tracert (Trace Route) are concerned… unless you specifically need the functionality, then it is probably not worth making your system visible on the Internet for them. These days, almost everybody blocks ICMP Echo Requests/Responses anyway, and not just us users either… a lot web sites & server admins do as well. They are mostly used on internal networks (corporate LANs), by Gamers & some P2P applications. But, I suspect the value of Ping & Tracert are constantly diminishing over the Internet, simply because they make your system visible… or to put it another way… a target.
Safe they are. The one you can’t read blocks “port unreachable”. The rules allow ping and tracert, and block everything else. The ones without log block unnecessary traffic that I actually see. The block and log at the end is in case a particular system is doing something and asks for more access. Since I don’t use global rules, my system type rules look a little different.
Do they work OK for you? Allowing outbound is generally pretty safe, especially with a final block and log. CFP3 is actually rather flexible about your rules. I just cut mine down because I am not using some capabilities that your rules would support. But note that tracert and ping don’t use udp or tcp, for example; they use the ICMPs in my WOS ruleset. So you might try setting the firewall to safe mode and letting CFP3 make some rules for you, with firewall behavior/alert settings set to high, then editing in the block and logs when done.
The big delay (+200ms) is between hops/nodes 4 (58.71.0.143) & 5 (LA something… maybe… can’t see the IP). But, on checking the IPs… if node 4 is in the Philippines & node 5 is LA (US), then perhaps, 200ms isn’t that unreasonable (something I’m not sure about).
