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

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

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?

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