Test TCP (TTCP) is a command-line sockets-based benchmarking tool for measuring TCP and UDP performance between two systems. It was originally developed for the BSD operating system starting in 1984. The original TTCP and sources are in the public domain, and copies are available from many anonymous FTP sites.

The Microsoft version of Test TCP is provided with Windows Server 2003 in the Valueadd\Msft\Net\Tools folder of the Windows Server 2003 product CD-ROM. The Test TCP tool is called Ttcp.exe and you can use it to listen for and send TCP segment data or UDP messages between two nodes. With Test TCP, you can configure for example a computer to listen on a specific TCP or UDP port without having to install the application or service on the computer. This allows you to test network connectivity for specific traffic before the services are in place. Another good use of TTCP is to test for speed & duplex mismatch between adapters, switches and routers.

The basic syntax for Ttcp.exe on the listening node (the receiver) is the following:

• ttcp -r -pPort (to listen on a TCP port)

• ttcp -r -pPort-u (to listen on a UDP port)

The basic syntax for Ttcp.exe on the sending node (the transmitter) is the following:

• ttcp -t -pPort (to send to a TCP port)

• ttcp -t -pPort-u (to send to a UDP port)

For additional command line options, type ttcp at the command prompt as shown in the figure below:

Take note that Ttcp.exe can only listen on or send to a single port. To configure a computer to listen on multiple ports, run Ttcp.exe in separate command prompt windows.

Another port of Test TCP to Windows Sockets can be found at http://www.pcausa.com/Utilities/pcattcp.htm. It has some enhanced features such as an option to send continuously, instead of stopping after sending a specified number of buffers, and a receiver that would automatically restart after each test. Similar benchmark tools are IPerf and NetIO.

HTH,
Stefaan

The world’s most popular network protocol analyzer Ethereal has a new home and has changed its name to Wireshark!

Gerald Combs, the creator of the Ethereal® network protocol analyzer, has accepted a position with CACE Technologies. CACE is best known for the popular WinPcap packet capture library.

The site http://www.wireshark.org/ is the new home of the project. The name might be new, but the software is the same. Wireshark’s powerful features make it the tool of choice for network troubleshooting, protocol development, and education worldwide. Read the press release.

HTH,
Stefaan

One of the new features in ISA Server 2004 is the concept of multi-networking. You can use the multi-networking features of ISA Server to protect your network against internal and external security threats, by limiting communication between clients, even within your own organization. That’s indeed a great feature but consider for a moment the following simple but very common scenario:

On the ISA internal interface we have enabled the publishing of the automatic discovery information so we can use automatic discovery (WPAD in DNS or DHCP) to allow Firewall clients and Web Proxy clients to automatically locate the ISA Server computer. That works all well for the internal clients and everybody is happy.

On the perimeter network we have a number of Windows hosts. It would be great if we could keep them up-to-date by using Windows Update. However, if you try Windows Update as a SecureNAT client it won’t work that well because at some point an SSL connection is setted up. This request is obviously made by IP address. As a result, ISA must perform a reverse DNS lookup in order to match the request to a Domain Name or URL set. Yet, this will not succeed because no proper reverse DNS entries exists for the Windows Update sites.

So, if we want to restrict the allowed HTTP/HTTPS communications originating from the perimeter hosts than we will have to configure those hosts as Web Proxy clients. To accomplish that we enabled the Web Proxy outbound listener and the publishing of the automatic discovery information on the ISA perimeter network. Next, we configured a WPAD entry in the DNS zone ’splab.net’ pointing to the ISA perimeter interface (isa.splab.net). At last we checked out that ‘Automatically detect settings’ was enabled in IE (default setting) on the perimeter hosts. Despite all this effort it still didn’t work. Why?

If you take a closer look at the ‘wpad.dat’ file returned by the ISA server to a host located on the internal and the perimeter network, you will see that the functions MakeIPs() and MakeNames() are multi-networking aware; that means they return network specific information. However, the function MakeProxies() returns always as proxy server the FQDN based on the machine’s domain association, regardless of the network where this data is sent. In our case the FQDN is ‘isa.intranet.splab.net’:

According to my resources, this is by design with no plans to change this for the current ISA version but will be considered in future releases. In other words, with ISA Server 2004 the perimeter hosts are instructed to use the Web Proxy listener on the internal interface instead of the perimeter one. Of course this will not work because there is no default rule allowing that type of access.

The proper way to solve that problem is to make sure that internal hosts resolve the returned FQDN (in our case ‘isa.intranet.splab.net’) to the primary IP address assigned to the ISA internal interface (in our case ‘192.168.22.1′) and that the perimeter hosts resolve the returned FQDN (in our case ‘isa.intranet.splab.net’) to the primary IP address assigned to the ISA perimeter interface (in our case ‘192.168.33.1′). How you accomplish that depends on your specific DNS infrastructure, but in our case we use an internal DNS server responsible for the domain ‘intranet.splab.net’ and defined there two forward and reverse resource records for the FQDN ‘isa.intranet.splab.net’:

Now, to be sure that the proper DNS answer is returned to the host depending on the location of the host, you must also make sure that the option Enable netmask ordering is enabled in the properties of your DNS server as shown in the figure below:

For more information about the DNS Netmask Ordering feature, check out the Microsoft Technet article How DNS Works and the Knowledge Base article Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS. Take note that I tested the above instructions only in an ISA Server 2004 SE scenario. Personally, I have no experience with ISA Server 2004 EE but I expect that as long as you have an FQDN in the MakeProxies() function or whatever the function is called in an enterprise edition, you can apply the same logic.

HTH,
Stefaan

A while ago, Jim Harrison from Microsoft started a thread in the ISAserver.org Discussion List called Think outside the GUI challenge #1. Because he discussed a scenario that might be useful for some folks, I summarized this thread here.

Scenario:
- ISA is connected directly to the Internet via a “manageable” DSL bridge
- ISA uses 123.123.123.123/24 static external IP; DG = 123.123.123.1
- Internal LAN uses 10.9.8.x/24
- DSL bridge has unchangeable 10.0.0.2/24 internal IP
- DSL bridge offers web-based management on that internal IP

Note:
- The DSL bridge internal IP is irrelevant to normal Internet access.
Because it’s operating in “bridge” (as opposed to NAT) mode, it’s effectively transparent to the ISA for Internet traffic.

Challenges:
1. Allow either ISA-local or ISA-internal to access the DSL bridge web interface.
2. Explain why the correct solution is impossible to implement if the ISP provides a dynamic IP.

Hint:
- The core of the solution has nothing whatsoever to do with ISA itself.

Challenge #1: Allow either ISA-local or ISA-internal to access the DSL bridge web interface.

For simplicity’s sake, we’ll use ISA-local traffic for this demo.

The original packet headers are built as (simplified):

Because Windows has no clear instructions on how to handle this destination IP, internal logic sends it as:

It should be obvious that this won’t work. Neither the destination MAC nor the source IP is correct.

So, we have to make sure that the packets are sent to the bridge instead of to the default gateway (layer-2). To accomplish that we need to bind a 10.0.0.0/24 IP address to the ISA interface. You can use the following command:

• netsh int ip add addr north 10.0.0.1 255.255.255.0

Adding the new IP address only instructs Windows that this is now a local subnet, creating the following headers:

At this stage the destination MAC is correct but not the source IP address.

Unless instructed otherwise, Windows always sends originating traffic using the default Primary IP (123.123.123.123) as the source address in the IP header. Since the bridge doesn’t understand how to respond to what it sees as non-local traffic, it simply drops it.

So, we have to make sure that the packets are sent with a source IP address belonging to 10.0.0.0/24 (layer-3). To accomplish that we need to create an extra persistent route. You can use one of the following commands:

- without RRAS

• route -p add 10.0.0.0 mask 255.255.255.0 10.0.0.1

- with RRAS

• netsh routing ip add persistentroute dest=10.0.0.0 mask=255.255.255.0 name=”North” nhop=10.0.0.1 proto=NONDOD preference=0 metric=1 view=both
• netsh routing ip set persistentroute dest=10.0.0.0 mask=255.255.255.0 name=”North” nhop=10.0.0.1 proto=NONDOD preference=0 metric=1 view=both

The part of the routing command that makes it work is specifying the new IP (10.0.0.1) as the gateway for this route. This causes Windows to “route internally” and results in the bridge seeing the 10.0.0.1 IP as the source IP.

When we add the new route definition, Windows now understands that some internal routing is required and forwards the packet this way:

Note that you can’t see these internal routing changes happening via NetMon or any other packet sniffer because it’s occuring in what’s known as “memory mapped networking”.

Challenges #2: Explain why the correct solution is impossible to implement if the ISP provides a dynamic IP.

In case of dynamic IP, a static IP can’t be assigned and that is necessary to get it working (cfr challenge #1).

HTH,
Stefaan

You’ve heard it probably before: whenever you struggle with a weird problem, take a network capture on the ISA external and/or internal interface to find out what is really happening on the wire. You can use for that the Microsoft Network Monitor 2.1 Lite Version included with Windows 2003 or the excellent free tool Ethereal. However, the hardest part is definitely correctly interpreting the network capture.

Today, I stumbled on an excellent TechNet Webcast Troubleshooting “The Network is Slow” (Level 300) given by Laura Chappell from the Protocol Analysis Institute:

A slow network is the most common onsite request and we explain the information you need to troubleshoot various types of network calls. Where do you tap in? How do you set up the analyzer to measure time properly? What do you look for at the packet level? This webcast takes you through several case studies of networks that would make many IT professionals consider getting a job as a lint-picker in a garment factory.

I hope that this webcast, together with the information available at http://www.packet-level.net/2006TechNet/, will help a lot of people to become familiar with the most important troubleshooting tool for anyone serious about networking.

BTW — Jim Harrison from Microsoft announced today in the excellent TechEd 2006 Webcast Securing Wireless Access with Internet Security and Acceleration (ISA) Server 2004 (Level 400) that Microsoft Network Monitor 3.0 will go in Beta around 1 August 2006 (http://connect.microsoft.com). Here is a screenshot of the new version as shown in this webcast:

It sounds to be a very good product with a lot of new features. So, stay tuned.

HTH,
Stefaan

It is a well-known fact that network denial-of-service attacks have one characteristic in common: spoofed addresses. Therefore, it is good security practice to implement some ingress filtering in your border router to defeat denial-of-service attacks which employ IP source address spoofing (RFC2827 - Network Ingress Filtering). The border router is the router that connects you to the Internet or another network outside your control.

As mentioned in Jesper and Steve’s book Protect Your Windows Network, five filtering rules in your border router will block almost all denial-of-service attacks. The first two help prevent spoofing; the remaining three block other kinds of bad traffic from entering your network although I personally would not implement the fifth rule. By offloading this work from your firewall, it’s got less traffic to process and more CPU time to better analyze application-layer attacks. Here are the five filtering rules you should implement:

1. Block all inbound traffic where the source address is in your network.

Why should there be traffic trying to enter your network that is coming from your network? This rule prevents someone from spoofing you.

2. Block all outbound traffic where the source address isn’t in your network.

Why should there be traffic trying to leave your network that is coming from some place else? This rule prevents someone from using you to spoof someone else.

3. Block all inbound and outbound traffic where the source or destination address is in these ranges:

• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16: this are globally non-routed as defined in RFC1918 - Address Allocation for Private Internets.

• 169.254.0.0/16: this is the “link local” block as defined in RFC3330 - Special-Use IPv4 Addresses and used by Windows for Automatic Private IP Addressing (APIPA).

4. Block all source-routed traffic.

The Internet’s infrastructure is so good that it always routes around outages; source-routed traffic these days is crafted traffic intended to accomplish some attack.

5. Block all fragments.

Attackers still use tools to create packet fragments to circumvent certain access control mechanisms. Note, though, that IPSec-based VPNs that use IKE for key negotiation won’t work now because IKE packets are very long (it’s the key lengths) and will always get fragmented. So if you’re allowing IPsec between the Internet and something behind your border router, you’ll need to skip this final rule.

HTH,
Stefaan

It has probably already been posted somewhere, but I thought that the following two settings on the ISA 2004 are worth reiterating…

1. Tired of the ISA sending NetBT broadcasts when DNS lookups fail?

By setting the key HKLM\System\CurrentControlSet\Services\NetBT\Parameters\NodeType to a value of 2 (DWORD) you are telling Windows to limit its name lookup efforts to the defined DNS and WINS servers (P-node). As a result, Windows will no longer wait for NetBT broadcasts to fail before reporting a name lookup failure.

This setting require a machine reboot to take effect.

It should be obvious that you can configure every internal host as a P-node, at least if you have a proper DNS/WINS infrastructure. For non-DHCP clients you’ll have to set the above registry key. For DHCP clients you can use the DHCP Server or Scope Option 046 WINS/NBT Node Type to set this parameter as shown in the figure below.

Note: do you see the DHCP Server or Scope Option 019 IP Layer Forwarding in the above figure? Clients shouldn’t be routers (hint…)!

2. MS05-019 fixed an ICMP MTU vulnerability that existed in Windows 2003.

Because the ISA team was aware of this issue before ISA 2004 shipped, they opted to give you a “safe by default” configuration since they had no idea if or when the Windows issue might be fixed. Unfortunately, it also has the side effect of limiting Windows to 576-byte packets on all interfaces, reducing network efficiency.

By setting the key HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery to a value of 1 (DWORD) you will remove this protection, or you can just delete the EnablePMTUDiscovery value, and regain the normal network efficiency. However, before removing this protection, make sure you got MS05-019 installed first or even better Windows 2003 SP1. Take note that ISA 2004 SP1 resets the EnablePMTUDiscovery value to 0, so you’ll have to change it back after installing ISA 2004 SP1.

This setting require a machine reboot to take effect.

HTH,
Stefaan

If you are looking for a really good starting point for trying to get a handle on what protocols and TCP/UDP ports are used by standard and Windows services, you should definitely check out the Microsoft Knowledge Base article http://support.microsoft.com/kb/832017. Don’t lose this one!

HTH,
Stefaan

We can’t stress it enough, understanding how the different ISA clients work and how they interact with the ISA server is a key requirement to get the most out of the ISA server. A lot of good information can be found in the ISA help file and Jim Harrison’s excellent articles over at http://www.isaserver.org/Jim_Harrison/. In my article How to pass IPSec traffic through ISA Server I explained on which layer in the TCP/IP protocol stack the different ISA client types work. Because that information can be very helpful, it is well worth a reprint as a separate blog. The following figure shows you a logical view of the TCP/IP protocol stack:

Note: keep in mind that a single host can be configured as a SecureNAT, Firewall and Web Proxy client without any adverse interaction between the client configuration settings.   

Web Proxy client

Unlike the Firewall client, the Web Proxy client is not a piece of software you have to install. It refers to client Web applications that are configured to use the ISA server as Web Proxy server. In most cases it will be a CERN-compatible Web browser. When a Web application is configured to use the Web Proxy service on ISA server, all HTTP/HTTPS requests for destinations not set for direct access are sent to the Web Proxy component on ISA server. That means that those requests are redirected by the Web application itself to the outbound Web Proxy listener on ISA server. In other words, the Web application will ask the transport layer to create a connection to the Internal IP address of the ISA server (a LAT destination) and TCP port 8080, assuming the default configuration of the outbound Web Proxy listener. Because the redirection is done by the Web application itself, we can say that the Web Proxy client is working at the application layer.  

Firewall client

The Firewall client is a very interesting piece of software and it works hand in hand with the Firewall service on the ISA server. In platforms that support Winsock 2.0, the client is implemented as a layered service provider (LSP). On other platforms, the client setup application renames the original Winsock DLL (wsock32.dll) and installs its own implementation of wsock32.dll. The Firewall client communicates with the Firewall service by using a dedicated connection called the Firewall client control channel. The control channel connection is established the first time it is needed. When a client application calls a Winsock function, the client DLL intercepts the call and decides, based on the specified request and the firewall service configuration files, whether the call is local or remote. Local calls are passed to the original Winsock implementation. Remote calls are redirected to the firewall service. In general, all TCP/UDP requests for non-LAT destinations are redirected by the Firewall client software to the Firewall service on ISA server. This is done by rewriting the original Winsock call and replacing some parameters, such as the destination IP address and destination port number, with those negotiated along the Firewall client control channel. Take note that the new destination IP address will be the Internal IP address of the ISA server. Because the redirection is done by the Firewall client software at the Winsock level, the Firewall client is definitely working at the transport layer.

SecureNAT client

Any computer that understands TCP/IP networking and has a default gateway capable of routing Internet bound traffic through the internal interface of the ISA server, is called a SecureNAT client. In a simple non-routed internal network, the default gateway on the clients should be configured with the IP address of the ISA internal interface. If you run a more complex routed internal network, check out Jim Harrison’s article Designing An ISA Server Solution on a Complex Network. Unlike the Web Proxy and Firewall client, no redirection or special processing whatsoever is done at the client site. That means that SecureNAT requests follows the normal packet processing of the TCP/IP stack and that all processing must be done at the firewall service on ISA server. In other words, the destination IP address will be the IP address of the requested destination and the protocol and port number (if applicable) will be the requested ones. Because it depends on the gateway configuration and network routing infrastructure, the SecureNAT client belongs to the network layer.  

Conclusion

With the above knowledge, you should be able to determine how a client host will act for a particular request, even if the host is configured as all three ISA client types.

HTH,
Stefaan

In my article How the FTP protocol Challenges Firewall Security I explain thoroughly how the FTP protocol works and how ISA server supports the FTP protocol. Although that article was written with ISA 2000 in mind, most of the stuff is still valid for ISA 2004, especially the behavior of the different ISA client types. It is crucial that you make yourself familiar with the three different ISA client types and how they interact with the ISA server. For more info about them, check out Jim Harrison’s excellent articles over at http://www.isaserver.org/Jim_Harrison/ and my blog A different look at the ISA Clients.

For SecureNAT and Firewall clients, ISA server supports fully the FTP protocol including active and passive FTP mode. Keep in mind that the FTP mode active or passive is determined by the FTP client itself. For Web Proxy clients, that means FTP over HTTP, ISA is CERN Proxy compatible what means that only FTP download is supported and that active or passive FTP mode is determined by a global configuration setting on the ISA server itself. By default the Web Proxy component on ISA will use active mode FTP. You can alter this behaviour by editing the registry on the ISA server to allow FTP requests made through the Web Proxy component to use passive mode. Check out the KB article HOW TO: Enable Passive CERN FTP Connections Through Internet Security and Acceleration Server 2000 for more info. Although it is not listed in the KB article, I can assure you that the NonPassiveFTPTransfer registry key is also valid on ISA 2004.

I strongly suggest that you test first your full FTP access with the standard Microsoft FTP command line client. If you can login and do a dir command, you have tested the FTP control and data connection. Take note that the Microsoft FTP command line client does not support passive mode. If you need to test passive mode too, use the free FTP command line client MoveIt Freely from Standard Networks. It support Secure FTP too. Once it is working with one of those clients, you can start to play with IE as FTP client.

The most important IE setting regarding the FTP protocol is the setting Enable folder view for FTP sites (Internet Options -> tab Advanced):

• If the IE setting Enable folder view for FTP sites is not checked and you have a rule allowing the FTP protocol, then you will be able to connect to the FTP server with the URL syntax ftp://username:password@FQDN but you will only be able to download files, not upload files. In other words, with this configuration setting IE is acting as a Web Proxy client.
  
• If the IE setting Enable folder view for FTP sites is checked and you have a rule allowing the FTP protocol, then the client must also be configured as a Firewall or a SecureNAT client, depending if you require authentication on the FTP rule or not. In both cases you will be able to connect to the FTP server with the URL syntax ftp://username:password@FQDN and you will be able to download and upload files, assuming the Read Only flag on the FTP rule is cleared. If the Firewall client is installed and enabled, this request is intercepted and handled by the Firewall Client. However, if the Firewall client is disabled or not installed, the request is sent as from a SecureNAT client. Which FTP mode active or passive IE will use is determined by the setting Use Passive FTP (for firewall and DSL modem compatibility).

HTH,
Stefaan