FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Article Id 190239


In some cases, it is possible to reach the FortiGate unit through a Ping, Telnet or SSH, but not through the web admin GUI.  

This article discusses some possible causes for a non-working GUI access.



1) Interface settings.
GUI access, HTTP and/or HTTPS, has to be enabled on the interface.
CLI commands:
# config system interface     
edit <interface name>
            set allowaccess ping http https end
Possible allow access settings: PING, HTTP, HTTPS, TELNET, SSH, FGFM (FGFM is required for FortiManager access).
2) Trusted host configuration.
If 'trusted hosts' are configured, IP address of the computer used for the GUI access must be allowed as 'trusted host'. 
A whole subnet can be allowed as 'trusted host'".
By default, trusted host settings are not configured, and administrative access is not restricted to any specific user IP addresses.
Sample trusted host configuration:
# show
# config system admin         
edit "admin-test"
set trusthost1             
set trusthost2             
set vdom "root"
# config dashboard-tabs             
Changing the trusted host configuration:
# config system admin     
    edit <admin user>
        set trusthost <1 to 10> <ip address>/<mask>         
        set ip6-trusthost <1 to 10> <ip6 address>/<mask>
Trusted host settings are per admin user, and are valid for all types of access.
If a user is trusted for access through SSH, it is also trusted for HTTP or HTTPS access.
3) MTU along the path.
After the first few synchronization and handshake packets, the web admin GUI HTTP and HTTPS packets can become larger than 1500 bytes.
When a FortiGate network interface is connected to a network segment that supports such extended size packets. 
For Telnet or SSH, packets typically remain of smaller size.
To be then able to use the web admin GUI, the fragmentation must be allowed at certain points in the network infrastructure (points, where a jumbo-frame reaches a network segment that does not support it), or Jumbo frames must be allowed along the whole communication path.
Note about Jumbo frames: Jumbo frames are packets that are larger than the standard 1500 maximum transmission unit (MTU) size. Jumbo frames increase data transfer speeds by carrying more data per frame, reducing the overhead from headers.
All networks that carry jumbo frames must have network units that all support jumbo frames. 
Otherwise, jumbo frames will be dropped, when they reach network devices that do not support them.
4) Admin access ports.
By default, for admin login via GUI, the HTTPS port is configured to 443 and the HTTP port to 80.
If those default settings are changed, access to the GUI will not be possible without specifying the custom-port used at the end of the URL.
To verify which HTTPS/HTTP ports are configured for admin access:
# show full | grep admin-port           
set admin-port 80 
TestFGT # show full | grep admin-sport
        set admin-sport 443
In the event that the default ports have been changed, either directly access the GUI using the specific port that is currently defined: http(s)://<address_of_appliance>:<custom port>.
For example: where 222 is the non-default port used to access GUI via HTTP.
If the ports needs to be changed to a new value or the default value, use the following syntax for HTTP access:
# config system global     
set admin-port <integer> end
Whereas for HTTPS access, use the syntax:
# config system global     
set admin-sport <integer> end
5) admin-server-cert (for versions 5.6 and above only).
Enable the following debug and try to access the GUI again:
# diagnose debug application httpsd -1
# diagnose debug enable
If the output is matching the following:
[httpsd 1746 - 1552998712    error] log_error_core[439] --
[Tue 19 12:31:52 2019] [crit] Can't open certificate file /tmp/admin_server.crt, nor /ssl/certs//tmp/admin_server.crt
[httpsd 1749 - 1552998714    error] log_error_core[439] --
[Tue 19 12:31:54 2019] [crit] Can't open certificate file /tmp/admin_server.crt, nor /ssl/certs//tmp/admin_server.crt
[httpsd 1752 - 1552998716    error] log_error_core[439] --
[Tue 19 12:31:56 2019] [crit] Can't open certificate file
/tmp/admin_server.crt, nor /ssl/certs//tmp/admin_server.crt Proceed with the following:
# config sys global
set admin-server-cert Fortinet_Factory end
6) Existing virtual IP is overriding admin HTTP or HTTPS ports.
When a Virtual IP (VIP) has the same IP address of FortiGate interface and forwarding the same ports used for HTTP/HTTPS access (example 80 or 443), the VIP will override the administrative access.
This should either be removed or changed such that it doesn’t overlap with FortiGate HTTP/HTTPS ports.
This can be verified by checking the VIP list on FortiGate (Policy & Objects -> Virtual IPs) or running the debug flow.
7) Check if any local in policy is configured to deny the access on the related interface.
#conf firewall local-in-policy
# sh full
    edit 1
        set uuid 794fef20-38ce-51ec-b995-89227f742faa
        set intf "wan1"
        set srcaddr "all"
        set srcaddr-negate disable
        set dstaddr-negate disable
        set action deny
        set service "HTTPS"
        set service-negate disable
        set schedule ''
        set status enable
        set comments ''
8) Restart HTTPS Daemon.
In case none of the processes above fixed the issue, try to restart the HTTPS Daemon.
# dia sys process pidof httpsd
- Note the first listed process ID (this is the parent process).
# dia sys kill 11 XX                                                    <----- Add the process ID gathered in step 1.
- This restarts httpsd.

Related Articles

Steps to enable remote management

Configuring Administrator access to a FortiGate unit using Trusted Hosts

Troubleshooting Tip : debug flow messages "iprope_in_check() check failed, drop" - "Denied by forwar...