Software Conflicts

There are several software applications which can conflict with DNSFilter because they have their own methods of sending DNS requests or tunneling traffic. Most notably, these are security applications, browsers, and VPNS. This article explains how to turn off conflicting settings in such software, so that content filtering is not circumvented by your users.

Security Application Conflicts

Some security software proxies DNS requests and sends them to the vendor for analysis or “big data” purposes. Software in this section will require a change in settings, or removal.

Avast Antivirus (Real Site)

The Real Site feature in Avast Antivirus proxies DNS queries to Avast’s DNS servers. This feature must be disabled to utilize DNSFilter.

This feature is not available in all versions of Avast Antivirus.

Panda Safe (Web)

Panda security products (Panda Antivirus and Panda Dome) offer a product feature called “Panda Safe Web”. This operates a URL filtering service on Windows which conflicts with the DNSFilter Roaming Client proxy which is necessary for the Roaming Client to function. You can either uncheck this option during the installation of Panda products, or disable the windows service if they have already been installed.

During Installation

The below screenshots show which options should be unchecked during Panda installation to prevent a conflict with the DNSFilter Roaming Client.

If you have already installed Panda’s security software, you can simply disable the url filtering service that causes conflict with the DNSFilter Roaming Client. To do so, you can type “services.msc” into the Windows search bar and find “panda_url_filtering Service” in the list of services. Right click, open properties, and change the Startup Type to “disabled” and stop the service. Now restart the DNSFilter service and test your DNS resolution.

Webroot (DNS Protection)

Webroot endpoint products have a setting called “DNS Protection”, which causes DNS requests to be sent to their servers. This setting must be turned off or it will send DNS traffic to Webroot instead of to DNS Filter. Webroot products can still be used for their anti-virus and anti-malware capabilities, as long as this setting is off. The best way to do this is at the policy level in the SecureAnywhere dashboard. It will involve two steps:

1. Creating/editing a policy with “DNS Protection” turned off.
2. Applying this policy to the endpoints used by DNS Filter.

Creating/Editing Policy

There is an old and new version of the dashboard. Either one will work to make policy changes. Create or select a policy and under the “DNS Protection” section, turn “Install DNS Protection” to OFF.

Up to this point, changes have been made to policy only. You must apply these policies to the endpoints. Click on the “Groups” section at the top of the page. Create/edit a group that contains all of the endpoints with the DNS Filter Roaming Client. Click on “Edit Policy”. A menu will be displayed that allows you to select and apply this policy to the endpoints. This policy change will take place within the next few hours, depending on the polling interval set by the Webroot software. Once this change takes place, your DNS traffic can reach us. If in use, our Roaming Client can run without conflict.

For more information, see the Webroot DNS Protection Administrator Guide

enSilo

The enSilo product may attempt to block communication between the computer, the DNSFilter Roaming Client, and external systems. We have compiled a list of URLs and IP Address Ranges which are required for the proper functionality of the Roaming Client. [block:api-header] { “title”: “Browser Conflicts” } [/block] Some browsers or browser versions come with the option to use a proxy as a solution for faster internet access. This is mostly targeted at slow internet connections and mobile devices.

Google Chrome (Data Saver)

Google Chrome’s Data Saver feature is a proxy, performing on-the-fly optimizations, with the goal of reducing bandwidth usage and loading content for mobile devices faster. This is especially useful for cellular 3g/4g/LTE connections, due to the cost and speed of bandwidth.

According to Google’s documentation, this feature is enabled by default on all Android devices, but in our experience, this is not always the case and depends on the Android version, device, and Google Chrome version. There is also a Chrome plugin for desktop operating systems.

With Data Saver enabled, DNS requests go directly through the proxy, bypassing DNSFilter enforcement.

To block Chrome’s Data Saver proxy, which effectively allows circumventing any DNSFilter policies, simply block Proxy and Filter Avoidance in the Threats tab when editing a Policy.

Alternatively, add only the following domains to your Block list: * googlezip.net * datasaver.googleapis.com to your Block list.

Puffin Browser

The Puffin web browser is unique because it is a server-side browser. As such, it uses its own connection to CloudMosa servers (the company which produces Puffin). Essential to the communication of the browser is the HTTPS communication to CloudMosa. This makes blocking Puffin easy. By adding cloudmosa.net to your policy Block list, the browser cannot trust the SSL certificate it uses for communication and will hang on startup. The domain puffinbrowser.com can also be Block listed so that users cannot download the browser to begin with.

Opera (VPN, Turbo, Mini)

VPN

Opera (desktop browser) has a built-in VPN which can bypass DNS-based content filtering. To stop this VPN from being able to connection, add to the following domain to your Block list:

• api.sec-tunnel.com

Turbo/Mini Proxy

Opera Mini, Opera for Android, and Opera for desktop computers (with Turbo Mode) have proxies built in for caching and filter avoidance, which can bypass DNS-based content filtering.

To block Opera’s built-in proxy, which may circumvent DNSFilter policies, simply block Proxy and Filter Avoidance in the Threats tab when editing a policy, or add the following domains to your Block list:

• opera-mini.net
• sitecheck2.opera.com

VPNs

VPNs create a secure tunnel, where DNS queries will be sent through the VPN, rather than the local network. Depending on the type of endusers and use case, you may decide to block the ability for endusers to use a VPN.

SSL VPNs

SSL VPNs are common with free and consumer-focused VPN offerings. SSL VPNs usually use one the following ports to connect:

• 443 (HTTPS)
• 465 (Secure SMTP)
• 993 (Secure IMAP)
• 995 (Secure POP3)

Because these ports are used for very common applications, a network administrator cannot normally block these ports in a firewall.

Deep Packet Inspection is a feature available with some firewalls and security-focused network appliances. The technology analyzes packet information to determine if the packets’ attributes match the intended usage of the port and protocol being used. If the packets have non-standard attributes, they are blocked. If Deep Packet Inspection is enabled and monitoring the aforementioned ports, it’s likely that most SSL VPNs will not connect. Testing is always encouraged. Please contact the vendor of your firewall or security appliance for further information.

IPSec VPNs

Unlike SSL VPNs, these VPN types usually use standardized ports which are dedicated to IPSec VPNs, and can normally can be blocked in the firewall without affecting any applications or services:

• IPSec: 500/udp, 4500/udp
• L2TP: 1701/udp
• PPTP: 1723/tcp
• OpenVPN: 1194/udp

VPN servers and services can usually be configured to run over any port, and VPN services which specifically advertise the ability to get around proxies or content filters are more likely to use nonstandard ports. If your firewall or appliance appliance has Deep Packet Inspection capabilities, it’s recommend to enable it if circumvention is a concern on your network.

SSTP VPNs

An SSTP VPN uses the HTTP protocol as part of it’s initialization process. If the HTTP connection is blocked, the VPN will fail to initialize.

If your firewall supports Layer-7 filtering, you can create a rule to inspect all outbound 80/tcp traffic and block any “HTTP_Connect” headers which contain: "SSTP_VERSION:*"

Microsoft’s Universal Windows Platform (UWP)

When the roaming client is active, UWP VPN application users will receive a “No such host is known” or similar error message when attempting to initiate a VPN session. This will prevent the user from connecting successfully to the VPN. This error will not appear if the roaming client is stopped or if the desktop edition of the VPN client is utilized.

By design, Microsoft constructed “modern” apps in Windows 8+ to be more sandboxed. One of these limitations applies to VPN applications. VPNs built on the UWP (apps) are restricted to use the interface generating the query. Since the Windows Roaming Client is listening on 127.0.0.1 - a different interface l0 - the query therefore never hits the roaming client (or any other DNS forwarding run on 127.0.0.1).

At this time for the standalone roaming client, there is no update to the roaming client that can change this Windows behavior resulting from 127.0.0.1 being set as the local DNS server. This is a core requirement for the roaming client to function. Until Microsoft allows for 127.0.0.1 to be used for DNS by a UWP VPN app, the only option is to either switch to the desktop edition of the VPN client or connect to the VPN concentrator using an IP address rather than a hostname.