Description
This article gives 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 in order 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):
1) 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 was reproduced, the packet capture can be stopped with Ctrl+C.
2) Get DNS debugs in SSH session 2:
# diag test app dnsproxy 2 <----- Show stats.
# diag test app dnsproxy 3 <----- Dump DNS setting.
# diag test app dnsproxy 6 <----- Dump FQDN.
# diag test app dnsproxy 7 <----- Dump DNS cache.
# diag test app dnsproxy 8 <----- Dump DNS DB.
# diag test app dnsproxy 12 <----- Show Hostname cache.
# diag debug reset
# diag debug console timestamp enable
# diag debug application dnsproxy -1
# diag debug enable
3) Get wad daemon logs in SSH session 3:
# diag wad filter clear
# diag console timestamp enable
# diag wad filter src x.x.x.x <----- Where x.x.x.x is the IP address of a test workstation.
# diag wad debug enable category all
# diag 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:
# diag test app dnsproxy 1
and see if the DNS resolution for the website is actually happening by using:
# diag test app dnsproxy 7
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).
