Firewall Client Basics: Introduction to the ISA Server Firewall Client and Forefront TMG Client

Introduction

Since the early days of the Internet, HTTP-based applications have enjoyed the definition of a proxy mechanism that allowed hosts operating in private networks to reach hosts in public networks. These applications would connect to the local proxy on its listening port (8080 is the accepted default) and issue the request in a specific form so that the proxy could handle it correctly. The proxy would then mediate between the internal client and the external server so that the communication would be carried out in accordance with their needs and the policies dictated by the proxy administrators. This mechanism is known officially as a CERN proxy, in reference to the organization that defined the HTTP protocol and HTTP proxy mechanisms. Currently, it’s commonly referred to as an HTTP proxy or a Web proxy, but the meanings are identical – a mechanism that mediates between the HTTP client and server. This process works very well and even includes the ability to authenticate the user by means of specific HTTP request/response sequences. Figure 01 illustrates this process for a directly-connected client.

Figure 01 Direct-connected HTTP request

Figure 02 illustrates a CERN proxy request process.

Figure 02 CERN proxy HTTP request

Unfortunately, this proxy mechanism is generally limited to the HTTP protocol. Applications that use protocols other than HTTP need a different solution. For these applications, another mechanism called SOCKS proxy was devised. The initial implementation was called SOCKS4 and provides TCP proxy services for almost any application protocol (FTP, SMTP, POP3 – even HTTP). This mechanism operates similarly to a CERN proxy except that the proxy mechanism functions separately from the application protocol. The SOCKS client application connects to the SOCKS proxy (1080 is the accepted default) and negotiates with the SOCKS proxy to establish the connection to the remote server. Once this connection was established, the SOCKS proxy acts as a basic NAT router for the session protocol between the client and server. SOCKS4 was later extended to support name resolution (SOCKS4a) and UDP traffic, user authentication and IPv6 (SOCKS5 and extensions). While SOCKS offers a great deal of functionality that a CERN proxy does not, it still requires that an application be written to use the SOCKS protocol if it were to successfully reach a remote host through a SOCKS proxy. Figure 03 illustrates basic SOCKS proxy behavior.

Figure 03 SOCKS proxy behavior

In both cases (CERN and SOCKS proxy), the application data traverses the proxy using the proxy port connection. Except for SOCKS5, which offers a UDP proxy mechanism, no other connections are made between the client and remote server.

Beginning in 1996, Microsoft has offered a mechanism through which non-proxy-enabled applications could pass traffic through the proxy server at the edge of their network. For Proxy Server 1 and Proxy Server 2, this mechanism was known as the Winsock Proxy (WSP). For ISA Server, it became known as the Firewall Client (FWC) and for Forefront TMG, as the TMG Client (TMGC). For simplicity, we’ll refer to them collectively as “the FWC” and the various firewall versions as “the firewall”. Although the name and features of each have changed through the years, the primary goal of the FWC has remained the same – to enable non-proxy applications to successfully operate across a Microsoft proxy/firewall solution in accordance with the traffic policies imposed by the administrator.

Winsock 101

In order to understand how the FWC operates, you need to start with an understanding of how Windows applications generate and consume network traffic. While it is possible for an application to build IP packets themselves, this is very inefficient and leads to a set of challenges that few application developers are willing to face. Most Windows network application developers find that it’s more efficient and effective to use a Windows API set called Winsock.

Winsock is the Windows implementation of the Berkeley Software Distribution UNIX sockets API known as Berkeley Sockets or BSD Sockets. In both cases, this API provides application developers the means to use network protocols without having to manage the fine details of each and every protocol or packet.

Although the Winsock API defines dozens of functions, we’ll limit this discussion to the following list:

• bind() – associates a network address with a socket

• connect() – creates a connection to a remote host

• getaddrinfo() – obtains the IP address or host name from a hostname or IP address, respectively

• listen() – configures a bound socket to accept incoming connections

• recv() – receives data from a connected or bound socket

• send() – sends data on a connected socket

• socket() – creates a socket

As you may have noticed, all of these functions except getaddrinfo() have a common aspect – they all operate in the context of a socket. A socket is a programmatic reference to a network resource and is used as determined by the application creating it and the functionality provided by Winsock.

Almost everything an application does through Winsock is done in the context of a socket. The reason this point is significant is that a socket is also the context in which the FWC will do most of its work. In order to provide a baseline from which to compare the FWC behavior, we first need to establish how a typical FTP client / server conversation proceeds under non-FWC conditions. Figure 04 and the following process illustrate a very simplified version of a typical FTP client application conversation with an FTP server.

Figure 04 Simplified Winsock usage for a direct connect FTP session

This process begins when the user uses the command-line tool ftp.exe to reach an FTP server at ftp.contoso.com. Where network traffic is generated, a snip from a Network Monitor capture is included.

1. Ftp.exe passes “ftp.contoso.com” to the Winsock getaddrinfo() function. Winsock calls Windows name resolution mechanisms and returns “131.107.0.21” to ftp.exe.

   Source	Destination	Action
   131.107.0.19	131.107.0.2	DNS: Query for ftp.contoso.com
   131.107.0.2	131.107.0.19	DNS: Success, 131.107.0.21

2. Ftp.exe obtains a IPv4 TCP socket from the Winsock socket() function

3. Ftp.exe calls the Winsock connect() function, indicating that the destination for the connection is at IP address 131.107.0.21 and the destination port is 21. Winsock creates a connection to the FTP server on TCP port 21 and responds “success” to ftp.exe. This establishes an FTP control channel connection between ftp.exe and the FTP server.

   Source	Destination	Action
   131.107.0.19	131.107.0.21	TCP:Flags=......S., SrcPort=2345, DstPort=21
   131.107.0.21	131.107.0.19	TCP:Flags=...A..S., SrcPort=21, DstPort=2345
   131.107.0.19	131.107.0.21	TCP:Flags=...A...., SrcPort=2345, Dstport=21

4. The user and FTP server engage in the following conversation on the FTP control channel:

   1. The FTP server sends “220 Microsoft FTP Service”.

   2. The user types “anonymous” in the ftp.exe window and ftp.exe sends “USER anonymous” to the FTP server

   3. The FTP server responds with “331 Anonymous access allowed, send identity (e-mail name) as password.”

   4. The user types “me@you.com” in the ftp.exe window and hits Enter.

   5. ftp.exe sends “PASS me@you.com” to the FTP server.

   6. The FTP server responds with “230 Anonymous user logged in.”

      Source	Destination	Action
      131.107.0.21	131.107.0.19	FTP: '220 Microsoft FTP Service'
      131.107.0.19	131.107.0.21	FTP: 'USER anonymous'
      131.107.0.21	131.107.0.19	FTP: '331 Anonymous access allowed, send identity (e-mail name) as password.'
      131.107.0.19	131.107.0.21	FTP: 'PASS me@you.com'
      131.107.0.21	131.107.0.19	FTP: '230 Anonymous user logged in.'

   7. The user types “dir” in the ftp.exe window.

      Note

      Because ftp.exe knows that it must receive data from the FTP server, and this data must be transferred over a separate connection from the one it is currently using, it must create another socket (FTP data channel) to receive that data.

5. Ftp.exe passes an empty hostname to the Winsock getaddrinfo() function. Winsock understands this to mean “get my own IP address” and returns 131.107.0.19; the IP address assigned to this computer.

6. Ftp.exe acquires a new IPv4 TCP socket by calling the Winsock socket() API once more. Winsock returns a reference for that socket to ftp.exe.

7. Ftp.exe instructs Winsock to bind the new socket to 131.107.0.19 using a dynamic port. Winsock returns “success” to ftp.exe; indicating that 1234 is the bound port

8. Ftp.exe instructs Winsock to listen for incoming connections on the bound socket. Winsock returns “success” to ftp.exe.

9. Ftp.exe and the FTP server engage in the following conversation on the FTP control channel:

   1. ftp.exe sends “PORT 131,107,0,19,4,210” to the FTP server.

   2. The FTP server responds “200 PORT command successful”.

   3. ftp.exe sends “LIST” to the FTP server.

   4. The FTP server responds with “150 Opening ASCII mode data connection for /bin/ls”

      Source	Destination	Action
      131.107.0.19	131.107.0.21	FTP: 'PORT 131,107,0,19,4,210'
      131.107.0.21	131.107.0.19	FTP: '200 PORT command successful.'
      131.107.0.19	131.107.0.21	FTP: 'LIST'
      131.107.0.21	131.107.0.19	FTP: '150 Opening ASCII mode data connection for /bin/ls.'

10. The FTP server establishes the FTP data channel to ftp.exe when it connects from IP address 131.107.0.21 TCP port 20 to 131.107.0.19 TCP port 1234. Because ftp.exe created a socket and configured it to listen for incoming connections, this connection is accepted by Winsock.

    Source	Destination	Action
    131.107.0.21	131.107.0.19	TCP:Flags=......S., SrcPort=20, DstPort=1234
    131.107.0.19	131.107.0.21	TCP:Flags=...A..S., SrcPort=1234, DstPort=20
    131.107.0.21	131.107.0.19	TCP:Flags=...A...., SrcPort=20, DstPort=1234

11. The FTP server sends the directory information to ftp.exe over the FTP data channel.

    Source	Destination	Action
    131.107.0.21	131.107.0.19	FTP: Data transfer to client

There is more that occurs between ftp.exe and Winsock in the process of satisfying the user’s commands, but these are the important points for this example. As you can see, any application that creates or consumes network traffic has a lot to do in order to be successful. Imagine how interesting this process was before Sockets were invented…

Winsock Service Providers

Winsock provides two basic service types; transport services (traffic flow) and name services (translation between IP address and name). In the example illustrated in Figure 04, getaddrinfo() makes use of Winsock name services and the socket calls make use of Winsock transport services. Although these services have been available since Winsock was first created, they weren’t extensible (meaning they couldn’t be enhanced [or broken] by others) until Winsock 2.0 was released for Windows 98 and later Windows operating systems. This transport and namespace extensibility is referred to collectively as Service Provider Interface (SPI). Transport service providers are also called Layered Service Providers (LSP) because Winsock allows multiple TSP to be chained together in a sequential fashion.

LSP are used to provide additional Winsock functionality specific to the LSP vendor’s goals. In some cases, this might be a pseudo-network interface such as those created by some cell provider wireless links, a special printer driver or it may be the latest piece of malware attempting to redirect your network traffic. The point is, this extensibility allows the SP author to add functionality to Winsock and it’s this extensibility that makes the FWC a successful mechanism. Figure 05 depicts a simplified relationship between applications, Winsock and SP.

Figure 05 Winsock and SP functional relationship

When a SP is installed, it updates Winsock regarding the type of functionality it provides, such as:

• Type of SP; name or transport service provider

• Level of service provider

• Transport protocols it supports (TSP only)

• Its preferred place in the LSP chain (TSP only)

This way, Winsock knows how and when to call the LSP chain for a given application request. The Winsock LSP list is maintained in the system registry and can be viewed using the netsh utility that Windows provides, for instance: netsh winsock show catalog. A summarized form of this output for a TMGC-enabled host is shown below:

C:\Windows\system32>netsh winsock show catalog

Winsock Catalog Provider Entry
------------------------------------------------------
Entry Type:                         Layered Chain Entry
Description:                        Microsoft TMG Client Service Provider over [MSAFD Tcpip [TCP/IP]]
Provider ID:                        {81FB7E30-EAF3-4C63-B9B0-2BA247212B2D}
Provider Path:                      C:\Program Files (x86)\Microsoft TMG Client\FwcWsp64.dll
Catalog Entry ID:                   1033
Version:                            2
Address Family:                     2
Max Address Length:                 16
Min Address Length:                 16
Socket Type:                        1
Protocol:                           6
Service Flags:                      0x20066
Protocol Chain Length:              2
Protocol Chain: 1031 : 1001


Winsock Catalog Provider Entry
------------------------------------------------------
Entry Type:                         Layered Chain Entry
Description:                        Microsoft TMG Client Service Provider over [MSAFD Tcpip [UDP/IP]]
Provider ID:                        {73330A3F-1162-4204-8D82-70D86CC6A71F}
Provider Path:                      C:\Program Files (x86)\Microsoft TMG Client\FwcWsp64.dll
Catalog Entry ID:                   1034
Version:                            2
Address Family:                     2
Max Address Length:                 16
Min Address Length:                 16
Socket Type:                        2
Protocol:                           17
Service Flags:                      0x20609
Protocol Chain Length:              2
Protocol Chain: 1031 : 1002


..<removed for clarity>..


Winsock Catalog Provider Entry
------------------------------------------------------
Entry Type:                         Layered Chain Entry (32)
Description:                        Microsoft TMG Client Service Provider over [MSAFD Tcpip [TCP/IP]]
Provider ID:                        {BC2BA834-D05F-4301-B185-22D1C876E821}
Provider Path:                      C:\Program Files (x86)\Microsoft TMG Client\FwcWsp.dll
Catalog Entry ID:                   1037
Version:                            2
Address Family:                     2
Max Address Length:                 16
Min Address Length:                 16
Socket Type:                        1
Protocol:                           6
Service Flags:                      0x20066
Protocol Chain Length:              2
Protocol Chain: 1032 : 1001


Winsock Catalog Provider Entry
------------------------------------------------------
Entry Type:                         Layered Chain Entry (32)
Description:                        Microsoft TMG Client Service Provider over [MSAFD Tcpip [UDP/IP]]
Provider ID:                        {825EF4FF-5C2D-4555-8563-5570568305E6}
Provider Path:                      C:\Program Files (x86)\Microsoft TMG Client\FwcWsp.dll
Catalog Entry ID:                   1038
Version:                            2
Address Family:                     2
Max Address Length:                 16
Min Address Length:                 16
Socket Type:                        2
Protocol:                           17
Service Flags:                      0x20609
Protocol Chain Length:              2
Protocol Chain: 1032 : 1002


..<removed for clarity>..


Name Space Provider Entry
------------------------------------------------------
Description:                        Microsoft TMG Client Name Space Service Provider
Provider ID:                        {4A2A9951-8573-11D0-A7EB-0000F8750B21}
Name Space:                         12
Active:                             1
Version:                            1


..<removed for clarity>..


Name Space Provider Entry (32)
------------------------------------------------------
Description:                        Microsoft TMG Client Name Space Service Provider
Provider ID:                        {4A2A9951-8573-11D0-A7EB-0000F8750B21}
Name Space:                         12
Active:                             1
Version:                            1


..<removed for clarity>..

In this example, the TMG client has registered as two transport service providers (TCP/IP and UDP/IP) and as a name service provider. You may have noticed that there are two entries for the Microsoft TMG Client relative to TCP/IP, UDP/IP and naming services. This is because the host in this example is running a 64-bit version of Windows. In this environment, the TMG client registers with Winsock as 32- and 64-bit SP, indicating to Winsock which component Winsock should call for 32-bit and 64-bit Winsock usage. An LSP that only registers as 32-bit cannot be called when Winsock is used by a 64-bit client and an LSP that only registers as 64-bit will miss 32-bit client Winsock calls.

Although we don’t intend to delve into the deep, dark mysteries of Winsock LSP, it is worth mentioning that an LSP may perform its task and forward the request to other SP down the chain for further processing or it may signal Winsock that processing is complete for this request. For instance, NSP1 may not want Winsock to process a name resolution request any further so when it returns the call to Winsock, it signals that Winsock should not pass the request to any other NSP. Likewise, a TSP can perform processing on the request and signal Winsock to cease further processing and return the response provided by this TSP. This is a point which causes significant conflict between LSP.

Firewall Client Winsock Abstractions

In the case of the FWC, the additional functionality is threefold:

1. Winsock applications can connect to servers across an ISA Server or Forefront TMG without imposing special functionality such as that required by CERN or SOCKS proxies or without forcing their default route through the firewall.

2. Firewall administrators can enforce firewall authentication for traffic that couldn’t normally participate in proxy authentication (SMTP, POP3, F2FP, etc.)

3. Firewall administrators can control specific behaviors of Winsock applications with respect to firewall usage

Figure 06 and the following list summarize the basic process of the previous FTP session as handled through the FWC.

Figure 06 Simplified Winsock usage for a FWC connect FTP session

This process starts when the user opens a command window and types ftp ftp.contoso.com and hits the Enter key.

1. Ftp.exe passes “ftp.contoso.com” to the Winsock getaddrinfo() function.

   1. Because the FWC is registered as a NSP, Winsock passes this request to the FWC which recognizes “ftp.contoso.com” as an external domain

   2. The FWC establishes the FWC control channel connection to the firewall on TCP port 1745 and if required, authenticates to the firewall

      Source	Destination	Action
      192.168.0.2	192.168.0.1	TCP:Flags=......S., SrcPort=1423, DstPort=1745
      192.168.0.1	192.168.0.2	TCP:Flags=...A..S., SrcPort=1745, DstPort=1423
      192.168.0.2	192.168.0.1	TCP:Flags=...A...., SrcPort=1423, DstPort=1745
      192.168.0.2	192.168.0.1	RWS:Channel setup request (ISA Server compatible) for ftp.exe as <User> on <Client> running Windows XP x32
      192.168.0.1	192.168.0.2	RWS:Channel setup response to ftp.exe (ISA Server compatible), authentication to <Firewall> is required; encryption not required
      192.168.0.2	192.168.0.1	NLMP:NTLM NEGOTIATE MESSAGE, Workstation Name: <Client>, Workstation Domain: <Domain>
      192.168.0.1	192.168.0.2	NLMP:NTLM CHALLENGE MESSAGE
      192.168.0.2	192.168.0.1	NLMP:NTLM AUTHENTICATE MESSAGE, Domain: <Domain>, User: <User>, Workstation: <Client>
      192.168.0.1	192.168.0.2	RWS:Logon OK

      Note

      The authentication cycle in the FWC control channel setup process is where the FWC provides user authentication to the firewall. All FWC control channel traffic occurs over the connection to the firewall on TCP port 1745

   3. The FWC sends a gethostbyname() request for “ftp.contoso.com” to the firewall on the FWC control channel.

   4. The firewall uses Windows name resolution mechanisms and returns “131.107.0.21” in a HOSTENT response through the FWC control channel to the FWC that passes it back to ftp.exe through Winsock.

      Note

      A HOSTENT is a data structure defined and used by Winsock to communicate address information to the application. Because the FWC basically forwards application Winsock calls to the firewall, much of the data you see in the FWC control channel mimics the data structures used by Winsock.

      Source	Destination	Action
      192.168.0.2	192.168.0.1	RWS:0x10000 Get host by name('ftp.contoso.com') from ftp.exe
      192.168.0.1	192.168.0.2	RWS:0x10000 Host entry response to ftp.exe for 'ftp.contoso.com'

2. Ftp.exe obtains an IPv4 TCP socket through a call to the Winsock socket() function.

3. Ftp.exe calls the Winsock connect() function, indicating that the destination for the connection is at IP address 131.107.0.21 and the destination port is 21

   1. Because the FWC is registered as a TSP, Winsock passes this call to the FWC which forwards this request to the firewall via the FWC control channel.

      Source	Destination	Action
      192.168.0.2	192.168.0.1	RWS:0x20000 New Connect request from ftp.exe to 131.107.0.21/21; client will send from 192.168.0.2/1516

      Note

      This message also includes a client IP address and port which the FWC will use to send and receive data with the FTP server through the firewall.

   2. The firewall creates a connection to the FTP server on TCP port 21 and responds “success” to the FWC on the FWC control channel.

      Source	Destination	Action
      192.168.0.1	192.168.0.2	RWS:0x20000 Connect reply to ftp.exe; using 192.168.0.2/1516 with 192.168.0.1/6789 == 131.107.0.19/1590 with 131.107.0.21/21

      Note

      This message also includes a firewall internal IP address and port which the FWC should use to send and receive data on this connection through the firewall; port 6789 is used in this example. Data passing between ftp.exe and the FTP server on the FTP control channel (port 21 at the FTP server) flows through this connection.

   3. The FWC creates a connection to the firewall on port 6789

      Source	Destination	Action
      192.168.0.2	192.168.0.1	TCP:Flags=......S., SrcPort=1516, DstPort=6789
      192.168.0.1	192.168.0.2	TCP:Flags=...A..S., SrcPort=6789, DstPort=1516
      192.168.0.2	192.168.0.1	TCP:Flags=...A...., SrcPort=1516, DstPort=6789

   4. The FWC forwards the success state to ftp.exe through Winsock. This establishes the FTP control channel between ftp.exe and the FTP server.

4. Ftp.exe and the FTP server engage in the following conversation through the connection to the firewall on the FTP control channel:

   1. The FTP server sends “220 Microsoft FTP Service”.

   2. The user types “anonymous” in the ftp.exe window and ftp.exe sends “USER anonymous” to the FTP server

   3. The user types “me@you.com” in the ftp.exe window and hits Enter.

   4. ftp.exe sends “PASS me@you.com” to the FTP server.

   5. The FTP server responds with “230 Guest login ok, access restrictions apply.”

      Source	Destination	Action
      131.107.0.21	131.107.0.19	FTP: '220 Microsoft FTP Service'
      131.107.0.19	131.107.0.21	FTP: 'USER anonymous'
      131.107.0.21	131.107.0.19	FTP: '331 Anonymous access allowed, send identity (e-mail name) as password.'
      131.107.0.19	131.107.0.21	FTP: 'PASS me@you.com'
      131.107.0.21	131.107.0.19	FTP: '230 Anonymous user logged in.'

      The external conversation between the firewall and the FTP server on port 21 is mirrored internally between the FTP client and the firewall on port 6789.

      Source	Destination	Action
      192.168.0.1	192.168.0.2	FTP: '220 Microsoft FTP Service'
      192.168.0.2	192.168.0.1	FTP: 'USER anonymous'
      192.168.0.1	192.168.0.2	FTP: '331 Anonymous access allowed, send identity (e-mail name) as password.'
      192.168.0.2	192.168.0.1	FTP: 'PASS me@you.com'
      192.168.0.1	192.168.0.2	FTP: '230 Anonymous user logged in.'

   6. The user types “dir” in the ftp.exe window

      Note

      Because ftp.exe knows that it must receive data from the FTP server, and this data must be transferred over a connection separate from the FTP control channel, it must create an FTP data channel to receive that data.

5. Ftp.exe passes an empty hostname to the Winsock getaddrinfo() function, which responds with “192.168.0.2”.

6. Ftp.exe acquires a new IPv4 TCP socket by calling the Winsock socket() API once more. Winsock returns a reference for that socket to ftp.exe.

7. Ftp.exe instructs Winsock to bind the new socket to 192.168.0.2 on a dynamic port. Winsock forwards this request to the FWC.

   1. The FWC creates a socket and binding of its own on which to accept incoming connections from the firewall. In this example, this port is 1234.

   2. The FWC includes this socket information in the bind request that it sends to the firewall. The firewall will use this socket to send data received from the FTP server to the FWC

      Source	Destination	Action
      192.168.0.2	192.168.0.1	RWS:0x40200 TCP bind request from ftp.exe to 131.107.0.19/Dynamic. ftp.exe bound to 192.168.0.2/1234

   3. The firewall executes a bind() request to Winsock on the firewall server to obtain a dynamically-assigned port in the network facing the FTP server.

   4. The firewall returns this port (2345 in this example) to the FWC on the FWC control channel, which returns port 1234 to ftp.exe via Winsock.

      Source	Destination	Action
      192.168.0.1	192.168.0.2	RWS:0x40200 Bind reply to ftp.exe on 131.107.0.19/2345 successful

8. Ftp.exe instructs Winsock to listen for incoming connections on the bound socket. Winsock passes this to the FWC which forwards it to the firewall. The firewall listens on this socket and returns “success” through the FWC control channel. The FWC passes this to ftp.exe via Winsock.

   Source	Destination	Action
   192.168.0.1	192.168.0.2	RWS:0x40200 Listen on 131.107.0.19/2345 from ftp.exe
   192.168.0.2	192.168.0.1	RWS:0x40200 Listen reply to 131.107.0.19/2345 on ftp.exe successful

9. Ftp.exe and the FTP server engage in the following conversation on the FTP control channel:

   1. ftp.exe sends a “PORT 192,168,0,2,4,210” command to the FTP server.

   2. The FTP server responds “200 PORT command successful”.

   3. ftp.exe sends “LIST” to the FTP server. The FTP server responds with “150 Opening ASCII mode data connection for /bin/ls”

      Source	Destination	Action
      192.168.0.2	192.168.0.1	FTP:Request from Port 1516,'PORT 192,168,0,2,4,210'
      192.168.0.1	192.168.0.2	FTP:Response to Port 1516, '200 PORT command successful.'
      192.168.0.2	192.168.0.1	FTP:Request from Port 1516, 'LIST'
      192.168.0.1	192.168.0.2	FTP:Response to Port 1516, '150 Opening ASCII mode data connection for /bin/ls.'

      The conversation between the FTP client and the firewall on port 6789 is (almost) mirrored between the firewall and the FTP server on port 21.

      Note

      because the firewall FTP application filter knows that the external IP address and listening port differ from those indicated by ftp.exe, it changes this command to “PORT 131,107,0,19,9,41” before sending it to the FTP server

      Source	Destination	Action
      131.107.0.19	131.107.0.21	FTP:Request from Port 1590,'PORT 131,107,0,19,9,41'
      131.107.0.21	131.107.0.19	FTP:Response to Port 1590, '200 PORT command successful.'
      131.107.0.19	131.107.0.21	FTP:Request from Port 1590, 'LIST'
      131.107.0.21	131.107.0.19	FTP:Response to Port 1590, '150 Opening ASCII mode data connection for /bin/ls.'

10. The FTP server establishes the FTP data connection from 131.107.0.21 port 20 to 131.107.0.19 port 2345.

    Source	Destination	Action
    131.107.0.21	131.107.0.19	TCP:Flags=......S., SrcPort=20, DstPort=2345
    131.107.0.19	131.107.0.21	TCP:Flags=...A..S., SrcPort=2345, DstPort=20
    131.107.0.21	131.107.0.19	TCP:Flags=...A...., SrcPort=20, DstPort=2345

    Because ftp.exe created a listening socket at the firewall through the FWC:

    1. The firewall notifies the FWC of the incoming connection by sending a New Mapping message on the FWC control channel.

       Source	Destination	Action
       192.168.0.1	192.168.0.2	RWS:0x40200 New mapping to ftp.exe; 131.107.0.21/20 with 131.107.0.19/2345 == 192.168.0.1/1999 with 192.168.0.2/1234

       Note

       This message also includes a firewall internal IP address and port (port 1999 in this example) which the firewall will use to send data to the FWC on this connection. The FWC IP and port for this mapping were defined in the bind() request and response in steps (7) and (8).

    2. The FWC responds to the firewall with a Mapping Received message on the FWC control channel. This message includes the full connection map as understood by the FWC.

    3. The firewall creates a connection from the port specified in the Add Mapping command to the FWC on port 1234.

       Source	Destination	Action
       192.168.0.1	192.168.0.2	TCP:Flags=......S., SrcPort=1999, DstPort=1234
       192.168.0.2	192.168.0.1	TCP:Flags=...A..S., SrcPort=1234, DstPort=1999
       192.168.0.1	192.168.0.2	TCP:Flags=...A...., SrcPort=1999, DstPort=1234

11. The FTP server sends the directory information to the firewall on port 2345. The firewall forwards this to ftp.exe via the connection to the FWC on port 1234.

    Source	Destination	Action
    131.107.0.21	131.107.0.19	FTP:Data Transfer To Client,DstPort = 2345,size = 169 bytes

    The conversation between the firewall on port 2345 and the FTP server on port 20 is mirrored between the firewall on port 1999 and FTP client on port 1234.

    Source	Destination	Action
    192.168.0.1	192.168.0.2	FTP:Data Transfer To Client,DstPort = 1234,size = 169 bytes

Summary

At the network level, the direct-connect FTP session differs from the FWC-connect session in some very fundamental ways:

Direct-connect

FWC-connect

Although both tables include specific ports for many of the connections, these ports are actually assigned dynamically through Winsock bind() calls. This method is used to ensure that the Windows networking components are the only ones attempting to manage network resource allocations. This behavior is also what makes it impossible to separate FWC-enabled hosts from the firewall by means of an isolating firewall without allowing all ports above 1024 across the isolating firewall in both directions.

This article covered only the most basic Winsock mechanisms used by most applications and described how the FWC and firewall work together to make this process transparent, policy-driven and authenticated; all without involving the client application or its developer. In later articles, we’ll discuss more complex scenarios and what the FWC Application Settings do to change the FWC behavior for an application.

References

• Wikipedia article Berkeley Sockets

• MSDN article Windows Sockets 2

• MSDN article Windows Sockets 2.2 Architecture

• Microsoft Systems Journal article Unraveling the Mysteries of Writing a Winsock 2 Layered Service Provider