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:
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:
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.
I find this to be a real problem with web publishing under ISA, a lot of valuable data is lost when you don't know the client ip. I am too lazy to do it, but why not get ISA and IIS to log to the same sql server, then do some kind of fancy DTS to the data to pruce a real-style log file. Then we could have our precious stats.
um pruce = produce
Question: We absolutely must have the client IP address on the IIS server. We are running server publishing rules and are thinking about switching to web publishing rules to achieve this. However, we have ISA configured as an array. I've heard that using server pub rules in an ISA array configuration will prevent IIS from seeing the client IP address. Can anyone verify? Thanks.
Server publishing already puts the client IP in the IIS logs; Web Publishing is what doesn't. If you're not seeing a real client IP address, you might be behind more than one reverse proxy (is that what you mean by an array? In ISA terms, an array implies parallelism, not chaining), in which case you're potentially out of luck - if the IP is gone by the time it gets to the ISA Server, there's nothing ISA can do about that...
It modifies http(s) request header and adds variable IPREMOTEADDR containing client IP address to it.