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

Upgrade from 9.3x to 9.401-11: 1) Application Control does not work anymore. 2) Web Protection breaks DNS lookups

After upgrading to 9.401-11 we received a DMCA Notice.

"No way" I thought because there's an Application Control rule that we had working for years that disallows Bittorrent.

I go and investigate/test and find that bittorrent works perfectly despite Network Visibility and Application Control being turned on and a "block and log" rule for bittorrent and Gnutella that worked fine for years I can initiate and download/seed bittorrents.

Is Application Control broken in 9.4 or have they changed the way it needs to be set up ? I did not see anything pertinent in known issues list.

Second issue is that we have Web Protection in transparent mode, http only and since 9.4 it breaks browsing. Interestingly it breaks DNS lookups. Any attempts to browse with transparent Web Protection enabled will bring up the block page saying "DNS Resolution Timeout".

The log shows

2016:04:17-21:53:17 guests httpproxy[19017]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query 6fdd (www.cnn.com) timed out, retransmitting (retry 1)"
2016:04:17-21:53:17 guests httpproxy[19017]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query c6d0 (media-cache-ak0.pinimg.com) timed out, retransmitting (retry 2)"
2016:04:17-21:53:22 guests httpproxy[19017]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query 9de3 (media-cache-ec0.pinimg.com) timed out, retransmitting (retry 1)"
2016:04:17-21:53:22 guests httpproxy[19017]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query 6fdd (www.cnn.com) timed out, retransmitting (retry 2)"

Disabling web protection immediately fixes the DNS issues. I do not understand the connection. Before 9.4 there was no connection between Web Protection and DNS resolution.
My clients are setup to use OpenDNS and on UTM I have OpenDNS set up as forwarders as well so UTM can resolve DNS, too. I have tested this in Support -> Tools -> DNS lookup.


This thread was automatically locked due to age.
Parents
  • Check your IPS logs - I began experiencing the same DNS issue after the upgrade to 9.354 and it persisted through 9.4.  I noticed an incredible amount of UDP flood entries in the IPS logs which I suspect are being caused by Google's experimental QUIC protocol.  I attempted to block QUIC through app control but had limited success.  Eventually, I had to whitelist some of the Google IP addresses that were being logged.  DNS issue cleared up immediately.  Please let me know what you find - I have a support case open on this issue.  Thank you.

  • I don't have anything in the IPS logs as you've suggested.

    Apple have just released a later version of 10.11.5, which at the moment appears to fix a couple of the wifi issues, and this morning it's been a little more stable, although I'm seeing this in the Web Filter logs and it has frozen a couple of times, I'm not getting the WiFi disconnects, so think this is a UTM issue.

    2016:04:21-12:03:37 phobos httpproxy[16820]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query cdad (safebrowsing-cache.google.com) timed out, retransmitting (retry 1)"

    2016:04:21-12:03:47 phobos httpproxy[16820]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query 2383 (safebrowsing-cache.google.com) timed out, retransmitting (retry 1)"

    2016:04:21-13:25:27 phobos httpproxy[16820]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="dns_expire" file="dns.c" line="195" message="dns query 92ed (www.ebay.co.uk) timed out, retransmitting (retry 1)"

    I'm going to try again with the pharming protection disabled and see what happens.

    Tim Grantham

    Enterprise Architect & Business owner

  • Been testing this weekend, not sure if this helps but it does appear that there is a bug with DNS resolution and the UTM 9.4 release.

    Firstly, I use the UTM as a DNS server as well as a perimeter firewall, and configured to use the ISP forwarders.

    With the DHCP configuration set as using the UTM as the DNS server, quite often I will get the errors indicated as above, and also running NameBench resulted in quite a few DNS lookup failures.

    I then built a DNS server on a Windows 2012 R2 demo license, this was allowed through the firewall and configured clients to use that for DNS resolution.

    Then I ran NameBench and this didn't report any DNS lookup failures, and the Macs on the network now always seem to resolve and display the pages correctly.......although.....

    Still getting the http.log file still has the retransmitting errors in there with pharming  protection enabled, this hasn't been so much of a problem just means occasionally web pages take a little longer to load, but at least I'm not getting the dreaded page cannot be displayed any more.

    Going by my tests, it would appear that there is an issue with DNS name resolution in 9.4 that needs fixing.

    Tim Grantham

    Enterprise Architect & Business owner

  • When you configured your clients to use Windows 2012's DNS, did you change the DNS forwarder in the UTM to use Window's DNS as well? 

Reply Children
  • I had the UTM pointing to the Windows 2012 R2 server.

    To ensure it wasn't my network etc, I used a 4G dongle connected to the server to route out any traffic going to google DNS through that path.

    Taking the VDSL line totally out the equation for any DNS lookups.

    Tim Grantham

    Enterprise Architect & Business owner

  • Applied the update 9.402-7 this morning, and must say that I've not had any DNS issues since.

    Hopefully this means that this issue is now resolved.

    Tim Grantham

    Enterprise Architect & Business owner

  • Keep us updated on any issues you find in 9.402-7 going forward. Thanks!

  • For what it's worth, I'm pretty sure the DNS issues aren't resolved yet.  I'm using the SG115w... is it possible that the 'w' version hasn't been fixed yet?  I actually experienced a DNS storm about 4 months ago that would've bricked the UTM if I hadn't noticed that the firewall log was growing at a rate of ~120MB every 10 minutes.  I blamed our VoIP provider and found a new one.  But I still had to stop using the UTM as a DNS proxy, and Namebench still timed out when testing the UTM.  I'm on 9409-9.

  • Brian, do you still have a sample line from the Firewall log file?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • DNS drops were also reported here

    https://community.sophos.com/products/unified-threat-management/f/network-protection-firewall-nat-qos-ips/84469/dns-packets-dropped

    I commented I was having similar issues. What has fixed it for me was re-doing the settings. I've removed the internal DNS servers from the "Allowed Networks" DNS and applied the setting. I then re-added them again, and applied. I also did the same for the firewall rule I had created. It hasn't failed in weeks  

  • Bob,

    Unfortunately not, they were too large so I deleted them.

    Looking at the post under mine and the thread it links to, I don't know that I ever "cleanly" recreated the forwarders and allowed networks, although I definitely deleted and re-entered the config at some point.  And even though I entered the networks in the "Allowed" window, I also explicitly permitted access to the DNS servers via a firewall rule.  At the time my primary DNS was from my ISP with a Level 3 server as backup.

    Thanks,

    Brian