After you have been diligent enough to configure pfSense to act as a DNS server, it would be a shame if end users on your network could circumvent pfSense and specify whatever DNS server they want. Yet that’s exactly what most modern OSes allow the end user to do. The following screenshot shows part of the IPv4 configuration page in a recent version of Mint Linux:

As you can see, the end user has disabled automatic DNS configuration and specified one of the Google DNS servers instead. Thus, even if we have set up pfSense to act as the DNS server for the local network, the user's computer will bypass pfSense and go directly to 8.8.4.4. Other than the fact that the user is subverting the policy we were trying to enforce, this is bad for a number of reasons:

• Every time the user accesses a site that requires a new DNS lookup, their computer will only cache the results on his computer. If the user had used pfSense as his DNS server, the results of the lookup would be cached on the pfSense system, and therefore would be available to everyone else on the local network.
• The user could specify a DNS server whose security has been compromised, and their computer would now be vulnerable to DNS cache poisoning and other attacks.

Fortunately, there are ways of preventing this sort of end user behavior. Although we have not covered firewall rules yet, it might prove useful to demonstrate how such rules can be used to block users from manually specifying a DNS server.

We know that DNS uses port 53 to communicate, so rules blocking or allowing port 53 traffic is what we need. Specifically, we need the following:

• A rule allowing port 53 traffic on the LAN network whose destination is a LAN node.
• A rule blocking all other port 53 traffic on the LAN network.

We begin by creating the rule allowing port 53 traffic to a LAN node. Using the top menu in the web GUI, navigate to Firewall | Rules and click on the LAN tab. There should already be at least two rules there: default Allow LAN to any rules for IPv4 and IPv6, respectively. Since firewall rules are applied from top to bottom with the first rule encountered that applies to the traffic being applied, we want to create a rule above those rules. Otherwise, pfSense will apply one of the Allow LAN to any rules first to the DNS traffic, which will defeat the purpose of our rule. Therefore, we click on the green +Add button with an up arrow next to the word Add to create a rule at the top of the list.

We want this rule to allow traffic, so we leave the Action set to Pass. We know that DNS traffic uses the UDP protocol, so we set Protocol to UDP. Scrolling down, we leave the Source set to Any, but we want to change the Destination to LAN address.

We want to change the Destination port range to port 53, and we can do that either by selecting it in the From drop-down box, or by just typing 53 into the first Custom edit box. You can enter a brief description in the Description edit box (for example, Allow DNS to LAN nodes) and then click on the Save button, which will return us to the main Firewall page and the rules table for LAN.

We still need a rule to block all other DNS traffic. Actually, what we will be doing is creating a rule that blocks all DNS traffic on the LAN network and placing it after the rule we just created so that all DNS traffic on the LAN network whose destination is not a LAN address will be blocked. It will be easiest to modify the rule we just created, so navigate to the rule in the table and, in the Actions column, click on the icon that looks like two sheets of paper to copy the rule. This will create a duplicate of the rule, which we can now modify. Change Action to either Block or Reject, and change Destination to any. You probably also want to change the Description (for example, Block all DNS). That is all you need to do, then click on Save.

When you return to the main Firewall page, make sure that the rule for allowing DNS traffic to a LAN node comes before the block DNS rule. If the order is incorrect, you can drag and drop the rules until they are in the correct order. When you are done, click on the green Apply Changes button at the top right of the page.

You probably want to confirm that the rules we added do what they are supposed to do, so go ahead and use nslookup to try to look up a domain name using a different server. The nslookup utility is available on Linux, Windows, and macOS, and by specifying a domain name as the first parameter and a DNS server as the second parameter, you can bypass the default DNS server, for example:

nslookup packtpub.com 8.8.4.4

The preceding command will do a DNS lookup for packtpub using one of the Google DNS servers. If the rules we created work, this should fail, while invoking the same command when omitting the second parameter (so nslookup will use the default DNS server) should work.

These rules can be fairly effective in preventing the end user from bypassing the pfSense DNS server, but there are at least two major flaws:

• The rules only apply to the LAN network. On a larger network, there will be several network segments. We want a means of applying these rules to more than one network.
• The end user can still defeat the rules we created by connecting to a VPN.

We will revisit these issues in Chapter 6, Firewall and NAT.