Skip to main content
Aigarz
Aigarz
New Member
April 19, 2016
Question

Traceroute via FGT unit doesn't show as a hop

  • April 19, 2016
  • 1 reply
  • 25894 views

Hello,

 

I've come across fgt100d HA 

 installation where internal Ip doesn't show in traceroute

What I get.

>tracert -d 8.8.8.8   1     1 ms     2 ms     1 ms  2.2.2.2   2     4 ms     3 ms     3 ms  1.1.1.1

... ^C

 

What I would like to get

>tracert -d 8.8.8.8   1     1 ms     1 ms     1 ms  192.168.100.1   2     1 ms     2 ms     1 ms  2.2.2.2   3     4 ms     3 ms     3 ms  1.1.1.1 ^C

 

Setup is quite basic.

there are several Lan interfaces combined under one zone. Policy is

LANzone > wan all traffic is permitted

192.168.100.1 responds to icmp

 

 

I'm suspecting fortigate doesn't decrease TTL or it's somehow connected that traffic is processed using NP...  Any ideas what could be switched on/off ;) ?

1 reply

emnoc
emnoc
New Member
April 19, 2016

1st

 

is the traceroute udp or icmp based

 

2nd

 

The diag debug flow  is your best friend

 

3rd

 

what's your allowaccess statement on the in-comming interface for the traceroute?

 

here's a tracerouet unix with udp and then icmp, 10.52.1.1 is my edge-fgt btw, you will see that reported in the ICMP based traceroute

 

 

Aigarz
AigarzAuthor
New Member
April 19, 2016

Thanks for looking into this. 1st trace issued from windows, should be ICMP 3rd while testing: set allowaccess ping https snmp http fgfm As from your trace with UDP it's obviously blocked, therefore showing  * * * In my scenario - hop simply doesn't show up. If I would "translate" it to you screenshot - it would be ... 4. 10.255.255.6 5. 10.255.255.5 ----------10.52.1.1----- missing 6. <public network> nb: I went over similar installations also 100d  - first hop is showing properly - direct gateway shows as a first hop(Fortigate internal IP). Only differences I can spot  in this case - there are several "Vlan Interfaces" bundled into one "Zone" and then security policies are made from "Zone" to WAN1 Actually this is the first time I've came across this behaviour on Fortigate. I recall over years there were boxes (non Fortigate) where you could artificially manipulate TTL settings to  make L3 Firewalls "dissapear" from traceroutes. But in this case customer didn't touch any special knobs or settings. (hopefully :))

emnoc
emnoc
New Member
April 19, 2016

What did diag debug flow show? I was also going to suggest  a NPU issue but a 100D pretty much does not have any NPU.

 

FWIW a FGT140D ( similar ) that's running   5.2.4 in my lab works great with udp so I do believe you are on to something with the 1st hop being dropped by the FGT.

 

e.g

 

LAB# traceroute 8.8.8.8 port 666  <I tried my own port # for the heck of it traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets  1  10.64.1.1 (10.64.1.1)  0.645 ms  0.943 ms  2.359 ms  2  10.64.18.30 (10.64.18.30)  2.388 ms  0.983 ms  2.294 ms  <-FGT  3  1.1.1.1 (1.1.1.1)  2.462 ms  3.677 ms  2.552 ms   <- ISP  4  * * *  5  * * *  6  24.175.43.223 (24.175.43.223)  26.671 ms  17.369 ms  17.125 ms  7  24.175.41.46 (24.175.41.46)  20.408 ms  26.485 ms 24.175.41.50 (24.175.41.50)  25.853 ms  8  66.109.6.88 (66.109.6.88)  20.213 ms  22.052 ms  23.949 ms  9  107.14.17.236 (107.14.17.236)  18.466 ms  19.814 ms 107.14.17.232 (107.14.17.232)  23.181 ms 10  66.110.57.97 (66.110.57.97)  41.224 ms  36.653 ms  31.729 ms 11  * *c * 12  *

The TTL is set by the client so I don't see how a FGT or any device will adjust the TTL  btw.

 

 

 

 

 

 

 

 

Terms & ConditionsAccessibility statement