In this article

Prevent end users from circumventing DNSFilter on network devices. Users can circumvent filtering policies by changing DNS settings if prevention is not in place.

Network administrators can prevent circumvention at different levels:

• Device network interface
• Operating system or browser encryption
• Firewall rules and deep packet inspection
• End-user VPN installation
• Roaming Client admin settings

Select the methods that best serve the organization's preferences and systems.

Lock device DNS settings

Denying users the ability to edit the network interface on their devices eliminates the possibility of circumvention. 

Implement operating system or browser encryption

DNS over HTTPS (DoH) encrypts DNS requests at the browser level. DNSFilter also supports DNS over TLS (DoT), which encrypts all DNS traffic at the operating system level. DoT is available in all Roaming Clients and the Relay.

Firefox automatically detects when DNSFilter resolvers are in use and disables its built-in DoH. In those cases, Firefox continues using DoT, so queries remain encrypted. DNSFilter also returns an NXDOMAIN response for Firefox’s DoH detection domain, use-application-dns.net, ensuring the browser correctly identifies that secure DNS resolution is already managed.

Other browsers may still attempt to use DoH. To prevent circumvention, block access to known DoH providers. DNSFilter contributes to a community-maintained list of DoH servers that can be blocked at the firewall.

Force DNS traffic to DNSFilter with firewall rules

There are several ways to do this, depending on the firewall's options. Reference the firewall manufacturer's documentation for detailed instructions. 

Transparently redirect outbound DNS requests to DNSFilter

Set up firewall rules to forward DNS traffic to port 5353 or 5354 to prevent ISP and end-user content filtering circumvention. This is useful if the ISP is transparently proxying DNS, or if end users can use third-party DNS servers. 

Apply this logic to any firewall make or model. To redirect outbound DNS traffic with iptables, run these commands:

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

Load balance round robin settings

If the organization's firewall offers destination-based round robin settings, enter multiple destinations to load balance the two DNSFilter Anycast IP addresses.

Intercept all DNS lookups with a NAT rule

Create a NAT rule or port-forwarding rule on the firewall, such as on Fortinet or pfSense, that sends all UDP and TCP port 53 traffic to the DNSFilter Anycast IPs. Redirecting to localhost (127.0.0.1) sends traffic to the firewall's own resolver instead of DNSFilter, so DNS never reaches DNSFilter for filtering. 

To create the rule in pfSense:

1. Navigate to Firewall > NAT > Port Forward.
2. Select Add to create a new rule.
3. Complete these fields:
   • Interface: LAN
   • Protocol: TCP/UDP
   • Destination: LAN Address, with Invert Match selected
   • Destination Port Range: DNS (53)
   • Redirect Target IP: 103.247.36.36
   • Redirect Target Port: 5353
   • Description: Redirect DNS to DNSFilter
   • NAT Reflection: Disable
4. Repeat for the second Anycast IP (103.247.37.37) as a failover, or create an alias containing both IPs.

Test firewall rules

Test firewall rules to ensure that users cannot circumvent DNSFilter policies.

1. From the DNSFilter dashboard, add a domain to a Block List.

2. Run a query for that domain against the DNSFilter Anycast IP addresses, using resolve-dnsname on Windows or dig on macOS and Linux:

   resolve-dnsname -name YOURTESTSITE.com. -server 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 a browser and attempt to visit it. A Block Page displays.

   

4. Run the same test using Google’s public DNS resolver:

   resolve-dnsname -name YOURTESTSITE.com. -server 8.8.8.8
   dig +short YOURTESTSITE.com. @8.8.8.8

The test returns the same result as the previous query. This is evidence that the firewall rule is operative and DNS queries are being sent to DNSFilter. Users are blocked according to policy, no matter what they have set on their device. 

Block end-user VPN installation

Depending on the type of end user and use case, blocking the ability to use a VPN may be appropriate. The following methods block VPN installation by type.

SSL VPNs

SSL VPNs are common with free and consumer-focused VPN offerings. SSL VPNs usually use one of 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 these ports, most SSL VPNs do not connect.

IPSec VPNs

Unlike SSL VPNs, these VPN types usually use standardized ports which are dedicated to IPSec VPNs and can normally 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 the firewall or appliance has Deep Packet Inspection capabilities, enable it if circumvention is a concern on the network.

SSTP VPNs

An SSTP VPN uses the HTTP protocol as part of its initialization process. If the HTTP connection is blocked, the VPN fails to initialize.

If the firewall supports Layer-7 filtering, create a rule to inspect all outbound 80/tcp traffic and block any HTTP_Connect headers that contain SSTP_VERSION:*.

Prevent Windows Roaming Client interference 

The Windows agent is installed as a standard MSI package. As a standard application, normal users in a Windows environment are unable to prevent the filter from running.

However, in some environments, IT allows local users to have admin privileges on their devices. While the Roaming Client cannot prevent itself from being uninstalled, there are several precautions available to prevent even administrative users from interfering with filtering policies.

Use a GPO

Apply a Group Policy Object (GPO) to prevent users from stopping the DNSFilter service.  

Remove the DNSFilter agent from Add/Remove Programs

Hide the agent with ARPSYSTEMCOMPONENT=1 to make it more difficult to remove. This method alone does not prevent the Roaming Client from being uninstalled from the command line. 

Hide the tray icon

Use the TRAYICON="disabled" flag to hide the tray icon. Hiding the tray icon makes it more difficult to troubleshoot issues that arise.