In my latest SOP video I look at the two most common services that affect the speed and reliability of your network. Many people still hang onto the old habit of throwing everything on the server.
The best practice today - in a Windows environment - is to put the DNS service on the Windows Server and putting DHCP on the firewall or router. Here's why:
Feedback welcome, of course!
At 3:30, you say, "So, let's put an end to the debate and just serve DHCP on the firewall."
But you do not state any reasons why DHCP server on Windows Server is not desirable, other than to say, "since 2011 Microsoft has not recommended it". I don't consider that a reason. Microsoft also strongly recommends upgrading to Windows 10 for everybody and we all various opinions on THAT recommendation!
On the other hand, since Windows Server 2012, you can now setup DHCP on 2 or more servers and provide for redundancy of DHCP. Can't do that on a firewall!
Combine that with the fact that Windows DHCP server pushes dynamic information into DNS and integrates with Active Directory and I'd say it's still the best practice.
So, let's START the debate! ;-)
Any firewall you buy today should be UPnP capable. And even though a firewall might fail at any time, firewalls fail far less often than servers fail, reboot, or go down for maintenance. DHCP is a disc-intensive service. The easiest, fastest way to configure a firewall is to use UPnP from the server. The server knows which ports need to be open and which services to use. So it configures the firewall beautifully without long, complicated scripts and without leaving lots of extra ports open.ReplyDelete
If you enable the Windows servers as a DHCP server, you can use the Firewall as the primary and the server for "balancing." But in the small business environment, that's serious overkill.
All modern firewalls can serve up active directory and most will do it a lot faster than the server. Again, it just needs to be set up right.
A note about UPNP. Many small networks do not have a separate firewall with an edge router in front. In many cases, the firewall is the edge device. This is a common configuration many UTM devices, such Sophos, Sonicwall, Fortinet, Meraki, and Cisco ASA units. Enabling UPNP on the firewall is OK if there is another router in front of it, but enabling UPNP on any device that has a direct connection to an untrusted network is a serious vulnerability.Delete
UPnP used to be unsafe under these circumstances. That's not the case anymore. With any of these devices, the default setting for UPnP is that it is off until you turn it on. You then configure the router by UPnP and it turns itself off. So no one from the outside can configure it with a rogue script because they can't access it to flip the switch ON.ReplyDelete
Also, we set up routers and firewalls so they can only be configured from the internal network. So you need to remote into the server and then turn around access the router for configuration.
This comment has been removed by the author.ReplyDelete
First off, UPnP automates a process that you should be doing with planning, execution and verification. Your should never allow anything to configure your firewall, on even the smallest networks. At the very least you should be setting up static subnetting, verifying that ONLY ports that MUST be open are open, doing Geo IP filtering and Botnet filtering, setting up wireless parameters (if used) and seting up the SSLVPN remote access (again, if used). UPnP is for trunk slammers.ReplyDelete
DHCP from the firewall makes good sense if you find your firewall provides adequate options in it's configuration, including scope, exclusions, reservations, etc. and if you don't need to split or load balance your DHCP assignments across multiple servers as you can in 2012 R2, which in small business installation is unlikely to be an issue. However . . . you do give up some important advantages of using DHCP in the Windows 2012 R2 server.
The single biggest advantage of 2012 R2 (other than split DHCP) is the ability to do MAC address filtering for IP assignment (which we call the poor man's network access control). This is the ability to build a list of "acceptable" MACs to get IPs, and can therefore lock out "rogue" machines from your network. This is a wonderfully powerful feature that can prevent someone from sitting down at a network drop and simply getting a DHCP address on your network!
DNS from the DC makes all the sense in the world, but I would go a step further and advocate using a filtering DNS provider such as OpenDNS to filter out known malware sites. Simply employing sites that continuously "clean" their DNS helps prevent more malware across a broader range of attack vendors (click-bys, phishing, domain squatting) than any other single effort you can make. So yes, DNS at the server (a must w/AD), but use "clean DNS" providers upstream!
Obviously if you have larger networks or a bunch of VLANs, you may need a different solution. But just the complicated nature of devices coming out will mean that a lot more pieces of the network will be managed through UPnP.ReplyDelete
And if you can control everything from the server, then you really don't need to hand-craft everything on the firewall. If you're more comfortable with that, fine. But getting the same result by using UPnP from the server still gets you the same result.
If you only have 100 computers connected to the network and 85 of them are desktops, you don't really need to load balance DHCP in terms of lease renewals. But just running on the server will affect performance.
I think the bigger picture is to figure out where we're going and build the network you're going to have in five years. You should absolutely not be selling under-$100 "firewalls" or using the ISP router as a firewall. You should be isolating IoT devices. You should be learning UPnP and IPv6, DNSv6, and DHCPv6.
Now that IPv6 is real for more and more networks, we're going to see stomping on poorly managed DNS - both in small business and large. You gotta learn this stuff and figure how you can own this knowledge. And you don't have to do it my way. But you better a way that works as the network evolves.
Thanks for the comments.
Do you have any links from Microsoft regarding the recommendation of keeping DHCP off the server? This is the first I have heard of it and I am intrigued. My assumption with DHCP not being installed by default was Microsoft was just doing that with more and more features, where you had to turn on what you wanted to use rather than going around and shutting down everything you didn't want running.ReplyDelete
do you have any references from Microsoft why its best practice to keep DHCP off a Windows Server?
FYI - regarding DHCP. I haven't had a lot of time to look into the Microsoft reference. But here's one I happened to come across that mentions the fact that newer servers ship with DHCP disabled because the preference is to service this from the router: https://blogs.technet.microsoft.com/sbs/2011/09/22/running-dhcp-server-on-sbs-2011-essentials-with-a-static-ip/ReplyDelete