Using the ISA Firewall to Configure Granular Access Controls for VPN Clients (Part 1)

If you would like to read the next article in this series then please check out out Using the ISA Firewall to Configure Granular Access Controls for VPN Clients (Part 2).

Using the ISA Firewall to Configure Granular Access Controls for VPN Clients (Part 1)

by Thomas W Shinder MD, MVP

Have Questions about the article?
Ask at:;f=30;t=001031

One ISA firewall feature that doesn’t get the attention it deserves is the VPN remote access server component. The ISA firewall’s VPN server can provide an unusually high level of security for your remote access VPN connections because it applies the same strong stateful packet and application layer inspection features to VPN connections that it applies to any other connection made to or through the ISA firewall. This sets the ISA firewall’s VPN remote access server component apart from the typical stateful packet inspection-only firewall, where VPN users have the same level of access to the corporate network as a host directly connected to the network.

There are many advantages to using the ISA firewall’s VPN remote access server component to allow remote users access to resources on the corporate network. Some of these advantages include:

  • A superior solution for enabling remote access to file shares and Web shares The most common reason for organizations to provide VPN connectivity to users is to provide them access to file servers on the corporate network. Enabling direct connections to SMB/CIFS file shares from the Internet is universally considered a poor security practice. The ISA firewall can be configured to provide secure remote access to file shares on a per-user/per group basis, and you can limit users access to only the file servers they need to access on a per-user/group basis. This prevents VPN users who are not authorized to use SMB/CIFS from using this protocol to connect to unauthorized servers, and prevents users who are authorized to use SMB/CIFS from connecting to servers other than those they authorized to connect
  • Enables remote access to protocols that don’t support NAT There are many applications that do not fully support NATed connections between source and destination networks. VoIP applications are good example of limited support for NATed network relationships. For this reason, you need a route relationship between the source and destination. VPN clients connecting to the ISA firewall benefit from a Network Rule that defines a route relationship between members of the VPN Clients Network and the corporate network.
  • Enforcement of user authentication for protocols that you would otherwise create Server Publishing Rules, which don’t support pre-authentication of users Server Publishing Rules enable you to provide remote access non-Web protocols. Examples of common non-Web protocols include RPC, SQL, SMTP, POP3, RDP, IMAP4 and Telnet. In contrast to Web Publishing Rules for Web protocols, you cannot enforce pre-authentication at the ISA firewall for protocols published via Server Publishing Rules. Remote access VPN connections provide the ideal infrastructure for pre-authenticating users before they are allowed access to the protocols that you would have otherwise allowed anonymous access (at the ISA firewall at least) via Server Publishing Rules. Remote access VPN users are authenticated at the ISA firewall, and are allowed to connect to servers using specific protocols only if the user is authorized to connect to the specific server using a specific protocol.
  • Reduces the attack surface on the ISA firewall and on upstream servers (servers located on the corporate network) by reducing the number of Web and Server Publishing Rules you need to create for remote access By default, the ISA firewall is a network brick. No connections are allowed to or through the ISA firewall after installation is complete. No connections are allowed to or from the ISA firewall except for those enabled by System Policy, which you can customize to further lock down the ISA firewall device and no connections are allowed through the ISA firewall until you create either Access Rules or Publishing Rules.
  • Remote access VPN Quarantine The ISA firewall includes tightly integrated support for remote access VPN quarantine. VPN remote access VPN quarantine allows you to place VPN clients on a custom VPN quarantine network until the clients have passed client health tests to determine the security configuration of the VPN client device. Unfortunately, you need to have advanced scripting or programming skills to make this work. In addition high bar created by these application development requirements is the time it takes to research issues and configuration requirements related to implementing a viable remote access quarantine solution. For example, try to figure out how your favorite antivirus program registers its version number and update status – you’ll find that its not a simple task. At this time I consider the ISA firewall’s remote access quarantine component a “dot-one” release that represents more of a development platform that a “fully baked” defense in depth feature. However, if you’re interested in completely developed solution that leverages the ISA firewall’s built-in support for remote access quarantine, check out Frederic Esnouf’s Quarantine Security Suite (QSS) at

Reviewing the VPN Remote Access Scenario Discussed in this Article

The scenario discussed in this article series will include the following key features:

  • ISA firewall is a member of the domain Its my very strong and well considered opinion that an ISA firewall joined to the domain is a much more secure configuration than a stand-alone ISA firewall installed in a workgroup. For this reason, I recommend that you always install the ISA firewall as a domain member, the exception to this rule would be when there are no benefits accrued by domain membership, such as when the ISA firewall is used as a front-end firewall in a back to back firewall configuration and the segment between the firewall’s is an anonymous access DMZ. There are real, repeatable, usable and consistently demonstrated reasons why an ISA firewall domain member significantly increases the level of security the ISA firewall can provide, while there are only theoretical reasons, which even the most skilled security consultants in the industry cannot provide a proof of concept, for making the ISA firewall a workgroup member (except for the scenario I mentioned with the front-end ISA firewall). The ISA firewall will be able to use native Windows authentication to authenticate and authorize VPN user access to the VPN server and servers and services on the corporate network.
  • VPN RDP Users group allowed RDP access to a Terminal Server We will create an RDP Users group on the ISA firewall and use that group in an access rule that enables trusted administrators RDP access to the corporate network.
  • VPN File Shares group allowed file share access to a File Server We will create a File Shares group on the ISA firewall and use that group in an Access Rule that enabled users we want to have access to a file server using the Windows file sharing protocols.
  • VPN UNIX Admins group allowed Telnet access to UNIX server We will create a Unix Admins group on the ISA firewall and use that group in an Access Rule that enables these users access to the UNIX server on the corporate network using the Telnet protocol.
  • VPN Outlook MAPI Users group allowed full Outlook MAPI client access to Exchange Server We will create an MAPI Outlook group on the ISA firewall and use that group in an Access Rule that enables these users access to this protocol to connect to the Exchange Server.
  • Create four users, user1, user2, user3 and user4. Assign each of these users to one of the above mentioned groups

Note that when we create each of the Access Rules, users will be allowed access to certain protocols, and they will be able to use those protocols only when connecting to specific servers. If a user tried to access a protocol that he is not allowed to use, then the connection will be denied. If the user is allowed access to the protocol, but tries to use that protocol to connect to a server that the user is not authorized to use that protocol with, then the connection will be denied.

Another important thing to be aware of is that you can put domain users in custom ISA firewall Groups. For example, you can create an ISA firewall Group called VPN File Share Users on the ISA firewall and then add domain members to that group. Alternatively, you can create a Global Group on the domain controller called VPN File Share Users, add users to that Global Group, and then add this group to the VPN File Share Users ISA firewall Group. The advantage of using ISA firewall Groups is that you don’t need permissions to create a Global Group to create an ISA firewall Group. This is a big advantage when the network infrastructure group (which manages the ISA firewall) doesn’t have rights to manage users and groups in the Active Directory.

The figure below provides a high-level overview the machines included in the sample network used in this article.

Figure 1

In this article we will perform the following procedures to meet our granular access control goals for VPN users:

  • Enable the VPN server component on the ISA firewall The VPN server component is not enabled by default on the ISA firewall. We first need to enable and configure the ISA firewall’s VPN server before remote access VPN connections are accepted.
  • Create granular Access Rules on the ISA firewall After enabling and configuring the VPN server component on the ISA firewall, the next step is to create the granular user/group/protocol/server based Access Rules on the ISA firewall. The goals of these rules are: 1. Require authentication at the ISA firewall before access is allowed to the network server and service and 2. Provide VPN users access only to the resources they need when connected to the VPN server. This is the incarnation of the principle of least privilege. You should always keep least privilege in mind when configuring any firewall policy.
  • Install the CMAK and create the CMAK profile to distribute to users The Connection Manager Administration Kit allows you to create connection manager packages that you deploy to your users that contain all the VPN client configuration options you need. Users never need to understand how to configure VPN client settings or know about VPN protocols or addresses. Just have them download the connection manager executable you created for them and all they need to do is double click on the file. Since we know that users never have problems double clicking on firewalls, installing the VPN client will be a no-brainer. All the user needs to enter is his user name and password.
  • Distribute the CMAK profile and install the profile on VPN client computers After creating the CMAK profile, we’ll distribute the profile to users via a Web site download. The users can then install the file from there
  • Test the solution and review the ISA firewall’s log files We’ll finish up the article by testing the connections and observing the ISA firewall log files to see what happens when different users try to access different resources using different protocols

Have Questions about the article?
Ask at:;f=30;t=001031

Enable the VPN Server Component on the ISA Firewall

The first step is to enable the ISA firewall’s VPN server component. Perform the following steps to enable the ISA firewall’s VPN server:

By default, the VPN server component is disabled. The first step is to enable the VPN server feature and configure the VPN server components.

Perform the following steps to enable and configure the ISA Server 2004 VPN Server:

  1. In the ISA firewall console, expand the server name. Click on the Virtual Private Networks (VPN) node.
  2. Click on the Tasks tab in the Task Pane. Click the Enable VPN Client Access link.

Figure 2

  1. Click the Configure VPN Client Access link.
  2. On the General tab, change the value for the Maximum number of VPN clients allowed from 5 to 10. I’m using the value 10 as an example only. You can enter a value of up to 1000, which is the limit of VPN connections accepted by ISA Server 2004 Standard Edition. ISA Server 2004 Enterprise Edition supports an unlimited number of VPN connections (up to your bandwidth and hardware limits).

Figure 3

  1. Click on the Groups tab. On the Groups tab, click the Add button.
  2. In the Select Groups dialog box, click the Locations button. In the Locations dialog box, click the entry and click OK.
  3. In the Select Group dialog box, enter Domain Users in the Enter the object names to select text box. Click the Check Names button. The group name will be underlined when it is found in the Active Directory. This value is used in the remote access policy conditions managed by the ISA firewall device. This is a potentially confusing option, because it implies that if you enter a group into this dialog box, they will be allowed remote access permissions to the ISA firewall. This isn’t necessarily the case. These users will only be allowed permissions to establish a VPN connection to the ISA firewall if their user accounts are configured to enable Dial-in access via remote access policy. This is the default setting for domain in Windows Server 2003 mode or Windows 2000 native mode. However, if you are running at a lower functional level for your domain, then you’ll need to configure accounts individually to allow them remote access (Dial-in) permission. If you are running in Windows 2000 Mixed mode, the settings on the Groups tab will have no effect unless you manually configure the accounts to control remote access permission via remote access policy. Click OK.

Figure 4

  1. Click the Protocols tab. On the Protocols tab, put a checkmark in the Enable L2TP/IPSec checkbox. Note that you will have to issue a machine certificate to the ISA firewall, and to the connecting VPN clients, before you can use L2TP/IPSec. An alternative is to use a pre-shared key for the IPSec security negotiations, but this is not the preferred option and is less secure and less scalable. When both check boxes are enabled, users can connect to the ISA firewall’s VPN server using either PPTP or L2TP/IPSec. Click Apply.

Figure 5

  1. Click the User Mapping tab. We will not make any changes on the User Mapping tab because we are using integrated Windows authentication. User Mapping is only potentially useful if you are using EAP or RADIUS authentication. Click OK.

Figure 6

  1. On the Tasks tab, click the Select Access Networks link.

Figure 7

  1. In the Virtual Private Networks (VPN) Properties dialog box, click the Access Networks tab. Note that the External checkbox is selected by default. This indicates that the external interface is listening for incoming VPN client connections with source addresses identified as being on the default External Network. You could choose other interfaces, such as DMZ or extranet interfaces, if you wish to provide dedicated VPN services to trusted hosts and networks. Don’t make any changes on the Access Networks tab.

Figure 8

  1. Click the Address Assignment tab. Select the internal interface from the list in the Use the following network to obtain DHCP, DNS and WINS services list box. This is a critical setting, as it defines the network on which access to the DHCP server is made. Note that in this example we are using a DHCP server on the default Internal Network to assign addresses to VPN clients. The DHCP server will not assign DHCP options to the VPN clients unless you install the DHCP Relay Agent on the ISA firewall device. You have the option to create a static address pool of IP addresses to be assigned to the VPN clients. If you choose to use a static address pool, you will not be able to assign DHCP options to these hosts. Also, if you choose to use a static address pool, you should use an off-subnet network ID. If you do not use an off-subnet network ID, you will need to remove the addresses from the definition of the on-subnet network’s ISA firewall Network definition. Please refer to Stefaan Pouseele’s article on off-subnet address configuration over at

Figure 9

  1. Click on the Authentication tab. Note that the default setting is to enable only Microsoft encrypted authentication version 2 (MS-CHAPv2). You should use this default setting unless you have clients that do not support this authentication protocol. You also have the option to use EAP user authentication, but we won’t discuss that option in this article. Note the Allow custom IPSec policy for L2TP connection checkbox. If you do not want to create a public key infrastructure or in the process of creating one but have not yet finished, then you can enable this checkbox and then enter a pre-shared key. The VPN clients will need to be configured to use the same pre-shared key. Note that the pre-shared key is stored in the user interface in clear text and is visible to anyone who has access to the ISA firewall console. In addition, the pre-shared key is stored in clear text in the machine’s registry and you can also view it in the ipsecmon MMC console when the L2TP/IPSec connection is active. I strongly recommend that you use machine certificates to support your L2TP/IPSec VPN connections.

Figure 10

  1. Click the RADIUS tab. Here you can configure the ISA Server 2004 firewall VPN server to use RADIUS to authenticate the VPN users. Use RADIUS authentication when you are forced to not join the ISA firewall to the domain. Check out my article on using RADIUS authentication for remote access VPN clients over at Since we’re following ISA firewall best practices in this article, we’ve joined the ISA firewall to the domain and are not forced to confront the compromises inherent in RADIUS authentication.

Figure 11

  1. Click Apply in the Virtual Private Networks (VPN) Properties dialog box and then click OK.
  2. Click Apply to save the changes and update the firewall policy.
  3. Click OK in the Apply New Configuration dialog box.
  4. Restart the ISA firewall device.

The machine will obtain a block of IP addresses from the DHCP Server on the default Internal Network (which is where out DHCP server is located) when it restarts. Note that on a production network where the DHCP server is located on a network segment remote from the ISA firewall, all interposed routers will need to have BOOTP or DHCP relay enabled so that DHCP requests from the ISA firewall can reach the remote DHCP servers.

Have Questions about the article?
Ask at:;f=30;t=001031


In part 1 of this article series on how to maximize VPN security by using the ISA firewall’s exceptional remote access VPN server component we began with a discussion on how the ISA firewall’s VPN server provides superior security for VPN connections than typical stateful packet inspection-only firewall/VPN servers. The article finished up with a detailed description of how to enable the ISA firewall’s VPN components. In part 2 of this series we’ll go over the granular Access Rules required to lock down remote access VPN users connecting to the corporate network.

If you would like to read the next article in this series then please check out out Using the ISA Firewall to Configure Granular Access Controls for VPN Clients (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top