1. The ISA Server 2004 Firewall’s One of a Kind VPN Server

By Dr. Thomas W Shinder

These are exciting times for ISAserver.org members. The new ISA 2004 firewall is scheduled to be announced by the time TechEd in San Diego rolls around in late May. And if we’re lucky, the ISA Server 2004 software will be available at the same time!

If you’re an ISA Server 2000 firewall administrator, you’re going to be very happy with the new ISA 2004 firewall. Why? Because the ISA 2004 firewall team worked hard to bring into the product a number of features you’ve been asking for over the last three years. Just check out some of these things you can do with ISA Server 2004 that you couldn’t do with ISA Server 2000:

• Define Internal networks without a LAT!
• Create a DMZ using public or private addresses and use firewall rules to control all traffic between any two networks
• Retain the actual source IP address of the client when using Web Publishing rules
• See firewall connection activity using a Real-time log viewer
• Control access to sites on a per protocol basis; i.e., allow access FTP protocol only when going to specific sites
• Rules are now evaluated from the top down; the first rule to match a connection’s characteristics
• System backup and restore is a snap; disaster recovery is a no-brainer using .xml based backup and restore files
• Publish PPTP VPN servers in a back to back ISA 2004 firewall scenario
• And lots more…

Those are all great features and will certainly increase the level of security the ISA firewall provide for your network. But what is the ISA 2004 firewall killer app? What feature or component is so cool, so unique and so valuable that it’ll get even the more dyed-in-the-wool PIX or Checkpoint fan to say “hey, I need one of those ISA firewall things”?

The answer is easy: The ISA 2004 firewall VPN server.

The ISA 2004 firewall now takes over most of the VPN server functionality from the Windows Routing and Remote Access Service (RRAS). This allows you to configure and manage the VPN server from within the ISA 2004 firewall management console itself, instead of having to move back and forth between the ISA console and the RRAS console. Like ISA Server 2000, the ISA 2004 firewall allows you to create a VPN server (that accepts inbound VPN remote access client connections) and a VPN gateway (that allows you to create site to site VPN links that join entire networks).

There are two things integrated into the ISA 2004 firewall/VPN server that make it the easy choice for firewall administrators who also need VPN functionality:

• Integrated support for VPN Quarantine
• Firewall Policy based user/group based access control over VPN users

ISA 2004 Firewall's VPN Quarantine Control

The VPN Quarantine feature allows you to screen VPN client machines before allowing them access to the corporate network. The VPN Quarantine functionality included with ISA Server 2004 is similar to that found in the Windows Server 2003 RRAS. You create a CMAK package that includes a VPN-Q client and a VPN-Q client-side script. The client runs the script and reports the results to the VPN-Q server component on the ISA 2004 firewall/VPN server. If the script reports that the client meets the software requirements for connecting to the network, then the VPN client is moved from the “VPN Quarantine” network to the “VPN Clients” network. You can set different access policies for hosts on the VPN Quarantine network versus the VPN Clients network.

The ISA 2004 firewall greatly extends the functionality of the Windows Server 2003 RRAS VPN-Q because the Windows Server 2003 RRAS VPN-Q does not set policy-based access controls. There are simple “port based” access controls available with the RRAS VPN-Q, but it would be a stretch to the imagination to consider port-based access controls as providing any level of serious security (you might as well use a simple PIX). In contrast, the ISA 2004 firewall applies strong firewall policy based access controls over hosts on the VPN Quarantine network and exposes these connections to the ISA 2004 firewall’s sophisticated application layer filters.

There is some especially good news for ISA 2004 firewall administrators who are planning to install the firewall on Windows 2000. When you install ISA Server 2004 on a Windows 2000 machine, the firewall will bring with it VPN-Q functionality. That’s right! You don’t need Windows Server 2003 to get the VPN-Q feature when ISA Server 2004 is installed on the Windows 2000 machine.

While VPN-Q is a nice feature, there are other vendors who provide similar functionality under the guise of “managed VPN clients”. In addition, those vendors provide user interfaces that don’t require the firewall admin to be a scripting or programming genius in order to get a simple, straightforward VPN-Q policy in place. For example, Nortel and Sygate offeri this type of managed VPN client support without requiring you to bust a blood vessel trying to get it to work. I really like and recommend the ISA 2004 firewall, but not for its VPN-Q support. Let’s hope they’re thinking of the current incarnation of the VPN-Q feature as v1. Once they get a workable management interface for this feature, it’s going to rock!

ISA 2004 Firewalls Force Strong Firewall Access Policy to VPN Clients

OK, so if VPN-Q isn’t the ISA 2004 firewall’s killer app, what is? The ISA Server 2004 killer app is its ability to control VPN client access based on firewall policy. All VPN client connections are exposed to the ISA 2004 firewall’s Access Policies. This is a BIG deal. In fact, only the ISA Server 2004 firewall/VPN server can do this; NO other firewall allows you this total control over VPN client access.

For example, one of the most common reasons to allow users VPN connections is to provide them a method to access Microsoft Exchange services via the full Outlook MAPI client. While you could create a secure Exchange RPC publishing rule to do this, too many dopey ISPs are blocking TCP port 135, which breaks your secure Exchange RPC publishing plan. Your only other choice (except for OWA, which doesn’t provide the entire “big” Outlook feature set) is to allow the Outlook users VPN access to the network.

The problem with allowing these users VPN access is that while they can access Exchange resources via the Outlook MAPI client, they also can access just about anything else they want on the corporate network. The reason for this is that VPN clients are considered trusted hosts, in the same way they are when they are directly connected to the corporate network. Yes, they still can be blocked based on local share and NTFS settings on servers and workstations on the corpnet, but allowing VPN connections from untrusted networks and untrusted hosts represents a tremendous security problem. Are you that confident in the local security settings of ALL the machines on your network?

An even bigger problem is that VPN clients can act as attack vectors. There were many networks protected with ISA Server 2000 firewalls that were not successfully attacked from the outside when the Blaster worm made its appearance last year. This protection provided by the ISA Server 2000 firewalls gave administrators time to patch their systems if they had no done so already. However, I heard from a number of administrators that while they thought they had the corporate network locked down against the Blaster worm, VPN clients connected and introduced the worm via a VPN client session! In the process, the entire network became infected because their VPN servers could not block the worm’s activities.

These problems, and many more, go away with the ISA 2004 firewall’s VPN server. Using the ISA 2004 firewall’s VPN server, you can create groups of users that have access to only the servers and to only the protocols they require on those servers. The days of “all open” access to VPN clients are over. The ISA 2004 firewall VPN server locks down VPN clients and gives them the access they require, and no more than that.

For example, you can create an Access Rule that allows a group access to the Exchange Server and DNS server. You then limit them to using only the DNS protocol when connecting to the DNS server machine, and you limit them to only the secure Exchange RPC protocol when connecting to the Exchange Server. Bingo! When users in this group make a VPN connection, they can only perform DNS queries and connect to the Exchange Server via the Outlook MAPI client. That’s it. They can’t “browse” the network and get themselves, and you, in trouble.

Another nice improvement with the ISA Server 2004 VPN server is that the VPN clients no longer need to use the Firewall Client to connect to the Internet. You can create specific Access Rules that control what Internet content and protocols VPN clients can access when connected to the corpnet via the VPN connection. This completely removes the requirement for split tunneling.

ISA 2004 Firewalls Allow You to Give SSL VPNs "the Boot"

The ISA 2004 firewall’s VPN server is a killer app. No other “real” VPN server provides this level of access control over VPN connections. What is extremely attractive about the ISA 2004 firewall’s VPN server is that it provides an even higher level of control than so-called “SSL VPNs”. These “SSL VPNs” provide application specific access control to resources on the corporate network. They work nicely for applications for which the specific SSL VPN implementation is designed to work with, but you are limited by the SSL VPN vendor’s application level support. Also, these SSL VPNs are outrageously expensive. The ISA Server 2004 VPN server provides a higher level of security, a higher level of access control, and a higher level of accessibility at a tiny fraction of the price of these SSL VPN solutions.

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

3. ISAserver.org Learning Zone articles of Interest

We have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:

4. KB Articles of the Month

Here are some interesting and useful ISA Server related Q articles posted by Microsoft in the last month:

5. Post of the Month

If you're working with the ISA 2004 beta and want to get SecurID authentication to work, you might have noticed that it doesn't. This was a big mystery until Avi Avidor from Microsoft posted the solution to the public newsgroups. Check this out:

" 1. What OS do you use? If you use W2K, the actions regarding permissions are
not relevant. In any case, try doing the following:
a. Create the HKLM\Software\SDTI\ACECLIENT key.
b. Under it, create a new string value with name PrimaryInterfaceIP. The value shoud be the IP by which the ISA is identified as a host on the Ace Server. (E.g. The "Network address" field in the "Edit Agent Host" dialog box)
 
2. Please check the Event Log and see if the Application log contains events from ACECLIENT as source. If so, please tell me what they say.
 
3. What do you mean by "the first authentication is successfully"?. If you seem to have logged on to OWA but get SecurID auth page again, it might be because your browser does not allow cookies. Please verify that you allow cookies in your browser (at least to ISA). "

Thanks Zvi!

6. ISA Server Links of the Month

7. Ask Dr. Tom