A Drip Under Pressure

I read somewhere a while ago that the word "expert" comes from a combination of the two Latin words "ex" meaning "a has-been", and "spurt" meaning "a drip under pressure". I'm not sure I actually believe it, but is does seem a remarkably fortuitous match to my capabilities when it comes to the grudge matches I regularly indulge in just trying to keep my own network running. I suppose I've rambled on about my semi-competence as a network administrator enough times in the past. It's one of those areas where you think you're starting to get the knack of it, and then you realize that it's only because you haven't yet discovered all the things you don't know.

I guess it's a bit like the famous quote from Donald Rumsfield (the US Secretary of Defence a while back), who told a Pentagon briefing that "There are known knowns; these are things we know that we know. There are known unknowns. That is to say, there are things we know we don't know. But there are also unknown unknowns. These are things we don't know we don't know." Pretty much sums up the task of network administration I reckon. I just wish I could get a list of the things I don't know that I don't know - probably there's a Web site out there with it on, but one of the things I don't know is where to find it.

Anyway, enough prevarication - time I dragged this post back to somewhere nearer to reality (or at least as near as I usually get). The background to all this is another round of network updates aimed at trying to achieve a more reliable - and faster - connection between the confines of my daily routine in a remote office perched precariously on the edge of the Internet, and the big wide world of high speed connectivity out there. In a shock announcement a few weeks ago, our Government took the bold step of announcing that they expect everyone in the country to have access to "high speed broadband" at a speed of at least 2MB by no later than 2015. I suspect they're thinking we'll catch up with countries like Japan who can get 100MB without really trying.

Well, I get about 1.6MB on a good day over my 2MB ADSL connection, so waiting till 2015 for an extra 0.4MB seems a less than attractive proposition. And I'll still only get 512K up, which is the real killer when you use VPN or need to send large documents and files. And, unless I move house to next door to the local telephone exchange, I'm not going to get anything faster over ADSL. However, our national cable company suddenly seems to have got its act together, and can now provide data connections in our area. They even offer a symmetric service, with packages from 4MB to 100MB both ways! The only hang-up is that the cheapest is around 5,000 pounds ($9,000) per year.

But they do a "business service" that's 20MB down and 1MB up for a much more realistic rate, and so I've taken the plunge and ordered it. However, I hear regular disaster tales about cable services, so I decided to keep the ADSL line as well to provide redundancy in addition to higher speed. LinkSys do a reasonably priced load-balancing and failover router (the RV042) that should do the job nicely. And it will no doubt prove to be a useful source for a forthcoming diatribe on networking for dummies.

In the meantime, it means reshuffling the existing stuff around to make room; and to reconfigure the servers to provide separate connections for the Web server and DNS, which require static IP addresses, and the main network gateway that doesn't. That way I can take advantage of load-balancing for the internal network, while leaving the stuff that needs static addresses - and isn't, in reality, very busy - on the existing ADSL line. It all seemed very simple until I started to Visio the network diagram (is Visio a verb these days?), and discovered I don't have enough network cards in the servers...

So here I can sing the praises of Hyper-V. Previously I used one NIC for the host server O/S, one for the virtual internal switch, and one for the virtual external switch (as described in Hyper-Ventilation, Act III). Now I need two separate external connections, so I reconfigured the Hyper-V network to have one virtual switch connected to the internal network NIC, and two external switches connected to the other two NICs. I took the precaution of removing the VMs from Hyper-V manager first, and - amazingly - when I re-imported them, they retained all of their IPv4 settings! OK, so they did forget all their IPv6 settings, but that's not a huge job to reconfigure. And I even moved one of the VMs from one machine to another using the Export and Import tools, and it worked a treat. I have to say that going Hyper-V certainly seems like it was a good choice.

However, I came across one issue that first raised its ugly head a while ago. Hyper-V tries to be clever and ensure that you always have a working connection in the base (host) O/S. This means that, if you have more than one NIC in the machine, you end up with multiple active connections in the base O/S - and you have to disable the ones you don't need. That's OK, but I noticed that Service Pack 2 helpfully re-enabled all of the connections without telling me, and I only found out when I got error messages saying there were duplicate machine names on the network. Now I only have one connection to the internal network, so that error will never arise. If the connections in the base O/S get enabled again by some update or other factor, I'll have active connections between the external network and the base O/S.

One saving grace is that the duplicated connections have no fixed IP address or DNS entry, and rely on DHCP, so they won't actually work because the external router doesn't support DHCP. But if they were connected directly to an ISP, that IPS's system could provide one quite happily I guess. Would you know about it? I asked some Hyper-V experts whether I should uninstall the duplicated connections in the base O/S, but they advised against it. It seems this is resolved in Server 2008 R2, but you probably want to keep your eye on your base O/S connections until you upgrade.

And Server 2008 isn't the only thing that's waiting for the software to catch up. As part of the upgrades, I replaced the somewhat limited (and nearly full) Buffalo NAS drive with a gleaming new NetGear 4TB X-RAID package to try and keep my backups (including the server VMs) safe. Guess what? Just like the Buffalo drive, it can't talk to Server 2008 Active Directory. The updated system software is in beta and I'm loathe to try that with my precious data, so I'm back to using the drive admin account in my backup batch files. As they say in the trade (though I'm not sure which trade): "Rearrange these words into a well-known phrase or saying: Your Guys Act Together Get".

Finally (yes, there is an end to this post in sight), I discovered an interesting feature of the built-in Windows standard firewall. After moving the external DNS server from the gateway server to the Web server that lives in the perimeter network, I enabled the "DNS Service" filter in the standard Windows firewall to allow access for lookups from the Internet. As usual, after any network updates, I ran a port scan to check I hadn't done anything stupid. So it was a bit of a shock to discover that port 135 (DCOM / RPC) was open. It seems it's to allow external management of the DNS server using the MMC snap-in, and only allows connections to the DNS server executable, but I'm pretty sure that's not really something I want to allow anyone and his dog to do from their spare bedroom. Yes, I know that my external router will block port 135, and they'd need to be able to log on anyway, but it seems like I should have been told this would happen.

The answer is to configure Windows Firewall With Advanced Security (on the Administrative Tools menu). It looks a bit scary, especially as - at first glance - it seems like there are tons of enabled "Allow" rules that you definitely don't want on a public machine. But if you click the Monitoring node in the tree view you should see that the Public profile is active, and so most of the enabled rules (which specify the Domain or Private profile) are not active. Click the Firewall node to see which rules actually are active. To see (and change) which profile a connection uses, open Control Panel | Network and Sharing Center and click Customize for the connection. In my case, I disabled the DNS Service filter in the standard firewall dialog and enabled the two Public rules in WFWAS for DNS Incoming - one each for TCP and UDP on port 53. A subsequent port scan found port 135 firmly closed. Back in the standard Windows firewall dialog, the DNS Service entry now displays a "shaded tick" status.

All this shows how it's a really good idea to always check every update to your network - you can use a site such as Shields Up at Gibson Research for public facing machines and routers. I actually got a "perfect TruStealth rating" from them and from a couple of other sites on one connection, so I feel like a real administrator now. Though I'm sure there'll be some new unknown unknowns to discover tomorrow...