14120 Errors; Discussion and Solution

14120 Errors,

or

“ISA Server Isotropic IP Bounce”

Last Updated: 6/21/2002

By Jim Harrison

Background:

            ISA Server is firewall / proxy application that is built on Windows 2000 technology and is designed to work very closely with that functionality.  As a result, any of the behaviors that Windows exhibits and ISA is dependent upon can become magnified across the clients that are served by an ISA server.  In particular, name resolution plays a large part in how ISA and its clients function.  This is one of the primary causes of the 14120 errors that ISA reports.

 

If you’re looking for a tutorial on how to set up the ISA server before you install ISA, then you want this article.

 

Note:  all ISA MMC screen shots in this article are made using the ISA Management MMC in Advanced mode (I don’t like “Taskpad”).

Definitions: 

DNS – Domain Name Services; the services residing on a computer that are able to answer a name resolution query.  How they answer that query depends on many settings for that server.

FQDN – Fully Qualified Domain Name; this is a computer name that indicates its logical association by virtue of the domain structure associated with the name.  For instance, www.microsoft.com indicates a host named “www” that lives in the domain “microsoft” under the top-level domain “com”.  These names are always separated by dots “.” and are also known as “dotted decimal”.

LAT – This is the Local Address Table; a list of IP addresses that the ISA considers “trusted”, or “internal”

LDT – This is the Local Domain Table; a list of domain names that ISA considers internal

LAT host – This is a computer that operates in the subnet that is defined in the LAT.  All traffic to and from this host is NAT-ed through the ISA

ISA Clients:

SecureNAT – This a LAT host that has a default route through the network to the ISA as its only means of Internet communication.  In a simple network (no routers), this client has the ISA primary internal IP as its default gateway.  In a complex (routed) network, this gets a bit tricky.  This client will also be a prime cause of 14120 errors if it can’t resolve published services to internal IP addresses.  Remember; SecureNAT clients don’t use ISA to resolve names, they have to be able to do it themselves.

Firewall – This is a LAT host that has the ISA Firewall client software installed, enabled and the application is using it. 

Web Proxy – This is simply an application (IE or other web-enabled application) on a LAT host that uses proxy requests to the ISA outbound web listener IP and port to reach the Internet. 

Note:  These clients normally depend on ISA to resolve the names of the hosts they ask ISA for, although there are ISA settings that can modify that behavior under very specific circumstances.

Discussion:

The “14120 error”, as it’s commonly known, is a result of the ISA server’s packet filtering service being asked to create a route through the ISA that begins and ends in the ISA external interface.  The LAT table is normally derived from the Windows routing table (which includes the external IP), and this is why the 14120 event log entry makes reference to “a problem in either the LAT or the Windows routing table”. 

The question on everyone’s minds is, of course, “what can I do about it?”  To fully understand this question, we have to examine the “why” in terms of each ISA client type.

 

When one host needs to contact another host, it must first resolve the name of the other host to an IP address.  How each of the various ISA clients does this differs:

·         SecureNAT client requests: ISA never resolves names on behalf of this client.  When this client resolves hostnames, it uses the DNS server entries in its TCP/IP settings to provide name resolution.  ISA protocol rules can affect this client’s ability to resolve names, but that’s the extent of ISA involvement in SecureNAT name resolution

·         Web Proxy client requests: ISA always resolves names on behalf of the client.  When a host makes a Web Proxy request to ISA, it makes a TCP connection to the ISA outgoing web listener port and passes a “connect” request for the site it wants.  ISA must then perform name resolution so that it can make a connection to the server being requested.  The thing to bear in mind here is that the LAT host never actually talks to the remote server; ISA intercepts the traffic from each host and repeats it to the other.  This is why the LAT host doesn’t need to worry about resolving the name of the remote server.

·         Firewall client requests:  ISA may or may not resolve names on behalf of the client, depending on the settings present in Client Configuration, Firewall Client, Application Settings.  The settings for each individual application and those in the category of Common Configuration will determine how name resolution functions for all or a given application.  If the Common Configuration section contains a setting of “Name Resolution=L”, then the Firewall client will behave the same as a SecureNAT client where name resolution is concerned unless the app being used for testing has a setting that differs from this one.

·         ISA DNS cache: ISA provides an additional name resolution cache for Web proxy and Firewall clients that is discussed in two previous articles on ISA client behavior:

SecureNAT / Web Proxy Clients

Firewall Clients

This cache was included in the ISA Web proxy and Firewall services to help avoid issues that arise when external DNS servers become unavailable, but it also provides an unexpected side effect of holding name-to-IP mappings longer than the TTL may specify, causing name resolution failures in rare cases.

 

The point to bear in mind is that if ISA is resolving names for the client, the DNS entries and their order in the Windows TCP/IP settings on the ISA server will determine how ISA will respond.  (hint-hint)

 

When the internal host has the address it needs, it then proceeds to create a connection to the remote host.  This process also occurs differently for each client:

·         SecureNAT client requests: This client makes the connection to the remote IP address as if ISA were not there.  If you were to observe the communications that occur between a SecureNAT client and the remote host, you would see that the SecureNAT client traffic is directed to the remote IP address of the remote host, not to ISA.  It depends on ISA protocol rules and the functionality of the ISA packet filter to provide the proper translation of source IP and ports when it forwards the traffic so that the remote host can respond to the SecureNAT client (if required).

·         Web Proxy client requests: ISA intercepts the traffic between the LAT and remote hosts and acts as intermediary between them.  The LAT and remote hosts never actually talk to each other; they talk to the ISA server and it passes the traffic to the opposite end as if it were the originator.  Generally speaking, only the LAT host understands that it is talking to a proxy; the remote host sees ISA as the client.  All communications between them are “proxied” in this fashion.  It’s also this proxy functionality that allows ISA to route even in the face of 14120 errors.

·         Firewall client requests:  This client routes traffic according to the ISA settings in Client Configuration, Firewall Client, Application Settings.  There are many configuration options for Firewall clients, and they all determine how both the Firewall client and ISA interact with regard to traffic for a particular application.  Depending on those settings, a LAT host can acts as a Firewall or SecureNAT client, depending on the application being used and the ISA settings involved.  The Firewall client article deals with this in more detail.

 

Here’s where it gets nasty.  If the connection request to the “remote” host is actually to a server being published by ISA, it presents a unique problem for the Packet Filter service.  In every case not involving the Web Proxy service, the Packet Filtering service has to manipulate the packet header as it passes through.  For those who may not be familiar with what happens to a packet as it crosses a NAT device, read on.  If you’re already conversant with these concepts, run, don’t walk to the “14120 Errors” section.

 

Basic TCP/IP routing

In every case, traffic between hosts is performed using at least two levels; Ethernet and IP.  These are normally referred to as Layer 2 and Layer 3 protocols, respectively.  Generally speaking, switches operate at L2, while routers operate at L3, although those lines are becoming more blurred in recent devices.  When a TCP/IP packet is constructed, it contains (at a minimum) the following routing information:

 

 

Source

Destination

IP Address

192.168.0.2

123.123.123.123

MAC Address

00-00-00-00-00-00

11-11-11-11-11-11

 

Normal NAT behavior – When one host wants to talk to another, it places the IP address of the remote host in the Destination IP field and its own IP address in the Source IP field.   We assume that name resolution has provided the LAT host with the destination IP already.

For the following discussion, assume the following facts:

1.      ISA

o        ext IP – 123.123.123.123

o        ext MAC – 33-33-33-33-33-33

o        int IP – 192.168.0.1

o        int MAC – 22-22-22-22-22-22

2.      LAT Host

o        IP – 192.168.0.2

o        MAC – 11-11-11-11-11-11

3.      Remote FTP server

o        IP – 213.213.213.213

 

The LAT host constructs a packet like this:

 

 

Source

Destination

IP Address

192.168.0.2

213.213.213.213

MAC Address

11-11-11-11-11-11

22-22-22-22-22-22

 

The destination IP address of the packet represents the remote server, while the destination MAC address is the ISA internal interface.   When ISA receives this packet, it understands that the source data has to change so that the remote server can respond to the traffic.  ISA incorporates a NAT editor to perform this task (as does every NAT device).  ISA changes the packet so that it looks like this:

 

 

Source

Destination

IP Address

123.123.123.123

213.213.213.213

MAC Address

33-33-33-33-33-33

(next L2 device)

 

..bear in mind that while ISA is changing the packet, it’s also updating an internal traffic table so that when return traffic arrives, it knows how to direct it back to the correct LAT host.

 

Return traffic from the remote FTP server would look like this:

 

 

Source

Destination

IP Address

213.213.213.213

123.123.123.123

MAC Address

(last L2 device)

22-22-22-22-22-22

 

.. when the ISA NAT editor is done with it, the LAT host receives a packet the looks like this:

 

 

Source

Destination

IP Address

213.213.213.213

192.168.0.2

MAC Address

22-22-22-22-22-22

11-11-11-11-11-11

 

..so you can see that the SecureNAT client has every reason to believe that it’s actually talking directly to the remote FTP server

 

14120 Errors – When the LAT host makes a request for an ISA-published resource, ISA balks; and with good reason, too.   Let’s examine this process.  Remember; name resolution has already provided the LAT host with the destination IP and in this case, it’s an ISA external IP.

·         For the following discussion, assume the following facts:

1.      ISA

o        ext IP – 123.123.123.123

o        ext MAC – 33-33-33-33-33-33

o        int IP – 192.168.0.1

o        int MAC – 22-22-22-22-22-22

2.      LAT Host

o        IP – 192.168.0.2

o        MAC – 11-11-11-11-11-11

3.      ISA-Published FTP server

o        ext IP – 123.123.123.123 (ISA-ext)

o        int IP – 192.168.0.3 (int server)

 

The LAT host constructs a packet like this:

 

 

Source

Destination

IP Address

192.168.0.2

123-123-123-123

MAC Address

11-11-11-11-11-11

22-22-22-22-22-22

 

When ISA receives the packet, the NAT editor goes to work on it and produces the following result:

 

 

Source

Destination

IP Address

123.123.123.123

123.123.123.123

MAC Address

33-33-33-33-33-33

33-33-33-33-33-33

 

The problem is clear; ISA is being asked to create a packet where the source and destination addresses as identical.  Since th only comparative data ISA has to evaluate this situation is the LAT and the Windows routing table, the error it generates points you to both.

 

Web Proxy Response to 14120 – I know what you’re thinking; “why does the Web Proxy service know how to handle this and the Firewall / Packet Filtering services don’t?”  Remember that the Web Proxy Service isn’t acting as a router, but as a server for the internal client and as an HTTP 1.0 client to the server.  What this boils down to is that ISA isn’t routing the traffic; it’s terminating the internal requests and creating new traffic to the real server.  Since the connection doesn’t require NAT-ing the traffic, the Web Proxy service is able to correct what would be an otherwise intolerable packet addressing scheme and pass the traffic.

 

OK, Fine; so how do I fix this? – The short answer is “take control of and clearly define your name resolution scheme.”  The long answer is a bit more complex and requires that you revisit your initial ISA installation as well as understanding your LAT clients’ name resolution methods.

The Fix:

ISA functionality is heavily dependent on proper configuration of the ISA server itself.  If the ISA has difficulty resolving names, or resolves them incorrectly, so will the Web Proxy and Firewall clients.

 

  • Name Resolution – This is really the heart of the 14120 issue.  You have to provide reliable DNS services in order for ISA to resolve both internal and external FQDN on behalf of Web Proxy and Firewall clients.  This should ideally be two separate DNS servers.  You can install DNS services on the ISA server, and it’s actually a good idea to do just that.
  • DNS Server Configuration – The DNS setup I use and recommend is found in my article DNS for ISA Server as “Multi-purpose internal DNS”, with the “external DNS” actually installed on the ISA itself.  It provides for internal name resolution first, followed by forwarding to the “external” DNS service, while saving on server costs.

·         ISA Server Configuration – If ISA has trouble resolving names, so will the Web Proxy and Firewall clients.  I know I’ve said that about 57.2 gabillion times in this article, but you can’t afford to forget it.  Since ISA depends on W2K name resolution, the ISA IP settings are critical.  Ideally, ISA will have a choice of DNS servers to use; this ensures that if one fails to respond, then ISA has an alternate DNS server to draw on.

·         ISA IP settings – Given the order of operations for W2K name resolution (discussed in detail in the W2K Resource Kit), you should provide internal and external DNS services for ISA.  The simplest way to do this is to install DNS services on the ISA itself to provide name resolution for external clients and create an internal DNS server for resolving internal host names.  The details of those settings for ISA are outlined in my article Configuring ISA Server Interface Settings.  What isn’t detailed there is the DNS setup that supports those settings. 

·         Local Address Table – this is critical information for ISA.  It allows:

o        ISA to make informed decisions as to whether or not filtering should be applied to a packet as it travels through the ISA server. 

o        Firewall clients to understand the difference between “internal” and “external” networks.  This data is critical for the Firewall clients to make efficient use of ISA.  There’s no need for the FW client to ask ISA for a connection to an internal resource, is there?

 

 

·         Local Domain Table – This is critical information for ISA and the clients it serves.  Any domain that is entered here causes two things to happen:

§         Web Proxy and Firewall clients attempt to resolve that domain name themselves (not via the related ISA service)

§         Web Proxy clients make their requests directly to any server in that domain, ignoring ISA proxy services

§         Since the entries here have the effect of making the internal client ignore ISA, it becomes a useful tool in the defense against unwanted 14120 entries (as if there were any you wanted to see).

 

 

Generally speaking, any external domain that is reachable internally should be listed here.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top