No Anti-Virus for ISA Server? Get Real!! GFI DownloadSecurity for ISA Server

 

ISA SERVER 2000 VPN DEPLOYMENT KIT
Overview of ISA Server 2000 VPN Networking
by

Thomas W. Shinder, M.D.

Virtual private networking allows you to connect a single computer or an entire network, to your corporate network over the Internet. A virtual private network uses the Internet as the network medium to create the connection. Virtual private networks (VPNs) can save a company significant amounts of money when VPN links replace dedicated dial-up or WAN links.

 

An ISA Server firewall/VPN server is the ideal VPN solution for the small to medium sized business that can’t afford, or does not wish to spend, tens of thousands of dollars on dedicated hardware-based VPN servers and firewalls from third party vendors. A small to medium sized business can install 4 or 5 ISA Server firewall/VPN servers at the edge of the internal network to provide a highly available, fault tolerant and high performance ISA Server firewall/ VPN server array for less than a single hardware-based firewall, load balancer or VPN server from many third party vendors.

 

*       Note:
Please see ISA Server 2000 VPN Deployment Kit document Configuring Fault Tolerance and Load Balancing for ISA Firewall/VPN Servers for information on how to create a Network Load Balancing (NLB) array of ISA Server firewall/VPN servers that provides load balancing and transparent fail over.

 

This ISA Server 2000 VPN Deployment Kit document covers basic VPN networking concepts. These basic concepts bring the information in the other ISA Server 2000 VPN Deployment Kit documents into focus persons thinking about introducing a VPN server or VPN gateway into their ISA Server 2000 environment.

 

This ISA Server 2000 Deployment Kit document covers the following subjects:

 

 

*       Note:
This overview of VPN networking is not designed to provide comprehensive planning and deployment information for VPN servers, clients or gateways. Please refer to Virtual Private Networking with Windows Server 2003: Deploying Remote Access VPNs and Virtual Private Networking with Windows Server 2003: Deploying Site-to-Site VPNs for in depth coverage of Windows Server 2003 VPN servers and gateways.

 

ISA Server 2000 VPN Deployment Kit Assumptions

 

There are almost an unlimited number of scenarios in which a VPN server or gateway can be deployed. It is impossible to create a comprehensive VPN Deployment Kit containing the detailed step by step procedures included in the ISA Server 2000 VPN Deployment Kit documents for every possible networking scenario. Throughout the documents in the kit, we have made some assumptions about your current networking environment:

 

·         VPN Servers and VPN gateways have dedicated connections to the Internet

 

ISA Server 2000-based VPN servers and gateways should have dedicated links to the Internet and at least one static public address bound to its external interface. Most Internet Service Provides (ISPs) block incoming, outgoing or both incoming and outgoing VPN connections to non-business accounts. These non-business accounts have dynamically assigned IP addresses. Business grade accounts have permanent IP addresses and dedicated Internet links.

 

Some examples of a dedicated link include ATM DSL routers, cable Internet routers, T1 routers, and ISDN terminal adapters. The ISA Server firewall/VPN Server external interface must have a public address that is part of your public address block. Your ISP can tell you the addresses you can use on the external interface of the ISA Server firewall/VPN server and what the default gateway on the external interface should be.

 

·         Upstream routers and firewalls allow all traffic to the ISA Server firewall/VPN server

 

If you have a router or firewall in front of the ISA Server firewall/VPN server, that router or firewall should allow all traffic destined to the IP address or addresses bound to the external interface of the ISA Server firewall/VPN server through unfiltered. The ISA Server firewall/VPN server can protect your internal network. If you need to create a back to back DMZ using a 3rd party firewall in front of the ISA Server firewall/VPN server, please refer to the Windows Server 2003 Help for more information on required packet filters to support inbound and outbound PPTP and L2TP/IPSec connections.

 

*       Note:
If you choose to use ISA Server firewalls in a back to back DMZ configuration, please refer to ISA Server 2000 VPN Deployment Kit document Allowing Inbound L2TP/IPSec Connections Through a Back to Back ISA Server 2000/Windows Server 2003 DMZ for information on how to allow inbound RFC L2TP/IPSec connections inbound to the internal ISA Server firewall/VPN server.

 

·         The ISA Server firewall/VPN server administrator is familiar with Windows 2000/Windows Server 2003 administration and the Routing and Remote Access Service (RRAS)

 

The ISA Server 2000 VPN Deployment Kit documents include detailed step by step instructions on how to setup and configure VPN clients, VPN servers and VPN gateways. However, we assume the person deploying the VPN is familiar with Windows 2000 or Windows Server 2003, the Windows Routing and Remote Access service, and the basics of Windows networking.

 

·         The ISA Server firewall will be used as both a firewall and VPN server

 

One of the highest return, valued-added features of ISA Server 2000 is the integrated VPN server. You do not need to pay for additional client access licenses to make VPN connections. There is no limit on the number of VPN connections made to a Windows 2000 VPN server and the limit on a Windows Server 2003 VPN server is 1000 concurrent connections. The ISA Server 2000 firewall component provides an ideal level of protection for both the private network and VPN server.

 

·         The ISA Server firewall/VPN server, domain controllers and networking services run on Windows Server 2003

 

We have assumed throughout the kit that you will place all networking services on the Windows Server 2003 operating system. This is not a requirement. Most of the procedures are the same on Windows 2000 machines, with some minor differences.

 

·         ISA Server firewall/VPN scenarios are tested before implemented in a production environment

 

We have tested all these scenarios in both lab and production environments. However, because of the multiplicity of networking environments, it’s important to test the configurations in a lab that mirrors your production environment to confirm that there are no unexpected conflicts between the configuration requirements described in this document and your current network setup.

 

What is a Virtual Private Network (VPN)?

 

A VPN is an extension of the private network located behind your ISA Server firewall/VPN server. The VPN has two key components:

 

·         A “virtual” network

 

Computers communicate with directly connected network devices using a layer 2 (data link layer) networking protocol. LAN-based computers on Ethernet networks connect to other network devices using the Ethernet data link layer protocol. Computers connecting to the Internet via a dial-up analog modem connection use the Point to Point (PPP) data link layer protocol to create a direct connection with the ISP network over a phone line.

 

These data link layer protocols establish a network connection between devices that are “directly connected” over a common wire or circuit. It is not possible to create a direct connection between two machines over the Internet because multiple networking devices separate two Internet connected computers.

 

However, computers can be “tricked” into acting as if they were directly connected by using a “virtual network” protocol, such as the Microsoft Point to Point Tunneling Protocol (PPTP) or the Layer 2 Tunneling Protocol (L2TP).

 

PPTP and L2TP create “virtual” direct connections between a VPN client and VPN server, or between two VPN gateways. This virtual network connection allows the computer connected over the virtual network to send TCP/IP messages back and forth in the same way they do on other directly connected networks, such as computers located on the same Ethernet LAN.

 

*       Note:
Virtual networking protocols are referred to as “tunneling” protocols because IP packets moving over the virtual network are encapsulated with the virtual networking protocol header.

 

·         A “private” network

 

While a virtual networking protocol can create a virtual “direct link” between hosts participating in the virtual network, the data moving between these hosts is not secure. For example, you can connect two machines over the Internet using the Layer 2 Tunneling Protocol (L2TP) virtual networking protocol and all data moving between the two computers will be readable by anyone with a network analyzer.

 

The privacy in a virtual private network stems from the encryption protocol used to protect the data moving through the virtual connection. The PPTP VPN protocol uses the Microsoft Point to Point Encryption Protocol (MPPE) to protect the data moving through the PPTP virtual networking connection. The L2TP/IPSec VPN protocol uses Internet Protocol Security (IPSec) encrypt the data moving through the L2TP virtual network.

 

Data encryption (or “privatization”) is critical in virtual networking scenarios because you have no knowledge of the path taken for communications between two virtual networking participants. This is why the Internet is always depicted as a “cloud” in network drawings, such as figure 1. The data moving through the virtual networking protocol must be protected by encryption because you can not be sure that a malicious third party is not located on some link between the source and destination.

 

 

Figure 1

 

 

VPN Protocols

 

The ISA Server firewall/VPN server supports two VPN protocols:

 

·         Point to Point Tunneling Protocol (PPTP)

 

The Point to Point Tunneling Protocol is a combination of the Point to Point Tunneling Protocol virtual networking protocol and the Microsoft Point to Point Encryption (MPPE) encryption protocol. PPTP was the first VPN protocol introduced by Microsoft and the current version of PPTP is 2.0.

 

The level of security afforded to PPTPv2 connections is related to the complexity of the passwords used for user authentication. PPTP does not authenticate the VPN client, server or gateway computer. PPTP authentication mechanisms authenticate the user only.

 

While PPTP provides a good level of security, the future of VPN networking belongs to L2TP/IPSec. IPSec encryption protocols are more secure than the MPPE based encryption used by PPTP.

 

·         Layer 2 Tunneling Protocol over IPSec (L2TP/IPSec)

 

The L2TP/IPSec VPN protocol is a combination of the Layer 2 Tunneling Protocol (L2TP) and the IPSec encryption protocol. The IPSec encryption protocol confers several advantages to L2TP/IPSec:

 

ü       Certificate-based computer authentication in addition to password or certificate-based user authentication; two levels of authentication instead of PPTP’s single level of authentication

ü       Protection of data in transit; data changed between source and destination is dropped by IPSec

ü       User credentials are protected by an established IPSec encrypted tunnel; PPTP does protect user credentials inside an encrypted tunnel and depends on the security of the user authentication protocol

 

L2TP/IPSec should be used preferentially over PPTP whenever possible.

 

VPN Authentication

 

Connections to a VPN server must be authenticated before permission is granted to access the private network through the VPN link. There are two general categories of user authentication protocols used by ISA Server firewall/VPN servers:

 

·         PPP authentication protocols

 

PPP user authentication protocols authenticate the connection between a PPP client and PPP server. PPP authentication protocols are the standard for remote access user authentication. PPP authentication protocols supported by the ISA Server firewall/VPN server include:

 

ü       Password Authentication Protocol (PAP)

ü       Challenge-Handshake Authentication Protocol (CHAP)

ü       Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)

ü       Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2)

 

To insure the greatest level of security for PPTP VPN connections, allow only the MS-CHAP v2 authentication protocol. All Microsoft VPN clients are capable of using MS-CHAP v2. MS-CHAP v2 provides a mutual authentication mechanism that is unavailable with the other PPP authentication protocols.

 

PPP user authentication protocols authenticate users making PPTP and L2TP/IPSec VPN connections. It is critical that you force MS-CHAP v2 for PPTP VPN connections because the user credentials are not passed through an encrypted channel; tunnel encryption begins after the user is authenticated.

 

The PPP user authentication protocol is less of a concern for L2TP/IPSec connections because user credentials by an IPSec encrypted tunnel during authentication. Nevertheless, if PPP user authentication is used by L2TP/IPSec VPN clients, then MS-CHAP v2 should be forced for these connections as well.

 

·         EAP/TLS certificate-based authentication

 

The Extensible Authentication Protocol (EAP) is an extension to the PPP authentication protocol mechanisms. EAP supports multiple authentication methods beyond those supported by the traditional PPP user authentication protocols. EAP authentication allows users to authenticate using Kerberos, one-time passwords, user certificates and certificate-based Smart Cards.

 

The ISA Server firewall/VPN server can allow you to replace password based authentication with certificate-based authentication. You can do certificate-based authentication with certificates installed on the VPN client computer or with certificates be installed on a Smart Card.

 

The certificate stored on the VPN client computer replaces the user name and password. The calling user does not need to type in any authentication information. Smart Card authentication can leverage two factor authentication by requiring the VPN caller to use a certificate stored on a Smart Card and a PIN (personal identification number) to validate the Smart Card credentials. The two factors in this example are the physical Smart Card, and the user’s knowledge of the PIN associated with the Smart Card.

 

Both PPTP and L2TP/IPSec can leverage the EAP/TLS authentication mechanism to present certificates for user authentication. ISA Server 2000 VPN Deployment Kit document Configuring the VPN Client and Server to Support Certificate-Based PPTP EAP-TLS Authentication describes how to configure the ISA Server firewall/VPN server to accept certificates for user authentication.

 

*       Note:
You may have seen the term “SSL VPN” used on the Internet and in the media. These so-called “SSL VPNs” are not virtual private networks. SSL is a session layer protocol and cannot provide the layer two functionality required of a true virtual private network. SSL (secure sockets layer or transport layer security) does provide data encryption. However, in contrast to what industry pundits and “SSL VPN” vendors advertise, a client piece is required to create the special purpose SSL link to the destination SSL remote access server. These SSL connections provide a type of remote access solution allowing proxied access to specific applications on the internal network. They do not provide true virtual network access.

 

What is a VPN Server?

 

A VPN server accepts calls from VPN client computers and allows these VPN client computers access to resources on the internal network located behind the VPN server. Figure 2 shows a VPN client connection to a VPN server. The sequence of events is straightforward:

 

  1. The VPN client computer establishes a PPP or data link connection with a gateway device that connects the VPN client to the Internet. If the VPN client computer uses a dial-up connection to connect to an ISP, then it uses PPP as its data link layer protocol for the direct link to the ISP’s Internet gateway server. If the VPN client computer is connected to an Ethernet network, such as a hotel network, then it uses Ethernet as its data link layer protocol to connect to the Internet gateway at the edge of the hotel network. If the VPN client connects to the Internet via a wireless connection, then the VPN client computer uses 802.11b or 802.11g to connect to a wireless access point.
  2. After establishing a data link layer connection to a network or network server that can provide Internet access, the VPN client makes a call to the IP address of the external interface of the ISA Server firewall/VPN server. A virtual data link connection is established to the external IP address on the ISA Server firewall/VPN server.
  3. The VPN client is able to connect to resources, such as file shares, printers, and other network devices on the internal, corporate network just like any computer that is physically located behind the ISA Server firewall/VPN server. The VPN connection between the VPN client and ISA Server firewall/VPN server acts like a very long Ethernet cable connecting the VPN client to the internal network.

 

Figure 2

 

 

While we usually think of VPN severs connecting a VPN client computer to a private network over the Internet, you can also use VPN servers to create security zones within the internal network.

 

Figure 3 shows a VPN client computer on the internal network connecting to a VPN server. This VPN server is connected to the same LAN as the VPN client. In this example, the VPN server has an interface on the corporate backbone and a second interface on a highly secured network, such as payroll, finance or research and development. Users not physically attached to the highly secured network can securely access resources on the secure network by creating a VPN link to the VPN server connected to the highly secure network.

 

Figure 3

 

*       Note:
VPN Servers can accept VPN connections from hundreds or even thousands of users at the same time. However, each VPN link between the VPN client and VPN server represents a single virtual “cabled” connection between the VPN server and VPN client. The VPN client/server connection does not allow machines that are behind the VPN client or VPN server to connect to resources on the opposite network. You need a VPN gateway to connect entire networks to one another.

 

What is a VPN Gateway?

 

In contrast to a VPN Server that allows single VPN client computers to establish connections to the internal network through the VPN server machine, a VPN gateway allows you to connect entire networks to one another.

 

*       Note:
An ISA Server firewall/VPN Server can act as both a VPN server and a VPN gateway. You can use the same machine to perform both roles. There are no conflicts between the VPN server and the VPN gateway configurations.

 

Figure 4 shows two entire networks connected to one another using a local ISA Server firewall/VPN gateway and a remote ISA Server firewall/VPN gateway. These VPN gateway computers act like VPN routers. These VPN gateways (or routers) route packets behind one network to another through a VPN-based demand-dial interface.

 

Figure 4

 

VPN gateways appears as normal IP routers to all hosts on the networks behind the VPN gateways. There can be domain controllers, RADIUS (IAS) servers, certificate servers (CAs), Web servers and all types of client machines at each site. All these machines are able to communicate with machines on the opposite network via the gateway to gateway link. Figure 5 shows this type of setup.

 

Figure 5

 

 

You can also use VPN gateway to gateway connections to secure networks on the same LAN. This is a commonly seen when departmental LANs are connected to each other over a busy and relatively open, corporate backbone. In this scenario, the corporate backbone transports traffic between departmental LANs, between departmental LANs and the Internet, and between untrusted network hosts directly connected to the backbone and the Internet, or connected to the backbone via a wireless link and the Internet.

 

Figure 6 is an example of two departmental LANs connected to each other via a gateway to gateway link over a corporate Ethernet backbone.

 

Figure 6

 

 

Network Services that Support VPN Client and Gateway Connections

 

VPN networks require the assistance of a number of network services to provide the best VPN client/server and VPN gateway to gateway connection experience. Some networking services are required, some are not required, and some are optional but highly recommended. In this section we’ll review the following networking services that are used to support VPN networking connections:

 

·         Dynamic Host Configuration Protocol (DHCP)

·         Domain Name System (DNS)

·         Windows Internet Name Service (WINS)

·         Windows 2000 and Windows Server 2003 Active Directory

·         Certificate Authorities (CAs) and Public Key Infrastructure (PKI)

·         Internet Authentication Service (IAS) or RADIUS

 

Dynamic Host Configuration Protocol (DHCP) Server

 

The Dynamic Host Configuration Protocol (DHCP) allows you to automatically assign IP addressing information to VPN clients. IP addressing information the DHCP server can assign to VPN clients includes:

 

·         IP address

·         WINS server address

·         DNS server address

·         Primary domain name

 

The ISA Server firewall/VPN server can be configured to use a static address pool or DHCP to assign IP addresses to VPN clients and gateways. When you use a static address pool, the IP address pool is configured on the ISA Server firewall/VPN server and WINS and DNS server addresses are assigned based on the WINS and DNS server address settings on the internal interface of the ISA Server firewall/VPN server.

 

You can use DHCP to assign VPN clients an IP address, a WINS server address, a DNS server address, and a primary domain name, as well as other DHCP options. The in order to fully utilize the information a DHCP server can provide to the VPN client, the ISA Server firewall/VPN server must be configured with a DHCP Relay Agent. The DHCP Relay Agent acts as a “DHCP proxy” between the VPN client and the DHCP server. The DHCP Relay Agent forwards the DHCP messages between the VPN client and DHCP server and back.

 

Figure 7 shows the relationship between the VPN client acting as a DHCP client, the ISA Server firewall/VPN server, and the DHCP server on the internal network. When the ISA Server firewall/VPN server starts up, it obtains a block of 10 IP addresses from the DHCP server. The ISA Server firewall/VPN server delivers IP addresses from this initial block of addresses. When the ISA Server firewall/VPN server runs out of IP addresses to deliver to VPN clients, it obtains another block of 10 IP addresses.

 

Figure 7

 

The ISA Server firewall/VPN server’s Routing and Remote Access Service does not obtain any DHCP options (such a WINS address, DNS address and primary domain name) on system start up. Instead, the DHCP Relay Agent relays requests for DHCP options to the DHCP server and returns those options to the DHCP client.

 

*       Note:
You do not need to install a DHCP server on your network to support VPN clients or VPN gateways. The most compelling reason for using a DHCP server to support VPN clients is the ability to assign a primary domain name to VPN clients. Please refer to ISA Server 2000 VPN Deployment Kit document DNS Name Resolution Issues and Solutions for VPN Client/Server and VPN Gateway to Gateway Connections for more information on how assigning a primary domain name to VPN clients aid in name resolution. Please refer to ISA Server 2000 VPN Deployment Kit document Configuring the DHCP Relay Agent to Support VPN Client TCP/IP Addressing Options for details on configured a DHCP server on the internal network and a DHCP Relay Agent on the ISA Server firewall/VPN server.

 

Domain Naming Service (DNS) Server

 

You must have a DNS server on your internal network. A DNS server is required if you run a Windows 2000 or Windows Server 2003 Active Directory domain. However, you should still have a DNS server on your network even if you don’t have an Active Directory domain. In the absence of a Active Directory domain, the DNS server is used to resolve Internet DNS host names. The DNS server used to resolve Internet DNS host names can be located on a server on the internal network, or you can configure a co-located caching-only DNS server on the ISA Server firewall/VPN server machine.

 

DNS servers use other DNS servers to resolve a DNS host name to an IP address. Figure 8 shows what happens when a DNS client computer (such as a VPN client) sends a request for name resolution to a DNS server for the name www.example.microsoft.com:

 

  1. The DNS client sends a request to a DNS server on the internal network to resolve the name example.microsoft.com.
  2. The DNS server checks to see if it has the IP address for this DNS host name in its DNS cache. If the IP address is not in the DNS cache, the server then checks to see if it is authoritative (responsible for) the microsoft.com domain. If the DNS server is not responsible for the microsoft.com domain, then the DNS server begins the process of “recursion”. The recursive process involves sending a series of “iterative” queries to DNS servers on the Internet. Because the DNS server sent an “iterative” query request to these Internet DNS servers, the DNS server will accept partial responses to the question what is the IP address of example.microsoft.com?” The DNS server sends an iterative query to an Internet Root DNS server.
  3. The Internet Root DNS server is not authoritative for the microsoft.com domain, but it does know the address of the DNS server responsible for the .com top level domain. The Internet Root DNS server sends the IP address of a DNS server responsible for the .com top level domain to the DNS server.
  4. The DNS server sends a request to the .com DNS server for the IP address of example.microsoft.com.
  5. The .com DNS server responds with the IP address of a DNS server responsible for the microsoft.com domain.
  6. The DNS server sends a query to the microsoft.com domain DNS server to resolve the name example.microsoft.com to an IP address.
  7. The microsoft.com domain DNS server sends back a response informing the DNS server of the IP address of the DNS server responsible for the example.microsoft.com domain.
  8. The DNS server sends a request for the IP address of www.example.microsoft.com to the example.microsoft.com DNS server.
  9. The example.microsoft.com DNS server sends the IP address of DNS host www.example.microsoft.com to the DNS server. The DNS server places this result in its DNS cache.
  10. The DNS server returns the result to the DNS client on the internal network.

 

Figure 8

 

VPN clients leverage internal network DNS servers in two ways:

 

 

VPN clients should be configured to use the ISA Server firewall/VPN server to access the Internet. You set up the VPN clients as Web Proxy and/or Firewall clients. This allows them to connect to Internet resources through the ISA Server firewall/VPN server machine. The Web Proxy and Firewall client configuration allows the ISA Server firewall to resolve names on their behalf. The ISA Server firewall/VPN server should be configured to use an internal DNS server that is able to resolve Internet host names. Please refer to ISA Server 2000 VPN Deployment Kit document DNS Name Resolution Issues and Solutions for VPN Client/Server and VPN Gateway to Gateway Connections  for details on how to configure DNS servers to support Internet DNS host name resolution.

 

 

VPN clients need to resolve DNS host names of servers on the internal network. The only way this can be accomplished it to install and configure a DNS server on the internal network that resolves the DNS host names of internal network hosts, and then configure the ISA Server firewall/VPN server to provide the address of the DNS server to the VPN clients.

 

Windows Internet Name Service (WINS) Server

 

A Windows Internet Name Server (WINS) server can be used to resolve names of internal network computers. In contrast to DNS servers that resolve a DNS host name to an IP address, the WINS server resolves a NetBIOS name to an IP address. The NetBIOS name is often referred to the computer name because the NetBIOS name is a single word, instead of a “dotted” name like DNS host names. In Windows environments, the NetBIOS name is usually the same as the leftmost name or “label” in the FQDN.

 

A WINS server is not required. The primary reason to install a WINS server on the internal network is to support network browsing using the Network Neighborhood or My Network Places applet. You should install a WINS server if your VPN clients need to be able to browse the internal network to access shared resources on file servers.

 

Please refer to ISA Server 2000 VPN Deployment Kit article Configuring VPN Clients to Support Network Browsing for detailed information on how to support network browsing for VPN clients.

 

*       Note:
The details of the Windows browser service are beyond the scope of this ISA Server 2000 VPN Deployment Kit article. There are many reasons why the Windows browser service may fail. If you have problems with network browsing, please refer to Microsoft Knowledge Base article Troubleshooting the Microsoft Computer Browser Service.

 

Figure 9 shows how a WINS server works on a simple three segment (three subnet) network. Computers on Subnet 1, Subnet 2 and Subnet 3 register their computer names with the WINS server when they start up. The WINS server stores the computer name and IP address of each computer on the network that is configured to use the WINS server. When a computer on Subnet 1 needs to communicate with a computer on Subnet 3, the computer on Subnet 1 asks the WINS server for the IP address of the computer on Subnet 3. The WINS server returns the address and the computer on Subnet 1 sends the request to the computer on Subnet 3.

 

 

Figure 9

 

VPN clients can also send requests to the WINS server to find the IP address of a computer based on its computer name, instead of the entire FQDN.

 

*       Note:
WINS servers support VPN clients that are not configured with a primary domain name. If you have a DNS server on the internal network and a WINS server on the internal network, you can configure a WINS referral zone that the DNS server can use to resolve unqualified names for VPN clients. Please refer to TechNet article Using WINS lookup for more information on how WINS referral zone work and how to configure them.

 

Windows 2000 and Windows Server 2003 Active Directory

 

The Active Directory is a centralized database containing domain directory information. Directories contain information about users, groups, computers and network policies. There are an insurmountable number of advantages of joining all network computers to an Active Directory domain versus not doing so.

 

All articles in this ISA Server 2000 VPN Deployment Kit assume that you have either a Windows 2000 or Windows Server 2003 Active Directory domain on the internal network.

 

Your ISA Server firewall/VPN server leverages the Active Directory database in the following ways:

 

 

There are many other advantages to using Active Directory domains with your ISA Server firewall/VPN server. Please refer to TechNet article Technical Overview of Windows Server 2003 Active Directory for a good overview of Windows Server 2003 Active Directory features and enhancements.

 

Certificate Authorities (CAs or Certificate Servers) and Public Key Infrastructure (PKI)

 

A Certificate Authority is a machine that can issue certificates to users or computers. Certificates include information about the computer or user and confirm the identity of that computer or user. A certificate typically includes:

 

 

Certificate Authorities are also known as Certificate Servers. You can use a Windows 2000 or Windows Server 2003 Certificate Server to issue computer certificates to VPN clients and servers that can be used to create L2TP/IPSec VPN connections. User certificates can be issued to users and these certificates can be presented to the ISA Server firewall/VPN server for user authentication.

 

Certificates and Certificate Servers are part of a wider subject known as Public Key Infrastructure (PKI). The subject of PKI has the potential to become extraordinary complex, and many VPN and firewall administrators get lost in the details of PKI and give up on using certificates to create secure L2TP/IPSec VPNs and SSL secured Web sites.

 

While learning the entire theory and practice of PKI is a long and tedious process, you do not need to be familiar with all the intricacies of PKI to allow your VPN client to use L2TP/IPSec to connect to your ISA Server firewall/VPN server.

 

In the context of this ISA Server 2000 VPN Deployment Kit, you need to be aware of the following features and functions of certificates and Certificate Servers in your organization:

 

·         A computer certificate is required to create an L2TP/IPSec connection

 

Both the ISA Server firewall/VPN server and the VPN client must have a computer certificate installed before they can establish a L2TP/IPSec VPN link. The exception to this is to use a pre-shared key that is configured on the VPN client and server. There are a number of disadvantages to using a pre-shared key to support L2TP/IPSec connections and pre-shared keys are not recommended.

 

·         A user certificate can be used to provide a high level of security to user authentication to the ISA Server firewall/VPN server

 

While computer certificates can be used to create an L2TP/IPSec connection between the VPN client and ISA Server firewall/VPN server, user certificates can be used to authenticate users instead of requiring users to enter user names and passwords. User certificates are not required to create L2TP/IPSec connections.

 

·         All machines participating in a certificate dependent connection attempt much trust the root CA issuing the certificates

 

The VPN client, the VPN server and the VPN gateway participating in a L2TP/IPSec connection must trust the certificates presented by the opposite device.

 

For example, when a VPN client attempts to create a L2TP/IPSec VPN connection to the ISA Server firewall/VPN server, the client and server exchange a list of root certificate authorities that each machine trusts. If the client doesn’t trust the certificate authority that issued the VPN server’s certificate or if the VPN server doesn’t trust the certification authority that issued the VPN client’s certificate, then the IPSec negotiation phase will fail and the L2TP/IPSec VPN link will not be established.

 

The problem is solved by placing the root certificate authority’s self-signed CA certificate into the Trusted Root Certification Authorities node into each machine’s certificate store. This procedure is discussed in detail in ISA Server 2000 VPN Deployment Kit document Obtaining a Machine Certificate via Web Enrollment from a Windows Server 2003 Standalone CA.

 

·         Fragment filtering must be disabled on network devices in the path to the ISA Server firewall/VPN server serving the L2TP/IPSec VPN connection

 

Fragment filtering must be disabled in order for the certificate exchange process to complete so that the IPSec security associations can be established. If IP fragments are blocked at the ISA Server firewall/VPN server, or any firewalls or routers in front of the ISA Server firewall/VPN server, then the L2TP/IPSec VPN connection attempt will fail.

 

·         Microsoft Certificate Servers can be installed as either standalone or enterprise CAs

 

If you choose to host your own certificate authorities, you can install either a standalone or enterprise certificate authority. A standalone certificate authority is helpful if you do not have a Active Directory domain or you wish to assign certificates to machines or users that are not members of the internal network domain. The enterprise certificate authority allows you to automatically deploy machine and user certificates to user and computers.

 

Please refer to ISA Server 2000 VPN Deployment Kit documents Installing and Configuring a Windows Server 2003 Standalone Certification Authority and Installing and Configuring a Windows Server 2003 Enterprise Certification Authority for more information on installing and configuring a standalone and enterprise CA. Please refer to ISA Server 2000 VPN Deployment Kit documents Obtaining a Machine Certificate via Web Enrollment from a Windows Server 2003 Standalone CA and Assigning Certificates to Domain Members via Autoenrollment in a Windows Server 2003 Active Directory Domain for more information on how to assign machine certificates to VPN clients and servers.

 

·         Third party certificates can be used for both user and computer authentication

 

You do not need to issue your own certificates. There are circumstances that using a third party certificate authority is preferred. If you want your users to be able to create SSL or VPN connections from untrusted systems, such as workstations located at a partner site, an airport kiosk, or other public device, then you should use a third party certificate authority. It is unlikely that your root certificate authority’s self-signed certificate is in the Trusted Root Certificate Authorities machine certificate store on these untrusted machines because you have no administrative control over these machines.

 

*       Note:
Third party certificates are more useful in situations where you wish to allow SSL connections to Web servers on your internal network. Because of the nature of VPN connections, you usually do not wish to allow untrusted devices full access to the corporate network. For this reason, if you require certificates only for L2TP/IPSec VPN connections, you should consider deploying your certificates using the Microsoft Certificate Server included with Windows 2000 and Windows Server 2003.

 

·         Certificates are about increased security and administrative control. They are not about ease of use or deployment

 

Certificate deployment to VPN clients and servers can be time consuming and there may be a number of perceived inefficiencies in the system. It’s important to realize that certificate based L2TP/IPSec VPN connections and certificate-based user authentication is all about increased security, not increased convenience for the user or administrator. However, we believe that the short term pain of deploying certificates will allow your organization to avoid the long term risks of a lower security solution.

 

Please refer to Planning Your Public Key Infrastructure and Certificates overview for more information on PKI and Microsoft Certificate Servers.

 

Internet Authentication Server (IAS) or RADIUS Server

 

The Microsoft Internet Authentication Server (IAS) allows VPN clients to authenticate using domain credentials when the ISA Server firewall/VPN server is not a member of the internal network domain. This adds a layer of security to the ISA Server firewall/VPN server solution because if the firewall is compromised in any way, the machine’s domain membership cannot be leveraged to attack the internal network.

 

*       Note:
Another term commonly used for the Internet Authentication Server is RADIUS server. RADIUS stands for Remote Access Dial-in User Service. IAS/RADIUS servers are in widespread use on the Internet so that the RAS server receiving credentials for a connection request can use another machine located elsewhere to authenticate the request.

 

Figure 10 show a number of scenarios where an IAS server can be used to “offload” authentication from the machine or network device accepting the authentication request. In the case of the ISA Server firewall/VPN server, the VPN server component forwards the credentials presented to it by the VPN client to the IAS server on the internal network. The IAS Server forwards these credentials to a domain controller which authenticates the user. The IAS Server also can apply Remote Access Policy to control what users and what types of connections are allowed to the ISA Server firewall/VPN server.

 

Figure 10

 

IAS Servers also allow you to centralize Remote Access Policies. For example, suppose you have five ISA Server firewall/VPN servers configured in a network load balancing (NLB) array. You wish to apply the same Remote Access Policies to all of the ISA Server firewall/VPN servers. You could do this manually on each server or you could configure each of the servers to use an IAS Server on the internal network. You configure the Remote Access Policies once on the IAS Server on the internal network and the same policies are automatically applied to each ISA Server firewall/VPN server.

 

Please refer to Installing and Configuring Windows Server 2003 RADIUS Support for VPN Clients – Including Support for EAP/TLS Authentication for more information on using IAS Servers with your ISA Server firewall/VPN servers.

 

TCP/IP Addressing Considerations with VPN Networks

 

One of the most common reasons for a VPN client/server or VPN gateway to gateway configuration to fail is that the IP addressing schemes on the networks involved do not support the VPN connection. It’s important to consider the current IP addressing configuration on the network and figure your VPN server to support VPN client and VPN gateway connections.

 

Supporting VPN Clients

 

VPN clients can be assigned two general types of addresses:

 

·         On-subnet network addresses

 

On-subnet network addresses belong to the same network ID as the internal interface of the ISA Server firewall/VPN server. This is the most common method used to assigned addresses to VPN clients. On-subnet network addresses have the advantage of not requiring you to create special routing table entries to support the VPN clients.

 

You can create a static pool of on-subnet addresses on the ISA Server firewall/VPN server itself, or you can use a DHCP server on the internal network to assign these addresses.

 

For example, suppose the IP address on the internal interface of the ISA Server firewall/VPN server is 10.0.0.1/16. You would then create a static address pool on the ISA Server firewall/VPN server with a group of addresses in the 10.0.0.0/16 network ID, or you would configure a scope on the DHCP server o the internal network with a group of addresses on the 10.0.0.0/16 network ID. When the VPN clients connect to the ISA Server firewall/VPN server, they are assigned an address in the configured range. VPN clients will be able to connect to any resource on the internal network that can research the IP address of the internal interface of the ISA Server firewall/VPN server.

 

·         Off-subnet network addresses

 

The disadvantage of on subnet network addressing is that VPN clients that enable split tunneling can access resources on the internal network. This is an undesirable configuration because VPN clients with split tunneling enabled can directly access the Internet without being forced to use firewall policy while connected to the internal network via the VPN connection. One way you can prevent this from being a problem is to use off-subnet addresses for VPN clients.

 

For example, suppose the internal network behind the ISA Server firewall/VPN server is based on network ID 10.0.0.0/8. All segments on the internal network are assigned subnets of this network ID. Now suppose the VPN client enables split tunneling. When the VPN client connects to the ISA Server firewall/VPN server, the client is assigned the IP address 10.0.0.10/8 (VPN clients are always assigned class-based subnet masks).

 

The VPN client will be able to access all networks on the internal network because all networks are subnets of 10.0.0.0/8. For example, the VPN client needs to connect to network ID 10.1.0.0/16, which is a subnet remote from the Internet interface of the ISA Server firewall/VPN server. The VPN client, who is using the default subnet mask, sees the destination network ID as 10.0.0.0/8, so it sends the request via its VPN interface. The VPN clients don’t need to use the VPN interface as its default gateway because the VPN client sees the remote network as being on the same network ID. The VPN client can then use the ISP connection as its default gateway and still connect to all networks on the internal network.

 

What would happen if you assigned the VPN clients IP addresses in network ID 172.17.0.0/12? If the VPN client is configured to allow split tunneling, it is using its ISP connect for its default gateway. When the VPN client tries to access resources on network ID 10.1.0.0/16, the VPN client sees the remote network ID as different from the network ID belonging to any of its interfaces, and therefore sends the request to its default gateway. The ISP’s router drops the request for 172.17.0.0./12 because it is a private IP address. The VPN client with split tunneling enabled is stopped from accessing resources on the internal network.

 

Regardless of whether you use on or off subnet addresses, make sure that VPN clients have some way to obtain an IP address. One of the most common reasons for connection failure is that the VPN client is unable to obtain an IP address.

 

Supporting VPN Gateway to Gateway Connected Networks

 

Networks connected over the Internet via a gateway to gateway link are addressed in the same way any other routed network is addressed. The ISA Server firewall/VPN servers acting as VPN routers that route packets from one private network to the other over the Internet, in the same way that an Ethernet router routes packets from one network ID to another on the internal network.

 

There are three basic IP addressing considerations that are important to the success of the gateway to gateway configuration:

 

·         All networks must have different network IDs

 

Each site connected by the gateway to gateway link must be on a different network ID. All networks behind each VPN gateway must have different network IDs than the networks that are behind the opposite VPN gateway. You cannot have a 10.1.0.0/16 network at the local site and a 10.1.0.0/16 at the remote network. How would the internal network routers know whether it should stay within the same network or be sent over the VPN gateway to the opposite site?

 

This is not an optional setting. All network IDs must be different. You cannot allow duplication of network IDs on the sites connected by the VPN gateways.

 

·         Configure static routing table entries

 

Static routing table entries are configured on the ISA Server firewall/VPN servers to allow proper routing through the VPN interface for packets destined to opposite network connected by the gateway to gateway link. The ISA Server 2000 Local and Remote VPN Wizards create these static routing table entries for you automatically.

 

·         Configure dynamic routing protocols

 

If you have a large network with many network IDs and multiple paths to each network, then you may wish to use a dynamic routing protocol such as RIP or OSPF to allow proper routing of requests through the VPN gateways. Please refer to Achieving Site-to-Site Virtual Private Networking and Perimeter Security in a High Availability Environment with Microsoft ISA Server and RRAS for more information on how to use dynamic routing protocols in conjunction with your gateway to gateway VPN configuration.

No Anti-Virus for ISA Server? Get Real!! GFI DownloadSecurity for ISA Server