Description
This article describes some basic troubleshooting steps to follow when an explicit Web proxy is enabled on the FortiGate and when a client PC receives the following error message when trying to access a website.
Scope
FortiProxy.
Solution
The 504 Gateway Timeout HTTP code indicates that the server while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access to complete the request.
The message received is most probably generated if the FortiProxy either did not receive a DNS response for the host name or the response it received was not good (not reachable/not understandable etc).
The following steps might provide more insight into the cause of the issue (these debugs need to be run in parallel CLI sessions, preferably over multiple SSH sessions with saved session output):
- Get a DNS packet capture from the FortiProxy in SSH session 1:
diagnose sniffer packet any "(host <dns-primary-ip> or host <dns-secondary-ip>) and port 53" 6 0 a
Where <dns-primary-ip> and <dns-secondary-ip> are the DNS servers which are configured on the FortiGate.
Run this sniffer trace (after having checked that DNS packets can actually be captured) and let it run until several 'Gateway Timeout' issues have been received in a browser. Note the timestamp of the occurrence. After the issue is reproduced, the packet capture can be stopped with Ctrl+C.
- Get DNS debugs in SSH session 2:
diagnose test application dnsproxy 2 <----- Show stats.
diagnose test application dnsproxy 3 <----- Dump DNS setting.
diagnose test application dnsproxy 6 <----- Dump FQDN.
diagnose test application dnsproxy 7 <----- Dump DNS cache.
diagnose test application dnsproxy 8 <----- Dump DNS database.
diagnose test application dnsproxy 12 <----- Show Hostname cache.
diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application dnsproxy -1
diagnose debug enable
-
Get WAD daemon logs in SSH session 3:
diagnose wad filter clear
diagnose debug console timestamp enable
diagnose wad filter src x.x.x.x <----- Where x.x.x.x is the IP address of a test workstation.
diagnose wad debug enable category all
diagnose debug enable
Reproduce the issue with these logs enabled. This should allow the identification of the type of DNS issue that is being faced.
Try also to clear the DNS cache:
diagnose test application dnsproxy 1
And see if the DNS resolution for the website is actually happening by using:
diagnose test application dnsproxy 7
To stop the debug:
diagnose debug disable
diagnose debug reset
The DNS resolution can happen, but the resolved IP is not reachable (for example, if in front of it is another firewall that would block some traffic).
