Chapter 9: Creating Remote Access and Site-to-Site VPNs with ISA Firewalls - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Chapter 9: Creating Remote Access and Site-to-Site VPNs with ISA Firewalls

Overview of ISA Firewall VPN Networking

Virtual private networking (VPN) has grown in popularity until it has become a standard for companies that have telecommuters, executives, and salespeople who need network access when on the road, and/or partners and customers who need access to resources on the corporate network. The purpose of VPN networking is to allow remote access to resources on the corporate network that would otherwise only be available if the user were directly connected to the corporate LAN. With a VPN connection, the user has a 'virtual' point-to-point link between the remote VPN user and the corporate network. The user can work as if he/she were on site; applications and services running on the users' computers treat the VPN link as if it were a typical Ethernet connection. The Internet over which the client is connected to the corporate network is completely transparent to the users and applications.

One of the major advantages of using a VPN connection instead of a client/server Web application is that VPN users at remote locations can potentially access all of the protocols and servers on the corporate network. This means your users can access the full range of services on Microsoft Exchange Servers, Microsoft SharePoint Servers, Microsoft SQL Servers, and Microsoft Live Communication Servers just as they do when they are directly connected to the network at the corporate location. VPN client software is built into all modern Windows operating systems. A VPN user does not need any special software to connect to each of these services, and it's not necessary to create special proxy applications to allow your users to connect to these resources.

ISA Server 2000 was the first Microsoft firewall to provide tightly integrated VPN configuration and management. ISA Server 2000 included easy-to-use wizards that made it simple to create remote access and site-to-site (gateway-to-gateway) VPN connections to the ISA Server 2000 firewall/VPN server. However, there were still some improvements that could be made. The ISA Server 2000 VPN server still required the firewall administrator to spend a significant amount of time fine-tuning the VPN server configuration via the Routing and Remote Access console.

ISA 2004 significantly enhances the VPN components that are included with the Windows 2000 and Windows Server 2003 Routing and Remote Access Services (RRAS). Now an administrator can enable, configure, and manage the VPN server and gateway components directly from the ISA 2004 firewall management console, rather than having to go back and forth between the ISA MMC and the RRAS MMC. You will rarely need to use the Routing and Remote Access console to configure VPN components.

Other improvements to VPN functionality in ISA 2004 include:

Firewall Policy Applied to VPN Client Connections

Firewall Policy Applied to VPN Site-to-Site Connections

VPN Quarantine

User Mapping of VPN Clients

SecureNAT Client Support for VPN Connections

Site-to-Site VPN using Tunnel Mode IPSec

Publishing PPTP VPN Servers

Pre-shared Key Support for IPSec VPN Connections

Advanced Name Server Assignment for VPN Clients

Monitoring of VPN Client Connections

These new VPN server and gateway features make ISA 2004 one of the most powerful co-located VPN and firewall solutions on the market today. In the following subsections, we discuss these new features and how they work together to make the ISA 2004 VPN solution the VPN of choice for all organizations running Microsoft networks.

Firewall Policy Applied to VPN Client Connections

When a VPN remote-access client establishes a connection with the VPN server, the VPN client acts like a machine that is directly connected to the corporate network. This virtual link to the corporate network enables the remote VPN user access to almost every resource on the corporate network, limited only by the access controls configured on the servers and workstations. However, this power to access virtually any resource on the corporate network can be a security risk. Generally, you should not allow users to have a full range of access to corporate resources when they connect over a remote access VPN connection. That's because these users might be connecting from computers that aren't within your control and don't conform to corporate software and security policies, or they may be connecting from computers that are on untrusted networks, such as hotel broadband networks. You have no way of knowing whether these machines pose a threat to your network.

Your VPN policy should stipulate that only highly-trusted users who are connecting from known trusted machines on known trusted networks are allowed unfettered access to the corporate network over a remote-access VPN link. Examples of users who might be granted such access include your network, security, and firewall administrators, and perhaps some highly-placed executives. All other users should be restricted to accessing only the subset of network resources that they need to do their jobs when connected via the VPN link.

For example, many firewall administrators allow users to connect over VPN so that they can use the full Outlook 2000/2002/2003 MAPI client to access a Microsoft Exchange Server. Microsoft Exchange provides several different methods for remotely accessing Exchange Server resources. These include the SMTP, POP3, IMAP3, and Outlook Web Access (OWA) services. However, users like to keep the broad range of options available to them when using the full Outlook MAPI client.

There are basically three ways to satisfy users' needs in this situation:

Publish the Exchange Server using the ISA Server secure RPC Server Publishing Rule

Have your users use the Outlook 2003/Exchange 2003 RPC over HTTP protocol

Grant your users VPN access to the corporate network

The ISA Server secure RPC Server Publishing mechanism enables remote Outlook MAPI clients to connect to the full range of Microsoft Exchange Server services from any remote location. The only problem is that, for security reasons, many firewalls and ISPs have blocked access to the RPC port mapper port (TCP 135). This port is required to make the initial secure connection to the Exchange Server using a secure Exchange RPC publishing rule, but the Blaster worm, which exploited this port, caused most administrators to shut it down. Consequently, RPC publishing has lost much of its former utility.

RPC over HTTP(S) can solve this problem by encapsulating the RPC connection inside an HTTP header. This allows the Outlook MAPI client to send requests to the Exchange Server using HTTP. HTTP is generally allowed by all corporate firewalls and ISPs, since it is used for Web communications. The problem with this solution is that not all organizations have upgraded to Outlook 2003 and Exchange Server 2003.

Granting users VPN access will circumvent the limitations of the other solutions, but providing such access can pose a security risk when all VPN clients can access the entire network. The ideal solution is to enforce Access Policy on VPN clients, based on user/group accounts. This way, users can access only the servers and protocols they require.

ISA 2004 is the only VPN server solution that gives administrators this level of access control. When VPN clients connect to the VPN server, those clients are placed on a built-in network entity called the VPN Clients Network. The ISA 2004 firewall treats this network like any other network, which means strong user- and group-based access controls can be placed on data that travels between the VPN Clients Network and the corporate network.

All you need to do is create the user accounts and create an access policy on the ISA 2004 firewall/VPN server that limits what machines and protocols the users/groups can access and use, and all those network devices are protected from the VPN remote-access users.

This feature virtually eliminates the need for SSL VPNs (except in those circumstances where remote users are behind extremely restrictive firewalls that block all but HTTP and SSL connections outbound) and other proprietary remote-access solutions aimed at providing per protocol, per server, per user/group access to corporate network resources. Most commercial broadband networks at hotels and conference centers allow outbound PPTP and L2TP/IPSec via NAT Traversal. This way, you can provide remote access for your VPN users without the security threat that typically accompanies VPN client connections.

Firewall Policy Applied to VPN Site-to-Site Connections

A site-to-site VPN connection connects two or more networks (instead of an individual client and a network) over the Internet. Using a VPN site-to-site link can create substantial cost savings in comparison to dedicated WAN links that use dedicated circuits (for example, linking two sites via T-1).

To use a VPN site-to-site link, each site requires a VPN gateway and a relatively inexpensive Internet connection. When the VPN gateways establish connections with one another, the site-to-site VPN link is established. Then the users on each end can communicate with other networks over the VPN site-to-site link just as they would with a routed connection on their own network. The VPN gateways act as routers and route the packets to the appropriate network.

VPN site-to-site connections use the same technologies as do client-to-server (remote access) VPN connections - and traditionally suffered from the same security problem. That is, all users had access to the entire network to which their own network was connected. The only thing that kept users out of network resources for which they had no permission to access was local access controls on the servers.

Site-to-site VPN connections are typically set up between branch office and main office networks. Providing branch office users with access to the entire main office network can pose a major security threat.

The ISA 2004 firewall/VPN server can solve this problem by controlling outbound data that travels through the site-to-site link. Users at the branch office can be limited to only the resources on the main office network required to do their jobs, and thus, prevented from accessing other computer resources on the main network. As with remote-access VPN clients, the users at the branch office should only be allowed to use the specific protocols they need on the servers they are allowed to access.

VPN site-to-site connections that take advantage of strong user- and group-based access controls can save money without sacrificing security.

VPN Quarantine

VPN Quarantine (VPN-Q) is a new feature that allows you to screen VPN client machines before allowing them access to the corporate network. The VPN Quarantine feature included with ISA 2004 is similar to the Network Quarantine feature found in Windows Server 2003 RRAS.

To use VPN-Q, you must create a CMAK (Connection Manager Administration Kit) 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. The VPN client is moved from the 'VPN Quarantine' network to the 'VPN Clients' network if the script reports that the client meets the software requirements for connecting to the network. You can set different access policies for hosts on the VPN Quarantine network versus the VPN Clients network.

The ISA 2004 firewall extends the functionality of the Windows Server 2003 RRAS Quarantine controls because the Windows Server 2003 RRAS Quarantine feature does not let you set policy-based access controls. The RRAS Quarantine uses simple 'port-based' access controls, but it this doesn't really provide any level of serious security. 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.

User Mapping of VPN Clients

User mapping is a feature that allows you to map virtual private network (VPN) clients connecting to ISA Server using an authentication method that is not based on 'Windows authentication' (such as RADIUS or EAP authentication) to the Windows namespace. With user mapping enabled and configured, firewall policy access rules specifying user sets for Windows users and groups are also applied to authenticated users that do not use Windows authentication. Default firewall policy access rules will not be applied to users from namespaces that are not based on Windows, unless you define user mapping for users.

The user mapping feature extends the strong user/group-based access controls you can apply to VPN clients that use an authentication method other than Windows.

This is important because Windows authentication of domain users is only available when the ISA 2004 firewall belongs to the domain that contains the users accounts, or to a domain that is trusted by the user accounts' domain. If the ISA 2004 firewall does not belong to a domain, then Windows authentication is used only for user accounts stored on the ISA 2004 firewall machine itself.

With user mapping, you can use RADIUS authentication of domain users, and you can apply user/group-based access control over VPN clients who authenticate via RADIUS. Without user mapping, you would not have access to strong user/group-based access control, and Access Policies from the VPN Clients Network to the Internal network would be limited to controlling protocol and server access to all users connecting to the VPN.

SecureNAT Client Support for VPN Connections

When a VPN client connects to the VPN server, the routing table on the VPN client changes so that the default gateway is the IP address of the VPN server. This causes a potential problem for VPN clients in that, while they are connected to the VPN, they cannot access resources on the Internet at the same time.

A problem with the ISA Server 2000 firewall/VPN servers was that, for VPN clients to access resources on the Internet, you had to choose from one of the three following options:

Enabling split tunneling on the VPN client

Installing the Firewall Client software on the VPN client machines

Configuring the Dial-up and Virtual Private Network settings of the VPN connection with Proxy Server settings (this enables browsing with Internet Explorer only when the client is connected to the VPN)

Split tunneling refers to a configuration wherein the VPN client machine is not configured to use the default gateway on the remote network. The default setting for Microsoft VPN clients is to use the default gateway for the remote network. A VPN requires two connections: first, a connection is made to the Internet (with broadband or other always-on technology, this connection does not have to be manually established each time); second, the VPN connection is made over the Internet connection. When VPN clients are configured not to use the default gateway, they can access resources on the corporate network through the VPN connection, and they can also access resources on the Internet via the Internet connection that was established by the VPN client machine before the VPN connection took place.

There are some serious security threats that occur when the VPN client machine can access the Internet directly while at the same time being able to access the corporate network via the VPN link. This allows the VPN client computer to completely bypass all Internet access policies that were configured on the ISA Server 2000 firewall for the duration of the VPN connection. Split tunneling is like allowing users on the corporate network to have local modem connections along with their connections to the LAN. The modem connections would completely bypass the ISA Server 2000 firewall policy and allow the workstation access to the Internet that would not otherwise be allowed by the ISA Server 2000 firewall policies. This creates a potential for downloading worms, viruses, and other dangerous content. A malicious user on the Internet would even be able to route exploits from an outside computer through the machine that is performing split tunneling and into the corporate network.

Because of this risk, it was important to provide an alternate method of allowing VPN clients Internet access while connected to the ISA 2004 firewall/VPN server. The preferred alternative with ISA 2000 is to install the firewall client software on the VPN client machine. The Firewall Client will forward requests directly to the ISA Server firewall's internal IP address and does not require split tunneling to allow the client computer to connect to the Internet. In addition, the Firewall Client exposes the VPN client machine to the ISA Server 2000 firewall access policies.

ISA 2004 firewall/VPN servers solve the problem of split tunneling without requiring installation of the Firewall client by enabling Internet access for VPN SecureNAT clients. The VPN clients are SecureNAT clients of the ISA 2004 firewall by default, because they use the firewall as their default gateway. The ISA 2004 firewall/VPN server can use the log-on credentials of the VPN client to apply strong user- and group-based access controls in order to limit the sites, content, and protocols that the VPN client machines will be allowed to access on the Internet.

An alternative to using the Firewall client on the VPN client is to configure the Dial-up and Network settings of the VPN client connection object in Internet Explorer with Proxy Server settings. If you are using ISA Server 2000, you can configure the VPN connection object with the same Web Proxy settings that are used by internal clients. However, this approach allows VPN clients to use HTTP, HTTP(S) and FTP (download only) protocols for Internet access. This same feature is available when connecting to ISA 2004 firewall/VPN servers.

Site-to-Site VPN Using Tunnel Mode IPSec

With ISA Server 2000, VPN remote-access clients could use PPTP or L2TP/IPSec to connect to the ISA Server 2000 VPN server, and other VPN gateways could connect to the ISA Server 2000 VPN gateway and establish site-to-site VPN links between two geographically separate networks. However, most third-party VPN gateways (such as Cisco or other popular VPN gateway solutions) did not support PPTP or L2TP/IPSec for VPN gateway-to-gateway connections. Instead, they required IPSec tunnel mode VPN connections.

If you had ISA Server 2000 firewall/VPN servers on both sites, it was simple to create a highly secure L2TP/IPSec VPN connection between the two sites or a less secure PPTP VPN connection. However, if you had a third-party VPN gateway at the main office, and you wanted to install an ISA Server 2000 VPN gateway at a branch office, you couldn't establish a site-to-site VPN connection to the main office VPN gateway because the main office VPN gateway didn't support PPTP or L2TP/IPSec connections, and ISA Server 2000 didn't support IPSec tunnel mode connections for site-to-site links.

ISA 2004 firewalls solve this problem because you can now use IPSec tunnel mode for site-to-site links between an ISA 2004 VPN gateway and a third-party VPN gateway. You can still use PPTP or high security L2TP/IPSec to create site-to-site links between two ISA Server firewall/VPN gateways, but ISA 2004 enables you use a lower security IPSec tunnel mode connection to connect to third party VPN gateways.

Publishing PPTP VPN Servers

In ISA Server 2000, Server Publishing Rules limited you to publishing servers that required only TCP or UDP protocols. In other words, you could not publish servers that required non-TCP or UDP protocols, such as ICMP or GRE. This meant you could not publish a PPTP server because it uses the GRE protocol, which is a non-TCP or UDP protocol. The only alternative with ISA Server 2000 was to put these servers on a perimeter network segment and use packet filters to allow the required protocols to and from the Internet.

ISA 2004 has solved this problem. You can now create Server Publishing Rules for any IP protocol using ISA 2004. This includes Server Publishing Rules for GRE. The ISA 2004 firewall's enhanced PPTP filter now allows inbound and outbound access. The new inbound access support means you can publish a PPTP VPN server located behind an ISA 2004 firewall.

This feature is sure to be very popular among former ISA Server 2000 firewall administrators who formerly had to create VPN pass-through connections in order to reach the Internal network.

Pre-shared Key Support for IPSec VPN Connections

A Public Key Infrastructure (PKI) is necessary in high-security environments so that computer and user certificates can be issued to the computers that participate in an IPSec-based VPN connection. Digital certificates are used for computer authentication for L2TP/IPSec remote access and gateway-to-gateway connections, and for IPSec tunnel mode connections. Certificates can also be used for user authentication for both PPTP and L2TP/IPSec connections.

Setting up a PKI is not a simple task, and many network administrators do not have the time or the expertise to implement one quickly. In that case, there is another way to benefit from the level of security provided by IPSec-protected VPN connections.

With ISA 2004, you can use pre-shared keys instead of certificates when you create remote access and gateway-to-gateway VPN connections. All VPN client machines running the updated L2TP/IPSec VPN client software can use a pre-shared key to create an L2TP/IPSec remote-access VPN client connection with the ISA 2004 firewall/VPN server. Windows 2000 and Windows Server 2003 VPN gateways can also be configured to use a pre-shared key to establish site-to-site links.

Be aware that a single remote-access server can use only one pre-shared key for all L2TP/IPSec connections that require a pre-shared key for authentication. You must issue the same pre-shared key to all L2TP/IPSec VPN clients connecting to the remote-access server using a pre-shared key. Unless you distribute the pre-shared key within a Connection Manager profile (CMAK), each user will have to manually enter the preshared key into the VPN client software settings. This reduces the security of the L2TP/IPSec VPN deployment and increases the probability of user error and increased number of support calls related to L2TP/IPSec connection failures.

Despite its security drawbacks, the ability to easily use pre-shared keys to create secure L2TP/IPSec connections to the ISA 2004 firewall/VPN server is sure to be popular among firewall administrators. Pre-shared keys are an ideal 'stop gap' measure that you can put into place immediately and use while in the process of putting together a certificate-based Public Key Infrastructure. When the PKI is complete, you can then migrate the clients from pre-shared keys to high-security computer and user certificate authentication.

Advanced Name Server Assignment for VPN Clients

The ISA Server 2000 VPN server/gateway was based on the VPN components included with the Windows 2000 and Windows Server 2003 Routing and Remote Access Services. The RRAS VPN services allow you to assign name server addresses to VPN remote access clients. Proper name server assignment is very important to VPN clients because incorrect name server assignments can render the VPN client unable to connect to either Internal network resources or resources located on the Internet.

Alternatively, it is possible to configure the VPN client connectoid with the IP addresses of WINS and DNS server. You can automate this process by using the Connection Manager Administration Kit to distribute these settings. Client-side name server assignment requires that each connectoid object be manually configured or that you use CMAK to distribute these settings.

It is possible to distribute name resolution settings from the VPN server. However, if you wanted to distribute name server settings to a VPN client from the ISA Server 2000 VPN server, you had to use one of the following:

Name server addresses that were bound to one of the network interfaces on the ISA Server 2000 firewall machine

Name server addresses provided to the VPN client via DHCP options (this was available only if the DHCP Relay Agent was installed on the ISA Server 2000 firewall/VPN server)

You might sometimes want to assign VPN clients name server addresses that are not based on the network interface configuration on the firewall/VPN server, and you might not want to install the DHCP Relay Agent on the firewall. Unfortunately, if this was the case, you were out of luck with ISA Server 2000 because it did not support this scenario.

Good news: ISA 2004 firewall/VPN servers do not have this problem because they allow you to override the name server settings on the ISA 2004 firewall/VPN server and issue custom name server addresses to the VPN clients. This can be done within the ISA 2004 management console; you don't have to enter the RRAS console to create the custom configuration.

Monitoring of VPN Client Connections

The ISA Server 2000 VPN server was limited by the logging and monitoring capabilities of the Windows 2000 and Windows Server 2003 RRAS VPN. Determining who connected to the network via a VPN connection required that you sift through text files or database entries. And that's not all; because the firewall did not manage the VPN remote-access client connections, there was no central mechanism in place at the firewall to allow you to determine which resources were being accessed by VPN remote-access clients.

ISA 2004 solves this problem by applying firewall policy to all connections to the firewall, including VPN connections. You can use the real-time log viewer to look at ongoing VPN remote-access client connections and filter it to view only VPN client connections. If you log to an MSDE database, you can query the database to view an historical record of VPN connections. With ISA 2004 firewall/VPN servers, you not only get complete information about who connected to the ISA 2004 firewall/VPN, but you also get information about what resources those users connected to and what protocols they used to connect to those resources.

For example, you can filter VPN criteria in the log viewer if you are using live logging and are logging to a file. What you can't do with file-based logging is use the ISA firewall's log viewer to query the archived data. However, you can still filter and monitor real-time VPN connections in the log viewer. In addition, you can filter VPN connections in both the Sessions view and the Log view.

In the Tasks tab in the Task pane of the Virtual Private Networks (VPN) node in the Microsoft Internet Security and Acceleration Server 2004 management console, you can click on a link that allows you to monitor the VPN client and gateway connections. If you choose this option, make sure you back up the default filter settings so that you can return to your baseline filtering configuration.

This ISA 2004 logging and monitoring feature is a big improvement over the logging and monitoring features included with ISA Server 2000 and is also much better than the standalone Windows 2000 and Windows Server 2003 Routing and Remote Access Service VPN.