This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos UTM 9.510-4 released - let's share experiences!

Released yesterday:

https://community.sophos.com/products/unified-threat-management/b/utm-blog/posts/utm-up2date-9-510-released

 

Found out so far, that mailmanager is broken:

Others? :-)



This thread was automatically locked due to age.
Parents
  • Seeing a ton of these messages every few seconds in the DNS proxy log.

    No idea where to even look to resolve this...?   Don't see these messages in the previous logs, only after updating to 9.510-4.

    UPDATE:

    This flood of messages occurs when dns forwarding is configured (network services/dns/forwarders). Doesn't matter what goes in there, google, cloudflare, opendns, etc.  All cause these messages to be generated multiple times a minute. Happens regardless if "Use forwarders assigned by ISP" is checked ornot.

    UPDATE 2:

    Set up a test utm installation. Using ssh to do nslookups directly from the utm.  Every time a dns lookup is initiated (ping, nslookup), the resolver priming query line below is generated in the log if a dns forwarder is configured.  This is reproducible on the main utm too.

    So to keep the flood of these from filling up the dns proxy log, nothing on the dns forwarding screen needs to be configured or checked.

    2018:07:30-18:38:58 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:38:59 utm named[5294]: resolver priming query complete
    2018:07:30-18:38:59 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:39:04 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:10 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:11 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:39:16 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:25 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:48 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:06 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:10 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:16 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:18 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:24 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:24 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:30 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:30 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:35 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:38 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:41 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:41 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:42 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:42 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:51 utm named[5294]: resolver priming query complete

Reply
  • Seeing a ton of these messages every few seconds in the DNS proxy log.

    No idea where to even look to resolve this...?   Don't see these messages in the previous logs, only after updating to 9.510-4.

    UPDATE:

    This flood of messages occurs when dns forwarding is configured (network services/dns/forwarders). Doesn't matter what goes in there, google, cloudflare, opendns, etc.  All cause these messages to be generated multiple times a minute. Happens regardless if "Use forwarders assigned by ISP" is checked ornot.

    UPDATE 2:

    Set up a test utm installation. Using ssh to do nslookups directly from the utm.  Every time a dns lookup is initiated (ping, nslookup), the resolver priming query line below is generated in the log if a dns forwarder is configured.  This is reproducible on the main utm too.

    So to keep the flood of these from filling up the dns proxy log, nothing on the dns forwarding screen needs to be configured or checked.

    2018:07:30-18:38:58 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:38:59 utm named[5294]: resolver priming query complete
    2018:07:30-18:38:59 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:39:04 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:10 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:11 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:39:16 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:25 utm named[5294]: resolver priming query complete
    2018:07:30-18:39:48 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:06 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:10 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:16 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:18 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:24 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:24 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:30 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:30 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:35 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:38 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:41 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:41 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:42 utm named[5294]: resolver priming query complete
    2018:07:30-18:40:42 utm/utm named: Last message 'resolver priming que' repeated 1 times, suppressed by syslog-ng on utm.local.lan
    2018:07:30-18:40:51 utm named[5294]: resolver priming query complete

Children
  • Decided to role back to 9.509-3.  Read elsewhere on here that restoring a backup from a newer utm build is not recommended to an older utm.  Wasted 3 hours this morning redoing the changes I've made since (lots of webfiltering changes).  Lesson well learned.  In the future will only upgrade when there's no changes being made, at least for some period of time.  Otherwise, unless you like to do lots of testing, don't upgrade manually until the patch is officially pushed.  Even then, probably a good idea to wait some time for any unforeseen issues.

    And of course, backup backup backup before installing anything.  In the vm environment it's easy enough to make a snapshot of the system so there minimal log loss.  Otherwise at least you have your configuration backup, but no logs.

    FWIW, my latest backup was from 7/29 so loss wasn't too significant but still a hassle.

    Note, I did open a ticket with support but haven't received any response yet.

    Edit: Appears ticket was closed without any notification or reason.  Nice!

  • Webmin an Userportal are not reachable via public address from internal lan. Has anyone the same issue? Problem with loopback?

     

  • Hello,

    I can confirm the "resolver priming query complete" flood in DNS-Proxy-Log. Fills up quite fast. Is there a way to switch the parameters back from the now "verbose" configuration?

    BR,

    TP

  • @HanspeterHolzer

    Thanks for the update.  I won't even think about upgrading til sometime in october.  This issue indeed sounds like excessive logging was enabled for some reason but never turned back off.  Maybe fixed in the next update¿?