With lots of different devices now using our networks, we would like to keep them safe. We can prevent users from being a risk to themselves and others while attached to our system. Especially if we are offering guest Wifi services via the captive portal on a firewall.
Being able to corral the DNS requests to a known (and preferably sanitising) DNS server would be useful. We can ensure that nefarious sites are not reachable via DNS and helps reduce the risk to our guests. Let’s look at how we can deliver this.
We’ll perform NATting of DNS traffic from the Guest subnet to our local DNS server. For the example screens, we’ll use the OpnSense firewall. (The same configuration can also be applied to the pfSense firewall, as well as similar processes for other firewalls).
Set up aliases for internal and external DNS services
To make this extensible, we create a couple of aliases on the firewall. The first is DNS_Internal_Servers, which provides the host IP addresses of our internal DNS forwarding server(s). The second is forDNS_External_Servers, which contains the IP addresses for the external DNS services to which we are forwarding requests.
Setup port forwarding for DNS traffic not already targeting our internal server
We then add a Port Forward rule on our Guest WiFi subnet. This will redirect traffic not already destined for our internal DNS servers to them. (Remember, if we have a well-behaved client, it will have picked up and used the correct DNS servers in the firstplace via DHCP).
To do match the traffic not already destined fot the DNS_Internal_Servers, by using the Invert match check box. We apply a port match on the destination for the DNS service (port 53).
Then we redirect the traffic to the DNS Servers (we can use an alias for this, and specify how to distribute the traffic). We want to keep clients on the same server to take full advantage of any caching effects that may occur.
We don’t need to provide a firewall rule for DNS here. We’re capturing all the traffic to the servers with the NAT rule. Doing so would be counterproductive, as the firewall will drop the packets before the NAT rule kicks in.
Firewall rules to corral DNS traffic
We must remember that our local DNS server needs to access the Internet itself to perform the resolution of the names passed to it. So we allow traffic outbound from the DMZ to the Internet for the specific external DNS servers. We also need to make sure we let our responses back to our clients as well.
Next we create a rule to pass traffic from our DNS_Internal_Services to the DNS_External_Servers on port 53.
We then add a rule on the DMZ port (where we locate our DNS servers) to block queries from these to unrecognised servers. This becomes the ‘braces’ to the ‘belt’ of the DNS server forwarding configuration.
Notes on privacy
With the upcoming requirement for GDPR, it would be good to make sure that you inform your users that logging of their DNS queries may occur. The logging can occur both on the firewall, on the DNS server itself, and with the external DNS provider as well. Check to see if there is a GDPR compliant privacy notice available from the external provider.
Options and enhancements
If you have a locally installed DNS server on the firewall, then you must set this to bind and accept queries on the localhost IP address (127.0.0.1). This then needs to be coded as the single IP address in the DNS_Internal_Servers alias, or directly coded in the port-forwarding and firewall rules.
We can also avoid the a local DNS server, and direct the traffic straight to our external servers in the cloud, if minimising local infrastructure is a concern. In this case, we’d use the port forwarding directly against the DNS_External_Servers alias.
We could also cover the use of DNS over HTTP versions using things like the experimental DOH-Proxy. DOH-Proxy could prevent the DNS queries not caught by our port-forwarding rules above to be captured and redirected to a safe DNS server.
I’ll leave this is an exercise for you to conduct in your own time, and for me to complete in the future.
