• ISA Server and Beyond Book and ISA Server and Beyond Seminars Now Available
• Feature: Special Outbound Access Control Issues: SSL
• ISAServer.org Learning Zone Articles of Interest
• KB Articles of the Month
• Post of the Month
• ISA Server Links of the Month
• Ask Dr. Tom

1. ISA Server and Beyond Book and ISA Server and Beyond Seminars Now Available

By Thomas W Shinder ISA Server and Beyond is now available! ! We've included tons of stuff on DMZs, firewall chaining, hierarchical Web caching (Web Proxy chaining), SSL bridging, SSL publishing, OWA, Secure IMAP4/SMTP/POP3 publishing, and publishing services on the ISA Server itself! Most of this stuff isn't described anywhere else. If you're ready to take ISA Server 2000 to the next level, then this is a book you must have. Click here to order ISA Server and Beyond from Amazon.com today! Are you wrestling with ISA Server? Need to get your head around what makes ISA Server tick? If so, consider my one-day seminar on ISA Server. I'll bring meaning to inbound and outbound access, ISA Server client types, Web and Server Publishing, and VPN Servers and VPN Gateways. I guarantee you'll learn something new and maybe even have fun along the way. The next seminar is May 9th here in Dallas, Texas. Click HERE for more info and I hope to see you there!

Click here to Order your copy today

2. Special Outbound Access Control Issues: SSL

Many network administrators think of firewalls as devices aimed at keeping the bad guys out of the internal network. While its true that a firewall that doesn’t keep unwanted external users out of your network isn’t much use, a firewall like ISA Server can do much, much more than just keep the bad guys out. The basic mechanism behind preventing unwanted inbound access is dynamic packet filtering. You can selectively allow inbound access by using packet filters, Server Publishing Rules and Web Publishing Rules. If you don’t create one of those three things to allow external users into your network, they won’t get in, at least not through ISA Server.

Inbound access control is very easy when compared to outbound access control. Outbound access control separates ISA Server from the rest of the firewall pack. You can get very, very granular in terms of outbound access control. By default, there is no outbound access. That’s why we often hear complaints that “I’ve installed ISA Server and now I can’t get to the Internet!” While such statements are issued as complaints, I always interpret them as compliments because it shows Microsoft has shipped their premiere firewall in a locked down state.

There are three basic prerequisites for outbound access:

1. There must be a Site and Content Rule allowing access to the site, and optionally, the type of content
2. There must be a Protocol Rule to allow outbound access to the protocol the user requires
3. The user must have permission to access the Site and Content and Protocol Rules

For example, suppose one of your users needs access to the Web. What’s required? First, a Site and Content Rule must be in place to allow that user access to the Web site he wants to go to. If he wants to go to http://www.microsoft.com/, there must be a Site and Content Rule that allows him to go to http://www.microsoft.com/ and there also must not be a Site and Content Rule that denies him access to http://www.microsoft.com/. Deny Rules override allow rules, so even if there is a Site and Content Rule that allows the user access to http://www.microsoft.com/, if there is a Deny Rule, the user will be denied access.

In addition, the user must have access to a Site and Content Rule that allows him access to the type of content he wants to access. If the user wants to access an executable file on the site, the user must have access to the MIME type associated with that file. Note that you, as the ISA Server administrator or user behind the ISA Server, have no control over the MIME type sent by the remote server. If the user does not have access to the MIME type (when using HTTP tunneled FTP, file extensions are used when connecting to FTP sites), or if there is a rule that specifically denies the user access to the particular MIME type, then the user will not be able to connect to the site. Even if the user is allowed access to the site, if the user doesn’t have access to the MIME type (or file extension, if HTTP tunneled FTP is used), then access is denied.

There must be a Protocol Rule that allows the user outbound access to TCP port 80 (assuming the user is connecting to a site that uses the well-known HTTP port). If the user doesn’t have access to a Protocol Rule that allows outbound TCP port 80, or if there is a Deny Rule that prevents the user outbound access to TCP port 80, then it doesn’t matter if there is a Site and Content Rule that allows the user access to the site. The connection will be stopped at the Protocol Rule level.

Finally, Site and Content Rules and Protocol Rules can be assigned to:

• Everyone
• Specific Users and Groups
• Specific IP addresses (via client address sets)

When a rule is assigned to Everyone, its often referred to as an “anonymous access rule”. For example, the default Site and Content Rule (in stand-alone ISA Servers) is an anonymous access rule because it allows everyone access to the Rule. You can prevent anonymous access by insuring that all of your Site and Content Rules require a specific user account, a specific group, or specific client address set to gain access to the Rule.

With this as a background, let’s consider a of special case: SSL connections. I want to discuss SSL connections with you today because a lot of outbound access questions are generated by this subject.

ISA Server supports outbound SSL connections via the Firewall/SecureNAT client or via the Web Proxy client. If the Firewall/SecureNAT client communications are intercepted by the HTTP Redirector Filter, then they also access the Web via the Web Proxy service because the HTTP Redirector forwards those requests to the Web Proxy service. Since the default setting for the HTTP Redirector Filter is to forward requests to the Web Proxy service, all outgoing HTTP and SSL requests are handled by the Web Proxy service (unless you change the defaults).

Many people write in and say they can’t connect to an SSL site using a port other than TCP 443. The reason is that by default the Web Proxy service supports “tunneling” outgoing SSL requests to TCP 443 only. The term “tunneling” is somewhat of a misnomer for Firewall and SecureNAT clients, because the tunnel is only created by the Web Proxy client when it tunnels the SSL requests inside the HTTP tunnel created between the Web Proxy client and the Outgoing Web Requests listener at TCP 8080 on the internal interface of the ISA Server. The Web Proxy service removes the tunnel header and forwards the request as SSL.

The ISA Server Help File explains it this way:

“SSL tunneling:

1. When a client requests an SSL object from a Web server on the Internet, ISA Server sends the connect request

 https://URL_name

2. The following request is sent to port 8080 on the ISA Server computer:

CONNECT URL_name:443 HTTP/1.1

3. ISA Server connects to the destination Web server on port 443
4. When the TCP connection is established, the ISA Server returns:

HTTP/1.0 200 connection established

From that point on, the client communicates directly with the external Web server.”

I’ve always found this an interesting explanation. Its impossible for a Web Proxy client (or any other client behind an ISA Server) to “communicate directly” with a non-LAT host, since all LAT to non-LAT communications are translated. I think what the Help File is trying to say here is that the SSL client to SSL server communications bypass the Web Proxy service. This assumption is supported by the fact the Help File information also assumes that we’re talking about the Web Proxy client configuration, since Firewall and SecureNAT client will never “remote” any kind of request to TCP 8080 at the Outgoing Web Requests listener.

What’s the solution? You need to add to the Web Proxy service’s “tunnel port range”. The easiest way to do this is to use a script that Jim Harrison has kindly made available to all of us over at http://www.isatools.org/. The name of the file is SSL_TPR_add and it’s a VB script. You’ll need to edit the script with the ports you need. For details on its configuration, check out http://support.microsoft.com/?id=283284

SSL connections can create some surprises if you don’t understand what’s going on inside. As you’ve seen, the initial request to the SSL site it “remoted” to the Outgoing Web Requests listener and then forwarded by the Web Proxy service to the SSL server on the Internet. Once the SSL link is established, the Web Proxy service disavows all knowledge of what’s going on with that connection.

Unlike the situation with inbound connections created with Web Publishing Rules, outgoing connections from Web Proxy clients on the internal network are never “bridged”. SSL bridging allows the Web Proxy service to see what’s going on inside the SSL tunnel, since an inbound SSL to SSL bridged connection is decrypted before being “recrypted” for the second SSL link.

Since outbound SSL connections are never bridged, the only thing the Web Proxy service knows is what was described in the Help file in step 2 above. For example, if you want to go to http://www.microsoft.com/, this is what the Web Proxy service knows:

CONNECT http://www.microsoft.com:443/ HTTP/1.1

That’s it. That’s all the Web Proxy knows about the connection. Nothing more. Everything else is hidden away from the Web Proxy service inside the SSL link. What kinds of problems do you think might occur if the ISA Server can’t evaluate what’s going on inside the SSL link? What kinds of abuses might occur if the ISA Server isn’t able to access what’s going on inside the SSL link?

Suppose you can to give your users access to www.microsoft.com/isaserver and www.microsoft.com/windows. You also want users to have access to SSL portions of those sites. Users should be able to access http://www.microsoft.com/isaserver, https://www.microsoft.com/isaserver, http://www.microsoft.com/windows and https://www.microsoft.com/windows and no other sites in the microsoft.com domain. So you create a Destination set that has www.microsoft.com/isaserver and www.microsoft.com/windows in it and then create a Site and Content Rule that allows your users access to the sites contain in the Destination Set.

You have no problems accessing these sites via HTTP, but when you trying to connect to them via SSL, the connection attempt fails. For example, I created such a Destination Set and Site and Content Rule and applied those to a user bjsmith. I logged on as bjsmith and then accessed www.microsoft.com/windows and accessed the Site (or at least the elements in that path; there are a lot of elements on that default page that draw from outside that path). The same was true for www.microsoft.com/isaserver. But look what happens when I try to access those sites via SSL:

192.168.1.148, anonymous, -, -, 4/17/2003, 14:41:35, -, -, -, www.microsoft.com, -, 443, 0, 0, 0, SSL-tunnel, -, -, www.microsoft.com:443, -, Inet, 0, 0x0, -, -

192.168.1.148, TACTEAM\bjsmith, -, -, 4/17/2003, 14:41:35, -, -, -, www.microsoft.com, -, 443, 0, 0, 0, SSL-tunnel, -, -, www.microsoft.com:443, -, Inet, 12202, 0x0, All Open Users, Deny Smith

192.168.1.148, anonymous, -, -, 4/17/2003, 14:42:02, -, -, -, www.microsoft.com, -, 443, 0, 0, 0, SSL-tunnel, -, -, www.microsoft.com:443, -, Inet, 0, 0x0, -, -

192.168.1.148, TACTEAM\bjsmith, -, -, 4/17/2003, 14:42:02, -, -, -, www.microsoft.com, -, 443, 0, 0, 0, SSL-tunnel, -, -, www.microsoft.com:443, -, Inet, 12202, 0x0, All Open Users, Deny Smith

OK, so there aren’t actually any SSL pages in those paths, but that doesn’t matter. The Web Proxy log file entries show that I don’t even get a chance to get a 404, because the entire site is denied. Why? Because the bjsmith is limited to just a small subset of folder paths on the server. As long as he’s connected to http://www.microsoft.com/, everything stays in the tunnel.

Even though ISA Server can’t evaluate what’s in the tunnel, it does know that bjsmith isn’t allowed to access everything at http://www.microsoft.com/. Since bjsmith is not allowed to access everything at http://www.microsoft.com/, and since the ISA Server can’t determine what’s in the tunnel after the SSL connection is established, the ISA Server errs on the conservative side and denies SSL access to the entire server

What’s the solution? If you want to use SSL when connecting to a particular server, you need to give the user access to the entire server AND you need to give the user access to all content on that server. You need to give the user access to all content on that server for the same reason: once the SSL link is established, the ISA Server can’t determine what type of content you’re accessing, so it will deny all SSL connections to the server until you allow all paths and all content on that server.

On a related note, you can also prevent Firewall and SecureNAT clients from accessing all sites if you’re not careful with your Site and Content Rules. For example, suppose you create a Site and Content Rule that applies to everyone. This rule allows users access to all sites. On the HTTP Content tab of the Site and Content Rule you select the “Selected content groups” option and then select all the content groups listed. You rightly assume this is OK, because it makes sense that selecting all the content groups is the same as selecting the “all content groups” option on the HTTP Content tab.

A little while later you start getting phone calls from your users telling you that they can’t connect to the Internet. Why? These users are not configured as Web Proxy clients and the HTTP Redirector filter is either disabled or configured to forward the requests directly to the Internet server. Only the Web Proxy service can evaluate content type via MIME types (or file extension for HTTP tunneled FTP requests from Web Proxy clients). When requests from Firewall and SecureNAT clients go through the ISA Server and bypass the Web Proxy service, the requests are denied because the ISA Server Web Proxy service can’t evaluate the content type. This is regardless of the protocol accessed by the Firewall and SecureNAT client.

The good news is that there’s a fix for this problem. Check out http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b2975 15 for the details and a Registry edit.

I’ve not spent enough time with outbound access issues in my articles at the http://www.isaserver.org/ sites. ISA Server outbound access control is what puts ISA Server head and shoulders above all other firewalls, so I need to correct this problem. In the near future, I’ll include a lab-based article on the concepts and examples I just discussed, complete with screen shots, steps by steps, and all the things you know about love about our ISAServer.org articles and how-to’s.

3. ISAServer.org Learning Zone articles of Interest

• Using ISA Server to Create a Hub and Spoke VPN Network
• How to pass IPSec traffic through ISA Server
• Joining Networks over the Internet with a Gateway to Gateway VPN: ISA Server to Branch Office ISA Server/Domain Controller – Part 2
• Joining Networks over the Internet with a Gateway to Gateway VPN: ISA Server to Branch Office ISA Server/Domain Controller – Part 1
• How to Implement VPN Off-Subnet IP Addresses
• Using DHCP with ISA/VPN Server Clients
• Using Windows 2000 NLB with ISA Server Publishing RulesUsing Windows 2000 NLB with ISA Server Publishing Rules

4. KB Articles of the Month

• Support WebCast: Microsoft Internet Security and Acceleration (ISA) Server: An Overview of Feature Pack 1
• MS03-012: Flaw in Winsock Proxy Service Can Cause Denial of Service
• Cannot Relay Mail Through ISA Server If Authentication Is Required
• MS03-009: A Problem in the ISA Server DNS Intrusion Detection Filter May Cause Denial of Service
• FIX: Passive Mode FTP May Break with Multiple IP Addresses on External Interface
• "The Computer Cannot Join an Array" Error Message and Error Code 0x8007203a Logged When You Try to Install ISA Server 2000 Enterprise Edition
• Multiple Authentication Dialog Boxes Are Displayed When You Use Access Control
• Windows XP-Based Clients Do Not Receive "New Mail" Notification Messages After You Install Service Pack 1

5. Post of the Month!

"The Cisco VPN Client initiates a TCP Handshake to the external VPN Concentrator (or whatever other device supports NAT Traversal over TCP) but does not specify the Maximum Segment Size (MSS) option. This packet passes through ISA, but ISA, as Stefaan mentions, strips off the original TCP Header, and inserts it own, but does specify the MSS as 1460.

When the VPN Concentrator replies, it does not reply with the MSS option set. By RFC when a client sends a MSS Request and the remote system does not reply with an MSS option, the system must assume an MSS of 536.

This is exactly what is seen in a network capture of the client connecting. It sends a (for example) packet with 750 bytes of data - it reaches ISA and this is divided into 2 TCP Segments - 1 with 536 bytes, and the other with 214 bytes. The VPN Concentrator does not support this an apparently silently discards the packets.

Just for clarification, it is not an ISA problem (as the Cisco documentation mentions) - it is a problem with how the VPN Concentrator handles MSS "negotiation". I hate using the term "negotiation" for this as it isn't really a negotiation, but it gets the point across."

Great info Clint! We appreciate the explanation and its great to hear that its not ISA Server's fault .

6. ISA Server Links of the Month

7. Ask Dr. Tom

On the other hand, you can completely bypass Web Publishing Rules and user a Server Publishing Rule. The Server Publishing Rule allows you to essentially perform a reverse “half NAT” back to the SSL site on the internal network. You’ll have to make sure that no SSL listeners are active on the ISA Server and that you’ve disabled IIS on the ISA Server machine. You can do a netstat –na | find “:443” on the ISA Server machine to confirm that nothing is listening on that port. Once you confirm that nothing is listening on TCP 443, then you’re ready to create the SSL Server Publishing Rule. You can use the built-in HTTPS Server Protocol Definition to create the SSL Server Publishing Rule.

While you miss out on the many advantages that Web Publishing Rule provide over Server Publishing Rules, the Server Publishing Rules are definitely easier to configure.  Have fun and good luck on your SSL server publishing.

QUESTION: Hi Tom, my question is the following: How do you install a second ISA Server in load balancing together with the first one? The first ISA has three NIC's, Internet, internal and  “Protected Zone”. The idea was to use Windows 2000 NLB, but this works only for one NIC I think, and using OSPF or else to configure route. Have you got any better ideas?
Thanks, Dominique?


ANSWER: Hi Dominque! You can use NLB to provide fail over and load balancing for either inbound or outbound connections on to your ISA Servers. Most people are more interested in fail over than load balancing. You can provide fail over for SecureNAT, Firewall and Web Proxy clients, although there are special considerations you need to take for each type of client. For example, Web Proxy clients that perform client side CARP routing do not benefit from any load balancing features provided by NLB, because the CARP algorithm already does this. SecureNAT clients and Firewall clients benefit the most from outbound NLB on the Windows 2000 ISA Servers.

You can also use NLB to provide fault tolerance and load balancing for incoming connections. You can publish servers on the internal network and they will still be available even when one of the ISA Server becomes unavailable. Note that there are issues with Server Publishing, because the default for Server Publishing is to allow the original source IP address on the external client to remain intact on the forwarded packet. You can fix this using the methods described in MSBK 311777.

I’m not sure what you mean by “Protected Zone” by it sounds like a DMZ interface. There really isn’t a cogent reason I can think of for using a trihomed public address DMZ, and even less of a reason to consider applying NLB to that interface. Consider moving your publishing server to the Internal network and using a LAT-based DMZ. If you have more complex requirements for fault tolerance and load balancing, you should consider a more advanced NLB add-on, like RainFinity’s RainWall.