Syslog different in 2.2.x vs 2.1.x

  • Has anyone noticed how much less detail is in the logging in version 2.2?  In version 2.1 there was a lot more useful information in the syslogs.  For example, the dns queries were logged, so you could see who made what dns query.  This and other information is not logged in version 2.2.  Is there a way to get this functionality back?

  • Rebel Alliance Developer Netgate

    DNS query logging was never an option unless someone manually enabled it in the advanced options of the DNS Forwarder (dnsmasq) – Unless someone switched to the DNS Resolver (unbound), that would have stayed active.

  • Interesting.  I don't think we have any advanced settings set. The dns query logging stopped after upgrading.  Where would I look for those settings?

  • Rebel Alliance Developer Netgate

    See for that (it has entries for both the forwarder and resolver)

  • Ok, I think this is something else.  We do not have this setting enabled, and are not even using the DNS forwarder.  Yet, in the syslogs we can see all the DNS queries as they pass through the firewall on our 2.1.5 pfsense.  On the 2.2 pfsense that does not happen.  What am I missing here?

  • Rebel Alliance Developer Netgate

    Are the DNS logs sourced from "dnsmasq" in the logs? If so, that option must have been enabled.

    There isn't anything in the base system or packages that would have enabled query logging using the DNS Forwarder or DNS Resolver

  • No, here is an example of what I see in the 2.1.5 syslogs:

    Mar 23 12:30:03 Mar 23 12:30:03 pf: yyy.yyy.yyy.yyy.51658 > 26485+ A? (33)

    (private addresses replaced) = firewall address (syslog source)
    yyy.yyy.yyy.yyy = traffic source as seen and logged by the firewall

    These are just hosts on our network querying dns servers, we are not using DNS forwrder or DNS masq.  This is just being logged as the traffic passes through the firewall.

  • Rebel Alliance Developer Netgate

    That was being passed through by accident then, as a part of the pf output. We replaced the old log with a cleaner/more concise and easy-to-parse single-line format.

    If you want to log DNS queries, then use one of the methods from the link I pasted earlier.

  • Oh no, that is too bad.  That was extremely useful info to get in syslog.  So now in order to get that data I need to use either dns forwarder or dnsmasq?  Any chance this can be added back in for those of us that don't want to use either of those?

  • Rebel Alliance Developer Netgate

    It was never intended to be there in the first place, and there are no plans to bring back that old log format.

  • Ok, thanks for your help.

  • LAYER 8 Global Moderator

    so you want to log queries your clients do to say googledns?  Your not running any resolver or forwarder on pfsense or anywhere else in your network?  I do believe both dnsmasq and unbound have options to log queries.  I think dnstap was added to unbound in 1.5.0, so since we just moved to 1.5.3 thought that would be an option?

    Guess you could always run dnstop to view dns queries, etc.  But you want to log specific IP queries, for troubleshooting or always?

  • Yes, looking to log all dns queries.  We are not running any dns services on the pfsense.  We are running some bind resolvers, I suppose we could enable query logging on those to get the data.  It was just really nice getting the data in the pfsense logs, and hate that they took it away.  I want to always log dns queries, it is very useful for event correlation and forensics.

  • LAYER 8 Global Moderator

    If your clients are using your bind servers, why would you not log it there and send it to syslog?  Bind has very extensive logging functionality if you want it, etc.

    As to pfsense fixing how they were sending syslog - its a good thing!!

  • Yes, that is what we will be doing, using the logging in bind.  I agree that the log format needed to be fixed, but I think they could have done it without removing data.

  • Rebel Alliance Developer Netgate

    The data was never supposed to be there in the first place, it was only there by luck/coincidence the way that pf log output was interpreted by tcpdump. It's data that should never have shown up, but…

Log in to reply