Cannot run Traceroute

[edzsoqeta]

Hi,

I'm trying to run a traceroute from the CLI and also windows pc but unfortunately it does not give me the full hops for troubleshooting.

From the policy settings, I've enabled the below configs:

From the interface:

Traceroute from CLI

Is there something blocking this or have i missed something?

[poundy · Accepted solution]

What's actually the problem with this?  

Personally, it seems to me that your ISP has a peering with your local DNS.google hosting that precludes ICMP (or it's switched - but at 36msec that's a long path to switch). The ICMP response path is consistent from the PC and the FGT. I would have also expected that if you'd misconfigured the FGT, the ICMP would not work past your boundary at all, they'd all just time out, but you clearly hit the ISP's router. 

The only way you could convince me that there's an issue with FGT setup is if you had tried the same test on the same line with just a regular consumer-grade firewall device (or an enterprise grade) and you get different hop pattern.

You could also try a different application and watch if it detects different hop pattern over time. I use PingPlotter when I need to get this level of info on a link.    

[poundy]

BTW your images haven't come through properly so nobody can really see to help 

[edzsoqeta]

iv attached the configs 

[poundy]

one image won't help :) 

What are you trying to diagnose though?  Anything to do with the firewall or things outside the firewall ? What IP address(es) are you testing from / to?  There's a myriad of reasons why other people's devices won't respond to ICMP so if you're relying on that for some reason, then you're bound to run into trouble...

[edzsoqeta]

When I'm trying to do a trace to 8.8.8.8/other external ip addresses, it doesn't show me the full hopes for example:

from a pc:

C:\Users\SCE ADMIN>tracert 8.8.8.8

Tracing route to dns.google [8.8.8.8] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.99 2 1 ms 1 ms 1 ms 210.7.14.117 3 37 ms 37 ms 37 ms dns.google [8.8.8.8]

Trace complete.

From Firewall:

Connected FGT80ETK18016278 # execute traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 32 hops max, 3 probe packets per hop, 72 byte packets 1 210.7.14.117 1.307 ms 0.895 ms 0.718 ms 2 8.8.8.8 <dns.google> 36.938 ms 36.952 ms 36.952 ms

Please note that the policy has been enabled for UDP and ICMP however when doing troubleshooting I still cant do a full traceroute 

firewall model: FortiGate 80E  FGT80ETK18016278

[poundy · Accepted solution]

What's actually the problem with this?  

Personally, it seems to me that your ISP has a peering with your local DNS.google hosting that precludes ICMP (or it's switched - but at 36msec that's a long path to switch). The ICMP response path is consistent from the PC and the FGT. I would have also expected that if you'd misconfigured the FGT, the ICMP would not work past your boundary at all, they'd all just time out, but you clearly hit the ISP's router. 

The only way you could convince me that there's an issue with FGT setup is if you had tried the same test on the same line with just a regular consumer-grade firewall device (or an enterprise grade) and you get different hop pattern.

You could also try a different application and watch if it detects different hop pattern over time. I use PingPlotter when I need to get this level of info on a link.    

[Dave_Hall · Accepted solution]

I would suggest pinging/trace route to non-DNS IPs to see what path you get. 

That said, I have seen some (mostly satellite/dial up) ISPs deploying proxy/web accelerator software built into their gateway/router and/or deployed on their backend/haul.  If this is the case or you are not sure, I would log into the gateway device (if you can) can see what settings are listed.  Alternately, you can always contact your ISP support and they should be able to tell you.