Understanding the Firewall Client Control Channel
By Stefaan Pouseele
May 2002
Last Update: 09/08/2003
1. Summary
The firewall client talks to the firewall service on ISA through the Control channel. Authentication credentials, name resolution queries and port negotiations are examples of the kind of information that is sent along the control channel. However, keep in mind that no real data is exchanged on this channel. On ISA the Control channel is listening on TCP and UDP Port 1745.
I did not find any evidence that Microsoft should ever have made publicly available the protocol description of the Remote Winsock Protocol (RWSP) used by the firewall client. Lucky for us, the free Ethereal network monitor decodes this protocol fairly well. It is very enlightening to see how the firewall client actually talks to the ISA server. As an example, we will explore the setup of an outbound Telnet and FTP session.
Note: because there is no formal protocol description available, we depend completely on the Ethereal decoding. Therefore, we will put our effort in the overall workings of the Remote Winsock Protocol, and not waste time on the exact details of all protocol fields.
2. About Ethereal
Ethereal is a free Network Monitor and has a decoder for the Remote Winsock Protocol, named MSproxy in the Ethereal decoded display. Moreover, there is a plugin available for decoding the H.323 protocol used by Netmeeting and the ISA H.323 gateway/gatekeeper.
If you are interested in getting Ethereal and the H.323 plugin, check out the following links:
3. Outbound Telnet connection
In the following trace, you see a high level view of the outbound Telnet connection setup from the client. This trace is taken on the firewall client with the IP-address 172.16.22.5. The ISA server has the IP-address 172.31.0.1.
No. Time Source Destination Protocol Info
1 0.000000 172.16.22.5 172.31.0.1 MSproxy Client message: Hello
2 0.001299 172.31.0.1 172.16.22.5 MSproxy Server message: Hello Acknowledge
3 0.001501 172.16.22.5 172.31.0.1 MSproxy Client message: Hello
4 0.003198 172.31.0.1 172.16.22.5 MSproxy Server message: User Info Acknowledge
5 0.004574 172.16.22.5 172.31.0.1 MSproxy Client message: Authentication
6 0.004705 172.16.22.5 172.31.0.1 MSproxy Client message: Authentication
7 0.004762 172.16.22.5 172.31.0.1 MSproxy Client message: Authentication
8 0.009926 172.31.0.1 172.16.22.5 MSproxy Server message: Authentication 2 Acknowledge
9 0.010240 172.16.22.5 172.31.0.1 MSproxy Client message: Resolve
10 0.012122 172.31.0.1 172.16.22.5 MSproxy Server message: Resolve Acknowledge
11 0.014158 172.16.22.5 172.31.0.1 MSproxy Client message: Connect
12 0.015431 172.31.0.1 172.16.22.5 MSproxy Server message: Connect Acknowledge
13 0.015753 172.16.22.5 172.31.0.1 TCP 1541 > 10070 [SYN] Seq=3608864536 Ack=0 Win=16384 Len=0
14 0.017090 172.31.0.1 172.16.22.5 TCP 10070 > 1541 [SYN, ACK] Seq=1863736807 Ack=3608864537 Win=32736 Len=0
15 0.017166 172.16.22.5 172.31.0.1 TCP 1541 > 10070 [ACK] Seq=3608864537 Ack=1863736808 Win=17520 Len=0
16 0.026109 172.16.22.5 172.31.0.1 TELNET Telnet Data ...
We can break down the above trace into 5 parts:
- frame 1 – 4: set up a control channel session with the firewall service
- frame 5 – 8: authenticate the user to the firewall service
- frame 9 – 10: ask the firewall service to resolve the DNS name of the target host
- frame 11 – 12: ask the firewall service permission to make a telnet connection to the target host
- frame 13 and following: connect to the Telnet service on the target host
Before we examine each part of the above trace in more detail, you can see a snapshot of the fully decoded first frame in the following figure . For better readability only the transport and higher levels are expanded (click to open figure in new window). You can clearly see that the MSproxy protocol is carried as data within an UDP packet on port 1745.
3.1. Set up a control channel session with the firewall service
The following table contains the decoded MSproxy protocol of the control channel session setup in detail.
| Frame |
Firewall client |
ISA server |
|
1 |
Client id: 0xb |
||
2 |
Client id: 0xb |
||
3 |
Client id: 0x888a5c |
||
4 |
Client id: 0x1a3c1e2 |
||
In the first message, the client sends a Hello which is answered by the server with a Hello Acknowledge. This exchange of data seems to create a sort of Session Id for all further communication within that session. I assume this Session Id is decoded as Server Id (in this case 0x3e0700) by Ethereal. Other fields that could be of interest are the User Name, Client Computer Name and Application Name.
It is funny that the Client Id seems to be different on the client and the server, although they are always the same for that session. If you follow the complete conversation you’ll find out that the fields Server Ack, Client Ack and Sequence Number seem not to follow the usual pattern of a normal acknowledgement protocol. It’s hard to tell without a detailed protocol description what the exact meaning of these fields are.
In the next conversation the client seems to resend the Hello, but this time with the Server Id filled in with the value received from the ISA server. Next the server responds with a User Info Acknowledge. I assume that at this point the ISA server extracts the fields User Name and Application Name for further use in the firewall log (fields cs-username, c-agent).
3.2. Authenticate the user to the firewall service
The next step is to authenticate the user at the client to the firewall service on ISA. This is summarized in the following table.
| Frame | Firewall client | ISA server | |
5 |
Client id: 0x888a5c |
||
6 |
Client id: 0x888a5c |
||
7 |
Client id: 0x888a5c |
||
8 |
Client id: 0x1a3c1e2 |
||
The client authentication message with the client credentials as data seems to be rather long and therefore needs to be split into three successive frames. The answer from the server indicates whether the user authentication was successful or not. In this case it was. The outcome of this transaction will also be reflected in the firewall log (field sc-authenticated)
3.3. Ask the firewall service to resolve the DNS name of the target host
Depending on the firewall client settings and the TCP/IP properties at the client, the client may ask the ISA server to do the DNS resolving on behalf of the client. This is shown in the next table.
| Frame | Firewall client | ISA server | |
9 |
Client id: 0x888a5c |
||
10 |
Client id: 0x1a3c1e2 |
||
There is not much to say about this, except that the answer from the server indicates whether the DNS resolving was successful or not. If successful, the client receives the IP-address of the target host it wants to connect to. This conversation is logged as a separate entry in the firewall log with the field s-operation = GHBN (Get Host By Name request). I believe that if the client application asks for a reverse DNS lookup, the MSproxy protocol will return a DNS name and this transaction will also be logged as a separate entry in the firewall log with the field s-operation = GHBA (Get Host By Address request).
3.4. Ask the firewall service permission to make a telnet connection to the target host
The next step for the firewall client is to ask the firewall service on ISA if it is allowed to connect to the target host with this protocol. This is summarized in the following table.
| Frame | Firewall client | ISA server | |
11 |
Client id: 0x888a5c |
||
12 |
Client id: 0x1a3c1e2 |
||
This is probably the most interesting part of the whole dialog between the client and the server. In the Connection Request message the client specifies the target IP address (in this case 193.75.143.67), the target port number (in this case 23) and the source port number the client will use (in this case 1541). Now the firewall service has all the elements needed to check the outgoing access policy. When the connection is allowed the ISA server responds with the IP address (in this case 172.31.0.1) and port number (in this case 10070) the client must connect to (see fields Server Internal) . Also, the ISA server will tell the client which source IP address and port number it will use for the external connection (see fields Server External).
If the connection is allowed, ISA activates a listener on the internal interface to accept this connection. I assume that this event is not yet logged as a separate entry in the firewall log because the actual connection is not made and therefore the success or failure of it is not known. However, if the connection is denied by the outgoing access policy then the conversation is over and this is logged as a separate entry in the firewall log with the fields s-operation = Connect, rule#1 and rule#2 filled in and sc-status = 13301 (Request denied by the firewall policy).
3.5. Connect to the Telnet service on the target host
Now the client has to connect to the given IP address and port number. You can verify that in frame 13-15 in the above trace. You clearly see that the source/destination port numbers are those negotiated in the MSproxy Connect transaction. The result of this event (success or failure) will be logged as a separate entry in the firewall log with the fields s-operation = Connect, rule#1 and rule#2 filled in and sc-status properly set.
Note that if the connection terminates, another separate entry in the firewall log will be made with the fields s-operation = Connect, rule#1 and rule#2 filled in and sc-status set to the value 20000 (Connection terminated normally) or 20001 (Connection terminated abnormally).
The connection set up is then finalised and the flow of real data can start (see frame 16). Maybe you wonder how the network monitor is able to show this as Telnet data. Remember that the connection is not made on TCP port 23 and that is exactly the criterion a protocol analyzer uses to properly decode the traffic. If we look closer into this frame, Ethereal decodes it as:
Transmission Control Protocol, Src Port: 1541 (1541), Dst Port: 10070 (10070), Seq: 3608864537, Ack: 1863736808
Source port: 1541 (1541)
Destination port: 10070 (10070)
Sequence number: 3608864537
Next sequence number: 3608864552
Acknowledgement number: 1863736808
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 17520
Checksum: 0x0e91 (correct)
MS Proxy Protocol
Destination Port: 23
Destination Address: 193.75.143.67 (193.75.143.67)
Telnet
Command: Will Terminal Type
Command: Do Suppress Go Ahead
Command: Will Suppress Go Ahead
Command: Do Echo
Command: Will Negotiate About Window Size
0000 00 01 30 27 4f 00 00 d0 59 7b 9a a7 08 00 45 00 ..0’O…Y{….E.
0010 00 37 27 fe 40 00 80 06 64 8d ac 10 16 05 ac 1f .7′.@…d…….
0020 00 01 06 05 27 56 d7 1a e7 19 6f 16 5d e8 50 18 ….’V….o.].P.
0030 44 70 0e 91 00 00 ff fb 18 ff fd 03 ff fb 03 ff Dp…………..
0040 fd 01 ff fb 1f …..
At first sight you might think that the firewall client inserts a MSproxy layer between the TCP and the Telnet layer. However, if you look in more detail to this trace (I’ve used colors to make it easy for you) you’ll see this is not the case. So, for the convenience of the user, Ethereal is clever enough to keep track of this connection as a MSproxy initiated connection and uses the original target port number to correctly decode the traffic.
4. Outbound FTP connection
As you probably know, the FTP protocol is more complex than the Telnet protocol. So, let us look how this one is handled by the firewall client. In the following trace, you see a high level view of the outbound FTP connection setup from the client. This trace is taken on the firewall client with the IP-address 172.16.22.5. The ISA server has the IP-address 172.31.0.1.
No. Time Source Destination Protocol Info
1 0.000000 172.16.22.5 172.16.8.14 DNS Standard query A ftp.cevi.be
2 0.002584 172.16.8.14 172.16.22.5 DNS Standard query response CNAME www.cevi.be A 193.75.143.134
3 0.034748 172.16.22.5 172.31.0.1 MSproxy Client message: Hello
4 0.036045 172.31.0.1 172.16.22.5 MSproxy Server message: Hello Acknowledge
5 0.036206 172.16.22.5 172.31.0.1 MSproxy Client message: Hello
6 0.037846 172.31.0.1 172.16.22.5 MSproxy Server message: User Info Acknowledge
7 0.039196 172.16.22.5 172.31.0.1 MSproxy Client message: Authentication
8 0.039355 172.16.22.5 172.31.0.1 MSproxy Client message: Authentication
9 0.039398 172.16.22.5 172.31.0.1 MSproxy Client message: Authentication
10 0.044551 172.31.0.1 172.16.22.5 MSproxy Server message: Authentication 2 Acknowledge
11 0.044744 172.16.22.5 172.31.0.1 MSproxy Client message: Connect
12 0.047786 172.31.0.1 172.16.22.5 MSproxy Server message: Connect Acknowledge
13 0.048287 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [SYN] Seq=597200875 Ack=0 Win=16384 Len=0
14 0.048724 172.31.0.1 172.16.22.5 TCP 16567 > 1673 [SYN, ACK] Seq=945264351 Ack=597200876 Win=17520 Len=0
15 0.048795 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [ACK] Seq=597200876 Ack=945264352 Win=17520 Len=0
16 0.049426 172.31.0.1 172.16.22.5 FTP Response: 220 www Microsoft FTP Service (Version 4.0).
17 0.237458 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [ACK] Seq=597200876 Ack=945264398 Win=17474 Len=0
18 1.028624 172.16.22.5 172.31.0.1 MSproxy Client message: User Info Acknowledge
..
26 13.364523 172.16.22.5 172.31.0.1 MSproxy Client message: Bind
27 13.366090 172.31.0.1 172.16.22.5 MSproxy Server message: Bind or Associate Acknowledge
28 13.366427 172.16.22.5 172.31.0.1 MSproxy Client message: TCP Bind
29 13.367944 172.31.0.1 172.16.22.5 MSproxy Server message: TCP Bind Acknowledge
30 13.368214 172.16.22.5 172.31.0.1 FTP Request: PORT 193,75,143,3,64,185
31 13.369965 172.31.0.1 172.16.22.5 FTP Response: 200 PORT command successful.
32 13.370833 172.16.22.5 172.31.0.1 FTP Request: LIST
33 13.372219 172.31.0.1 172.16.22.5 FTP Response: 150 Opening ASCII mode data connection for /bin/ls.
34 13.374206 172.31.0.1 172.16.22.5 MSproxy Server message: Bind Info
35 13.374316 172.16.22.5 172.31.0.1 MSproxy Client message: Bind Info Acknowledge
36 13.375167 172.31.0.1 172.16.22.5 TCP 16570 > 1675 [SYN] Seq=948386323 Ack=0 Win=16384 Len=0
37 13.375221 172.16.22.5 172.31.0.1 TCP 1675 > 16570 [SYN, ACK] Seq=600560679 Ack=948386324 Win=17520 Len=0
38 13.375612 172.31.0.1 172.16.22.5 TCP 16570 > 1675 [ACK] Seq=948386324 Ack=600560680 Win=17520 Len=0
39 13.389406 172.31.0.1 172.16.22.5 TCP 16570 > 1675 [PSH, ACK] Seq=948386324 Ack=600560680 Win=17520 Len=133
40 13.389499 172.31.0.1 172.16.22.5 TCP 16570 > 1675 [FIN, ACK] Seq=948386457 Ack=600560680 Win=17520 Len=0
41 13.389545 172.16.22.5 172.31.0.1 TCP 1675 > 16570 [ACK] Seq=600560680 Ack=948386458 Win=17387 Len=0
42 13.390283 172.16.22.5 172.31.0.1 TCP 1675 > 16570 [FIN, ACK] Seq=600560680 Ack=948386458 Win=17387 Len=0
43 13.390687 172.31.0.1 172.16.22.5 TCP 16570 > 1675 [ACK] Seq=948386458 Ack=600560681 Win=17520 Len=0
44 13.556587 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [ACK] Seq=597200935 Ack=945264651 Win=17221 Len=0
45 13.557058 172.31.0.1 172.16.22.5 FTP Response: 226 Transfer complete.
46 13.756897 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [ACK] Seq=597200935 Ack=945264675 Win=17197 Len=0
47 14.139043 172.31.0.1 172.16.22.5 MSproxy Server message: User Info Acknowledge
48 20.255191 172.16.22.5 172.31.0.1 FTP Request: QUIT
49 20.256908 172.31.0.1 172.16.22.5 FTP Response: 221 Bye bye !
50 20.257048 172.31.0.1 172.16.22.5 TCP 16567 > 1673 [FIN, ACK] Seq=945264690 Ack=597200941 Win=17455 Len=0
51 20.257091 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [ACK] Seq=597200941 Ack=945264691 Win=17182 Len=0
52 20.257617 172.16.22.5 172.31.0.1 TCP 1673 > 16567 [FIN, ACK] Seq=597200941 Ack=945264691 Win=17182 Len=0
53 20.258021 172.31.0.1 172.16.22.5 TCP 16567 > 1673 [ACK] Seq=945264691 Ack=597200942 Win=17455 Len=0
To better understand the relation between the above trace and the firewall logging, you find below the firewall log entries for this outbound FTP connection.
time r-ip r-port cs-protocol cs-transport s-operation sc-status rule#1 rule#2 sessionid connectionid
14:02:26 193.75.143.134 21 21 TCP Connect 0 STANDARD INTERNET 76 238
14:02:39 - 0 0 TCP Bind 0 SPECIAL - 76 239
14:02:39 - 16569 0 TCP Listen 0 - - 76 239
14:02:39 193.75.143.134 20 0 TCP Accept 0 SPECIAL - 76 239
14:02:39 193.75.143.134 20 0 TCP Accept 20000 SPECIAL - 76 239
14:02:46 193.75.143.134 21 21 TCP Connect 20000 STANDARD INTERNET 76 238
4.1. The FTP protocol
On ISA the FTP protocol is handled by an application filter. Although the FTP protocol uses a primary and secondary connection, this is not reflected in the FTP protocol definition on ISA. If you look at the protocol definition for FTP on ISA, you will see that only the primary connection on TCP port 21 Outbound is specified. This is because the application filter itself informs the firewall service on ISA which secondary connections to open for the client, according to the specific protocol.
The FTP application filter examines the data that is flowing through the primary connection and determines which secondary connection the client is going to use. More specifically the FTP commands PORT (Data Port) and PASV (Passive) negotiate the secondary connection. In the above trace we have used the FTP active mode (standard) and hence the secondary connection is negotiated by the FTP PORT command.
4.2. Setting up the FTP Control connection
The setup of the FTP Control connection is very simular to the Outbound Telnet connection in the previous example. So, we will only highlight the important parts of it. In the above trace you find the setup in frame 1 – 15. The main difference is that in this case the DNS name resolving (frame 1 – 2) is done by the workstation itself and not through the firewall client. The reason for this is that we have explicitely configured the firewall client to do no DNS name resolving. If you want to know how to do that, read Jim Harrison’s article ISA Clients – Part 3: The Firewall Client.
Here again the most interesting part is frame 11 – 12. This is summarized in the following table. Watch the negotiated IP-addresses and port numbers, and compare them to the frames 13 – 15 where the connection is really made.
| Frame | Firewall client | ISA server | |
11 |
Client id: 0xf5b038 |
||
12 |
Client id: 0x108a9681 |
||
Now, jump to the end of the trace and you see that in frame 48 – 53 the FTP Control connection is taken down at the user request (FTP QUIT command).
At this point we have walked through the complete FTP control connection. So, now it is time to have a look at the firewall log. We see 6 entries related to the outbound FTP connection. They carry all the same sessionid (in this case value 76). Now, look at the connectionid. You see 2 values (in this case value 238 and 239). The first connectionid (value 238) is the FTP Control connection. The second one (value 239) is the FTP Data connection. The FTP Control connection setup is logged at time 14:02:26 with s-operation = Connect and sc-status = 0 (successful). The tear down of the FTP Control connection is logged at time 14:02:46 with s-operation = Connect and sc-status = 20000 (connection terminated normally).
If you look carefully at the trace, you have probably noticed two frames (frame 18 and 47) that seem to have no relation with the other ones. I’m not sure, but I believe those frames are some sort of keep-alive message between the firewall client and the firewall service. The goal seems to be to monitor the firewall control session and determine if both partners are still alive.
4.3. Setting up the FTP Data connection
After logging in to the FTP server, the user at the FTP client initiates a command (in this example a request for a directory listing) that needs to open a FTP Data connection to pass the results. Remember that in this example we use the FTP Active mode for the Data transfer. In this case the FTP client should tell the FTP server to which IP-address and port number it must connect for the Data connection. This is done with the FTP PORT command. In other words, the FTP client will activate a listener to accept the incoming Data connection from the FTP server.
Because the FTP client does not communicate directly with the target FTP server, the firewall client has first to negotiate the IP-address and port number with the firewall service on ISA. This is summarized in the following table.
| Frame | Firewall client | ISA server | |
26 |
Client id: 0xf5b038 |
||
27 |
Client id: 0x108a9681 |
||
With the Bind request the firewall client asks the firewall service to reserve a free port number (socket) on the same server external IP-address as used by the FTP Control connection. If the firewall service on ISA can honor this request, it responds with a Bind Acknowledge and returns the requested port number (in this case 16569) and a Bound Port Id (in this case 0x00103a01) that will be used as reference in further transactions for this Data connection. The success or failure of this operation is logged in the firewall log with the fields s-operation = Bind and sc-status properly set (success or failure).
Next the firewall client activates a TCP listener on its local port number (in this case 1675) and asks the firewall service on ISA to do the same on the agreed ip-address (in this case 193.75.143.3) and port number (in this case 16569). If done, the firewall acknowledges this to the firewall client. This is shown in the next table.
| Frame | Firewall client | ISA server | |
28 |
Client id: 0xf5b038 |
||
29 |
Client id: 0x108a9681 |
||
The success or failure of this operation is also logged in the firewall log with the fields s-operation = Listen and sc-status properly set (success or failure). Note that the field r-port shows the external port number ISA is listening on.
Once the listeners are activated, the FTP client can send the FTP PORT and LIST commands along the FTP Control channel. This is done in the frames 30 – 33. If you look in more detail to the PORT command, you see that the FTP client instructs the FTP server to connect to the IP-address 193.75.143.3 (coded as 193,75,143,3) and port number 16569 (coded as 64,185 = 64 * 256 + 185) for the Data connection.
The next step is to wait for the inbound connection from the FTP server. When this happens, the firewall service on ISA announces this to the firewall client with a Bind Info message. Normally the firewall client should accept this with a Bind Info Acknowledge message. This is summarized in the following table.
| Frame | Firewall client | ISA server | |
34 |
Client id: 0x108a9681 |
||
35 |
Client id: 0xf5b038 |
||
In the Bind Info message the firewall service tells the firewall client who is initiating the connection (Destination Address) and from which port number (Destination Port). Moreover, the Server Internal Port indicates from which port the firewall service will forward the incoming connection.
The success or failure of this operation is also logged in the firewall log with the fields s-operation = Accept and sc-status properly set (success or failure). Note that the fields r-ip and r-port show the real originator of the incoming connection.
Finally you should see the incoming FTP Data connection from the ISA server to the FTP client on the agreed port numbers. In the above trace you find this in the frames 36 – 43. In this example the real answer to the requested directory listing is sent in frame 39. When the transfer of the data is completed the FTP Data connection is automatically closed by the FTP server. This is done in the frames 40 – 43. As before with the FTP Control connection, the closing of the FTP Data connection is also logged in the firewall log with s-operation = Accept and sc-status = 20000 (connection terminated normally).
5. Important Note
Because IP addresses and port numbers are negotiated on the Firewall Client Control Channel, it should be obvious that the Firewall client assumes a transparent communication path to the Firewall service on the ISA server. Therefore, implementing Network Address Translation (NAT) along the communication path will very likely break the Remote Winsock Protocol. I can assure you that N:1 NAT or sometimes called PAT (Port address Translation) will break definitely the Remote Winsock Protocol. However, I’m not completely sure about 1:1 NAT because that does not change the port numbers negotiated along the Firewall Client Control Channel.
In any case, it is never a good idea to use Network Address Translation within the internal network. The chance that NAT breaks one or another protocol is just too high. Moreover, you can also run into other problems with ISA. For more info, check out the article SecureNAT and Firewall Clients Are Disconnected from the Network. So, try to avoid as much as possible Network Address Translation and only implement NAT for communications to the outside world.
6. Conclusion
In this article we examined some aspects of how the Firewall Client communicates with the firewall service on the ISA server. This was done by exploring the setup of an outbound Telnet and FTP session captured with the free Ethereal Network Monitor. It is a pity no formal description of the Remote Winsock Protocol is available. So, any information that can shed more light on the exact workings of RWSP is more than welcome.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=7;t=000791 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! – Stefaan.
