This post will be of interest to you if you require more comprehensive and flexible DHCP and local DNS services than might be available through your DSL router, and you have a FreeNAS server on your network.
On the network I am working with, there is a Fritz!Box providing a basic DHCP/DNS service to a local network made up predominantly of Windows PCs. For this post, I’ll be working with Fritz!OS 06.98-50796 BETA, FreeNAS 11.1-U4 and DNSMasq 2.79. Some working knowledge of the Fritz!Box and FreeNAS is assumed.
I love my FRITZ!Box! I think what I love about it most is that it’s feature-rich, but doesn’t require you to have a great deal of knowledge and expertise in order to tap into a broad range of its advanced features. Having said that, it’s surprising that it is lacking in the software in several key areas including the ability to act as a VPN client, and limited DHCP/DNS functionality. The latter is of interest here.
The FRITZ!Box is a closed system. Its DHCP server isn’t able to support WINS clients. While the local DNS server is very cleverly front-ended with a graphical web UI, it is virtually impossible to get behind that GUI to do some fairly basic tasks such as clearing the DNS cache. With earlier versions of the FRITZ!OS, it was possible to telnet into the FRITZ!Box, but that avenue has long been closed off.
In a previous post, I had set up WINS to support the computer browser service, but had to manually configure network adapters on client machines to become WINS aware. This is clumsy for anything more than a handful of Windows PCs noting that if any of those machines have several adapters such as an ethernet port and a wireless adapter, each would have to be configured separately. Even with a small number of PCs, it’s still easy to miss an adapter.
What if you have more than a handful of WINS capable clients to configure? Is it possible to WINS-enable clients automatically from a central location? On a more selfish note, ‘Is it possible to complement the functionality of the FRITZ!Box without having to replace it?’.
My research led me to DNSMasq software, which can provide network services including local DNS, DHCP, TFTP and network boot for small networks. It appeared ideal for home and small business environments.
The primary objective was to implement a DHCP server that could support my WINS clients. The idea was to turn off the DHCP server on my Fritz!Box and use DNSMasq on FreeNAS to provide more sophisticated DHCP services. The key steps to achieve this objective were:
- Rethink the DHCP approach.
- Alter the DHCP range on the Fritz!Box.
- Install and start DNSMasq on FreeNAS.
- Configure DNSMasq to provide a DHCP/DNS service to support WINS clients.
- Disable the DHCP server on the Fritz!Box.
- Refine the DHCP/DNS service to support non-WINS clients.
- Reconfigure clients with static addresses to reference the new DNS server.
Step 1: Rethink the DHCP approach
Home and small businesses are unlikely to have more than 50 DHCP clients consisting of a mix of computers, tablets, phones and printers. An address range of 50 addresses should suffice for this number of clients. Even with more clients, if your workforce is largely mobile, this address range may still be adequate if you use a shorter DHCP lease period. Otherwise, extend the address range out.
Referring to the table below, the first 50 addresses on my network I’ve used for fixed IP addresses. I’ve previously used the remainder for DHCP. The second lot of 50 addresses I’ve reserved for future use. The third group of 50 addresses will be used by the Fritz!Box to deliver a backup DHCP service that is not WINS aware. In case FreeNAS is unable to provide DHCP services, the DHCP server in the Fritz!Box can be turned on to provide leased addresses in this third range of addresses. The impact of using addresses in this range is an increase in broadcast traffic on the subnet as a consequence of not using WINS for name resolution. In the redesign, I’ll use the fourth lot of 50 addresses for an enhanced DHCP service using DNSMasq on FreeNAS. This group of addresses will be WINS aware.
The reason for partitioning addresses in this way is to avoid a conflict if both DHCP services are running simultaneously. If both DHCP servers were supplying addresses in the same range, it is possible that the same address could be leased by each DHCP server to two different machines resulting in unpredictable client behaviour. With the partitioning scheme described, it is possible to have both DHCP servers running. There’s little point in doing so though as the whole idea of implementing enhanced DHCP services is to minimise broadcast traffic by making client machines WINS aware.
Step 2: Alter the DHCP range for the Fritz!Box
I set the DHCP lease period to one day (default is 10 days) to cater for the event that the DHCP server on the Fritz!Box is temporarily switched into service while the FreeNAS server is out of action. This will ensure that within a day of the server being reinstated, broadcast traffic should again be minimised. Find the relevant settings on the Fritz!Box console under Home Network > Network > Network Settings > IPv4 Settings. Don’t forget to click OK to save the changes.
Fire up a Windows DHCP client and check its network connection details. You should be able to cross-reference what you see with the settings on the Fritz!Box DHCP server.
Here we see one of the annoying gotchas with the Fritz!Box DNS. It forces the local domain to be fritz.box and there is no way to change this.
Step 3: Install and start DNSMasq on FreeNAS
Create a jail (Jails > Add Jails > Advanced Mode) for FreeNAS and give it a name and IP address. Scroll to the bottom of the dialogue box, and click OK.
Shell into the jail…
…and install the DNSMasq package by executing the following command within the shell:
pkg install dnsmasq
I prefer Nano over the standard FreeNAS editing tools, so I’ve installed that within the jail as well. This is an optional step. Choose whatever editor takes your fancy.
pkg install nano
To start DNSMasq when the jail starts, add the following line to the file /etc/rc.conf.
Now exit the shell and restart the jail to make sure DNSMasq starts correctly when the jail starts.
Check by shelling back into the jail and executing the command sockstat. You should see a screen similar to that shown below. Look for dnsmasq under the COMMAND column.
Step 4: Configure DNSMasq to provide a DHCP service to support WINS clients.
The DNSMasq configuration file is located in /user/local/etc within the jail.
Rename the supplied configuration file. We will start with a blank file.
mv dnsmasq.conf dnsmasq.conf.original
There are some global parameters to set up first. Add the following lines to a new configuration file. Refer to this post for an explanation of the parameters.
domain-needed bogus-priv domain=lan expand-hosts local=/lan/ listen-address=127.0.0.1,10.1.1.25 bind-interfaces
Of particular interest, domain=lan replaces fritz.box with lan as the local domain name. Also, the loopback and jail addresses are specified in listen-address.
Just four parameters are required to set up DNSMasq as a WINS aware DHCP server.
dhcp-range=10.1.1.151,10.1.1.200,255.255.255.0,24h dhcp-option=option:router,10.1.1.1 dhcp-option=option:dns-server,10.1.1.25 dhcp-option=option:netbios-ns,10.1.1.20
The parameter dhcp-range=10.1.1.151,10.1.1.200,255.255.255.0,24h sets the range of 50 available DHCP addresses from 10.1.1.51 to 10.1.1.100 with a network mask of 255.255.255.0 and a lease period of one day. Where there are only a small number of DHCP clients, I’d probably consider a longer lease period of say 10 days (240h). Having a shorter lease period will result in more DHCP traffic. However, I figure that this DHCP traffic will be inconsequential compared to the reduction in broadcast traffic arising from turning the DHCP clients into WINS clients.
The parameter dhcp-option=option:router,10.1.1.1 specifies the Fritz!Box as the gateway/router. The parameter dhcp-option=option:dns-server,10.1.1.25 specifies DNSMasq as the DNS server. The parameter dhcp-option=option:netbios-ns,10.1.1.20 identifies the WINS server.
The next few lines tell DNSMasq the upstream nameservers to forward Internet DNS requests to. Your ISP or public name servers can be specified here. I’ve used OpenDNS and Google name servers in the example below.
server=126.96.36.199 server=188.8.131.52 server=184.108.40.206 server=220.127.116.11
After completing and saving your edits, exit the shell and restart DNSMasq to read the configuration file. At this point, DNSMasq actively participates as a DNS and DHCP server for the local network.
Step 5: Disable the DHCP server on the Fritz!Box
Finally, switch off the DHCP server on the Fritz!Box. On the Fritz!Box console, under Home Network > Network > Network Settings > IPv4 Settings, uncheck Enable DHCP server. Don’t forget to click OK to save the changes.
Fire up a Windows DHCP client and check its network connection details. You should find that the client is now receiving its settings from DNSMasq on the FreeNAS server.
Broadcast traffic will begin to reduce over the next 24 hours as DHCP clients acquire new leases from the FreeNAS DHCP server that will turn them into WINS clients.
Step 6: Refine the DHCP/DNS service to support non-WINS clients
Some non-Windows DHCP clients don’t have a hostname. You can associate a hostname with their MAC address. For example:
Add hostnames for hosts with static IP addresses. For address, names with and without the domain suffix should be included. For reverse lookup, use ptr-record.
Once you’ve added the parameters to the configuration file, restart the service for these to take effect.
I found an early version of SolarWinds IP Address Tracker invaluable in identifying hosts on the network without a hostname.
Step 7: Reconfigure clients with static addresses to reference the new DNS server
This step will be a device-specific. The screenshot below is for a FreeNAS server.
Interested in using DNSMasq on a DD-WRT router instead? Or just want to know how similar or different it is to the FreeNAS implementation? Or want to use it to add a backup DHCP/DNS service to your network? Then check out my other post DHCP/DNS Server using DD-WRT.
Edit (27 Feb 2019): For DNSMasq to successfully start within an IOcage jail under FreeNAS 11.2 or above, the property Berkeley Packet Filter must be checked. More detail here.
Edit (17/12/2019): Specific DNSMasq inclusions.
The following lines were first suggested in DNSMasq 2.79.
# If a DHCP client claims that its name is "wpad", ignore that. # This fixes a security hole. see CERT Vulnerability VU#598349 dhcp-name-match=set:wpad-ignore,wpad dhcp-ignore-names=tag:wpad-ignore
# For secure Plex connections. rebind-domain-ok=/plex.direct/
For completeness, here is the equivalent entry in the Frtiz!Box.
- Fritz!Box: Delete DNS cache
- Access to the FRITZ!Box via Telnet is not supported
- FreeNAS/dnsmasq – MattWiki
- Restarting jail fails to autostart dnsmasq service
- Run command on jail start
- Dnsmasq For Easy LAN Name Services
- DNSMasq as DHCP Server
- Dynamic Host Configuration Protocol
- Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters
- SolarWinds IP Address Tracker (early version)
- DHCP/DNS Server using DD-WRT
- DNSMasq fails to start in 11.2-U2
- Plex – How to Use Secure Server Connections
- Plex – Icon meaning