Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
horinius
New Contributor

Bug or documentation ambiguity concerning Trusted Hosts

Few days ago during a diagnostic, I was annoyed to find that I got no ping reply from my FortiGate 80c DMZ interface (ping sent from a server situated in the DMZ). But " PING" option in DMZ interface properties page has already been checked. After some fiddlings, I figured out that I also had to put source IP address in " Trusted Host" field of *any* administrator. Now, there' s a problem (or two problems): * The description of PING in the PDF documentation (fortigate-admin-40-mr2.pdf) says that Interface responds to pings. Use this settings to verify your installation and for testing. * The description of " Trusted Hosts" says that The IP address and netmask of trusted hosts from which the administrator can log in. But ping has nothing to do with " log in" , so in first reading, it was hard to imagine there' s a relationship between " trusted hosts" and " ping" . It' s either a bug or a documentation ambiguity.
3 Solutions
Jay_Libove
Contributor

</VENT ON> FortiOS 5.0.4, just ran into this same %#$%#%#$% bug, mis-feature, crappy documentation, whatever you want to call it. There should be NO relationship between Administrators, Trusted Hosts, and the configuration for whether an interface will respond to PINGs! I don' t give a rat' s *** WHY FortiNet ended up doing it this way. It' s wrong. It' s not " documented" , it' s a non-obvious (I found posts REFERRING to the KB entry, but my searches had turned up the KB entry itself), kluge. It makes no sense **IN TERMS OF HOW A REASONABLE ADMINISTRATOR EXPECTS A PRODUCT TO REASONABLY WORK**. FortiNet, what were you smoking when you came up with this? I have far too many other important headaches to suffer these kinds of insults... </VENT OFF>

View solution in original post

Jay_Libove
Contributor

Further, being forced to enable broad access so that PINGs would be possible also results, even though harmlessly in terms of real security threat, in the whole world being able to bounce off of the SSH front door, thus: The following critical firewall event was detected: Critical Event. date=2013-10-18 time=16:51:09 devname=FG100D3G13807731 devid=FG100D3G13807731 logid=0100032002 type=event subtype=system level=alert user=" root" ui=ssh(91.232.208.38) action=login status=failed reason=" name_invalid" msg=" Administrator root login failed from ssh(91.232.208.38) because of invalid user name" In fact, because the only administrator which could log in is the totally unprivileged one, this couldn' t produce harm ... but it will produce a lot of junk log messages. It really doesn' t matter that this incredibly poor design has been that way for a few years - it still deserves to be fixed.

View solution in original post

nothingel
New Contributor III

I agree -- it' s crazy to add a junk user with no IP restrictions just for PINGs. That said, I do know other admins who prefer to completely ignore PING and thus the existing behavior is probably desired. If anything, perhaps Fortinet could devise a way so that there' s an easy way to exempt PINGs from the IP restrictions without needing a totally separate username.

View solution in original post

26 REPLIES 26
rwpatterson
Valued Contributor III

Wow, is that OLD or what? Version 2.80?

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
horinius

ORIGINAL: TopJimmy I don' t see it as a bug …
LOL So what?? You don' t see it as a bug doesn' t mean you are correct. It only means your logic has flaw. It' s written " The IP address and netmask of trusted hosts from which the administrator can log in" for Trusted Hosts field. Ping is not associated with log in. So either the sentence or the implementation is incorrect. QED! Mind you that I have found the " workaround" to make it work before I made the post, but that doesn' t mean I agree with it.
ORIGINAL: TopJimmy … and documentation exits on it. Just search the KB..I did. http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=10876&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=43714791&stateId=0%200%2043716303
That, you called it " documentation" ? Come on! I would call it " disordered, odds and ends, slacky patchworks to remedy the shortcoming in the official documentation" . What I mean by " documentation" are those published as PDF. Moreover, the very existence of this article proves further that the corresponding part in the official documentation is not clear. The other day when I came across this " problem" , I had called a Fortinet-agreed company for technical assistance and they were unable to figure this out! LMAO
ede_pfau
SuperUser
SuperUser

The ' trusted hosts' setting governs the administrative access, further subdivided with the settings on each interface. Administrative access is not limited to login but includes ping as well. That' s the way it' s meant. If you feel this is documented in a misleading way then please report to techdoc@fortinet.com and ask for a clarified description to be included in future doc versions. To make things easier, suggest a paragraph of your wording instead of the current one. They are always very responsive and helpful and usually suggestions like these will make it to the docs in a couple of weeks (it' s not a big trashbin...). I' ve done that a couple of times now, with very good results.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
horinius

ORIGINAL: ede_pfau (snipped) ... That' s the way it' s meant. If you feel this is documented in a misleading way then please report to techdoc@fortinet.com and ask for a clarified description to be included in future doc versions. To make things easier, suggest a paragraph of your wording instead of the current one. (snipped)...
OK, thank you. I will do.
FredInd
New Contributor

To share you my own experience, the fact that there' s a link between ' Thrusted hosts' and allowing ping is a bit confusing. We' ve 3 admin accounts on our Fortigate cluster, and one had no ' thrusted hosts' referenced. In order to correct this security lack, i' ve add ' thrusted hosts' on this account and restrict those ' thrusted hosts' to network range in which administrative access for remote managment was needed. A few days after, I' ve discovered that I was unable to ping some gateways and I had no idea why ... I spend 2 days looking for a reason, and finally add those network range as ' thrusted hosts' in one of those 3 accounts .... grrrrr .... Fred
Jay_Libove
Contributor

</VENT ON> FortiOS 5.0.4, just ran into this same %#$%#%#$% bug, mis-feature, crappy documentation, whatever you want to call it. There should be NO relationship between Administrators, Trusted Hosts, and the configuration for whether an interface will respond to PINGs! I don' t give a rat' s *** WHY FortiNet ended up doing it this way. It' s wrong. It' s not " documented" , it' s a non-obvious (I found posts REFERRING to the KB entry, but my searches had turned up the KB entry itself), kluge. It makes no sense **IN TERMS OF HOW A REASONABLE ADMINISTRATOR EXPECTS A PRODUCT TO REASONABLY WORK**. FortiNet, what were you smoking when you came up with this? I have far too many other important headaches to suffer these kinds of insults... </VENT OFF>
emnoc
Esteemed Contributor III

Will it' s been that way for afew years and a few releases now. To add to ede_pfau clarifications; it effects just more than admin access, but pings and even snmp. So be aware.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Jay_Libove
Contributor

Further, being forced to enable broad access so that PINGs would be possible also results, even though harmlessly in terms of real security threat, in the whole world being able to bounce off of the SSH front door, thus: The following critical firewall event was detected: Critical Event. date=2013-10-18 time=16:51:09 devname=FG100D3G13807731 devid=FG100D3G13807731 logid=0100032002 type=event subtype=system level=alert user=" root" ui=ssh(91.232.208.38) action=login status=failed reason=" name_invalid" msg=" Administrator root login failed from ssh(91.232.208.38) because of invalid user name" In fact, because the only administrator which could log in is the totally unprivileged one, this couldn' t produce harm ... but it will produce a lot of junk log messages. It really doesn' t matter that this incredibly poor design has been that way for a few years - it still deserves to be fixed.
nothingel
New Contributor III

I agree -- it' s crazy to add a junk user with no IP restrictions just for PINGs. That said, I do know other admins who prefer to completely ignore PING and thus the existing behavior is probably desired. If anything, perhaps Fortinet could devise a way so that there' s an easy way to exempt PINGs from the IP restrictions without needing a totally separate username.
emnoc
Esteemed Contributor III

In reality their' s a lot of drama over nothing. You should be controlling pings from the external untrusted or internal(s) via the set allowaccess command imho and further via the trusthost if you have it enabled. I don' t personally think it' s a bad design, except that person are using it in the wrong fashion & expecting a different outcome. So what if you need to create a few junk accounts as so-called. This is a security appliance & should be thought of just that " security" appliance :)

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors