Packet Filters Log
The ISA Server packet filter log contains entries about the
packets that had been handled by the ISA Server packet filter. By default, only
"dropped" packets are logged. If an administrator wants to log all of the
packets that are dropped and enabled by the firewall, the administrator can
enable that option in the
IP packet filters dialog box:
- Open the ISA Management user interface.
- Open the Server or Array node that you want to
manage.
- Open the Access Policy node.
- Right-click the IP packet filters folder, and then click Properties.
- On the Packet filters tab, click to select the Log packets from allow
filters check box. If you enable this option, the packet filter logs
can be potentially very large, depending upon the amount of traffic that ISA
Server handles.
Note For a detailed description of the log fields, refer to the ISA
Server product documentation. If you set the
LogAllInterfaces registry key, the packets that are sent to the internal interface
of the firewall are dropped and logged in the packet filter log. These packets
are logged as "internal" to distinguish them from blocked packets that arrive
from the external interface.
Log Event Dispositions
- ALLOWED - The traffic was permitted by the ISA IP Packet
Filtering service.
- BLOCKED - Blocked traffic was not permitted to pass through
the firewall.
- INTERNAL � Refers to traffic that was seen at the internal
interface in either direction. The internal interface is determined by what is
defined in the LAT.
ISA Server Firewall Service Log
There are two fields: Bytes that are sent (cs-bytes) and the
bytes that are received (sc-bytes). These two fields provide valuable
information about the connection, for example, the actual amount of data and
the direction of data that has been either sent or received. These fields
indicate the data size for the individual loggings. For the outbound User
Datagram Protocol (UDP) traffic, the last log entry summarizes the traffic on
the connection.
Operation Field (s-operation)
The following operations may be displayed in the firewall log
operation field:
"Connect" - Transmission Control Protocol (TCP)
connection request (outgoing)
"Bind" - Internal firewall service operation
(port bind request)
"Listen" - Internal firewall service operation (listen
on specific port)
"Accept" - TCP connection request (incoming)
"UdpMap" - A UDP mapping has been created
"GHBN" - Get host by name
request
"GHBA" - Get host by address request
Result Code (sc-status)
The following additional result codes that relate to the logged
event may be displayed. Other values may seem to indicate a Web request status
result or a communications error code. Refer to the ISA Server product
documentation for a list of other possible values.
"0" - Operation
had been successful
"13301" - Request denied by the firewall policy
"20000" - Connection terminated normally
"20001" - Connection terminated
abnormally
"20002" - Malformed request packet
Other result codes
(sc-status):
- For values less than 100" A Windows (Win32) error
code
- For values between 100 and 1,000 - An HTTP status
code
- For values between 10,000 and 11,004 - A Winsock error
code
For more information about Win32 and Network error codes, visit
the following Microsoft Web site:
For information about Winsock error code definitions, visit the
following Microsoft Web site:
Rule#1 and Rule#2 Fields
These two fields specify the rule that either accepted or denied
the request. If a rule is not mentioned for a denied request, an implicit
denial occurred (for the default behavior, if a rule does not enable certain
traffic, the request is rejected). Refer to the ISA Server product
documentation for a complete explanation of those fields.
Traffic Analysis
Analyzing TCP Traffic
In the case of TCP traffic, the firewall log can indicate a
"connect" operation (outbound access) or an "accept" operation (inbound
access). The status field indicates whether this operation had been successful,
had been rejected, or had resulted in an error. The other various fields
indicate the Internet Protocol (IP) addresses of the client and server, the
ports involved, and the rules that applied to the traffic.
Analyzing UDP traffic
In the case of UDP traffic, the firewall log can display both the
"bind" and the "udpMap" operations. These operations indicate that a mapping
had been requested for that UDP traffic. (A UDP mapping is a virtual
association of the datagram traffic. There is no actual connection in the case
of UDP traffic).
The connection and session identification (ID)
fields can help to distinguish between overlapping (interleaving) operations,
if such operations exist. A single session ID can represent the traffic that
has been sent on a virtual connection. Session IDs represent firewall client
connections (the same ID equals [=] the same process). Or, in the case of
secure network address translation (SecureNAT) clients, the same ID equals (=)
the same client IP. Connection IDs represent "remote sockets." Same-connection
ID means same-connection TCP or the same local port for UDP. As always, the
status field has to be checked to verify if the operation had been enabled,
rejected, or resulted in an error. As previously mentioned, the "bytes sent"
and the "bytes received" fields indicate the amount and the direction of data
that had been either sent or received during the connection.
To
distinguish between the success and the failure of a UDP request, and the bytes
sent in the transaction (if any), the relevant fields must be checked:
- The "Rule#1" field indicates the rule that either enabled
or denied the traffic (either a Protocol rule or a Server Publishing rule). If
a rule is not logged, the traffic had been implicitly denied for not having any
relevant Allow rule.
- The "cs-bytes" and "sc-bytes" fields indicate the number of
bytes sent and received (respectively) on the connection.
- For outbound UDP traffic, the last log entry summarizes the
traffic on the connection. The "cs-bytes" and "sc-bytes" fields indicate the
total amount of bytes that had been sent and received, respectively. The
"Rule#1" and the "Rule#2" fields can be checked to find the rules that had been
involved in the traffic denial.
Note Because of the connectionless nature of UDP traffic, there is no
guarantee that a sent packet reached its destination. Therefore, an operation
that had been logged as successfully completed by the firewall log merely
indicates that the packet had been sent, and not that the packet had been
received by the destination computer.
For additional information, click the
article number below to view the article in the Microsoft Knowledge Base:
283213 Blocking and Logging Traffic on ISA Server Internal Interfaces