Skip to main content
Akononov
New Member
July 11, 2016
Question

Fortigate 100D Fortios 5.4.1 Deny: DNS error

  • July 11, 2016
  • 27 replies
  • 108032 views

Hello!

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

IP77.88.8.1Host Namesecondary.dns.yandex.ruPort53Interfacewan1

ApplicationNameUnknownCategoryunscannedProtocoludp

ActionActionDeny: DNS error

 

AND

 

IP77.88.8.1Host Namesecondary.dns.yandex.ruPort53Interfacewan2

ApplicationNameUnknownCategoryunscannedProtocoludp

ActionActionDeny: IP connection error

    27 replies

    Akononov
    AkononovAuthor
    New Member
    August 8, 2016

    Hi! 

    This problem only for me?

    kwik
    New Member
    September 5, 2016

    Nope, I've also the same 100D on 5.4.1 and the DNS error.

    Loading webpage takes a minutes (do you also have this behaviour?)

     

    Did you find a solution ?

     

     

    MikePruett
    New Member
    September 6, 2016

    Do you have any layer 7 applied to the policy that is letting DNS out?

    Alby23
    New Member
    January 17, 2017

    Possible malformed/invalid DNS requests?

    Holy
    New Member
    January 25, 2017

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

     

    will also open a ticket today.

    Holy
    New Member
    January 27, 2017

    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 
    tmazowski
    New Member
    March 21, 2017

    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
    New Member
    March 21, 2017

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

    MikePruett
    New Member
    March 21, 2017

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

    dlopez
    New Member
    May 5, 2017

    Hello,

    Same errors with same device and same OS.

    Did you fix the issue ?

    Thanks

    Regs

    lmccuistian
    New Member
    May 5, 2017

    Sorry, I didn't update this thread sooner.  I think I found the solution to my problem. It seems the log severity was set much higher than it should have been. I set the log severity to informational by using the commands below and now I have a usable log. config log mem filter set severity information end

    Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
    Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.
    Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!