Added to my RSS readerI have recently completed a consolidation / redesign of an ISA2006 infrastructure.The resulting platform publishes multiple web farms both internally and externally. Two factor authentication for the external clients via Radius was a requirement. The internal clients were presented via an internal firewall cluster with the external clients presented via an edge firewall cluster with ISA farm sitting between the two firewall clusters.
Like this:
There were a number of problems that need to be addressed and so I have decided to highlight these. Some are common to all load balanced environments such as application state. Others only arise with multi-tier firewall / load balancer environments such as routing/firewall spoofing issues.
Network routing
One of the key requirements business have is to measure the popularity of the web applications that they publish. This can be for a large number of reasons such as to establish the effectiveness of an advertising campaign, to track usage trends or even inform strategic decisions regarding the organisation future. The Information that is available from data recorded in the logs is therefore strategically and operationally valuable.
So we want the clients details recorded in the web server logs. Easy right? That’s done by default…..
Internet user requests a web page via the published IP hosted by the ISA servers. ISA Server passes the request through to the web back-end. The response is sent (to the client) as shown below. Everyone’s happy
Problems!
So now we consider the Internal users.
The INT VLAN has a static route that enables the internal client request to be routed to the ISA server EXT VLAN. The ISA Server publishes the request to the web servers. The web servers send the response to the client IP which in this case is a VLAN with a route via the Internal Firewall. the Internal Firewall process the response expecting the response to be routed to the ISA INT VLAN. The Firewall closes the connection. The response is considered to be spoofed traffic (see below) due to the mismatch in source and destination IPs. The destination port on the firewall for the response is different to the port that the request was received on.
Firewall Anti-Spoof checking
This mechanism protects against activity from spoofed or forged IP addresses, mainly by blocking packets appearing on interfaces and in directions which are logically not possible.
This diagram shows the routing problem
In order to resolve this issue, the Internal Client IP is replaced by the ISA Servers Internal NIC IP, NATing the client behind ISA servers NIC address.
So now when you look in your web server logs every request seems to come from your ISA server Internal NIC.
Immovable object meets irresistible force
So the business wants the data but the network topology prevents this from happening. What do you do?
You have several options
Don’t Log at the Web Servers
Use ISA Server logging capability to provide the information you need.
ISA server logs a huge amount of information (full list here) . ISA Server also logs to SQL Server and Microsoft provide example reports for SQL Reporting Services . However it maybe that you must get the client IP to arrive at the web server.
Modify the HTTP Header
The industry standard approach is to insert the X_FORWARDED_FOR in the http header. Using this method offer the ability to get the client IP recorded in the web server log as it is part of the HTTP request header.
ISA Server does not natively support this for two reasons.
1) X_FORWARDED_FOR is not a ratified standard. There is no Internet Engineering Task Force (IETF www.ietf.org) documentation.
2) The value recorded in the HTTP Header is easily spoofed and is not authenticated so cannot be relied on to actual represent the clients IP.
There is a plug-in for ISA Server 2004/2006 that inserts the value into the HTTP header.
http://www.winfrasoft.com/X-Forwarded-For.htm
And an article about how to use it here
Alternatives
There are other options but they may or may not be viable. If you are building the solution from scratch design out routing issues. Another option is to utilise functionality of other devices in you network topology. E.G. Cisco ACE (Application Control Engine) Load Balance modules can insert the Client IP into the HTTP request.
In this Infrastructure* I would remove the ISA servers and use Zeus ZXTM v5.1 instead. The Internal and External Firewalls provide the TCP/IP packet inspection, so actually reduce the ISA server farm to a Proxy / Web Publishing solution. This is ZXTM’s core capability and for this environment there is no comparison. ZXTM’s load balancing, traffic inspection and modification is far superior to ISA Server 2006 R1. ZXTM v4.2 and above automatically adds a value "X-Cluster-Client-IP" to HTTP Header which will be recorded in the web server logs.
* There are a number of reasons for this not just the Client IP. The next post includes more of these reasons
In the next post I will look at Load Balancing, Application State and DNS.