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)
    (shrug)


  • 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.

NLB: Dedicated IP Addresses Explained (An NLB Myth debunked?)

For information on Network Load Balancing – or “Wibbles” as we affectionately refer to it locally – it was called Windows Load Balancing Service, or WLBS until Windows 2000 – the definitive guide still appears to be nlbtech2.doc at the time of writing. I think there was a newer version for Windows Server 2003 that I can’t find any more (or did I dream it?), so for the purposes of this discussion, Nlbtech2 is the juice.


Anyway, when configuring a dual-NIC NLB cluster – one cluster NIC, one internal, a common slip is to configure the “dedicated” IP address on the non-clustered adapter. This doesn’t do anything. It doesn’t hurt, but it’s not working the way you might imagine it does. Here’s the money quote from The Source:


Network Load Balancing never load-balances traffic for the dedicated IP address. Instead, it load-balances incoming traffic from all IP addresses other than the dedicated IP address.


“Dedicated” in the NLB sense means “excluded”. NLB will (attempt to) balance every other IP address bound to an NLB-enabled NIC except the dedicated IP. So, on your NLB NIC, you have a maximum of one IP address that will not be balanced, and this is what you punch into the NLB UI as the “dedicated” IP if you need to create an exclusion.


The dedicated IP also needs to be bound first in TCP/IP properties (eg, it needs to be the address you see on the first page of the TCP/IP Properties dialog, which should be first in the list on the Advanced addressing page) so that connections originated on the NLB NIC originate from this unbalanced IP address, not on a clustered IP – which could be balanced to another node when the response arrives back for the source IP(!). (To pick which NIC will initiate connections to non-cluster hosts, you can fiddle the interface metrics).


So, why have a “Cluster” IP if all IP’s except the dedicated IP are balanced? Think of it as the primary cluster IP – it’s basically used to determine the MAC address of the cluster, so all cluster members with the same primary IP can spot each other and converge (the heartbeat packets (ethernet 886f) also contain the cluster primary IP – it’s not just used in the MAC).

XPSP2 Resources for IT Pros

A friend of mine that works in the IT industry just stunned me by asking whether there was anything new in SP2 for Windows XP – seems we haven’t quite got the message out there enough yet – be prepared for this one, it is not just another Service Pack.


So, for him and you, I’ve linked the Microsoft.com page that conveniently lists the resources available for SP2 for IT Pros:


http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/winxpsp2.mspx


Developer-focused info is here:  http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx


I don’t care what anyone else tells you – in my opinion, this is Windows XP – The Second Coming. It’s a pretty major product upgrade, and you need to have at least a rough idea of what’s happening in it if your professional life intersects with it.


Enjoy!

DNS Resolution for Internet-Facing Servers: Clingy

NB Ahead of time, anytime I’m referring to a “primary” or “secondary” DNS server in this blurb, I’m referring to their relative positions on the client, not the “primary/master/secondary/slave/AD-integrated” mode of the server.


You might have spotted that I spend a reasonable amount of time with ISA and Networking, and that I don’t mind writing about it. This is something that comes up occasionally:


DNS resolution in Windows operates on the principle that all servers bound to a given adapter agree with each other all the time. This is why you shouldn’t mix ISP DNS and internal DNS on the same adapter – it’s not healthy, and actual results may vary.


Windows’ DNS resolver (aka “DNS client”, but not necessarily the DNS Client service (dnscache)) is quite exhaustively documented in the Windows Resource Kit, but the short version is this:


For each adapter:
 – While the topmost DNS Server in the list responds to queries, use only that DNS Server.
 – If the highest-priority DNS Server on an adapter doesn’t respond, find a responding DNS Server and use it instead (eg, until it doesn’t respond).
 – If a response is ever “Name does not exist”, cease all queries on this adapter.


So, The Golden Rule: All DNS Servers On The Same Adapter Should Really Agree With Each Other.


Now, this can lead to interesting situations: If the topmost DNS fails to respond to a query, the second DNS server is queried by the client. If the second server responds, and keeps responding, then the second server is the DNS client’s new best friend, and it gets a bit, well, clingy, (or at least it used to (XP was modified in SP1 / 2000 in SP3). Before these hotfixes, name resolution would “stick” to the currently-responding server.


If you follow the golden rule and only point one adapter’s DNS to one set of DNS servers, you’re fine, this generally won’t affect you in an “it’s broken” kind of way. You might end up talking to the secondary for longer than intended (eg, until reboot), but that’s generally OK for a client and only mildly annoying for a server*.


However, if you make the mistake of mixing DNS sets on the same adapter – for example, AD DNS and then ISP DNS as primary and secondary, you’ll probably end up with some weird, glitchy behaviour.


For example, if your internal DNS server is shut down, rebooted or otherwise has the cable kicked out for a short while and the DNS client does a query, for the next 15 minutes (or forever, without the above fixes), it’ll only talk to the ISP DNS server. If it’s asking questions about the Internet, that’s no problem, but if it’s asking about AD, it’s going to be told “your domain does not exist”, which might make it understandably upset. It won’t ask for a second opinion from other DNS servers, because it just got an authoritative response, and the response was “no“, which means that the query stops at this point, and your client/server/IP-enabled refrigerator can’t find the AD domain any more. Much Fun Will Ensue*.


For a single-NIC ISA Server that’s doing the cache-only thing, this means that you only have the following options:



  • Use Internal DNS for External Name Resolution

    • If your internal DNS infrastructure can do Internet names, just point the DNS on the adapter to the internal DNS server, and you’re done.

  • Use Internal DNS and use an Upstream Proxy

    • One of the cool things that a proxy can do is resolve names on behalf of a client. This works when your proxy is routing to an upstream proxy too. Fix suggested:
      292018 Slow Response from Downstream ISA Server Using Web Proxy Chaining
      http://support.microsoft.com/?id=292018

  • Host a DNS server on the ISA box itself, point ISA to itself

    • Make the ISA a Secondary Server for the internal zone, and use Forwarders or Root Hints to resolve internet names.

If ISA is dual-homed, there’s generally no problem because you can have two sets of disagreeing DNS Servers – Internet DNS on the external NIC, internal DNS on the inner NIC. Voila.


(Updated with an example).