How Windows Firewall Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

Windows Firewall Terminology

Windows Firewall Architecture

Windows Firewall Interfaces

Windows Firewall Protocols

Windows Firewall Connection Types

Windows Firewall Service Dependencies

Windows Firewall Physical Structures

Windows Firewall Processes and Interactions

Windows Firewall is a stateful host-firewall technology that inspects and filters all IP version 4 (IPv4) and IP version 6 (IPv6) network traffic. As a stateful firewall, Windows Firewall tracks the state of each network connection and determines whether the unsolicited incoming traffic should be allowed or dropped. Windows Firewall blocks incoming traffic unless the traffic is a response to a request by the host (in which case, it is solicited traffic) or it is specifically allowed (in which case, it has been added to the Windows Firewall exceptions list). Exceptions can be specified by program name, UDP or TCP port number, or system service name. Aside from a few Internet Control Message Protocol (ICMP) messages, Windows Firewall allows all outgoing traffic.

Windows Firewall Terminology

Before you review the components and processes that are associated with Windows Firewall, it is helpful to understand Windows Firewall terminology.

Domain profile

A set of Windows Firewall settings that are applied when a computer is connected to a network that contains the domain controllers for the domain in which its computer account resides. The domain profile is one of two profiles used by Windows Firewall to apply settings to a computer.

Exception

A port, program, or system service that is allowed to receive unsolicited traffic.

Exceptions list

A rules store that specifies which ports, programs, or system services are allowed to receive unsolicited traffic. To allow unsolicited incoming traffic through Windows Firewall, you add ports, programs, and system services to the exceptions list.

Notification

A Windows Security Alert dialog box that appears when a program that is not listed in the exceptions list attempts to listen for unsolicited traffic on a port. If you have administrative rights on a computer, the notification displays the option to add the program to the exceptions list, which will allow the program to receive unsolicited traffic. If you do not have administrative rights on a computer, the notification displays a warning that a program is attempting to listen on a port.

A Windows Security Alert dialog box does not appear when a system service attempts to listen for unsolicited incoming traffic; it appears only when a program attempts to listen for unsolicited incoming traffic.

Port

A logical communication endpoint representing a program or a system service that listens for and receives IP packets. Ports are specified by a positive 16-bit decimal number and by the type of traffic (either UDP or TCP) that is expected to pass through the port. Most ports are predefined and well-known for specific services, such as DHCP and DNS. However, some ports are created dynamically by a server and assigned to the programs and system services that need to listen for incoming traffic from clients.

Program

A software program that is usually started by a user and runs under the user's account. Programs run only while the user is logged on to a computer and usually consist of one or more executable (.exe) files and one or more dynamic-link library (.dll) files.

Scope

A Windows Firewall setting that you configure for an exception. The scope setting controls from which addresses unsolicited traffic is allowed to originate. By default, the scope of an exception is any address, which includes any computer on the Internet. You can change the scope of an exception to locally reachable addresses or a list of individual IPv4 addresses or IPv4 address ranges.

Standard profile

A set of Windows Firewall settings that are applied when a computer is not connected to a network that contains the domain controllers in which its computer account resides (for example, a public network, such as the Internet). The standard profile is one of two profiles used by Windows Firewall to apply settings to a computer.

System service

A software program that is usually not started by a user and runs under a privileged account, such as LocalSystem. System services run even when a user is not logged on to a computer and usually run as a separate process within Svchost.exe.

Windows Firewall Architecture

Windows Firewall relies on several networking components, including the Windows Firewall/Internet Connection Sharing service (also known as the SharedAccess service), the network address translation (NAT) driver (Ipnat.sys), the IPv4-based TCP/IP driver (Tcpip.sys) and the IPv6-based TCP/IP driver (Tcpipv6.sys), and the Windows Sockets (Winsock) driver (Winsock.dll). Windows Firewall also relies on several administrative tools that allow you to configure Windows Firewall settings. The following figure shows the relationship among these components.

The following describes each of the architectural components.

Administrative tools

There are several administrative tools that interact with the Windows Firewall/Internet Connection Sharing service and allow you to configure Windows Firewall settings. These tools include Windows Firewall in Control Panel (Firewall.cpl), the netsh firewall command, and Group Policy with the Group Policy Object Editor.

NAT driver

The NAT driver (Ipnat.sys) provides a data store for Windows Firewall. Windows Firewall uses the data store, known as the NAT Mapping Table, to store connection state information for dynamically-created exceptions. The connection state information typically consists of a 5-tuple entry, which includes the protocol, the source and destination port numbers, and the source and destination IP addresses. Without a data store, Windows Firewall would not be a stateful firewall.

TCP/IP driver

The TCP/IP driver (Tcpip.sys) controls the flow of information between a network adapter and a program or system service. As incoming traffic flows through the TCP/IP driver, the traffic is inspected by the NAT driver. The NAT driver processes the traffic based on the entries in the Windows Firewall exceptions list. If the traffic matches an exception, the NAT driver determines that the traffic is allowed; the packets continue through the TCP/IP driver. If the traffic does not match an exception, the NAT driver determines that the traffic is unsolicited; the packets are dropped and do not continue through the TCP/IP stack. Neither the NAT driver nor the TCP/IP driver sends a notification to the sender when packets are dropped (this is sometimes referred to as a silent discard).

Winsock driver

The Winsock driver is responsible for assigning and binding ports to a program or system service. Programs and system services use this driver when they need to listen for incoming traffic.

Windows Firewall/Internet Connection Sharing service

The Windows Firewall/Internet Connection Sharing service runs in Svchost.exe. The Windows Firewall/Internet Connection Sharing service is responsible for processing the Windows Firewall exceptions that you configure for network traffic. The Windows Firewall/Internet Connection Sharing service then relays the exceptions to the NAT driver, which inspects the traffic that is flowing through the TCP/IP driver.

Winsock driver

The Windows Firewall/Internet Connection Sharing service provides all of the processing (filtering) that determines whether unsolicited incoming traffic is allowed or dropped.

Windows Firewall Interfaces

There are two interfaces related to Windows Firewall: the firewall-hook interface and the Windows Firewall application programming interfaces (APIs). The following figure shows these interfaces and how they relate to Windows Firewall components.

The firewall-hook interface is used by the TCP/IP driver to communicate with Windows Firewall, which instructs the TCP/IP driver about how to process incoming and outgoing packets. There should be only one firewall-hook interface on Windows XP and Windows Server 2003 operating systems because it is not recommended that software developers implement a firewall-hook driver on these operating systems. To provide additional firewall functionality on Windows XP and Windows Server 2003, software developers should create a Network Driver Interface Specification (NDIS) intermediate miniport driver to manage packets sent and received across a firewall. For information about firewall-hook drivers, see MSDN (https://go.microsoft.com/fwlink/?LinkId=45023).

The Windows Firewall APIs provide a public interface for programmatically configuring Windows Firewall settings. Windows Firewall APIs and Internet Connection Sharing (ICS) APIs are implemented in Hnetcfg.dll. Using the Windows Firewall API, you can:

• Enable and disable Windows Firewall.

• Add and remove programs and system services from the exceptions list.

• Add and remove TCP and UDP ports from the exceptions list.

• Enable and disable preconfigured system service exceptions.

• Configure ICMP settings.

• Configure the log file.

The following table describes the Windows Firewall APIs.

Interface	Description
INetFwOpenPort	Provides access to the properties of a port opened in Windows Firewall.
INetFwOpenPorts	Provides access to a collection of ports opened in Windows Firewall.
INetFwService	Provides access to the properties of a service that may be authorized to listen through Windows Firewall.
INetFwRemoteAdminSettings	Provides access to the settings that control remote administration.
INetFwServices	Provides access to a collection of services that may be authorized to listen through Windows Firewall.
INetFwAuthorizedApplication	Provides access to the properties of a program that has been authorized to open ports in Windows Firewall.
INetFwAuthorizedApplications	Provides access to a collection of programs authorized to open ports in Windows Firewall.
INetFwIcmpSettings	Provides access to the settings that control ICMP packets.
INetFwProfile	Provides access to a Windows Firewall settings profile.
INetFwPolicy	Provides access to a Windows Firewall policy.
INetFwMgr	Provides access to the Windows Firewall settings for a computer.

For more information about Windows Firewall APIs, see MSDN.

Windows Firewall Protocols

Windows Firewall provides the stateful filtering of TCP/IP traffic (IPv4 and IPv6) that uses the TCP transport protocol. It also provides the “pseudo-stateful” filtering of TCP/IP traffic that uses the UDP transport protocol. ICMP traffic is not statefully filtered; rather, ICMP traffic is allowed or blocked based on Windows Firewall settings (for example, you can explicitly allow or deny incoming echo requests or outgoing destination unreachable messages by configuring Windows Firewall settings). Because Windows Firewall is tied directly to the TCP/IP architecture of Windows, it does not provide any filtering of non-TCP/IP protocols, such as IPX/SPX or AppleTalk.

With the exception of some File Transfer Protocol (FTP) traffic, Windows Firewall does not use Application layer information to statefully filter traffic. FTP is a special case because of the way in which an FTP server establishes the data channel for an FTP file transfer. During a typical FTP user session, an FTP client initiates a control channel with an FTP server. When the FTP client transfers a file from the FTP server, the FTP server tries to establish a data channel with the FTP client by initiating communication on a TCP port different from the one used for the control channel. This can cause most firewalls running on the FTP client computer to drop the data channel packets coming from the server because they appear to be unsolicited. To overcome this problem, Windows Firewall uses the Application Layer Gateway Service to provide dynamic port mapping for the FTP data channel, thereby facilitating the stateful filtering of FTP traffic.

Although Windows Firewall does not use Application layer information to statefully filter traffic, Windows Firewall does use Application layer information to identify and manage some traffic.

IPv6 Tunneled Traffic

IPv6 tunneled traffic is an IPv6 packet that has been encapsulated with an IPv4 header so that hosts that support both IPv4 and IPv6 can communicate using IPv6 even when separated by an IPv4 infrastructure, such as the Internet or a private intranet. The tunneled IPv6 packet bypasses the IPv4 processing of Windows Firewall. However, after the IPv4 header of the packet is removed, the decapsulated IPv6 packet is processed by Windows Firewall just like all other IPv6 traffic.

AH/ESP

IPsec uses two transforms, the Authentication Header (AH) and the Encapsulating Security Payload (ESP) header and trailer, to encapsulate and secure IP packets or payloads. These transforms wrap the IP payload with header or header and trailer information and provide security properties, such as data origin authentication, data integrity, data confidentiality, and replay protection.

Traffic protected with AH or ESP is processed by the IPsec components of Windows before it is processed by Windows Firewall. The IPsec components validate the security information in the AH or ESP header and trailer, decrypt the payload if needed, and remove the AH or ESP header and trailer. The resulting IP packet is handed back to the TCP/IP driver, which is then handed to Windows Firewall for processing. However, you can change this behavior so that IPsec-secured traffic bypasses Windows Firewall by configuring the Windows Firewall: Allow authenticated bypass Group Policy setting. When you enable this setting, you specify groups of IPsec-secured computers whose traffic bypasses all Windows Firewall processing and overrides any existing policies or settings that would otherwise block the traffic.

GRE

The Generic Routing Encapsulation (GRE) protocol is used to encapsulate the data channel of Point-to-Point Tunneling Protocol (PPTP) traffic. Any PPTP traffic that uses a GRE header to encapsulate Point-to-Point Protocol (PPP) frames will pass directly through Windows Firewall. Non-PPTP traffic that uses GRE is filtered by Windows Firewall.

IGMP

Internet Group Management Protocol (IGMP) is an IP multicast maintenance protocol. IP multicast provides the one-to-many delivery of traffic without the overhead and performance impact that is associated with broadcast delivery and multiple unicast delivery. IP multicast is used primarily for audio and video teleconferencing and gaming. Hosts and routers send IGMP messages so that IP multicast-enabled routers can determine the set of multicast host groups that have members on a subnet. All IGMP traffic passes directly through Windows Firewall.

PGM

The Pragmatic General Multicast (PGM) protocol is a scalable multicast protocol that enables receivers to detect loss, request retransmission of lost data, or notify a program of unrecoverable loss. PGM is often referred to as reliable multicast; it is a receiver-reliable protocol, which means the receiver is responsible for ensuring all data is received, absolving the sender of reception responsibility. Any traffic that uses the PGM protocol passes directly through Windows Firewall.

Windows Firewall Connection Types

Windows Firewall can be bound to any network connection that is listed in Network Connections in Control Panel. This includes the following connection types.

Local area connections

This includes wired and wireless network connections that use Ethernet, Token Ring, cable modem, 1394, Digital Subscriber Line (DSL) modem, Fiber Distributed Data Interface (FDDI), IP over Asynchronous Transfer Mode (ATM), and WAN technologies such as T1 and Frame Relay.

Dial-up connections

This includes network connections that use X.25, modem, and Integrated Services Digital Network (ISDN) technologies.

VPN connections

This includes virtual private networking (VPN) connections that use PPTP or Layer Two Tunneling Protocol (L2TP).

Incoming connections

This includes incoming connections that use dial-up (modem, ISDN, X.25) and VPN (PPTP, L2TP). However, Windows Firewall settings for incoming connections can only be configured globally. You cannot configure Windows Firewall settings on a per-connection basis for incoming connections.

Windows Firewall Service Dependencies

Windows Firewall runs in the Windows Firewall/Internet Connection Sharing service and is dependent on several subsidiary services. If any of the subsidiary services are not running or cannot be started, Windows Firewall might not start or run properly. Windows Firewall depends on the following services.

Application Layer Gateway Service

The Application Layer Gateway Service (sometimes known as the ALG service) is required if you enable Windows Firewall on a computer that is an FTP client or FTP server that does not use PASV FTP. The Application Layer Gateway Service listens for outgoing FTP traffic from an FTP client. It then extracts the port from which the FTP client is expecting to receive data and creates an appropriate dynamic port mapping for the FTP data channel.

The Application Layer Gateway Service and Windows Firewall interact as follows:

• If the Application Layer Gateway Service is disabled and you try to enable Windows Firewall, Windows Firewall will start, but FTP traffic that does not use PASV FTP might fail.

• If you stop the Application Layer Gateway Service while Windows Firewall is running, Windows Firewall will continue to run, but FTP traffic that does not use PASV FTP might fail.

• If the Application Layer Gateway Service is stopped and its startup type is set to Manual, then the Application Layer Gateway Service will attempt to start when you enable Windows Firewall.

DCOM Server Process Launcher

The DCOM Server Process Launcher service (sometimes known as the Dcomlaunch service) is new in Windows Server 2003 with Service Pack 1 (SP1); it is responsible for starting all DCOM-related services. Because Windows Firewall relies on DCOM, the DCOM Server Process Launcher service must be running when you start Windows Firewall.

The DCOM Server Process Launcher service and Windows Firewall interact as follows:

• If the DCOM Server Process Launcher is disabled and you try to enable Windows Firewall, Windows Firewall will not start because the Windows Firewall/Internet Connection Sharing service cannot start.

• You cannot stop the DCOM Server Process Launcher service, so it is not possible to configure the DCOM Server Process Launcher service if it is started and Windows Firewall is enabled.

• If the startup type for the DCOM Server Process Launcher service is set to Manual, and the DCOM Server Process Launcher is not started, you will not be able to enable Windows Firewall. If you attempt to enable Windows Firewall, a Windows Firewall dialog box will be displayed to indicate that another process that requires the network address translation driver (Ipnat.sys) is running.

Network Connections

The Network Connections service (sometimes known as the Netman service) manages all network connections that are created and configured in Network Connections in Control Panel. This service is also responsible for displaying network status in the notification area on the desktop (the area on the taskbar to the right of the taskbar buttons). Windows Firewall uses this service to identify and manage network connections.

The Network Connections service and Windows Firewall interact as follows:

• You cannot enable Windows Firewall if the Network Connections service is disabled.

• If you stop the Network Connections service while Windows Firewall is enabled, Windows Firewall will stop running and become disabled.

• If the Network Connections service is stopped and its startup type is set to Manual, the Network Connections service will attempt to start when you enable Windows Firewall. If the Network Connections service cannot start, Windows Firewall cannot be enabled.

Network Location Awareness

The Network Location Awareness service (sometimes known as the Nla service) collects and stores network configuration information, such as changes to the names and locations of IP addresses and domain names. The Network Location Awareness service component supports the Network Location Service, which provides the infrastructure that informs programs and the operating system of the network connections on a computer. Windows Firewall uses the Network Location Awareness service to determine which Windows Firewall profile to use.

The Network Location Awareness service and Windows Firewall interact as follows:

• If the Network Location Awareness service is disabled and you try to enable Windows Firewall, Windows Firewall will start but cannot determine which profile to use. In this case, Windows Firewall uses the settings for the standard profile.

• If you stop the Network Location Awareness service while Windows Firewall is running, Windows Firewall continues to run and use the settings for the profile that it is currently using.

• If the Network Location Awareness service is stopped and its startup type is set to Manual, then the service will attempt to start when you enable Windows Firewall.

Remote Procedure Call

The Remote Procedure Call service (sometimes known as the RpcSs service) is a secure interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality that resides in a different process. That different process can be on the same computer, on the local area network (LAN), or across the Internet. The Remote Procedure Call service serves as the RPC Endpoint Mapper (EPM) and Service Control Manager (SCM).

The Remote Procedure Call service and Windows Firewall interact as follows:

• You cannot enable Windows Firewall if the Remote Procedure Call service is disabled.

• If you stop the Remote Procedure Call service while Windows Firewall is enabled, Windows Firewall will stop running and become disabled.

• If the Remote Procedure Call service is stopped and its startup type is set to Manual, then the service will attempt to start when you enable Windows Firewall. If the Remote Procedure Call service cannot start, Windows Firewall cannot be enabled.

Windows Management Instrumentation

Windows Management Instrumentation (WMI) is an infrastructure for building management programs and instrumentation released as part of the current generation of Microsoft operating systems. The Windows Management Instrumentation service (sometimes known as the Winmgmt service) provides a common interface and object model to access management information about operating system, devices, programs, and system services. Windows Firewall uses the Windows Management Instrumentation service to store per-connection settings and legacy (ICF) settings.

• You cannot enable Windows Firewall if the Windows Management Instrumentation service is disabled.

• If you stop the service while Windows Firewall is enabled, Windows Firewall will stop running and become disabled.

• If the service is stopped and its startup type is set to Manual, then the service will attempt to start when you enable Windows Firewall. If the Windows Management Instrumentation service cannot start, Windows Firewall cannot be enabled.

Windows Firewall Physical Structures

Windows Firewall relies on two physical structures: the NAT Mapping Table, which contains information about the traffic passing through a network connection, and a rules store, which contains the configuration settings (rules) that are used to filter traffic. The state table allows Windows Firewall to track the activity of a given network connection; it is the mechanism that makes Windows Firewall a stateful firewall. The rules store provides a persistent data store for Windows Firewall configuration settings; it is the mechanism that Windows Firewall uses to apply consistent filtering rules to a network connection.

NAT Mapping Table

Windows Firewall uses the NAT Mapping Table to store the state of network connections. The NAT Mapping Table is managed by the NAT driver (Ipnat.sys) and is used by both Windows Firewall and Routing and Remote Access to store connection information.

TCP Connections

TCP connections are stored in a standard 5-tuple entry format in the NAT Mapping Table. The 5-tuple entry consists of the following data:

• Protocol. This is either TCP or UDP.

• Source address. This is the IP address of the host that initiated the communication session.

• Source port. This is the TCP or UDP port number that the host used to initiate the communication session.

• Destination address. This is the IP address of the computer with which the host initiated traffic.

• Destination port. This is the TCP or UDP port number to which the host sent traffic.

A 5-tuple entry is created in the NAT Mapping Table for every incoming communication session that uses TCP. A separate mapping table is maintained for each network connection (for example, if you have two network adapters in a computer, there is a mapping table for each network adapter). The timeout for established but inactive TCP connections is 24 hours. In other words, the state table entry for an inactive TCP connection remains in the NAT Mapping Table for 24 hours unless the connection is terminated and closed using the standard TCP close sequence.

UDP Connections

UDP connections that use ports 1 through 1024 are also stored in the standard 5-tuple entry format in the NAT Mapping Table. The 5-tuple entry is the same as the entry used for TCP connections. The 5-tuple entry is used to track UDP connections on ports 1 through 1024 because these ports are usually designated for use by specific operating system services. Using a 5-tuple entry to store the state of all connections to these ports decreases the likelihood of an attack on these critical system services.

UDP connections that use ports higher than 1024 are stored in a 3-tuple entry format in the NAT Mapping Table. The 3-tuple format, sometimes known as loose source mapping, consists of the following data:

• Protocol. This is always UDP.

• Source address. This is the IP address of the host that initiated the communication session.

• Source port. This is the UDP port number that the host used to initiate the communication session.

A 3-tuple entry is created in the NAT Mapping Table for every incoming communication session that uses a UDP port greater than 1024. A separate mapping table is maintained for each network connection (for example, if you have two network adapters in a computer, there is a mapping table for each network adapter).

Because UDP is a connectionless protocol and has no sequence numbers or flags, it has no mechanism for terminating and closing a connection. Therefore, the timeout for UDP connections is much shorter than that for TCP connections. The timeout for established but inactive UDP connections is 60 seconds. In other words, if an established UDP connection is inactive for 60 seconds, the state table entry for that connection is removed from the NAT Mapping Table. This behavior applies to UDP connections on all ports.

There are some exceptions to the 60-second timeout for UDP connections. When a computer sends a multicast or broadcast message, Windows Firewall waits for up to 3 seconds for a unicast response. In essence, the state table entry for multicast or broadcast connections is maintained for up to 3 seconds; if the multicast or broadcast connection is inactive for 3 seconds (that is, there is no response), then the state table entry is deleted from the NAT Mapping Table. Dynamic Host Configuration Protocol (DHCP) multicast messages are a special case and are exempt from the 3-second timeout.

ICMP Traffic

The Windows Firewall state table does not store any information about ICMP traffic. Incoming ICMP traffic is accepted or rejected according to the configured Windows Firewall ICMP settings.

Rules Store

A rules store contains the list of rules used by a firewall to determine whether unsolicited incoming traffic is allowed or blocked. A typical rules store is created around the notion of “implicit deny,” which means that all unsolicited incoming traffic is blocked (denied) unless there is an explicit rule allowing the traffic through the firewall. Furthermore, a typical rules store is processed sequentially from top to bottom: that is, the firewall compares the characteristics of unsolicited incoming traffic against each rule, one at a time, until a rule is found that allows the traffic (in which case, the traffic passes through the firewall) or the end of the rules list is reached (in which case, the traffic is blocked). Creating and maintaining this type of rules store can be difficult because the order of the rules is important and it is relatively easy to create a rule that inadvertently allows all traffic through the firewall.

Windows Firewall uses the notion of implicit deny, but it does not use a strictly sequential or ordered rules store. When you turn on Windows Firewall in its default configuration, all unsolicited incoming TCP and UDP traffic is blocked. In other words, you must create explicit rules to allow unsolicited incoming traffic to pass through Windows Firewall. However, you do not need to create the rules in any particular order because the rules are not processed sequentially.

In most cases, the rules used by Windows Firewall to filter unsolicited incoming traffic are a union of the Windows Firewall settings you configure using Windows Firewall in Control Panel, the netsh firewall command, local Group Policy settings, and domain-based Group Policy settings. You cannot configure ordered rules or rules that specify a precedence for specific protocols, ports, programs, or IP addresses. The only time the resultant rules are not determined by a union of all settings is when Group Policy settings conflict with settings that you configured locally through Windows Firewall in Control Panel or the netsh firewall command. In this case, the resultant rules are still determined by a union, but the domain-based Group Policy settings take precedence over any locally-configured settings (including local Group Policy settings) and the local Group Policy settings take precedence over settings configured through Windows Firewall in Control Panel and the netsh firewall command.

Windows Firewall stores its rules in two locations in the registry:

HKLM\Software\Policies\Microsoft\WindowsFirewall

This subkey contains the settings you configure through Group Policy (both local Group Policy and domain-based Group Policy).

HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy

This subkey contains the settings you configure through Windows Firewall in Control Panel, the netsh firewall command, and scripts.

Windows Firewall Processes and Interactions

This section describes how Windows Firewall processes network traffic and the way in which Windows Firewall interacts with other operating system components.

Windows Firewall and Post-Setup Security Updates

By default, Windows Firewall and the Windows Firewall/Internet Connection Sharing service are turned off in Windows Server 2003 with SP1. However, there are instances when Windows Firewall and the Windows Firewall/Internet Connection Sharing server are turned on automatically on a temporary basis. This occurs when the Post-Setup Security Updates feature runs. The Post-Setup Security Updates feature is designed to reduce the risk of a new server being attacked from the time it is first connected to the network until the most recent security updates are installed from Windows Update. The new feature appears in the graphical user interface as a single dialog box the first time a member of the Administrators group logs on to a new server. The dialog box provides links for installing current security updates and configuring automatic updates. In addition, the Post-Setup Security Updates feature temporarily turns on Windows Firewall, which blocks all inbound connections other than those that are specifically opened during setup or by policy. When you close the Post-Setup Security Updates dialog box, Windows Firewall is turned off.

Post-Setup Security Updates is available only when you perform a clean installation of Windows Server 2003 with SP1, including slip-stream installations. You cannot run Post-Setup Security Updates from the Start menu or from the command line (it starts automatically), and it is not available when:

• Windows Firewall is enabled or disabled during setup by using an unattended installation answer file or a Netfw.inf file.

• Windows Firewall is enabled or disabled through Group Policy before the Post-Setup Security Updates dialog box appears.

In addition, Post-Setup Security Updates is not available when you upgrade an existing Windows Server 2003 operating system by adding a service pack or if you upgrade a Windows 2000 Server operating system to Windows Server 2003 with SP1.

What Happens When Post-Setup Security Updates Is Closed?

If Windows Update or any other configuration change causes your computer to restart before you click the Finish button on the Post-Setup Security Updates dialog box, it reopens the next time an administrator logs on to the server.

If you close the Post-Setup Security Updates dialog box using ALT+F4 or Task Manager, no change is made to the configuration of Windows Firewall. The tests the server uses to determine whether the Post-Setup Security Updates dialog box should be displayed run again the next time a user logs on.

If you close Post-Setup Security Updates by clicking the Finish button on the Post-Setup Security Updates dialog box, the following occurs:

• If you did not change any Windows Firewall settings while the Post-Setup Security Updates dialog box was displayed, a confirmation dialog box appears explaining that inbound connections will now be opened and giving you the opportunity to confirm that you are done with any post-setup security updates. When the action is confirmed, Post-Setup Security Updates attempts to disable Windows Firewall and stop and disable the Windows Firewall/Internet Connection Sharing service.

• If Windows Firewall is disabled successfully, a registry value is set to suppress Post-Setup Security Updates in the future. It is possible that Windows Firewall is disabled successfully, but the attempt to stop the Windows Firewall/Internet Connection Sharing service fails.

• If Windows Firewall settings cannot be changed, a dialog box appears explaining that no changes will be made to inbound connection settings. Post-Setup Security Updates is not suppressed and the tests to determine whether Post-Setup Security Updates should be displayed will be run again the next time a user logs on.

• If Windows Firewall was explicitly enabled or disabled while the Post-Setup Security Updates was displayed, a dialog box appears indicating that no changes will be made to inbound connection settings. These changes could have been made by Group Policy settings or by opening Windows Firewall in Control Panel and clicking OK to confirm the firewall settings. A registry value is set to suppress Post-Setup Security Updates in the future.

• If the Windows Firewall/Internet Connection Sharing service was stopped or disabled while the Post-Setup Security Updates dialog box was displayed, a dialog box appears indicating that no changes will be made to inbound connection settings. A registry value is set to suppress Post-Setup Security Updates in the future.

• If Internet Connection Sharing was enabled while the Post-Setup Security Updates dialog box was displayed, a confirmation dialog box appears indicating that inbound connections will now be opened and giving you the opportunity to confirm that you are done with any post-setup security updates. When the action is confirmed, Post-Setup Security Updates attempts to disable Windows Firewall and stop the Windows Firewall/Internet Connection Sharing service.

• If the state of the firewall cannot be determined, a dialog box appears indicating that no changes will be made to inbound connection settings. Post-Setup Security Updates is not suppressed and the tests to determine whether the Post-Setup Security Updates dialog box should be displayed will be run again the next time a user logs on.

When Is the Post-Setup Security Updates Dialog Box Displayed?

Because the Post-Setup Security Updates feature runs automatically and cannot be started manually, you can use the following information to determine whether Post-Setup Security Updates will run on your server:

Test Question	Answer=Yes	Answer=No
Is the logged-on user an administrator?	Continue to the next test.	Skip the remaining tests and do not display the Post-Setup Security Updates dialog box. These tests run again the next time a user logs on.
Is this is a new installation of a version of Windows Server 2003 that includes Service Pack 1 (not an upgrade)?	Continue to the next test.	Skip the remaining tests and do not display the Post-Setup Security Updates dialog box. The registry value is set to suppress Post-Setup Security Updates in the future.
Has Post-Setup Security Updates been suppressed in the registry?	Skip the remaining tests and do not display the Post-Setup Security Updates dialog box.	Continue to the next test.
Is the Windows Firewall/Internet Connection Sharing service running?	Continue to the next test.	Repeat this test for two minutes. If the service has still not started, do not display the Post-Setup Security Updates dialog box. These tests are run again the next time a user logs on.
Has Windows Firewall been explicitly enabled or disabled for the current Windows Firewall profile? (Windows Firewall may have been enabled or disabled using an unattended-setup script at the time of installation or through the application of Group Policy settings or by opening Windows Firewall in Control Panel and clicking OK to confirm the settings.)	Skip the remaining tests and do not display the Post-Setup Security Updates dialog box. A registry value is set to suppress Post-Setup Security Updates in the future.	If Windows Firewall is enabled and the user did not enable it, display the Post-Setup Security Updates dialog box. If the status of Windows Firewall cannot be determined, do not display the Post-Setup Security Updates dialog box. These tests are run again the next time a user logs on.

Startup Protection

Because there is a brief period of time during startup when a computer is connected to a network but Windows Firewall is not yet running, Windows Firewall uses a special startup policy that allows it to perform stateful packet filtering while your computer is starting. The startup policy, which you cannot configure, allows your computer to perform basic networking startup tasks using DHCP and the DNS service to communicate with a domain controller to obtain Group Policy updates. The startup policy is in effect only until the Windows Firewall/Internet Connection Sharing service starts, at which time Windows Firewall uses its user-configured settings and discards the special startup policy settings.

Windows Firewall Filtering

When an incoming packet reaches your computer, Windows Firewall inspects the packet and determines whether it meets criteria specified in the Windows Firewall exceptions list (the combination of the NAT Mapping Table and the Windows Firewall rules store). If the packet matches an entry in the list, Windows Firewall passes the packet to the TCP/IP protocol for further processing. If the packet does not match an entry in the list, Windows Firewall silently discards the packet and creates an entry in the Windows Firewall log file (if the log file is enabled on the Log Settings dialog box in Windows Firewall). The entries in the exceptions list can consist of program names, system service names, TCP ports, and UDP ports. There is no way to create an entry in the exceptions list based on the IP Protocol field in the IP header.

There are only two conditions under which traffic can pass through Windows Firewall:

• When the incoming traffic corresponds to a recent outgoing request, in which case the response traffic is then considered incoming solicited traffic.

An example of this occurs when a DNS Name Query Request message is sent to a DNS server. Windows Firewall adds an entry to the NAT Mapping Table so that the corresponding DNS Name Query Response message sent by the DNS server can be passed to the TCP/IP protocol for further processing.

• When you configure Windows Firewall for exceptions, in which case you allow a computer using Windows Firewall to accept unsolicited incoming traffic when acting as a server, a listener, or a peer.

An example of this occurs when your computer is acting as a Web server. In this case, you must configure Windows Firewall to allow Web traffic so that the computer can respond to requests from Web clients. To do this, you configure an exception, which becomes a rule in the Windows Firewall rules store. You can configure exceptions based on specific programs, in which case the ports required by the program are opened and closed dynamically according to the program’s needs, or on TCP or UDP ports, in which case the ports are opened even if the programs or system services are not using them.

Windows Firewall Profile Determination

Windows Firewall filters traffic according to the settings that are stored in one of two profiles: the domain profile or the standard profile. Windows Firewall uses a network determination algorithm to determine which profile to use.

The network determination algorithm uses connection-specific DNS suffix information to determine whether a computer is connected to a managed network containing the domain in which the computer is a member. To do this, the algorithm compares the following DNS suffix information:

• The last-received Group Policy update DNS name. This is stored in the HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName registry entry and represents the connection-specific DNS suffix of the connection over which the last Group Policy update was received.

• The connection-specific DNS suffixes of the currently connected connections (those that are assigned an IP address) that are not Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP)-based, such as dial-up or VPN network connections.

Using this DNS suffix information, the algorithm performs the following analysis:

• If the computer is not a member of a domain, then the computer is always attached to another network.

• If the last-received Group Policy update DNS name matches any of the connection-specific DNS suffixes of the currently connected connections on the computer that are not PPP or SLIP-based, then the computer is attached to a managed network.

• If the last-received Group Policy update DNS name does not match any of the connection-specific DNS suffixes of the currently connected connections on the computer that are not PPP or SLIP-based, then the computer is attached to another network.

Windows Server 2003 uses this network determination process during startup and when it is informed by the Network Location Awareness service that network settings on the computer have changed. To determine which profile to use, Windows Firewall applies this network determination process as follows:

• If the connection-specific DNS suffix of a currently connected connection on the computer that is not PPP or SLIP-based (such as an Ethernet or 802.11 wireless network adapter) matches the value of the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName registry entry, Windows Firewall uses the domain profile.

• If the connection-specific DNS suffix of a currently connected connection on the computer that is not PPP or SLIP-based does not match the value of the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName registry entry, Windows Firewall uses the standard profile.

Although this network determination algorithm works well in most situations, configuration variations can cause Windows Server 2003 to determine that it is always attached to the managed network or create temporary configuration problems when roaming between different portions of the same managed network that assign different DNS suffixes with DHCP.

Always Attached to the Managed Network

The connection-specific DNS suffix of the connection over which the last set of Group Policy updates were received is determined from its TCP/IP configuration, which is typically configured using DHCP and the DNS Domain Name DHCP option (DHCP option number 15). You can also manually configure connection-specific DNS suffixes.

If the connection-specific DNS suffixes for the computer's connections are manually configured, then the manually-specified value overrides the value from the DNS Domain Name DHCP option. If the manually-configured DNS suffix matches the last-received Group Policy update DNS name, then Windows will always determine that the computer is attached to the managed network.

This can create a problem for Windows Firewall Group Policy settings if an administrator configures Group Policy settings so that Windows Firewall is disabled when the computer is attached to the managed network (this practice is highly discouraged unless another host-based firewall is being used) and Windows Firewall is enabled when the computer is attached to another network. If Windows Server 2003 always determines that the computer is attached to the managed network, Windows Firewall will be disabled when the computer is attached to the Internet, thereby making the computer accessible to network attacks.

Roaming Between Different Portions of the Same Managed Network

Temporary network determination problems can also occur when computers roam between portions of a managed network that assign different DNS domain names using DHCP.

For example, a laptop computer with only a wireless LAN connection is a member of the noam.corp.example.com Active Directory domain. DHCP servers in all of the offices of the organization in North America assign the DNS name noam.corp.example.com. However, in Europe, the Active Directory domain is europe.corp.example.com and the DNS servers assign the DNS name europe.corp.example.com. When the user connects a laptop computer to the wireless network in an office in Europe, the computer's last-received Group Policy update DNS name no longer matches the DNS suffix of the computer's wireless connection and Windows determines that the laptop computer is on another network, even though the laptop computer is connected to a portion of the managed network.

However, this condition lasts only as long as it takes for Group Policy settings to be updated. When the computer updates Group Policy settings, the last-received Group Policy update DNS name is reset to the new connection-specific DNS suffix and the computer is then determined to be on the managed network.

Continuing our example, the laptop computer updates Group Policy settings from a domain controller in the noam.corp.example.com domain and the last-received Group Policy update DNS name is set to europe.corp.example.com, which now matches the connection-specific DNS suffix of the wireless connection. When the network determination algorithm is run again, it determines that the computer is connected to a managed network.

The workaround for this issue is to have all of the DHCP servers in an organization assign a common DNS domain name, rather than a region-specific DNS domain name. For our example, the workaround is to have all the DNS servers assign the name "example.com." Therefore, the last-received Group Policy update DNS name will always match the connection-specific DNS suffix of a LAN connection that is attached to the organization network.

The problem of temporarily determining that the computer is on another network when it is actually on the managed network can also occur with the following configurations:

• The DNS Domain Name DHCP option is changed, assigning a domain suffix that does not match the last-received Group Policy update DNS name.

• The DNS Domain Name DHCP option is removed, resulting in a blank connection-specific DNS suffix for the computer's LAN connection.

• The connection-specific DNS suffix for the computer's LAN connection is manually configured and does not match the last-received Group Policy update DNS name.

Scope Resolution

Scope settings define from which addresses incoming traffic is allowed to originate for a specific exception. By default, exceptions have unrestricted scope, which means that exceptions apply to all unsolicited incoming IPv4 and IPv6 traffic no matter from where the traffic originates. You can change this default behavior and restrict the scope of an exception by using the My network (subnet) only scope option or by using the Custom list scope option. The My network (subnet) only scope option changes the default behavior so that an exception applies only to unsolicited incoming traffic that originates from an IPv4 or IPv6 address that is directly reachable from your computer. The Custom list scope option changes the default behavior so that an exception applies only to specific IPv4 addresses or a range of IPv4 addresses. You cannot use the Custom list scope option to specify an IPv6 address or a range of IPv6 addresses.

Resolving Directly Reachable Computers

When you use the My network (subnet) only scope option to restrict the scope of an exception, Windows Firewall does not perform any IP configuration testing or subnet mask interpretation to determine whether the traffic is coming from a computer that is a neighbor on a locally attached subnet. Instead, Windows Firewall queries the IPv4 and IPv6 routing tables to determine whether the source IPv4 or IPv6 address of the incoming packet can be reached directly. You can see all destinations that are considered directly reachable by typing the route print command at a command prompt. For the IPv4 routing table, all IPv4 addresses that match the routes in which the IPv4 address of the Gateway column equals the IPv4 address of the Interface column are considered directly reachable. For the IPv6 routing table, all IPv6 addresses that match routes in which the Gateway column is set to On-link are considered directly reachable. Therefore, the set of directly reachable addresses depends on your networking configuration, as specified by the IPv4 and IPv6 configuration of LAN-based connections (such as Ethernet and 802.11 wireless), dial-up connections, and broadband Internet connections. In some Internet configurations, all destinations are considered directly reachable.

For example, for a computer that is directly connected to a private home network only, the set of directly reachable unicast addresses is confined to those that match the IPv4 network ID of the private subnet. If the network connection is configured with an IPv4 address of 192.168.0.99 with a subnet mask of 255.255.0.0, only traffic from IPv4 addresses in the range 192.168.0.0 to 192.168.255.255 is allowed.

In another example, for a computer that is directly connected to both a private home network and the Internet through a cable modem, the set of directly reachable unicast addresses are those that match either the network ID of the private subnet or the subnet of the cable modem provider. For example, if the private network connection is configured with an IPv4 address of 192.168.0.1 and a subnet mask of 255.255.0.0 and the cable modem connection is configured with an IPv4 address of 131.107.17.211 and a subnet mask of 255.255.255.0, traffic received by either network connection is allowed from IPv4 addresses in the ranges from 192.168.0.0 to 192.168.255.255 and from 131.107.17.0 to 131.107.17.255.

Resolving Specific IP Addresses and Address Ranges

When you use the Custom list scope option to restrict the scope of a exception, you must provide a list of specific IPv4 addresses or a list of IPv4 address ranges (which usually correspond to subnets).

The IPv4 addresses are specified in dotted decimal notation; each address is separated by a comma. IPv4 address ranges are specified using a dotted decimal subnet mask or a prefix length; each address range is separated by a comma. A dotted decimal subnet mask is typically specified as an IPv4 network ID (such as 10.47.81.0/255.255.255.0) or by an IPv4 address within a range (such as 10.47.81.231/255.255.255.0). A network prefix length is typically specified as an IPv4 network ID (such as 10.47.81.0/24) or an IPv4 address within the range (such as 10.47.81.231/24).

Windows Firewall will ignore any IPv6 addresses or IPv6 address ranges that you add to the Custom list scope option.