Frequently Asked Question

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, yet not through the web admin GUI.

Scope

FortiGate.

Solution

Shortlist:

1. HTTP/HTTPS service is not enabled on the interface.
2. Trusted hosts are enabled on all admin users and the source IP that is in use is not listed as a trusted host.
3. MTU along the path.
4. GUI PORT (HTTP/HTTPs) is another.
5. VIP Overlap.
6. Local-in policy with a deny action.
7. Issues with the HTTPS Daemon.
8. Routing issue.
9. TLS/SSL issue.
10. VDOMs issue.

Details:

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.

When the endpoint is unable to ping the FortiGate interface IP address, the next step is to determine if the endpoint is in the same broadcast domain using ipconfig /all. In some cases, the IP address must be assigned statically on the endpoint device if DHCP is not enabled on the FortiGate interface or when the endpoint is unable to connect to the internal DHCP server.

Connect to FortiGate via SSH through 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 the next steps:
Technical Tip: 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
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). Troubleshooting:Execute a sniffer and/or a debug flow. diagnose sniffer packet any "host 10.1.1.10 and port 443" 4 0 port3 in 10.1.1.1.55826 -> 10.1.1.10.443: syn 3127611448 -> See the INBOUND request but not a reply. port3 in 10.1.1.1.55825 -> 10.1.1.10.443: syn 2440393440 Debug FLOW: msg="iprope_in_check() check failed on policy 0, drop" <- The final action is drop. Check if the HTTP/HTTPS service is enabled on the interface: show sys int port3 | grep -i allowaccess set allowaccess ping ssh --> HTTPS is missed (it is not a best practice to enable HTTP). Enable the service on the interface: config system interface edit port3 set allowaccess ping ssh https nextend show sys int port3 | grep -i allowaccess set allowaccess ping https ssh

Test the GUI access again:It will show the following message msg='policy-4294967295 is matched, act-accept'. diagnose sniffer packet any "host 10.1.1.10 and port 443" 4 0port3 in 10.1.1.1.56070 -> 10.1.1.10.443: syn 3312775163 ->INBOUND packetsport3 out 10.1.1.10.443 -> 10.1.1.1.56070: syn 2692103782 ack 3312775164 ->OUTBOUND msg="policy-4294967295 is matched, act-accept" -> Debug will show policy matchmsg="after check: ret-matched, act-accept, flag-00000000, flag2-00000000"

1. 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 ...omit next end Changing the trusted host configuration: config system admin edit set trusthost <1 to 10> / set ip6-trusthost <1 to 10> /end Trusted host settings are defined on an individual admin user basis and are valid for all types of access.

GUI: Define Trusted hosts by going to System ->Administrators.

For example:If a user is trusted for access through SSH, it is also trusted for HTTP or HTTPS access. Troubleshooting:

1. See the inbound request: there is no reply.
2. The debug flow will show the 'policy 0, drop'.
3. It won’t indicate anything about TRUSTED HOSTS.
4. Debug HTTPs will not show any log.

diagnose sniffer packet any "host 10.1.1.10 and port 443" 4 0

port3 in 10.1.1.1.55826 -> 10.1.1.10.443: syn 3127611448

port3 in 10.1.1.1.55825 -> 10.1.1.10.443: syn 2440393440

Debug Flow:

msg="iprope_in_check() check failed on policy 0, drop"

Check if trusted hosts are configured in all admin users, which is the case:

show sys admin

config system admin

edit "admin"

set trusthost1 10.1.7.0 255.255.255.0

set accprofile "super_admin"

...omit

next

end"

Add the source IP as a trusted host:

config system admin

(admin) # edit admin

(admin) # set trusthost2 10.1.1.0/24

(admin) # show

config system admin

edit "admin"

set trusthost1 10.1.7.0 255.255.255.0

set trusthost2 10.1.1.0 255.255.255.0

next

Another option is to create a SECOND admin user without a trusted host. config system admin edit "admin" set trusthost1 10.1.7.0 255.255.255.0 ….omit next edit "admin2" <- admin2 has no trusted host configured. set accprofile "super_admin" …omit nextend This will show the GUI no matter which is the SOURCE_IP, but upon trying to log in using an ADMIN user from an IP that is not trusted on that specific user, it will show an authentication failure. Debug HTTPSD will show the following error: logincheck_handler[532] -- login attempt completed with code -101

1. 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 a smaller size.

To then be 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.

1. 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 8080 <- The ports were changed from the default.
show full | grep admin-sport

set admin-sport 8443 <- The ports were changed from the default.

Troubleshooting:Try to access it using the default ports 80/443. It will have the same behavior as if the service is not enabled: it will not reply and will show a 'policy 0, drop' message. diagnose sniffer packet any "host 10.1.1.10 and port 443" 4 0 port3 in 10.1.1.1.55826 -> 10.1.1.10.443: syn 3127611448 port3 in 10.1.1.1.55825 -> 10.1.1.10.443: syn 2440393440msg="iprope_in_check() check failed on policy 0, drop"

When using port 443 to access the GUI, check if 'DNS over HTTPS' is enabled under the DNS Service of the same interface, as it also uses port 443 - which can conflict with the GUI connection. To check if 'DNS over HTTPS' is enabled, run this command under FortiGate GUI -> Network -> DNS Server -> DNS Service on Interface -> Edit the Associated Interface Entry -> Disable 'DNS over HTTPS': show full system dns-server | grep doh set doh enable

CLI Reference:

config system dns-server
edit "fortilink" <- It can be any FortiGate Interface where the user is trying to log in.
set doh disable <-
next
end

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

:

.

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

end

For HTTPS access, use the following syntax instead: config system global set admin-sport end

1. The existing virtual IP is overriding the 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.

Troubleshooting:

The sniffer will show the INBOUND request has been forwarded it to another IP

HUB01 # diagnose sniffer packet any "host 192.168.247.1 and port 443" 4 0 a
port2 in 192.168.247.1.57530 -> 192.168.247.20.443: syn 174545504
port4 out 192.168.247.1.57530 -> 10.255.255.11.443: syn 174545504 <- Same Source IP and Same Source Port.

A debug flow will show the traffic matches a VIP:

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow show function-name enable
diagnose debug flow show iprope enable
diagnose debug flow filter saddr 192.168.247.1 <- Adjust to the source IP of the testing PC.
diagnose debug flow filter daddr 192.168.247.20 <- Adjust to the GUI FortiGate IP.
diagnose debug flow filter dport 443 <- Adjust the port if it is not the default port.
diagnose debug console timestamp enable
diagnose debug flow trace start 1
diagnose debug enable

Among all the lines it will receive on the DEBUG, the following will appear in the first lines:

msg="find DNAT: IP-10.255.255.11, port-0(fixed port)"

This indicates there is a VIP matching the request. Check the VIPs on the GUI under Policy & Objects -> Virtual IPs.

1. Check if any local in policy is configured to deny access to the related interface.

config firewall local-in-policy

show full

edit 1

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

Troubleshooting: Run a sniffer or a debug flow. diagnose sniffer packet any "host 10.1.1.10 and port 443" 4 0port3 in 10.1.1.1.55826 -> 10.1.1.10.443: syn 3127611448 <- It will show the INBOUND yet not a reply.port3 in 10.1.1.1.55825 -> 10.1.1.10.443: syn 2440393440 Debug Flow will indicate that a LOCAL-IN HANDLER denied the traffic. msg="policy-1 is matched, act-drop" func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 1, drop" Check local-in policies using the CLI. show firewall local-in-policyconfig firewall local-in-policy edit 1 set intf "virtual-wan-link" set srcaddr "all" set dstaddr "FG_GUI_192.168.247.20/32" set service "ALL" set schedule "always" next
end In this case, there is a LOCAL-IN policy denying all traffic with the destination set to the object 'FG_GUI_192.168.247.20/32', which is the IP of the FortiGate on which the GUI is enabled.

1. If the issue happens after creating IPSEC DIAULUP VPN, check if ike-tcp port is changed to port 443 from the default port 4500. This should be checked if the firewall is on v7.6.1 or later.

In v7.6.3, a warning will be presented to remind users that the HTTPS port conflicts with the ike-tcp-port.

1. Restart the HTTPS Daemon.

If none of the processes above fixed the issue, try restarting the HTTPS Daemon. diagnose sys process pidof httpsd Note the first listed process ID (this is the parent process). diagnose sys kill 11 XX <- Add the process ID gathered in step 1. Or: Consider killing PIDs one by one. For example: diagnose sys process pidof httpsd100329563213diagnose sys kill 11 1003diagnose sys kill 11 2956diagnose sys kill 11 3213 This restarts httpsd. To restart the httpsd process, use the 'fnsysctl killall httpsd' command. Note: Try using a custom Admin Access port (for example: 8443, 4443) to avoid any port conflict for the default HTTPS port 443. 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 the diagnose sys top. It will be possible to log in normally through the GUI.

1. Routing Issue: If there are two default routes to 0.0.0.0 with the same distance and priority (for example, 5), it will not be possible to access the 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.

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'

1. VDOMs issue:

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

1. If the GUI is not reachable, that may also be because packets are not reaching the web server 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:

diagnose 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:

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

Example output:

FGT# diagnose 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

Legacy (for versions 5.6 and above only).
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_Factoryend