Setup Best Practices

This article addresses recommended network configurations, preventing circumvention of DNSFilter, and more.

Network DNS Configuration (DNS Forwarders)
- Firewall: 512-byte Limitation
Don't Mix DNS Providers 
- Preventing Circumvention
--> Transparent DNS Redirection (3rd-party DNS)
--> Block SSL VPNs
--> Block IPSec, L2TP, OpenVPN, and PPTP VPNs
--> Block SSTP VPNs

Network DNS Configuration (DNS Forwarders)

The following 3 examples represent the most common ways to deploy DNSFilter on a network.

No DNS Forwarders

A common setup, wherein DNS servers are distributed by the DHCP settings, or set directly on the computer's networking settings. No DNS forwarders are utilized.

Use Cases:

  • Guest Wi-Fi
  • No LAN Resources (printers, servers, resource sharing)
  • Utilizing the NAT IPs feature

Router as a Forwarder

A common setup, which allows the router / DHCP server to store local DNS names for local resources, such as servers, computers, printers, etc, via DNS names.

Use Cases:

  • Home / Personal
  • Small Offices
  • No Local Authentication (Active Directory, LDAP, Radius, etc)

Local DNS Forwarder (Active Directory)

The most common setup for businesses, schools, and large networks. If you're using local authentication, or have any other need for a local DNS forwarder.

Use Cases:

  • Business
  • Corporate
  • Schools
  • Local Authentication (Active Directory, LDAP, Radius)

Firewall: 512-byte limitation

The DNS protocol originally had a 512-byte maximum packet size. Modern usage of the DNS protocol can sometimes require a packet size up to 4096 bytes.
If the firewall is set to block/drop DNS packets less than 4096 bytes, this could result in DNS timeouts.

Don't Mix DNS Providers

DNS contacts recursive DNS servers in a  round-robin methodology, which means that an endpoint with more than one DNS server in the local configuration may use any DNS server at random. The only supported and effective way to configure DNS on your network (endpoint, router, firewall, or DNS forwarder), is to only point DNS to, and, with no tertiary or quaternary DNS servers being utilized.

Preventing Circumvention

There a number of ways to circumvent DNSFilter's content filtering. The following aims to assist networkadministrators with blocking the most common methods.

Note: VPNs are a common and legitimate business and security tool; blocking VPNs is not always the best solution for every network; use good judgement.

Transparent DNS Redirection (3rd-party DNS)

Without a compensating firewall rule, an endpoint using 3rd-party DNS servers, such as OpenDNS or Google, will be able to circumvent your content and security filtering configured in DNSFilter.



In order to prevent endusers from utilizing 3rd-party DNS servers, implement a compensating firewall rule in your network's firewall which will transparently redirect any outbound DNS request to DNSFilter.
Using iptables, the most common firewall on Linux systems, the rules in a config file look like this:
-A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination
-A OUTPUT -p tcp -m tcp --dport 53 -j DNAT --to-destination
Or, using the command line to add the rules:
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to
There are several ways to accomplish this, but this is the simplest. You firewall may offer additional options, suchas destination-based round robin, that would allow you to enter multiple destinations and therefor load balance the two DNSFilter AnyCast IPs (,
To test this, add a domain to your  Blacklist  in the   Dashboard , then perform a DNS lookup with nslookup or dig .

Copy the resulting IP address when querying DNSFilter for the domain, and type it into your browser to make sure it's the IP of a block page.

Then perform an nslookup using google's DNS. If your transparent DNS redirection rule is working correctly, it should actually be querying DNSFilter, and also returning the DNSFilter block page IP address.



Prevent SSL VPNs with Deep-Packet Inspection (DPI)

One of the most common ways to get around DNS-based content filtering is by using an SSL VPN, which often connects over one of the following ports (TCP or UDP):

  • 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, it's likely that most SSL VPNs will not connect. Testing is always encouraged.

Prevent IPSec VPNs with Firewall

One of the most common ways to get around DNS-based content filtering is by using a VPN. Unlike SSL VPNs, these VPN types usually use standardized ports, which normally can be blocked in the firewall without affecting any applications or services:
  • IPSec: 500/udp, 4500/udp 
  • L2TP: 1701/tcp
  • PPTP: 1723/tcp
  • OpenVPN: 1149/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 highly recommend to enable it if circumvention is a concern on your network.

Prevent SSTP VPN with Layer-7 Firewall

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:*"

Questions, concerns, inaccurate information? Contact support.

Still need help? Contact Us Contact Us