Share via

The Cable Guy - June 2005

  • Article

TCP/IP Packet Processing Paths

TechNet's The Cable Guy

By The Cable Guy

With the inclusion of Windows Firewall in Microsoft® Windows® XP Service Pack 2 and Windows Server 2003 Service Pack 1 and the growing use of Internet Protocol security (IPsec) in organization intranets, information technology (IT) professionals need to know how unicast Internet Protocol (IP) packets are processed by the TCP/IP protocol and its associated components in Windows. Detailed knowledge of the IP packet processing path can make it easier to understand how to configure and troubleshoot packet processing and filtering components.

This article describes the following:

  • The basic architecture of the TCP/IP protocol for IP version 4 and the additional components that process packets.

  • The packet processing path for unicast traffic sent, received, and forwarded by Windows-based computers.

Note To simplify the discussion, this article does not describe multicast, broadcast, fragmented, or tunneled packets.

TCP/IP Architecture for Packet Processing

The following figure shows a simplified view of the TCP/IP protocol driver (Tcpip.sys) and its associated components that process IP packets in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1.

If your browser does not support inline frames, click here to view on a separate page.

The following components process IP packets:

  • IP forwarding Determines the next-hop interface and address for packets being sent or forwarded.

  • TCP/IP filtering Allows you to specify by IP protocol, TCP port, or UDP port, the types of traffic that are acceptable for incoming local host traffic (packets destined for the host). You can configure TCP/IP filtering on the Options tab from the advanced properties of the Internet Protocol (TCP/IP) component in the Network Connections folder.

  • Filter-hook driver A Windows component that uses the filter-hook API to filter incoming and outgoing IP packets. On a computer running Windows Server 2003, the filter-hook driver is Ipfltdrv.sys, a component of Routing and Remote Access. When enabled, Routing and Remote Access allows you to configure separate inbound and outbound IP packet filters for each interface using the Routing and Remote Access snap-in. Ipfltdrv.sys examines both local host and transit IP traffic (packets not destined for the host).

  • Firewall-hook driver A Windows component that uses the firewall-hook API to examine incoming and outgoing packets. On a computer running Windows XP, the firewall-hook driver is Ipnat.sys, which is shared by both Internet Connection Sharing and Windows Firewall. Internet Connection Sharing is a basic network address translator (NAT). Windows Firewall is a stateful host-based firewall. Ipnat.sys examines both local host and transit IP traffic. On a computer running Windows Server 2003, Ipnat.sys is shared by Internet Connection Sharing, Windows Firewall, and the NAT/Basic Firewall component of Routing and Remote Access. If the NAT/Basic Firewall component of Routing and Remote Access is enabled, you cannot also enable Windows Firewall or Internet Connection Sharing.

  • IPsec The IPsec component, Ipsec.sys, is the implementation of IPsec in Windows to provide cryptographic protection to IP traffic. Ipsec.sys examines both local host and transit IP traffic and can permit, block, or secure traffic.

Packet Processing Paths

The following sections describe the specific packet processing paths for:

  • Source traffic Originated by a Windows-based sending host.

  • Destination traffic Arriving at the final Windows-based destination host.

  • Transit traffic Forwarded by a Windows-based IP router.

This discussion only includes components that are provided with Windows Server 2003 or Windows XP and does not include Windows Sockets layered service providers or NDIS intermediate miniport drivers.

Source Traffic

The following figure shows the packet processing path for source traffic.

If your browser does not support inline frames, click here to view on a separate page.

  1. After the IP packet has been formed, Tcpip.sys passes it to the firewall-hook driver, Ipnat.sys, for processing.

    Windows Firewall checks whether the traffic is a specific type of Internet Control Message Protocol (ICMP) message that Windows Firewall is designed to block. If the ICMP message is blocked, Windows Firewall discards the packet.

    Windows Firewall checks whether the traffic is Point-to-Point Tunneling Protocol (PPTP) tunnel maintenance traffic. If so, Windows Firewall analyzes the traffic to determine the Generic Routing Encapsulation (GRE) Call ID that identifies the specific PPTP tunnel so that incoming GRE-based traffic for the PPTP tunnel is allowed.

    If needed, Windows Firewall adds a dynamic entry to the exceptions list so that the response traffic will be allowed.

    After processing, Ipnat.sys passes the IP packet back to Tcpip.sys, which uses the IP forwarding component to determine the next-hop IP address and interface. For more information, see Understanding the IP Routing Table.

  2. Tcpip.sys passes the packet to the filter-hook driver, Ipfltdrv.sys, for processing.

    Based on the next-hop interface, Ipfltdrv.sys compares the packet to the configured outbound IP packet filters.

    If the outbound IP packet filters do not allow the packet, Ipfltdrv.sys silently discards the packet. If the outbound IP packet filters allow the packet, Ipfltdrv.sys passes the packet back to Tcpip.sys.

  3. Tcpip.sys passes the packet to Ipsec.sys for processing.

    Based on the set of IPsec filters, Ipsec.sys determines whether the packet is permitted, blocked, or secured. If permitted, Ipsec.sys passes the packet back to Tcpip.sys without modification. If blocked, Ipsec.sys silently discards the packet. If secured, Ipsec.sys adds the appropriate IPsec protection to the packet before handing it back to Tcpip.sys. For more information about IPsec filters, see IPsec Filter Ordering, the February 2005 The Cable Guy article.

    Tcpip.sys then sends the packet over the next-hop interface to the next-hop IP address.

Destination Traffic

The following figure shows the packet processing path for destination traffic.

If your browser does not support inline frames, click here to view on a separate page.

  1. After receiving the IP packet, Tcpip.sys passes it to Ipsec.sys for processing.

    If the packet has IPsec protection (the IP Protocol field value indicates either Authentication Header [AH] or Encapsulating Security Payload [ESP]), it is processed and removed. If the Windows Firewall: Allow authenticated IPSec bypass Group Policy setting applies and the computer was the responder in the IPsec security negotiation, Ipsec.sys sets an IPsec Bypass flag associated with the packet. Ipsec.sys passes the resulting packet back to Tcpip.sys.

    If the packet does not have IPsec protection, based on the set of IPsec filters, Ipsec.sys determines whether the packet is permitted, blocked, or requires security. If permitted, Ipsec.sys passes the packet back to Tcpip.sys without modification. If the packet is blocked or requires security, Ipsec.sys silently discards the packet.

  2. Tcpip.sys passes the packet to Ipfltdrv.sys for processing.

    Based on the interface on which the packet was received, Ipfltdrv.sys compares the packet to the configured inbound IP packet filters.

    If the inbound IP packet filters do not allow the packet, Ipfltdrv.sys silently discards the packet. If the inbound IP packet filters allow the packet, Ipfltdrv.sys passes the packet back to Tcpip.sys.

  3. Tcpip.sys passes the packet to Ipnat.sys for processing.

    If Internet Connection Sharing or the NAT/Basic Firewall is enabled and the interface on which the packet was received is the public interface connected to the Internet, Ipnat.sys compares the packet to its NAT translation table. If an entry is found, the IP packet is translated and the resulting packet is treated as source traffic.

    Windows Firewall checks the IPsec Bypass flag associated with the packet. If the IPsec Bypass flag is set, Windows Firewall passes the packet back to Tcpip.sys.

    If the IPsec Bypass flag is not set, Windows Firewall compares the packet to its exceptions list. If the packet matches an exception, Ipnat.sys passes the IP packet back to Tcpip.sys. If the IP packet does not match an exception, Ipnat.sys silently discards the IP packet.

  4. Tcpip.sys compares the IP packet to the configured set of allowed packets for TCP/IP filtering.

    If TCP/IP filtering does not allow the packet, Tcpip.sys silently discards the packet. If TCP/IP filtering allows the packet, Tcpip.sys continues processing the packet, eventually passing the packet payload to TCP, UDP, or other upper layer protocols.

Transit Traffic

The following figure shows the first part of the path for transit traffic.

If your browser does not support inline frames, click here to view on a separate page.

  1. After receiving the IP packet, Tcpip.sys passes it to Ipfltdrv.sys for processing.

    Based on the interface on which the IP packet was received, Ipfltdrv.sys compares the packet to the configured inbound IP packet filters.

    If the inbound IP packet filters do not allow the packet, Ipfltdrv.sys silently discards the IP packet. If the inbound IP packet filters allow the packet, Ipfltdrv.sys passes the IP packet back to Tcpip.sys.

    Tcpip.sys passes the packet to the IP forwarding component to determine the next-hop interface and address for forwarding the packet.

    The following figure shows the next part of the traffic path for transit traffic.

    If your browser does not support inline frames, click here to view on a separate page.

  2. Tcpip.sys passes the packet to Ipnat.sys.

    If Internet Connection Sharing or the NAT/Basic Firewall is enabled and the interface on which the packet was received is a private interface connected to the intranet, Ipnat.sys compares the packet to its NAT translation table. If Internet Connection Sharing or the NAT/Basic Firewall finds an entry, it translates the IP packet and treats the resulting packet as source traffic. If Internet Connection Sharing or the NAT/Basic Firewall does not find an entry, it creates a new NAT translation table entry, translates the IP packet, and treats the resulting packet as source traffic.

    If Internet Connection Sharing or the NAT/Basic Firewall is not enabled, Ipnat.sys passes the IP packet back to Tcpip.sys.

  3. Tcpip.sys passes the packet to Ipfltdrv.sys.

    Based on the next-hop interface, Ipfltdrv.sys compares the packet to the configured outbound IP packet filters.

    If the outbound IP packet filters do not allow the packet, Ipfltdrv.sys silently discards the IP packet. If the outbound IP packet filters allow the packet, Ipfltdrv.sys passes the IP packet back to Tcpip.sys.

  4. Tcpip.sys passes the packet to Ipsec.sys for processing.

    Based on the set of IPsec filters, Ipsec.sys determines whether the packet is permitted, blocked, or secured. If permitted, Ipsec.sys passes the packet back to Tcpip.sys without modification. If blocked, Ipsec.sys silently discards the packet. If secured, Ipsec.sys adds the appropriate IPsec protection to the packet before handing it back to Tcpip.sys.

    Tcpip.sys then sends the IP packet over the next-hop interface to the next-hop address.

For a commonly configured client or server computer running Windows XP with SP2 or Windows Server 2003 with SP1 that is not acting as a router or a NAT and has TCP/IP filtering disabled, the packet processing path for source traffic involves the following components:

  1. Windows Firewall

  2. IPsec

The packet processing path for destination traffic for such a commonly configured Windows-based computer involves the following components:

  1. IPsec

  2. Windows Firewall

If you are using IPsec and have Windows Firewall enabled, then you might need to configure both components to allow the desired traffic. For example, if you are configuring a Web server and securing Web traffic to that server with IPsec, you must configure the following:

  1. An IPsec rule that requires security for packets to and from the server's IP address and for TCP port 80.

  2. A Windows Firewall exception for TCP port 80.

The IPsec rule ensures that the traffic to the Web server service is protected. The Windows Firewall exception ensures that Windows Firewall does not drop unsolicited incoming requests to create connections to the Web server over TCP port 80. Because IPsec and Windows Firewall process IP packets as separate components, you must configure both components. If you want to keep Windows Firewall from processing packets that have been protected with IPsec, configure the Windows Firewall: Allow authenticated IPSec bypass Group Policy setting. For more information, see Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2.

For More Information

For more information about TCP/IP and IP packet processing, consult the following resources:

For a list of all The Cable Guy articles, click here.