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:
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:
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.