Fortigate 100D Fortios 5.4.1 Deny: DNS error

[Akononov]

Hello!

After upgrade our 100D, in Forward traffic we can see messages:

IP77.88.8.1Host Namesecondary.dns.yandex.ruPort53Interfacewan1ApplicationNameUnknownCategoryunscannedProtocoludpActionActionDeny: DNS error

AND

IP77.88.8.1Host Namesecondary.dns.yandex.ruPort53Interfacewan2ApplicationNameUnknownCategoryunscannedProtocoludpActionActionDeny: IP connection error

[IUseFGT]

Can you post your config to further assist.

Please make sure you are allowing http, https, dns, ntp, and port 8888 at a minimum from your internal to wan.

Also, I would recommend going to system, fortiguard.  Make sure under fortiguard filtering port is set to 8888.  

If you have any other interfaces, I would make sure they also have http, https, dns, and ntp allowed to wan.

In addition, I would recommend setting your FGT dns to the closest server to you.  I have had the best luck if an internal dns is used and then place forwarders in active directory dns to whatever dns you want.  Example, if you use Comcast, use their dns servers in FGT.  Also, place any other network dns to the closest dns server.  Example, If you have a separate wifi interface, specify that same dns server.  Example, Comcast is 75.75.75.75.

Waiting to receive your config if you are still having problems. 

[Alby23]

Possible malformed/invalid DNS requests?

[Holy]

pretty the same errors on 13 FortiGate 50E branches. our FortiAnalyzer is now full of this errors.

will also open a ticket today.

[Holy]

Here is the Answer from Fortinet.

Dear customer,  Thank you for contacting Fortinet Technical Support.  My name *** and I will assist you with this issue.  You will see the following errors if the conditions are met:  1. DNS Queries -- DNS query returns anything but NOERROR.  "action" in log is "dns"  By design FortiGate looks for invalid/failed DNS traffic and will mark it as action=dns or in the GUI as "Action Deny: DNS error".  This happens if the DNS query is not successful returns any other status than NOERROR.  This is an expected behavior in version 5.4 where the firewall logs any invalid DNS traffic.  The firewall action itself is allow/pass, but the bad reply from the server is not forwarded back to the requesting client thus showing the "Deny: DNS Error" message.  ---  2. Host not reachable -- If trying to reach an IP address that do not respond.  "action" in log is "ip-conn"  ---  In both cases of your logs the connection actually allowed by the firewall, for DNS you receive anything but NOERROR and for IP connection error, the destination host does not respond.  Please let me know whether you need further assistance or the ticket can be closed. 

After that i did some Traffic Capture and we looked on it.

in deed there were many errors because of for example a DNS Suffix. 

Dear customer,  As stated in the above answers your requests  in your provided packet capture from the firewall there are 106 DNS packets.  87 have been returned with NOERROR  19 have been returned with "No such name".  That is about 18% non successful requests and are leading to the messages you question.  From my point of view it is exactly behaving as I explained.  For your reference a couple of examples below:  2 2017-01-27 12:42:13.143902 172.16.1.1 172.16.4.200 DNS 164 Standard query response 0x35a0 No such name A wpad.stuttgart.****.local SOA dc01.*****.local 

[ARPi]

Hi, ran into the same error on two different FTG deployments, of one which we had to roll back the deployment because there were lots of incidents. Nearly no DNS resolving was succesful.

So, do the Fortinet replies imply that either;

1. DNS is incorrectly configured (and thus Fortinet is helping you improve your DNS configuration) because this is expected behaviour in FortiOS 5.4

2. this is too much of an advanced or assisting feature that you might aswell disable it (session helper option) ?

How does this help us solve the issue at hand on the FTG ? Or is it not the FTG the issue should be solved on ?

@Holy and @gsarica how did you solve this DNS Error issue at your end ?

[gsarica]

We didn't resolve this. Support sent us the following:

** Can you try to delete the dns session helper from session-helper configuration: 

How session helper works:  The FortiOS firewall can analyze most TCP/IP protocol traffic by comparing packet header information to security policies. This comparison determines whether to accept or deny the packet and the session that the packet belongs to. Some protocols include information in the packet body (or payload) that must be analyzed to successfully process sessions for this protocol. It can happen that the information expected by the security policy is not contained in the header/payload of the packet and that is when the packet is denied or dropped; session helper for DNS is not mandatory for which reason you can delete it and it should work properly after.  DELETE:  #config system session-helper  #show  find the one for DNS and than edit it by giving the number)  #edit 14 <---- I checked on the remote session it is "14"  #set name dns-udp  set protocol 17  set port 53  next  #delete 14 <------  end

We haven't tried this though since we're hesitant to straight up delete anything without being able to test first (it's our only production firewall).

[tmazowski]

We were having similar problems with a FortiGate not being able to resolve DNS names, and thus not being able to connect to FortiGuard. Here is what solved our issue.

(names/IPs changed to protect the innocent)

FORTIGATE # config sys dns

FORTIGATE (dns) # get

primary             : 169.254.253.252

secondary           : 169.254.252.253

domain              : null.com

ip6-primary         : ::

ip6-secondary       : ::

dns-cache-limit     : 5000

dns-cache-ttl       : 1800

cache-notfound-responses: disable

source-ip           : 10.1.2.3 (** this is the LAN/Internal IP)

##Updated the Source IP to 0.0.0.0: 

FORTIGATE (dns) # set source-ip 0.0.0.0

[whizzard]

Mine already has that source IP and we are still getting the error.

[MikePruett]

I created some new security sensors to replace the ones that I already had and it resolved the issues in my case.

[lmccuistian]

I'm have the same issue on my Fortigate 100E FortiOS 5.4.4.  I tried deleting the session helper, without luck (but it didn't seem to hurt anything either).  I also verified my DNS Source IP is 0.0.0.0 already too.

@MikePruett, you stated you created some new security sensors. Are you saying you created new security profiles (AV, Web Filter, App Control, Etc..) across the board, or just for the ones that tied to a policy for DNS traffic?