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.
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.
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.
The Real Site feature of Avast
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 agent proxy which is necessary for the agent 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.
The below screenshots show which options should be unchecked during Panda installation to prevent a conflict with the DNSFilter agent.
If you have already installed Panda's security software, you can simply disable the url filtering service that causes conflict with the DNSFilter agent. 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 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:
- Creating/editing a policy with "DNS Protection" turned off.
- Applying this policy to the endpoints used by DNS Filter.
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 agent. 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 user agent can run without conflict.
For more information, see the Webroot DNS Protection Administrator Guide
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'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 Blacklist:
- datasaver.googleapis.com to your blacklist.
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 blacklist, the browser cannot trust the SSL certificate it uses for communication and will hang on startup. The domain
puffinbrowser.com can also be blacklisted so that users cannot download the browser to begin with.
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 Blacklist:
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 Blacklist:
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.
VPNs are a common and legitimate business and security tool; blocking VPNs is not always the best solution for every use case; use good judgement.
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.
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.
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:*"