I've written instructions for one router type, but this principle may be useful for others of the same brand and even other brands of router.
I had an issue especially with mobile devices that refused to use DNS information supplied via DHCP, in general they seem to use service provider DNS information that is used by data (3G/4G) services and override wifi with it.
My aim was to get all DNS traffic to go to OpenDNS for filtering.
My firewall is a Zywall USG 50, I'm not sure how it compares with yours for features but I had to experiment to find a way to not just
#a. block DNS requests to unapproved addresses
#b. take those requests and redirect them so that the end user has a seamless experience and no reconfiguration for any devices.
In my mind I wanted a router option that simply allowed me to direct all traffic on port 53 (DNS uses TCP and UDP on this port) to a specified address, but as is often the case, manuals didn't make it obvious that this was even possible let alone how to go about it.
In the end the answer came through NAT (network address translation) rather than DNS forwarding options.
With the USG 50, DNS forwarding only really helps when a client directly requests DNS from the router itself. (*Make sure you check your router manual before you follow these tips as you may have more options than I do in this case)
In my organization I've set up an internal domain controller for DNS that forwards unknown requests externally via this router.
Using 'NAT' I needed to make sure we retained a primary + secondary DNS structure, so first of all I added a rule that passed requests to our secondary server through to the same address.
For the Zywall this was done by adding a 'Virtual Server' mapping from the internal interface 'lan1' with the original and mapped IP address+port (53) remaining the same. I named this rule 'DNSPassthrough' (rule #1).
Even though this rule doesn't actually do anything, it's important to have it in place as it prevents the next rule from overriding requests to this address.
Next I created another similar 'virtual server' rule on the same internal interface, this time referencing the primary DNS as my mapped address and original IP as 'any' rather than the 'user defined' option where you input your desired IP, again the port (53) is unchanged as in the previous rule. I named this one 'FunnelDNS' (rule #2).
Because I created the rules in this order, the priority for each meant that rule #1 is processed first and rule #2 second.
Basically, a PC making a request to either correct DNS server will be treated as before, both addresses are allowed through to their respective hosts.
Any other DNS request, regardless of destination, is sent to our primary DNS by rule #2.
The only downside is that our mobile devices affected will only ever request DNS from one address but as these are not mission critical like servers/desktop clients I considered it acceptable.
It's not just about Wi-Fi connectivity anymore. A wireless security breach can cost your business large amounts of time, trouble, and expense. Plus, hear first-hand from Miercom how WatchGuard's Wi-Fi security stacks up against the competition in our upcoming webinar!