Home | Services | About Us | Reference Area

Multiple NIC, Configure Windows Advanced Firewall

For our Small Business customers moving to Windows Server 2008, I needed some type of Plain English in-depth guide to using and configuring Microsoft's Windows Firewall with Advanced Security, especially in a Hyper-V dual NIC scenario. Since I could not find such a write-up, here is my attempt.

If you find any mistakes, have any suggestions, or just want to let me know this was useful, please use the email link on our Home Page to contact me.

As with any Microsoft technology, there are usually numerous ways to manipulate settings. Since I ended up investing a lot of time investigating just about any method I could think of to manipulate Windows Advanced Firewall settings, I have included my entire process below in the hope that others will benefit for the different approaches I experimented with.

See our Multiple NIC, Configuring WFAS, Quick Guide page to skip the background info.

Background, environment
Our Typical scenario: the Small Business Customer (SMB) has for their Operations Server (Op-Server) a Windows 2000/2003 Standard or Small Business Server (SBS) Standard edition with dual NIC's. Using the RRAS service, it was quite easy to accomplish several tasks:
- create a Virtual Private Network (VPN) from our office to the customer site, for easy remote control and administration of the workstations.
- block all inbound public traffic except: PPTP port 1723 (MS VPN) and Remote Desktop (RDP) port 3389.

The external NIC was typically behind an inexpensive router, which allowed for a DMZ and reduced attack surface of the Operating System (OS) by pin-hole forwarding just ports 1723 and 3389. For the SMB, this solution to the desired goals was reasonably affordable. It is also possible (although undesirable) to just attach the internet connection directly to the external NIC, and configure the external NIC with the public address.

The introduction of Hyper-V in Windows Server 2008 has made possible for the SMB the many advantages moving the Op-Server to a Virtual Machine (VM). With the Op-Server in a VM, remote console access to the Host OS is highly desired in case normal network access through the Op-Server becomes unavailable either because of router or cabling problems, or problems with the Op-Server.

It would also make sense that if adding the RRAS service can be avoided on a minimal Role 2008 server, we can take advantage of keeping the Host OS as a minimal install, with only the Hyper-V Role installed.

In my thinking, since most of our SMBs have a block of 5 static IP's, this should be easy:
- Connect the extra NIC on the physical server directly to the internet device (cable/DSL modem, etc.)
- In the Host OS, configure the extra NIC by assigning one of the unused static IP's and configure the firewall profile "Ultra Secure Everything Blocked Except RDP"
- Then setup the LAN NIC with a private IP and the "Private Network" firewall profile.

Bada-bing, good-to-go, nice affordable solution for the SMB!
I hear you lauging! Hey, an SMB Admin can dream, can't I?!
Silly me, trying to keep it affordable for the customer.

Microsoft does not make this easy
I am usually fine with wizards and suggestions, but the forced Network Location Awareness (NLA) feature makes locking down and administering networks a nightmare. It would seem that Microsoft's decision to make indentifying a network based on that connection's gateway is a poor choice in a multi-homed server configuration. Knowledgable IT administrators should be able to define the network profile ("Set Network Location") regardless of whether a gateway exists or not. When we are not allowed to configure our systems, I think most IT administrators chafe that Microsoft has forced settings, especially when the gaping holes created are obvious.

To make matters worse, the initial version of Server 2008 (pre-R2) does NOT allow assigning of network profiles on a per adapter basis! If the machine is a domain member, all adapters are assigned 'Domain Network' profile and all the firewall ports for domain communication are open on all adapters, no choice in the matter!! In my humble opinion, this is pathetic.

Investigating options for configuring 'Location Type' on a multi-homed server.

Keep in mind, this is for configuring a dual-homed server.

It would seem the only way to be able to define the network type is to assign a gateway to the LAN connection. The irony here is that this configuration can lead to problems, and we are even warned as such! (See the pop-up warning at right).

Now that the LAN network is no longer considered "unidentified", we can assign a network type.

Note: to assist with keeping track of the multiple network adapters, in the "Network Connections" list I rename the "Local Area Connection" name to "LAN" and "WAN" accordingly.

Clicking on the "Public Network" that now appears below for the LAN connection will now let us assign the "Work Network" profile, which appears as "Private network" in the Network and Sharing Center. The icon will also change.

Changing the Group Policy for unidentified networks
The alternative way for defining the network type is by using Group Policy to specify that an "Unidentifed Network" should be assigned "Private Network". If the server is joined to a domain, you will probably want to do this with a Domain GPO.

For a stand-alone server, the procedure is:
1. Start --> run --> gpedit.msc
2. Browse: Computer configration --> Windows Settings --> Security Settings -->
Network List Manager Policies --> Unidentified Networks
3. Change 'Location type' to: Private, click 'Ok'.

As you can see in the image at right, with the Gateway removed from the LAN configuration, the "Unidentifed Network" is now assigned the "Private Network" profile.

This is the solution I decided to go with.

Now that I had the Network Type(s) as I needed them, I set about the task of defining the Windows Firewall and Advanced Security (WFAS) profiles the way I wanted them. I wanted all traffic on the WAN interface to be blocked except RDP (port 3389). In WFAS terminology, what I wanted was: "any enabled inbound rule with Profile of 'All' change to Profile of 'Domain,Private'".

What I was NOT going to do was edit every rule individually! That would be crazy!

It is rather alarming that the 'Default' WFAS policy is to allow on a Public connection such activity as Hyper-V managment, DHCP, File and Printer share, and (judging from the portscan) netbios and RPC (I may be mis-judging here). Still, on a server, I can't imagine why by default any public ports would be open.

Important Tips:
I strongly recommend you export your current WFAS policy before making any changes!! In the WFAS snap-in, in the left pane right-click the top node "Windows Firewall and Advanced Security" > "Export Policy..." This saved my bacon for writing this up.

Also, I did not have a good experience with using the "Restore Default Policy..." option, in that there were numerous rules that disappeared as compared to the original set of rules. Apparently, "Default Policy" does not take into account if you have enabled any Roles, Features, or File sharing.

netsh Command
My first try was to attempt changing the configuration with the netsh command. What I had been able to do in the past with netsh is dump the current firewall configuration to a text file, make any tweaks using notepad giving me a chance to review carefully, then re-import the rules.

Unfortunately, with WFAS, there seems to be no way to dump the rules to a text file. I am forced to work on the rules 'live'. Using the TechNet page 'Netsh AdvFirewall Firewall Commands' as a reference, it would seem I could change rules according to certain filters. Perfect! I attempted the following commands:
----------------------------------------------------------------------------------
C:\>netsh netsh>advfirewall netsh advfirewall>set rule name=all enable=yes profile=any dir=in new profile=domain,private 'enable' is not a valid argument for this command. ----------------------------------------------------------------------------------
Error? Upon closer review of the article, 'enable' is indeed not listed before the 'new' keyword. That's a problem, I only want to change the rules that are enabled, so that rules out the netsh command as an option. Just to see if the command would work anyway, I tried to make "all inbound rules with profile of public not enabled":
----------------------------------------------------------------------------------
netsh advfirewall>set rule name=all profile=public dir=in new enable=no Updated 19 rule(s). Ok. ----------------------------------------------------------------------------------
That worked. But considering all of the default rules with profile of just public are already disabled, this does not do me much good (after reviewing the default rules, I purposely chose this command in that nothing would actually change). I could maybe try to change all profile=all rules to just profile=Domain,Private, but that would also change the not enabled rules, which I would rather not do. Clearly, better filtering is needed.

Changing WFAS with VBScript
One of the most annoying features of the WFAS management snap-in, is the left-right scrolling required to see all of the columns of information (it sure would be nice if the Actions Pane was stacked on the left under the WFAS pane, to gain a little more screen real estate). Additionally, I am typically Remote Desktop into the server. So despite my having dual monitors, I usually use a desktop size of 1152 x 864, which is not wide enough to display all the columns of information in WFAS (another nice touch would be for Remote Desktop to be dual monitor aware, and let me use the screen size slider to span both my monitors, say about 2000 or 2500 pixels wide with the slider, it's a bit of a pain to make an RDP file then go edit the screen width manually in the RDP file).

I decided exporting all the WFAS settings to Excel would be nice for opening on my local workstation, so that I could easily span both monitors and thus see all columns at once. Microsoft has a nice sample VBScript for displaying all WFAS properties, it didn't take much to create a tweaked Script for enumerating all the current rules to a tab-delimited file.

Example:
----------------------------------------------------------------------------------
C:\>cscript //Nologo C:\TestScripts\JEnumFWRules.vbs > C:\TestScripts\EnumFW.txt ----------------------------------------------------------------------------------
I copied the text file to my local network, then dropped the file into Excel. Now I had the ability to "Freeze Panes", sort, and span two monitors with all the WFAS rule information.

Note: I saved all sample scripts here as ".txt" files, you will need to save them as ".vbs".
Disclaimer: Use sample scripts at your own risk! You should export current WFAS settings first!

Going back to my original goal, "allow RDP only" on external interface, I was now able to use VBScript to quickly make the desired changes. There were two stategies I could use to block all public traffic using the existing rules:
- Change all "enabled" rules with "Profile=All" to "Profile=Domain,Private" (my preference).
- Optionally, first copy all "enabled" rules with "Profile=All" to "enabled=no & Profile=Public"
(I was thinking the second option would be nice for retaining which rules were originally "Profile=All", but I have since decided too many rules are created).

For setup purposes, I also prefer to allow ICMPv4 response to Ping (there does not appear to be a rule for ICMPv4 ping, so I needed to add a rule). I made a VBScript that "enables existing Remote Desktop rule, and adds rule to allow ICMPv4 ping".

With careful review of the rules using the WFAS tool, these changes were made perfectly! I also performed a port scan on the reconfigured interface, and now the only port responding was RDP (3389), happy day!.

Summary
I fully recognize that with powerful features, the complexity increases. There are enough failings of WFAS that it would seem improvement is needed. In my humble opinion, properly managed security should NOT involve resorting to hacks and scripts to get a multi-homed server configured. The chance for unintended consequences and mis-configuration elevates when resorting to these non-interface methods. Hopefully, Microsoft will recognize these shortcomings and improve WFAS through an update or Service Pack.

Needed Changes to Network and Sharing Center, Windows Firewall with Advanced Security, and related tools
(in my humble opinion, of course)
- Allow pre-R2 machines to define the network profile on a per adapter basis. urgent!
- Allow manual setting of Network Location, without a gateway assigned.
- Align terms!

(very annoying when searching for an option, and the option is worded different in another window)
- Profile = Set Network Location
- Work Network = Private Network
- (on Windows Firewall window) Advanced Settings = Windows Firewall with Advanced Security - Adapter Settings = Network Connections

- In netsh advfirewall mode, allow filtering by: "enable=yes"
- When exporting the Inbound Rules to CSV, change any commas to another character.
- Allow dump of all netsh advfirewall rules in text format for importing, like we can for netsh.
- With "add rule", allow "group="
- When drag/dropping one rule on to another, allow "Undo"!! (what is this functionality, anyway?)
- Allow assigning/changing of Group to new/changed rules.
- Fix the COM object: 'INetFwRule::LocalPorts Property' to allow value of 'IPHTTPS'.
- Create a "Network List" API, to allow manipulation of "Network Category" from VBScript.

Mildly related suggested tweaks:
- When navigating within the Network and Sharing Center window, allow right-click "Open in new window"
- When using Avanced Sharing on a server, the default permissions should be for group "Administrators", not "Everyone".
- When many columns of information appear in an MMC snap-in, allow the first column to be "frozen" from the left-right scrolling (Excel style).
- Remote Desktop could be dual-monitor aware, to allow easy connection with a window that spans both monitors.

References:
Microsoft Technet Reference, Netsh Commands for Windows Firewall with Advanced Security
Better left unspoken, Using Netsh advfirewall
dimeby8, Change ‘Unidentified network’ from Public to Work in Windows 7
Microsoft Technet Reference, Unidentified network / default gateway
Microsoft Technet Reference, VBScript, Displaying all WFAS Properties

Quick Links, WFAS scripts:

- Enumurate all Rules to a tab-delimited file.
- Change all enabled rules where "profile=all" to "profile=domain, private".
- Copy all enabled rules where "profile=all" to "profile=public" and disable.
- Enable RDP and Ping.
- Enable Ping.
- Enable SQL Server 2008 Remote Management.