Description
This article describes how to troubleshoot when DNS cannot be resolved from FortiManager/FortiAnalyzer.
When pinging to a fully FQDN or a domain, it will throw a 'bad address' error.
Scope
FortiManager, FortiAnalyzer.
Solution
- Isolate the issue if able to ping the IP address.
Wira-kvm20 # execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=116 time=4.043 ms
64 bytes from 8.8.8.8: seq=1 ttl=116 time=3.851 ms
64 bytes from 8.8.8.8: seq=2 ttl=116 time=3.696 ms
64 bytes from 8.8.8.8: seq=3 ttl=116 time=3.499 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 3.499/3.772/4.043 ms
- Check if the DNS server is configured correctly, or isolate to use a public DNS server
Wira-kvm20 # show system dns
config system dns
set primary 8.8.8.8
set secondary 1.1.1.1
end
Note:
When changing to a new DNS server, it will still have a cache (10 minutes) of the previous server until it is cleared. Manually kill the DNS daemon to clear the cache as per the steps below.
- Check netstat and get the pid, 'diagnose system print netstat' Example: tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 29007/dns
- Kill the DNS daemon, 'diagnose system process kill -9 <pid>' Example: 'diagnose system process kill -9 29007'.
- Check if FortiManager/FortiAnalyzer is listening to the DNS port TCP 53
Wira-kvm20 # diagnose system print netstat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 29007/dns
tcp 0 0 127.0.0.1:7080 0.0.0.0:* LISTEN 1442/sdnproxy
tcp 0 0 127.0.0.1:31723 0.0.0.0:* LISTEN 2247/httpd
tcp 0 0 127.0.0.1:6386 0.0.0.0:* LISTEN 1459/redis-server 1
........
......
- Perform a debug to understand what happened on the backend
diagnose debug application dns 255
diagnose debug enable
Wira-kvm20 # execute ping google.com
got query 0f66: len=28 google.com A
forward query 0f66 to 8.8.8.8
got query 05fc: len=28 google.com AAAA
forward query 05fc to 8.8.8.8
forward query 0f66 to 1.1.1.1
forward query 05fc to 1.1.1.1
got query 0f66: len=28 google.com A
use unique id: 0f66 -> 0f67
forward query 0f66 to 8.8.8.8
got query 05fc: len=28 google.com AAAA
use unique id: 05fc -> 05fd
forward query 05fc to 8.8.8.8
cancelled query 0f66
cancelled query 05fc
forward query 0f66 to 1.1.1.1
forward query 05fc to 1.1.1.1
ping: bad address 'google.com'
cancelled query 0f66 <----- Failed response, something is blocking from FortiManager/FortiAnalyzer.
cancelled query 05fc <----- Failed response, something is blocking from FortiManager/FortiAnalyzer.
FMG-VM64-KVM # execute ping google.com
got query 404a: len=28 google.com A
connected 12.33.11.1
forward query 404a to 12.33.11.1
got query 46ad: len=28 google.com AAAA
forward query 46ad to 12.33.11.1 <----- No response from Primary DNS server.
connected 8.8.8.8 <----- Query to Secondary DNS server.
forward query 404a to 8.8.8.8
forward query 46ad to 8.8.8.8
got reply 404a from 8.8.8.8: len=44 err=0 google.com A
answer query 404a <----- Successful response, connected via Secondary DNS server.
got reply 46ad from 8.8.8.8: len=56 err=0 google.com AAAA
answer query 46ad <----- Successful response, connected via Secondary DNS server.
PING google.com (172.217.26.78): 56 data bytes
64 bytes from 172.217.26.78: seq=0 ttl=116 time=3.197 ms
64 bytes from 172.217.26.78: seq=1 ttl=116 time=2.631 ms
64 bytes from 172.217.26.78: seq=2 ttl=116 time=3.573 ms
64 bytes from 172.217.26.78: seq=3 ttl=116 time=2.942 ms
--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.631/3.085/3.573 ms
5. Check in the configuration if any 'local-in-policy' is configured:
Wira-kvm20 # show system local-in-policy
config system local-in-policy
edit 1
set action accept
set dport 443
next
edit 2
set action accept
set dport 22
next
edit 3
set intf "port1"
next
end
This configuration will block all TCP/UDP port traffic from port1 besides ports 443 and 22.
Related article:
Technical Tip: How to create a FortiManager local-in policy via CLI
