In this article

After installing DNSFilter on your network, it is also important to prevent users from bypassing your filter by setting custom DNS entries into their network devices. This article assists network administrators with blocking the most common methods.

Circumvention of content filtering can be prevented by:

• Denying users the ability to change network settings on their devices
• Creating firewall rules that force DNS traffic only to DNSFilter

If these methods are not applied, users will be able to circumvent your content and security filtering by changing their DNS settings. These diagrams show what traffic flow is like without and with firewall rules.

Implement firewall rules

In order to prevent end-users from utilizing 3rd-party DNS servers, you can implement a compensating firewall rule in your network’s firewall, which will transparently redirect any outbound DNS request to DNSFilter.

Add firewall rules according to the manufacturer's documentation. There are several common methods available to accomplish this, which include:

• Edit the .conf file or run shell commands (iptables example below)
• Utilize destination-based round robin to enter multiple destinations to load balance the two DNSFilter AnyCast IPs (103.247.36.36, 103.247.37.37)
• Create a NAT rule to intercept all DNS lookups on port 53 and port 853 that forwards the lookups to localhost (127.0.0.1), which centralizes DNS resolution. See our Community post for instructions to set this up on a Fortinet firewall

iptables

You can implement a firewall rule via either the iptables.conf file or shell commands:

iptables.conf

*nat
    :PREROUTING ACCEPT [2:143]
    :INPUT ACCEPT [2:143]
    :OUTPUT ACCEPT [0:0]<br>:POSTROUTING ACCEPT [2:134]
    -A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination 103.247.36.36:53
    -A OUTPUT -p tcp -m tcp --dport 53 -j DNAT --to-destination 103.247.37.37:53
    

Shell commands

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 103.247.36.36:53
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 103.247.37.37:53

pfSense

The pfSense section in our transparent proxying article provides an explanation of how to create rules for DNSFilter.

Test firewall rules

Below is the method for testing your firewall rules to ensure that users cannot circumvent the policies that you have set for DNSFilter.

1. Add a domain to the policy Block list associated with your site
2. Perform an nslookup (Windows) or dig (MacOS/Linux) to that site over DNSFilter’s Anycast IP addresses

   nslookup YOURTESTSITE.com. 103.247.36.36
       dig +short YOURTESTSITE.com. @103.247.36.36

3. Copy the resulting IP address (in Windows non-authoritative answer) for the domain into your browser and attempt to visit it, there should be a block page as below

   

4. Now, perform the same test but using Google’s public DNS resolver:

nslookup YOURTESTSITE.com. 8.8.8.8
dig +short YOURTESTSITE.com. @8.8.8.8

If your firewall rule is set correctly, you should receive the same answer as the previous query. This is evidence that your firewall rule is operative and DNS queries are being sent to DNSFilter. This means users will be blocked according to policy, no matter what they have set on their device.

You may also want to look at our Addressing Conflicts article, which details devices/software that may conflict with DNSFilter’s operation.

DNS-over-HTTPS

DNS-over-HTTPS (DoH) is great if all you can do is implement encryption at the browser level. The preferred solution is DNS-over-TLS, which covers the entire OS (not just browser traffic). We support DoT in all our Roaming Clients and our Relay.

Firefox recognizes when a computer is using the DNSFilter resolvers and will automatically disable DNS-over-HTTPS, which is built-in to the Firefox browser. It works differently in that it checks to see if the configured DNS server supports DNS-over-HTTPS, and if so, will use it accordingly. When DoH is bypassed, the query is still encrypted by DNSFilter through DNS-over-TLS.

For other browsers, organizations that want to ensure their filtering policies are not circumvented can do this by blocking access to DoH providers. DNSFilter has contributed to a community-maintained list of DoH providers your firewall can block. Download the list of DoH providers.

For more details, check out our blog on DNS-over-HTTPS.

Preventing circumvention in the Windows Roaming Client

The Windows roaming client is installed via a standard MSI package format. As a standard application, normal users in a Windows environment are unable to prevent the filter from running. However, in some environments, IT has allowed local users to have admin privileges on their devices. While the roaming client cannot prevent itself from being uninstalled, there are several steps you can take to prevent even administrative users from interfering with filtering:

1. Using a GPO to prevent stopping the DNSFilter service

If you're running a Microsoft Windows network that allows you the ability to apply GPOs to your Users/Computers - the first step is to prevent the users ability to affect the Roaming Client Service.

In order to configure this GPO, you will need to run your Group Policy Management Console on a machine that already has the Roaming Client installed in order to identify the service that the policy should affect.

Note: If the service that you want to configure is not present in the list, you will need to install GPMC on a computer that has the service running.

This process should be compatible with pretty much any currently supported edition of Windows Server (and likely a few that aren't supported anymore!)

1. If you don't want to apply this restriction to your domain(s) universally, you will need to create a new security group containing the AD Users/Computers that you want to restrict
2. Open the Group Policy Management Console, and create a new Group Policy Object (GPO) with a unique name like "Prevent DNSFilter Agent Service Stoppage"
3. Edit your newly created GPO and navigate through the tree starting at "Computer Configuration," then "Policies," then "Windows Settings," then "Security Settings," and finally, "System Services"
4. Scroll through the list of services until you find the "DNSFilter Agent" Service
5. Double-click the "DNSFilter Agent" service entry
6. Check the "Define this Policy" box
7. Select the "Automatic" radio button underneath "Select Service Startup Mode"
8. Click the "Edit Security ..." button
9. Click the "Add" button, add an entry for the "NETWORK SERVICE" user, and grant it read permissions
10. Remove any "Administrators", "Domain Administrators," etc., groups that may contain the users you wish to prevent. (do not remove the "SYSTEM" or "INTERACTIVE" accounts - this would be very bad.)
11. Exit the GPO Editor by clicking OK until you return to the main list and close the editor
12. Your GPO is now properly configured to prevent the DNSFilter Agent service from being stopped via the Services control panel
13. Apply the GPO to your required Organizational Units or Individual User Accounts using the standard methods

Once you have done this, and the relevant users or workstations have been logged off and back on, the restriction should be in place!

You can test the efficacy of the GPO by logging on to a workstation with one of the affected accounts and opening the Services control panel. When you right-click on the "DNSFilter Agent" line item, all the runtime options (Start/Stop/Restart) should be greyed out, and if you go into the service itself, the buttons for the same functions should also be greyed out.

If this is not the case, double-check that the GPO you created is configured correctly and is taking effect properly, and not being overridden by another GPO in your configuration. Troubleshooting steps for this are outside the scope of this document.

NOTE: Even when working correctly, this will not prevent the user from killing the process via the task manager, and though the service will restart more or less immediately, fast-fingered individuals will be able to delete or rename the executable and prevent the service from reloading correctly, or simply delete the containing folder.

2. Removing the DNSFilter client from add/remove programs

The Windows roaming client can be hidden from appearing in the Add/Remove Programs wizard. This method alone does not prevent it from being uninstalled via the command line but makes it more difficult to remove.

To remove the client from add/remove programs, use the flag ARPSYSTEMCOMPONENT=1 during installation time.

3. Hiding the DNSFilter tray icon

The roaming client can also be hidden from the Windows tray (typically the lower right corner of the screen) by using the flag TRAYICON="disabled" during install time. (Remember that hiding the tray icon will make it more difficult to troubleshoot any issues that should arise.)