Troubleshooting Tip: Cannot access the FortiGate web admin interface (GUI)

[slautenschlager]

Description

This article describes some possible causes for non-working GUI access. In some cases, it is possible to reach the FortiGate unit through a Ping, Telnet, or SSH, but not through the web admin GUI.

Scope

FortiGate.

Solution

To initiate access, start by pinging the management IP address to verify that the FortiGate is actively listening on the specified management IP. This step helps isolate whether the FortiGate is operational and responsive, assuming that ping is enabled on the management port.

To proceed, attempt to access via SSH using PuTTY as demonstrated below, ensuring that SSH is enabled on the management port:

If SSH access is unsuccessful, then use the following article to access the FortiGate via console cable and move on to next steps:
How to connect to the FortiGate and FortiAP console port

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

Allow access settings: PING, HTTP, HTTPS, TELNET, SSH, FGFM (FGFM is required for FortiManager access), Fabric (Fabric needs to be enabled for Security Fabric access), SNMP (SNMP access).

2. Trusted host configuration. If 'trusted hosts' are configured, the IP address of the computer used for the GUI access must be allowed as a trusted host. A whole subnet can be allowed as a 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 10.10.10.1 255.255.255.255             
            set trusthost2 192.168.0.0 255.255.0.0             
            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>

    end 

Trusted host settings are defined on an individual admin user basis, and are valid for all types of access.

For example:

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.

For example:
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 
show full | grep admin-sport

    set admin-sport 443

If the default ports have been changed, consider directly accessing the GUI using the specific port that is currently defined: http(s)://<address_of_appliance>:<custom port>.

For example: http://192.168.0.101:222 where 222 is the non-default port used to access GUI via HTTP.

If the ports need 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

For HTTPS access, use the following syntax instead:

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

Check if the output matches 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

If it matches, proceed with the following:

config sys global

    set admin-server-cert Fortinet_Factory

end

6. The existing virtual IP is overriding admin HTTP or HTTPS ports.
   
   When a Virtual IP (VIP) has the same IP address as the FortiGate interface and forwards 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 access to 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 ''

    next

end

8. Restart the HTTPS Daemon.
   
   If none of the processes above fixed the issue, try restarting 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.

 
Or:

Consider killing PIDs one by one. For example:

diag sys process pidof httpsd

1003

2956

3213

di sys kill 11 1003

di sys kill 11 2956

di sys kill 11 3213

This restarts httpsd.

To restart the httpsd process, use the 'fnsysctl killall httpsd' command.

In some cases, no HTTPS processes are seen to be running, so it may be necessary to restart the FortiGate firewall.

This may be the case if a recent firmware upgrade was completed and the GUI login issues are observed after the upgrade.

After the restart, the HTTPS process will appear in the results of diag sys top. It will be possible to log in normally through the GUI.

9. If there are two default routes to 0.0.0.0 with the same distance and priority, for example, 5, it can not be possible to access GUI. To find default routes in the CLI, run "get router info routing-table database | grep 0.0.0.0".

• Change the distance for one route to 10 as an example.
• Now it should be possible to log in to the GUI and it should not freeze or hang.
• Disable the setting: Retrieve the default Gateway from the server on the internal network interface.
• If trying to access FortiGate using the WAN interface, make sure that the route is active or valid in the routing table.

10. Modify the TLS version for the FortiGate GUI access.

    By default, TLS 1.1 and TLS 1.2 are enabled when accessing the FortiGate GUI via a web browser.

    
    To verify what version is enabled, run the following commands:

    config system global

    get | grep 'min-proto'

10. If Multi-VDOMs are enabled, run the following commands:

       config global 

    config system global 

    get | grep 'min-proto'

To change this setting from the CLI:

config system global
    set admin-https-ssl-versions (shift + ?) <- To list the available TLS version.

tlsv1-0 TLS 1.0.
tlsv1-1 TLS 1.1.
tlsv1-2 TLS 1.2.
set admin-https-ssl-versions tlsv1-2 <- With this setting, only TLS 1.2 is allowed.

end

From v6.4, tlsv1-0 is no longer supported and instead, tlsv1-3 was introduced:

config system global
    set admin-https-ssl-versions
tlsv1-1 TLS 1.1.
tlsv1-2 TLS 1.2.
tlsv1-3 TLS 1.3.
end 

10. If the GUI is not reachable, that may also be that packets are not reaching the webserver or interface or responses from the web interface are not transmitted back to the user.

To verify, run a packet capture via CLI and see how the TCP handshake is made and if follow-up packets are visible.

The command is:

diag sniffer packet any 'port 8443' 4 0 a (replace the port if the web interface is reachable via a different port).

Filters, adding a host IP, if the connecting IP is known, can be added:

diag sniffer packet any 'host 192.168.48.2 and port 8443' 4 0 a

Example output:

FGT# diag sniffer packet any 'port 8443' 4 0 a
Using Original Sniffing Mode
interfaces=[any]
filters=[port 8443]
2024-08-28 16:36:30.527027 port1 in 192.168.48.2.56662 -> 10.191.19.1728443: syn 1919112407 
2024-08-28 16:36:30.527238 port1 out 10.191.19.1728443 -> 192.168.48.2.56662: syn 3263049518 ack 1919112408 
2024-08-28 16:36:30.527648 port1 in 192.168.48.2.56662 -> 10.191.19.1728443: ack 3263049519

Related documents:

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....