ISA 2000: Web Publishing and the Pesky Client IP Address
ISA 2000: when you publish a web server, the requests in its IIS logs all appear to come from the ISA Server computer.
This is normal. What happens under the covers is that the client computer connects directly to the ISA Server, which it believes is the Web server (you install the Web Server's Server Authentication certificate including the private key on the ISA box for SSL).
ISA's Web Proxy service accepts the HTTP/SSL connection, optionally preauthenticates and authorizes the user, checks the request for compliance with Web Publishing destination sets, checks it for correctness and runs any web filters, then initiates a new connection to the back-end IIS server to pass the data to it. Quite a bit of work is involved; it's not just a NATted port.
There are several benefits to Web Publishing over sitting your web server on the Internet:
- ISA Server can pre-authenticate and pre-authorize the user, so that before the web server even sees a request, ISA knows who the user is and has granted/denied them access based on its policy.
- Multiple Web servers can be published using the same listener (IP)
- Web Publishing rules and Web Filters (like URLScan for ISA from Feature Pack 1) can be applied to the request so that the request is as polished as possible by the time it hits the back-end.
Using URLScan on ISA also allows central configuration for scanning - especially useful if you publish many similar servers.
- Link translation is possible (another Feature Pack 1 web filter goodie (if you also need path/tail translation, look here) - but also necessary for some applications, so I'm not sure if it really counts as a benefit per se).
The price for all this is that the Web Server won't see the original client's IP address, and so the IIS logs won't show the source IP of the client, only of the ISA Server. The ISA Server's Web Proxy logs (WEBEXTnnnn in the Program Files\ISA Server\Isalogs folder) will show the source IP (as much as it's ever possible to get a source IP), and marrying the two up can show you who did what when, and from where.
Web Publishing works in Cache-Only or Integrated mode, with one or more NICs.
At the other end of the scale is Server Publishing, which is basically just port forwarding. Better than no NAT, but the client hits the IIS server more-or-less directly; the session isn't terminated or scanned by ISA, it's just port forwarded.
You would need to use Server Publishing if:
- You absolutely need to see the Client IP address on the IIS server.
- You need to use Client Certificates for authentication - the web publishing process can't impersonate a client certificate because it doesn't know the client's private key.
The big limitation here (other than all the stuff it doesn't do) is that because there are no application-layer smarts to this method, you can only publish a single internal IP to a single external IP address (no port sharing), and you can't mix and match multiple server contents on the published website.
The published server also needs to know how to route requests to the Internet through the ISA Server, since it's essentially acting as a SecureNAT client - so plan on using the ISA box as the default gateway (if not the default gateway, make sure the client's gateway knows about it) for this method.
Server Publishing requires two NICs, and is available in Firewall-only or Integrated mode.
ISA 2004 offers a hybrid Web Publishing option, which looks like a best-of-both-worlds-with-only-a-few-limitations method.