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.
5.3.181415.1237 
Unrestricted Freeware 
Windows XP (SP2), Vista, Windows 7
LibreOffice
Firefox
OpenSUSE
