In my article How to build an ISA firewall lab with Virtual PC 2004 I wrote that when you start up the ISA virtual machine you might see the following warning message:

If that’s the case, the Virtual PC configurator did not assign correctly a MAC address to the network adapters for the virtual machine. To workaround that problem you can manual assign a MAC address to the network adapters as explained in my article. However, if you like to know why this can happen and how to correct that problem, check out the Virtual PC Guy’s WebLog Virtual PC SP1 Networking problems (address “00:00:00:00:00:00″ failed to initialize).

HTH,
Stefaan

ISA Server 2004 SP2 makes some changes to the way that destinations specified for direct access are handled. This is documented in KB903746 Changes that are made to the Cache Array Routing Protocol (CARP) in ISA Server 2004 Service Pack 2, particular in the section Clients in a branch office cannot route requests for internal destinations through the local ISA Server computer. These changes have been made to facilitate some typical branch office scenarios. However, by doing that the ISA team broke the way people did use the “Directly access these servers or domains” list to solve some common web proxy and authentication problems due to badly written web client software.

Back in Februari 2006, I logged a case with Microsoft PSS to fix that problem. Very soon I got a private fix that solves the problem without losing the new branch office features introduced by ISA 2004 SP2. However, that private fix was broken with KB916106 Update for HTTP issues in Internet Security and Acceleration Server 2004 Service Pack 2 because the private fix didn’t make it through the usual Microsoft approval process at that time. On July 17, 2006 Microsoft finally released the Knowledge Base article KB920715 Web Proxy clients do not directly access a Web site that you enter in the “Directly access these servers or domains” list in ISA Server 2004 SP2 with a reference to a hotfix described in the article KB920716 Description of the ISA Server 2004 hotfix package: June 6, 2006 to solve that problem.

I have requested that hotfix, installed and tested it in my lab and it effectively solved the “Directly access these servers or domains” issue mentioned above. The key is that in order to get the pre-SP2 behavior, you should specify the destinations as a URL instead of as an FQDN. The generic format for a URL is <Protocol>://<FQDN>:<Port>/<Path>. Therefore, as explained in the article KB920715, you should specify *.domain.tld/* for a whole domain. For a single server the syntax */host.domain.tld/* should do the trick.

For those interested in the bits and bytes, here is what has changed so far in ISA 2004 concerning direct access. It might be useful to read first the article Proxy Client Autoconfig File Format in order to better understand the predefined functions used in the wpad.dat file or the routing script.

If you carefully look at the content of the wpad.dat file or the routing script, you will see three major functions used in the decision process for direct access:

• function MakeIPs(): defines the IP ranges which possible should not be redirected to the web proxy server.
• function MakeNames(): defines the FQDN’s which possible should not be redirected to the web proxy server.
• function FindProxyForURL(url, host): contains the script that IE uses to determine if a destination should be redirected to the web proxy server or not.

With pre-SP2, if direct names and direct IPs are configured in the exception list, we first check if the requested site belongs to the direct names list and if YES then the script returns a DIRECT route immediately. If the requested site was an IP address, then the direct IPs list was used instead. Take note that there was no dependency whatsoever between the direct names and IPs lists. Here is an extract of the function FindProxyForURL(url, host) obtained with SP1:

It was common practice to specify standard the internal domain as *.domain.tld, the internal network ID and the network ID 127/8 in the “Directly access these servers or domains” list (http://www.isaserver.org/IsaNews/copylattowebproxy.html). In that way, any destination that must be considered local was accessed directly, regardless if the request was made by FQDN or IP address. Of course, some other sites such as the Hotmail (*.hotmail.com), the MSN (*.msn.com) and the Passport (*.passport.net and *.passport.com) domains are very popular members of the list too.

With SP2, the above behavior has changed considerable. If direct names and direct IPs are used, we still check if the requested site belongs to the direct names list. If YES we are getting a DIRECT route immediately ONLY if there is NO direct IPs configured. If there are direct IPs, then we try to resolve the requested site name to an IP. Then we are returning a DIRECT route ONLY if this IP belongs to the direct IPs list. Take note that the behavior was not changed if the requested site was an IP address. Here is a code snippet of the function FindProxyForURL(url, host) obtained with SP2:

The problem with the SP2 behavior is that it is impossible for an ISA administrator to enumerate all possible IP addresses belonging to all domains he has configured in the “Directly access these servers or domains” list. Therefore, there was nothing else we could do but removing all IP addresses from the list. Moreover, if we have to add selected IP addresses such as 127.0.0.1 to the list we have to do it as FQDNs, not as IPs. Obviously this workaround can’t be considered a long term solution.

Now with the KB920716 hotfix, there is a clever way to regain the pre-SP2 behavior without losing the new branch office features introduced by ISA 2004 SP2, although you should specify the destinations as a URL instead of as an FQDN (e.g. *.hotmail.com/* instead of *.hotmail.com). In my opinion, that’s a small price to pay. Here is a code snippet of the function FindProxyForURL(url, host) obtained with SP2 + KB920716:

The fix is the new and second if statement if(shExpMatch(url, DirectNames[i])) following the old and first one if(shExpMatch(host, DirectNames[i])). If you specify a destination as a URL then the first if statement will not catch the new format. In other words, we will never have a match for a URL on the first if statement and therefore the second one will evaluate the entry instead. If a match is found on the second if statement then the script returns a DIRECT route immediately, just as it was before SP2. As a result, we can apply again our common practice to specify standard the internal domain as *.domain.tld and the internal network ID in the “Directly access these servers or domains” list. Take note that from SP2 onwards, if IP addresses are added to the list than the address range of 127.0.0.0-127.255.255.255 (127/8) is automatically added to the list.

HTH,
Stefaan

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