TECHREPUBLIC RESOURCE CD LICENSE AGREEMENT
READ THIS AGREEMENT BEFORE USING THIS TECHREPUBLIC
RESOURCE CD-ROM DISK (“CD”) FROM TECHREPUBLIC. BY
USING THE CD YOU AGREE TO BE BOUND BY THE TERMS AND
CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO
THE TERMS AND CONDITIONS OF THIS AGREEMENT, IMMEDI-
ATELY RETURN THE UNUSED CD FOR A FULL REFUND OF
MONIES PAID, IF ANY.
The articles, forms, tools, templates, programs, and other materials
included on this CD and their compilation (the ‘Collection’) are
licensed to you subject to the terms and conditions of this
Agreement by TechRepublic, having a place of business at 1630
Lyndon Farm Court, Louisville, KY 40223 (‘TechRepublic’).
By using the Collection, in whole or in part, you agree to be bound
by the terms and conditions of this Agreement. TechRepublic owns
the title to the Collection and to all intellectual property rights
therein, except in so far as it contains materials that are proprietary
to third-party suppliers. All rights in the Collection except those
expressly granted to you in this Agreement are reserved to
TechRepublic and such suppliers, as their respective interests may
appear.
1. Limited License
TechRepublic grants you a limited, nonexclusive, nontransferable
license to use the Collection on a single dedicated computer. This
Agreement and your rights hereunder shall automatically terminate
if you fail to comply with any provision of this Agreement. Upon
such termination, you agree to destroy the CD and all copies of the
CD, whether or not lawful, that are in your possession or under
your control.
2. Additional Restrictions
A. You shall not (and shall not permit other persons or entities to)
directly or indirectly, by electronic or other means, copy or repro-
duce (except for archival purposes as permitted by law), publish,
distribute, rent, lease, sell, sublicense, assign, or otherwise transfer
the Collection or any part thereof or this Agreement, and neither the
CD nor its contents can be shared over a network for access by
multiple users without a separate site license agreement. Any
attempt to do so shall be void and of no effect.
B. You shall not (and shall not permit other persons or entities to)
reverse-engineer, decompile, disassemble, merge, modify, create
derivative works of, or translate the Collection or use the
Collection for any purpose.
C. You shall not (and shall not permit other persons or entities to)
remove or obscure TechRepublic’s or its suppliers’ copyright,
trademark, or other proprietary notices or legends from any portion
of the Collection or any related materials.
3. Limited Warranty and Limited Liability
A. THE ONLY WARRANTY MADE BY TECHREPUBLIC IS THAT
THE ORIGINAL CD IN WHICH THE COLLECTION IS EMBODIED
AND WHICH IS DISTRIBUTED BY TECHREPUBLIC SHALL BE FREE
OF DEFECTS IN MATERIALS AND WORKMANSHIP FOR A PERIOD
OF NINETY (90) DAYS AFTER DELIVERY TO YOU. TECHREPUB-
LIC’S AND ITS SUPPLIERS’ ENTIRE LIABILITY AND YOUR EXCLU-
SIVE REMEDY SHALL BE LIMITED TO THE REPLACEMENT OF
THE ORIGINAL CD, IF DEFECTIVE, WITHIN A REASONABLE
PERIOD OF TIME.
B. EXCEPT AS SPECIFICALLY PROVIDED ABOVE, THE COLLEC-
TION IS PROVIDED ‘AS IS’ WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITA-
TION, ANY WARRANTY OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
RESULTS AND PERFORMANCE OF THE SOFTWARE AND OTHER
MATERIAL THAT IS PART OF THE COLLECTION IS ASSUMED BY
YOU, AND TECHREPUBLIC AND ITS SUPPLIERS ASSUME NO
RESPONSIBILITY FOR THE ACCURACY ON APPLICATION OF OR
ERRORS OR OMISSIONS IN THE COLLECTION. IN NO EVENT
SHALL TECHREPUBLIC OR ITS SUPPLIERS BE LIABLE FOR ANY
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
COLLECTION, EVEN IF TECHREPUBLIC OR ITS SUPPLIERS HAVE
BEEN ADVISED OF THE LIKELIHOOD OF SUCH DAMAGES
OCCURRING. TECHREPUBLIC AND ITS SUPPLIERS SHALL NOT
BE LIABLE FOR ANY LOSS, DAMAGES, OR COSTS ARISING OUT
OF, BUT NOT LIMITED TO, LOST PROFITS OR REVENUE; LOSS
OF USE OF THE COLLECTION; LOSS OF DATA OR EQUIPMENT;
COST OF RECOVERING SOFTWARE, DATA, OR THE MATERIALS
IN THE COLLECTION; THE COST OF SUBSTITUTE SOFTWARE,
DATA OR MATERIALS IN THE COLLECTION; CLAIMS BY THIRD
PARTIES; OR OTHER SIMILAR COSTS.
C. THE WARRANTIES AND REMEDIES SET FORTH HEREIN ARE
EXCLUSIVE AND IN LIEU OF ALL OTHERS, ORAL OR WRITTEN,
EXPRESSED OR IMPLIED. NO TECHREPUBLIC AGENT OR
EMPLOYEE OR THIRD PARTY IS AUTHORIZED TO MAKE ANY
MODIFICATION OR ADDITION TO THIS WARRANTY.
D. SOME STATES DO NOT ALLOW EXCLUSION OR LIMITATION
OF IMPLIED WARRANTIES OR LIMITATION OF LIABILITY FOR
INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE
LIMITATIONS OR EXCLUSIONS MAY NOT APPLY TO YOU.
4. U.S. Government Restricted Rights
The Collection is licensed subject to RESTRICTED RIGHTS. Use,
duplication, or disclosure by the U.S. Government or any person or
entity acting on its behalf is subject to restrictions as set forth in
subdivision (c)(1)(ii) of the Rights in Technical Data and Computer
Software Clause at DFARS (48 CFR 252.227-7013) for DoD con-
tracts, in paragraphs (c)(1) and (2) of the Commercial Computer
Software and the Restricted Rights clause in the FAR (48 CER
52.227-19) for civilian agencies or in other comparable agency
clauses. The contractor, manufacturer, is TechRepublic.
5. General Provision
Nothing in this Agreement constitutes a waiver of TechRepublic’s
or its suppliers’ rights under U.S. copyright laws or any other feder-
al, state, local, or foreign law. You are responsible for installation,
management, and operation of the Collection. This Agreement shall
be construed, interpreted, and governed under California law.
CD-ROM Requirements
The TechRepublic Resource CD requires:
• Windows 98/98SE/ME/NT4/2000 or XP
• Internet Explorer 5.0 or later
• 16 MB of RAM or more
• 10 MB of free disk space or more
• Windows-compatible CD-ROM drive
 ®

Administrator's Guide
to VPN and Remote Access,
Second Edition
TechRepublic Credits and Copyrights
Managing Editor, Ancillaries Content Resources Manager
Janice Conard Marilyn Bryan
Track Editors Promotions Manager, Membership
John Sheesley, Jack Wallen, Jr., Jim Wells Megan Hancock
Community Editors Membership Director
Paul Baldwin, Toni Bowers, Bill Detwiler, Dan Scofield
Jason Hiner, Judy Mottl
Director of Community Content
Senior Review Editor Veronica Combs
Rich Crossett
Editor in Chief, TechProGuild and Ancillaries
Review Editors Erik Eckel
Kachina Dunn, Jody Gilbert, Kim Mays,
Geri Perkins, Dennis Ryan
Editor in Chief, TechRepublic
Lisa Kiava
Copy Editors
Vice President, Membership
Susan Craig, Selena Frye, Susan Mitchell,
Jon Pyles
Lauren Mosko, Julie Tonini, Linda Watkins
Vice President, TechRepublic
Editorial Intern
Bob Artner
Lindsay Puckett
TechRepublic
Product Manager, Content Management
9900 Corporate Campus Drive
Travis Frazier
Suite 1500
Graphic Artists Louisville, KY 40223
Natalie Strange, Kimberly Wright E-mail: customerservice@techrepublic.com
www.techrepublic.com

© 1995-2002 by CNET Networks, Inc. All rights reserved. TechRepublic and its logo are trade-
marks of CNET Networks, Inc. All other product names or services identified throughout this
book are trademarks or registered trademarks of their respective companies.
Reproduction of this publication in any form without prior written permission is forbid-
den. The information contained herein has been obtained from sources believed to be reliable.
CNET Networks, Inc. disclaims all warranties as to the accuracy, completeness, or adequacy
of such information. CNET Networks, Inc. shall have no liability for errors, omissions, or
inadequacies in the information contained herein or for the interpretations thereof. The reader
assumes sole responsibility for the selection of these materials to achieve its intended results.
The opinions expressed herein are subject to change without notice.

ISBN 1-931490-43-0
Foreword

I
ncreasingly, leaders throughout the enterprise are recognizing the business benefits of providing
authorized users remote access to electronic data. However, as an IT professional, you know
that the risks associated with transferring data across the Internet far outweigh the benefits of,
say, being able to check e-mail from anywhere in the world. How do you reconcile the need to pro-
vide remote access to sensitive corporate data with the greater need to safeguard it?
The solution for many IT organizations is to create a secure tunnel for data transfer via a virtual
private network (VPN). As you know, VPN technology lets users take advantage of high-speed
Internet access while minimizing the Internet’s attendant security risks. To more thoroughly under-
stand the ins and outs of VPN implementation in today’s enterprise computing environments, look
no further than TechRepublic’s Administrator’s Guide to VPN and Remote Access, Second Edition.
In this updated version of one of our most popular titles, you’ll find expert information and
advice to help you:
X Determine how to provide remote access without compromising data security.
X Set up and administer VPNs within Windows, NetWare, and Linux networks.
X Configure VPN connections with firewalls.
X Optimize VPN and remote access connections.
X Troubleshoot TCP/IP and other data transfer protocol issues.
X Identify and evaluate a wide range of remote access solutions.
As an added bonus, the searchable CD-ROM includes a special chapter of case studies by in-the-
trenches IT professionals, including two pieces on TechRepublic’s own VPN implementation.
If you have suggestions or comments regarding this product, please e-mail us at
trproducts@techrepublic.com.
Quick Reference
Introduction to VPN and Remote Access ........................................................1
Administration..............................................................................................23
Security ....................................................................................................159
Protocols....................................................................................................177
Solutions ....................................................................................................207
Case Studies ......................................................................................CD-ROM
 Administrator's Guide
to VPN and Remote Access, Second Edition

Introduction to VPN and Remote Access

Virtual private networks: The current state ..................................................................................................1
Understanding virtual private networking ....................................................................................................5
Going beyond the buzz to understand VPN technology ..........................................................................8
Virtual private networks save money, increase productivity ....................................................................11
How can using a VPN benefit your company? ..........................................................................................13
Understand your organization’s needs before selecting VPN hardware ................................................14
Cost benefit of VPN appliances vs. VPN servers ....................................................................................15
Telecommuting: Balancing the need for speed and security ....................................................................17
Access your home PC from the office ........................................................................................................19

Administration
Managing remote access to your network ..................................................................................................23
Understanding and troubleshooting virtual private networking ..............................................................26
Controlling the dial-up bandwidth on your VPN ......................................................................................34
Making the connection with Windows 2000 Professional Dial-Up Networking ................................35
Understanding demand dial connections in Windows 2000 ....................................................................43
Configuring Windows 2000 for demand dial connections ......................................................................46
How to configure Win2K client VPN connections ..................................................................................50
Setting up a VPN with Windows 2000 ........................................................................................................53
Issues surrounding a Windows 2000 VPN implementation ....................................................................58
Setting up a Windows 2000 virtual private network..................................................................................60
Introducing Windows 2000 Routing and Remote Access ........................................................................63
Configuring Routing and Remote Access on your Windows 2000 server ............................................68
Configuring Windows 2000 as a remote access server ............................................................................75
Increasing Windows 2000 RRAS security ..................................................................................................78
Routing and remote access on Windows 2000 Advanced Server ..........................................................82
Optimize inbound client connections for your Windows 2000 VPN servers ......................................85
VPN networking services built for speed....................................................................................................91
Optimal VPN server configuration and management ..............................................................................95
Troubleshoot Windows RAS and VPN connections with these tips ....................................................99
Learn why NAT can cause VPN connection problems ........................................................................102
Create a gateway-to-gateway VPN with ISA Server 2000 ......................................................................104
Troubleshoot ISA Server VPN connections ............................................................................................108
Configure Windows XP Professional to be a VPN server ....................................................................113
How to configure Windows XP client VPN connections......................................................................118
Configure Windows NT to support VPN connections..........................................................................119
Monitoring and troubleshooting VPN connections in WinNT ............................................................124
The Win9x VPN client connection guide ................................................................................................127
Understanding Exchange 2000 Server’s Outlook Web Access..............................................................132
Enabling Web access of Exchange accounts using Outlook Web Access ..........................................137
Enhance Exchange 2000 OWA using front-end servers ........................................................................141
Implementing site-to-site VPN with BorderManager 3.x ......................................................................143
Setting up client-to-site VPN in BorderManager 3.x ..............................................................................148
Serving up NetWare’s Web Manager..........................................................................................................153
Believe it or not: A Linux VPN without kernel recompilation ............................................................155

Security
Configuring VPN connections with firewalls ..........................................................................................159
Securing the Edge: Windows 2000 Firewall/VPN and beyond: The firewall ....................................162
Securing the Edge: Windows 2000 Firewall/VPN and beyond: Tuning the security........................164
Secure Shell: Protecting data in transit ......................................................................................................165
Making the most of OpenSSH ..................................................................................................................170
Protect your VPN by keeping a tight rein on passwords ......................................................................173
Protocols
TechRepublic’s TCP/IP primer ..................................................................................................................177
Troubleshoot your network errors with TechRepublic’s TCP/IP checklist ........................................180
Troubleshoot Novell TCP/IP network errors with TechRepublic’s checklist ....................................183
Putting the “private” in virtual private networking..................................................................................186
Configuring certificates for an L2TP/IPSec VPN ..................................................................................191
Customize the security of L2TP/IPSec connections ............................................................................196
Troubleshooting L2TP/IPSec VPN connections in Win2K ................................................................199
The Windows NT 4.0 PPTP VPN client connection guide ..................................................................202

Solutions
VPN services on a Cisco PIX firewall ......................................................................................................207
Eight commonly overlooked troubleshooting tips for the Cisco PIX VPN ......................................210
SonicWALL PRO-VX provides fast, simple firewall and VPN solution ............................................213
The D-Link DI-704 cable/DSL gateway ..................................................................................................215
Who said you can’t afford your own router? ............................................................................................220
Sharing Internet access with just one IP address ....................................................................................222
Share small office broadband pipes using a Linksys router and Win2K Pro......................................224
Check Point offers integrated firewall and VPN on Linux ....................................................................228
High marks for Mangosoft’s VPN alternative..........................................................................................230
More options for secure collaboration ..........................................................................................CD-ROM

Case Studies
Dealing with the growing pains of a site-to-site VPN ................................................................CD-ROM
International VPN can have its challenges ....................................................................................CD-ROM
How to resolve two common VPN problems..............................................................................CD-ROM
A TechRepublic member shares his VPN success story ............................................................CD-ROM
Free VPN solution had a major impact on this company ..........................................................CD-ROM
A VPN case study: A creative solution for a VPN-based WAN ..............................................CD-ROM
Admin finds low-cost VPN solution using Linux........................................................................CD-ROM
 Introduction to VPN
and Remote Access
Introduction to VPN and Remote Access
This opening chapter provides an overview of the benefits of virtual private networking, the
technology that makes it possible, and some of the issues that must be considered when planning
a VPN implementation.

Virtual private networks: The current state..............................................................................................1

Understanding virtual private networking ................................................................................................5
Going beyond the buzz to understand VPN technology ......................................................................8
Virtual private networks save money, increase productivity................................................................11
How can using a VPN benefit your company? ....................................................................................13
Understand your organization’s needs before selecting VPN hardware ..........................................14
Cost benefit of VPN appliances vs. VPN servers................................................................................15
Telecommuting: Balancing the need for speed and security ..............................................................17
Access your home PC from the office....................................................................................................19
Virtual private networks: The current state
May 4, 2000
By Scott Lape
A
virtual private network (VPN) by defi-
nition is quite simply secure access to
data and/or resources via a private
network. This private network connects
through public data lines and uses a tunneling
protocol and encryption by individuals or
machines for whom the data and/or resource
is intended.
Over the past few years, VPN has become
one of the most-used acronyms in the history
of the networking industry. Every company
that can possibly justify instituting a VPN solu-
tion is chomping at the bit to do so.
In this article, I’ll discuss the benefits of
deploying a VPN and examine the design and
technology behind it.
The path of least resistance
They (you know—all of those “experts” out
there who know everything) say that VPNs
and related services will have a market of
greater than $10 billion by 2001. CEOs, CIOs,
networking executives, and even the managers
below them have become very well read in the
area of VPNs. Something about the promise
of having secure access to a corporate network
from darn near anywhere in the world is
tremendously appealing—not to mention the
convenience and relatively low expense associ-
ated with setting up and maintaining a highly
available global network. It seems that in a
world of nonstandard standards and rapidly
changing technologies, a VPN (which is largely
standards-based) is the path of least resistance
to a highly available, reliable, and secure net-
work to which you could potentially connect
(with the right tools) from a thatched hut in
the Himalayas.
On the surface, the high-level benefit of a
VPN seems great. One small fact to keep in
mind: Understanding the benefits and the tech-
nologies of a VPN and how it works is very
different than knowing you need one. The only
way to truly reap the benefit is to dig into the
technology and its foundation. Many of the
above-mentioned professionals and others
alike have only begun to scratch the surface of
the potential of virtual private networking, its
services, and its capabilities.
VPN from the clouds
It is only appropriate to touch on the benefits
of deploying a VPN prior to delving into its
technologies. These benefits are not all that
exist, nor do they apply to every organization
and circumstance. Your actual results and ben-
efits may vary.
Cost seems to drive and control many proj-
ects in the networking industry. Technologies
are available to provide almost any desired or
required result, assuming that a company’s
pockets are deep enough. Realistically, every
member of every technology team faces some,
if not many, budgetary constraints. (If you’re a
hiring manager and your company’s projects
don’t have any monetary or budgetary con-
straints, please e-mail me and I will forward
you a résumé.) Members of information tech-
nology departments and their managers are
paid to find and implement better ways to
reach an end. Better can mean faster or more
reliable, secure, or available. Generally, a better
way to reach a similar end equals—whether
directly or indirectly—less expensive. And
VPNs may be the answer for many companies.
One of the most-known benefits of VPNs
is access to resources from any point on the
Internet. This access could potentially provide
companies that currently manage multiple net-
work points of entry with the ability to main-
tain a single point of entry. A fast connection
to the Internet via an Internet service provider
(ISP) could take the place of many, if not all,
other data lines and remote-access mediums.
A single high-speed line could replace the
function of multiple point-to-point connec-
tions, Frame Relay, ISDN, and analog modems.
Each of these connectivity options requires
some piece of unique hardware, which in turn
requires unique management and expense. The
single link could transport all required traffic
to and from remote users and remote sites.
Introduction to VPN and Remote Access 1
 The most apparent benefits from the reduc- individuals’ homes, VPNs make telecommut-
tion in the number of entry points to a corpo- ing not only an employment alternative but
rate network are fewer potential points of also a selling point to potential employees. The
failure and reduced hardware and administra- labor market is the tightest it has been in his-
tion costs. Another benefit is the ability to take tory. Employers are having a hard time finding
advantage of the inherent redundancy that’s qualified individuals to fill needed positions.
built into the Internet. A properly written Telecommuting via VPNs affords companies
service-level agreement with an ISP could the ability to move outside their local labor
potentially offload some responsibility and market to hire individuals who live virtually
accountability for network uptime. No matter anywhere, without incurring relocation
how high your level of redundancy and plan- expenses.
ning, however, you can’t guarantee that a
worker repairing a phone line in Anywhere, VPN technology
USA, won’t accidentally slice through the Assuming that a VPN is a viable solution for a
wrong fiber-optic cable and drop one or all of company, the two major concerns that many
the core backbones of face are performance
the Internet to its and security. While IP
knees. Catastrophic fail- …an Internet-based VPN consists was designed to be the
ures are just that. All of three pieces: security standard protocol of
the precaution in the the Internet, perform-
gateways, security policy servers, ance and security were
world can’t protect
against these types of and certificate authorities. not necessarily fac-
problems. Luckily, tored into its design. In
though, situations like the early days of the
these are rare. So, using a VPN to reduce your Internet, neither security nor reliable perform-
multiple point-to-point connections is a fairly ance was mandated. Standards have been
safe way to save those resources. introduced to provide the ability to ensure the
All the resources saved usually equate to network performance, security, and availability
dollars. Exactly how many dollars the savings required of a secure VPN.
will turn into is up to debate. Common wis- The major obstacles of transmitting private
dom pegs intranational remote-access savings information over public or shared lines are
estimates in the area of 50 percent. Interna- familiar to most IT managers. Data transmit-
tional estimates of savings are thought to be ted via a VPN must:
close to 90 percent over that of conventional X Maintain its integrity.
remote-access solutions. Site connectivity sav- X Be tamper-resistant.
ings are estimated to be an equally impressive
X Be protected from duplication from
70 percent over point-to-point. These savings
unauthorized parties.
estimates are very generalized. VPNs have the
potential to save many companies money. X Remain confidential until it meets its
However, to say that implementing a VPN will intended recipient.
save every company money would be a mis- VPNs accomplish this by creating tunnels
statement. In the world of technology, there’s along the Internet from the data’s point of ori-
always an exception. gin to the point of delivery. These tunnels are
While potential savings may vary, one state- secure paths through which encrypted data can
ment holds true: Nothing can currently touch travel without being intercepted by unautho-
an Internet-based VPN in terms of global rized parties. Protocol suites have been devel-
availability. This is facilitated by the use of the oped that provide the ability to form VPNs
standards-based Internet Protocol (IP). over the Internet and accomplish the goals I’ve
With the recent explosion of low-cost, listed. Four of these protocol suites are:
high-speed Internet access available to many X PPTP (Point-to-Point Tunneling Protocol)

2 Administrator’s Guide to VPN and Remote Access, Second Edition

X L2F (Layer-2 Forwarding)
X L2TP (Layer-2 Tunneling Protocol)
X IPSec (Internet Protocol Security)
PPTP is a proposed standard that Microsoft
has included with Windows 98, with RRAS for
NT4, and in a service pack for Windows 95.
PPTP uses PPP (Point-to-Point Protocol) to
provide remote-access services across the
Internet via a tunnel. PPP packets are encapsu-
lated by using a modified version of GRE
(Generic Routing Encapsulation) Protocol.
This encapsulation allows other protocols,
including IPX and NetBEUI, to be utilized by
PPTP. This is one of the main attractions of
PPTP. By design, it functions at the Data Link
layer (Layer 2) of the Open Systems Intercon-
nection (OSI) model, allowing for transmission
of protocols other than IP. In contrast, IPSec
functions at the network layer (Layer 3) of the
OSI model. The main weaknesses of PPTP
are its lack of support of token-based authen-
tication and the inability to provide strong
encryption. PPTP relies on PAP (Password
Authentication Protocol), CHAP (Challenge
Handshake Authentication Protocol), and a
Microsoft Windows NT variation that uses
MS-CHAP (Microsoft Challenge Handshake
Authentication Protocol), NT domain-level
security for authentication.
L2F is a tunneling protocol that encapsu-
lates PPP packets within IP packets. It allows
the use of unregistered IP addresses by hiding
the IP address of the remote user from Inter-
net users. Unlike PPTP, L2F has the ability to
work directly with Frame Relay and ATM
(Asynchronous Transfer Mode). L2F uses PPP
for remote user authentication; however, it
supports TACACS (Terminal Access Con-
troller Access System) and RADIUS (Remote
Authentication Dial-in User Service). Where
PPTP allows only single connections to be
made across tunnels, L2F supports multiple
connections. Since it functions at the Data
Link layer (Layer 2) of the OSI model, L2F
also provides the flexibility of being able to
handle protocols other than IP.
L2TP was designed to take over where L2F
and PPTP left off and become a standard
approved by the IETF (Internet Engineering
Task Force). It is a Layer 2 tunneling protocol
that combines the best of both L2F and PPTP.
It supports the transfer of protocols other
than IP and is used primarily in remote-access
scenarios. Although many believe L2TP to be
a security-based protocol, it doesn’t provide a
secure tunnel. Like L2F, it facilitates authenti-
cation of both the user and the connection.
For security, L2TP must incorporate IPSec.
IPSec is widely considered to be the best
solution for the implementation of a secure
VPN. IPSec was originally developed to plug
the security inadequacies of Ipv4 in the next
generation of IP protocols, IPv6. Adoption of
IPv6 has been slow, and the current need for
securing IP packets is great. These two facts
played a large role in the modification of
IPSec to make it compatible with IPv4 in an
attempt to accommodate the security needs
of the current version of IP. Support for
IPSec headers is optional in IPv4 but manda-
tory in IPv6.
In order for current networking applica-
tions to use IPSec, they must incorporate spe-
cial TCP/IP stacks that have been designed to
include the IPSec protocols. IPSec is a Layer 3
security protocol from the IETF that provides
authentication and/or encryption for IP traffic
for transport across the Internet. IPSec affords
the sender of IP packets the ability to authenti-
cate and/or encrypt data at the packet level.
There are two different methods of using
IPSec, which were brought about by the ability
to separate authentication and encryption
application to each packet. The different
modes are referred to as transport mode and
tunnel mode. In transport mode, the transport
layer is the only segment that is authenticated
or encrypted. Tunnel mode authenticates or
encrypts the entire packet, which provides
even more protection against unauthorized
access, interception, or attack.
IPSec is built around a number of standard-
ized cryptographic technologies to provide
confidentiality, data integrity, and authentica-
tion. For example, IPSec uses:
X Diffie-Hellman key exchanges to deliver
secret keys between peers on a public net
X Public key cryptography for signing
Diffie-Hellman exchanges, to guarantee
Introduction to VPN and Remote Access 3
 the identities of the two parties and avoid
man-in-the-middle attacks
X Data encryption standard (DES) and
other bulk-encryption algorithms for
encrypting data
X Keyed hash algorithms (HMAC, MD5,
SHA) for authenticating packets
X Digital certificates for validating public keys
IPSec relies on the exchange of secret
keys to allow different IPSec parties secure
communications. Key management is a “key”
ingredient of IPSec. There are two ways to
handle these key exchanges and management
within the architecture of IPSec: manual key-
ing and the ISAKMP/Oakley scheme, also
referred to as IKE (Internet Key Exchange).
IKE provides the automation of key manage-
ment and is the result of the combining
ISAKMP (Internet Security Association and
Key Management Protocol), which serves as
the framework for authentication and key
exchange, with the Oakley Protocol, which
describes various modes of key exchange.
Both manual keying and IKE are mandatory
requirements of IPSec.
As with any other management automation
tools, the benefit of IKE is easy to see. A
VPN with a small number of sites can use
manual keying effectively. VPN encompassing
a larger number of users and/or supporting
many remote-access users will benefit from the
automation provided by the use of IKE.
IKE is designed to provide the following
capabilities:
X It provides the means for protocol
agreement between parties, along with
which algorithms and keys to use.
X It ensures from the beginning of the
exchange that you’re communicating with
the intended party.
X It manages the keys that are agreed on.
X It ensures that the key exchanges are
handled completely and safely.
IPSec is currently viewed as the best solution
to support an IP-based environment. It includes
the strong security that the other protocol suites
lack: encryption, authentication, and usage of
keys and their management. While IPSec is
4 Administrator’s Guide to VPN and Remote Access, Second Edition
designed to handle only IP packets, PPTP and
L2TP are better suited to environments requir-
ing transmission of IPX, NetBEUI, and
AppleTalk.
VPN design
Aside from the Internet, an Internet-based
VPN consists of three pieces: security gate-
ways, security policy servers, and certificate
authorities. The Internet is the foundation and
groundwork of a VPN. It provides the large
pipes for traversal by the small tunnels created
by a VPN.
A security gateway is the gatekeeper of the pri-
vate network. It provides security against
unauthorized access to the information on the
inside. It can consist of routers, firewalls, VPN
hardware, and/or software. In many cases, all
or most of these functions are provided by the
gateway, or vice versa.
The security policy server contains the access-
list information, which dictates what and
who to allow and disallow access to resources.
This access list can reside in many places: a
router, firewall, VPN hardware, or RADIUS
server.
Certificate authorities are the governing body
of key verification. This governing body can
be a database residing inside the private net-
work or can be outsourced to a third party.
The latter provides the best method of key
verification in cases where corporations make
use of extranets.
Basic questions that should be answered
before settling on the best VPN solution (if
any) for your company include the following:
X How many users are at each site?
X What are the bandwidth requirements for
each needed connection?
X Does the connection need to be permanent
or on-demand (dial-up)?
X How much traffic will the site generate?
X Are there times when traffic is higher
than others?
X What are the service-level requirements?
X Are there any problems existing in your
company that will be solved by the
implementation of a VPN?
X Why is a VPN better than the next
competing alternative?
X Should the VPN be outsourced or built
in-house?
VPN last word
Tremendous advantages accompany the imple-
mentation of a VPN for many companies. In
many cases, there are also tremendous savings
associated with VPN that could make the proj-
ect sponsor a corporate hero—not to mention
the fact that a VPN and a fast Internet connec-
tion at a user’s home are a telecommuter’s
dream. However, as with any relatively new
technology, there are numerous questions to
be asked and much studying to be done.
Understanding virtual private networking
June 15, 2000
By Talainia Posey
D
o you have traveling users on your
network who wish they could con-
nect to your corporate network from
home, a hotel room, or even an airport?
Unfortunately, many companies don’t have a
remote access server (RAS) in place to make
this possible. Even if your company does have
a RAS, what are the chances that the line will
be busy when you call? The reasons I’ve just
listed have all made doing business on the
road difficult. However, by setting up a virtual
private network (VPN), you can access your
corporate network from anywhere that you
have access to an Internet connection. In this
article, I’ll explain how VPNs work with Win-
dows 98.
What is a VPN?
A traditional network consists of two comput-
ers that must communicate with each other.
The two computers are connected by a physi-
cal medium, such as an Ethernet connection.
A VPN works on the same principle. It con-
The best solutions are always based on
knowledge. If a VPN is for you, look to the
future. Make sure your choice is as scalable as
you think you’ll need. Also, pay particularly
close attention to any other regulations or
requirements that are mandated by much larger
bodies, such as the government. A number of
options are available, some geared toward small
business, some toward much larger. If your
company is in need of a VPN, there’s a solu-
tion that’s right for you—just make sure you’re
very aware of the requirements today and, as
always, think scalable.
sists of two computers that must communicate
and a medium. However, unlike with tradi-
tional networks, this medium isn’t dedicated to
the network in question. Often the medium is
the Internet. Because both computers are con-
nected to the Internet, it’s possible to establish
a route through the Internet between the two
computers. In the case of a VPN, this route is
called a tunnel.
Introducing the Point-to-Point
Tunneling Protocol
As you’re probably aware, a network connec-
tion requires the computers on the network to
share a common protocol. A protocol is the
language computers use to communicate over
the connection medium.
For a standard Internet connection, com-
puters use the TCP/IP protocol over a PPP
(Point-to-Point Protocol) connection. In the
case of a VPN, this concept is taken a step fur-
ther. The Windows 98 implementation of vir-
tual private networking relies on a protocol
Introduction to VPN and Remote Access 5
 called PPTP (Point-to-Point Tunneling Proto-
col). As you might have guessed by the name,
PPTP is simply an extension of the PPP pro-
tocol. PPTP provides a tunnel through the log-
ical connection medium that allows the two
computers to communicate.
Because of the way PPTP works, you can
use it regardless of the communications proto-
col your corporate network normally uses. For
example, suppose your corporate network nor-
mally uses Internetwork Package Exchange/
Sequenced Package Exchange (IPX/SPX).
You can set up IPX/SPX on your remote
computer and communicate with your corpo-
rate network using IPX/SPX packets traveling
across PPTP.
The first step in having a secure
environment is to have
strong passwords.
Virtual private networking
over the Internet
Now that you’re familiar with some of the
basic concepts and terminology associated
with VPNs, let’s look at how virtual private
networking works in a little more detail. For
the remainder of this article, I’ll assume that a
remote user dialing into the Internet is making
the VPN connection.
When establishing a VPN connection over
the Internet, the remote user must make two
connections. The first connection is to the
user’s Internet service provider (ISP) by way of
a dial-up session. As I mentioned earlier, this
dial-up session uses TCP/IP and PPP to com-
municate with the ISP. At the time the connec-
tion is made, the remote user is automatically
assigned an IP address by a Dynamic Host
Configuration Protocol (DHCP) server at the
ISP’s office.
The second connection actually creates the
VPN. It uses some of the Windows 98 code
that’s normally associated with dial-up net-
working to establish this connection over the
existing PPP connection. Packets are sent
across the second connection in the form of
6 Administrator’s Guide to VPN and Remote Access, Second Edition
IP datagrams containing encapsulated PPP
packets.
Under normal circumstances, when a
remote user tries to access a corporate network
via the Internet, the company’s firewall pre-
vents PPP packets from entering the network.
This means the private network is inaccessible
to Internet users. However, when the company
loads the VPN services, it can enable certain
firewall ports that provide a route across the
firewall (or router) and allow Internet users
who meet specific security criteria to access the
private network from across the Internet.
When a VPN server receives a packet from
across the Internet, it disassembles the packet.
From this packet, it can derive the name of the
computer the packet was intended for. The
packet also contains the underlying protocols,
such as NetBEUI and IPX/SPX. Once this
information has been extracted into a usable
form, the packet can be passed from the VPN
server to the destination computer residing on
the private network. As you can see, the VPN
server functions similarly to a gateway.
Because you can imbed standard network-
ing protocols into a packet that’s sent across
a VPN, all standard networking features con-
tinue to work. For example, name resolutions
by way of a Windows Internet Naming Ser-
vice (WINS) server or a Domain Name Ser-
vice (DNS) server will function just as if the
remote host were directly plugged into the
local network.
Because name resolution continues to
function, you may be wondering about the
general DNS requirements. After all, address-
ing a computer by name across the Internet
normally requires the name to be registered
and globally accessible. However, in the case
of virtual private networking, only the VPN
server needs a valid globally accessible DNS
name (with a static IP address). This is
because when you send packets from the
remote computer, the VPN server is as far as
those packets must travel. As far as anything
on the Internet knows, the VPN server is the
packet’s final destination. It’s not until the
VPN server disassembles the packets that
they’re passed on to their true final destina-
tion. Because the packet already resides at the
local level at the time of disassembly, the
Internet requires absolutely no knowledge of
the name of the computer that’s the true
final destination of the packet. As a matter of
fact, it’s a bad idea from a security standpoint
to make the name of that computer accessi-
ble via the Internet. You should place all
local nodes on your network, as well as the
VPN server, behind a firewall for protection.
Virtual private networking
and routing
As I mentioned earlier, connecting to a VPN
involves using two dial-up networking sessions.
The first session establishes your Internet con-
nection. Once you’re connected to the Inter-
net, you can establish the VPN connection via
the second dial-up networking connection.
However, there are a couple of side effects you
should know about.
First, when you launch the VPN session,
the Internet is no longer accessible for stan-
dard access (Web browsing, e-mail, and so
forth) unless the network you’re connecting to
can also get to the Internet. If the remote net-
work doesn’t provide access to the Internet,
you can’t surf the Web or check your e-mail at
the same time you’re connected to a VPN.
Second, you should know that establishing a
VPN session kills your connection to any local
networks you might be attached to. For exam-
ple, suppose you’re part of a ten-user work-
group. Now suppose you establish a VPN
session to a corporate enterprise network.
Once you do, the corporate enterprise network
will be accessible but your workgroup won’t.
Consequently, you won’t be able to use Win-
dows 98 to route packets between the two
networks.
The reason for these routing limitations is
because of the way the PPTP protocol affects
Windows 98’s local routing tables. If you
absolutely have to connect to the Internet, to a
local network, or to both at the same time
you’re connected to a VPN, you may be able to
do so in some cases by using Windows 98’s
Route command. The Route command can be
used to make Windows 98 aware of other IP
networks that you’re connected to without the
aid of a router.
VPN security
Given the insecure nature of the Internet,
security is a big concern with VPNs. After all,
you don’t want someone to steal your packets
as they flow freely across the Internet. And
you don’t want your corporate network to be
compromised. Fortunately, the Windows 98
implementation of virtual private networking
is designed to be secure. In this section, I’ll dis-
cuss some of the aspects of VPN security that
you need to be aware of.
The first step in having a secure environ-
ment is to have strong passwords. When you
dial into your ISP, it typically asks for a pass-
word. However, this password grants you only
an Internet connection—it has absolutely
nothing to do with your VPN access. Instead,
when you establish the VPN session, you’ll be
prompted for a second password. This is your
usual Windows NT (or Windows 2000) domain
password. The password is authenticated using
the same method that a RAS server uses. You
can use Challenge Handshake Authentication
Protocol (CHAP), Microsoft CHAP (MS-
CHAP), or Password Authentication Protocol
(PAP) to authenticate Windows NT passwords.
Once a user has been authenticated into a
Windows NT domain, all the usual security
mechanisms continue to apply. For example, all
NTFS permissions and share permissions
apply to a user who’s connected through a
VPN just as if the user were connected to a
network locally.
An added level security comes from encryp-
tion. Once a user has specified his or her pass-
word, the remote client and the VPN server
generate a 40-bit encryption key that can be
used to encrypt and decrypt packets. If you’re
using Windows NT Server with Service Pack
1, 2, or 3, this encryption key changes with
every 256 packets. If you’re using Service Pack
4 or above, the encryption key changes with
every packet. To further enhance security,
users in the United States and Canada may use
128-bit encryption as opposed to the standard
40-bit encryption.
Firewalls
I mentioned earlier that you should always
place your VPN server behind a firewall. A
Introduction to VPN and Remote Access 7
 firewall is designed to block all IP ports that
are unused. This prevents attacks on your net-
work by malicious Internet users. Another
function of a firewall is to hide the computer
names and IP addresses used on your private
network from Internet users.
If you already have a firewall in place, you’ll
have to enable the ports that are used by vir-
tual private networking before the VPN server
will be accessible from across the Internet.
Remember that virtual private networking
relies on the PPTP Protocol. PPTP uses TCP
port 1723 and ID number 47. Therefore, you
must enable port 1723 and ID 47 (in some
Going beyond the buzz to understand
VPN technology
Oct 5, 2000
By Jason Hiner, MCSE, CCNA
V
PN is one of those acronyms that
describes a revolutionary technology
few people appear to be using. The
confusion and misinformation that swirls
around VPN (virtual private network) may be
the reason for this perception. In this article,
we’ll focus on VPN, including the basics
about how it works and the definitions of
some of the buzzwords that surround this
new technology.
VPN is a new way to connect your users to
your network. The technology has drawn a
good deal of speculation and criticism about its
security and reliability. On the flip side, VPN
has also received its fair share of exaggeration
about its merits, including claims that it is des-
tined to replace all dedicated T1s, frame-relay
circuits, and other proven connections.
How VPN works
So what can VPN really do for you? It can
provide low-cost, reliable, and secure connec-
8 Administrator’s Guide to VPN and Remote Access, Second Edition
cases listed as Protocol 47) before you can use
virtual private networking. If these addresses
aren’t enabled, all VPN traffic will be stopped
at the firewall and will never even reach your
VPN server, not to mention the rest of your
network.
Conclusion
In this article, I’ve discussed VPNs as they
apply to Windows 98. I’ve explained a bit
about the infrastructure behind a VPN, and I
discussed some configuration issues you may
encounter when setting up a VPN through
Windows 98.
tions to your local area network (LAN) for
commuters and remote office users. How does
it work? VPN essentially takes two systems, or
networks, connected to the Internet and cre-
ates a secure connection using encapsulation
and encryption. VPN also uses authentication
and routing to further increase security and
functionality.
When using a client-to-server VPN (see the
sidebar article), a remote client requests a
resource from its corporate LAN. The com-
puter then dials up an ISP to connect to the
Internet and creates a logical connection to the
corporate VPN server. This VPN server
authenticates the client and manages encapsu-
lation and encryption on the communications
between the client and the resources on the
corporate LAN.
Sorting out VPN terminology
A VPN has its own subset of buzzwords, such
as tunnels, PPTP, L2TP, GRE, CHAP, IPSec,
THE BASICS OF VPN
Figure A depicts a client-to-server VPN where a remote user connects to a corporate VPN server using Point-to-Point
Tunneling Protocol (PPTP). The use of PPTP allows enterprises to extend their own corporate network through pri-
vate “tunnels” over the public Internet. Using this type of interconnection, a company no longer needs to lease its
own lines for wide-area communication. Instead, enterprises can securely use the public networks because the
communication packets are encrypted before they are sent through the tunnel.
Figure B depicts a basic server-to-server VPN. Both of these diagrams show very simplified solutions. In reality,
VPN servers often sit behind a firewall and are part of the corporate network’s “Demilitarized Zone.” Setting up a
VPN usually involves some trial and error on the part of both the clients and the server. Once VPN is up and run-
ning, however, it is typically reliable if you have a dependable Internet connection on both ends.
For more on VPN with Windows products, you can go to Microsoft’s site on virtual private networking
(www.microsoft.com/ISN/ind_solutions/virtual_private_networking.asp) or read Nortel’s VPN Tutorial at
www.iec.org/tutorials/vpn.

and other concepts. How do they fit into the PPP, such as CHAP, PAP, and SPAP. For
VPN picture? Let’s start with the most confus- encryption purposes, however, it is best to use
ing concept—tunneling. MS-CHAP, which in turn allows for link
A VPN tunnel is a logical concept for illus- encryption via MPPE.
trating the transfer of private data packets on Around the same time that Microsoft cre-
the Internet, which is mostly full of packets ated PPTP, Cisco created its own L2F protocol
anyone can open and read quite easily. A tun- for VPN. Microsoft and Cisco collaborated to
nel is not a private, dedicated path of electrons produce a single VPN tunneling protocol, and
directly crossing the Internet from one spot to the result was L2TP. Like PPTP, L2TP pro-
another. Hackers can still intercept the packets vides user authentication and data encryption.
in your tunnel. But, without your encryption It also provides mutual computer authentica-
key, the packets are simply a jumbled mess of tion, data authentication, and data integrity.
characters. The tunnel is simply the route While PPTP provides link encryption via
taken by encapsulated packets between the two MPPE, L2TP provides more secure end-to-
networks. Remember that tunneling encapsula- end encryption with IPSec. By using IPSec
tion occurs at the Data Link Layer (Layer 2) of
the OSI reference model. Figure A
In a Windows environment, VPN tunneling
is made possible by one of two protocols— VPN tunnel (logical connection)
PPTP or L2TP. In a UNIX or Linux environ-
ment SSH can be used for VPN. Cisco has a Remote
client Internet VPN Corporate
VPN protocol called L2F, and there are others. LAN
server
But we will focus on PPTP and L2TP for Win-
dows networks, with an emphasis on Windows
2000, the most comprehensive Windows plat- Figure B
form for VPN.
PPTP provides user authentication and data
encryption following a protocol that has been VPN tunnel (logical connection)
used in Windows NT networks for several
years. It accesses TCP port 1723 for communi- VPN Internet VPN
server server
cation and encapsulates PPP frames for tun-
neling using GRE. For authentication, PPTP Remote Corporate
office LAN
can use the same authentication protocols as

Introduction to VPN and Remote Access 9

 both the computer and the user are authenti-
cated. Although L2TP is still a virgin technol-
ogy and Microsoft just began supporting it
with the release of Windows 2000, it is clear
that the future of VPN is moving in this direc-
tion. For more detailed information on this
new standard see Request For Comment 2661
at http://www.ietf.org/rfc/rfc2661.txt.
Whether you use PPTP or L2TP, there are a
few more core concepts you should under-
stand about setting up a VPN. You can set up
a VPN using two general configurations:
client-to-server and server-to-server. A server-
to-server VPN allows remote office networks
to connect to corporate LAN resources. VPN
servers on both ends of the Internet connec-
tion authenticate each other, create the tunnel
between the two networks, and allow a secure
exchange between the networks. However,
keep in mind that the encapsulation and
encryption process can add around 30 percent
in protocol overhead. This means that slow
dial-up connections will be even a little slower.
Nevertheless, they will still function reliably for
file transfer and other basic remote access
functions.
KEY TO ACRONYMS
PPTP—Point-to-Point Tunneling Protocol
L2TP—Layer-2 Tunneling Protocol
TCP—Transfer Control Protocol
GRE—Generic Routing Encapsulation
SSH—Secure Shell
L2F—Layer-2 Forwarding
CHAP—Challenge Handshake
Authentication Protocol
PAP—Password Authentication Protocol
SPAP—Shiva Password Authentication
Protocol
10 Administrator’s Guide to VPN and Remote Access, Second Edition
Summing it all up
VPN can offer some great advantages over
traditional remote access and dedicated lines.
With the dynamic nature of organizations
these days, remote access users and offices can
change very rapidly. Rather than investing in
expensive RAS ports and expensive dedicated
lines (i.e., ISDN and frame-relay circuits), a
company can increase the bandwidth of its
corporate Internet connection and dynami-
cally support remote VPN servers and clients
on an as-needed basis. While this may not be
the ideal solution in every case, it does allow
companies to be faster and more fluid in set-
ting up remote access when a new need arises.
It also allows for a better use of resources
since different users and connections can con-
nect at different times and thus share the same
infrastructure rather than requiring separate
infrastructures. And, for those who are count-
ing, all of this can result in saving some seri-
ous money.
MPPE—Microsoft Point-to-Point Encryption
IPSec—Internet Protocol Security
VPN—virtual private network
DSL—digital subscriber line
XML—Extensible Markup Language
ASP—application service provider
RAS—remote access services
ISDN—Integrated Service Digital Network
Virtual private networks save money,
increase productivity
Aug 21, 2000
By L. Pepper Morton
M
y firm had a client that had been
paying about $20,000 a month in
long distance data line costs and felt
that a strategy change could reduce this price
tag considerably as well as upgrade the data
throughput capability.
The client’s strategy in the past was to give
remote branch offices access to a mainframe
system that would give users online access and
transaction process capability. The user would
have an ADDS dumb terminal located at each
branch. Thus, the client installed remote and
local modems and a T1 fractionated into 64k
segments for each branch.
We felt like a change in strategy for the
company would address a need to upgrade the
remote office dumb terminals with Pentium
personal computers and take advantage of the
Internet with the use of a virtual private net-
work (VPN). What follows is a case study in
favor of VPN technology.
Choosing VPN over frame relay
The new strategy for this client was to
upgrade the remote access user to today’s
desktop solutions and interface this desktop
via the Internet to the home office mainframe
via one of two means:
X Frame relay
X Virtual private network
The frame relay was ideal; however, the
one-time cost for the remote and local hard-
ware was prohibitive. The company did not
think they could justify the one-time cost,
especially if there was a lower cost alternative.
Thus, the VPN alternative was adopted.
The strategy consisted of bundling as much
technology into the upgrade so that the com-
pany would be able to maximize the financial
leverage of the VPN strategy over three to
five years.
The cost of the installation and PC pur-
chases would be recouped through the long
distance savings on the data lines. By utilizing
the Internet, the company could reduce its
long distance data cost to $20 or $30 per port
each month. With approximately 120 ports,
this comes to around $3,600 a month versus
the $20,000 the client had been paying. This
may sound like a no-brainer, but there were
other issues to be addressed.
Applying the VPN concept
Microsoft changed the way it handles VPNs
with the advent of NT 4.0 when it added rout-
ing and remote access service (RRAS). This
change was designed to enhance the VPN
connectivity and reliability, but the jury is still
out on the success of the change. In our
effort to install the VPN, we worked closely
with Microsoft’s technical support staff. We
received good response, but the content seems
to be a little short.
We also did quite a bit of research and dis-
covery. We found that client dial-up connec-
tions worked with little or no problem.
However, network connections do not work
nearly as well. There are ample products on the
market that make VPN connections a breeze,
but they are somewhat costly, especially since
the technology is supposed to be resident in
RRAS. Since one of our main strategy objec-
tives was to maximize our cost, we continued
down the RRAS path.
Eventually, we found that the dial-up con-
nection into an ISDN pipe via the Internet
was fine for clients but not for remote net-
work connections. The encryption code and
RRAS code take up most of the data line on a
64k ISDN connection, and thus allow no
room for data transmission.
Microsoft recommended that a dual-channel
ISDN line would make a better connection;
however, we went ahead and stepped up to a
burstable T1. This would provide a little grow-
ing room for the client and remote network
connections. RRAS comes with routing built in
the software and therefore eliminates the need
for a router. An interface card must be installed
Introduction to VPN and Remote Access 11
 in the NT server that connects to the ISP
incoming T1.
The burstable T1 ended up costing a little
more than originally anticipated, but it was
still somewhat less than the original cost of
$20,000 per month.
VPN implementation brings cost
savings, increased productivity
We implemented these technologies for
the client:
X T1 interface
X T1 burstable connection to local provider
X 36 remote network connections
X 80 dial-up client connections
As a result, the client now can accomplish:
X Transaction processing
X Desktop word processing and spreadsheets
X Network e-mail
The savings that result from this implemen-
tation are considerable:
X Total cost monthly, fixed: $3,700
X Total cost monthly, variable: approximately
$3,000
So, for a total cost of $6,700 per month, the
client has enhanced remote users’ ability to use
the system and cut the monthly cost to operate
by $13,300.
The remote desktop users responded by
increasing their individual productivity, and
branch managers reported a noted positive
attitude change.
The large margin of cost savings will allow
the client to pay for the desktop Pentium com-
puters and other miscellaneous equipment in
about six months. After six months, the sav-
ings can be added back to the bottom line.
VPNs are getting easier to install and debug.
We are amazed at the number of clients who
are afraid of VPN technology and therefore
have not adopted this off-the-shelf technol-
ogy. This client had a large margin to work
with, and the VPN was a winning choice.

WHAT’S A VPN?
A virtual private network (VPN) is a private data network that makes use of the public
telecommunication infrastructure, maintaining privacy through the use of a tunneling proto-
col and security procedures. A VPN can be contrasted with a system of owned or leased
lines that can be used by only one company. The idea of the VPN is to give the company the
same capabilities at much lower cost by using the shared public infrastructure rather than a
private one. Phone companies have provided secure shared resources for voice messages.
A VPN makes it possible to have the same secure sharing of public resources for data.
Companies today are looking at using a private virtual network for both extranet and wide-
area intranet.

HOW DO VPNS WORK?

Using a VPN involves encrypting data before sending it through the public network and
decrypting it at the receiving end. An additional level of security involves encrypting not only
the data but also the originating and receiving network addresses. Microsoft, 3Com, and
several other companies have developed the Point-to-Point Tunneling Protocol, and
Microsoft has extended Windows NT to support it. VPN software is typically installed as part
of a company’s firewall server.

Courtesy of whatis.com

12 Administrator’s Guide to VPN and Remote Access, Second Edition

How can using a VPN benefit your company?
Nov 17, 2000
By Ed Engelking II, A+

V
irtual private networks, or VPNs, have able tool for many organizations. Users simply
become a major networking technol- dial in to a local Internet service provider (ISP)
ogy within just the past few years. and then establish a secure tunnel (with the
Does VPN technology live up to its own hype? VPN) to the office network. Users are then
How can a VPN improve your company? This able to authenticate into their company’s net-
article takes a look at what a VPN is, how it work and browse as if they were in the office.
works, and how it can benefit your company. Imagine finding the perfect hire for a posi-
tion, but that individual can’t relocate. VPN
What exactly is a VPN? enables this employee to have access to the
A VPN is essentially a private data network company network and the vital resources he
that uses existing telecommunications infra- or she needs from a remote location.
structures (regular phone lines, T1 lines, DSL,
cable lines, and so on). Privacy is achieved VPN for road warriors
through the use of a tunneling protocol and One of the greatest benefits a VPN offers is to
security procedures. VPN technology enables individuals who travel extensively. These indi-
company offices or individuals in different viduals need frequent access to the company
locations to securely access a central network network for file sharing, checking e-mail, or
without having to dial directly in to the com- other tasks that depend on connectivity. With
pany network, as shown in Figure A.
Figure A
VPN vs. traditional dial-in access
Connecting remote users via the traditional Connecting to office network dial-in access
dial-in method can be costly. In order for
employees to dial in to the network, the com-
pany needs a leased telephone line for multiple
users to dial in on, as well as call-trafficking
equipment (e.g., modems) to handle the
incoming calls. A company must also consider remote PC
dial-in server
the cost of these toll calls and the time their
users stay connected. While the implementa-
tion of toll-free 800 numbers can alleviate
direct dial-in line corporate network
some of this cost, there is still a significant fee
for having an 800 number. Connecting to office network with VPN
By using a VPN, however, remote users can
connect to an ISP with a local phone number Internet
and from there, tunnel securely to the office
network. With this configuration, the only
ISP server
equipment needed is a VPN server, eliminating
the need for leased lines and call-trafficking
equipment. Toll calls and 800 numbers are also
no longer an issue, as most national or global
ISPs usually have local numbers for almost remote PC VPN server
anywhere in the world.

VPN for telecommuters corporate network

With more people working from home, This diagram illustrates the difference between a dial-in connection and a connection
remote-access VPNs have become an invalu- with a VPN.

Introduction to VPN and Remote Access 13

 a laptop, VPN, and global ISP, these road war-
riors can connect to the company network
from anywhere there’s a phone line.
VPN offices around the country
What if your company’s main office is located
in Miami, while your branch offices are located
in Los Angeles, New York, and Chicago?
While each branch has its own separate net-
work, there aren’t many realistic ways to
Understand your organization’s needs before
selecting VPN hardware
Nov 22, 2000
By Ed Engelking II, A+
I
n “How can using a VPN benefit your
company?” (page 13), I discussed the
basics of virtual private networks (VPNs)
and how they could be used in traditional com-
pany networks. I also discussed the differences
between general and remote access virtual pri-
vate networks. In this article, I’ll focus on
some questions to ask before choosing a VPN
hardware solution.
Questions to ask before investing
in VPN hardware
As with any network solution, VPN hardware
should be chosen based on the needs of your
organization. Ask yourself the following ques-
tions before buying any piece of hardware:
X How many remote access users will
be connecting?
Do you have the infrastructure to support
multiple remote access accounts? If your
organization has a lot of users who travel
and/or work from home, the hardware that
you purchase needs to be able to connect
multiple remote users at one time.
14 Administrator’s Guide to VPN and Remote Access, Second Edition
directly connect each office unless fiber were
run between the locations, and this would be
very expensive.
With a VPN, however, each network can
connect to the main office’s network and
then to the other branch offices. All that’s
needed is an Internet connection, a VPN
server for each location, and an IP address
to authenticate to.
X How many users will be connecting
at the same time?
Will 10 or 100 users be connecting simulta-
neously? Knowing your user base is essen-
tial for selecting the appropriate hardware.
You wouldn’t want to purchase VPN hard-
ware that supports a maximum of only 20
simultaneous users when you need one that
supports 50.
X Will remote offices connect to your
hardware?
Connecting entire remote offices and con-
necting individual remote users are two
entirely different challenges. Maintaining
access for remote offices can be the differ-
ence between life and death for your com-
pany. How can your employees at your
organization’s remote offices work properly
if they can’t access the home network?
X What kind of uptime does your
organization desire?
Not all VPN hardware is created equal.
While some hardware may be cheaper than
others, it may pay for your organization to
 invest in the more costly hardware, as the
uptime may be generally better. Keep in
mind, however, that the operating system
shares a large role in uptime as well. Without
a stable OS, you won’t be able to maintain
much of an uptime.
X What kind of budget does your organi-
zation have to purchase hardware?
Ideally, all equipment in every organization’s
network would be top of the line. However,
due to budgeting restrictions, your choices
can often be limited. Despite this, it is
important that you purchase the equipment
that meets your budget. Don’t cut corners
to add other services. Know what you need
to offer your organization’s employees and
make sure that it is available.
Many vendors offer VPN
solutions
Now that you know what to consider when
purchasing VPN hardware, what equipment is
available on the market that meets your needs?
There are several different vendors that offer
VPN solutions. A select few of these vendors
are listed below:
Cost benefit of VPN appliances vs.
VPN servers
May 21, 2002
By Del Smith, CCNA, CCA, MCSE
A
n increasing number of organizations
are using VPNs to connect branch
offices, telecommuting workers, busi-
ness partners, and other users to the corporate
network. A superior alternative to long-distance
dial-in, leased-line, or Frame Relay connections,
X 3Com VPN Solutions
3Com offers software solutions for your
organization’s existing server hardware. You
can also find products for mobile users, site-
to-site, and secure extranet VPN systems.
X Cisco VPN
If you want top-of-the-line VPN hardware
and software solutions, Cisco is your vendor
of choice. However, Cisco’s products can
be a bit pricey if you have a limited budget.
X IBM OS/400 VPN solution for the
AS/400 server
IBM offers a VPN solution in its OS/400
operating system, designed specifically for
its AS/400 server.
The vendors listed here are by far the most
popular and will give you the best value for
your investment. However, if you want addi-
tional solution options, you can find a list of
links to several other vendors at InternetWeek
(http://www.internetwk.com/VPN/links.
htm). With a clear understanding of what your
organization needs in a VPN solution, you
should be able to find what you need from at
least one of these vendors.
VPNs can be used to securely carry informa-
tion at a fraction of the cost.
These cost savings are the catalyst driving
IT managers and administrators to develop
end-to-end secure VPN solutions for their
organizations. Specifically, these professionals
Introduction to VPN and Remote Access 15
 are asking the question, “VPN appliance or
VPN server, which solution provides the
greatest cost benefit?” Here is a look at those
options and a third: managed service
providers.
Integrated appliance
When we take a look at the VPN appliances
offered today, we notice two different flavors:
stand-alone VPN appliances and integrated
VPN appliances such as VPN-enabled fire-
walls and routers. With the integrated VPN
appliance, we find our first and possibly most
important cost benefit. Currently, deployed
hardware firewalls such as the Cisco PIX,
Nokia Checkpoint Firewall, and Watchguard
Firebox include optional VPN capabilities out
of the box.
Virtually all routers, including Cisco’s access
and modular routers, also include VPN sup-
port. The cost associated with this solution is
often included in the firewall or router. Getting
VPN services going in this scenario often
means making just a few configuration
changes in the firewall or router itself. Since a
discussion on VPNs falls within a comprehen-
sive network security policy, the ability to have
an integrated VPN appliance can save thou-
sands in simplified security policy administra-
tion, particularly in environments where
multiple firewalls, routers, and VPN gateways
are required.
Stand-alone VPN appliances, sometimes
referred to as VPN concentrators, primarily
find a place in organizations where simultane-
ous VPN connections need to number in the
thousands. They provide high availability, high
performance, and scalability that is unmatched
by any integrated appliance or VPN server. The
increase in reliability, capacity, and throughput
is not without its costs, however. Expect to pay
several times more for an enterprise-level VPN
concentrator with these capabilities.
VPN servers
So far, we have heard how integrated VPN
appliances offer impressive cost benefits. From
this, it would seem the question of whether to
choose a VPN appliance or build a VPN
server would be a rather simple one to answer.
To determine if this scenario is true, let’s take a
16 Administrator’s Guide to VPN and Remote Access, Second Edition
closer look at the option of building and
using a VPN server(s) for secure Internet
communications.
Microsoft, Novell, UNIX, AS400, and
Linux are all capable of providing VPN serv-
ices (granted, some are better than others).
Chances are you run one of these common
operating systems in your organization today
and are very familiar with them. This can be a
tremendous cost benefit to organizations that
do not have an existing firewall or router with
VPN capabilities.
The integration of VPN services into the
operating system means that IT professionals
who work with these operating systems are
already familiar with how to navigate these sys-
tems and do not have to worry about learning
a new product. Since most VPN appliances do
not integrate well with existing networks, using
servers for VPN services often means greater
integration with the network, particularly in
the area of authentication. Microsoft-centric
organizations can take advantage of the seam-
less integration Windows 2000, and possibly
ISA Server, has to offer when creating VPNs
in conjunction with Active Directory, certifi-
cates, and smart cards. Client computers or
sites that run current Microsoft operating sys-
tems will not encounter proprietary VPN
issues or require an install of separate VPN
client software.
Here’s where the cost benefits of using a
VPN server stop. The issues of security, relia-
bility, and cost stand out when evaluating a
server-based VPN solution. There should be
no surprise that a hardware-based VPN solu-
tion brings a greater degree of reliability and
security than one built around a server operat-
ing system such as Microsoft. The same is true
in the case of firewalls and routers. The cost
associated with maintaining security patches
and basic server administration add up on a
monthly basis. Additionally, the cost of build-
ing a VPN server solution can run in excess of
$2,500 once the costs of hardware and soft-
ware are added (although Linux does offer
some exceptions).
The managed option
Traditionally, VPN solutions could be catego-
rized in one of only two areas: VPN appliances
or VPN servers. Today, the introduction of
managed service providers has created a third
possible solution. Well-known vendors such as
WorldCom, Quest, and AT&T are now offer-
ing regional, nationwide, and even interna-
tional managed VPN services. This service
allows companies to have an enterprisewide
VPN solution without a heavy investment in
infrastructure or personnel. Most managed
VPN providers will monitor your organiza-
tion’s VPN connections 24/7 to ensure they
are available at the times when your remote
users may need it most. Pricing varies but gen-
erally starts around $200 per month, per loca-
Telecommuting: Balancing the need
for speed and security
Nov 17, 2000
By Mike Walton
J ay Pultz sits at the center of a home office
that hums with computers, printers, and a
cable modem gateway.
Pultz works for Gartner, a business tech-
nology advisor based in Stamford, CT.
Because of his background working with
high-speed access issues, Pultz can assure
Gartner that his powerful home office isn’t
a security threat to the corporation. But
organizations can’t always rely on a telecom-
muter’s expertise to protect the business.
Telecommuting carries with it a number
of security, connectivity, and productivity
issues.
Here’s how Pultz recommends addressing
those issues. He urges organizations to con-
sider three key issues when dealing with broad-
band telecommuters:
X The need to limit the number of ISPs that
provide your employees broadband access.
tion and often includes managed firewall serv-
ices and service level agreements as well.
VPNs are permitting organizations to estab-
lish secure, end-to-end, private network con-
nections over the Internet while reducing
communication costs. Implementing and
maintaining VPNs requires choosing the right
solution and having an in-depth understanding
of public network security issues. Whether you
are looking at a VPN appliance, server, or
managed service provider, performing proper
cost/benefit analyses can be the most impor-
tant step in a successful VPN solution.
X The unique set of security concerns that
come with broadband access.
X The number of control issues your IT
department can expect to face and how to
limit those issues.
Broadband access: Got to love it
Pultz said he stretches the definition of broad-
band when he talks about it in relation to
telecommuting. In his view, broadband is any
access that involves a connection faster than
what a user can achieve via a normal telephone
connection and a dial-up modem. The tech-
nologies that fall under his definition are DSL,
cable, wireless, and satellite. He limits the dis-
cussion to DSL and cable because they are
most commonly used.
“I view broadband as an enabler of
telecommuting,” Pultz said. Without a broad-
band connection, telecommuters face substan-
tial productivity challenges. “It’s harder if you
Introduction to VPN and Remote Access 17
 have to get access to a number of corporate
resources and the Web to do your work with a
56Kbps modem compared to someone work-
ing on the LAN with the same resources.”
“Broadband access shrinks the disparity
between telecommuters and workers on the
company’s LAN,” he said.
“The problem is, when you look at both
DSL and cable, they are both kind of local-
oriented technologies that weren’t originally
designed with telecommuting in mind,” Pultz
said. “If an enterprise is reasonably large, pro-
viding teleworkers throughout the United
States with broadband access is an issue.”
While cable access might be available for
some telecommuters in a company, others in
different parts of the country may have DSL.
Each may have a different provider.
“You can easily end up with a situation
where you have multiple technologies and mul-
tiple service providers, and that’s a hard envi-
ronment for the IT department in the average
company to run,” Pultz said. “If you are a
smaller company and your users are all within a
local area or within the footprint of a single
provider, then it is less of an issue.”
“Another problem is that your telecom-
muters throughout the United States may not
be able to get broadband of any kind because
neither cable nor DSL have been fully rolled
out,” he said.
On the plus side, however, a number of
companies are starting to provide nationwide
service, including:
X Northpoint
X WorldCom
X Verizon
Finding a single provider for an entire com-
pany will still be difficult, Pultz said, but there
are good reasons to try.
“For purchase power reasons, a limited
number of suppliers [is beneficial] so compa-
nies can maximize the volume discount they
can get for these kinds of services,” he said.
Always on, always a danger
The second broadband telecommuting issue is
the security concerns created because cable
and DSL are essentially always online.
18 Administrator’s Guide to VPN and Remote Access, Second Edition
When telecommuters are using dial-up serv-
ices to access the corporate VPN, they may be
online for only a few hours. It is difficult,
under those ephemeral circumstances, for a
hacker to target the user.
Continuous connections made by cable and
DSL hookups make it easier for hackers to
attack the system.
“If you are a corporate teleworker, it is
likely that you will have some interesting infor-
mation or software on your PC,” Pultz said.
“You probably have a file labeled, covertly,
‘passwords,’ which might be of interest if you
are of the hacker persuasion.”
“Or you may have software on your machine
that is server-like so a hacker can get access to
your machine as a corporate server and from that
machine, they can get to corporate resources.
The corporate network assumes this is a trusted
machine, but it has actually been infiltrated by a
hacker…[who] can use that machine as a back-
door to get into the corporate network.”
“Companies such as Norton and BlackICE
offer software firewalls that can protect your
telecommuter machines,” Pultz said. “They are
both very nice, but they have to be configured,
they have to be in place, and the user has to
not subvert them,” he said. “Unfortunately, it
is easy for the user to look at the firewall tech-
nology and say, ‘I want to do something the
firewall is blocking now,’ and just turn off the
firewall.”
Security for the telecommuter is compli-
cated by how you separate the home office
environment from whatever else is going on in
the home.
“This gets into age-old questions like, ‘Can
you use your home PC for teleworking?’ and
that’s something we advise against,” Pultz said.
“You don’t know if that is a trusted machine.
You don’t know where that machine has been.”
“You can get into really messy issues [with]
confidential information. It may not be Los
Alamos information, but it’s not stuff you
want on a home machine.”
Limit the impact on your
help desk
One of the most important decisions compa-
nies can make involves the way telecommuters
interact with IT staff for support.
 A typical telecommuting scheme is for the
company to provide a VPN for telecommuters
and then have the worker provide their own
modem and cable or DSL service.
This is how most organizations set up their
systems, “but the problem is that when those
teleworkers have a problem, they call the IT
help desk,” Pultz said, adding that the help
desk is handcuffed because they don’t know
how the home PC is configured, how the user
is accessing the VPN, or what type of cable
modem they are using. “It’s very difficult to
guarantee a teleworker any level of service.”
There are some workarounds to these con-
cerns, such as providing a company computer
that has the corporate hard disk image and set-
tings installed.
Decide what type of access
is appropriate
IT managers need to make other decisions
that will affect support and performance, such
as which kind of network access is most
appropriate for the kind of work the telecom-
muter does.
Access your home PC from the office
Sep 28, 2000
By Brien M. Posey, MCSE
H
ow many times have you been at the
office and wished that you could get a
file from your home PC? Unfortu-
nately, driving home usually isn’t an option for
network administrators. Unless you live only a
few minutes from the office, the commute
time just cuts too deeply into your hectic
workday. Fortunately, there’s a solution. In this
article, I’ll show you some techniques that you
can use to remotely access your home PC from
the office.
The options
In the past, setting up remote access to a home
PC has been too expensive for most adminis-
A worker who needs the Internet for com-
munication and research is already defined, as
far as what form of access that worker
requires. In this case, a VPN via the Internet
makes the most sense.
If the teleworker is handling transaction
processing or production work, however, then
a faster and more secure connection such as an
ISDN or T1 connection may be needed. The
costs would have to be weighed against the
productivity of the worker.
“Worker performance also is a gateway to
some potential legal issues with telecommut-
ing,” Pultz said. One argument you might hear
could be: “I got a bad performance [review],
but I didn’t have a good connection so my per-
formance suffered because you couldn’t pro-
vide me a good service compared to my
counterpart, who has high-speed service,”
Pultz said.
“I’d still call this kind of an experimental
phase for broadband telecommuting, with the
exception of a couple of very large corpora-
tions,” Pultz said.
trators. After all, the primary remote access
method that most administrators have been
trained for involves using a Windows NT
Server running the Remote Access Service. A
copy of Windows NT Server can be on the
pricey side. Fortunately, there are alternatives.
One alternative is to set up a copy of a
remote access software package, such as
Symantec’s pcAnywhere, at home so that you
can dial in to your PC and control it from the
office. Doing so may be the easiest method
of remote access, but simply running
pcAnywhere has its downside. First, you have
to buy a copy of pcAnywhere, which can still
Introduction to VPN and Remote Access 19
 be a bit pricey, although not nearly as expen-
sive as a copy of Windows NT Server. But the
biggest negative in using pcAnywhere for
remote access is the performance issue—
pcAnywhere is true remote access software.
This means that from your terminal at the
office, you’ll actually see the screen of your
computer at home. In addition to downloading
files, you can actually run programs on your
home PC. Unfortunately, such power comes at
a price. Because you’re seeing the actual screen
image from your home PC, all of the informa-
tion about what’s on the screen has to be
transmitted over the modem. Even with a 56-
Kbps modem, this results in a very slow com-
puting experience. What makes it worse is that
the higher the screen resolution you’re using
on your home PC, the more pixel information
must be transmitted across the modem. In
essence, the higher the screen resolution at
home, the worse the remote access perform-
ance will be.
There is a happy medium, though. A little-
known component in Windows 98 lets you set
up a Windows 98 machine as a remote access
server. This arrangement works very similarly
to the Remote Access Service that comes with
Windows NT Server. What makes this service
so nice is that although you can’t use it to con-
trol your home PC remotely, you can treat
your home PC as if it were a network server.
For example, you can do things like map net-
work drives and upload and download files.
The other nice thing about using this service
is that it’s included with Windows 98, so
there’s no extra software to buy. All you need
is a computer with a modem and a dedicated
phone line.
The skinny on Windows 98
as a dial-up server
Although Windows 98 running as a dial-up
server functions similarly to a Windows NT
Server running Remote Access Service, there
are some important differences. After all, Win-
dows NT Server was designed to support
entire businesses, while Windows 98 was
designed for basic home use. As you can imag-
ine, Windows 98 has much less power than
Windows NT Server. Likewise, Microsoft
20 Administrator’s Guide to VPN and Remote Access, Second Edition
would lose a lot of money if you could do the
exact same thing with Windows 98 that you
could do with Windows NT Server.
Perhaps the biggest difference between the
two is that the Windows NT Server Remote
Access Service can be used as a gateway to the
underlying network. For example, users can
dial in to the remote access server and use the
connection as a gateway from which to con-
nect to any other server on the network. Win-
dows 98 offers this capability, but with
significant restrictions. Unlike Windows NT,
the Windows 98 dial-up services can be used
as a gateway only to networks running Net-
BEUI or IPX/SPX. Because TCP/IP isn’t
supported as a gateway protocol, don’t plan on
being able to connect to the Internet by dialing
into your home PC. You can connect to other
PCs on a home network as long as the PC at
your office, the dial-up server at home, and the
other PCs on the home network that you want
to access are all running the same protocol.
The protocol in use must be either NetBEUI
or IPX/SPX.
In addition to the fact that you can’t use
Windows 98 as an IP router, you also can’t
use it as a virtual private network (VPN)
router. Another important difference is the
number of allowed connections. The Win-
dows NT Remote Access Service allows up
to 256 remote dial-in connections, while Win-
dows 98 has been limited to a single remote
access connection.
Installing a Windows 98
dial-up server
To set up your Windows 98 workstation as
a dial-up server, open Control Panel and
double-click the Add/Remove Programs
icon. When you see the Add/Remove Pro-
grams Properties sheet, select the Windows
Setup tab. The Windows Setup tab contains a
list of available Windows 98 components.
Select the Communications option from the
list and click the Details button. In the result-
ing dialog box, select the Dial Up Server
check box and click OK twice. Windows 98
will now copy the necessary files from your
Windows 98 CD.
Dial-up server security
As you can see, there’s nothing to installing the
dial-up server module. But, as you can imagine,
after you’ve installed the dial-up server, secu-
rity becomes a concern. After all, without
some security in place, any idiot who owns a
computer and who knows your phone number
could have unlimited access to your home
computer or to your home network.
There are two basic types of security under
Windows 98: user-level security and share-level
security. Of these two types, user-level security
is much more secure. Unfortunately, the reason
that it is more secure is that it borrows some of
its security infrastructure from a Windows NT
Server. Therefore, unless you happen to have a
Windows NT Server in your basement, user-
level security really isn’t an option.
Share-level security allows you to specify
general, rather than user-specific, access to
each share point on the machine, such as a
folder and its subfolders. Most home com-
puter environments are better suited to using
share-level security. When you dial in to your
server, Windows 98 prompts you for a pass-
word. After you enter the password, you’re
connected to the dial-up server. From there,
you can use Windows Explorer or My Com-
puter to explore the allowed shares on the
remote server.
Setting up share-level security
To set the remote access password, make sure
that File And Print Sharing is installed in
Control Panel’s Network section. Once you’ve
installed File And Print Sharing, go to the
Dial-Up Networking folder and select the
Dial-Up Server command from the Connec-
tions menu. When you see the Dial-Up Server
dialog box, select Allow Caller Access and
then use the Change Password option to set
the password that the remote access server
requires the client to enter upon the initial
connection. If you want to require the pass-
word to be encrypted, click the Server Type
button. The Server Type dialog box contains a
check box that you can use to make the dial-
up server require an encrypted password from
the client.
As you browse the remote computer, the
directory structure will display only shared
directories and the subdirectories beneath
them. For example, if you shared the Windows
directory, a user with the appropriate access
could remotely access all the files in the Win-
dows directory and all the subdirectories
beneath it, such as the System directory or the
Fonts directory. About a year ago, I had to
temporarily set up a dial-up server. During this
time, I simply shared the root directory on
each drive. This allowed me to have unlimited
access to every file on the system by going into
a share associated with the root directory of
the hard disk that contained the files that I
needed to access.
The biggest thing that you need to remem-
ber about share-level security is that as you
create each share, by default, the share is read-
only. You can change the share to allow full
access by checking the appropriate radio but-
ton, as shown in Figure A.
As you can see in the figure, you can also set
a password to the share point. By doing so, any
time dial-up clients try to access the share
point, they will be prompted for a password.
Figure A
Use the Sharing page to set up read-only access, full access,
or either, depending on the password.
Introduction to VPN and Remote Access 21
 You can even set one password for read-only
access and another password for full control.
The level of access that a remote user gets will
depend on the password entered.
Watch for overlapping security
When you create share points, you must also
remember that the security that you apply is
specific to each one. Each share point func-
tions as a separate entity. For example, if you
set the Windows directory to allow full control
and the \Windows\System directory to allow
read-only access, when you browse the remote
system, you’d see both share points. If you
attempted to directly access the share associ-
ated with \Windows\System, you’d just have
read-only access, as you’d expect. If on the
Notes
22 Administrator’s Guide to VPN and Remote Access, Second Edition
other hand, you went into the share associated
with the Windows directory, you’d be able to
navigate to the \Windows\System directory
and gain full access to that directory. There-
fore, you must be very careful not to overlap
shares if you’re trying to restrict a remote user
to read-only access.
Conclusion
When you need to access a file on your home
PC during the course of the workday, having a
remote access link can save a lot of time and
trouble. In this article, I’ve discussed two ways
to establish remote access for the home PC
running Windows 98.
Administration
In this chapter you’ll find the expert guidance you need to install, configure, and administer VPN
solutions within Windows, NetWare, and Linux networks.

Managing remote access to your network ..............................................................................................23

Understanding and troubleshooting virtual private networking ........................................................26
Controlling the dial-up bandwidth on your VPN ................................................................................34

Administration
Making the connection with Windows 2000 Professional Dial-Up Networking ............................35
Understanding demand dial connections in Windows 2000 ..............................................................43
Configuring Windows 2000 for demand dial connections ..................................................................46
How to configure Win2K client VPN connections ............................................................................50
Setting up a VPN with Windows 2000 ..................................................................................................53
Issues surrounding a Windows 2000 VPN implementation ..............................................................58
Setting up a Windows 2000 virtual private network ............................................................................60
Introducing Windows 2000 Routing and Remote Access ..................................................................63
Configuring Routing and Remote Access on your Windows 2000 server........................................68
Configuring Windows 2000 as a remote access server ........................................................................75
Increasing Windows 2000 RRAS security ..............................................................................................78
Routing and remote access on Windows 2000 Advanced Server ......................................................82
Optimize inbound client connections for your Windows 2000 VPN servers ................................85
VPN networking services built for speed ..............................................................................................91
Optimal VPN server configuration and management ........................................................................95
Troubleshoot Windows RAS and VPN connections with these tips ................................................99
Learn why NAT can cause VPN connection problems ....................................................................102
Create a gateway-to-gateway VPN with ISA Server 2000 ................................................................104
Troubleshoot ISA Server VPN connections ......................................................................................108
Configure Windows XP Professional to be a VPN server ..............................................................113
How to configure Windows XP client VPN connections ................................................................118
Configure Windows NT to support VPN connections ....................................................................119
Monitoring and troubleshooting VPN connections in WinNT ......................................................124
The Win9x VPN client connection guide ............................................................................................127
Understanding Exchange 2000 Server’s Outlook Web Access ........................................................132
Enabling Web access of Exchange accounts using Outlook Web Access ....................................137
Enhance Exchange 2000 OWA using front-end servers ..................................................................141
Implementing site-to-site VPN with BorderManager 3.x..................................................................143
Setting up client-to-site VPN in BorderManager 3.x ........................................................................148
Serving up NetWare’s Web Manager ....................................................................................................153
Believe it or not: A Linux VPN without kernel recompilation ........................................................155
Managing remote access to your network
May 26, 2000
By Ron Nutter, MCSE, CNE, ASE
A
re you getting more and more
requests for remote access to your
network? As I’m sure you’re aware,
granting these requests means a greater risk
that unwelcome visitors will access your net-
work. In this article, I’ll discuss a host of ideas
that should serve as a starting point for imple-
menting remote access.
There’s no single solution for protecting
your network and the valuable data it contains.
You’ll need to look at all the options I present
here and decide where they’ll fit into your
overall scheme. The only bad decision you can
make is to not make any decision at all.
Choosing the right type of
remote access
With recent changes in technology, you have
several options to choose from. In addition to
using a POTS (Plain Old Telephone Service)
line to connect to your network, you have such
options as xDSL (Digital Subscriber Line),
cable modem, PCS (Personal Communications
Service), and even satellite.
Depending on the phone company in your
area, you may hear terms like SDSL, HDSL, or
ADSL. Don’t be confused—this is a way of
identifying the specific type of DSL service
and how far away you can be from the CO
(central office) that provides the service. The
main requirements for DSL are:
X You must be less than 18,000 feet away
from the CO.
X The CO and your location must obtain the
service via copper wire.
The closer you are to a CO, the higher the
speed of service. If you’re receiving your serv-
ice via a fiber-optic connection, you won’t be
able to get DSL.
Cable modem Internet service isn’t as
prevalent in certain parts of the country
because of the infrastructure requirements
placed on cable companies to provide the
service. The advantage to this option is that it
can be faster than its DSL counterpart and just
as economical. With both DSL and cable
modem, you’re dealing with a connection that’s
always on and ready to go. This means that
your users will spend less time dialing up and
dealing with modem-related problems. The
disadvantage to both options is that the serv-
ices are good only to a fixed location (for
example, your house) and can’t be moved easily.
Another option is to use a PCS phone,
although that may not be a good long-term
solution. You have to add a small cable that
connects to the base of the phone and then to
the serial port on your computer. You then add
some software, and you can use an already
encrypted digital connection to get a link to
your network from just about anywhere that
the PCS provider’s network is available. The
current speed runs between 14.4 and 19.2,
depending on how close you are to a tower.
Satellite connectivity was once thought to
be very expensive and difficult to set up. With
services such as DirecPC and others (DISH
Network has announced that it will offer two-
way satellite Internet service this fall), you can
now consider using satellite when options such
as DSL and cable modem aren’t available. For
example, the way DirecPC works is that you
dial up a conventional ISP (Internet service
provider), and then, using software provided
with the DirecPC dish, you send the command
you want to execute (for instance, connecting
to a particular Web site). The results can be 10
to 20 times faster than you’d experience using
only a dial-up connection. The only thing that
can disrupt the satellite service is a snowstorm
or heavy rain. Unless you live in an area with
heavy or frequent storms, satellite connectivity
is an option worth considering.
Don’t publish the number
If you’re using a dial-in connection, the num-
ber you use for remote access should be kept
a fairly close secret. You should give this num-
ber only to those who have to dial in to the
network directly—and then probably only
with a manager’s approval. Depending on the
Administration 23
 frequency of staff turnover, you may need to
change this number occasionally to help dis-
courage ex-employees from causing problems
on your network.
Depending on the type of PBX you have,
you may want to consider using DID (Direct
Inward Dial) numbers for controlling remote
access. This way, you can easily busy out a
phone number when a remote user doesn’t
need it any longer. In addition, you can track
usage for department billing purposes. With
DID, you don’t have to worry about a bunch
of individual phone lines for all your remote
users. Instead, have the incoming DID trunk
terminate directly into a digital modem pool.
Using a dial-back
connection system
Years ago, IBM implemented a system called
Guardian that was designed for users needing
remote access to corporate information. With
Guardian, the user dials in to a predetermined
number. After properly authenticating to the
system that answered the phone, the user
hangs up and waits for a return call. When the
call comes, the software answers the call from
Guardian, provides an additional layer of
authentication, and then allows the session to
continue.
The problem with dial-back systems is that
they require the user to be at a predetermined
number unless the system is configured to
allow the user to specify the number. That in
itself somewhat defeats the purpose of a dial-
back system by allowing the call to be redi-
rected. With call forwarding fairly common,
users may not be where you think they are.
The advantage of a dial-back system is that
you can avoid extra long-distance charges
when calling from a hotel or using an inbound
800 number.
Letting the ISP be the
modem pool
The biggest hassle of offering remote access
to your network is managing what could
become a fairly substantial modem pool. This
could be an especially expensive proposition if
you implement a digital modem pool that
channelizes a T1 into multiple logical modems.
24 Administrator’s Guide to VPN and Remote Access, Second Edition
Most large ISPs have modem pools in more
than one city and, in many cases, on a national
or even international level. This means that
you are no longer tied to one or more banks of
modems. Therefore, you can concentrate on
having enough T1 or T3 capacity to handle the
number of remote users needing to access the
network.
Using RADIUS
The only problem with using an ISP as a
modem pool is that you now have an addi-
tional layer of management—a user account
for each user who will be remotely connecting
to your network. By using RADIUS (Remote
Authentication Dial-In User Service), you
remove that layer of management and allow
remote access to your network to be controlled
from one point (your network) instead of both
your and your ISP’s networks. When connect-
ing to the ISP’s modem pool for authentica-
tion, users can enter something as simple as
their e-mail addresses.
Consider VPN for secure
communications
There are varying levels of encryption. With
each step up the encryption ladder, you gain
more security while delaying access to infor-
mation. Keep in mind that regardless of any
VPN (virtual private network) solution you
choose to implement, the communications can
be unencrypted, given enough time and
resources. You must determine what type of
barrier can prevent hackers from gaining
access to your corporate data.
You can divide the VPN solutions into two
camps—hardware- and software-based. Hard-
ware solutions such as Cisco’s Secure PIX fire-
wall can carry a huge amount of VPN-based
communications. However, a software-based
solution won’t be able to carry as much
because you’re multitasking an existing net-
work operating system (NetWare, in this case).
An advantage of software-based solutions,
such as Novell’s BorderManager, is that it inte-
grates with your existing network infrastruc-
ture and minimizes multiple points of
administration. If you need additional levels of
authentication (sometimes known as strong
authentication), you can require that tokens be
used that constantly generate a series of num-
bers. The numbers change at periodic intervals
based on a mathematical formula.
When designing a secure network solution
such as a VPN, you want to avoid having a sin-
gle point of failure. Depending on the number
of remote users you’ll support, having more
than one VPN access device running is a good
idea. (For example, if you’re using BorderMan-
ager as your VPN solution, you may want to
have more than one BorderManager server
running the VPN service.) This approach
ensures that if one device fails, you won’t lose
all your remote access. While existing firewall
products can also provide VPN service, you
may choose to run the service on another sys-
tem so that if the firewall is down, your
remote VPN users can still gain access to
your network.
Using a personal firewall
While VPNs give you an encrypted link from a
remote user into your network, the possibility
still exists that hackers can work their way into
a remote PC connected to your network. They
can then jump onto the encrypted link and go
right into your network with little or no chal-
lenge. Firewalls were once used only to protect
access in and out of corporate networks. You
can now find a host of products, such as Nor-
ton Internet Security and BlackICE, that can
provide firewalls on your personal workstation
or home network.
As with any solution of this nature, you’ll
want to have some type of subscription serv-
ice to help keep the product current. As hack-
ers find new tools to gain access to your
network, you must, in turn, upgrade the tools
you’re using to protect access. You may want
to consider learning how hackers access net-
works and doing the same things in a test lab
so that you can continue to evaluate new tools
as they become available.
As you’re testing both the prospective solu-
tions and connectivity options, don’t immedi-
ately assume any potential “threats” that are
identified are actually threats. For example,
remote users using the @Home Internet cable
service to access the corporate network will
probably see periodic port probes looking for
the NNTP service running on the computer
they’ve attached to the cable modem. This is a
method used by the @Home NOC (Network
Operation Center) to ensure no one is running
a Usenet server. Running a Usenet server is a
violation of the user agreement for the
@Home network.
Mandate antivirus protection
for all remote users
It has been said that any solution is only as
good as the weakest link in the chain. So far,
I’ve discussed using a VPN link for an
encrypted connection to your corporate net-
work and a personal firewall to protect the
remote PC. You still have one point of vulner-
ability: computer viruses from an e-mail
attachment or a file download. There are sev-
eral good solutions—McAfee, Symantec, and
CAI, to mention just a few candidates. At least
one vendor, Symantec, has realized that you
may want a solution that involves both a per-
sonal firewall and an antivirus software pro-
gram. Symantec offers a bundled solution in
Norton Internet Security. The advantage of a
bundled solution is that if there’s a problem,
you have one less company to talk to for tech-
nical support.
More and more corporate networks are run-
ning some type of antivirus solution at net-
work entry points. Nevertheless, running an
antivirus package on the remote PC introduces
yet one more safeguard for your network—
and one more hurdle that a potential virus
must clear. Just as with the personal firewall
option I discussed earlier, you’ll want to have
some type of subscription service available. In
addition, make sure your remote users under-
stand that they need to periodically check for
updated virus signatures (or you can configure
their workstation to perform that step for
them). Running with outdated signatures is
almost as bad as not using any antivirus solu-
tion at all.
Using Citrix or Windows
Terminal Server
If you’re concerned about rolling out remote
access options to “computer-challenged”
Administration 25
 users, you may want to consider using either
Citrix WinFrame or Microsoft’s Windows
Terminal Server. You can think of these
products as the equivalent of a computer
running PCAnywhere on steroids. With this
type of solution, however, you’re getting
access to a session on the computer running
either WinFrame or Terminal Server and not
controlling the whole system. An added
advantage is that if a user has a problem log-
ging on or running a particular application,
you can “shadow” the session in question and
walk the user through the problem.
Depending on your configuration, you may
be able to use a fairly inexpensive computer
(even an XT, in some cases) to access your net-
work remotely without having to beef up the
hardware in the field. That way, neither the
application nor the data that’s being accessed
actually leaves your network—only screens and
keystrokes are passing back and forth. You
may also be able to get away with using a regu-
lar dial-up connection without making the
Understanding and troubleshooting virtual
private networking
Mar 5, 2001
By Debra Littlejohn Shinder, MCSE
I
t’s easy to understand why virtual private
networking (VPN) is steadily increasing in
popularity—VPNs are flexible and secure.
In this article, I’ll explain how VPNs work and
how to troubleshoot common client-side con-
figuration and connection problems.
Three ways to connect from
the road
Over the past few years, it has become more
and more important for workers to be able to
connect to their company networks even
when at home, on the road, or on location at
26 Administrator’s Guide to VPN and Remote Access, Second Edition
additional investment in cable modem, DSL,
or ISDN access.
The disadvantage is that you potentially will
have a single box with two or more processors
with more than 256 MB of RAM in your com-
puter room to support the incoming user ses-
sions. Consider having a second box that users
can access to get to your network. (Citrix
offers a server farm option that allows multiple
servers to be disguised as a single logical
server. Users never know they’re using a differ-
ent server each time they authenticate to the
network.)
Conclusion
You’ll need to continually evaluate your net-
work to ensure that you have the level of pro-
tection you need. Don’t ever be content that
you have done everything that can be done to
protect your network and the access to it. Just
take things one step at a time, and don’t try to
implement the whole solution at once.
clients’ sites. This can be accomplished in three
basic ways:
X A direct dedicated connection
X A dial-up remote access connection
X A VPN connection
The last is an attractive alternative for several
reasons, including flexibility, cost-effectiveness,
security, and ease of implementation.
All modern Microsoft operating systems—
Windows 95 (with the Dial-up Networking 1.3
upgrade), 98, Me, NT 4.0, and 2000—include
built-in support for virtual private networking,
as will the yet-to-be-released Windows XP
(code name “Whistler”). Tunneling protocols
and VPN client functionality can be installed
from the Windows installation CD, making a
computer running any of these operating sys-
tems function as a VPN client. Although
Microsoft has made VPN configuration as
simple as possible, even providing wizards in
the latest versions of Windows, establishing
and using a VPN connection can still be a lit-
tle tricky.
VPN overview
Before you can effectively diagnose and cor-
rect VPN problems, you need a basic under-
standing of how a VPN works. A VPN
connection is made by “tunneling” through a
public network (typically the Internet) to reach
a private network. There are three basic com-
ponents involved:
X Encapsulation
X Encryption
X Authentication
Encapsulation
The link between the client and the private
network emulates a point-to-point connection
by encapsulating, or wrapping, the data packet
(which can use any network transport protocol
supported on the private network, including
NetBEUI, IPX/SPX, or TCP/IP) inside a
header that contains information for routing
across the public TCP/IP network.
Encapsulation is performed by a tunneling
protocol. There are two tunneling protocols
supported by Microsoft for VPN connections:
the Point-to-Point Tunneling Protocol (PPTP)
Table A: Tunneling protocols supported by Microsoft operating systems
Operating system
Windows 95 with Dial-up Networking 1.3 upgrade
Windows 98
Windows NT 4.0
Windows 2000
Windows Me
and Layer 2 Tunneling Protocol (L2TP),
depending on the operating system (see Table A).
Encryption
Encapsulation makes it possible for the pack-
ets to travel across the public network.
Encryption provides confidentiality for the
contents, creating the element of privacy. It is
possible to send unencrypted data through a
tunnel, but this would be virtual networking,
not virtual private networking. Encryption is
performed by:
X Microsoft Point-to-Point Encryption
(MPPE) protocol—with a PPTP tunnel
X IPSecurity (IPSec) protocol—with an
L2TP tunnel
VPN data encryption is between the VPN
client and VPN server. The availability of
encryption depends on the user-level authenti-
cation method used for the connection.
Authentication
Authentication protocols supported by all
Microsoft VPN clients include:
X Challenge Handshake Authentication
Protocol (CHAP)
X Microsoft Challenge Handshake Authenti-
cation Protocol (MS-CHAP) version 1
X Password Authentication Protocol (PAP)
X Shiva Password Authentication Protocol
(SPAP)
Additionally, Windows 2000, Windows 95
with the Dial-up Networking 1.3 upgrade,
Windows 98 with Service Pack 1 or later, and
Windows NT with Service Pack 4 or later sup-
port MS-CHAP version 2. Only Windows
Supports PPTP Supports L2TP
Yes No
Yes No
Yes No
Yes Yes
Yes No
Administration 27
 2000 supports the Extensible Authentication
Protocol (EAP).
Troubleshooting common
VPN problems
A VPN connection requires that both the
client and the VPN server be connected to
the Internet. The client connection can be
either via a direct dedicated connection or a
dial-up connection to the client user’s ISP.
The dial-up connection presents the first
point of failure, so it is important to ensure
that the client is properly connected to the
ISP. Do this by checking the status of the
dial-up connection. Attempt to ping an Inter-
net host. If you are able to do so, you have a
connection to the ISP. If not, you will need to
troubleshoot your modem configuration
and/or Dial-up Networking.
The most common VPN connection prob-
lems fall generally into one of the following
categories:
X Problems related to the Internet
connectivity on one or both sides
X Problems related to VPN server
configuration
X Problems related to VPN client
configuration
This article focuses on the last category, but
if you are unable to detect a reason for the
problem on the client side, the problem may
lie in one of the other categories. Most VPN
users will be running the Windows 9x/Me,
NT 4.0 Workstation, or Windows 2000 Pro-
fessional operating system on the client com-
puter. Basic considerations are the same,
although there are some differences in config-
uration dialog boxes. First, I’ll look at configu-
ration of Windows 2000 clients and then
Figure A
You may get an Error 678 message if the VPN server does not
answer.
28 Administrator’s Guide to VPN and Remote Access, Second Edition
point out differences (where they exist) in
other Microsoft operating systems. As with
any troubleshooting situation, you should first
consider the most basic (and easiest to cor-
rect) possibilities.
Invalid credentials (logon failure)
You must have a valid username and password
that will allow you to connect to the VPN
server. Otherwise, you will receive this message:
Your credentials have failed remote network
authentication
You will be prompted to re-enter your user-
name and password (and logon domain, if
applicable). Ensure that you are entering the
proper account name and password.
Your user account must be set on the server
to allow remote access (although this is a
server configuration problem, it is one to be
aware of if your credentials are rejected by the
VPN server). If you’re sure the credentials you
entered are correct, contact the network
administrator or check the settings on the
Dial-in tab of the user account properties
sheet on the server.
Tunneling protocol configuration
problems
If the VPN server does not support the tun-
neling protocol with which the client is
attempting to connect, the connection will fail.
Windows 9x/Me/NT clients support only
PPTP as the tunneling protocol. However,
when you configure a Windows 2000 client,
you have three options: PPTP, L2TP, or Auto-
matic. The last is the default (in which case the
client will try to establish an L2TP connection
first, then try PPTP).
If your VPN client is configured to use a
different tunneling protocol from that sup-
ported by the VPN server, you will see an
Error 678 message (No answer), as shown in
Figure A.
This error occurs because there are no ports
on the server configured to answer for the
specified tunneling protocol. You may also get
this message if all the PPTP or L2TP ports on
the VPN server are already in use.
When you use the Network And Dial-Up
Connections Wizard to create a Win2K VPN
connection, Automatic will be set as the server Figure B
type (the wizard does not offer you a chance to
select). However, you should check the proto-
col configuration in the Properties box for the
VPN connection, as shown in Figure B, and
change it to Automatic or to the protocol set-
ting for which the server is configured to cor-
rect this problem.
Note that in Windows NT 4.0, only PPTP is
supported, and you must install PPTP as a new
protocol in the Select Network Protocol dialog
box, as shown in Figure C. The VPN connection
is configured by adding a VPN adapter device
from the Port box in the RAS Setup dialog box.
You then create a dial-up networking entry to
connect to the PPTP server.
In Windows 98, you add Virtual Private
Networking as a Communications component
from Add/Remove Programs in the Control In Windows 2000, you can select a specific tunneling protocol.
Panel. Making a VPN connection requires
using two connections: a dial-up connection to
the Internet and a PPTP connection to the pri- tion. Another possibility, if you are able to
vate network. You configure the VPN connec- ping the server by name and address but you
tion with the Make New Connection Wizard cannot establish a VPN connection, is that the
by selecting Microsoft VPN Adapter as the server is filtering GRE packets. Again, this is a
connection device instead of a modem. server configuration problem that cannot be
If the VPN server supports only L2TP corrected from the client side.
connections, you will not be able to establish Authentication method configuration
a VPN with a Windows 9x/Me or Windows problems
NT client. In addition to a common tunneling protocol,
You may also see the same No Answer both client and server must support a common
error message presented above if PPTP filter- authentication method. If the client is not con-
ing is enabled in the server’s RAS configura- figured to use an authentication method that

Figure C Figure D

If there is no common authentication protocol, you will get an Error

919 message.

PPTP must be installed as a network protocol in Windows NT 4.0.

Administration 29
 the VPN server supports, you will see an Error
919 message, shown in Figure D.
In Windows 2000, check the authentication
protocols allowed by the client in Advanced
Security Settings (Figure E), accessed via the
Security tab of the VPN connection properties
sheet.
Note that the Windows 2000 client can
be configured to use EAP or to allow any or
all of the standard authentication methods
supported by other Microsoft operating sys-
tems. If you have chosen to use EAP, you
can choose either Smart Card Or Other
Certificate-Based Authentication or MD-5
Challenge.
Remote access policies on the VPN server
can also be responsible for this error message.
Figure E
The client must use an authentication protocol that is allowed
by the server.
Figure F
An encryption type mismatch will result in an Error 742 message.
30 Administrator’s Guide to VPN and Remote Access, Second Edition
Encryption type mismatch
Another reason your VPN connection may fail
is a mismatch between data encryption
requirements on the client and server. In the
Windows 2000 client’s Advanced Security Set-
tings, you can choose one of the following:
X No Encryption Allowed (Server Will Dis-
connect If It Requires Encryption)
X Optional Encryption (Connect Even If No
Encryption)
X Require Encryption (Disconnect If Server
Declines)
A mismatch will result in an Error 742 mes-
sage, shown in Figure F.
As with authentication protocols, Windows
2000 encryption settings are changed via the
Advanced Security Settings property sheet, as
shown in Figure G.
Because the default setting is to Require
Encryption, if you get this error message, you
should always check out the possibility that the
VPN server is set not to allow encryption.
“Unreachable Destination” problems
In all of the problems discussed above, the
client is able to contact the VPN server but is
Figure G
You can select No Encryption, Optional Encryption, or
Require Encryption.
unable to negotiate a VPN connection because Figure H
of configuration settings that do not meet the
server’s criteria. Sometimes, you’ll see the
Error 769 message (The specified destination
is not reachable), shown in Figure H.
There can be three causes of this error:
XThe VPN server may be offline. You should
If the destination VPN server cannot be contacted, you will get an
attempt to ping the server to ascertain Error 769 message.
whether it is online.
Figure I
XYou may have entered the wrong server
name or IP address for the VPN server in
the client configuration properties. You
should recheck the entry and ensure you
have the proper name or IP address
entered.
XThere may be a name resolution problem if
you are trying to connect by server name.
You should try connecting by IP address
instead of server name.
If you can ping the server by IP address but
not by name, this means that either the server
does not have a registered domain name or the
DNS server on the network is down or not
functioning correctly.
You can determine whether traffic is moving across the
VPN connection by checking its Status sheet.

TIP: ISPS AND MULTIPLE IP ADDRESSES

Note that if the VPN server has a dial-up connection to the Internet, it is likely that the ISP
will assign it a different IP address each time an Internet connection is established. You will
not be able to connect by IP address unless you know the server’s currently assigned
address. More commonly, a VPN server will have a permanent (static) address and a dedi-
cated full-time Internet connection.

Figure J

Connection status is shown in the Status column of the Network And Dial-Up Connections window.

Administration 31
 Problems after connecting
If it appears that the VPN has connected suc-
cessfully, but you are unable to access
resources on the server or LAN, you can check
the status of the connection in several ways.
A Windows 9x/Me/2000 client will have
an icon in the system tray for each remote
access connection. Right-click the icon and
click Status. You will see a status box similar
to that in Figure I. In the Activity section, note
changes in the number of bytes sent and
received to confirm that traffic is going across
the VPN connection.
The same properties box can be accessed
via Start | Settings | Network And Dial-Up
Connections. Again, right-click the VPN con-
nection and select Status. In addition, the sta-
tus for the VPN connection should show as
Connected in the Network And Dial-Up Con-
nections window, as shown in Figure J.
At the command prompt, run netstat. This
will show a list of active connections, as shown
in Figure K. In the Foreign Address column,
you can recognize VPN connections by the
appearance of the type of tunneling protocol
(PPTP or L2TP) following the foreign address.
Note the two active VPN connections in Fig-
ure K—one to a VPN server named Mail.star-
blazer.tzo.com and one to Exeter.tacteam.net.
If your connection is established and you
can access the VPN server, but you cannot
browse the LAN or access resources on other
computers, there can be several reasons for the
problem:
Figure K
The netstat command will show you all active connections, including VPN connections.
32 Administrator’s Guide to VPN and Remote Access, Second Edition
X The VPN server must be configured to
allow access to the entire LAN, not just to
the VPN server computer. This is a server
configuration that cannot be corrected from
the client side.
X If you receive an Error 53 message, (Net-
work path was not found) this may be
because the client cannot resolve NetBIOS
names. Ensure that the client has a WINS
server assigned. This can be done manually
in the client’s TCP/IP properties or via
DHCP.
X Your account may not have the proper per-
missions to access the resources on the
server.
If you are unable to browse, attempt to
connect to the network shares on computers
inside the LAN using the UNC path
(\\servername\sharename).
If you are using Windows 9x clients to log
on to a domain, ensure that the workgroup
name in the Network Identification properties
is the same as the domain name.
Undesired disconnections
If you are able to establish the VPN connec-
tion, access resources, and browse the net-
work, but the link is prematurely disconnected,
check the following possibilities:
X You may have the VPN connection config-
ured on the client to hang up after a speci-
fied number of minutes of idle time. As
shown in Figure L, you can set this value
from one minute to 24 hours, or to never
hang up (the default). Check this setting
first if you are getting disconnected at a reg-
ular interval of time.
X Your ISP may have idle time limitation rules
or connect time limitation rules that auto-
matically disconnect you after a specified
period of idle time or a specified period of
time online, even if active.
Firewall and proxy problems
The firewalls and proxy servers that often pro-
tect our networks from unauthorized access
can complicate VPN connectivity. Although
you may be unable to correct these problems
from the client side, you should be aware that
if your client configuration appears to be cor- Figure L
rect and you are unable to establish a VPN
connection, it may be due to firewall or proxy
restrictions or packet filtering rules on the
router.
For example, you may be unable to browse
the LAN if NetBIOS packets are being filtered
by the firewall or router. In this case, the net-
work administrator needs to open UDP ports
137 and 138 and TCP port 139. You cannot
reach a VPN server behind a firewall at all
unless port 1723 is open and protocol 47
(GRE) is allowed.
If you have an active Winsock Proxy client,
you will not be able to create a VPN, because
the Winsock client immediately redirects data
to the proxy server before it can be processed
as necessary by the VPN. You will have to dis-
able the Winsock Proxy client. Microsoft’s
Proxy Server does not support outbound
Disconnections can be caused by an idle time hang-up setting
PPTP requests from internal clients (behind in the Virtual Private Connection Properties dialog box.
the proxy). Gateway-to-gateway VPNs, in
which the proxy server is the VPN client, can
be established. Also, because IPSec does not
work with address translation (which is the way Conclusion
Proxy Server provides Internet access to its Virtual private networking provides a cost-
clients via a single public IP address), you will effective way to take advantage of today’s
not be able to establish an L2TP/IPSec VPN almost universal Internet connectivity to create
from behind the proxy server. a private “tunnel” to a company LAN or other
In Microsoft’s new ISA Server, the Winsock network from a remote location. VPN connec-
Proxy client is called the Firewall client. ISA tion failures and other problems are often easy
clients running the Firewall client software to correct by modifying the client configura-
cannot establish a VPN because outbound tion. In this article, I showed you techniques
PPTP is not supported. However, ISA clients for troubleshooting and correcting common
that are configured as Secure NAT (SNAT) client-side VPN connectivity problems.
clients can be VPN clients.

TIP
For more information about Microsoft’s ISA
Server, see www.ISAserver.org.

Administration 33
 Controlling the dial-up bandwidth
on your VPN
Jan 26, 2001
By Ed Engelking II, A+
M
anaging available bandwidth via dial-
up connectivity was once a relatively
easy task for network administra-
tors. Previously, most users connected to a vir-
tual private network, or VPN, via the Internet
using connections that consumed only a small
amount of bandwidth. With the onset of
broadband communications such as cable and
DSL within SOHO environments, however,
administrators now face the challenge of con-
trolling available bandwidth on VPNs.
If your telecommuters are burning band-
width by using broadband connectivity, how
can you address this problem? Here are some
solutions available to network administrators
that can help limit and control the amount of
bandwidth used, both inside and outside of
the network.
Quality of Service for all
Improved firewalls and routers, incorporating
Quality of Service (QoS), enable the limitation
of bandwidth for incoming and outgoing data,
which in turn increases acceptable perform-
ance for each employee outside of the office,
no matter the connection speed.
DEFINITION: QUALITY OF SERVICE
In networking, Quality of Service (QoS) is
a term that indicates a guaranteed band-
width level.
With QoS integrated within a VPN, an
administrator gains full control over the data
flowing through the network. Two ways to
maintain this control are packet classification
and bandwidth management:
X Packet classification
Packet classification groups data by impor-
tance. The more important the data, the
higher its classification, and the better han-
dling it receives at the expense of other, less
important data on the same network.
34 Administrator’s Guide to VPN and Remote Access, Second Edition
X Bandwidth management
By using bandwidth management, a VPN
administrator can police the incoming and
outgoing data from a network and allow
certain amounts of bandwidth to be avail-
able for differing packet classifications.
Other forms of bandwidth control
Depending on the needs of the network
administrator, there are additional ways of
controlling the amount of available bandwidth:
X Traffic shaping
Traffic shaping comes into play when a
service provider detects Internet traffic con-
gestion. The amount of incoming and out-
going data streams is then lowered via
queuing. This causes the bandwidth in use
to fall below the allowed allocation.
X Fair bandwidth
Fair bandwidth allows all users on a net-
work to obtain equal access to Internet
bandwidth. With fair bandwidth enabled,
applications using large amounts of a data
stream, such as MP3s, will have their band-
width decreased in order to provide fair
access to other employees.
X Guaranteed delivery
Guaranteed delivery reserves a section of
bandwidth for specific services within a net-
work, such as video teleconferencing,
voiceover IP, and money transactions. It
determines which services are high priority
and allocates bandwidth accordingly.
Controlling bandwidth will
continue to challenge
administrators
Network administrators must control virtual
private networking and the resources that
are required for it to operate successfully
in an organization. Because telecommuters
and remote offices are here to stay, VPN
administrators will continue to have issues
with maintaining bandwidth. However, the
incorporation of new technologies intended to
supplement QoS will help network administra-
tors manage this problem.
Article resources
The following resources were used in the
creation of this article:
X Ashley Laurent Security Newsletter—
Volume 1, Issue 2, 3/3/00
(http://www.ashleylaurent.com/
newsletter/03-03-00.htm)
Making the connection with Windows 2000
Professional Dial-Up Networking
Jun 28, 2001
By Dr. Thomas Shinder, MCSE
D
id you know Windows NT 4.0 Work-
station had built-in RAS client and
RAS server capabilities? It you didn’t,
then you’re a member of a very large club. Set-
ting up Windows NT 4.0 Workstation to be a
RAS client or server was not an easy thing to
accomplish. As was typical in Windows NT
4.0, there were multiple interfaces you had to
slog through to access the configuration dia-
log boxes and get things set up correctly.
When you eventually found your way to the
correct interface, the configuration was far
from intuitive.
Windows 2000 Professional includes all the
features of the Windows NT 4.0 Workstation
RAS client and server, and a lot more. The
configuration interface is wizard-driven; it’s
almost impossible to make a mistake. The
Windows 2000 Professional Dial-Up Network-
ing client now allows you to call a VPN server
on the intranet or Internet. Unlike in Windows
NT 4.0, this feature is available right out of the
X Access VPNs for the Enterprise—Cisco
Systems, 7/3/000
(http://www.cisco.com/warp/public/
cc/so/neso/vpn/vpnsp/justify/avpnn_bc.
htm)
X Quality of Service for Virtual Private
Networks—Cisco Systems, 8/28/00
(http://www.cisco.com/warp/public/
cc/so/neso/vpn/vpne/qsvpn_wp.htm)
X QoS definition by Webopedia
(http://webopedia.internet.com/TERM/
Q/QoS.html)
box, and there are no complex protocol and
interface configurations to make.
The RAS server feature is also improved. A
Windows 2000 Professional machine can sup-
port a single dial-in session from a remote user
per interface. However, the operating system
also supports analog, ISDN, VPN, parallel,
serial, and infrared interfaces. Thus, the
machine can actually handle multiple inbound
sessions.
In this article, we’ll look at the dial-up net-
working features available in Windows 2000
Professional. These features can be broken
down into two major categories:
X Outbound access
X Inbound access
Once you understand the features and func-
tionality of outbound and inbound RAS access
on a Windows 2000 Professional computer,
you’ll never want to get near a Windows NT
4.0 workstation again!
Administration 35
 Windows 2000 Professional
outbound remote access
Windows 2000 Professional supports several
types of outbound remote access. These
include:
X Corporate dial-up RAS client calls
X ISP dial-up calls
X VPN client calls
A wizard guides you through creating each
type of connection. When you create a con-
nection to a particular location, the object the
wizard creates is called a connectoid. There are
several connectoids seen in Figure A.
Figure A
The connectoid is an icon located in the Network And Dial-up Connections
window; it is used to invoke a particular type of connection.
Figure B
Choose the Dial-up To Private Network option on the Network Connection
Type page.
36 Administrator’s Guide to VPN and Remote Access, Second Edition
Creating a corporate RAS
Dial-Up client
When a remote user establishes a dial-up con-
nection to the corporate network, his or her
computer is a participant on the network in
exactly the same way as a machine attached via
the local Ethernet. The VPN client can access
the same resources and print to the same print-
ers as the locally attached machines. If the user
dials in using the option in the logon dialog
box for remote access, he or she will not even
need to enter credentials to access network
shares and other network resources.
To create a connectoid to connect to the cor-
porate RAS server, perform the following steps:
1. Open the Control Panel and double-click
on the Network And Dial-up Connec-
tions icon.
2. In the Network And Dial-up Connections
window, double-click the Make New Con-
nection icon. This opens the Welcome To
The Network Connection Wizard page.
Click Next to continue.
3. The Network Connection Type page
appears (Figure B). Select the Dial-up To
Private Network option and click Next.
4. The Phone Number To Dial (Figure C) page
allows you to enter the phone number for
the corporate RAS server. You can enter the
entire phone number in the Phone Number
text box, or you can enable the Use Dialing
Rules check box and select the area code
from the Area Code drop-down list box.
After entering the phone number, click Next.
5. The Connection Availability page allows
you to make the connectoid available for
all users or only for yourself. For security
reasons, the connectoid should be available
only to the user who creates it. Many users
decide to save their dial-up password in the
connectoid. Therefore, you do not want it
to be available to other users who might
access the machine. Click Next.
6. The Completing The Network Connec-
tion Wizard dialog box appears and asks
you to name the connectoid. Click Finish
(Figure D).
 From the connectoid’s icon on the desktop, Figure C
launch the RAS connection. You will see the
Connect Corporate RAS Server dialog box, as
seen in Figure E.
The logged-on user’s name will appear auto-
matically in the User Name text box. If the
user needs to log on with another name, he or
she can manually enter it here. The Save Pass-
word check box allows the password to be
saved with the connectoid. Beware of the
security implications of saving the password
with the connectoid. The phone number to
dial is automatically included, as is the location.
Creating an ISP dial-up and local
network Internet connection
Your company may decide not to allow direct
dial-up connections to a corporate RAS server. Configure the phone number to dial.
Direct dial-up RAS servers can be expensive to
implement and maintain. A more cost-effective
solution is to allow users to dial up an Internet 2. In the Network And Dial-up Connections
connection and then create a virtual private net- windows, double-click the Make New
work (VPN) connection to a corporate VPN Connection icon. This opens the Welcome
server via the dial-up Internet connection. To The Network Connection Wizard page.
Creating an ISP dial-up connectoid is simi- Click Next to continue.
lar to creating the corporate RAS client con- 3. The Network Connection Type page will
nectoid. Perform the following steps to create appear. Select Dial-up To The Internet and
the ISP dial-up connectoid: click Next.
1. Open the Control Panel and double-click 4. The Welcome To The Internet Connection
on the Network And Dial-up Connec- Wizard (Figure F) appears. You have three
tions icon. choices:

Figure D Figure E

Put a check mark in the check box for Add A Shortcut To My Desktop to make
access to the connectoid much easier. Make the connection in this dialog box.

Administration 37
 X The I Want To Sign Up For A New
Internet Account... option allows the
user to create a new dial-up account
with an ISP. Microsoft provides a list of
ISPs. Since your company will have pro-
vided its users with an account, there is
no reason for a user to select this
option. Even if the user does not have
Figure F
Select the third option and click Next to
continue.
5. The Setting Up Your Internet Connection
Select the third option from the Internet Connection Wizard.
Figure G
6. The Local Area Network Internet Config-
Connect to the Internet through the LAN.
38 Administrator’s Guide to VPN and Remote Access, Second Edition
an ISP account, he can do better by
researching local or national ISPs.
X The I Want To Transfer My Existing
Internet Account To This Computer...
option gives you the opportunity to sign
up for a new account, even though you
already have an existing one. Avoid this
option unless you want to transfer to a
new ISP.
X The I Want To Set Up My Internet
Connection Manually... option is the
preferred option if you already have an
ISP account. This option provides you
the most flexibility when setting up the
connection.
page (Figure G) allows you to connect to the
Internet using a phone line and modem or
via a local area network (LAN) connection.
If you choose the I Connect Through A
Phone Line And A Modem option, subse-
quent pages will ask you for a username
and password, the phone number of the
ISP, the name of the connection, and
whether you want to create a mail account.
All these steps, except for the mail account
step, are the same as when you created a
direct dial-up connection to the corporate
RAS server. The I Connect Through A
Local Area Network (LAN) option allows
a machine on a network with a centrally
routed or proxied connection to the Inter-
net to connect to Internet resources. A
large proportion of remote employees have
small home networks. In this example, we’ll
select this option. Click Next to continue.
uration page appears next (Figure H). The
Automatic Discovery Of Proxy Server
(Recommended) option allows the client
to use a wpad entry contained on either a
DNS or DHCP server. If such an entry is
not made on the internal network, this
option should be left blank. The Use
Automatic Configuration Script option
allows the client to take advantage of
 Microsoft Proxy Server 2.0 or ISA Server Figure H
2000 caching arrays. Since it’s unlikely that
a user will have an enterprise array on his
home network, this option should also be
disabled. The Manual Proxy Server option
is the preferred option for a home net-
work. Select this option and click Next.
7. The second Local Area Network Internet
Configuration page allows you to config-
ure the IP address of the proxy server.
Most home network users will have a sin-
gle proxy or NAT server. Enter the IP
address of the internal interface of the
proxy server and place a check mark in the
Use The Same Proxy Server For All Proto-
cols check box. Click Next.
8. The third Local Area Network Internet
Configuration page allows you to config-
ure addresses on the local network that will
Configure the LAN-connected Internet client to use a proxy server.
bypass the proxy server. Click Next to
continue.
Figure I
9. The Set Up Your Internal Mail Account
page offers the user an opportunity to cre-
ate a new mail account. Select No on this
page and click Next.
10. On the last page of the wizard, click Finish
to complete the Internet connection.
The machine is now able to connect to the
Internet through the proxy or NAT server. If
you had created a dial-up connection to the
Internet, a connectoid similar to the corporate
RAS client connection would be created.
Creating a VPN client connection
Windows 2000 Professional supports out-
bound VPN client connections through both
dial-up and LAN interfaces. Unlike in Win-
dows NT 4.0 Workstation, you do not need to Select the type of public network connection.
install a PPTP VPN adapter and go through a
circuitous configuration procedure. A wizard
the ISP automatically before establishing the
walks you through the process of creating the
VPN link.
VPN client connection.
To create a dial-up VPN link, perform the
If the machine is not connecting to the
following steps:
VPN server through a LAN connection, it will
need to dial up an ISP before establishing the 1. Open the Control Panel and double-click
VPN link. Therefore, you need a dial-up con- on the Network And Dial-up Connec-
nectoid configured on the machine. When you tions icon.
configure the dial-up VPN connection, Win- 2. In the Network And Dial-up Connections
dows 2000 Professional will offer to dial up window, double-click the Make New

Administration 39
 Connection icon. This opens the Welcome
To The Network Connection Wizard page.
Click Next to continue.
3. The Network Connection Type page will
appear. Select the Connect To A Private
Network Through The Internet option
and click Next.
4. On the Public Network page (Figure I),
you choose whether to connect to the
VPN server via a LAN connection or
through a dial-up connection. To create
the initial ISP link, click the down arrow
under the Automatically Dial This Initial
Connection option and select your ISP
connection. After making the selection,
click Next.
5. On the Destination Address page (Figure J),
type in the Fully Qualified Domain Name
(FQDN) or IP address of the VPN server.
Click Next to continue.
6. On the Connection Availability page,
choose to make the connection available
for all users or only for yourself. For secu-
rity reasons, your best option is to make
the connection available only for the user
who creates it. Click Next to continue.
7. On the final page of the wizard, type in the
name of the connectoid and click Finish.
Figure J
If you type in a FQDN, the client must be able to resolve the address by using a
public DNS server.
40 Administrator’s Guide to VPN and Remote Access, Second Edition
The connectoid for the VPN link will
appear in the Network And Dial-up Connec-
tions window. When you double-click the con-
nectoid, a dialog box will appear asking if you
would like to establish a link with the ISP
before connecting to the VPN server. After
the Internet connection is established, a sec-
ond dialog box will appear asking for creden-
tials to establish the VPN connection to the
VPN server.
Windows 2000 Professional
inbound remote access
connections
Windows 2000 Professional can also accept
inbound calls. Unlike Windows 2000 Server
machines, a Windows 2000 Professional
machine can accept only a single inbound con-
nection per RAS interface. Inbound calls can
be accepted via serial, parallel, infrared, and
VPN interfaces.
To configure the Windows 2000 Profes-
sional computer to accept inbound calls, per-
form the following steps:
1. Open the Control Panel and double-click
on the Network And Dial-up Connec-
tions icon.
2. In the Network And Dial-up Connections
windows, double-click the Make New
Connection icon. This opens the Welcome
To The Network Connection Wizard page.
Click Next to continue.
3. Select the Accept Incoming Connections
option and click Next.
4. On the Devices For Incoming Connec-
tions page (Figure K), select the device on
which you want to accept inbound connec-
tions. In this example, we can accept calls
on a modem and an LPT (parallel) port.
Note that we can select and receive calls
on all devices. We’ll select both interfaces,
and click Next.
5. On the Incoming Virtual Private Connec-
tion page (Figure L), you tell the wizard
whether you want to accept VPN connec-
tions on this interface. If you wish to make
VPN connections to the Windows 2000
Professional computer, the machine
Figure K Figure L

Select a device for inbound connections. We will allow inbound VPN connections.

should have a dedicated connection to the In the TCP/IP address assignment

Internet. Typical dedicated connections frame, choose whether you want to assign
are xDSL, ISDN, and cable modem con- addresses via DHCP or from a static pool of
nections. However, you can get dial-up IP addresses. If you choose to use DHCP,
modem accounts that allow for dedicated you must be sure you have a DHCP server
connections with true unlimited access. on the internal network on the same net-
Note that the modem will still allow work ID as the internal interface of the
inbound direct dial-up connections with Windows 2000 Professional computer. If
this configuration. Click Next. you choose to use a static pool of addresses,
6. On the Allowed Users page (Figure M), you you will have to configure a From and a To
select which users you want to allow per- address. You must include at least two
mission to make inbound calls. In this addresses. If you try to put the same
example, we’ll select the Administrator address in both boxes, you will get an error.
account and click Next.
7. The Networking Components page Figure M
(Figure N) displays the network protocols
and services used for this connection.
Click on the Internet Protocol (TCP/IP)
entry and then click the Properties button.
8. The Incoming TCP/IP Properties page
(Figure O) allows you to configure how IP
addresses are assigned to inbound callers.
Place a check mark in the Allow Callers To
Access My Local Area Network check box
if you want RAS clients to be able to access
the internal network behind the Windows
2000 Professional machine. If this check
box is not checked, the user will be able to
access resources only on the Windows
2000 Professional machine itself. Allow Administrator inbound access.

Administration 41
 The Allow Calling Computer To Specify
Its Own IP Address option will allow the
caller to configure his or her own IP
address in the VPN client connection
interface. Be careful with this option. If
the client tries to use an IP address that is
Figure N
You can also configure the properties of the other components here.
Figure O Figure P
Configure client IP addressing parameters.
All inbound connections will be accessed through this connection.
42 Administrator’s Guide to VPN and Remote Access, Second Edition
already in use on the network, the connec-
tion will fail. Click OK and click Next.
9. On the final page of the wizard (Figure P),
you are informed that the connection will
be named Incoming Connections.
You do not need to restart the computer.
After you complete the wizard, users can begin
to make inbound calls to the Windows 2000
Professional computer.
Conclusion
Windows 2000 Professional supports the roles
of RAS server and RAS client. As a RAS
client, it can make direct dial-up and VPN con-
nections. As a RAS server, it can receive a sin-
gle inbound call on each RAS-enabled
interface. The Windows 2000 Professional
computer supports inbound calls to just the
Windows 2000 Professional machine itself, or
to the entire network to which the Windows
2000 Professional machine is attached. RAS
connections are easy to set up because all
inbound and outbound connections are cre-
ated using a wizard.
Understanding demand dial connections
in Windows 2000
Dec 25, 2000
By Jim Boyce
W
hen you configure a Windows 2000
router, you have two options for
establishing connections with other
routers or networks: dedicated or demand dial
connections. Dedicated connections typically
use connections such as T1 and frame relay.
Except on rare occasions when a hardware fail-
ure occurs, the connection remains persistent.
Demand dial routing (also called on-
demand routing) forwards packets across a
nonpersistent Point-to-Point Protocol (PPP)
connection. In general, you can think of
demand dial connections as those routing con-
nections that connect via dial-up means,
whether those connections are persistent or
not. For example, if you support a remote
office that needs to be fed data from your local
servers only once or twice a day, and the con-
nection is metered and incurs charges based on
connection duration, a dedicated connection
might not make sense. In such a situation, a
demand dial connection, which gets used only
when data actually needs to be transmitted,
makes more sense and could save the company
Figure A
Internet
Main Office
Router
A demand dial connection can serve a satellite office.
a small bundle in connectivity charges. After
the data is transmitted and an appropriate idle
time has passed, Windows 2000 drops the con-
nection. Figure A illustrates a situation in which
demand dial routing would be useful.
On-demand versus persistent
There are two types of demand dial connec-
tions: on-demand and persistent. An on-
demand connection is nonpersistent and
remains connected only when packets need to
be forwarded through the demand dial inter-
face. The previous example of the remote
office is a good example of a scenario where
an on-demand connection would be the best
solution. Any time you have a metered connec-
tion, such as a long-distance POTS call or
metered ISDN service, on-demand routing is
generally the best solution.
The alternative is a persistent connection.
At first blush, persistent connections might
seem illogical in the context of demand dial
routing, but you need to remember that
demand dial routing isn’t simply geared toward
Demand Dial
Connection
Satellite Office
Router
Administration 43
 forwarding packets across metered connec-
tions, but rather forwarding packets across any
PPP dial-up connection. There are, therefore,
scenarios where you’d want the demand dial
interface to be persistent. For example, if the
connection uses a local POTS call or flat-rate
ISDN service where there is no per-minute
charge, there’s no reason why you should not
have the connection persist. If the connection
is dropped, Windows 2000 automatically
attempts to reestablish the connection.
Why not make all connections be on-
demand, even if it doesn’t cost any more for a
given connection to be persistent? Client
access is the primary reason. The amount of
time required to establish a demand dial con-
nection varies depending on the connection
media. A POTS call could take 20 seconds or
more to establish a link, while ISDN could
take less than five seconds.
This is an important consideration when
setting up the demand dial connections—you
need to take into account how the client
applications will handle the connection delay.
If the application supports a variable timeout
setting, modify the timeout setting to accom-
modate the link establishment delay. If
increasing the timeout doesn’t address link
delay in all situations, modify the number of
connection attempts the application makes.
The application’s first attempt will initiate
the connection sequence, and a secondary
attempt will allow the application to connect
after the router has time to establish the
connection.
For all Microsoft Windows platforms, TCP
sets a retransmission timer when it attempts
the first data transmission for a connection.
The initial retransmission timeout value is 3
seconds. TCP doubles the retransmission time-
out value for each subsequent connection
attempt and by default attempts retransmission
two times. For example, the first attempt is
made at 3 seconds, the second at 3+6 seconds,
and the third at 3+6+12 seconds, for a maxi-
mum timeout of 21 seconds. Increasing the
initial retransmission timer to 5 seconds
would result in a total maximum timeout of
5+10+20, or 35 seconds. Setting the retrans-
mission count to 4 with a retransmission timer
44 Administrator’s Guide to VPN and Remote Access, Second Edition
of five would result in a total timeout of
5+10+20+40, or 75 seconds.
You can modify the TCP retransmission
timer properties to extend the length of time
that TCP will attempt a connection before
timing out. For Windows 2000 and Win-
dows NT 4.0 clients, the initial TCP retrans-
mission timeout is set by the registry value
HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\Tcpip\Parame-
ters\InitialRtt. The InitialRtt value is a
REG_DWORD with a valid range from
0-65535 and it specifies the length of the
timeout in milliseconds. A value of 5,000, for
example, specifies an initial timeout of five
seconds. The default value is 3,000.
The number of connection attempts
is defined by the registry setting
HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\Tcpip\Parame-
ters\TcpMaxDataRetransmissions. The
TcpMaxDataRetransmissions value is also a
REG_DWORD with a valid range of 0-65535.
The default value is five.
For Windows 9x and Windows Me clients,
the registry setting MaxConnectRetries speci-
fies the number of times TCP will attempt a
connection. The default is three. As with Win-
dows 2000 and Windows NT, the default value
for the initial connection timer is also three
seconds.
One-way versus two-way demand
dial connections
When you’re setting up a demand dial connec-
tion, you need to consider whether the con-
nection will be one-way initiated or two-way
initiated. In a one-way connection, one router
always functions as the calling router and the
other always functions as the answering router.
In a two-way connection, either router can
function as the calling or answering router.
For both types of connections, the answer-
ing router must be configured with an account
that the calling router can use to establish the
connection. In the case of a two-way connec-
tion, you need to create an account on both
sides of the connection to be used by the
calling router to authenticate on the answer-
ing router. Since either router can initiate a
connection, both need to have accounts the
other can use to authenticate and connect. In
addition, the account name used by the calling
router must match the demand dial interface
name on the answering router—a requirement
for both one-way and two-way connections.
Static routing and autostatic
updates
In addition to authentication considerations,
you also need to think about routing issues.
While you could use dynamic routing (RIP or
OSPF) over demand dial connections, the
routing overhead traffic generated by the
routers could nullify the benefit of using
demand dial connections, including the reduc-
tion of connection charges. This is because the
routers must exchange routing announce-
ments, causing additional periodic traffic and
requiring more frequent connections.
The solution is to use static routes where
the number of routes is small, or use autosta-
tic updates with RIP when the number of
routes doesn’t lend itself to manually created
static routes. In the case of manually created
routes, simply add the static routes to the
appropriate interfaces on both sides of the
connection. Use the option Use This Route
To Initiate Demand Dial Connections to con-
trol whether or not traffic that applies to the
static route causes the demand dial connection
to be initiated.
If the static route directs traffic to a primary
subnet that carries critical traffic, you’ll proba-
bly want the static route to be used to initiate
the demand dial connection. If the traffic is
secondary, deselect this option to prevent the
traffic from initiating the demand dial connec-
tion. In this latter scenario, the traffic will be
routed only if the demand dial connection is
already established (caused by traffic through
another route) and will fail if the demand dial
connection is not active.
Where there are more complex routing
requirements not easily satisfied with manu-
ally created static routes, using RIP with auto-
static updates is a viable solution. Autostatic
updates marry the convenience of RIP with
the connection control of static routes. Auto-
static updates enable RIP to request all
known routes from the remote router and
add them to the local routing table as static
routes. The autostatic update is a one-time,
one-way event, and no additional route
updates occur on the interface until you man-
ually perform another autostatic update or
the local router initiates another scheduled
update. We’ll cover performing autostatic
updates in the next article.
When you’re configuring routes between
your routers, consider the impact that the
default route will have on traffic and the
demand dial interface. Because the default
route is applied to all traffic not serviced by
another route, traffic routed through the
default route could cause unwanted connec-
tions. For example, if you configure the default
route to be used to initiate the demand dial
connection, the connection will dial any time
the traffic is routed through the default route,
including when you have traffic bound for a
nonexistent or unreachable subnet. For that
reason, you should configure the default route
so that it will not initiate the demand dial con-
nection. To do so (or to configure the behavior
for any other route), open the RRAS console,
expand the IP Routing branch, and then select
the Static Routes node. Select the route in
question and display its properties. Deselect
the option Use This Route To Initiate Demand
Dial Connections.
Demand dial filters and time
restrictions
Another issue to consider before you start cre-
ating your demand dial connections is whether
or not you want to apply filters and time
restrictions to the demand dial connections.
In addition to configuring each static route
according to whether or not it can initiate the
demand dial connection, you can control con-
nection initiation through demand dial filters.
These filters let you specify criteria for the
source and destination that determines when
the demand dial interface can be initiated. As
Figure B shows, you can configure the filters to
allow all traffic that fits the filter criteria to ini-
tiate the connection or exclude all traffic fit-
ting the criteria, preventing that traffic from
initiating the connection.
Administration 45
Figure B
Configure demand dial filters to determine which traffic can initiate a demand dial
connection.
Configuring Windows 2000 for demand
dial connections
Dec 28, 2000
By Jim Boyce
I
n the previous article, I introduced you to
demand dial connections in Windows
2000. In this article, I’ll show you how you
actually make the connections.
Getting started
In general, the process involves several steps:
X Enabling demand dial routing
X Setting up remote access on the called
router
X Enabling demand dial connections on the
dial-out hardware
X Creating the connection
X Configuring accounts and authentication
X Adding RIP and/or creating static routes
46 Administrator’s Guide to VPN and Remote Access, Second Edition
Another consideration is when the demand
dial interface can or should be initiated. By
default, there are no dial-out hour restrictions
on a demand dial interface, so traffic that fits
the route or filter criteria can initiate the con-
nection at any time. In some cases, you might
want to restrict those hours. For example, you
might process data transfers only at night and
want the demand dial interface to be used only
during those hours, preventing routing during
the day as a means of controlling traffic or
reducing costs. In the next article, “Configur-
ing Windows 2000 for demand dial connec-
tions,” I’ll show you how you can configure
each demand dial interface with hour restric-
tions to do just that.
X Configuring demand dial initiation filters
X Setting up dial-out hours
X Configuring autostatic updates
X Configuring persistence
X Enabling demand dial routing and
remote access (RRAS)
First, you must enable demand dial routing
for each router that needs to support it. To do
so, open the RRAS console and connect to
that router. In the console, right-click the
server and choose Properties. On the General
page, verify that the Router option is selected
and then select the option LAN And Demand-
Dial Routing. On a called router, also select the
option Remote Access Server and click OK.
Windows 2000 will restart the RRAS service to
accommodate the change.
In addition to configuring RRAS to support
demand dial, you have to configure the dial-out
port to support demand dial connections. In
the RRAS console, expand the server, right-
click on the Ports node, and choose Properties.
Locate the device’s port, click the port, and
choose Configure. Select the Demand Dial
Routing Connections option, and if you also
want to use the device for incoming remote
access calls, select the Remote Access Connec-
tions option as well. Close the dialog boxes
when you’ve finished.
Creating the demand
dial connection
Next, create the demand dial interface. To
begin, install and configure the hardware to be
used for the connection, such as the modem
and ISDN interface. Then, open the RRAS
console, expand the server, right-click Routing
Interfaces, and choose New Demand-Dial
Interface to start the Demand Dial Interface
wizard. The wizard prompts for the following
information:
X Interface Name: Specify the name as it
will appear in the RRAS console. For easy
identification, consider naming the connec-
tion after the remote router. If you’re con-
figuring a demand dial connection for
incoming calls in a two-way connection,
give the interface a name that matches the
account the remote router will use to con-
nect to the local router.
X Connection Type: Choose between a
physical device (modem, ISDN, etc.) or
VPN connection depending on the require-
ments of the remote router.
X VPN Options: If you choose to connect
through a VPN, the wizard prompts for
additional properties. Select the VPN type
as PPTP, L2TP, or automatic selection.
Remember that if you choose L2TP, you’ll
need to configure certificates and filters. If
you choose the VPN option, you’ll also
need to specify the IP address or DNS
name of the remote router.
X Phone Number: For non-VPN connec-
tions, specify the phone number of the
remote router, including alternate numbers
to dial if the primary is unavailable.
X Route IP Packets On This Interface:
Select this option to allow IP routing on the
demand dial interface.
X Route IPX Packets On This Interface:
Select this option to allow IPX routing on
the demand dial interface.
X Add A User Account So A Remote
Router Can Dial In: If you’re configuring
a two-way demand dial interface, select this
option. The wizard will prompt you for the
account properties for the account the
remote router will use to connect to the
local router. The wizard automatically uses
the name specified in the Interface Name
property (the first wizard page) as the
account name and prompts only for the
password for the account. The User Name
field is dimmed to prevent you from chang-
ing the account name.
X Send A Plain-Text Password If That Is
The Only Way To Connect: This option
allows the router to accept plain-text pass-
words if it doesn’t support encrypted pass-
words. This option is dimmed for VPN
connections.
X Use Scripting To Complete The Con-
nection With The Remote Router: Select
this option to enable the local router to use
a script to complete the connection to the
remote router after dialing. You specify the
script after completing the wizard.
After the wizard finishes, you have some
additional configuration to perform. In the
RRAS console, right-click the demand dial
interface you just created and click Properties.
The General page enables you to configure the
dial-up device used by the demand dial con-
nection. The properties are the same as those
you’d configure for a typical dial-out connec-
tion through the Network And Dial-Up Con-
nections folder. If you want to use multilink to
improve throughput, select all appropriate
devices from the Connect Using group. You
Administration 47
 configure additional multilink options through
the Options page.
The Options page shown in Figure A lets you
configure several connection options. In the
Connection Type group, you specify whether
the connection will be on-demand (demand
dial) or persistent. If choosing Demand Dial,
use the drop-down list to specify the idle time
for hanging up. Make sure you specify a length
of time that accommodates normal idle times
during data transmission. Use the Dialing Pol-
icy group to specify the number of redial
attempts and interval between redial attempts.
The Multiple Devices group lets you config-
ure multilink for the demand dial connection.
From the drop-down list, select the method
you want Windows 2000 to use to establish
multilink connections. If you choose Dial
Devices Only As Needed, click Configure
Bandwidth Utilization Parameters to control
dialing and hanging up. Finally, if you need to
use callback or X.25, click the appropriate
button to configure those properties for the
connection.
The Security page is the place to go to con-
figure the authentication method(s) used by the
Figure A
Use the Options page to configure the connection as demand
dial or persistent.
48 Administrator’s Guide to VPN and Remote Access, Second Edition
demand dial connection, and the settings are
just like any other outgoing dial-up connection.
If you need to run a script to complete the
demand dial connection, configure the script in
the Interactive Logon And Scripting group.
The final property page, Networking,
enables you to configure the network services
that the demand dial connection will use,
including network protocols, clients, and
server type. Again, these properties are the
same as for any other outgoing remote access
connection. Configure the settings according
to the requirements for your data transfer. If
the clients use a given protocol, for example,
make sure that protocol is enabled for the dial-
out connection.
Configuring filters and hour
restrictions
Next, you’ll need to configure demand dial fil-
ters to determine which traffic can initiate the
demand dial connection and to restrict (if
desired) the connection to specific hours. First,
open the RRAS console and select the Routing
Interfaces branch. In the right pane, right-click
the demand dial interface you want to config-
ure and choose Set IP Demand-Dial Filters.
Click Add and then specify the criteria based
on source network or destination network (or
both), as well as the protocol. Then, click OK.
Add filters as needed and then select one of
the following options:
X For All Traffic Except: Select this option
if you want all traffic except that falling
under your specified filter criteria to be able
to initiate the connection. All traffic that fits
the filter criteria will not initiate the demand
dial connection.
X Only For The Following Traffic: Select
this option if you want only traffic that
meets the filter criteria to be able to initiate
the demand dial connection.
Click OK when you’ve finished creating
the filters.
Next, configure dial-out restrictions if you
don’t want the demand dial connection to be
available all the time. Right-click the demand
dial interface and choose Dial-Out Hours. Use
the resulting dialog box to select the hours that
the demand dial connection is either permitted
or denied.
Setting up the routes
If the number of routes you need to manage
over the demand dial connection is relatively
high and you intend to use Routing Informa-
tion Protocol (RIP) and autostatic updates to
maintain the routes, you need to add RIP. In
the RRAS console, expand the server, open
the IP Routing branch, right-click General,
and choose New Routing Protocol. Select RIP
and choose OK.
Next, right-click RIP in the IP Routing
branch and choose New Interface. Select the
demand dial connection and click OK. Win-
dows 2000 presents a tabbed property sheet
that is the same as when you configure RIP on
any other routing interface. Verify that autosta-
tic Update Mode is selected in the Operation
Mode drop-down list. The other default set-
tings are correct for connecting to another
Windows 2000 RRAS router. If you need to
tweak the settings to accommodate a different
remote router or your network requirements,
make the changes now.
If the number of routes for the demand
dial interface is low, a better solution than
using RIP is to simply create static routes.
Open the IP Routing\Static Routes node in
the RRAS console, right-click the node (or
right-click in the right pane), and choose New
Static Route. Select the demand dial interface
from the Interface drop-down list and config-
ure the static route as needed.
If you want traffic destined for the selected
route to be able to initiate the demand dial
connection, select the option Use This Route
To Initiate Demand-Dial Connections. Dese-
lect the option if you don’t want traffic des-
tined for the selected route to be able to
initiate the connection. When you’re satisfied
with the static route properties, close the dia-
log box and then repeat the process to create
any other required static routes.
Performing manual and
scheduled autostatic updates
When RRAS performs an autostatic route
update, it deletes the existing routes and then
requests an update from the remote router,
obtaining all remote routes. If the update
request fails for some reason (the remote
router is unavailable, for example), the local
router won’t be able to rebuild its routing table.
This means that the routes will be unavailable
until a successful update occurs. This is one
minor disadvantage to using RIP instead of
static routes for the demand dial interface, but
in most situations it is a manageable risk. Be
sure to take this risk into account when you’re
developing your routing strategy for the
demand dial connection.
When you want to initiate an autostatic
update, open the RRAS console and then
expand the server. Open the IP Routing
branch and then open the General branch.
Right-click the demand dial interface whose
routes you want to update and choose
Update Routes. If the demand dial connec-
tion is currently active, the route transfer will
begin. If not, the local router will initiate the
demand dial connection and then request the
update. Keep in mind that an autostatic update
transfers routing data from the remote router
to the local router. If you’re updating routes in
a two-way demand dial connection, you need
to also perform an autostatic update at the
remote router to update its routes.
The RRAS GUI interface doesn’t provide a
mechanism for scheduling autostatic route
updates to occur automatically, but you can use
the NETSH command from a command con-
sole to update routes. This enables you to cre-
ate a script containing the appropriate NETSH
commands and schedule that script using the
Windows 2000 AT command. Here is an
example of a script that updates the routing
information for a demand dial connection
named RemoteOffice:
netsh interface set interface
name=RemoteOffice connect=CONNECTED
netsh routing ip rip update
RemoteOffice
netsh interface set interface
name=RemoteOffice
connect=DISCONNECTED
You can also create a script for NETSH and
execute that script through the NETSH com-
mand. For example, save the previous commands
Administration 49
 to a text file called RemoteUp.scp. Then, run the
following command to execute the script:
netsh -f RemoteUp.scp
Setting up a two-way demand
dial connection
Up to this point, I’ve primarily focused on set-
ting up a one-way demand dial connection.
Setting up a two-way connection is essentially
the same, except you perform the configura-
tion tasks at both ends of the connection.
You’ll need to configure the hardware, set up
the connection, configure routes, and perform
the other tasks explained above.
One of the most potentially confusing
aspects of two-way demand dial connections is
the naming convention you use on both
routers. Remember that when you’re naming
the connections each connection’s name
should be the same as the connection authenti-
cation account on the remote router.
How to configure Win2K client
VPN connections
Nov 28, 2000
By Erik Eckel, Network+, MCP+I, MCSE
I
ncreasingly, network administrators are
turning to virtual private networking
(VPN) connections to link remote workers
to LANs. Windows 2000 includes VPN func-
tionality, and even if you’re not using VPNs at
your organization, you’ll need to be familiar
with Win2K’s VPN feature if you’re planning
on sitting for any of the following exams:
X Exam 70-210—Installing, Configuring,
and Administering Microsoft Windows
2000 Professional
X Exam 70-215—Installing, Configuring,
and Administering Microsoft Windows
2000 Server
50 Administrator’s Guide to VPN and Remote Access, Second Edition
For example, assume you have two routers
in two locations. At your Headquarters loca-
tion, you have a router with an interface name
of RemoteOffice. At your remote location,
you have a router with an interface name of
HomeOffice. Therefore, to make the connec-
tion work properly you should create a user
account at Headquarters with a user account
name of HomeOffice, as well as a user
account at the remote site with a user account
name of RemoteOffice.
Conclusion
Demand dial connections make it easier for
you to use routing to connect networks with-
out having a permanent connection between
them. Windows 2000 lets you create demand
dial connections with a little bit of work. In
this article, I’ve shown you how.
X Exam 70-216—Implementing and Admin-
istering a Microsoft Windows 2000 Net-
work Infrastructure
Why a VPN?
VPNs have caught on quickly primarily for the
following two reasons:
X VPNs permit employees to connect to
office resources from home or other loca-
tions using common hardware.
X VPNs provide secure connections.
By using tunneling protocols, such as PPTP
or LT2P, secure connections can be config-
ured between a client’s laptop or home
machine and a company’s LAN, as diagramed Figure A
in Figure A.
The Windows 2000 Network Connection
Wizard offers two methods for connecting to
private networks. The Network Connection PSTN
Wizard can be reached by clicking Start | Set-
tings | Network And Dial-up Connections |
Make New Connection from within Windows
Computer
2000 Professional. The method you select will
Server
depend largely on the telecommunications
technology you have in place.
You should select Dial-Up To Private Net-
work if you plan to use a traditional 56Kbps
modem or ISDN connection. You should
select Connect To A Private Network Through Laptop
The Internet if you wish to use a preexisting VPNs use tunneling protocols to create secure connections through the Public Switched
Telephone Network.
Internet connection. Most likely, if you’re
using a cable modem or a DSL connection,
you’ll choose this option. Figure B
Creating a dial-up VPN
connection
Dial-up VPN connections are created by
selecting Dial-Up To Private Network from
the Network Connection Wizard, as shown in
Figure B.
The wizard will then prompt you to supply
the telephone number of the computer or net-
work you wish to call. If you’re installing the
VPN link on a laptop, you may wish to check
the Use Dialing Rules box. Doing so enables
you to configure different dialing configura-
tions depending upon your location.
Next, you’ll need to specify whether the
connection will be used only by yourself or by
all users of the machine upon which it’s being
installed. Select the default, For All Users, if
everyone using the workstation should have Select Dial-Up To Private Network to begin creating a dial-up VPN connection.
access to the VPN connection. Select Only For
Myself if you wish to make the connection
available only for your user logon. Should you need to change the telephone
Provide a name for the VPN connection number or other settings associated with the
and select Finish to complete the process. If VPN connection, you can do so easily. Just
you wish to create a shortcut for the dial-up click Start | Settings | Network And Dial-Up
VPN connection on your desktop, be sure to Connections, right-click the dial-up connec-
check the Add A Shortcut To My Desktop tion you wish to configure, and select Proper-
box. To connect to the remote system, select ties. Figure C shows the Dial-Up Connection
the connection from Start | Settings | Net- Properties dialog.
work And Dial-Up Connections.

Administration 51
 Creating a tunneled connection
If you need to create a VPN connection using
a cable or DSL modem, a LAN, or a WAN
connection, in the Network Troubleshooting
Wizard you’ll want to select Connect To A
Private Network Through The Internet. The
wizard will ask you whether an initial call
needs to be placed. If it does, select Automati-
cally Dial This Initial Connection and supply
the name of the connection you wish to have
dialed from the provided drop-down box. If
no initial connection is required, select Do
Not Dial The Initial Connection and click the
Next button.
Provide the host name or IP address of the
computer or network to which you want to
connect. You can supply the host name in the
form somehostname.com, substituting the
appropriate name, of course. Or, you can enter
the IP address of the machine you wish to
contact, such as 192.168.1.1. Click Next.
Just as with a dial-up connection, you’ll be
asked whether the connection is to be used
only by yourself or by all of the system’s
accounts. Select the appropriate option and
Figure C
A variety of settings can be configured for dial-up connections
from the Properties box. For example, you can specify (or
change) the modem to use by clicking Configure.
52 Administrator’s Guide to VPN and Remote Access, Second Edition
click Next. Supply a name for the connection,
indicate whether you wish to add a shortcut to
the desktop, and click Finish.
To connect, double-click the shortcut—if
you chose to create one—or select the connec-
tion from Start | Settings | Network And
Dial-Up Connections. Supply your user name
and password for the network you wish to
access (see Figure D), and you’re ready to begin
enjoying the benefits of secure, remote access.
If you want to edit the settings for the con-
nection, you can do so easily. Just right-click
the connection name and select Properties.
Here you can modify TCP/IP settings, the IP
or host name of the computer to which you
wish to connect, and other configuration
information.
Several other options can be configured
using the tabs in your connection’s Properties
dialog, including:
X Whether you wish to have connection
progress displayed.
X Whether data encryption is automatically
required.
Figure D
You’ll need to supply your networking user name and
password for authentication purposes.
X Which networking components are used by
the connection (such as TCP/IP, Client for
Microsoft Networks, etc.).
X The type of VPN server being called (you
can specify Automatic discovery, Layer-2
Tunneling Protocol [L2TP], or Point-to-
Point Tunneling Protocol [PPTP]).
Other options you can configure include
whether the connection appears in the Taskbar
when it’s in use, whether to include your Win-
dows logon domain when connecting, and
whether Internet Connection Sharing should
be enabled for the connection.
Windows 2000 includes a VPN functional-
ity that is more robust and clearer than previ-
ous versions of Windows. Given that more
and more companies are turning to VPNs for
security reasons, you’ll want to understand
how to configure this networking option.

USE IP FORWARDING IN WINDOWS 2000 PROFESSIONAL

IP forwarding in Windows 2000 enables a Windows 2000 computer to forward IP packets. For example, a dial-
up server that enables remote users to also access the network uses IP forwarding to forward that traffic. IP
forwarding allows Windows 2000 to, in effect, act as a router. In fact, Windows 2000 Server’s Routing and
Remote Access Service (RRAS) enables a Windows 2000 Server computer to function as a full-fledged router,
complete with support for RIP, OSPF, and other routing protocols.
Enabling IP forwarding is a relatively simple matter on a Windows 2000 Server computer—you just run the
RRAS wizard in the RRAS console. Enabling IP forwarding on a Windows 2000 Professional computer isn’t as
intuitive, but it’s actually easier than on a server, thanks to a simple registry edit. (It’s easier still in Windows NT,
requiring only a change to a check box in the TCP/IP properties.)
1. Open the Registry Editor and then open the branch HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Tcpip\Parameters.
2. Look for the setting IPEnableRouter.
3. Set the value to 1 to enable IP routing on all the computer’s interfaces.
Note: As always, we’ll remind you that registry editing can be risky, so be sure you have a verified backup
before you begin.

Setting up a VPN with Windows 2000

Oct 18, 2000
By Jason Hiner, MCSE, CCNA

H
ave you heard about the magical ben-
efits of the virtual private network?
Are you ready to test its merits in
your remote access infrastructure? If so, you’ll
be happy to hear that Windows 2000 provides
an excellent VPN platform, especially for con-
necting small remote offices and supporting
telecommuters from their home offices. You’ll
be amazed at how easy the basic setup of a
VPN has become with Windows 2000. At the
same time, Win2K offers dramatic improve-
ments in functionality and security over the
bare bones VPN of Windows NT.
In this article, we’ll examine what hardware
and software you’ll need for your VPN, explain
how to configure a VPN server on your cor-
porate network, and show you how to config-
ure telecommuters to make a VPN connection

Administration 53
 to the corporate LAN. We’ll focus on the
basics of VPN setup, but we won’t touch on
advanced topics, such as setting up a server-to-
server VPN with a remote office network, set-
ting up Remote Access Policies, or configuring
your VPN connection to pass through fire-
walls and proxy servers. With this in mind, let’s
get started on configuring your Windows 2000
remote access VPN.
Preparing the infrastructure
The first thing you need to consider is the
hardware requirements for your VPN server.
Remember that Windows 2000 by itself
requires substantial hardware resources. In an
enterprise environment, you will want your
VPN server to be a dedicated server with
nothing but Windows 2000 Server or Win-
dows 2000 Advanced Server running on the
machine. For this configuration, I would rec-
ommend at least a 450-MHz Pentium III with
at least 256 megabytes of RAM. For a small
business or branch office with fewer than 100
users and fewer than 20 remote access connec-
tions, you can use a 300 MHz (or better) Pen-
tium II or Celeron machine with at least 128
megabytes of RAM.
Your server will need to have two network
cards. One card will connect to the Internet
and the other will connect to the local area net-
work. As you’ve probably realized, this means
your VPN server is actually functioning as
more of a VPN router than as a server. It
authenticates the users, creates the secure tun-
nel, and then, like any router, allows users to
access resources on the subnet to which they
are connecting or to another subnet, based on
routing tables. Keep in mind that this can
include non-Windows resources such as Net-
Ware and UNIX servers.
The final major consideration is your Inter-
net connection. Using a VPN server can mean
that you’ll be able to get rid of many of your
phone lines that are currently dedicated to
RAS. However, in one sense, this is robbing
Peter to pay Paul because you’ll probably need
to consider increasing the Internet bandwidth
at your corporate office. This will depend on
how much bandwidth you have to begin with,
what your current utilization is, and the num-
54 Administrator’s Guide to VPN and Remote Access, Second Edition
bers of users and remote offices that will be
connecting to your VPN server. Also, VPN
works best if you have an always-on Internet
connection at your corporate network. If you
have a dial-up Internet connection, the only
VPN solution I would recommend would be a
server-to-server connection between your cor-
porate office and a remote office.
Configuring the VPN server
Once you’ve dealt with the hardware issues,
you need to install Windows 2000 Server and
the latest Service Pack on your machine. Make
sure you don’t install other unnecessary serv-
ices, such as DNS, DHCP, and IIS. Also avoid
loading any additional third-party software,
except for things that are absolutely necessary
such as backup agents.
During installation, you should choose to
statically assign IP addresses. You’ll need to set
up one network card with a true Internet IP
address and the default gateway of your Inter-
net router. The other network card should have
an IP address assigned to the local network,
and it should not contain a default gateway.
You’ll also need to set the domain/work-
group for your VPN server. This setting will
depend on how you decide to do authentica-
tion. There are three basic options: The VPN
server can authenticate users locally, you can
use Windows 2000 domain security, or you can
pass authentication to a RADIUS server. If
you have the VPN server authenticate users
locally, you’ll want to set up a workgroup just
for the VPN server—something like “Inter-
net.” If you want to use Active Directory and
have a Windows 2000 domain controller han-
dle authentication, have the VPN server join a
Windows 2000 domain. If you’re going to
have a cluster of VPN servers, you may want
to use a RADIUS server (such as Microsoft’s
Internet Authentication Service) to perform
VPN authentication. In this example, we’ll
have the VPN server authenticate users locally.
Once you have Windows 2000 Server
installed, go to Start | Programs | Administra-
tive Tools | Routing And Remote Access to
pull up the RRAS Microsoft Management
Console, shown in Figure A. Then, click on the
icon with the name of your server and click
Action | Configure And Enable Routing And Figure A
Remote Access. This will launch a wizard that
sets up a new server. Select Manually Config-
ured Server, which will take you into RRAS to
begin your configuration. You may be tempted
to select the VPN option in the wizard, but
please control yourself. The VPN wizard is still
a little quirky, and it’s much better to configure
the few basic VPN settings in RRAS manually
so you’ll know how to troubleshoot and tweak
them in the future.
Start the configuration by right-clicking on
the icon with the name of your VPN server
and selecting Properties. This will bring up the
main options you’ll use to activate your VPN
server. In the General tab, shown in Figure B,
make sure that you have checked the Router
and Remote Access Server selections and that
the LAN And Demand-Dial Routing option is RRAS Microsoft Management Console

selected under Router. Switch to the Security

tab and select Windows Authentication if the
VPN server is doing its own authentication or
if you’re using a Windows domain for authen-
tication. If you’re using a RADIUS server,
choose RADIUS Authentication. As for PPP
and Event Logging, you can leave the default
settings or tweak them to your preferences.
The settings in the IP tab, shown in Figure C,
are very important. You’ll want to check
Enable IP Routing and Allow IP-based
Remote Access And Demand-Dial Connec-
tions, and then configure IP Address Assign-
ment for DHCP or assign a static address pool
(in the subnet you want clients to connect on).
Set the Adapter option to the adapter that con-
nects to your LAN. The settings in the IP tab
are crucial because they regulate the IP and
network information that incoming VPN

Figure B Figure C

General tab in the Properties dialog box Settings in the IP tab

Administration 55
 clients will receive. In most cases, I would rec-
ommend using DHCP to assign IP informa-
tion to your VPN clients. This is especially
effective when using the same DHCP server
that clients on your LAN use to receive their
IP information. VPN users can also receive
static IPs, as you will see when we get to client
configuration.
After completing the VPN server proper-
ties, there are only a few more settings to con-
figure. If you did opt to use DHCP, you’ll need
to right-click on DHCP Relay Agent (a con-
tainer under IP Routing), select Properties, and
add the IP address of the DHCP server(s) for
your local area network.
After that, right-click on Ports and select
Properties, and you should see the default con-
figuration of 5 PPTP ports, 5 L2TP ports, and
1 Parallel port, as shown in Figure D.
You can leave the default Parallel port alone,
but you can double-click on the PPTP and
L2TP ports and configure the number of
ports you need for these protocols. You want
to make sure that there are enough ports for all
of your users and remote servers, but you
don’t want to enable more ports than you
need. Keep in mind that Windows 2000 Pro-
fessional is currently the only client that sup-
Figure D
The Ports Properties dialog box
56 Administrator’s Guide to VPN and Remote Access, Second Edition
ports L2TP, so most clients will connect using
PPTP. While L2TP is destined to become the
new standard in VPN, this article will focus on
making connections using the simpler and
more universal PPTP protocol.
Configuring remote clients
You have now completed all of the basic steps
for preparing a VPN server on your corporate
network. Now, let’s take a look at how to con-
nect a remote client. In this example, I’ll focus
on the best VPN client, Windows 2000 Profes-
sional. You can also make good VPN connec-
tions with Windows NT 4.0 and Windows 98,
but they aren’t nearly as fast or as functional as
Win2K Pro. However, before any client can
connect to your VPN server, you need to pro-
vide their user account with remote access
permission.
If your VPN server is authenticating users
locally, set up user remote access permissions
by going to Start | Programs | Administrative
Tools | Computer Management | Local Users
And Groups | Users and double-clicking a
user (or creating a username) that you want to
enable for remote access. Next, select the
Dial-In tab and then select the Allow Access
option, as shown in Figure E. As you get more
advanced with VPN, you can select Control
Figure E
Options in the Dial-In tab
Access Through Remote Access Policy and
use Remote Access Policies for greater control
and security. The Dial-In tab also lets you set
up users to receive a static IP address, rather
than receiving their IP information from
DHCP when they connect.
On a Windows 2000 Professional machine
with an Internet connection, connecting to a
corporate VPN server is simple. First, click
Start | Settings | Network And Dial-up Con-
nections | Make New Connection. Click Next
to begin the wizard, and then select Connect
To A Private Network Through The Internet.
At the next prompt, you’ll need to specify how
to connect to the Internet. If you have an
“always-on” connection, such as a DSL or
cable modem, choose Do Not Dial The Initial
Connection. If you have a dial-up connection,
choose Automatically Dial This Connection
and select your Internet dial-up connection
from the list. Now, you’ll need to select your
destination address, which will be the fully
qualified domain name or IP address of your
VPN server. Choose whether the connection
will be accessible for all users or only for your-
self. Then, name the connection (I suggest
something like Office VPN) and click Finish.
Now, when you open Network And Dial-up
Connections, you’ll notice the Office VPN
icon, as shown in Figure F.
Figure F
The Network And Dial-up Connections window
Right-click on the Office VPN icon and
click Properties. This will bring up your client
VPN options, which you’ll use to troubleshoot
and adjust settings in the future. Now you can
double-click the Office VPN icon to display a
login screen, shown in Figure G. Enter a user-
name and password for a user who has remote
access permission and click Connect. If you
have an always-on Internet connection, this
should bring up a dialog box to follow along
with the authentication steps. If you have a
dial-up connection, you should see the dial-up
connection triggered first (you may have to hit
Connect for that one and then hit Connect
again for the VPN connection), and then you
will see the dialog box showing the VPN
authentication process.
Summary
This article has provided a primer for setting
up a VPN using Windows 2000. We’ve
focused on VPN as a remote access solution
for telecommuters, but the scope of VPN in
Windows 2000 extends far beyond the basic
concepts reviewed here. If you’re ready to
pilot a Windows 2000 VPN in your enterprise,
I recommend further study on VPN concepts
and troubleshooting by consulting Microsoft’s
VPN Web site (http://www.microsoft.com/
serviceproviders/vpn_ras/default.asp).
Figure G
The Office VPN login screen
Administration 57
 Issues surrounding a Windows 2000
VPN implementation
Nov 28, 2000
By Talainia Posey
I
f your business has multiple locations,
there’s a good chance that sooner or later
someone will ask you to link the various
locations’ computer systems together. When
taking on such a task, you have a couple of
options. One option is to use a leased line,
such as a T-1 line, to connect the facilities.
Leased lines typically cost big money, however.
If a leased line is out of your league, another
option is to create a virtual private network. In
this article, I’ll discuss some of the issues you’ll
face when implementing a virtual private net-
work in a Windows 2000 environment.
What’s a virtual private
network?
Virtual private networks (VPNs) are often
misunderstood. It seems that these days, prac-
tically everyone is selling a VPN solution, and
they’re all different. For example, you can buy
VPN solutions from router manufacturers and
firewall vendors. Likewise, there are pure
hardware VPN solutions and VPNs that are
part of your network operating system, as in
Windows 2000.
Each of these solutions works differently.
Some of these solutions conform to the stan-
dards of a true VPN, and others don’t.
Because of the variety of virtual private net-
working solutions, I’ll begin by discussing vir-
tual private networking from the standpoint of
a generic VPN solution. Once I’ve covered the
basics of how VPNs function, I’ll discuss
implementing a VPN in a Windows 2000
environment.
To understand how a VPN works, let’s
assume you’ve been asked to link two corpo-
rate networks together, but a dedicated leased
line is too expensive. Instead, you’ve thought
about using a VPN. In its purest form, a VPN
is nothing more than a method for joining two
private networks together by passing data
packets between the two networks through
one or more third-party networks.
58 Administrator’s Guide to VPN and Remote Access, Second Edition
The most common example of a VPN is a
situation in which two networks exchange data
through the Internet. For example, suppose a
user in Las Vegas needed to access a file from
a server in Miami. If the two networks were
linked through a VPN, the user could access
the needed file just as though the Miami server
were sitting in the next room. The end user
would be totally oblivious to the fact that the
file was passing through the Internet to get to
the Las Vegas office.
Issues to consider
At first, the idea of passing files across the
Internet may not seem like that big a deal.
After all, we all exchange files through e-mail
everyday. However, VPNs work differently
than e-mail servers. In an e-mail environment,
it’s up to a user to send specific files to some-
one else. In a VPN, however, any user with the
appropriate permissions may access any file on
the network without the need for someone to
send the files to them. To a user on a VPN, the
remote servers look and act as if they are on
your LAN.
If you stop and think about it, this means
that your servers are totally exposed to Internet
users. That’s a very scary thought when you
consider the insecure nature of the Internet.
Because the Internet is full of people with
questionable intentions, it’s necessary to pro-
tect your servers. This is where the word “pri-
vate” in virtual private networks comes in.
VPNs are designed so that only registered net-
work users may access your network. In a Win-
dows 2000 environment, this is accomplished
by using a combination of different protocols
and encryption methods. I’ll discuss the
specifics of Windows 2000 VPN security a
little later.
When it comes to virtual private network-
ing, performance and reliability are just as
important as security. After all, what good is
security if you can’t even access your own
data? When it comes to virtual private net- widely supported, PPTP is being slowly
working, the issues of performance and relia- replaced by IPSec-based VPNs. To help you to
bility can be summed up in a single sentence decide which protocol is right for your VPN
that I can’t stress enough: Your VPN is only as installation, I’ll discuss the two protocols in
good as your Internet connections. detail and then compare the two.
To understand why this is so true, consider
how a Windows 2000-based VPN works.
Point-to-Point Tunneling Protocol
PPTP was the original VPN protocol
When packets are destined for a remote loca-
Microsoft introduced. Many forms of Internet
tion, the packets are encrypted and encapsu-
communications use the PPP (Point-to-Point)
lated inside a protocol that’s specifically
protocol. PPTP is merely an extension of PPP.
designed to move the packets safely across the
I mentioned earlier that VPNs rely heavily
Internet. Because of the encryption and
on encapsulation. The way the Windows 2000
encapsulation techniques being used, packets
PPTP implementation works is that standard
flowing across a VPN tend to be larger than
network packets are encapsulated inside PPTP
packets flowing across a conventional network.
packets. The PPTP packets are then passed
A significant amount of bandwidth is required
across the Internet. The advantage of using
for moving these larger packets. Now consider
this method is that it works regardless of the
your Internet connection. Browsing the Web
protocol being used on your corporate net-
involves a relatively small amount of data
works. For example, suppose that your corpo-
exchange. If your Internet connection is too
rate networks use IPX/SPX. If a packet was
slow to comfortably surf the Web, what will
destined for the remote network, the IPX/
happen when you flood the connection with
SPX packet would be encapsulated inside a
VPN packets? I’ll give you one guess.
PPTP packet.
To build an effective VPN, your Internet
When the remote VPN server receives the
connection should be as fast and reliable as
PPTP packet, it recognizes the packet as a
possible. Keep in mind that this rule applies to
PPTP packet and allows the packet to pass
both offices. After all, your VPN is only as fast
through the firewall (assuming that you’ve
as the slowest Internet link involved. There-
opened the appropriate firewall port). Once
fore, if the Las Vegas server from my earlier
the packet gets past the firewall and reaches
example has a T-3 connection, but the Miami
the VPN server, the PPTP shell is stripped
server has only an ISDN link, then your VPN
away. At this point, the remaining data is a true
will be limited to ISDN speeds.
IPX/SPX packet. The IPX/SPX packet con-
Technically, a VPN will work with slow
tains all the usual information, such as the
Internet connections, but you’ll almost have to
sender and recipient. The packet is then placed
use some form of broadband communications
onto the network where it will reach the desti-
to build your VPN. If you’re limited to using
nation PC in the usual manner.
analog modems, communications are faster
and infinitely more secure if the two servers IPSec
dial each other directly rather than having the IPSec is the first standards-based VPN proto-
packets pass through the Internet. The only col. IPSec is actually a collection of several
downside to such an arrangement would be services and protocols that are designed to col-
the charges for the long distance phone call. lectively provide comprehensive security. In a
The slowest practical connection I’ve seen suc- virtual private networking environment, IPSec
cessfully used for a VPN involved using a 128- provides the mechanism through which the
Kbps ISDN link with a static IP address. data is encrypted and decrypted.
While IPSec itself is responsible for estab-
Windows 2000 VPN security lishing a secure connection between the two
There are two protocols you can use for Win-
private networks, Microsoft’s implementation
dows 2000 VPNs. The first is Point-to-Point
takes security a step further. It uses a mecha-
Tunneling Protocol (PPTP). Although still
nism called L2TP (Level-2 Tunneling Protocol)

Administration 59
 to better encrypt things like usernames, pass-
words, and data.
Not only does IPSec offer the encryption
services necessary for VPNs, it also prevents
hackers from launching a replay attack against
either network by being “replay proof.” A
replay attack is the process by which hackers
capture packets and then replay them in order
to gain access to a network. IPSec guards
against replay attacks by associating a
sequence number with each packet. If the
recipient receives a packet with a sequence
number that’s already been received, the
packet is assumed to be fraudulent and is
therefore discarded.
Comparing PPTP and IPSec
Now you know a little bit about how both
VPN protocols work. Before you can truly
make an informed decision about which pro-
tocol is right for your network, however, it’s
necessary to understand the differences in the
two protocols.
In a nutshell, IPSec is a standards-based
protocol that runs on a variety of operating
systems, such as Windows, Macintosh, and
Linux. IPSec uses DES/3DES encryption
and supports header compression. IPSec has
Setting up a Windows 2000 virtual
private network
Dec 26, 2000
By Talainia Posey
I Installing a VPN
n “Issues surrounding a Windows 2000
VPN implementation” (page 58), I dis-
cussed some of the primary issues you
should consider when building a virtual private
network (VPN). These issues include such fac-
tors as security, reliability, and cost. In this arti-
cle, I’ll describe the process of installing a
VPN. I’ll also cover some additional issues
you’ll face during the installation process.
60 Administrator’s Guide to VPN and Remote Access, Second Edition
minimal requirements for the network media
since it requires only packet-based point-to-
point connectivity.
PPTP, on the other hand, is a proprietary
protocol designed by Microsoft to run on
Windows and Linux platforms. It uses a pro-
prietary encryption algorithm designed by
Microsoft and doesn’t support header com-
pression. PPTP also requires that the transit
network support the IP protocol.
So which protocol is right for you? It
depends on your network. If you’re adding an
extra site to an existing Windows-based VPN,
then it may be wise to stick with PPTP. If
you’re building a brand-new VPN that’s purely
Windows 2000 or that uses non-Microsoft/
Linux VPN servers, however, IPSec is the pro-
tocol of choice.
Conclusion
In this article, I discussed some of the issues
involved in creating a VPN in a Windows 2000
environment. As I did, I addressed typical con-
cerns, such as cost, security, and reliability. In
the next article, I’ll discuss the actual process
of setting up a VPN.
Before we begin creating a VPN, let’s review the
basic requirements. On one end of the VPN,
you have a client. This client may be a remote
network or a remote user. On the other end of
the VPN, you have the host. The host is a Win-
dows 2000 server that functions as a router
between the Internet and the private network.
 The server that’s functioning as a router
should have a permanent Internet connec-
tion, such as the type provided through a
leased line. It is possible to implement a VPN
even if the host relies on a dial-up connection
to the Internet. However, I highly discourage
using a dial-up connection. That’s because
even if you can manage to stay dialed in 24
hours a day, 7 days a week, most Internet
service providers assign dynamic IP addresses
to dial-up users. This means the host router
would likely have a different IP address every
time it connects to the Internet. As you can
imagine, it would be very difficult for remote
clients to connect to the host if the host’s IP
address keeps changing.
With that said, let’s look at the process for
configuring the host router to provide VPN
capabilities. For the purpose of this article, I’ll
work through the process of joining two net-
works through a VPN. As such, both of the
Windows 2000 servers involved in the process
function as hosts and clients. The dual func-
tionality of each machine allows VPN traffic
to flow in both directions. This arrangement
allows the free exchange of data between the
two networks.
Begin the configuration process by clicking
the Start button and selecting Programs |
Administrative Tools | Routing And Remote
Access. When the Routing And Remote
Access console appears, right-click on the host
server and select the Enable Routing And
Remote Access command from the context
menu. When you do, you’ll see the Routing
And Remote Access Server Setup Wizard. On
the initial wizard screen, click Next to begin
the installation process.
The resulting screen gives you the choice of
several types of routing and remote access.
Even though this server will function as a
VPN router, don’t select VPN just yet. Instead,
select Manually Configured Server and click
Next. The resulting screen will display a sum-
mary of the configuration you’ve chosen. Click
Finish to close the wizard.
When you complete the wizard, Windows
will ask if you want to start the Remote
Access Service. Click Yes, and the service will
be started. If you’ve ever created a remote
access server under Windows NT 4.0, you’ll
notice (and appreciate) the fact that Windows
2000 doesn’t require you to reboot the server.
When the service starts, you’ll see there are
several configuration options available in the
Routing And Remote Access console, as
shown in Figure A.
At this point, right-click on Routing Inter-
faces, and then select the New Demand Dial
Interface command from the context menu.
When you do, Windows 2000 will launch the
Demand Dial Interface Wizard. Start by click-
ing Next. Now, the wizard will ask you for the
name of the interface you’re configuring. Many
people choose to name the interface after the
network it’s attached to or after the function
the interface will provide. For example, you
might call the interface VPN Interface. Once
you’ve entered the name of the new interface,
click Next.
Now, Windows will ask you what type of
demand dial interface you want to create.
Select the Connect Using Virtual Private Net-
work (VPN) radio button and click Next.
The next screen the wizard displays asks for
the type of VPN interface you want to create.
The choices are PPTP, L2TP, or Automatic
Selection. The type of VPN interface you cre-
ate is really up to you. Microsoft recommends
using L2TP for new VPN installations. So, let’s
use L2TP for the purpose of this article.
At this point, you’ll see a screen that asks
for the IP address or host name for the remote
Figure A
The Routing And Remote Access console will contain many
more options after you’ve enabled the Remote Access Service.
Administration 61
 VPN router. As you probably know, the host
name is the remote machine’s registered DNS
name. Therefore, in the space provided you
can enter an IP address, such as
147.100.100.34, or a host name, such as techre-
public.com. Click Next to continue.
After you’ve entered the host name or IP
address of the remote router, you’ll see a
screen similar to the one shown in Figure B.
This screen asks what type of packets you plan
on routing across the VPN link. Again, the
selections you make will greatly depend on
your individual network. As you can see in the
figure, I’ve chosen to allow IP packets but to
disallow IPX packets. I’ve also chosen to create
a remote access user account and password so
that it’s possible for the remote router (or
remote users for that matter) to access the net-
work through the VPN. When you’ve made
your selections, click Next.
Now, assuming you’ve allowed dial-in
access, the wizard will display a screen that
asks for some dial-in credentials. At first, this
screen may be a bit deceptive. It’s easy to acci-
dentally assume this screen is designed to give
access to dial-in users. However, its purpose is
to establish a user name and password that can
be used to validate the remote router when it
tries to connect. After all, you don’t want just
Figure B
Select the types of data you’ll allow to flow across your VPN link.
62 Administrator’s Guide to VPN and Remote Access, Second Edition
anyone who knows your host name or IP
address to build a VPN that allows access to
your network.
On this screen, the wizard will be set to
automatically create a user account that uses
the same name as the interface you’re creating.
For example, if you named your interface
VPN Interface, then the user account will also
be called VPN Interface. Although this screen
won’t allow you to change the user name, you
can enter a password for the user account.
Once you’ve entered and confirmed the
account’s password, click Next to proceed.
The resulting screen gives you a chance to
enter the credentials for connecting to the
remote network. Remember that when you
join two networks through a VPN, both net-
works must be protected. This means you’ll
have a separate VPN user name and password
for each network. Each VPN router must be
set up to know the authentication information
for the remote VPN router it will connect to.
Simply fill in the domain name, user name,
password, and password confirmation for the
remote router. When you’ve entered this
information, click Next.
You’ve now finished configuring your VPN
router. Click Finish to complete the process.
Remember that you must configure both
routers before your VPN will work.
Cleaning house
Now that you’ve created a VPN, there are a few
things you need to do to ensure that your net-
work is secure and that your VPN is functional.
Remember that each VPN router is connected
to the Internet. There are countless Internet
users with malicious intent who would just love
to get their hands on your network.
Although the VPN link you’ve just created
is secure, there are other ways to get into your
network from across the Internet. Typically,
hackers exploit unused TCP/IP ports. There-
fore, I strongly recommend implementing IP
packet filtering in a way that will block all
inbound Internet traffic except for VPN traffic
(and any other types of traffic you might
require).
IP filtering is a science in and of itself.
Therefore, it’s impossible to thoroughly discuss
IP filtering in the amount of space I have to
work with. I can, however, show you the basic
technique.
To enable IP filtering, go to Control Panel
and double-click the Network And Dial Up
Connections icon. Now, right-click on your
Internet connection and select the Properties
command from the context menu. Next, select
Internet Protocol (TCP/IP) from the list of
installed components and click the Properties
button.
When you do, you’ll see the Internet Proto-
col (TCP/IP) Properties sheet. Click the
Advanced button to view the advanced
TCP/IP properties. On the Advanced TCP/IP
Properties sheet, select the Options tab. Now,
select TCP/IP Filtering and click the Proper-
ties button. You can then use the resulting dia-
log box to enable or disable various TCP/IP
ports. It’s important to point out, however,
that in Windows 2000, it’s impossible to filter
TCP/IP on one adapter but not another. If
you filter TCP/IP on one adapter, you’ve fil-
tered TCP/IP on all the adapters.
Introducing Windows 2000 Routing
and Remote Access
Oct 20, 2000
By Jim Boyce
M
icrosoft introduced Remote Access
Services (RAS) early in the Windows
NT product cycle, adding routing
capability through an add-on service for Win-
dows NT. Windows 2000 integrates these
services in a single Routing and Remote
Access Service (RRAS) that provides excellent
utility for routing, remote access, and integra-
tion with other Windows 2000 services, as
well as third-party platforms. In this article, I’ll
take a look at RRAS in Windows 2000 Server,
The other task you must complete is to
exchange route information between the
routers and test the VPN link. To do so,
return to the Routing And Remote Access
console and navigate to Server | IP Routing |
General. Next, right-click on the demand dial
interface and select the Update Route com-
mand from the context menu.
Now, perform this task on the other router
as well. To make sure that the route exchange
worked, go to the Routing And Remote Access
console’s IP Routing | Static Routes section.
The routes you created should be visible. You
should now be able to ping each router from
the other router.
Conclusion
In this article, I’ve explained how to imple-
ment a VPN. As I did, I discussed some
issues you may encounter during the imple-
mentation phase.
starting with an overview of what the service
can do.
Overview of Windows 2000
RRAS
Remote Access Services (RAS) enables a Win-
dows 2000 computer to dial and access remote
networks, the Internet, and even individual
servers or client workstations. RAS is the
mechanism you use, for example, to dial out
from a Windows 2000 computer to access an
Administration 63
 Internet service provider or a remote LAN.
Windows 2000 RAS supports several connec-
tion options including modem, ISDN, infrared
connections, parallel and serial port direct con-
nections, X.25, and asynchronous transfer
mode (ATM). Windows 2000’s support for tun-
neling protocols, such as PPTP and L2TP,
enables clients to establish a secure connection
to a remote network through a public network
such as the Internet.
The RAS component in Windows 2000
also enables a computer running Windows
2000 Server to function as a dial-up server,
allowing clients to dial into the server to
access local server resources, such as files and
printers. Depending on the configuration of
the server, clients can also gain access to the
network on which the server resides, accessing
LAN resources just as if the client were con-
nected locally to the LAN. Windows 2000
Server supports an unlimited number of con-
current connections, subject to hardware con-
siderations such as server capacity, number of
physical connections (available modems, for
example), and so on. Windows 2000 Profes-
sional computers can also serve as RAS
servers but only for one connection at a time.
A Windows 2000 remote access server sup-
ports the same connection options for incom-
ing connections as the outgoing connection
options mentioned previously. You can also
use Windows 2000 RRAS to support incom-
ing Terminal Services client connections.
Windows 2000 RRAS also enables a Win-
dows 2000 server to function as a router. Win-
dows 2000 RRAS supports both unicast and
multicast protocols, as well as packet filtering,
connection sharing, demand-dial routing, and
encrypted authentication for secure router-to-
router connections. A key advantage to using
Windows 2000 RRAS for routing services is its
integration with other Windows 2000 services,
such as Active Directory (AD) and Kerberos
authentication, DHCP, and so on. Integration
with AD enables user accounts and remote
access policies and settings such as callback,
access permissions, and so on to be replicated
across the domain for redundancy. AD inte-
gration also can simplify management by pro-
viding a single point of administration and
64 Administrator’s Guide to VPN and Remote Access, Second Edition
enabling you to delegate remote access admin-
istrative authority over specific services or
organizational units (OUs).
Windows 2000 RRAS offers several
authentication options. By supporting
Remote Authentication Dial-In User Service
(RADIUS)—either through a non-Windows
2000 RADIUS server or through the Windows
2000 Internet Authentication Services (IAS)—
Windows 2000 RRAS enables you to rely on
Windows 2000 for routing services while
offloading authentication and accounting to a
RADIUS server. Windows 2000 also supports
a broad range of authentication protocols
including Microsoft Challenge Handshake
Authentication Protocol (MS-CHAP), Extensi-
ble Authentication Protocol (EAP), CHAP,
SPAP, and PAP. You’ll find good network
protocol support in RRAS with TCP/IP,
IPX/SPX, NetBEUI, and AppleTalk enabling
Macintosh, NetWare, and UNIX clients to
connect to a Windows 2000 RRAS server in
addition to Microsoft clients.
New features in Windows 2000
Windows 2000’s RRAS integrates all the fea-
tures in Windows NT RAS and the Routing
and Remote Access Service and adds several
more features to improve performance, inte-
gration, and security. One of the most impor-
tant additions is the integration of RRAS into
Active Directory (AD). You gain the advantage
of AD’s replication, enabling replication of
client account properties throughout the direc-
tory. Administration is easier too, thanks to
the ability to browse multiple RRAS servers
through AD and manage those servers
through the RRAS console, an MMC snap-in
(Figure A).
The Windows 2000 RRAS service adds
support for both Bandwidth Allocation Proto-
col (BAP) and Bandwidth Allocation Control
Protocol (BACP), which work in concert to
support multilink connections. Multilink
enables Windows 2000 to bundle multiple
connections to provide an aggregate band-
width equaling the sum of the individual con-
nections. Aggregate two 56-Kbps dial-up
connections, for example, and you get a theo-
retical connection of 112 Kbps (although the
resulting connection is limited by the FCC-
imposed limit on 56 Kbps connections, line
quality, and other factors). BACP enables
Windows 2000 to dynamically allocate and
de-allocate connections based on bandwidth
utilization.
As bandwidth use increases, Windows 2000
can automatically dial additional connections
to accommodate the increase. When band-
width demand decreases, Windows 2000 can
automatically drop connections. Managing the
number of connections in this way can realize
a significant cost savings. You can apply
BAP/BACP policies through remote access
policies, tailoring those policies to OUs,
groups, or individual accounts.
Support for MS-CHAP version 2 is another
addition in Windows 2000 RRAS. Version 2
offers improved security primarily aimed at
virtual private network (VPN) connections.
MS-CHAP version 2 integrates several changes
for improved security:
X Stronger encryption: Previous versions of
MS-CHAP used 40-bit encryption and the
user’s password to create the cryptographic
key for each session. This resulted in the
same key being used for each session unless
the password changed. Version 2 uses an
arbitrary challenge string along with the
user’s password to create the session key.
The use of the arbitrary challenge string
results in a unique key for each session even
if the user’s password remains unchanged.
X Mutual authentication: This feature pro-
vides for two-way authentication between
the remote client and the RRAS server.
Bidirectional authentication not only allows
the server to authenticate the client’s logon
request but also enables the client to
authenticate the server’s authority to service
its authentication request.
X Improved transmission security: Windows
2000 RRAS uses separate cryptographic keys
for incoming and outgoing data, providing
enhanced transmission security.
X LAN Manager coding no longer sup-
ported: MS-CHAP version 2 drops support
for LAN Manager response coding and
password encoding for improved security.
Figure A
Like other Windows 2000 services, RRAS provides an MMC snap-in that lets you manage
all RRAS server properties.
Another new feature in Windows 2000’s
RRAS is support for EAP, which enables addi-
tional authentication methods to be supported
without changes to the operating system or
RRAS. The server and client negotiate the
authentication method. Protocols currently
supported by Windows 2000 include EAP-
MD5 CHAP, EAP-TLS, and RADIUS. We’ll
take a look at each of these a little later.
As hinted at previously, Windows 2000
RRAS supports RADIUS for authenticating
clients. RRAS can authenticate access against
a Windows 2000 server running the Internet
Authentication Service (IAS) included with
Windows 2000 Server or any server running a
standards-based version of RADIUS, includ-
ing UNIX hosts. Support for RADIUS enables
a Windows 2000 RRAS server to authenticate
clients that connect through RADIUS-based
devices such as modem pools. The RRAS
server can handle RADIUS authentication
itself if IAS is installed on the server or redi-
rect authentication to another server, whether
that server is running Windows 2000 IAS or
other RADIUS implementation (including
UNIX platforms). One of the primary advan-
tages to using RADIUS—other than integra-
tion with existing hardware or authentication
servers—is the capabilities provided by
RADIUS for accounting. Several third-party
utilities exist that provide rich account man-
agement through integration of the RADIUS
logs with database utilities for SQL and other
database platforms.
Security and administration are important
areas of improvement in Windows 2000 RRAS.
Administration 65
 You can apply remote access settings such as
callback, connect time restrictions, allowed ses-
sion limits, authentication methods, and other
properties at the user account level, as shown
in Figure B. A better method, however, is to use
remote access policies to apply remote access
settings on a group or OU basis. Windows 2000
RRAS also supports account lockout, which
helps prevent dictionary attacks by locking the
account after an administrator-defined number
of bad logon attempts. You can also specify the
length of time the account is locked out before
it is re-enabled.
One final improvement in Windows 2000
RRAS is the addition of support for Apple-
Talk over PPP, enabling Macintosh clients to
connect to a Windows 2000 RRAS server
using native Macintosh protocols.
Managing RRAS through
the MMC
As with other Windows 2000 services, you
manage RRAS through an MMC console snap-
in. The RRAS console enables you to fully man-
age local and remote RRAS servers (subject to
access and security restrictions). The console
Figure B
You can apply remote access settings at the user
account level, but remote access policies provide better
administrative control, enabling you to define settings at
the group or OU level.
66 Administrator’s Guide to VPN and Remote Access, Second Edition
provides a wizard to help you configure the
server according to its primary function,
whether Internet connection server, VPN
server, remote access server, or router. You can
configure the server manually and fine-tune the
configuration to accommodate changes or set-
tings not available through the wizard. You also
use the RRAS console to configure remote
access policies.
Exploring RAS protocols and
connection types
Windows 2000 RRAS provides support for
several protocols and connection types, giving
you quite a bit of flexibility in designing your
remote access structure to accommodate secu-
rity needs, network topology, or remote server
capability. Windows 2000 supports Serial Line
Interface Protocol (SLIP) for dial-out connec-
tion to remote servers that support SLIP (such
as older UNIX-based servers), but it doesn’t
support SLIP for incoming connections.
Probably the most common connection
protocol in use today, and one you’ll likely use,
is Point-to-Point Protocol, or PPP. This suc-
cessor to SLIP offers better reliability and per-
formance and provides good cross-platform
support. Windows 2000 supports PPP for
both incoming and outgoing connections,
enabling clients to use TCP/IP, IPX, or Net-
BEUI as the network protocol. Macintosh
clients can connect to a Windows 2000 RRAS
server using TCP/IP or AppleTalk. PPP sup-
ports a good selection of authentication proto-
cols, offering options that can accommodate
both client capability and security needs.
Windows 2000 RRAS supports the Micro-
soft RAS protocol, a proprietary Microsoft
protocol for DOS, Windows for Workgroups,
Windows NT 3.1, and LAN Manager remote
access. Microsoft RAS protocol requires that
the client use NetBEUI as the network proto-
col, with the RAS server functioning as a Net-
BIOS gateway supporting NetBEUI, NetBIOS
over TCP/IP, and NetBIOS over IPX. Since
NetBEUI will likely go away in the next OS
release, you should rely on one of the other
protocols instead of Microsoft RAS.
As mentioned previously, Windows 2000
RRAS also supports Point-to-Point Multilink
Protocol (PPMP) and Bandwidth Allocation
Protocol (BAP). These protocols enable Win-
dows 2000 to bundle multiple connections to
achieve an aggregate bandwidth. For example,
you can use multilink to combine both B chan-
nels of an ISDN connection to achieve an
effective throughput twice what you’d get with
a single channel (or even do the same thing
with two DSL circuits). BAP lets Windows
2000 dynamically manage the connection,
adding or dropping connections as needed
according to bandwidth utilization.
For situations requiring secure connections,
Windows 2000 supports Point-to-Point Tunnel-
ing Protocol (PPTP) and Layer 2 Tunneling Pro-
tocol (L2TP). Both protocols provide a means
for encapsulating and encrypting data packets
for secure transmission across public networks
such as the Internet. You might use PPTP or
L2TP to connect through the Internet to a VPN
server on your LAN, for example, giving you
secure dial-up access to your LAN. Why not just
dial directly into the LAN? Connection costs are
a primary reason. The LAN might be located
outside your local calling area, requiring a toll call
to connect. But connection cost isn’t the only
factor. If the LAN already has a direct connec-
tion to the Internet, you avoid the need to install
and support dial-up equipment on the LAN
side, plus you eliminate a potential security
risk—unauthorized clients bypassing the firewall
or proxy server to gain access to your LAN
through the dial-up back door.
PPTP doesn’t use encryption by default but
can use Microsoft Point-to-Point Encryption
(MPPE) to encrypt the PPP frames with
encryption keys generated with MS-CHAP or
EAP-TLS authentication. Since PPTP encap-
sulates the data unencrypted by default, you’ll
need to specifically use MS-CHAP or EAP-
TLS if you want your PPTP connection to be
truly secure.
Where additional security is needed, you can
use L2TP rather than PPTP. L2TP relies on
Internet Protocol Security (IPSec) to provide
encryption of encapsulated data rather than
MPPE. While this requires that both source
and destination routers support L2TP and
IPSec, it provides a higher degree of security
than PPTP.
Windows 2000 RRAS also offers good net-
work protocol support for RRAS connec-
tions, supporting TCP/IP, IPX, NetBEUI,
and AppleTalk. For TCP/IP connections,
RRAS can allocate IP addresses and related
settings to incoming connections either
through DHCP or a static address pool. The
RRAS service also allows clients to request a
predefined IP address. Unless you’re config-
uring a router or remote access server for
only Microsoft clients that don’t require
Internet connectivity or supporting only Net-
Ware clients, you’re probably going to settle
on TCP/IP as the protocol of choice.
If you do need to support NetWare clients
that use IPX, you can do so through the RRAS
service. IPX support enables a Windows 2000
RRAS server to function as a remote access
server for NetWare IPX clients and also serve
as an IPX router to route RIP, SAP, and Net-
BIOS traffic. In addition to the IPX protocol,
the client must be running a NetWare network
client, such as the Client for NetWare on Win-
dows 2000 Professional computers or Gateway
Service for NetWare on a Windows 2000
Server computer.
NetBEUI is a good solution for remote
access to small LANs and where dial-up traf-
fic does not require routing (since NetBEUI
is a nonroutable protocol). NetBEUI is much
easier to configure than TCP/IP and there-
fore results in lower administrative overhead.
Support for the AppleTalk protocol enables
Macintosh clients to access network resources
shared by other AppleTalk clients on the
LAN, including those shared through Ser-
vices for Macintosh or by other local Macin-
tosh clients.
Enabling RRAS
When you install Windows 2000 Server, Setup
automatically installs the RRAS service but
doesn’t enable it. This means you don’t have to
install the service but you do need to enable
and configure it according to the functions you
want the RRAS server to perform. The server
can handle incoming remote access connec-
tions, manage outgoing remote access connec-
tions, function as a router, or do any
combination of the three.
Administration 67
 The first step in getting the RRAS server up
and running is to ensure the connections are in
place. For incoming connections, this could
mean installing additional network interfaces,
modems, multiport cards, standalone modem
pools, and so on, depending on the types of
clients you need to support. The same is true
for outgoing RAS connections, but this typi-
cally involves adding only a network interface
or installing a modem, ISDN adapter, DLS
equipment, and so on. Configuring connec-
tions for routers typically means adding a net-
work interface where appropriate and
configuring its protocol settings.
Once the interfaces or remote access hard-
ware is in place and tested, your next step is to
enable and begin configuring the RRAS server.
You’ll find the Routing and Remote Access
console in the Administrative Tools folder. In
the left pane, right-click the server and choose
Configure And Enable Routing And Remote
Access to start the Routing And Remote
Access Server Setup Wizard. The wizard lets
you choose between four different types of
Configuring Routing and Remote Access on
your Windows 2000 server
Oct 24, 2000
By Jim Boyce
I Configuring a network
n “Introducing Windows 2000 Routing
and Remote Access” (page 63), I discussed
the Windows 2000 Routing and Remote
Access Service (RRAS), which provides sup-
port for dial-out connections, dial-in connec-
tions, and routing. I also explained the
connection and network protocols supported
by Windows 2000 RRAS, along with security
and integration features. Now, it’s time to start
configuring your RRAS servers, starting with a
network address translation (NAT) proxy.
68 Administrator’s Guide to VPN and Remote Access, Second Edition
servers or configure the server manually. You
have full control over settings after installation
and can modify settings as needed if you
choose to let the wizard configure the server
for you. You can also configure the server
manually, and then run the wizard at a later
time if you want to change the server’s role,
although you’ll lose most of your manually
configured settings when you do so and you’ll
have to reapply them through the wizard. If
you configure the server using the wizard and
then decide you want to start over from
scratch, you can disable and then re-enable the
service to start with a clean slate. To do so, in
the RRAS console, right-click the server and
choose Disable Routing And Remote Access,
and after the service stops, run the wizard
again to configure the service.
What’s next
At this point you have a basic background in
the Windows 2000 Routing and Remote
Access service with a look at many of its
requirements and capabilities.
address translation server
(Internet gateway)
The Routing and Remote Access Server Setup
Wizard, which runs when you enable the
RRAS service, gives you five options for set-
ting up a Windows 2000 RRAS server. The
first wizard option, Internet Connection
Server, lets you configure a Windows 2000
RRAS server to share its Internet connection
and function as a gateway to the Internet for
other computers on the server’s local network.
In this configuration, the server sits on both
the public Internet and the private local net-
work, as illustrated in Figure A. The client com-
puters reside on the local private network, and
the server performs the necessary NAT
required to enable the clients to connect to the
Internet. This option actually offers two differ-
ent methods to support the Internet connec-
tion. The first method uses Internet Connection
Sharing (ICS), which also is available in Win-
dows 2000 Professional and Windows 98SE.
The second method provides essentially the
same function but much more flexibility for
configuration. Before diving into NAT setup,
though, let’s take a minute to get a background
understanding of NAT.
Understanding network address
translation (NAT)
To configure a NAT server, you need to
understand the different functions that the
NAT server performs. NAT handles three
main responsibilities, each performed by a dif-
ferent RRAS component. Address translation
is the first function the NAT server performs
by translating IP address and TCP/UDP ports
for packets traveling between the public inter-
face (the Internet) and the private local net-
work. This is the function that enables clients
to reside on a private, nonroutable subnet but
still gain access to the Internet. The server
handles the translation, replacing its own IP
address for the client’s address, enabling the
packets to be routed back. The server replaces
the IP address for incoming packets in the
same fashion, applying the local address of the
target client.
The second function the NAT server per-
forms is address allocation. As in the case of
ICS, the NAT server can allocate IP addresses
to clients that are configured to obtain their
address leases via DHCP. This function isn’t a
necessity if you want to use a different subnet
from the default of 192.168.0.n or if you
already have a DHCP server on the network to
handle address allocation. The following are
the network IDs reserved for private networks:
X 10.0.0.0 with subnet mask 255.0.0.0
Figure A
Private network
interface
192.168.0.1
Public Internet
interface
Workstation
206.147.17.5
Private Network
NAT Server
Workstation
Workstation
NAT enables computers on a private, nonroutable subnet to access the Internet.
X 172.16.1.0 with subnet mask 255.240.0.0
X192.168.0.0 with subnet mask 255.255.0.0
The third function the NAT server per-
forms is DNS resolution. Clients submit DNS
requests to the NAT server. The NAT server
then forwards the requests to the DNS servers
configured in the NAT server’s TCP/IP set-
tings. The NAT server redirects replies to the
requesting client.
The NAT server performs address transla-
tion through the use of a NAT table. Here’s
how it works: A client on the private network
generates packets for a public node, and the
server intercepts that traffic (since it functions
as the default gateway for the client). The
server replaces the client’s IP address with its
own public address and replaces the source
port with a different, unique port number.
For example, assume that the server resides
on the public interface 206.147.17.5 and uses a
private interface of 192.168.0.1. A client on
the private network at 192.168.0.20 requests a
Web site on a standard TCP port 80. The
server replaces 192.168.0.20 with 206.147.17.5
and replaces the port with, say, port 5000. The
Administration 69
 server stores the replacement data in the NAT
table and sends the packet. When a packet
comes back, it checks the NAT table, reverses
the translation according to the data in the
packet and in the NAT table, and forwards the
packet to the correct client.
NAT works just fine as long as the IP
address and port data are contained in the IP
header of the packet. When the address or
port data is contained in the body of the packet
(also referred to as the payload), translation
could fail. For example, PPTP doesn’t use a
TCP or UDP header but instead uses a
Generic Routing Encapsulation (GRE) header
with a tunnel ID stored in the GRE header
identifying the data stream. Certain FTP oper-
ations, as well as other IP operations, can also
have problems with NAT because of the way
the packets are built.
To get around this problem, the NAT
server needs a means of determining the
appropriate address and port information for
routing the packets. NAT servers, including
Windows 2000 RRAS, employ NAT editors to
perform this additional processing. Windows
2000 RRAS includes NAT editors for FTP,
Figure B
NAT Editors
(if req.)
Private
Internet Network
Translation
NAT Service
Outgoing Traffic
Incoming Traffic
NAT editors provide additional processing for both incoming and outgoing traffic where
needed.
70 Administrator’s Guide to VPN and Remote Access, Second Edition
ICMP, PPTP, and NetBIOS over TCP/IP. The
NAT editor analyzes the packet and performs
the necessary additional translation to send the
packet on its way, doing the same for incoming
packets before passing them to the destination
client on the private network. Figure B illus-
trates the concept.
Internet Connection Sharing (ICS)
The first of the two methods that Windows
2000 offers for NAT services is Internet Con-
nection Sharing (ICS). ICS is included with
Windows 2000 Server, Windows 2000 Profes-
sional, and Windows 98SE. In an ICS connec-
tion, the server shares its Internet connection
and acts as a proxy for the clients to enable
them to use the connection as well. That con-
nection could be something as simple as an
analog dial-up connection or a dedicated, high-
speed connection, such as a T1.
The practicality of the connection depends
on the type of connection, number of clients,
and ways in which the clients use the connec-
tion. Several clients sharing a 56K dial-up con-
nection to access e-mail is a practical
application of ICS, but sharing a dial-up line
such as this to enable Web browsing or con-
current FTP sessions isn’t very practical. Even
so, ICS presents an easy way to share a single
connection and can provide a layer of security
between the clients and the Internet because
the local clients reside on a nonroutable sub-
net. Here’s why: Enabling ICS on a Windows
2000 Server computer automatically assigns
the IP address 192.168.0.1 to the server’s local
network interface, using a Class B subnet mask
of 255.255.0.0. The server then allocates IP
addresses to clients when they start up, assign-
ing addresses in the range 192.168.0.2 through
192.168.254.254, much like a DHCP server.
You can also configure clients to use static
addresses in that range, if preferred. The ICS
server provides DNS proxy name resolution
for the clients and performs the network
address translation necessary for the clients to
use the connection. This network address
translation and the fact that the local network
resides on a nonroutable private subnet can
provide a layer of protection for the clients,
helping isolate them from the Internet.
 If you decide to use ICS, you don’t use the
RRAS console to configure it. If you select
ICS in the RRAS Wizard, the wizard points
you to the Network And Dial-Up Connec-
tions folder to enable ICS. Simply make sure
you have two functioning network interfaces,
one for the local network and one for the
Internet connection (which can be a dial-up
connection). Then, open the Network And
Dial-Up Connections folder, right-click the
Internet connection, and choose Properties.
Click the Sharing tab, and then select the
option Enable Internet Connection Sharing
For This Connection. Select the network
interface through which the connection is
shared from the drop-down list, if the server
has more than one interface. This is the inter-
face that will be assigned the 192.168.0.1
address. If the shared connection is a dial-up
connection, select the Dial On Demand
option to enable the server to automatically
dial the connection when a client attempts to
access an Internet resource. When you click
OK, Windows 2000 automatically reconfig-
ures the network address of the computer’s
local network interface and begins handling
requests from clients for IP address assign-
ment and Internet access.
ICS provides an extremely easy means of
setting up a shared Internet connection for
clients and is essentially a one-click procedure.
What you gain in ease of configuration, you
lose in flexibility, however, because ICS offers
few configurable options. If you need to use a
different subnet or need to control other
aspects of the connection, you’ll need to use
the second method, NAT.
Starting NAT server configuration
Although both the ICS and NAT features in
Windows 2000 perform network address
translation, NAT provides full control over
server configuration and is the Internet con-
nection sharing option you configure through
the RRAS console. You can configure RRAS
to function as a NAT server either through the
RRAS Setup Wizard or manually. (Skip to the
section on completing the NAT server config-
uration, if you want to configure the NAT
server manually.)
When you choose the NAT method in the
RRAS Setup Wizard, the wizard first prompts
you for the Internet connection for which the
server will provide NAT services. You can
choose an existing network interface with an
Internet connection or direct the wizard to
create a new demand dial interface. If the
server has more than two additional network
interfaces, the wizard prompts you to select
the private interface. If there is only one inter-
face, the wizard selects it automatically. After
you specify the public and private interfaces,
Windows 2000 starts the RRAS, and you can
then use the RRAS console to fine-tune the
configuration. If you choose the latter option
to create a new demand dial interface, Win-
dows 2000 starts the RRAS and then launches
the Demand Dial Interface Wizard.
Configuring a demand dial interface
A demand dial interface doesn’t remain con-
nected all the time but instead connects only
when a client requests a resource that resides
beyond the interface. Using a demand dial
interface can reduce costs by reducing connec-
tion time for metered services.
The Demand Dial Interface Wizard, which
runs as part of the RRAS Setup Wizard,
prompts you for the following:
X Name—This is a friendly name for the
connection as it appears in the RRAS con-
sole. Choose a name that adequately
describes the remote connection.
X Connection type—You can choose
between physical devices such as modems
and ISDN adapters or a VPN connection.
If you choose a physical device, the wizard
prompts you to select the device, which you
should already have installed and function-
ing, as well as the dial-up number.
X VPN protocol—If you choose a VPN
connection for the demand dial interface,
the wizard prompts you to select the proto-
col, whether PPTP or L2TP. If you choose
Automatic Selection, Windows 2000 will
attempt to use L2TP for the connection,
and if that fails, it will use PPTP.
X Server address—For VPN connections,
specify the IP address or Fully Qualified
Administration 71
 Domain Name (FQDN) of the remote
VPN server.
X Protocols and security—The wizard
prompts for the protocols that should be
routed through this connection, which
include IP and IPX. You also specify a user
account to use for authentication and set
other security and connection options, such
as password handling and connection
scripting.
Completing the NAT server
configuration
After you run the wizard and configure the
server for NAT, you’ll probably need to fine-
tune the configuration. Or, you might have
already configured the server for another pur-
pose, and you can’t use the wizard to configure
the server for NAT (since you’ll lose your cur-
rent configuration). In that case, you can con-
figure the server manually. This section
explains how to do that, as well as modify the
configuration for both situations.
Enabling NAT manually
If you’ve already configured the server
through the wizard for a function other than
NAT (such as dial-up remote access) or simply
prefer not to use the wizard, you can manually
configure the server for NAT. (You don’t need
to perform this step if you’ve configured NAT
Figure C
Add the public and private interfaces to the NAT protocol
through the RRAS console.
72 Administrator’s Guide to VPN and Remote Access, Second Edition
through the wizard.) Open the RRAS console
and expand the server in the left pane. Right-
click General, and select New Routing Proto-
col. Select Network Address Translation, and
click OK. RRAS adds a Network Address
Translation node under the IP Routing branch.
The next step is to add the interfaces for NAT.
Adding a NAT interface
After adding the NAT protocol, you need to
specify the interfaces on which the RRAS
server should perform translation. If you con-
figure the server through the wizard, the wizard
prompts you for the two minimum inter-
faces—the public Internet connection and the
private network interface. However, Windows
2000 RRAS can provide NAT services on more
than one interface. If you have multiple net-
work subnets, for example, you could configure
the server with a network interface for each
and have the server provide NAT for all the
subnets.
To add NAT interfaces, open the RRAS
console and expand the server. Open the IP
Routing branch, right-click Network Address
Translation, and choose New Interface. Select
the interface for which you want to add NAT
services, as shown in Figure C, and click OK.
Windows 2000 then prompts you to spec-
ify whether the interface is public or private.
Select the option Private Interface Connected
To Private Network to identify the interface
as residing on the private side of the server.
Select Public Interface Connected To The
Internet if the interface resides on the public
side of the server.
Selecting the latter option enables the
Translate TCP/UPD Headers option. Select
this option to have the server translate TCP
and UDP ports in addition to the IP address
for translated packets. In most cases you’ll
need to select this option to enable NAT to
function properly for the private networks.
The property sheet displays two additional
pages if you select the public interface option:
Address Pool and Special Ports. You can reach
these pages later, if needed, by double-clicking
the public interface. You use the Address Pool
page to configure the range of IP addresses
assigned by your ISP for your network’s use.
The Special Ports page lets you define special
translation properties for specific TCP or
UDP ports.
Configuring address ranges
Use the Address Pool tab on the NAT inter-
face’s property sheet to specify the range of
addresses allocated by your ISP to the public
side of your network, as shown in Figure D.
RRAS uses this pool of addresses for mapping
packets to and from the private network. If
your ISP allocated only one IP address, you can
leave this list empty. In this situation, the RRAS
server requests unique TCP and UDP ports
from the protocol stack, using those ports to
translate packets to and from the private net-
work. If you have multiple public IP addresses,
the server leaves the ports as is and only trans-
lates the IP address, selecting a currently
unused address from the pool. If the server
runs out of addresses, it switches to translating
the ports, just as it does when only one IP
address is available.
You need to add the address range to the
list if your ISP allocated more than one
address. Once you’ve done that, you can apply
reservations to reserve one or more of the
allocated addresses for other nodes on the
public side of your network (for other servers,
for example).
To do this, first click Add on the Address
Pool page to open the Add Address Pool dia-
log. Type the starting address of the allocated
range and the subnet mask. RRAS determines
the ending address automatically. Or, you can
specify the starting and ending addresses if you
can’t use a subnet mask to define the range.
Next, click Reservations if you need to
reserve one or more addresses for other nodes
on the public side of the network or if you
need to reserve an IP address for use by a com-
puter on the private side of the network. For
example, you might have a Web server located
on the private network and need to reserve a
public address for it, mapping the public
address to the Web server’s private address.
Finally, click Add in the Reserve Addresses
dialog to open the Add Reservation dialog.
Specify both the public IP address to reserve
and the IP address of the computer on the pri-
vate side that will use that address. If the com-
Figure D
Specify the range of addresses the NAT server uses for
translating traffic to and from the private network.
puter needs to be accessible to Internet clients,
select the option Allow Incoming Sessions To
This Address.
Configuring special ports
In most cases you can allow NAT to handle
TCP and UDP port translation on its own. In
special circumstances, however, you might need
to direct the server to handle specific ports in a
certain way. For example, if a packet comes in
for a specific port, you might need that traffic
redirected to a specific port on a specific pri-
vate IP address. Here’s an example: Assume
you have a Web server on the private network,
but it’s using port 8080 instead of the default
port 80 and you want to map incoming port 80
traffic to port 8080. To do that, you’d configure
a special port so that incoming traffic bound
for port 80 is translated to port 8080 on the
appropriate IP address. You can have the spe-
cial translation apply to all incoming traffic on
the interface or only to traffic for a specific
public IP address.
To configure a special port, click the Special
Ports tab. Select either TCP or UDP from the
drop-down list, as appropriate; then click Add.
To translate the port for all addresses on the
public interface, select On This Interface. Other-
wise, select On This Address Pool Entry, and
enter the IP public address for which the special
translation needs to occur. In the Incoming Port
Administration 73
 text box, type the port number to which incom-
ing traffic is directed. Specify the private IP
address to which the traffic needs to be routed
and the control destination port on the private
computer in the Outgoing Port box. In the pre-
vious example of the Web server, you’d put 80
in the Incoming Port box and 8080 in the Out-
going Port box.
Configuring general NAT properties
After you configure each interface as I’ve
explained, you need to turn your attention to
general NAT service properties. In the RRAS
console, expand the server, right-click Net-
work Address Translation under IP Routing in
the left pane, and choose Properties. The Gen-
eral page of the NAT properties lets you con-
figure the level of logging by NAT in the
System log. The options are self-explanatory.
The Translation page lets you specify how
long the NAT server maintains port mappings
in the NAT table. There are separate settings
for TCP and UDP.
Configuring applications
The Translation page of the NAT server’s
properties also lets you configure applications
for NAT. For example, you might run an appli-
cation that uses nonstandard ports to commu-
nicate with a server on the Internet, which is
common with Internet games such as Sub-
space or Diablo. So, you can configure the
NAT server to provide the appropriate port
translation, either for UDP or TCP, as needed.
To configure applications, open the proper-
ties for NAT, click the Translation tab, and
then click Applications. Click Add to display
the Internet Connection Sharing Application
dialog. Provide the following information:
X Name—This name serves to identify the
application in the RRAS console’s list.
X Remote server port number—Specify the
port on the remote server that needs to be
remapped on the private network.
X TCP or UDP—Select the port type for the
remote server port.
X Incoming response ports—Specify the
port translations for the ports on the private
network. You can specify TCP and UDP
ports separately.
74 Administrator’s Guide to VPN and Remote Access, Second Edition
Add additional port assignments as required
by the applications you use. A given applica-
tion could require more than one entry.
Configuring address assignment
The clients on the private network must reside
on the same subnet as the NAT server’s pri-
vate network interface. You can configure the
clients for static IP addressing or rely on
DHCP for address assignment. While you
could install a DHCP server to provide
addresses to the clients, the NAT server can
also handle that function, eliminating the need
for a separate DHCP server.
To configure address assignment, open the
RRAS console and expand the server in the
left pane. Open the properties for NAT under
IP Routing, then click the Address Assignment
tab. Select the option Automatically Assign IP
Addresses By Using DHCP; then specify the
address range by entering the starting IP
address in the range and the subnet mask.
Click Exclude if you need to exclude one or
more addresses from DHCP assignment, mak-
ing those available for other servers or fixed-
address nodes on the private network.
Configuring name resolution
The private clients need a server to provide
proxy DNS lookup, and the NAT server can
optionally fill that role if no other DNS proxy
is available. To configure DNS lookup on the
NAT server, first configure the NAT server’s
TCP/IP properties on the public interface to
add the DNS servers the NAT server will use
for lookup. Then, open the RRAS console, and
open the properties for NAT under IP Routing.
Click the Name Resolution tab, and select the
option Clients Using Domain Name System
(DNS). If you’re using a demand dial interface
to connect to the Internet, select the option
Connect To The Public Network; then select the
demand dial interface from the drop-down list.
What’s next?
This time around, we looked at network address
translation and configured a Windows 2000
RRAS server to function as a gateway between a
private network and the Internet. In the next arti-
cle, I’ll take a look at configuring a remote access
server to support incoming connections.
Configuring Windows 2000 as a
remote access server
Dec 4, 2000
By Jim Boyce
I
n “Configuring Routing and Remote
Access on your Windows 2000 server”
(page 68), I showed you how to configure
a Windows 2000 RRAS server to function as a
Network Address Translation (NAT) server.
In this article, I’ll take a look at configuring a
Windows 2000 RRAS server to function as a
remote access server (RAS), handling incom-
ing connections for remote clients.
What is a remote access server?
The term “remote access server” can refer to
a server that performs a range of remote
access services, instead of just providing the
ability for clients to dial into the company
LAN. Both Windows 2000 Professional and
Windows 2000 Server can act as remote
access servers, albeit with different restrictions
on each platform.
On the Windows 2000 Professional side,
you can configure a workstation to allow
incoming connections through dial-up (one at
a time), giving the remote caller the ability to
use resources stored on the local computer or
on the LAN, depending on how RRAS is con-
figured. Under Windows 2000 Server, RRAS
can support multiple concurrent remote access
clients for those same purposes, essentially
limited only by the number of available incom-
ing connections. For example, if you have a
modem pool of 48 modems, Windows 2000
Server will support all those connections con-
currently.
A RAS connection that connects the client
to the dial-up server is called a point-to-point
remote access connection. A RAS connection
that connects the client to the LAN is called a
point-to-LAN remote access connection.
Regardless of the type of connection, the
remote clients can access resources on the
server or LAN as if their computers were con-
nected locally to the server or LAN. For exam-
ple, clients can open and save files and use
printers, just as they can locally.
Remote access is not the same thing as
remote control. With a remote control applica-
tion such as Symantec’s pcAnywhere, the client
uses the remote control application to log onto
and run applications on a remote computer.
The applications run on the remote computer
rather than on the client’s local computer. In
effect, the remote control application gives the
client a long-distance keyboard, mouse, and
display for the remote computer.
Remote access makes the client’s local com-
puter a part of the remote network. Applica-
tions run on the client’s local computer, not on
the remote computer (except when the client
executes a network-enabled application).
Remote control applications can’t exist without
remote access—the client either dials in to the
remote computer directly or dials in to the
LAN. So, if you need to use a remote control
application to manage a remote server, for
example, you’ll need a remote access connec-
tion to the server or to the server’s LAN
before the remote control application can do
anything. Depending on the remote control
application, that connection might take the
form of a public Internet connection, using
the remote server’s and client’s existing con-
nections to the Internet as the means of com-
munication.
Setting up the hardware
Whether you’re configuring a Windows 2000
Professional computer to enable single con-
nections or a Server computer to handle a
modem pool, your first step in setting up a
remote access server is to configure the hard-
ware for the incoming connections. These
connections might come in through one or
more modems connected to the computer’s
communications ports, through a multiport
communications card handling multiple
modems, a modem pool/communications
server connected to the LAN, or even a net-
work interface.
Administration 75
 While you can certainly grow the server’s
capabilities later on, you need to determine
your clients’ current needs and plan for that
growth. Choosing the right communications
hardware is a big part of that process. If the
bandwidth needs aren’t critical, modems and
Public Switched Telephone Network (PSTN)
lines (standard voice lines, or Plain Old Tele-
phone Service—POTS) are an easy and rela-
tively inexpensive solution. If you’re installing
multiple lines, choose one number as the pri-
mary dial-up number and have your communi-
cations provider configure the lines in a hunt
group. If one line is busy in the hunt group,
the incoming call rolls to the next available
line. There are several options for hunt groups
that can address such problems as a ring-no-
answer due to a hung modem. Check with
your provider for details to decide what best
fits your needs.
PSTN is certainly not the only option, nor is
it the best option in terms of performance.
PSTN will give you a maximum of 33.6 Kbps
for connections. Even though 56-Kbps
modems are standard nowadays, you can’t sim-
ply install individual 56-Kbps dial-up modems
to PSTN lines and have them connect at the
full rate. To support 56-Kbps dial-up connec-
tions, you’ll need a channelized T1 (24 channels
or dial-up lines per T1) and the appropriate
remote access hardware to accommodate the
incoming calls.
If you choose to get a channelized T1,
things can get a bit complicated. Your commu-
nications provider assigns a phone number to
each channel, and as with the PSTN option,
you’ll want to set up a hunt group for the num-
bers with a single primary dial-up number. The
communications hardware for this type of
connection setup typically takes the form of a
network device that contains one or more
communications cards with onboard modems.
The T1 connects to the device and the device
connects to the network. Depending on the
firmware provided with the device, you can
use either Windows 2000 authentication or
RADIUS (the IAS service in Windows 2000).
ISDN is a third connection option. Basic Rate
Interface (BRI) provides two 64-Kbps channels,
and Primary Rate ISDN (PRI) provides twenty-
76 Administrator’s Guide to VPN and Remote Access, Second Edition
three 64-Kbps channels. ISDN functions in
some ways like a PSTN dial-up connection
except that the connection is digital rather than
analog and provides better throughput.
Other connection options include X.25 and
ATM (Asynchronous Transfer Mode) over
ADSL (Asymmetric Digital Subscriber Line).
Windows 2000 supports only X.25 smart
cards—X.25 adapters that connect computers
directly to an X.25 public network. ATM is a
standard communications protocol for high-
speed data links. ADSL is a relatively new
communications mechanism that employs
standard copper phone lines to achieve very
high data transfer rates.
In deciding which type of connection is
right for you, check with your local communi-
cations provider to determine what services
they offer. Some services, such as ADSL, may
not be available in your area. If you can’t get
ISDN or ADSL, for example, you’ll probably
have to choose between PSTN and digital 56
Kbps. The speed at which your users need to
connect will be the primary deciding factor in
your decision, but cost will no doubt be a
major consideration as well.
If you choose an external communications
device, such as a modem pool, you generally
will not use the RRAS service to provide dial-
up services for clients. Instead, the device’s
firmware, once configured, handles the task
of assigning IP addresses and performing
other tasks to service the RAS clients. In this
situation, the server will typically perform
two functions: hosting the configuration-
management software for the device or pro-
viding authentication services, or both.
Depending on the communications device,
the system might use either RADIUS or Win-
dows 2000 integrated authentication. If it uses
the former, you can use IAS as the authentica-
tion service, which enables the server to
process RADIUS authentication requests from
the communications equipment, authenticating
users against local or domain accounts. If the
device relies on Windows 2000 integrated
authentication, the device’s software will likely
include a service that enables the device to
interface with the Windows 2000 authentica-
tion mechanisms.
Configuring the RRAS server plays the installed ports in the right pane. You’ll
notice that if you configure the server for
through the wizard remote access through the wizard, RRAS will
After the hardware is set up and functioning,
automatically add 10 VPN ports—five PPTP
you’re ready to configure the server as a RAS
and five L2TP. The other installed communica-
server. You can configure the server through
tions devices (such as local modems) will also
the RRAS wizard or manually. If you choose
show up on the list. Double-clicking a port on
the wizard option, the wizard will prompt you
the list displays a status dialog box containing
for the following information:
line speed, connection statistics, network regis-
X Protocols: Select the installed protocols you tration (address, for example), and other infor-
need to support for remote access users or mation. You can also use this dialog box to
add protocols if they’re not already installed. reset a port, as would be required when a
X Network connections: Select the network modem is hung.
interface to which remote access clients will Right-click Ports in the left pane and choose
be assigned. Typically this is a LAN inter- Properties to configure ports. In the resulting
face. If you have multiple interfaces on the dialog box, select the port you want to config-
server, however, you need to decide which ure and click Configure to set these properties,
one the clients will be placed on. as shown in Figure A:
X IP address assignment: If you’re using X Remote Access Connections (Inbound
TCP/IP as one of the network protocols Only): Select this option to enable incom-
for RAS clients, you need to decide how IP ing remote access connections to the
addresses are assigned to the clients. You selected port type.
can assign addresses through DHCP if a X Demand-dial Routing Connections
DHCP server is available on the network. If (Inbound And Outbound): Select this
no DHCP server is available, the server will option to enable demand-dial connections
assign IP addresses automatically. Or, you for the selected port type.
can specify a range of addresses the server
X Phone Number For This Device: Use
will use to assign address leases to clients. If
this setting to specify the phone number
you choose this latter option, the wizard will
associated with the device. See the following
prompt you to specify the address range.
discussion for more information on config-
X Use RADIUS: You can choose at this uring the phone number.
point to configure RRAS to use RADIUS
X Maximum Ports: Use this setting to spec-
for authentication, specifying the IP
ify the maximum number of connections
addresses or DNS names of the primary
for the selected port type. For example, you
and secondary RADIUS servers, as well as
the RADIUS secret. You can choose not to
configure RADIUS if you’ll be using Win- Figure A
dows 2000 integrated authentication or
want to configure RADIUS properties later.
Whether you use the wizard to configure
the RAS server for incoming connections or
configure the server manually, you’ll use the
RRAS console to configure and fine-tune set-
tings. One of the configuration tasks you’ll
need to perform is to configure the remote
access ports.

Configuring ports
Use the Configure Device dialog box to configure port
In the RRAS console under the server you’ll properties.
find a Ports branch. Clicking the branch dis-

Administration 77
 might use this setting to limit the number of
L2TP connections that can be active at one
time. Windows 2000 doesn’t change the
number of ports shown in the RRAS con-
sole until you stop and restart the service.
The phone number property isn’t needed
unless you’re supporting multi-link connections
or restricting users through remote access poli-
cies to a specific dial-up number. With multi-
link, the phone number is used for
BAP-enabled connections, and the server sends
the phone number of the connection to the
remote client when the client’s system requests
another connection. If you’re using a hunt
group for your phone number pool, you needn’t
Increasing Windows 2000 RRAS security
Dec 7, 2000
By Jim Boyce
I
n the last few articles, I’ve shown you how
to configure Windows 2000 for Network
Address Translation and as a remote
access server. But now that you’ve set up your
remote access server, how do you secure it? In
this article, I’ll show you how to set up remote
access policies for your remote access server.
I’ll also show you how you can create secure
connections across the Internet using VPN
protocols.
Configuring remote
access policies
In my last article about Windows 2000 RRAS,
I showed you how to configure the hardware
and port settings for your server. In addition to
configuring the hardware and port settings,
you need to configure remote access policies.
These policies enable you to control allowed
access times, restrict users to specific dial-up
numbers, and configure other Remote Access
Policy settings.
78 Administrator’s Guide to VPN and Remote Access, Second Edition
specify individual numbers for each port. The
phone number property is also used for the
Called Station ID property in the remote access
profile. If the specified number doesn’t match
the value for Called Station ID in the remote
access profile, RRAS rejects the connection.
Conclusion
The Windows 2000 RRAS service provides
many different things for your network. One
of the most common purposes it serves is as a
remote access server. In this article, I’ve shown
you how to configure Windows 2000 to func-
tion as a remote access server.
You configure remote access policies
through the RRAS console. Open the console
and click the Remote Access Policies branch.
By default, remote access permission is denied
through the Remote Access Policy, Allow
Access If Dial-In Permission Is Enabled.
Double-click the policy and note that Deny
Remote Access Permission is selected. This is
because there are no other parameters yet
specified for the policy. If you enabled this
permission, it would allow all users to gain
remote access by default. So, you’ll need to
either modify this policy or create a new one.
In this case, I’ll assume you want to modify the
existing policy to allow permission only to
users who belong in a specific user group. For
my example, I’ll create a group called RAS
users and grant them permission.
First, open the Local Users And Groups
console (stand-alone or member server) or
the Active Directory Users And Computers
console (domain controller). Create a new
group named RAS Users and place in it all
the users to whom you want to grant remote
access permission.
Next, open the RRAS console and double-
click the policy to open its Settings property
page. Click Add, select Windows-Groups, and
click Add. Click Add in the Groups dialog box,
select the group, and click Add. Click OK,
then OK again to close the two configuration
dialog boxes and return to the Settings prop-
erty page. Select Grant Remote Access Permis-
sion, and click OK.
The policy you just created allows all users
in the RAS Users group to log in via RAS at
any time. You can modify the Day-And-Time-
Restrictions profile to allow RAS access only at
certain times. To do so, open the policy again,
click Day-And-Time Restrictions, and click
Edit. Specify the allowed dial-in times in the
Time Of Day Constraints window, as shown
in Figure A, and click OK. Configure other set-
tings as needed, and then close the property
sheet for the policy to apply the change.
Now, what happens if you want two sepa-
rate groups to have RAS access at different
times? Simple: You just create two policies.
RRAS processes all the remote access policies
if needed, granting access to a caller if the
caller’s parameters match at least one policy. So,
a caller might not match the first policy or the
second but might match the third, and RRAS
would therefore grant (or deny) access subject
to the properties of the matched policy.
For example, assume you have three groups
of users: one that needs access from 8:00 A.M.
to 5:00 P.M., another that needs access from
5:00 P.M. to midnight, and a third group that can
gain access at all hours but must use L2TP for
security. You create three policies, one for each
situation. Each group of users would belong in
an identifying group, which I’ll name RAS 1,
RAS 2, and RAS Secure. When you define the
policies for RAS 1 and RAS 2, each policy has
two properties (in this example): Windows-
Group and Day-And-Time-Restrictions. You
configure the allowed logon times for the Day-
And-Time-Restrictions property for RAS 1 to
be 8:00 A.M. to 5:00 P.M. and for RAS 2 to be
5:00 P.M. to 12:00 A.M.
For the third group, use the Windows-
Group property along with the Tunnel-Type
Figure A
Configure the Day-And-Time-Restrictions condition to control when remote
access users can dial in.
property set to L2TP to restrict users in that
group to use only L2TP. If they attempt to use
a different tunneling protocol, such as PPTP,
Windows 2000 rejects the connections.
You configure the priority of policies so
that RRAS parses them in a specific order.
This gives you the ability to move the most fre-
quently used policy to the beginning of the list
to speed connections and reduce overhead. To
configure policy priority, open the RRAS con-
sole, expand the Remote Access Policies
branch, click on a policy, and use the up- and
down-arrow buttons in the toolbar to change
the policy’s location in the list.
Configuring a VPN server
Virtual private network (VPN) connections
enable clients to establish a secure, private con-
nection to a remote computer or LAN
through a public network such as the Internet.
For example, users who travel can connect
through a national or local ISP, then connect
through that Internet connection to the office
LAN. Windows 2000 supports two tunneling
protocols, PPTP and L2TP; the latter provides
stronger security than PPTP primarily because
of differences in the encryption methods
between the two.
Setting up a VPN server is initially not
much different from configuring a remote
access server, although there are a few addi-
tional steps and considerations. When you run
the wizard and select the Virtual Private Net-
work option, Windows 2000 prompts you for
Administration 79
 essentially the same information as for a
Remote Access Server, including protocols,
network interfaces, IP address assignment
mode, and RADIUS authentication status.
One difference is when you use the wizard to
configure the server for VPN, it creates 128
ports each for PPTP and L2TP. Configuring
the server for remote access creates only five
ports each.
Even if you use the wizard to set up a VPN
server, you still have some tasks to perform to
complete the operation. Plus, you might
already have the server configured for another
RAS purpose and need to configure the server
manually for VPN. If you choose the manual
method, first perform these tasks:
X Set up the Internet connection—This is
the public connection through which
remote clients will gain access to the
intranet. Verify that the connection is fully
configured and functioning.
X Set up the intranet connection—If your
server is multihomed (has a public interface
to the Internet and a private interface to the
intranet), configure the intranet connection
and verify connectivity with clients on the
intranet. Note that you don’t need a second
interface to set up a VPN server. A single,
public interface will suffice. Remote clients
will receive an IP address assignment from
the same subnet as the computer’s Internet
interface.
X Set up routing (multihomed systems)—
If the server is multihomed, you’ll need
to configure static routes or use routing
protocols to enable routing between the
public and private interface(s). In most
situations the wizard will handle these
tasks, but you might have to fine-tune the
configuration, particularly if you are using
static routes. If the server has only one
network interface, you don’t need to con-
figure any routing properties, since no
routing is necessary.
X Enable remote access—If you are config-
uring VPN support manually, you’ll need to
enable RAS on the server. Open the RRAS
console, right-click the server, and choose
80 Administrator’s Guide to VPN and Remote Access, Second Edition
Properties. On the General page, select
Remote Access Server.
X Configure IP addressing and routing—
On the properties sheet for the server, click
the IP tab and select Enable IP Routing. If
you didn’t already do so through the wizard,
configure IP address assignment through the
same property page, configuring the server
to rely on DHCP, or use a static address pool
to assign IP addresses to clients.
X Configure ports for remote access—You
need to ensure that the necessary ports are
created and configured for remote access.
Expand the server in the RRAS console and
open the Ports branch. Right-click Ports
and choose Properties. Select either PPTP
or L2TP and click Configure. Select Remote
Access Connections (Inbound Only) to
enable remote access for the port type. Use
the Maximum Ports spin control to increase
or decrease the number of ports. The num-
ber won’t increase in the ports list, however,
until you stop and restart the service. If you
wish to support both VPN port types,
repeat the process for each.
Configuring the server for
PPTP VPN connections
Although you can begin using the server to
service VPN clients at this point, you’ll proba-
bly want to ensure a higher level of security
than what you’ll have by default. In particular,
you might want to configure filters to restrict
traffic to and from the VPN server, as well as
define the authentication mechanism(s) to be
supported.
In the RRAS console, right-click the server,
choose Properties, and then click the Security
tab. You can choose between Windows
Authentication and RADIUS both for authen-
tication and accounting. Click Authentication
Methods to specify the authentication meth-
ods you want to support. You need to use
either MS-CHAP or EAP-TLS if you need to
support encrypted authentication.
If your server is functioning only as a VPN
server, consider applying IP filters to allow
only PPTP traffic coming to and from the
server, excluding all other traffic. This will help
prevent unwanted traffic from being routed
through your server to your LAN or from the
LAN to the Internet. Filters apply at the inter-
face level, enabling you to configure filters dif-
ferently for each interface, if needed.
In the RRAS console, expand the server
then the IP Routing branch, and click the Gen-
eral branch. Right-click the interface on which
you want to configure filters and click Proper-
ties. The General page is the place to go to
configure filters. To configure the input filters,
click Input Filters and then click Add in the
Input Filters dialog box. Select Destination
Network, and then in the IP Address field,
enter the address of the interface. Specify
255.255.255.255 in the Subnet Mask field.
Select Other from the Protocol drop-down list
and type 47 in the Protocol Number text box,
as shown in Figure B. Click OK to add the filter.
When the Input Filters dialog box reap-
pears, click Add again and add another filter
with the same information as the first. How-
ever, this time select TCP from the Protocol
list, specifying 0 for the Source Port and 1723
for the Destination Port.
You’ll need to add one more input filter if
you intend to use the server as a PPTP client.
Create a third filter using the same basic infor-
mation as the first two, this time selecting TCP
from the Protocol list, specify 1723 as the
Source Port and 0 as the Destination Port.
The last step in configuring the input filters
is to specify the action to take for the filter.
Back on the Input Filters dialog box, select
Drop All Packets Except Those That Meet
The Criteria Below, and then click OK.
Next, configure output filters using much
the same process you used for the input filters.
On the General page of the interface’s prop-
erty sheet, click Output Filters. Create a filter
for Source Network, specifying the IP address
of the interface, entering the subnet mask of
255.255.255.255, setting Protocol to Other,
and entering 47 as the protocol number. Add a
second IP filter for Source Network with TCP
as the protocol, 1723 as the Source Port, and 0
as the Destination Port. If the server will be
used as a PPTP client, add a third filter for
Source Network, using TCP, Source Port 0,
and Destination Port 1723. Return to the Out-
Figure B
Configure input and output filters to restrict traffic on the
server to VPN traffic, if desired.
put Filters dialog box and configure the filters
to drop all packets except those that meet the
filter criteria.
Configuring the server for
L2TP VPN connections
As you do for PPTP, you need to configure the
L2TP ports to allow remote access. Open the
properties for the Ports branch, select L2TP
from the Ports list, and click Configure. Select
Remote Access Connections (Inbound Only)
and then close the dialog boxes.
You also should configure filters to restrict
traffic to and from the server to prevent
unwanted traffic from being routed through
the server. As you do for PPTP filters, you
configure L2TP filters through the properties
for the affected network interface. Start with
the input filters. Create the first filter for Des-
tination Network, the IP address of the inter-
face, a subnet mask of 255.255.255.255, UDP
as the protocol, and 500 for both the source
and destination ports. Add a second input fil-
ter using the same information but specifying
1701 for both the source and destination
ports. Configure the filter to drop all packets
except those that meet the filter criteria.
Next, create the necessary output filters.
Create the first filter for Source Network, the
IP address of the interface, a subnet mask of
255.255.255.255, UDP as the protocol, and
Administration 81
 source and destination ports specified as 500.
Add a second output port with similar settings
but with source and destination ports of 1701.
Configure the filters to exclude all packets
except those that fit the filter criteria.
Configuring RAS policy for
PPTP/L2TP
After you configure the ports and other set-
tings for PPTP and/or L2TP, turn your atten-
tion to configuring remote access policies to
allow VPN connections (and potentially restrict
access only to VPN access). First, create a
group (or use an existing group) to give you a
means of restricting VPN connections to spe-
cific users. Then, open the RRAS console, fol-
lowed by the Remote Access Policies branch.
Create a new remote access policy, giving it an
appropriate name such as VPN Access. Config-
ure the conditions for the policy to include
group membership so that it restricts access
only to users who belong in your VPN users
group. Then, add a condition for NAS-Port-
Type set to Virtual (VPN). Add a third condi-
Routing and remote access on Windows
2000 Advanced Server
Sep 6, 2000
By Matthew Mercurio, MCP
U
sing new products from Sybergen and
Linksys to share Internet access is
great for the consumer, but these
products aren’t practical or efficient for a cor-
porate network. To address this concern, this
article examines the routing and remote
access options available with Windows 2000
Advanced Server. Windows 2000 Advanced
Server allows IT professionals to share Inter-
net access, flatten their networks, and not
compromise connectivity.
82 Administrator’s Guide to VPN and Remote Access, Second Edition
tion for Tunnel-Type set to PPTP, L2TP, or
both, depending on which protocols you’re
supporting on the server. If you haven’t modi-
fied the default remote access policy, move it
after the VPN policy. You need to make this
change because the default policy denies access
to all users.
Finally, configure encryption. Double-click
the newly created policy to open its properties,
and then click the Encryption tab. Select the
appropriate options on the Encryption tab,
depending on the levels of encryption you
want to allow for VPN connections according
to your clients’ configurations.
Conclusion
In this article, I’ve shown you how to
increase security for your remote access
servers. You can do so using remote access
policies and VPN. On VPNs, you have sev-
eral different types of protocols to choose
from, including PPTP and L2TP. I explained
these protocols and how to configure RRAS
to support them.
BEFORE WE BEGIN
In order to configure the R&R module cor-
rectly, you must have your DNS server and
DHCP server information handy. You
should also have already installed a second
network adapter card in the machine. (I’ll
discuss the reason for this later.)
Windows 2000 Figure A
Advanced Server
I have to admit that at first glance, I thought it
was a bad idea to place a Windows 2000 box on
my network just to share Internet access. How-
ever, the Remote and Routing Access module
quickly changed my mind. After the installation
and a lot of experimenting with the many new
modules, it turned out to be a very eye-opening
experience. There are many modules, plug-ins,
and components included in the new network
operating system. For the purpose of this arti-
cle, I’ll focus on the Remote and Routing
Access module. Simplicity is key when it comes
to sharing a single IP for Internet access. The
Routing and Remote Access module installa- The arrows indicate the location of the Windows 2000 Advanced Server
Routing and Remote Access module.
tion was relatively easy, and the configuration
of it was even easier. Let’s take a closer look.
next to the R&R title. If the R&R module is
Remote and routing access up and running, a green arrow pointing
configuration upward will appear.
Once the Windows 2000 Advanced Server is Starting the routing and remote
installed, the easiest way to get to the Routing access setup wizard
and Remote Access (R&R) module is by right- To start the R&R setup wizard, click the
clicking on the My Computer icon on your Action button at the top of the toolbar as
desktop and choosing Manage. Once you are shown in Figure B. Then click Configure And
in the Computer Management window, shown Enable Routing And Remote Access. A dialog
in Figure A, expand the Services And Applica- box will appear reporting that you’ve started
tions tree, and the R&R module, will then be the R&R wizard. Click Next to continue.
visible. On the resulting screen, you will see the
If the R&R module is not running, a red connection choices, as shown in Figure C. From
arrow pointing down will appear on the icon here you can configure various connections,

Figure B Figure C

Click Configure And Enable Routing And Remote Access. For this demonstration, choose Internet Connection Server.

Administration 83

A FEW WORDS ABOUT NAT
There are a couple of things to keep in
mind when setting up NAT through Routing
and Remote Access. First, you must set up
a DHCP server before beginning the setup.
Second, you must decide what IP scheme
to assign the inside card. The R&R module
will use NAT to masquerade your internal
network, and the only visible IP will be the
one assigned to you by your ISP.
Figure D
Select the Network Address Translation (NAT) routing protocol.
Figure E
Specify your Internet connection NIC.
84 Administrator’s Guide to VPN and Remote Access, Second Edition
including the popular RAS and VPN connec-
tions. For this demonstration, choose the first
option—Internet Connection Server.
Using two NICs
We want the ability to share our Internet con-
nection with the rest of the network comput-
ers, so we will need an additional NIC placed
in the PC. The R&R module gives you a choice
to use Internet Connection Sharing (ICS) or
Network Address Translation (NAT). For the
purpose of our demonstration, we will choose
NAT. Assign the outside Internet connection
NIC an IP address assigned to you by your
ISP, and then give an internal IP scheme to the
second NIC. The R&R module does the rest.
When installing your NICs, be sure to use
unique names for your cards. The naming con-
vention is entirely up to you, but I recommend
using names that will allow you to quickly rec-
ognize which NIC is serving what purpose.
This is especially handy when you happen to
be using the same brand of network cards.
In my case, I have two 3Com 905B cards
installed, so I used Wizard.Home for my exter-
nal card because this is the card that is actually
connected to the outside Internet. I then used
RacerX.Lan to represent my internal LAN.
ICS or NAT
After you have chosen Internet Connection
Server and clicked Next, you are ready to make
the choice between ICS and NAT. I chose
NAT, as shown in Figure D, and I suggest you
do the same.
Choose your connection type
The next screen that appears is the Internet
Connection page. Here we have a couple of
choices to make. First, do we want to create a
demand-dial Internet connection? Since we
have a cable modem and a 24/7 connection to
the Internet, our answer is “No.” However, if
you are using a dial-up modem or a modem
pool, then you might want to create a demand-
dial connection. Our second choice is to
decide which NIC to designate as the outside
Internet connection. This is where our naming
convention pays off. Simply choose the card
that is directly connected to the Internet, as
shown in Figure E, and click Next.
 The final screen, shown in Figure F, will then Figure F
appear, and we are finished. We have set up the
Windows 2000 Advanced Server to act as a
router and share our single IP to use with the
rest of our network.

Wrapping up
I realize that using Windows 2000 Advanced
Server might have a high price tag attached for
a home network user’s solution. However, I
think that not only is this a good large network
solution, but it is also a good SOHO business
solution as well. For the general home user, I
would probably stick to the Sybergen or
Linksys products unless you are planning to do
other things like host a Web or FTP server, in
which case Windows 2000 Advanced Server Click Finish to complete the Routing and Remote Access configuration.
might be the choice for you.

Optimize inbound client connections for your

Windows 2000 VPN servers
Jan 22, 2002
By Dr. Thomas Shinder, MCSE

T
he Windows 2000 Routing And
Remote Access Service (RRAS) allows
you to configure a Windows 2000
Server family computer as a VPN server. The
Windows 2000 VPN server represents a
tremendous improvement over the VPN
server functions available in the Steelhead
release of the Windows NT 4.0 version of the
RRAS VPN server. Windows NT 4.0 VPN
server configuration was tedious and difficult,
and the only tunneling protocol supported was
PPTP. You configure the Windows 2000 VPN
server using easy-to-use wizards, and it sup-
ports both PPTP and L2TP/IPSec as tunnel-
ing protocols.
While the Windows 2000 VPN server is
easy to set up and configure, you should do
several things to make sure you have the most
effective and efficient inbound VPN server
traffic possible for your network. The VPN
Wizard does most of the legwork for you, but
you’ll do more after you run the wizards.
In this article, I’ll explain what you can
focus on to optimize your inbound VPN con-
nections. After reading this, you’ll be ready to
tune your VPN server environment for the
quickest and most secure inbound connections
you can get out of your setup.
Client side
Most Windows 2000 VPN servers allow
inbound VPN connections from external net-
work VPN clients directly connected to the
Internet. Implementing a VPN server allows
you to dispose of your modem banks and
replace them with a single fast connection to

Administration 85
 the Internet. Your remote users don’t need to
make expensive long-distance or 800-number
calls to reach the corporate network. All they
need to do is establish a connection to a local
ISP and then create the virtual link to the
internal network via a VPN client connection.
On the client side, you can focus on three
areas to optimize client connections:
X PPTP client connections
Figure A
Accessing the RRAS’s Properties dialog box
Figure B
Configuring PPP Authentication Methods
86 Administrator’s Guide to VPN and Remote Access, Second Edition
X L2TP/IPSec client connections
X Simplifying client connection setups using
the Connection Manager Administration Kit
PPTP client connections
The VPN Wizard creates a number of PPTP
ports on the external interface of the VPN
server that accept incoming calls from PPTP
VPN clients. PPTP was introduced with the
Steelhead release of the Routing And
Remote Access Server for Windows NT 4.0
(http://www.microsoft.com/ntserver/
techresources/commnet/rras/rras.asp).
The first version of PPTP got some bad press
because of some well-described security holes.
Although Microsoft patched those holes,
PPTP has suffered from a bad reputation as
an unsecure VPN protocol. However, nothing
could be farther from the truth.
The version included with Windows 2000 is
PPTP 2.0. It closes the holes seen with the ini-
tial version of PPTP and includes a number
of performance enhancements. PPTP is the
fastest of the VPN protocols included with
the Windows 2000 VPN server and the easiest
Windows 2000 VPN protocol to set up and
configure. If you’re a beginner at setting up
Windows 2000 VPN servers, you should use
PPTP as your VPN protocol.
PPTP is a secure VPN protocol, but the
level of security is dependent on the complex-
ity of the passwords used by VPN clients. If
your VPN clients choose simple passwords,
hackers and other Internet intruders will be
able to break into the VPN server almost as
easily as they could have with the previous ver-
sion of PPTP. Make sure your clients use com-
plex passwords of at least eight characters. The
passwords should contain letters, numbers, and
symbols. Your network policy should be set so
that passwords are changed periodically. Be
careful not to force password changes too
often, though, as users will balk if they have to
change and remember new, complex pass-
words frequently.
The default PPP authentication protocols
are MS-CHAP and MS-CHAP version 2. MS-
CHAP allows downlevel operating systems to
authenticate with the VPN server. To secure
your PPP logon credentials, you should disable
MS-CHAP authentication and require MS- Figure C
CHAP version 2. To disable MS-CHAP
authentication, perform the following steps:
1. Select Start | Programs | Administrative
Tools | Routing And Remote Access.
2. In the Routing And Remote Access con-
sole (Figure A), right-click on your server
name and click Properties.
3. In the server Properties dialog box, select
the Security tab (Figure B) and click the
Authentication Methods button.
4. In the Authentication Methods dialog box,
remove the checkmark from the Microsoft
Encrypted Authentication (MS-CHAP)
checkbox and click OK.
5. Click Apply and then click OK in the
server Properties dialog box. Restart the Restarting the Routing and Remote Access Server after configuring the PPP
Authentication Method
Routing And Remote Access Service.
Right-click on the server name, select All to the number you require. While you’re
Tasks, and click Restart (see Figure C). changing the PPTP ports, you can also change
Each VPN port configured on the VPN the number of L2TP ports:
server requires system resources. If your 1. In the Routing And Remote Access con-
organization requires a maximum of only 10 sole, expand your server name and then
concurrent VPN connections, it makes little right-click on the Ports node in the left
sense to use up resources required to support pane of the console. Click the Properties
128 PPTP virtual interfaces. To ameliorate this command.
situation, change the number of PPTP ports

Figure D Figure E

Changing the number of PPTP listening ports

Reducing the number of VPN ports

Administration 87
 2. In the Ports Properties dialog box, click on
the WAN Miniport (PPTP) entry and then
click the Configure button (see Figure D).
3. In the Configure Device - WAN Miniport
(PPTP) dialog box, type the number of
desired ports in the Maximum Ports text
box (see Figure E). Click OK after making
the change.
4. If you want to change the number of
L2TP listening ports, repeat the procedure
by clicking on the WAN Miniport (L2TP)
entry. After you have completed configur-
ing the port numbers, click Apply and
then click OK in the Ports Properties dia-
log box.
PPTP is the best protocol for small to
medium-size businesses that don’t want to
implement a Public Key Infrastructure to sup-
port L2TP/IPSec VPN calls. Even if you do
plan to roll out an L2TP/IPSec VPN solution,
it may actually be easier to allow PPTP and
L2TP/IPSec VPN connections to live side by
side for a while so that you can implement
client-side computer certificates and support
downlevel operating systems that are in the
process of being upgraded.
Figure F
Starting the Automatic Certificate Request Setup Wizard
88 Administrator’s Guide to VPN and Remote Access, Second Edition
L2TP/IPSec client connections
If you want the best security Windows 2000
VPN servers have to offer, you’ll want to use
L2TP/IPSec for your VPN client connections.
L2TP/IPSec doesn’t depend on just the user-
name and password information to secure a
connection. L2TP/IPSec clients require com-
puter certificates to authenticate to the VPN
server. Computer certificates cannot be
“guessed” and provide a high level of security
for VPN client connections.
I know many administrators who balk at the
idea of implementing L2TP/IPSec VPNs. It’s
not that they don’t want to use L2TP/IPSec,
it’s just that they’re unfamiliar with setting up a
Certificate Server and configuring Group Pol-
icy to automatically assign client certificates via
auto-enrollment. Once the VPN client com-
puters have computer certificates, creating
L2TP/IPSec connections is a no-brainer.
You can configure a Certificate Server on
your internal network using Microsoft Cer-
tificate Services. After the Certificate Server
is installed and configured, Group Policy is
configured to automatically enroll domain
members and assign machine certificates.
Perform the following steps to enable auto-
enrollment:
 1. On a Windows 2000 domain controller, Figure G
select Start | Programs | Administrative
Tools | Active Directory Users And
Computers.
2. Right-click on your domain name and click
Properties.
3. In the domain Properties dialog box’s
Group Policy tab, click on the domain
Group Policy object and then click Edit.
4. In the Group Policy window, expand the
Computer Configuration, Windows Set-
tings, Security Settings, and the Public Key
Policies nodes. Right-click on the Auto-
matic Certificate Request Settings node,
select New, and click on Automatic Certifi-
cate Request Settings (see Figure F).
Selecting the Computer Certificate Template for auto-enrollment
5. The Welcome page for the Automatic Cer-
tificate Request Setup Wizard will appear. Figure H
Click Next to continue.
6. On the Certificate Template page, select
the Computer certificate option. (Note
that only certificate templates that are
installed on the Certificate Server will be
available on the Certificate Template page.
See Figure G.) Click Next to continue.
7. On the Certification Authority page (see
Figure H), select the certification authority
(CA) that you want to process the request.
You can select multiple CAs, but only the
first one to receive the request will service
the request. Selecting multiple CAs adds a
measure of fault tolerance to the process.
Click Next.
8. On the last page of the wizard, click Selecting the certification authority to process auto-enrollment requests
Finish.
9. Open a command prompt on the Note that this method works for machines
domain controller, type secedit /refreshpolicy that are domain members. You can use the
machine_policy, and press [Enter]. You’ll Web-based certificate request interface to
receive notification that the policy will assign machine certificates to machines that are
be refreshed but that it may take some not members of the domain. In this situation,
time to replicate across multiple domain it’s useful to have a PPTP VPN connection in
controllers. place before moving over to L2TP. Users can
10. When new computers join the domain, connect via PPTP, use the Web-based certifi-
they’re automatically assigned a computer cate enrollment form to obtain a machine cer-
certificate. Existing domain members will tificate, and then use L2TP/IPSec connections
receive a certificate after they restart or after they obtain the certificate. Then at some
during a policy refresh. point, you can shut down the PPTP listening
ports and use only L2TP/IPSec.

Administration 89
 When VPN clients connect to the Windows
2000 VPN server, the default client configura-
tion is to negotiate the type of VPN tunnel.
The VPN client will try L2TP/IPSec first and,
if not successful, try PPTP. You can configure
the client to use only L2TP/IPSec by configur-
ing the client connection properties, like so:
1. Right-click the My Network Places object
on the desktop and click Properties.
2. In the Network And Dial-Up Connections
dialog box, right-click the VPN connection
object and click Properties.
3. In the VPN connection object’s Properties
dialog box, click the Networking tab.
Figure I
Forcing the type of VPN connection to create with the
VPN server
I DON’T SUGGEST THIS, BUT IF YOU HAVE TO…
If you must allow VPN clients to access the Internet at the same
time they’re connected to the VPN server, you can configure the
VPN client connection object to allow this. The key entry is Use
Default Gateway On Remote Network. You’ll find this entry in vari-
ous places, depending on the version of VPN client connection
object you’re using. Once you disable the Use Default Gateway On
Remote Network option, the user will be able to access the Inter-
net and the internal network simultaneously.
90 Administrator’s Guide to VPN and Remote Access, Second Edition
4. On the Networking tab, click the down
arrow in the Type Of VPN Server I Am
Calling drop-down list box, click the
Layer-2 Tunneling Protocol (L2TP) option
(see Figure I), and click OK. Note that if
you want the client to use only PPTP, you
can select Point To Point Tunneling Proto-
col (PPTP) and prevent negotiation for an
L2TP connection.
You may get complaints from your users
regarding their ability to access the Internet
after they establish the VPN link to the corpo-
rate network because a new default route is
added to the VPN client’s routing table. All
Internet-bound requests will be routed
through the VPN link and will cause attempts
to browse the Internet or access Internet
e-mail servers to fail.
This inability to access the Internet while
the VPN link is active is the preferred configu-
ration. You don’t want your clients to access
the Internet at the same time that they access
the internal network; this represents a very
poor security configuration. It would be like
allowing internal network users to add a
modem to their machines so that they can
access the Internet independently of any client
access controls you’ve set on your firewall.
Conclusion
As you work to set up and configure your
VPN, don’t forget that both the clients and the
servers can use some good old-fashioned
tweaking. Although the improvements from
previous versions are significant, the need for
further optimization, as with most Microsoft
products, is necessary in order to make the
best of your VPN server connections.
As VPNs have quickly become the de facto
standard for remote access, it’s critical for sys-
tems administrators to get up to speed on their
optimization. As VPN technology grows and
stabilizes, so should your knowledge of VPN
optimization. Getting rid of MS-CHAP ver-
sion 1, changing the number of L2TP ports,
enabling auto-enrollment, and configuring
clients to use only L2TP/IPSec are sound ways
to get your incoming VPN connections zip-
ping along with speed and security.
VPN networking services built for speed
Feb 19, 2002
By Dr. Thomas Shinder, MCSE
J
ust setting up a VPN with RRAS is not
enough when working in an enterprise-level
environment. For ultimate speed and secu-
rity, you need to optimize both the client-side
and network-side services. For a review of
methods that you can employ on the client
side, check out my article, “Optimize inbound
client connections for your Windows 2000
VPN servers” (page 85).
From the server side, there are several serv-
ices, such as WINS, DNS, and DHCP, you
should configure on the internal network with
your VPN clients in mind. Once you have
these services set up correctly, your VPN client
connections will work as if they were directly
connected to the internal network via an Eth-
ernet cable. Ultimately, that means you’ll get a
lot fewer support calls from your VPN users.
Here, I will explain how you can optimize
WINS, DNS, DHCP, and the routing table and
addressing infrastructure to improve your
VPN clients’ speed and security.
WINS
The Windows Internet (network) Naming
Server (WINS) resolves NetBIOS names to IP
addresses. I’ve heard people say that if you run
a Windows 2000-only network, you don’t need
a WINS server. This is only partially true. The
fact is, you don’t need WINS if you run a Win-
dows 2000 network that doesn’t require any Net-
BIOS services. Unfortunately, many popular
network services are dependent on the Net-
BIOS interface and NetBIOS name resolution.
The most prominent NetBIOS-dependent
service is the browser service. The browser
service is responsible for populating the
browser list, which appears as a list of network
resources (computers) in the Network Neigh-
borhood or the My Network Places applica-
tion. Because the browser service is a
NetBIOS-dependent service, it depends on
local subnet broadcasts to communicate with
other browser service participants.
This creates a problem when your VPN
clients need to browse to resources on subnets
outside of the broadcast range of the VPN
interface on the VPN server. To solve the
broadcast problem, you must install and con-
figure a WINS server on the internal network.
Also, all servers on the network need to be
configured as WINS clients, especially servers
that can act as master browsers on their local
subnet. This also includes the PDC or PDC
emulator for the network, because they collate
and redistribute the browser list.
The VPN client obtains the WINS server
address from the VPN server. This address is
typically obtained from the internal interface
of the VPN server. However, if you have mul-
tiple internal interfaces, you might need to
manually select the interface that assigns name
server addresses. Another option is to have a
DHCP server assign name server addresses to
the VPN client.
While the most common method of assign-
ing IP address and name server information to
VPN clients is via automatic assignment by the
VPN server, you aren’t limited to this option.
The VPN client software can be configured
with static IP and name server addresses. VPN
clients can also be assigned IP addresses on a
per-user account basis. Note that you cannot
assign name servers based on user account.
The WINS server is even more useful for
allowing clients to connect via a UNC path.
The VPN client will query the internal network
VPN CLIENTS NEVER DIRECTLY COMMUNICATE
WITH A DHCP SERVER
Keep in mind that VPN clients are RAS clients, so they never
directly communicate with a DHCP server—not even when you
have configured the VPN server to obtain IP addresses from a
DHCP server. However, your VPN clients can obtain DHCP
options by configuring a DHCP relay agent on the VPN server
itself. DHCP options such as WINS and DNS server addresses
can be assigned this way. One thing you cannot assign to RAS
clients via DHCP options is a default gateway. The VPN clients will
always be assigned a default fault and host route to the IP address
of the tunnel server’s virtual IP address.
Administration 91
 WINS server that was assigned to the VPN
interface on the client, and the WINS server
will return the IP address of the server on the
internal network.
DNS
If you construct your network well, you’ll have
relatively little use for NetBIOS-dependent
applications. The majority of applications used
on current networks aren’t tied to the Net-
BIOS interface; they are native TCP/IP-based
applications. These applications and services
use DNS for host name resolution. Although
DNS doesn’t populate the browser list, it per-
forms a host of other valuable functions for
your VPN clients.
For VPN clients to access Web, FTP, e-mail,
and news services on your internal network
using FQDNs, you want to ensure that DNS is
configured on the internal network. If you are
running a Windows 2000 Active Directory net-
work, you already have a DNS infrastructure in
place. If you aren’t running Active Directory
or DNS on your internal network, you’ll find
that name resolution will proceed much faster
and more reliably after installing DNS and
configuring the VPN client to use the internal
network DNS server.
USE NSLOOKUP TO CONFIRM
DNS FUNCTIONALITY
When setting up your VPN clients to use
the internal network DNS infrastructure,
you should test the configuration before
allowing your users to connect to the VPN.
You can quickly test the VPN client DNS
functionality using the Nslookup tool. Cre-
ate a dial-up connection to the VPN server
and then open a command prompt. Type
nslookup and the fully qualified domain
name of an internal network host, such as
server1.internal.net. Nslookup should
return the proper internal network address
for server1.internal.net.
DHCP
If you work on a network of any appreciable
size, you probably already have a DHCP server
92 Administrator’s Guide to VPN and Remote Access, Second Edition
providing IP addressing information to your
internal network clients. That same DHCP
server or servers can be used to assign IP
addresses to your VPN clients. You can create
custom scopes for your VPN clients to make it
easier to control the IP address assignment to
these machines.
A NOTE ABOUT SCOPES
A scope is a collection of IP addresses that
belong to a particular network ID. When a
DHCP server is configured with a scope, it
can service requests for IP addresses from
clients on that network ID.
The DHCP server can be on the same net-
work as the internal interface of the VPN
server or on a remote network. If you need to
use a DHCP server on a remote network, you
must configure a DHCP Relay Agent, which
acts as a router for DHCP messages. The
VPN server will be able to obtain addresses
for the DHCP clients by taking advantage of
the DHCP message routing capabilities of the
DHCP Relay Agent, which is why the DHCP
Relay Agent is considered a routing protocol.
Installing and configuring the DHCP Relay
Agent on the VPN server is easy. In the RRAS
console, expand your server name and then
expand the IP Routing node. Right-click the
General node and select New Routing Proto-
col. In the New Routing Protocol dialog box,
click on the DHCP Relay Agent entry and
click OK.
The DHCP Relay Agent will appear in the
left pane. Right-click the DHCP Relay Agent
node and select New Interface. Click on Inter-
nal and OK. In the DHCP Relay Properties
dialog box, leave the defaults—unless you
want the DHCP packets to hop more than
four routers—and click OK. Right-click the
DHCP Relay Agent node and open its proper-
ties sheet. In the DHCP Relay Agent Proper-
ties dialog box, type in the IP address of the
DHCP server and then click Add and OK.
The DHCP Relay Agent will now forward
DHCP messages to the DHCP server you
entered in the Properties dialog box.
Note that if you place the DHCP server on
a remote network, the server should have a
NIC installed with an IP address for each net-
work ID for which it has scopes. If you try to
logically multihome the server, all the
addresses will be served from the scope
matching the primary IP address bound to the
network interface. Each interface is connected
to the same physical segment. The Relay Agent
will allow assignment from the appropriate
scope, but DHCP clients on the same physical
segment as the multihomed DHCP server can
receive addresses from any of the scopes.
MULTIHOMED DHCP SERVERS
You can multihome a DHCP server so that
it supports scopes on multiple network IDs.
However, the server must be physically,
instead of logically, multihomed, because
the DHCP server service will bind only the
primary IP address on each interface. The
primary IP address is the IP address on
the top of the list of IP addresses found in
the Advanced tab of the TCP/IP configura-
tion for the interface.
Routing tables
When you have a single network segment on
your internal network, you don’t have to worry
about router issues. The VPN clients can be
assigned IP addresses on the same network ID
as the internal interface of the VPN server and
reach all resources on the local network seg-
ment. However, problems arise when the inter-
nal network has multiple subnets.
If the internal network has multiple net-
work IDs and VPN clients need to reach
resources on these multiple network IDs, con-
figure the routing table on the VPN server.
The VPN clients take advantage of the router
table on the VPN server to reach resources on
remote networks.
If there are only a few internal subnets, and
only a single path to each subnet, you can con-
figure the routing table on the VPN server
manually. The routing table can be configured
using either the Route Add command or by
using the Routing and Remote Access console.
I recommend you use the RRAS console to
create new routing table entries, as the GUI
interface is easier to use and leads to fewer
mistakes in configuration.
Large networks that allow multiple paths to
internal network resources don’t lend them-
selves to static routing table entries. These net-
works require that you use a routing protocol.
The Windows 2000 RRAS supports both the
Routing Information Protocol version 2
(RIPv2) and Open Shortest Path First (OSPF).
RIPv2 is the easiest to configure; it requires
little or no configuration after it’s installed.
RIPv2 supports Variable Length Subnet Mask-
ing (VLSM) and password protection for shar-
ing routing information with its neighbors.
OSPF is a more powerful routing protocol that
provides a great array of routing options, but it
is more complex to configure and shouldn’t be
considered a “plug and play” routing protocol
solution. While RIPv2 is much easier to set up
and configure, it doesn’t scale well, because it’s
a broadcast-based protocol.
Once the VPN server has routing table
entries for all the subnets on the internal net-
work, the VPN clients will be able to reach all
segments on the internal network.
Gateway configuration on
the VPN client
The default Microsoft VPN client configuration
sets the client to use the default gateway on the
remote network. When you select this option, a
new default gateway is set on the VPN client,
which represents a host-based route that sends
all nonlocal packets through the VPN interface.
The change in the default gateway on the client
can cause some sticky issues.
For example, suppose the client is a laptop
computer that isn’t connected to a network
that establishes a link to the Internet using a
dial-up modem interface. The modem creates
a connection to the ISP, which creates a default
route on the laptop so that all nonlocal packets
are sent to the ISP’s router. When the user
establishes the VPN link, a new gateway with a
lower metric is created on the laptop’s local
routing table. All nonlocal packets are routed
through the VPN interface, which makes it
impossible for the laptop to access the Inter-
net and the internal network through the VPN
interface at the same time.
Administration 93
 This should be considered a good thing. It
isn’t very wise to allow VPN clients to bridge
their Internet and VPN connections because
the client can act as a gateway for Internet
intruders to access the corporate network.
This is akin to allowing your corporate net-
work users to attach modems to their desktops
and connect to the Internet while still con-
nected to the corporate network. You don’t let
your internal network desktop users do this,
and you shouldn’t allow it on your VPN
clients either.
However, a workaround for this problem
would be to manually create static routing table
entries on the laptop computers after the VPN
link is established. The reason for this is that if
you use DHCP to assign an IP address to the
VPN clients, you never know what the gateway
address will be for the client’s VPN connec-
tion. To get around the dynamic address
assignment issues, you can assign a static IP
address to a user’s account on the Dial-in tab
of the user account properties. A far superior
solution is to configure the VPN client
machines to use the corporate Proxy/Firewall
servers to access the Internet. Then, you force
the VPN clients to conform to the corporate
Internet security policy.
When a machine connected to the routed
corporate network needs to create a VPN link
to a VPN server on an external network—or
even on the intranet if you are using VPNs to
segregate your security zones—you may have
another issue. The default gateway will change
to the VPN interface and the machine will no
longer be able to access remote subnets on the
corporate network. The solution is to enter
routing table entries for all the subnets on the
machine connected to both the VPN and the
corporate network. You can create static rout-
ing table entries; however, on a large network,
this is unfeasible. A better solution is to enable
a RIP listener on the machine.
To enable a RIP listener on a client
machine, do the following:
X Open Control Panel and click Add |
Remove Programs.
94 Administrator’s Guide to VPN and Remote Access, Second Edition
X Click Add | Remove Windows
Components.
X Click Networking Services.
X Select the Rip Listener check box.
X Click OK.
After the RIP listener is enabled, the
machine will listen for RIP version 1 broad-
casts. So if you’re using only RIPv2, the RIP
listener will not use routing table entries. The
Windows 2000 RRAS server can be configured
to issue RIP v1 and v2 broadcasts to support
machines configured as RIP listeners.
VPN CLIENTS CANNOT BE
CONFIGURED AS RIP LISTENERS
Machines connected to the internal net-
work can be configured as RIP listeners,
because the RIP listener software listens
on the physical interface. The RIP listener
doesn’t listen on the virtual interface. Even
if the RIP routing protocol is installed on
the VPN server, it will not be able to share
routing table information with VPN clients.
The RIP listener isn’t an answer to the
routing table problems that dial-up modem
clients have when connecting to the VPN
server over the Internet.
Conclusion
The Windows 2000 Routing and Remote
Access Service may make it easier to create a
VPN server; however, getting the internal net-
work tuned up to support your VPN clients
takes a bit more effort. The tips in this article
should help you appreciate the importance of
having WINS, DNS, and DHCP servers on
the internal network to support the VPN
clients, and how VPN clients handle routed
internal networks. With this information, you’ll
be ready to begin that VPN rollout that your
boss has been bugging you to get started.
Optimal VPN server configuration
and management
Mar 18, 2002
By Dr. Thomas Shinder, MCSE
T
hough it isn’t difficult to set up a Win-
dows 2000 VPN server for use, a gen-
eral setup doesn’t allow for optimal use
of the server’s resources. However, there are a
number of configurations that you can imple-
ment to help that server reach its full potential.
On the client side, you can enable MS-CHAP
version 2, change the number of L2TP ports,
enable auto-enrollment, and configure clients
to use only L2TP/IPSec.
On the server side, a couple of simple but
powerful actions allow you to optimize con-
nections: using Routing and Remote Access
Service (RRAS) policies and configuring IP
address and name server assignments. Doing
both of these things allows you to increase
your VPN server’s efficiency and blow the
socks off your users.
Using RRAS policies
RRAS policies allow you to simplify and opti-
mize all of your RRAS server connections by
Figure A
centralizing the management of VPN client
connections. To make the most of RRAS poli-
cies, run your Windows 2000 domains in
native mode. This allows you to configure the
policies on a granular basis by configuring the
properties of user accounts. Figure A shows the
available options when a Windows 2000
domain is run in native mode.
Note that Deb Shinder’s user account is
allowed dial-in access based on the Remote
Access Policy. The extant Remote Access Pol-
icy can be specific to a particular VPN server,
or if you decide to use RADIUS for authenti-
cation and accounting, you can have a single
Remote Access Policy apply to all VPN
servers.
To configure an RRAS policy to optimize
your VPN environment:
1. In the Routing And Remote Access con-
sole, expand your server name and click on
the Remote Access Policies node in the left
Figure B
Administration 95
 pane. You can create a new RRAS policy condition, a Windows group membership
or edit the existing RRAS policy. To edit condition, and a Network Access Server
the existing RRAS policy, double-click on port type condition. In this example, con-
the Allow Access If Dial-In Permission Is nections are accepted at any time on any
Enabled policy in the right pane of the day of the week, users must be members
RRAS console. of the TACTEAM\Domain Admins
2. In Figure B, you can see that several condi- group, and the connection type must be a
tions must be met to allow a connection to VPN connection. Only after all these con-
the RRAS VPN server: a day and time ditions are met will the Grant Remote
Access Permission option be activated.
Figure C (This option is seen in the If A User
Matches The Conditions frame.) To add a
condition, click the Add button.
3. The Select Attribute dialog box appears
next (Figure C). To allow only L2TP/IPSec
VPN tunnels for the Domain Admins
group covered in this policy, for example,
select the Tunnel-Type attribute and click
the Add button.
4. In the Available Types column in the Tunnel-
Type dialog box, select the Layer Two Tun-
neling Protocol (L2TP) entry and click the
Add button. The entry will then move to
the Selected Types column (Figure D).
5. The condition now appears in the pol-
icy’s properties dialog box (Figure E). Click

Figure D Figure E

96 Administrator’s Guide to VPN and Remote Access, Second Edition

Figure F
Deselecting MS-CHAP forces the server to use MS-CHAP version 2
for the Remote Access Policy.
Edit to change the profile settings for
this policy.
6. In the Edit Dial-In Profile dialog box, click
the Authentication tab (Figure F). The
default settings allow both MS-CHAP
and MS-CHAP version 2. Deselect the
Microsoft Encrypted Authentication
(MS-CHAP) check box.
7. Select the Encryption tab. Since domain
administrators will carry out the most
security-sensitive operations, you might
want to force 128-bit encryption for all
their sessions. Deselect the Basic and
Strong check boxes, leaving only the
Strongest encryption option selected
(Figure G). This will force 128-bit encryp-
tion on all connections matching the con-
ditions of this Remote Access Policy. Click
Apply and OK to accept the changes you
have made to the policy’s profile.
8. Then, click Apply and OK to accept the
changes you made to the RRAS policy.
You can create multiple RRAS policies to
meet the specific needs of your organization.
Figure G
In the above example, I set some stringent set-
tings on connections made by domain admins.
You might want to create other policies for dif-
ferent groups of users, which require different
VPN tunnel types, time of day requirements,
and levels of encryption.
Configuring IP address and name
server assignments
There are two ways VPN servers can assign
addresses to clients: via a DHCP server or via
a static address pool.
To assign addresses via DHCP, it is impor-
tant to note that your RAS VPN client never
directly communicates with the DHCP server.
The VPN server obtains the IP addresses used
for VPN client assignments during VPN
server boot-up. If the VPN server uses all the
available addresses it obtained during boot-up,
it will obtain extra blocks of IP addresses from
the DHCP server ad libitum. The RRAS server
doesn’t assign any DHCP options. However,
you can install a DHCP Relay Agent on the
RRAS server to assign a limited set of DHCP
options to VPN clients.
Administration 97
 A static address pool can be configured on
the VPN server, and IP addresses can be
assigned to VPN clients from this pool. If you
choose the static address pool option, make
sure internal network clients are not using the
addresses in the pool. You’ll also make life
simpler if you choose a range of addresses
that are on subnet—on the same network ID
as the internal interface of the VPN server.
You don’t need to use DHCP options to
assign name servers to VPN clients, because
the RRAS server will automatically assign
WINS and DNS server addresses to VPN
clients based on the WINS and DNS server
settings on the internal interface of the VPN
server. This name server assignment takes
place during the Internet Protocol Connection
Protocol (IPCP) negotiation process. If you
have multiple internal interfaces on the VPN
server, you can manually select which interface
will be used to assign name server addresses to
VPN clients.
Figure H
To configure address assignment:
1. Right-click the server name in the Routing
And Remote Access console and click
Properties.
2. Click on the IP tab (Figure H). The default
setting is to use DHCP for IP address
assignment. If you need to use a static
address pool, select the Static Address
Pool option and click Add to add a range
of IP addresses. The Enable IP Routing
check box should be selected if you want
the VPN clients to access servers on the
internal network. If it’s not selected, VPN
clients will be able to access only resources
on the VPN server itself. The Allow IP-
Based Remote Access And Demand-Dial
Connections option must be selected if
you want the VPN server to assign
addresses to the VPN clients.
3. The RRAS server determines which inter-
face should be used to assign name server
settings; however, it sometimes gets things
wrong. If it does, click the down-arrow on
the Adapter drop-down list and manually
select the adapter that should be used for
WINS and DNS server assignments to
VPN clients. The VPN clients will be con-
figured with WINS and DNS server
addresses that are configured on the inter-
face you select. Click Apply and OK to
accept the changes.

Conclusion
Using RRAS and configuring IP addresses
and name server assignments allows you to
further tune the settings on your Windows
2000 VPN server and create a VPN environ-
ment that meets the requirements of your
organization. Doing so can make your job go
a little smoother and your end users happy
campers.

98 Administrator’s Guide to VPN and Remote Access, Second Edition

Troubleshoot Windows RAS and VPN
connections with these tips
Oct 19, 2001
By Carol Bailey, MCSE+I
M
anaging remote access servers
can be among the most high-
maintenance activities that any
administrator has to juggle. Simply put, tons of
things can go wrong that prevent a user from
connecting, stop a user from accessing network
resources, or slow down the user’s connection.
However, many of these problems are
beyond the administrator’s immediate control,
such as client configuration difficulties, hard-
ware problems at the remote user’s end, issues
with the user’s ISP (if connecting over a VPN),
and Internet bandwidth problems.
In my experience, once a RAS server is up
and running, subsequent reported problems
tend to be user-related issues rather than
server problems. Nevertheless, you can bet
users will contact you and complain about
problems with the RAS server(s). And when
they do, you usually have to confirm that
everything is working as expected on the
server side before they will doubt their end of
the connection.
I’ve had many frantic calls from remote
users complaining that the RAS server is down
and must be fixed immediately because it is
imperative for them to do their work, and only
after I’ve proved that the problem is not with
the RAS server have they looked a little closer
to home and found the problem.
So what can you do to streamline the trou-
bleshooting process? I’ve put together some
tips that can help with this time-consuming
exercise.
Gather timely information
When a user complains that the RAS server is
down, the most obvious thing to check is that
the server is running and that the RAS service
is started. Most admins check this by pinging
the server and then connecting to the server to
verify that the RAS service is up.
Of course, you can do this from your work-
station rather than physically on the server
itself. But a quicker and more elegant solution
is to run the RAS Server Monitor (Rassrv-
mon.exe) from the Windows 2000 Resource
Kit (http://www.microsoft.com/win-
dows2000/techinfo/reskit/default.asp),
which, unfortunately, works only with Win-
dows 2000 RAS servers and not with NT4
RAS servers.
You can have the utility running perma-
nently on your workstation so that you can
quickly check the server’s status with the util-
ity’s GUI, or you can run it on another com-
puter and leave it to collect the monitored
information to file. You can then check the
information ad hoc. If you have multiple RAS
servers, you should have multiple instances of
the RAS Server Monitor—one for each server.
This utility produces three files, which all
have the base name of the server (name or
address) that you provide when you load the
utility, with the extensions .webstatus, .userlist,
and .userdetails. The .webstatus file is designed
to be posted on a Web server, so you can pub-
lish the current status of your RAS server on
your company intranet. This includes informa-
tion such as the number of currently con-
nected users, total calls, total bytes transferred,
and the total and peak number of connections.
The .userlist and .userdetails files provide more
details on each connection made and include
information such as user name and worksta-
tion name, the IP address allocated and type of
port used, the number of bytes transferred,
the first and last connection, the connection
duration, and the line speed.
As a background task, you can also config-
ure the RAS Server Monitor to alert you if it
detects problems, so that you will know about
them before a user contacts you. The first
alerting service monitors whether the RAS
service is up by sending the MprAdmin-
PortEnum API to the server you specify. A
failure to respond means the service or server
is down. You configure the alert (for example,
Administration 99
 send an e-mail message or log an error) by
running a program of your choice when the
number of failed responses continues over a
period of time. By default, this time period is
10 minutes.
The second alerting service monitors for
inactive RAS connections over a specified time
period. Obviously, there may be legitimate rea-
sons for this inactivity (for example, overnight
hours and quiet periods during popular vaca-
tion times), but on RAS servers that are usually
busy during the day, it could indicate that
there’s a problem with the line(s), which would
not be detected by the service API monitor.
Does the user have dial-in
permission?
If you’re running RAS servers in a native-
mode Active Directory domain, you can use
the new permission Control Access Through
Remote Access Policy on all user accounts so
that dial-in permissions are always kept cen-
trally on your RAS servers as part of your
Remote Access Policies. However, if you are
still using NT4 RAS servers or your Active
Directory is not in native mode, you will need
to grant the dial-in permission on each user
account.
It can be quite tedious and time-consuming
to individually check this on multiple accounts.
One way to ease the burden a bit is to make it a
regular administrative task to use the Resource
Kit tool RASUsers to output a list of all users
on a server or domain that have been granted
this right. You can then import this informa-
tion into a database or spreadsheet, making it
very quick to search and confirm whether a
user account has been granted that right.
Are Remote Access Policies
preventing users from
connecting?
Windows 2000 Remote Access Policies are
great for granular control of user permissions
and connections. However, they can also be a
pain to support, and they can get so complex
that it’s difficult to figure out which policy is
being used, and thus, which condition is
responsible for a failed connection.
100 Administrator’s Guide to VPN and Remote Access, Second Edition
My first tip here would be to make sure that
you know how the administration modes work
for Remote Access Policies, use the simplest
policies you can, bear in mind the order of
processing, and document your choices (per-
haps with a flowchart to show their decision
criteria for allowing connections).
My second tip—particularly when using
multiple RAS servers—is to centralize authen-
tication with Windows 2000’s Internet Authen-
tication Service (IAS), even if you have to load
it on the same machine as Win2K RRAS. This
is because IAS will record which Remote
Access Policy is being used with each connec-
tion in the Event Log, which makes it much
easier to troubleshoot policy problems.
Is your firewall preventing VPN
users from connecting?
If you have VPN connections using PPTP, you
will need to allow TCP port 1723 and IP pro-
tocol port 47 to pass through your firewall. If
you are using L2TP/IPSec, you will need UDP
port 500 and IP protocol port 50 to pass
through the firewall. If you are using AH as
well as ESP in your IPSec policies, you will
also need IP protocol port 51 to pass.
You can use the Windows 2000 Resource
Kit utility PPTP Ping to confirm that this pro-
tocol is working between client and server.
Simply install pptpsrv.exe on the RAS server
and install pptpclnt.exe on the client. Issue the
command pptpclnt <ip address of VPN server>
on the client. If the protocol reaches the
server, the server will display a successful mes-
sage. If port 1723 is blocked or if port 1723 is
open but protocol 47 is blocked (the most
common configuration mistake with firewalls),
this will be reported as an error since there will
be no connectivity taking place.
In the early stages, when you are testing
your VPN server, the simplest way to check
the viability of the VPN server itself is to
eliminate the firewall by setting up a client
VPN connection over Ethernet rather than
over the Internet. If this doesn’t work when
there is no firewall between the server and the
client, you can’t blame the firewall for the con-
nection problem.
Are certificates preventing
L2TP/IPSec users from
connecting?
When it comes to troubleshooting L2TP/
IPSec connections, I would put problems with
certificates at the top of the list of potential
problems. Verify that both client and server
have a Certificate Authority (CA) in common
and that both have been issued with a valid
computer certificate from this CA. If the cer-
tificates have been issued outside Active Direc-
tory, it’s particularly important to ensure that
the certification path has been installed and
the system date/time is correct on both
computers.
Are there performance problems?
There are a hundred and one reasons for con-
nections not going as quickly as users would
like, but one of my tips is to give remote
clients LMHOSTS and/or HOSTS files that
contain the domain name and the main
servers, such as domain controllers, WINS
servers, and any servers the user needs for
network resources. This should reduce any
problems that might be caused by name reso-
lution issues.
If you think poor performance could be
due to overstressing your RAS server, use the
Performance Monitor counters to keep an eye
on memory and processor metrics. PPTP will
incur more processing than PPP (because of
the encryption), and L2TP/IPSec will be
higher still (because of the IPSec processing).
If you suspect the additional stress of run-
ning L2TP/IPSec is responsible for poor per-
formance, look to see whether you are using
3DES encryption on most connections (the
default for 128-bit versions). If so, consider
disabling the default L2TP/IPSec policy and
configuring your own policy that uses DES
rather than 3DES. You could also invest in a
network card that offloads some of the IPSec
processing.
The RAS Server Monitor also provides sta-
tistical information you might find useful here,
such as peak connection time, total connect
time, and total bytes transferred. You can use
its sister utility, Reportgen, to provide reports
from the information produced by Rassrv-
mon, which can help provide trend analysis to
help you determine whether reports of poor
performance are linked to high usage.
Prevent user misconfiguration
problems
If possible, discourage or prevent most users
from changing their RAS settings if their con-
figuration is working. (Windows 2000 Local
Group Policies are fantastic for enforcing this.)
However, when a user has to configure a con-
nection from scratch, this is another matter.
You may find that deploying preconfigured
connections with a dialer program is a worth-
while investment of time.
Windows 2000 Server now ships with Con-
nection Manager Administration Kit (CMAK),
which allows you to preconfigure remote
access connections for your users and cus-
tomize the configuration with your own com-
pany logos, etc. You can include a static
address book for your RAS server details or, if
you think your RAS server details may change,
you can supply the phone book as an auto-
matic download that will update clients with
any changes. You’ll find details for using
CMAK at http://www.microsoft.com/
WINDOWS2000/en/server/help/cmak_
ops.htm.
Contingencies
Many network admins prefer VPN connec-
tions over dial-up modems these days because
they have many cost advantages and it’s easier
to run multiple simultaneous connections,
which eliminate the need for modem banks.
However, consider keeping some PPP ports
in case users have problems connecting over the
VPN—for example, if their ISP is having prob-
lems. Because these dial-up connections use
Point-to-Point rather than the Internet, they also
offer a more secure medium, which means that
you may consider configuring them with lower
security options, such as CHAP authentication
for non-Windows clients and no encryption for
better throughput. If you are using Windows
2000 Remote Access Policies, you can easily
configure the security settings for these different
connections based on the port type being used.
Administration 101
 Summing up
Running a trouble-free RAS service isn’t easy,
but I hope these tips and tools will help you
streamline troubleshooting this important
service. The tips have included gathering
timely information on your RAS servers’ sta-
Learn why NAT can cause VPN
connection problems
Nov 8, 2001
By David Davis, MCSE+I, CCNP, SCSA
M
any a network administrator has
tried to set up a virtual private net-
work (VPN) client from a worksta-
tion with a nonroutable (private) IP address
only to find out—amid much frustration—
that the network address translation (NAT) on
the Internet router keeps the VPN client from
making the connection. We’re going to look at
the reasons behind this common problem and
see what you can do about it.
Important concepts
First, here are four basic concepts you need to
understand:
X Encapsulation involves wrapping a header
around a data unit, typically an IP packet.
Encapsulation can also be referred to as
tunneling. For instance, IP packets get
encapsulated in a frame-relay header when
they traverse a frame-relay WAN.
X Encryption provides a way to secure sensi-
tive data by translating it into private code.
It can then be decrypted only by using a
secret key or a password.
X A VPN encapsulates and encrypts packets
to send a private network’s data over a pub-
lic network (such as the Internet) to another
private network. Point-to-Point Tunneling
Protocol (PPTP), Layer 2 Tunneling Proto-
102 Administrator’s Guide to VPN and Remote Access, Second Edition
tus, verifying dial-in permission and Remote
Access Policies, firewall configuration, cer-
tificate verification, performance improve-
ments, preconfiguring connection details for
users, and having some contingency plans to
call upon.
col (L2TP), and IP Security (IPSec) are the
most popular protocols for securing VPN
traffic.
X NAT is based on RFC1631 (http://www.
rfc-editor.org/rfc/rfc1631.txt) and is typi-
cally used to connect a private network to a
public network, such as connecting your
company network to the Internet. For more
information, refer to Cisco’s article “How
NAT Works” (http://www.cisco.com/
warp/public/556/nat-cisco.shtml). Keep
in mind that to function, NAT doesn’t just
swap IP source and destination addresses,
but it may also swap TCP source and desti-
nation ports, change the IP and TCP header
checksums, change the TCP sequence and
acknowledgment numbers, and change IP
addresses contained in the data payload.
VPN protocols
Now we need to look at a few of the impor-
tant differences between the two VPN tunnel-
ing methods:
X IPSec and L2TP—These two open proto-
cols are popular across multiple platforms.
However, they usually encapsulate and
encrypt the IP datagram, which contains the
IP source and destination addresses. This
can make them troublesome for NAT.
 IPSec can work in two different ways: trans-
port and tunnel. Transport mode is between
a client and a server. Tunnel mode is
between two IPSec tunneling gateways (for
instance, two routers or servers). In trans-
port mode, the application headers,
TCP/UDP headers, and data are encrypted,
leaving the IP headers exposed. The
authentication data is calculated based on
the values in the IP header (among other
things). In tunnel mode, the entire packet
(including the IP headers) is encrypted and
new IP headers are appended.
X PPTP—This Microsoft propriety protocol
does not encapsulate or encrypt the IP data-
gram, which makes this protocol compati-
ble with NAT, or “NAT friendly.” Windows
2000 RRAS (Routing and Remote Access
Services) uses this VPN protocol by default.
If you are using NAT, choosing Windows
2000 VPN (RRAS) services with PPTP can
greatly simplify your VPN-NAT issues.
NAT and VPN
NAT is supposed to be transparent to what-
ever applications it works with. Many NAT
and VPN dilemmas are created by this
assumption. NAT can break a VPN tunnel
because NAT changes the Layer 3 network
address of a packet (and checksum values),
whereas the tunneling, used by an IPSec or
L2TP VPN gateway, encapsulates/encrypts
the Layer 3 network address of a packet with
another Layer 3 network address, stripping it
off on the other side.
In other words, after a packet goes through
the NAT process, it has a different network
address. But after a packet goes through the
IPSec or L2TP VPN tunneling process, it has
the same network address. This concept is
invaluable when setting up and troubleshoot-
ing NAT and VPN together.
As I said, choosing PPTP can often elimi-
nate the NAT-VPN issues created with IPSec
and/or L2TP. However, if you are trying to
create a tunnel through the Internet between
two Cisco routers (or other non-Microsoft
devices or operating systems), you will likely be
using IPSec. If you are using IPSec with NAT
on a Cisco router, you can get around the
VPN-NAT issues by selecting the traffic that is
to be NATed and making sure that that traffic
is not NATed but encapsulated and encrypted
in the IPSec header.
In other words, you want the traffic bound
for true Internet destinations to be NATed,
and you want the traffic destined to travel
through the IPSec tunnel to be tunneled, not
NATed. On Cisco equipment, this is accom-
plished using an access control list.
Let’s return to our original scenario of the
troubled network administrator who config-
ures a workstation with a private IP address
and tries to use a VPN client to go through a
NAT-enabled router. We’ll assume that the
administrator is using an IPSec-based VPN
client (not PPTP). Because this is from a client
to a server, this means that the admin is using
IPSec in transport mode.
Remember that in transport mode, the IP
header is not encrypted but exposed. However,
the authentication data is calculated based on
the values in the IP header (among other
things). When the packets arrive at the NAT
router, the IP headers are modified (NATed).
Upon arriving at the VPN server, the authenti-
cation data in the packet is invalid because the
IP header information was modified by NAT.
So the VPN server drops the packet, and the
VPN client never gets connected.
To deal with this issue, VPN product ven-
dors are beginning to build IPSec NAT tra-
versal capabilities into their products. Different
standards and vendor implementations are
being used to make this work. Most rely on
some kind of IPSec encapsulation into UDP
packets. Because the IPSec packet is now
encapsulated, NAT devices do not affect the
packet’s IP header information, and the IPSec
authentication data is still valid. Thus, a con-
nection can be made.
Final word
This is a complex topic that should not be
taken lightly. Understanding how NAT and the
different VPN implementations do what they
do is crucial. You should also check with your
router and VPN vendors for specific solutions
Administration 103
 that their products may have for dealing with
NAT and VPN interoperability.
Cisco provides the following sample net-
work configurations and scenarios that can
help to better understand and manage NAT-
VPN issues:
X “Configuring Router to VPN Client,
Mode-config, Wild-card Pre-shared Key
with NAT”
(http://www.cisco.com/warp/public/
707/25.shtml)
X “Configuring an IPSec Tunnel through a
Firewall with NAT”
(http://www.cisco.com/warp/public/
707/ipsecnat.html)
X “Configuring a Router IPSec Tunnel
Private-to-Private Network with NAT
and a Static IP Address”
(http://www.cisco.com/warp/public/
707/static.html)
Create a gateway-to-gateway VPN with
ISA Server 2000
Sep 24, 2001
By Dr. Thomas Shinder, MCSE
V
irtual private networks (VPNs) allow
you to connect to private network
resources over the Internet. The VPN
link mimics the connection you would have if
all devices were directly connected to your pri-
vate LAN. The difference is that instead of
connecting directly to the private network,
devices connect first to the Internet and then
establish the virtual link that creates the con-
nection to your private network.
The most common implementation of
VPNs is allowing a client computer, such as a
Windows 2000 Professional notebook, to
make a connection to the Internet and then
establish the VPN link. After establishing the
104 Administrator’s Guide to VPN and Remote Access, Second Edition
X “Configuring Router-to-Router Dynamic-
to-Static IPSec with NAT”
(http://www.cisco.com/warp/public/
707/ios_804.html)
X “Configuring IPSec Router-to-Router,
Pre-shared, NAT Overload Between
Private Networks”
(http://www.cisco.com/warp/public/
707/overload_private.shtml)
X “Configuring IPSec Router-to-Router with
NAT Overload and CiscoSecure VPN Client”
(http://www.cisco.com/warp/public/
707/ios_D.html)
VPN link, the computer becomes a member to
the private network. The client then will be
able to access resources on the network, such
as printers and shares, just as if it were directly
connected.
A less common, but important, implemen-
tation of VPNs is to use them to connect
entire networks to one another. The VPN link
acts like a routed connection that allows clients
on both sides to access resources on the oppo-
site side. Communications move through the
Internet but are protected by the encryption
provided by the tunneled connection.
You need a VPN server on each end of
the link to create this type of VPN. The
configuration is most frequently referred to as
a gateway-to-gateway VPN. The gateway-to-
gateway VPN allows messages to be routed
from one network to the other with a secure
encrypted tunnel over the Internet.
Configuring a gateway-to-gateway VPN in
Windows 2000 is not for the faint of heart. In
this article, we’ll look at how to make the
process of creating the gateway-to-gateway
VPN easier by using ISA Server 2000 (ISA
Server). ISA Server makes it easy to create a
gateway-to-gateway VPN with VPN wizards
that actually work.
Preparing for the VPN
A lot of people have trouble getting a VPN to
work correctly the first time they implement
one. The main reason is that they forget that a
gateway-to-gateway VPN is just like any other
routed connection. The ISA Server acts like a
router; therefore, you have to configure your
network to support a routed infrastructure.
In a routed network, you need to address
issues related to:
X DNS host name resolution
X NetBIOS name resolution
X Routing tables
If the two networks host different internal
network domains, you need to configure DNS
to support name resolution for both sides. You
can do this in a number of ways. You could
make DNS servers on each side secondary
servers of one another. You could also create
referral records for nonlocal domains on each
of the DNS servers that point to the DNS on
the opposite side of the link.
NetBIOS name resolution is handled by a
WINS server. Since the connection is a routed
link, NetBIOS name broadcast queries will not
traverse the VPN. Make sure there is a WINS
server on each side of the link. You should
configure the WINS servers to be replication
partners if you wish to resolve NetBIOS
names for machines on the opposite side of
the VPN.
In a single-segment network, all machines
will have the internal interface of the ISA Server
set as their default gateway. On a multiple-
segment network, you will need to configure
routers to forward Internet-bound traffic to
the internal interface of the ISA Server. In
addition, you will need to configure the net-
work routers to forward traffic destined for the
network ID of the remote network on the
other side of the VPN to the internal interface
of the ISA Server.
Configuring the VPN connection
When using ISA Server to create the gateway-
to-gateway VPN connection, you must use two
wizards:
X The Local VPN Wizard
X The Remote VPN Wizard
The Local VPN Wizard is run at the loca-
tion that will receive the calls from remote
VPN servers. This wizard is usually run on the
ISA Server at the central office, after which it
will be ready to accept calls from an ISA
Server at a remote, branch office.
The Remote VPN Wizard is run at the
remote location—the location initiating the
calls. The Remote VPN Wizard uses informa-
tion collected by the Local VPN Wizard to
create the connection.
BIDIRECTIONAL VPN
COMMUNICATIONS
The Local VPN Wizard is run on the
machine that will accept inbound calls from
the remote VPN server. However, you can
tell the Local VPN Wizard to allow both
sides to initiate a call.
Running the Local VPN Wizard
The first step is to run the Local VPN Wizard.
Perform the following steps to configure the
local VPN Server:
1. Open the ISA Management console.
Expand your server or array and right-click
the Network Configuration node in the
left pane. Click the Set Up Local ISA VPN
Server command.
2. On the Welcome To The Local ISA Server
VPN Configuration Wizard page, click
Next to continue.
3. The ISA Server Virtual Private Network
(VPN) Identification page will appear.
Administration 105
 In the Type A Short Name To Describe
The Local Network text box, type a short
(less than 10 characters is safe) name for
the local network. In this example, we’ll
call it local. In the Type A Short Name To
Describe The Remote Network text box,
type in a short name for the remote net-
work. In this example, we’ll call it remote
(Figure A). Click Next.
4. The ISA Server Virtual Private Network
(VPN) Protocol page will appear. You
have three choices:
Figure A
Naming the VPN connection
Figure B Figure C
Selecting the tunnel type Configuring bidirectional call initiation
106 Administrator’s Guide to VPN and Remote Access, Second Edition
5. Use L2TP Over IPSec.
6. Use PPTP.
7. Use L2TP Over IPSec, If Available.
Otherwise, Use PPTP
In this example, we will select Use L2TP
Over IPSec, If Available. Otherwise, Use
PPTP (Figure B) because it gives us the most
flexibility in establishing the connection. Gen-
erally, you will want to use IPSec for your gate-
way-to-gateway tunnels, but it is helpful to
have PPTP available for initial testing. You can
remove the PPTP packet filters after you have
confirmed that your VPN is functioning and
that your IPSec configuration works properly.
Click Next.
1. The Two-Way Communication page will
appear next. If you wish to allow both ends
to initiate a call, put a check mark in the
Both The Local And Remote ISA VPN
Computers Can Initiate Communication
check box. If you do not, only the remote
VPN server will be able to initiate a call. In
the top text box, enter the IP address of
the FQDN of the remote ISA Server. In
the bottom text box, enter the NetBIOS
name of the computer or the NetBIOS
name of the domain (if the machine is a
domain controller). In this example, we will
allow bidirectional initiation of calls. We
will use gateway.tacteam.net as the FQDN
Figure D Figure E

Configuring access to the remote network IP addresses Configuring the local network IP addresses

of the remote gateway and type in the Figure F

domain name of the remote VPN server,
TACTEAM (Figure C). Click Next.
2. On the Remote Virtual Private Network
(VPN) Network page, enter the IP address
range of the remote network. If you do
not want access to all computers on the
remote network, enter the IP addresses of
the individual machines that you want
access to. To add the address ranges, click
the Add button. In this example, we’ll
allow the local network to access all the
machines on the remote network ID
192.168.9.0/24 (Figure D). Click Next.
3. The Local Virtual Private Network (VPN)
Network page will appear next (Figure E).
Select the external address of the ISA Naming the configuration file and creating a password

Server to which the remote ISA Server will

connect. Confirm that the entries for the
local network ID ranges are correct and
click Next.
4. The ISA VPN Computer Configuration
File page will appear. You’ll use this file to
create the remote VPN server. Type a path
and file name in the File Name text box.
Then, type in and confirm the password
(Figure F). You can save this to a floppy
disk to carry with you to the remote site or
you can save it to the hard disk and e-mail
it to an administrator at the remote site.
Click Next.
5. On the final page of the wizard, click the
Details button to review the changes made
to your machine. If the Routing and Remote
Access service has not been started, the wiz-
ard will start it and make the configuration
changes noted in the Details. Click Finish.
Running the Remote VPN Wizard
Running the Remote VPN Wizard is simple
because you already made all the configuration
decisions when you ran the Local VPN Wiz-
ard. To run the Remote VPN Wizard, perform
the following steps:

Administration 107
 1. Open the ISA Management console,
expand your server or array, and right-click
on the Network Configuration node in
the left pane. Click Set Up Remote ISA
VPN Server.
2. On the Welcome to the Remote ISA
Server VPN Configuration Wizard page,
click Next.
3. The ISA VPN Computer Configuration
File page appears next. Type in or browse to
the file name. After selecting the file, type
in the password (Figure G) and click Next.
4. The Completing The ISA VPN Configura-
tion Wizard will appear (Figure H). Click the
Figure G Figure H
Running the Remote VPN Wizard Completing the Remote VPN Wizard
Troubleshoot ISA Server VPN connections
Jun 24, 2002
By Dr. Thomas Shinder, MCSE
W
hen working with ISA Server con-
figured to run a VPN, trouble-
shooting the VPN problems can
be one of the most difficult tasks you’ll
encounter. The ISA Server’s VPN Wizards do
most of the work when creating the VPN
108 Administrator’s Guide to VPN and Remote Access, Second Edition
Details button to see the changes that will
be made to the server. You may also wish
to select the check boxes that will open the
Help files on how to configure demand-
dial interface and IP packet filters. Click
Finish to complete the wizard.
Once the Local and Remote VPN Wizards
have been run, users on either side of the
VPN will be able to initiate a demand-dial con-
nection to the remote network. You can con-
figure the demand-dial interface to drop the
connection after a period of idleness or to be a
permanent connection.
server or VPN gateway, but they can’t help
you resolve VPN problems. By learning about
the problems you might face and how to fix
them, however, you’ll be better prepared to
face the challenge should problems arise. In
this article, I’ll show you how to identify and
troubleshoot problems with ISA Server VPN
connections.
What kind of problems can
I expect?
Most ISA Server VPN problems are related to
VPN server or VPN client configuration and
not to the actual ISA Server setup. This is
because the ISA Server software does very lit-
tle in relation to VPN connections. The only
thing the ISA Server does when you run the
ISA Server VPN Wizards is create the packet
filters to support the VPN protocols. The
Routing And Remote Access Service (RRAS)
handles all other components of the VPN.
Some common VPN configuration and
management errors you may encounter
include:
X Name resolution issues
X IP addressing problems
X VPN client configuration problems
X VPN gateway issues
X Authentication and encryption errors
Once you get a handle on these areas, you’ll
be in good shape to have a smoothly running
ISA Server VPN server.
Name resolution
Name resolution issues are common with ISA
Server running a VPN server. The biggest
problem occurs when the ISA Server adminis-
trator doesn’t have a network infrastructure to
support the ISA Server solution. You can eas-
ily handle the problem by installing and config-
uring the appropriate network services.
NetBIOS
If you have problems with NetBIOS name
resolution, the obvious solution is to configure
a WINS server. A WINS server is required if
you want your VPN clients to resolve the Net-
BIOS names of machines on the internal net-
work, because the VPN client cannot use
NetBIOS broadcasts to resolve NetBIOS
names on the internal network.
You can manually or automatically config-
ure the VPN client with an address of a VPN
server on the internal network. An alternative
is to configure an LMHOSTS file on each
VPN client. LMHOSTS files are an inferior
solution because they aren’t dynamically
updated. If machines on the internal network
use DHCP for IP address assignment, the
LMHOSTS file will be worthless. However, if
you use static addresses for network servers,
the LMHOSTS file can be a viable alternative.
DNS
An alternative to NetBIOS name resolution is
DNS host name resolution. VPN clients can
use a DNS server that is manually or dynami-
cally assigned to them. They can query the
internal network DNS server to resolve host
names on the internal network. The problem
most VPN clients run into when it comes to
hosting name resolution on the internal net-
work occurs when the VPN clients try to
resolve unqualified names on the internal net-
work. This becomes an issue when the VPN
client wants to use DNS host name resolution
to resolve the NetBIOS names on the internal
network.
When the VPN client sends an unqualified
request to the DNS server on the internal net-
work, the DNS resolver on the client typically
appends the VPN client’s domain name to the
request. If the client is configured with an
inappropriate domain name or no domain
name at all, the request for name resolution
will fail. If the internal network DNS server is
configured to use a WINS server for name res-
olution, the request may succeed. But in that
case, you should just assign a WINS server
address to the VPN client in the first place.
When using ISA Server, VPN clients get
their name server addresses from the settings
on the internal interface of the VPN server or
from a DHCP server on the internal network.
If you configure a static address pooling for
the VPN clients, the clients obtain their name
server address from an internal interface on
the VPN server. If the VPN server had multi-
ple internal network adapters, you’d need to
choose the one that has the name server
addresses that you want assigned to the VPN
clients. You can configure which adapter to use
for name server assignment by looking at the
Properties page of the VPN server. Click the
IP tab on the Properties page. Make sure the
Administration 109
 Adapter field at the bottom of the IP tab is set
to Internal, as shown in Figure A.
DHCP
Your other option is to use a DHCP server on
the internal network. When your ISA Server is
configured to run as a VPN, make sure you
install and configure the DHCP Relay Agent
on the VPN server computer. VPN clients
never directly communicate with a DHCP
server because the VPN server doesn’t pass
broadcast messages from VPN clients to the
internal network. The DHCP Relay Agent will
proxy for the VPN clients and allow them to
receive DHCP options.
One thing that definitely won’t work with-
out a WINS server is the browser service. If
your users need access to a network server
browser list, you must install a WINS server
and configure the VPN clients to obtain the
WINS server address.
IP addressing
VPN clients can get an IP address from a static
address pool or from a DHCP server on the
internal network. You can configure a static
address pool in the same dialog box seen in
Figure A. Make sure that the addresses in the
static address pool aren’t already in use on the
Figure A
Select the interface that you want to assign name server
addresses.
110 Administrator’s Guide to VPN and Remote Access, Second Edition
network and that they aren’t assigned to a
scope on any of your DHCP servers.
You can also use a DHCP server to assign
addresses to VPN clients. The RRAS server
will obtain addresses from a DHCP server
when the RRAS server starts up. The server
will obtain more addresses when needed, how-
ever, the RRAS server doesn’t retain any
DHCP options. The only way to assign DHCP
options, such as WINS address, DNS address,
and domain name, to VPN clients is to install
and configure the DHCP Relay Agent on the
VPN server.
You can assign VPN clients on-subnet and
off-subnet addresses. On-subnet addresses
are those that match the same network ID as
the internal interface of the ISA Server. On-
subnet addresses are easiest to manage,
because VPN clients have a valid IP address
for the network ID that the VPN server is
directly attached to.
You can also use off-subnet network
addresses for the VPN clients. In this instance,
the VPN clients are assigned IP addresses that
are not on the same network ID as the internal
interface of the ISA Server. This can be a use-
ful security measure. If the network routing
infrastructure isn’t set up to support the off-
subnet addresses that you assign the VPN
Figure B
Select the VPN interface on which you want to use the Web
Proxy service.
clients, the only resources the VPN clients will
be able to access are on the VPN server itself.
Whether you use on-subnet or off-subnet
addressing on the VPN clients, it’s critical that
you configure the routing table on the VPN
server with the appropriate network IDs on
your internal network. If there are networks
you don’t want the ISA Server to reach, leave
them out of the routing table, but all other
networks must be included in the routing table.
If you use off-subnet addresses for VPN
clients, you must configure the routers on
the network to forward responses to the off-
subnet network ID to the internal interface of
the VPN server.
In general, it is a good idea to configure the
VPN clients to use off-subnet addresses.
Doing so will prevent rogue VPN clients from
accessing the internal network.
VPN client configuration
Windows VPN client software is configured
slightly differently, depending on the operating
system. However, there is one setting common
to almost all versions—the Use Default Gate-
way On Remote Network option. This is the
default option. When selected, all packets for
nonlocal networks are forwarded to the ISA
Server’s VPN interface. This prevents VPN
clients from accessing the Internet and the
corporate network at the same time.
You can still allow VPN clients to access
the Internet through the ISA Server by config-
uring the VPN client’s browser to use the Web
Proxy for the VPN connection. At the client,
launch Internet Explorer and select Internet
Options from the Tools menu. When the
Internet Options screen appears, click the
Connections tab. On the Connections tab, find
an entry for the VPN connection (see Figure B).
Select that connection and click the Settings
button.
You can configure a proxy server address
and port number in the connection’s Settings
dialog box. Put in the IP address of the outgo-
ing Web requests listener and port 8080, as
shown in Figure C. You’ll also need to include
the credentials required by the Web Proxy
service if you’re requiring authentication for
outbound access.
Figure C
Enter the IP address, port, and credentials when you use
the Web Proxy service.
Either intentionally or out of curiosity,
users may harpoon network security by dis-
abling the Use Default Gateway On Remote
Network option. When users disable this
option, a network route is added to the VPN
client’s routing table, but it isn’t a default route.
The route sends requests for the classful net-
work ID the VPN client was assigned for its
VPN interface.
Let’s look at an example of a dial-up VPN
client. The VPN client is assigned the IP
address 10.0.1.100, and a default route for net-
work ID 10.0.0.0/8 is configured on the VPN
client. All packets for that network ID (and all
subnets of that network ID) are sent to the
VPN server. All other nonlocal packets are
sent to the ISP’s remote router. The VPN
client then has a direct link to both the Inter-
net and the corporate network and can
become a gateway between the Internet and
the corporate network.
A good way to prevent users from torpedo-
ing internal network security is to design the
IP addressing and routing scheme so that if
users are able to set their VPN clients to not
Use The Default Gateway On The Remote
Network, they still won’t be able to access
anything other than resources on the VPN
server itself.
Administration 111
 The best way to do this is to assign the
VPN clients off-subnet IP addresses. For
example, the internal interface of the VPN
server is connected to network ID 10.0.0.0/16
and the VPN clients are assigned IP addresses
in the 169.254.0.0/16 range. With this setup,
those VPN clients configured not to use the
VPN server as their default gateway will be
able to access resources on the VPN server,
but they won’t be able to access resources any-
where else on the internal network.
This is because when the client is config-
ured not to use the default gateway on the
remote network, the actual default gateway on
the client points to the ISP (the Internet) or
whatever default gateway the client already has
set up. Any nonlocal requests—including
those for network ID 10.0.0.0/16—will be for-
warded to the existing default gateway, which
obviously won’t work in getting to subnets on
the VPN network. Even though the VPN
server contains the proper routing table entries
to forward requests to the network IDs on the
internal network, the off-subnet VPN client
won’t be able to take advantage of them
because they are not using the VPN server as
their default gateway.
VPN gateways
ISA Server includes a couple of nice wizards
that allow you to create a local and remote VPN
gateway. Gateways can join a remote office to a
local corporate network. The Local Wizard is
run on the machine receiving the call from the
remote office VPN server. The Remote Wizard
is run at the VPN server at the branch office.
These wizards work fine, except for a small
problem with allowing both sides to initiate a
connection. Only the remote office should
have the capability to call the central office. If
you configure both sides with the ability to dial
one another, you’ll end up with a potential race
condition when the VPN connection is
dropped. Each server will try to dial the other
simultaneously, preventing either from accept-
ing an incoming connection.
You can prevent this problem by allowing
only the central office to dial up the connec-
tion. After configuring the VPN gateways, go
to the local VPN server and configure the
112 Administrator’s Guide to VPN and Remote Access, Second Edition
machine to never redial a connection. The
gateway-to-gateway VPN router configuration
should have a passive side that receives calls
and an active side that makes calls. On the pas-
sive side, remove the dial-up credentials from
the demand-dial interface configured by the
VPN Wizard.
Remember that your VPN gateway solution
creates a routed connection to the remote net-
work. You should treat the connection between
the networks like you would any other routed
connection. Configure your routing infrastruc-
ture to send packets for the appropriate net-
work IDs to the network on the other side of
the VPN gateway. This will prevent one of
the most common communication failures
between networks joined by the VPN gateway.
Design your network services infrastructure
to support the routed networks. Place WINS,
DNS, DHCP, and directory services with this
routed architecture in mind. I often see ques-
tions from ISA Server administrators who
wonder how to deal with NetBIOS and host
name resolution for hosts on the other side of
the network. You handle this problem as you
would with any other routed network solution.
Since the link between VPN gateways is not
always reliable, you should install and config-
ure redundant services on each side of the link
and configure them to replicate with one
another, using mechanisms appropriate for
each network service.
Authentication and encryption
Your ISA Server configured to run VPN sup-
ports both PPTP and L2TP/IPSec VPN con-
nections. ISA Server does not support pure
IPSec VPN tunnels. This can create a problem
when you want to configure a pure IPSec tun-
nel between the ISA Server computer and a
third-party hardware VPN device. The only
solution is to configure the third-party device
to use L2TP/IPSec. If you do decide to use
L2TP/IPSec, make sure that you configure
compatible IPSec policies. Windows 2000 cre-
ates a default L2TP/IPSec policy.
You can disable the default IPSec policy and
use an alternate policy. This will help if you
want to use a preshared key between the VPN
server and the black box, or you can configure
a new IPSec policy to be used for your L2TP
connections.
There is one major ISA Server configuration
issue to take into account when implementing
an L2TP/IPSec VPN: The Internet Key
Exchange (IKE) required for the IPSec con-
nection requires that you allow fragmented
packets through the ISA Server. If you config-
ure the ISA Server to block fragmented pack-
ets, all L2TP/IPSec VPN connection attempts
will fail. This creates some risk because there
are known exploits that take advantage of
packet fragmentation. Because of this, you
might want to configure PPTP VPN connec-
tions instead. PPTP security is highly depend-
Configure Windows XP Professional
to be a VPN server
Mar 18, 2002
By Dr. Thomas Shinder, MCSE
F
or the Small Office/Home Office
(SOHO), Windows XP Professional
VPN features are a real boon. Traveling
users with laptops or handheld computers will
inevitably want files on the home network; you
just can’t bring everything with you. This is
where the beauty of the Windows XP Profes-
sional computer connected to an always-on
connection such as DSL or cable modem
shines. That always-on link can be used to
accept incoming VPN connections and allow
your mobile users to access shared folders and
files on your private network.
In this article, I’ll explain how to configure a
Windows XP Professional computer to accept
incoming VPN connections and discuss some
tips on improving the remote access experi-
ence for the VPN client computer user.
Windows XP’s all-in-one
VPN solution
Windows XP Professional is designed as the
one-stop solution for the SOHO, taking all the
ent on password complexity. If you’re able to
implement a secure password infrastructure,
then PPTP VPNs can be as secure as
L2TP/IPSec VPNs.
Solve those VPN trouble spots
ISA Server is built with VPN connectivity in
mind. In the majority of instances, ISA
Server configuration is not the problem. The
primary issue is either with the VPN configu-
ration in RRAS or with problems with the
underlying network infrastructure. When you
know the main areas that can cause ISA
Server’s VPN to fail, you can fix the problems
as they appear.
usability features available to Windows Me users
and adding the powerful networking features
available in Windows 2000. The combination lets
you, the support professional/net admin, create
the ideal remote access solution for the SOHO.
The Windows XP Professional remote
access server capabilities are very similar to
those available in Windows 2000 Professional.
A Windows XP computer can accept a single
incoming connection on each interface that
can accept a connection. For example, a Win-
dows XP machine can accept incoming con-
nections on each of the following interfaces:
X Dial-up modem serial interface
X Infrared interface
X Parallel port interface
X VPN interface
While it’s unlikely, a Windows XP Profes-
sional machine with the above configuration
could conceivably accept up to four simultane-
ous RAS connections. However, the typical
Administration 113
 configuration consists of a single RAS client
connection, either through a dial-up modem
interface or a VPN interface.
Create an incoming connection
with the New Connection Wizard
Like Windows 2000 Professional, Windows
XP Professional includes a New Connection
Wizard. I’ll show you how to use the New
Connection Wizard to create the new VPN
server interface. In this example, I’ll assume
the Windows XP Professional machine is not a
member of a Windows NT 4.0 or Windows
2000 domain. The machine has two network
Figure A
The Network Connections window
Figure B Figure C
Configuring XP to accept incoming connections
114 Administrator’s Guide to VPN and Remote Access, Second Edition
interface cards; one is directly connected to the
Internet and the other is connected to the
internal LAN. In addition, the external inter-
face of the machine is configured for Internet
Connection Sharing (ICS). While ICS changes
the IP address of the LAN interface of the
ICS computer to 192.168.0.1 through 16, it’s
easy to change the IP address to one that fits
the existing network environment. The IP
address of the LAN interface of the ICS com-
puter was changed to 10.0.0.1 through 24 to
fix the preexisting network configuration.
RUNNING ICS AND INCOMING
VPN CONNECTIONS ON THE
SAME INTERFACE
I have been able to run ICS and incoming
VPN connections on the same interface.
However, to prevent problematic configu-
ration issues, you should configure the
VPN interface before you configure ICS on
the same computer.
How to create the VPN server
interface, step-by-step
1. Click Start | Control Panel.
2. In the Control Panel, open the Network
Connections applet.
3. In the Network Connections window
(Figure A), open the New Connection Wizard.
 4. On the Welcome To The New Connection
Wizard page, click Next.
5. On the Network Connection Type page,
select the Set Up An Advanced Connec-
tion option (Figure B).
6. On the Advanced Connection Options
page, select the Accept Incoming Connec-
tions option (Figure C) and click Next.
7. On the Devices For Incoming Connec-
tions page (Figure D), you can select
optional devices on which you want to
accept incoming connections.
Figure D
Note that you are not presented with any of the network interfaces on the
computer.
Figure F
Any user that isn’t selected won’t be able to initiate an incoming
connection.
8. On the Incoming Virtual Private Network
(VPN) Connection page, select the Allow
Virtual Private Connections option (Figure E)
and click Next.
9. On the User Permissions page (Figure F),
select the users that are allowed to make
incoming VPN connections. Click Next.
10. On the Networking Software page, click
on the Internet Protocol (TCP/IP) entry
(Figure G) and click the Properties button.
11. In the Incoming TCP/IP Properties dialog
box, place a check mark in the Allow
Figure E
Figure G
Configuring TCP/IP properties
Administration 115
 Callers To Access My Local Area Network
check box (Figure H). This will allow VPN
callers to connect to other computers on
the LAN. If this check box isn’t selected,
VPN callers will be able to connect only
to resources on the Windows XP VPN
server itself.
12. On the Completing The New Connection
Wizard page, click Finish to create the
connection.
After the Incoming Connection is com-
plete, right-click on the connection in the Net-
work Connections window and click the
Properties command (Figure I).
Note that on the General tab of the Incom-
ing Connections Properties page (Figure J), no
devices are listed. The comment No Hardware
Capable Of Accepting Calls Is Installed isn’t true,
since you can now create VPN connections to
both network interface cards. In practice, there
is no point in creating a VPN connection to
the internal interface card.
VPN server optimization tips
The New Connection Wizard made it easy to
create the VPN server interface, but you can
still do more to optimize your VPN connec-
Figure H Figure I
Granting LAN access to callers
Accessing the properties of the VPN server link
116 Administrator’s Guide to VPN and Remote Access, Second Edition
tions. First, note that you can create PPTP
or L2TP/IPSec VPN connections. Figure K
shows the connection status dialog box of a
Windows XP VPN client connected to a
Windows XP VPN server. Note that MPPE
128-bit encryption is automatically enabled
and that Microsoft CHAP v2 is used for
authentication.
If you want the VPN client to access
resources on the internal network, the IP
address assigned to the VPN client should be
on the same network ID as the internal inter-
face of the Windows XP VPN server com-
puter. In addition, all the machines on the
internal network should have a default gateway
set using the IP address of the internal inter-
face of the Windows XP VPN server.
In the unlikely event that the SOHO has
multiple network segments, the routing table
on the Windows XP VPN server needs to be
configured with paths to the various internal
network IDs. You can use the ROUTE ADD
command to create these routing table entries.
Small networks that use a Windows XP
Professional machine for a VPN server proba-
bly won’t have network services such as WINS
or DNS. If name resolution on the private
network is an issue for the VPN client, then Figure J
you should create a LMHOSTS file, a simple
text file that contains name and IP address
mappings. For example, the following line
could represent an entry in an LMHOSTS file:
10.0.0.2 DEFIANT

TIP
When you save the LMHOSTS file to the
<system_root>\system32\drivers\etc
folder, make sure that the file doesn’t con-
tain a file extension. To prevent Notepad
from appending a file extension to the file-
name, when you save the file in Notepad,
put quotes around LMHOSTS.

The VPN client must be configured with an

IP address or host name for the Windows XP
VPN clients will call only the external IP address of
Professional VPN server. If the Windows XP the Windows XP Professional VPN server.
Professional client has a dedicated link to the
Internet and a static IP address, you can use
that IP address in the VPN client configura- Figure K
tion interface. However, if the Windows XP
Professional VPN server is assigned an IP
address via DHCP, you’ll have to use an Inter-
net host name and a method of registering the
host name dynamically. A couple of services
you might want to look into are TZO and
DYNDNS. Both of these services will let you
dynamically register a computer’s IP address
into the public DNS database.

Conclusion
Windows XP Professional provides simple
VPN server capabilities that let you connect
single VPN clients to your internal network,
one at a time. If the Windows XP Professional If both machines had machine certificates from the
same Certification Authority installed, an L2TP/
computer has a dedicated connection to the IPSec VPN link could have been negotiated.
Internet, you can connect to that computer
from virtually anywhere in the world using a
VPN link. The VPN server setup is simple and
can accept calls from any Windows PPTP or
L2TP/IPSec client.

Administration 117
 How to configure Windows XP client
VPN connections
Apr 25, 2002
By TechRepublic Staff
V
PNs have caught on quickly with
small and medium-size businesses,
primarily for three reasons:
1. VPNs permit employees to connect to
office resources from home or other loca-
tions using common hardware.
2. VPNs provide secure connections.
3. The cost to set up and maintain a VPN is
low compared to other networking con-
nection solutions.
In this article, we’ll describe the process of
setting up a VPN client connection within the
Windows XP operating system.
If you’re configuring laptops for remote
VPN connections via DSL modem, LAN, or
WAN connectivity, navigate through Start |
Control Panel | Network And Internet Con-
nections and click the Set Up Or Change Your
Internet Connection link. Once the Internet
Properties window opens (Figure A), click the
Setup button, which will open the New Con-
Figure A
You can configure a variety of settings for dial-up and VPN
connections.
118 Administrator’s Guide to VPN and Remote Access, Second Edition
nection Wizard. In the wizard, you’ll find four
selections (instead of the five in Windows
2000 Professional). The connection type you’ll
select is Connect To The Network At My
Workplace. Then, the next window will ask
you to specify the type of connection you’re
creating. Select the Virtual Private Network
Connection option and click Next. The next
two screens will ask for the company name
and the IP address of the VPN server. Once
you’ve clicked through these screens, you’ll be
greeted with the final screen, which will ask if
you’d like to add a shortcut to this connection
to the desktop. If you want a VPN icon, click
Yes; choose No if you don’t. Click Finish.
DIAL-UP
If you’re connecting via dial-up, there are
only two differences. In the New Connec-
tion Wizard, under the Network Connection
screen, you’ll select Dial-up Connection
instead of Virtual Private Network connec-
tion, and you’ll enter a phone number
instead of an IP address.
If you need to change the telephone num-
ber or other settings associated with the VPN
connection, you can do so easily through the
Properties window (see Figure A).
Connecting to the VPN
To connect, double-click the shortcut—if you
chose to create one—or select the connection
by clicking Start | Connect To and selecting
the name of the connection you created. Sup-
ply your User Name and Password for the net-
work you wish to access (see Figure B) and
you’ll be ready to start enjoying the benefits of
secure, remote access.
If you want to edit the settings for the con-
nection, you can do so from the Properties
window. You can modify Dialing and Redialing
options, Security options, TCP/IP, and
Advanced options, such as Firewalling and Figure B
NAT. Several other options can be configured
on the tabs in your connection’s Properties
window, including:
X Changing security settings of individual
components.
X Selecting privacy settings for Internet zones.
X Configuring a proxy server.
X Associating programs with a specific service.

XP makes VPN a cinch

Windows XP includes a VPN functionality
that is more robust and clearer than in previ-
ous versions of Windows. Given that more
and more companies are turning to VPNs for
security reasons, you need to understand how Supply your networking User Name and Password for
authentication purposes.
to configure this networking option.

Configure Windows NT to support

VPN connections
May 31, 2002
By John Sheesley

I
n the good old networking days, life as a
network administrator was simple. The
only users you had to worry about con-
necting to your network were the ones in your
building. Users at other locations had their
own networks with another network adminis-
trator to take care of them. Users working
from home or on the road couldn’t access net-
work resources, but had to transport floppies,
so you didn’t have to worry about them either.
Not any more. Nowadays, users are scat-
tered all across the globe, and they all want
access to your network with the same ease and
rights as if they were in the office next door to
you. That’s where VPNs come in. Deploying a
VPN doesn’t mean that you have to upgrade to
Windows 2000 or wait for Windows .NET.
Even though you’re still running Windows NT,
you can deploy a VPN for those users in need
by using NT’s RAS. In this article, I’ll show
you how it’s done.
AUTHOR’S NOTE
You can configure NT to act as a VPN for
both dial-up and Internet connections. For
the purposes of this article, I’ll show you
how to configure NT to act as a VPN for
users who are coming in over the Internet.
VPN on Windows NT
If you want to deploy a VPN on your network
and you already run Windows NT, then you
don’t necessarily have to invest in a hardware

Administration 119
 VPN or upgrade to Windows 2000. You can
deploy a VPN solution using NT’s RAS. Doing
so is almost as easy as deploying a VPN using
Windows 2000.
However, because Windows NT is older
than Windows 2000, you don’t gain all of Win-
dows 2000’s additional features in the Win-
dows NT VPN. Some of the things missing
from Windows NT’s VPN include:
X Support for L2TP
X Policy support for remote access
X Support for an Internet Key Exchange
X Support for IPSec
X Active Directory integration
That said, NT’s VPN solution is still very
robust and secure. For security, NT’s VPN
uses Point-to-Point Tunneling Protocol
(PPTP). NT uses either 40-bit or 128-bit
encryption keys to encrypt traffic that travels
to and from the server, with the actual encryp-
tion level depending on the software used by
the VPN client. For authentication purposes,
PPTP can use any of the following protocols:
X Password Authentication Protocol (PAP)
X Shiva Password Authentication Protocol
(SPAP)
X Challenge Handshake Authentication Pro-
tocol (CHAP)
X Microsoft Challenge Handshake Authenti-
cation Protocol (MS-CHAP)
You can support up to 256 simultaneous
logons to your Windows NT server over the
VPN. Once connected, users have the same
rights on the network as if they were con-
nected via a LAN.
Figure A
You must specify the number of PPTP connections.
120 Administrator’s Guide to VPN and Remote Access, Second Edition
Configuring Windows NT for
VPN support
Configuring Windows NT for VPN support is
a fairly easy task. By default Windows NT con-
figures its RAS to allow connections via dial-
up. To set up a VPN that will allow access
from the Internet, you must add PPTP. First,
right-click Network Neighborhood and select
Properties. When the Network Properties win-
dow appears, click Protocols.
Click Add on the Protocols screen. You’ll
then see the Select Network Protocol screen
appear. Select Point-to-Point Tunneling Proto-
col and click OK. Your server will prompt you
to insert the Windows NT Server CD. Do so
and wait while it copies the files to your server.
When the files finish copying, NT will begin
configuring PPTP. You’ll then see the PPTP
Configuration screen, shown in Figure A.
The first thing you must do to configure
PPTP is set the maximum number of connec-
tions that you want to allow via VPN. You can
specify anywhere from 10 to 256 connections.
Oddly enough, you can’t directly type the num-
ber of connections in the Number drop-down
list box. Instead, you must select the number
of connections from the box. You can speed
up the process somewhat by pressing the first
number of the connection you want. So, if you
want to connect 50 users, you would press 5
twice, which will cause the list box to scroll
first to 5 and then to 50. You would press 5
three times to scroll to 51, and four times to
scroll to 52, and so on. Click OK to close the
window after you’ve set the number of con-
nections you want.
Next, NT will prompt you to install the
RAS service. Click OK to close the Setup
Figure B
Make sure RASPPTPM is selected as the default device.
Message window informing you of this to Figure C
continue. NT will then begin copying the RAS
files to your server. When it’s done, you’ll see
the Add RAS Device screen, shown in Figure B.
To allow remote connections, make sure
VPN1-RASPPTM is selected in the RAS
Capable Devices drop-down list box. You can
add other devices later if you want, such as
dial-up modems. Click OK to continue.
You’ll then see the Remote Access Setup
screen. On this screen, you can see any RAS
connections your server is prepared to handle.
Select VPN1 and click Configure. When the
Configure Port Usage screen appears, make
sure that the Receive Calls Only radio button is
selected. This will ensure that users don’t
attempt to use the RAS to connect to external
resources. Click OK if everything looks correct.
Next, click Network to configure the net- The Network Configuration screen controls network
work settings for the remote connection. settings for the connection.
You’ll see the Network Configuration screen
appear, as shown in Figure C. Figure D
The Server Settings pane contains the selec-
tions for network protocols the client will be
able to use once connected to the VPN. NT
will display the protocols currently running on
your network. You should select only proto-
cols necessary for the users to get their work
done. Chances are you’ll use only TCP/IP, so
deselect any other protocols.
To configure the protocol, click the Config-
ure button. You’ll then see the RAS Server TCP/
IP Configuration screen, shown in Figure D. On
this screen, you make selections that dictate
how NT will assign the TCP/IP address for
the remote user.
The Allow Remote TCP/IP Clients To
Access box allows you to control the type of
access that remote users have. You can limit This screen allows you configure the protocol for the user.

them to resources only on the VPN server by

selecting This Computer Only. To allow users
to access any network resource, select Entire
Network.
You can either use DHCP to assign network
addresses or assign addresses from a static
pool. From an administrative standpoint, it’s
easiest to use DHCP. That way you don’t have
to worry about overlapping addresses or filter-
ing rights based on TCP/IP addresses. If users
need a particular static IP address for some
reason, you can select the Allow Remote
Clients To Request A Predetermined IP
Address check box. Click OK once you’ve
made all of your selections
When you get back to the Network Configu-
ration screen, double-check the other selections.
To secure communications between clients
and the server, select the Require Microsoft
Encrypted Authentication radio box. Don’t
worry about selecting the Enable Multilink

Administration 121
 check box. This is used primarily by dial-up
clients to maximize throughput. Click OK to
close the Network Configuration window.
After you return to the Remote Access
Setup screen, you can click Continue to close
the screen and finish the configuration. NT
will copy more files to your server and config-
ure the RAS service based on the selections
you made. When the configuration finishes,
NT will display an informational screen telling
you what utilities to use to administer RAS.
Click OK to shut down the window. You’ll
then have to restart your Windows NT Server.
After the server restarts, reapply the last
Service Pack you applied to your server and
restart it again. After this last restart, you’ll be
ready to start using RAS.
Allowing users to access RAS
Just because you install RAS and VPN support
on your server, doesn’t mean your users can
use it. By default, Windows NT denies every-
one the ability to access the server via VPN.
Figure E
You can control user rights using the Remote Access Admin
utility.
Figure F
You can control the Remote Access Service using Remote Access Admin.
122 Administrator’s Guide to VPN and Remote Access, Second Edition
This increases security on your network and
allows you to rest easy knowing that not just
anyone can get in through your VPN.
To allow a user to use the VPN, you have two
choices: You can either change the user’s rights
within User Manager For Domains or you can
use the Remote Access Admin utility. Let’s
look first at the User Manager For Domains.
Start the User Manager For Domains by
clicking Start | Programs | Administrative
Tools (Common) | User Manager For
Domains. When the utility starts, select the
user to whom you want to grant VPN rights.
Select Properties from the User menu. When
the User Properties screen appears for the
user, click the Dialin button.
You’ll then see the Dialin Information
screen appear. Select the Grant Dialin Permis-
sion To User check box. Make sure the No
Call Back is set in the Call Back box. This box
is only useful for users that dial in to a modem,
and it won’t work if users are connecting via
VPN. Click OK to close the Dialin Informa-
tion screen and then OK again to close the
User Properties screen.
You can also use the Remote Access Admin
utility. To start the Remote Access Admin util-
ity, click Start | Programs | Administrative
Tools (Common) | Remote Access Admin.
You’ll then see the Remote Access Admin
Window appear. This window lists the avail-
able RAS Server and other information for the
RAS server, which I’ll discuss more below.
To grant a user the right to use the VPN,
select Permissions from the Users menu.
You’ll then see the Remote Access Permissions
screen, shown in Figure E.
To allow a user to use the VPN, scroll
through the Users list box until you find the
user you want. Click the Grant Dialin Permis-
sion To User check box to allow access to the
VPN. Again, make sure that No Call Back is
also selected.
Unfortunately, there’s no easy way to select
multiple users at once. You must select each
user one at a time. Alternatively, you can click
the Grant All button to give VPN rights to
every user on your NT server and then scroll
through the User list box and remove the
check from the Grant check box. If you want
to quickly remove access to the VPN from Figure G
every user, click the Remove All button.

Other Remote Access

Admin tasks
The Remote Access Admin utility, shown in
Figure F, gives you full control over the RAS,
and thereby the VPN. As you can see, Remote
Access Admin lists the servers that can sup-
port VPN, along with the maximum number
of connections and current number of logged
on connections. Remote Access Admin has a
static display. It doesn’t change as users log on
and log off. To refresh the screen, select
Refresh from the View menu.
You can start or stop the RAS from the
Server menu. To stop the service, select Stop
Remote Access Service. To start it, select Start
Remote Access Service. You can also pause
access without unloading the service by select-
The Port Status screen shows you detailed information about
ing Pause Remote Access Service. a user’s session.
To view detailed information, double-click
the server. You’ll then see the Communica- Figure H
tions Ports screen appear. From this screen
you can do the following:
X Disconnect the user from the VPN by click-
ing Disconnecting User
X Send a message to a specific user by select-
ing the user and clicking Send Message
X Send a message to all users by clicking Send Remote Access Admin shows information about logged on users.
To All
X View detailed information about the con- If you want to view information about a
nection by clicking Port Status user account, highlight it and click User
If you click the Port Status button, you’ll Account. You’ll then see the screen shown in
see the Port Status screen, shown in Figure G. Figure H. While it doesn’t show detailed infor-
Here you can see detailed information about mation about permissions and such, it does
the user’s connection, including such things as show information about user rights in general,
how much bandwidth the user can use, how along with callback and password information.
many packets have been transmitted, and the
user’s VPN IP address.
VPNs on NT: Virtually Painless
Remote Access Admin also allows you to Networking
view user information. To do so, select Active Even though you’re still using Windows NT,
Users from the Users menu. You’ll then see you don’t have to be left out in the cold when it
the Remote Access Users screen. This screen comes to deploying such things as VPNs. Using
looks similar to the Communication Ports NT’s RAS, you can quickly deploy a VPN for
screen except that rather than showing con- your network. Users can dial in and have the
nections, it shows connected users. Like the same rights as if they were connected locally,
Communications Ports screen, you can send and you can administer their access without
messages or disconnect users from this screen. learning any new operating systems.

Administration 123
 Monitoring and troubleshooting VPN
connections in WinNT
Jun 12, 2002
By Rick Vanover

W Rights issues
indows 2000 Server has been on
the market for more than two years,
and its successor, Windows .NET,
is just around the corner. But many enterprises
have consolidated around Windows NT Server
4 as a back-end infrastructure. That includes
using NT as a first-generation, PPTP-based
VPN server, even though VPN was a very new
technology back when NT was released in the
mid-1990s.
Of course, supporting an NT VPN server
requires the administrator to be diligent in
monitoring and optimizing the VPN and to be
able to troubleshoot issues that appear in the
day-to-day administration of an NT VPN
server.
Troubleshooting
In supporting VPN clients, I have found most
issues to be related to the client-side configura-
tion, but some important server-side issues
must be considered as well. In terms of VPN
troubleshooting, we’re going to take a look at
rights issues, connection types, networking
setup, and client configurations.
The rights needed to access an NT VPN
server are assigned by the Grant Dialin Per-
mission To User option in each user account.
This option simply states whether this NT
account can access the Remote Access Service
(RAS). This option is assigned in each user
account from within the User Manager For
Domains administrative tool, as shown in
Figure A.
If a user does not have this option
enabled on the account, the connection will
not be established and the user will be told
that dial-in permission does not exist for the
selected account. This will also generate an
Event 20082 of source Remote Access in the
Event Log of the Remote Access/VPN
server.
Microsoft provides a nice list of all RAS-
related error codes and a description for
each in Knowledge Base article Q117304
(http://support.microsoft.com/search/
preview.aspx?scid=kb;en-us;Q117304).
Windows NT, unfortunately, does not allow
the dial-in right to be assigned to a local or

Figure A Figure B

Enable Dialin Permission for users who will make VPN

connections.

Use the Grant All button to enable RAS/VPN permissions for all users.

124 Administrator’s Guide to VPN and Remote Access, Second Edition

global group. You can bypass this limitation Figure C
somewhat by using the Remote Access
Admin administrative tool. The Remote
Access Admin will allow you to assign the
dial-in right to all users, as shown in Figure B.
If you take this approach, you’ll need to
watch the situation carefully. This option does
not allow you to select a number of users and
assign the right—it assigns all listed users the
right to dial in. It also lets you revoke all users.
Using the Remote Access Admin console to
give all users dial-in rights is most useful if
you are using your Windows NT VPN server
exclusively for remote dial-in (including VPN),
where the only accounts on that computer are
the dial-in accounts (not the domain
accounts).
Connection types
Supporting VPN clients entails an assortment
of responsibilities, and depending on your situ-
ation, you may have a mix of how users con-
Set the allowed number of incoming VPN connections.
nect to your VPN server. If you are supporting
telecommuters, users needing occasional
remote access, and/or site-to-site VPNs, you gateways can affect the reliability of your VPN
will be dealing with different connection types. solution.
While it is likely that the VPN server will On the server, be sure that you have enough
not be changing ISPs frequently, I have learned VPN connections enabled for the number of
to have the clients connect to the VPN’s fully potential VPN users that will be connecting.
qualified domain name instead of an IP This setting is configured in the properties of
address. That way, if you do change ISPs, you the Point-To-Point Tunneling Protocol within
don’t have to reconfigure all of your client the Network applet of the control panel on
configurations. For example, have the client the VPN server, as shown in Figure C.
connect to “vpn.company.com” and make sure Another concern related to connection
that your DNS records are modified accord- types and networking setup comes up when
ingly during your ISP change, which will make users try to use a nonstandard ISP to connect
an ISP change easier for everyone involved. their VPN. A nonstandard ISP is one that adds
Users tend to change ISP connections fre- items into the Network applet of the control
quently. Various dial-up, broadband, satellite, panel. I have had many issues with ISPs that
wireless, and other connections may cause you add protocols or adapters into the client net-
headaches in trying to support VPN users. working setup. When supporting users, you
Make an effort to be aware of how your VPN should provide or recommend a good ISP for
clients are connecting to the Internet (and then dial-up access in order to save yourself a lot of
to your VPN server). Also, try to provide or headaches down the road. If you have a user
recommend the best solutions based on your who is having trouble accessing the VPN, ask
experience. whether any software was installed that may
Networking setup have affected the network stacks, such as spe-
The networking of a VPN can be a frequent cial client software from the ISP.
trouble spot. Topics like RAS setup, ISP net- For the VPN client, an important consider-
working issues, name resolution means, and ation is whether the VPN connection will

Administration 125
 authenticate the client to be part of the Win-
dows domain or authenticate it on the VPN
server and simply give it a connection to the
internal network. This setting is configured on
the VPN client, and it varies slightly with dif-
ferent versions of Windows. Generally, you
can configure this setting by selecting (or not
selecting) the Include Windows Logon
Domain in the Properties dialog box for the
VPN connection in the Network/Dial-up
Connections applet. Figure D shows an example
of what this looks like using Windows XP as
the client operating system. (Windows 2000
looks almost identical to this.)
Another important aspect of the VPN
client setup is the default gateway. If the client
VPN connection is set up to use the default
gateway on the remote network, all Internet
traffic will be routed through the VPN con-
nection. For example, if someone makes a
VPN connection from a home machine, any
time that person tries to access an Internet site,
the request will be sent over the VPN tunnel
to the company network and out the Internet.
Figure D
Select whether you want the connecting client to be part of the Windows
domain.
126 Administrator’s Guide to VPN and Remote Access, Second Edition
The downloaded page will then be sent back
down the VPN tunnel to the client. Obviously,
most of the time you’re not going to want this
to happen.
But if you do want to enable this setting—
for example, for tracking all Internet traffic
from a company laptop—on a Win2K client,
go to the Properties of the VPN connection
and select the Networking tab. Then, select
TCP/IP, click Properties, click Advanced, and
select the Use Default Gateway On Remote
Network check box, as shown in Figure E.
Name resolution is also an important part
of supporting a VPN client. The easy option is
to have RAS use DHCP assignments for VPN
connections. This option will usually give the
clients the same network resolution services
that DHCP connections on the internal net-
work are entitled to use and will greatly sim-
plify the work of an admin.
Client configurations
Client VPN problems can be tough to diag-
nose. I have found client troubleshooting
Figure E
Set up the client to use the gateway of the remote network.
issues generally not to be related to VPN/
PPTP but to changes on the end user’s PC.
This can include problems with:
X Virtual hardware devices (modems in par-
ticular) not operating correctly.
X Bogus DHCP leases/assignments requiring
a manual release/renew.
X Installed software that has modified the
networking stack of Windows.
X Settings that have been accidentally changed
on the VPN connection itself.
While diagnosing these problems is chal-
lenging, getting the VPN to work again is usu-
ally fairly easy. One trick I’ve relied on is
creating two identical PPTP connections on
the client computer. I put one on the desktop
as a shortcut and keep one untouched. Since
the end user does not utilize it, I can use it as a
support tool. This setup allows you to tell if
the settings of a PPTP connection are inhibit-
ing the user from authenticating and/or con-
necting correctly.
Monitoring
Monitoring the VPN connections is important
to ensure that they are working correctly and
are not being abused. Here are some ways you
can monitor your VPN server:
X Use Remote Access Admin—This
configuration applet shows you current
connections, lets you see how long the
The Win9x VPN client connection guide
Jun 5, 2002
By Dr. Thomas Shinder, MCSE
V
PN Servers go a long way toward sav-
ing money for companies with remote
access clients. In the not-so-distant
past, companies that wanted to give road war-
riors access to corporate internal network
resources needed to install modem banks and
multiple phone lines. The cost of installing
active connections have been online, and
provides statistics on the number of bytes
transferred.
X Use WINS/DHCP Admin—This tool
lets you determine whether you have a
DHCP lease reserved for a VPN client.
X Reevaluate VPN strategy—If the VPN
solution is a trusted VPN (all TCP ports
open) to all clients, consider adding TCP/IP
security (Advanced Properties of TCP/IP
from the Network applet of the control
panel) for the explicit ports needed to the
VPN server’s internal interface.
MICROSOFT RESOURCES
Microsoft provides detailed information
about client and server PPTP connections
on Windows NT Server 4. You can down-
load these documents from the Microsoft
Web site (http://www.microsoft.com/
ntserver/techresources/commnet/
default.asp).
Final word
The Windows NT 4 VPN server is still in use
in many organizations, and keeping the con-
nections working correctly will ease your
administration worries. The tips provided here
should be a valuable companion for trou-
bleshooting and monitoring your NT 4 VPN
servers and their connecting clients.
multiple dial-up RAS servers was compounded
by the long distance charges or costs incurred
from 1-800 numbers. VPN servers remove this
cost-rich hardware/telco layer and allow you to
support dozens and even hundreds of remote
access calls with a single VPN server and high-
speed Internet connection.
Administration 127
 Most of the articles I see on the Internet
focus on how to set up and configure the VPN
server. This makes sense, since most of the
complicated work in setting up a VPN
client/server solution is done at the VPN
server. However, configuring VPN clients is
not always a piece of cake. This is especially
true when dealing with legacy VPN client oper-
ating systems, such as the Windows 9x line.
We’ll look at how to configure your Win9x
computers to be VPN clients that connect to
Windows NT 4.0 VPN servers. You can use
the same procedures to configure the Win9x
clients to connect to Windows 2000 VPN
servers. The only major difference between
connecting to Windows NT 4.0 and Windows
2000 VPN servers is that the Windows NT 4.0
VPN servers do not support the L2TP/IPSec
VPN protocol. However, this doesn’t pose
much of a problem for our Win9x VPN
clients, because the only VPN protocol sup-
ported by Win9x operating systems is the
Point-to-Point Tunneling Protocol (PPTP).
Windows 9x Dial-up Networking
Service 1.4 (DUN 1.4)
Before getting into the nuts and bolts of con-
figuring the Win9x VPN client, you need to
familiarize yourself with the latest update to
the Win9x Dial-Up Networking Service, DUN
1.4. There are several reasons why you’ll want
to download and install DUN 1.4, including:
X Support for 128-bit encryption.
Figure A
128 Administrator’s Guide to VPN and Remote Access, Second Edition
X A Y2K fix for the VPN DHCP client
component.
X Fixes that improve the stability of the PPTP
connection.
X Support for internal ISDN adapters.
X Multilink support.
X Support for PPTP connections over a
“LAN” or dedicated connection (such as
DSL or cable).
Check out Microsoft Knowledge Base arti-
cle Q297774 (http://support.microsoft.com/
default.aspx?scid=kb;en-us;Q297774&
SD=MSKB&) for full details on DUN 1.4.
There are several versions of DUN 1.4, one
each designed for Windows 95, Windows 98,
and Windows 98SE. Information about the
updates and files for download can be found in
Microsoft Knowledge Base article Q285189
(http://support.microsoft.com/default.aspx
?scid=kb;en-us;Q285189). Be aware that
you will need to restart the computer at the
end of the DUN 1.4 installation.
NOTE
Windows Me does not require the DUN 1.4
Dial-up Networking update.
Configuring the Windows 9x
VPN client
The procedure for configuring the Windows
9x VPN clients is very similar, with only very
minor differences between each version.
Prior to configuring the PPTP VPN client
connection on the Win9x client, make sure
you have an Internet connection to the Inter-
net VPN server. The Internet connection
device can be an analog dial-up modem,
ISDN terminal adapter, a DSL line, or a
cable connection.
Let’s use the Windows 95 client as an exam-
ple of how to configure all the Win9x clients.
Perform the following steps on your Windows
95 computer:
1. Click Start | Programs | Accessories.
Point to Communications, and then click
on Dial-up Networking.
 2. The Dial-up Network Wizard Welcome
dialog box will appear (Figure A). Click
Next to continue.
3. On the next page, type in a name for the
connection in the Type A Name For The
Computer You Are Dialing text box.
Click the down arrow in the Select A
Device drop-down list box and select the
Microsoft VPN Adapter option (Figure B).
DUN 1.4 added this feature to your Win-
dows 95 computer. Click Next.
4. On the Make New Connection page, type
in the IP address or the Fully Qualified
Domain Name (FQDN) of the VPN
server that the Windows 95 computer will
connect with (Figure C). If you use an
FQDN, make sure that there is an entry in
the public DNS that resolves to the IP
Figure B
Figure D
address on your VPN server that is listen-
ing for incoming VPN connections. If
you do not have a DNS entry for your
VPN server, enter an IP address instead.
Click Next.
5. On the last page of the wizard (Figure D),
you’ll be told that you’ve done everything
right and that you’ve created a new con-
nection. After clicking Finish, the connec-
toid will appear in your Dial-Up
Networking folder.
6. Return to the Dial-Up Networking win-
dow. You should see the icon for the VPN
connectoid you just created, and another
connectoid for an ISP connection if you
require a dial-up connection to access the
Internet (Figure E).
Figure C
Figure E
Administration 129

NOTE
You must create the dial-up connection
separate from the VPN connection.
Further tweaking with VPN Properties
You might want to do some further tweaking
of the VPN connection. Right-click the VPN
connectoid and click Properties. On the Gen-
eral tab (Figure F), you can change the name or
IP address of the VPN server. This is conven-
ient because, if the name or address of the
VPN server changes, you don’t have to create a
new connectoid. Just change an existing one.
You can make many customizations on the
Server Types tab (Figure G). By default, the Log
On To Network and Enable Software Com-
pression options are enabled. For connections
that support MS-CHAP, check the Require
Encrypted Password box. If you want to use
MS-CHAP version 2, the client will negotiate
MS-CHAP version 2 with the VPN server
first. If the server does not support MS-
CHAP version 2, the client will drop down to
support MS-CHAP version 1. Also, make sure
that data encryption is enabled. If you want to
optimize connection speed, uncheck protocols
that you do not use. If you do not disable the
Figure F
130 Administrator’s Guide to VPN and Remote Access, Second Edition
protocols, the client will attempt to negotiate
each one selected.
When you click on the TCP/IP Settings
button at the bottom of the Server Types tab,
you’ll see what appears in Figure H. Most VPN
servers will automatically assign IP addressing
information to the VPN client. Therefore, you
should leave the default settings Server
Assigned IP Address and Server Assigned
Name Server Addresses as they are. The Use
IP Header Compression option should be set
if the VPN server supports this option.
The most interesting option is the Use
Default Gateway On Remote Network. When
this option is selected, the VPN client uses the
VPN interface as the gateway for all nonlocal
network addresses. If the client dialed in to an
ISP first, the ISP assigned the computer a
default gateway at the ISP to allow the client
access to the Internet. However, when the Use
Default Gateway On Remote Network option
is enabled, the VPN client is assigned a new
default gateway, which is the VPN server’s
VPN interface. The end result is that the VPN
client cannot access the Internet once it con-
nects to the corporate VPN.
If this option is disabled, the VPN client will
be able to access both the internal corporate
network and the Internet at the same time. This
Figure G
Set high encryption for the link.
creates the possibility that the VPN client will Figure H
be able to route packets from the Internet to
the internal network. Allowing the VPN client
to access the Internet through the ISP and also
the corporate network through the VPN at the
same time is poor security practice. This is akin
to allowing users on the internal network to
plug modems into their computers and thus
bypass corporate Internet access policies.
The Windows 98/98SE VPN client
Configuring the Windows 98/98SE client
works exactly the same as configuring the Win-
dows 95 client. The interfaces are virtually
identical after installing DUN 1.4. The only
difference you’ll see is found in the Connec-
tions menu in the Dial-up Networking win-
dow. In the Dial-up Networking window, click
Connections and then click Settings (Figure I).
Windows 98/98SE allows you to configure
a redial value and a wait interval before redial- LAN Manager Passwords and Require Secure
ing. This option isn’t available in the Windows VPN Connections are enabled by default.
95 dial-up networking. You also have the LAN Manager password authentication is
option to be prompted before a dial-up con- inherently insecure and should always be dis-
nection is established. This is helpful when you abled. The secure VPN connection option will
use dial-up networking to map network drives force 128-bit encryption. If the VPN server
via the VPN interface. does not support 128-bit encryption, the con-
Click on the Security tab and you’ll see what nection attempt will fail. If this option is not
appears in Figure J. Both Disable Sending Of enabled, the client will first negotiate 128-bit

Figure I Figure J

Administration 131
 encryption. If the negotiation fails, it will fall
back to 40-bit encryption.
Some final thoughts on
troubleshooting
There are a handful of troubleshooting issues
you should be aware of before finalizing your
VPN client/server solution. Many ISPs do not
allow incoming GRE packets into their net-
works, or they require that the user pay extra
for a “business account.” If the VPN client
cannot establish a VPN connection with the
corporate VPN server, the user should contact
his ISP to determine if GRE connections are
allowed for the user’s account.
Windows 9x clients will not be able to con-
nect to VPN NLB server clusters if the NLB
interface still has the actual IP address config-
ured on the cluster servers. Only the virtual IP
address can be listed on the external interfaces
of the cluster members if you expect to con-
nect down-level clients to a PPTP VPN NLB
cluster. If the VPN client fails to connect to a
Understanding Exchange 2000 Server’s
Outlook Web Access
Mar 22, 2001
By Jim Boyce
M Overview of Outlook Web Access
icrosoft introduced Outlook Web
Access (OWA) in Exchange 5.0 to
enable clients to access their
Exchange Server mailboxes through a Web
browser. Microsoft has made some significant
improvements in OWA in Exchange 2000
Server to provide better performance, the abil-
ity to support a larger number of users, and
improved functionality for clients. In this arti-
cle, I’ll explore OWA to give you an under-
standing of how it works and how to
implement it.
132 Administrator’s Guide to VPN and Remote Access, Second Edition
PPTP NLB cluster, confirm that only the vir-
tual IP address appears on the external inter-
face of each of the cluster members.
If a WINS server is manually assigned to a
NIC, the PPTP VPN client will not be able to
obtain a WINS server address on the PPTP
VPN interface. This is in spite of the fact that
the WINS address is configured only on the
NIC. Note that manually setting a DNS server
address on the machine’s NIC will not prevent
the PPTP VPN client from obtaining a DNS
server address from the VPN server.
You may run in to issues when users plug
directly into the corporate network with an
Ethernet card while at work, and then go
home and try to connect to the same network
through the PPTP VPN interface. The user
may need to run the winipcfg utility from the
Run menu to renew the IP address. If that
does not work, the NIC may need to be
removed before the VPN user can connect to
the network remotely.
OWA provides a means for clients to connect
to an Exchange server through a Web browser
to access their mailboxes. Clients can send and
receive messages, manipulate their calendars,
and perform many—but not all—of the tasks
they can perform when connecting to mail-
boxes through an Outlook or Exchange client.
Exchange 2000 Server includes some addi-
tional features not provided by OWA in
Exchange Server 5.x. Some of these features
are added through OWA itself and others in
combination with Internet Explorer 5.0.
 OWA isn’t meant to be a complete replace-
ment for Outlook or the Exchange client,
which provide full access to Exchange Server
and its features. However, OWA is useful for
enabling roaming users to access the most
common mailbox features when they don’t
have access to their personal Outlook installa-
tion. OWA can also be a useful means for giv-
ing UNIX, Linux, and Macintosh users the
ability to access Exchange Server mailboxes
and participate in workgroup messaging and
scheduling. Finally, OWA is a good alternative
for those users who don’t need the full range
of features offered by Outlook and can save
the administrative and support overhead—as
well as licensing costs—to deploy Outlook.
OWA’s features
E-mail is inarguably the primary function of
Exchange and Outlook, and OWA naturally
supports e-mail access. Clients can connect to
the Exchange server, view the headers in the
inbox, read those messages, send new mes-
sages, reply, and forward or delete messages.
Although giving clients access to the inbox
without requiring an Outlook or Exchange
client is certainly an important aspect of
OWA, an added benefit is the ability to delete
messages without downloading them. Outlook
gives you this ability through its Remote Mail
feature, which enables you to download only
message headers and not message bodies. This
is useful when you have a corrupted message
that is causing your Outlook client to hang or
you have a message with a large attachment
that you want to delete rather than download.
You can simply connect to the mailbox with
your browser, select the message header, and
delete the message, all without downloading it
to your client computer.
OWA in Exchange 2000 Server adds a few
new features for messaging. For example, both
the current and previous versions support
rich-text messages, but OWA 2000 supports
HTML-based messages as well. You also can
access embedded objects in messages, another
feature not supported by 5.x. Two new fea-
tures in OWA 2000 rely on Internet Explorer
5.0: drag-and-drop editing and shortcut menus.
In addition to its messaging features, OWA
enables clients to access their Calendar folders.
You can view and modify existing items as well
as create new appointments. OWA doesn’t give
you the same level of access to your Calendar
folder as Outlook or the Exchange client, but
the ability to view your schedule and add new
appointments is certainly useful. OWA also lets
you access your Contacts folder through the
Web. You can view and modify existing con-
tacts as well as add new ones. Other new fea-
tures include support for ActiveX objects,
public folders containing contact and Calendar
items, multimedia messages, and named
URLs—rather than globally unique identifiers
(GUIDs)—for objects.
Even though OWA is a useful tool for
accessing your Inbox, Calendar, and Contacts
folders, it doesn’t offer all the capabilities pro-
vided by the Outlook client. For example,
OWA provides access to your Tasks folder
(and to all your other folders as well), but it
doesn’t enable you to create new tasks. Like-
wise, you can view the Journal but you can’t
add new Journal entries. OWA doesn’t provide
the means to use your mailbox offline. Other
features not supported by OWA that are avail-
able through Outlook and the Exchange client
are timed delivery and expiration for messages,
spelling checker, reminders, and Outlook rules
for processing messages.
Client options
OWA supports any Web browser that sup-
ports JavaScript and HTML version 3.2 or
higher. This includes Internet Explorer 4.0 or
later and Netscape 4.0 or later. However,
some features rely on Internet Explorer 5.x,
including the previously mentioned drag-and-
drop editing and shortcut menus, as well as
native Kerberos authentication. In addition,
browsers that support DHTML and XML
offer a richer set of features than those that
do not. For example, Internet Explorer 5.x
offers an interface to OWA that is much
closer to the native Outlook client, including a
preview pane and a folder tree for navigating
and managing folders.
A brief overview of the OWA
architecture
OWA in Exchange Server 5.x uses Active
Server Pages (ASP) to provide communication
Administration 133
 between the client and the Exchange server.
The server uses the Messaging Application
Programming Interface (MAPI) to handle
messaging requests. The reliance on ASP
essentially makes OWA a feature of Internet
Information Server (IIS) rather than Exchange
Server.
Under Exchange 5.x, OWA functions pri-
marily as a Web site hosted under IIS that uses
ASP to process client requests and then uses
HTTP to communicate with the Exchange
server (which uses MAPI to manipulate the
message store). The combination of ASP and
MAPI imposes a performance overhead that
limits OWA’s capabilities in Exchange Server
5.x and reduces the number of users a server
can support through OWA.
Exchange 2000 Server uses a different
architecture that improves performance and
thereby increases the number of users that a
server can support. OWA in Exchange 2000
Server no longer uses ASP but instead relies
on HTML and DHTML. The client browser
still uses HTTP to connect to the site, but
rather than having to process a client request,
IIS simply passes the request off to the
Exchange server and transmits replies back to
the client. OWA, rather than residing on IIS, is
now integrated within Exchange 2000 Server
as part of the Web Store.
The Web Store provides a single store for
multiple data elements, including e-mail mes-
sages, documents, Web pages, and other data.
The Web Store supports several important fea-
tures, such as off-line access and remote client
access, and supports multiple protocols,
including HTTP, WebDAV, and XML. The
Web Store isn’t specifically targeted at support-
ing access through OWA. Instead, the Web
Store offers a richer set of features and capa-
bilities for storing and accessing data through
means other than just Outlook. For example,
Microsoft originally included Web Store access
in Outlook XP (the next release of Outlook)
to enable Outlook clients to use HTTP to
work with their message store, but dropped it
due to performance problems. Through its
support for multiple protocols and APIs, the
Web Store opens up additional avenues for
developers to extend Exchange functionality
134 Administrator’s Guide to VPN and Remote Access, Second Edition
and offers alternative means of accessing
Exchange data.
Authentication options
OWA provides three options for authentication:
X Basic: This option uses clear text and sim-
ple challenge/response to authenticate
access. Although it offers the broadest
client support, it also offers the least secu-
rity because passwords are transmitted
unencrypted.
X Integrated Windows: This option uses the
native Windows authentication method
offered by the client. On Windows 2000
systems, for example, Internet Explorer
uses Kerberos to authenticate on the server.
Other Windows platforms use NTLM
rather than Kerberos. Security is better than
Basic authentication because passwords are
encrypted. The browser uses the client’s
Windows logon credentials to authenticate
on the server, eliminating the need for the
client to enter the credentials again when
connecting to OWA.
X Anonymous: You can use anonymous
access on public folders to simplify adminis-
tration.
In addition to these three authentication
mechanisms, OWA supports the use of Secure
Sockets Layer (SSL) to provide additional secu-
rity for remote connections.
Topology considerations for
deploying OWA
If you host only one Exchange 2000 Server
computer, there really aren’t many considera-
tions for deploying the server. In a multiserver
environment, however, you need to give some
careful consideration to how you will structure
your Exchange environment. When you pro-
vide access to your Exchange servers through
HTTP (OWA), IMAP, or POP3 to users on
the Internet, you should use a front-end
server/back-end server scheme. The front-end
server sits on the Internet, either outside the
firewall or inside a perimeter firewall. It
accepts requests from clients on the Internet,
uses Lightweight Directory Access Protocol
(LDAP) to query the Active Directory for the
location of the requested resource (mailbox,
for example), and passes the request to the
appropriate back-end server.
A front-end server is a specially configured
Exchange 2000 server. A back-end server is
just a normal Exchange 2000 server. You don’t
have to do anything to configure a server as a
back-end server. Any server not configured as
a front-end server is by default acting as a
back-end server.
One of the advantages to using a front-
end/back-end topology is that you have to
expose only one namespace to the Internet
because that front-end server functions as the
point of entry of sorts for your back-end
Exchange servers. For example, users might
connect to http://mail.yourcompany.com to
access their mailboxes. If you didn’t have a
front-end server, each user would have to
know the name of the server hosting his or
her mailbox and enter the appropriate URL.
By providing a single point of entry, you make
it much easier to expand and rearrange the
back-end server configuration without affect-
ing your users. In situations where you have a
high volume of traffic through the front-end
server, you can set up multiple front-end
servers to handle the traffic.
Front-end servers also offer a performance
advantage in situations where you need to use
SSL to provide additional security between the
client and server. The front-end server can be
configured for SSL and perform the associated
encryption and decryption, removing that load
from the back-end servers. This frees up addi-
tional processor time for the back-end servers
to process messaging requests from clients.
The ability to place the back-end servers
behind a firewall is another extremely impor-
tant reason to use a front-end server. The
front-end server hosts no mailboxes and there-
fore doesn’t expose the mail system to intru-
sion. By configuring the front-end server to
perform authentication prior to relaying
requests to the back-end servers, you consider-
ably reduce the risk of denial-of-service
attacks on your back-end servers.
When a request comes in to a front-end
server, the server uses LDAP to query the
Active Directory to determine the location of
the requested data. The front-end server then
passes the request to the appropriate back-end
server using HTTP port 80. Because the front-
end server always uses port 80, SSL and encryp-
tion are never used between the two, even
though the client might be using SSL to commu-
nicate with the front-end server. It also means
that back-end servers that listen on a nonstan-
dard port can’t function with front-end servers.
Instead, clients must connect to these servers
directly, specifying the appropriate port number.
The back-end servers handle the traffic
from the front-end server like any other HTTP
traffic, sending responses back to the front-
end server. The front-end server then passes
the traffic back to the client, acting as a proxy
for the HTTP traffic. Clients never know that
a server other than the one they specify in the
URL when they connect is actually handling
the messaging requests.
Clients can use one of two methods to
connect to their mailbox through a front-end
server: either authenticate on the server (pro-
viding implicit authentication on the back-end
server) or use explicit logon at the back-end
server. In the former, clients can specify the
URL of the front-end server without their
account name. In the latter, clients add their
account name, as in http://mail.techrepublic.
com/jboyce. You would also use explicit logon
when you need to access a mailbox that isn’t
your own but for which you have access per-
missions. In the case of explicit logon, the
front-end server extracts the user portion of
the URL and combines it with the SMTP
domain name to construct a fully qualified
SMTP address. The front-end server then
looks up the address in the AD and forwards
the request to the back-end server for the user
based on the information it finds in the AD.
As you begin planning how you will deploy
and manage your Exchange servers in light of
OWA, keep the front-end/back-end topology
requirements in mind. Decide what strategy—
including placement of front-end servers to
firewalls—makes the most sense for your
organization.
Configuring OWA
You configure OWA using the Microsoft
Exchange Manager and Active Directory Users
Administration 135
 And Computers consoles. You also can config-
ure certain aspects of OWA through the Inter-
net Services Manager console, although
changes you make through the Exchange Sys-
tem Manager overwrite changes you make
through the IIS console. In general, you
should use the Exchange Manager and Users
And Computers consoles for most configura-
tion tasks, using the IIS console only for those
tasks not available through the other consoles.
Typical configuration tasks you would perform
include specifying which users can access their
mailboxes through OWA, which authentication
methods to allow, and which public folders are
exposed to clients.
Controlling user access
By default, all users are enabled for OWA
when you install Exchange 2000 Server. In
many situations, you might want to limit the
users who can use OWA. You do so through
the Active Directory Users And Computers
console. Open the console and choose View,
Advanced Features.
Expand the Users branch and locate a user
for whom you want to deny access through
OWA. Click the Exchange Advanced tab and
then click Protocol Settings. Select HTTP, click
Settings, and deselect the Enable For Mailbox
option. Configure any other settings as needed
for the user and close the user’s property sheet.
Configuring a front-end server
If you intend to use a front-end/back-end
topology, you need to tweak one setting on the
front-end server to make it function as a front-
136 Administrator’s Guide to VPN and Remote Access, Second Edition
end server. Open the Exchange System Man-
ager and locate the server in the Servers
branch under the server’s administrative group.
Right-click the server and choose Properties to
open its property sheet and then click the
General tab. Select the option This Is A Front-
End Server and click OK. You need to restart
the Exchange and IIS services or restart the
server for the change to take effect. Because
the back-end servers handle requests from the
front-end server like any other request, there is
no configuration needed at the back-end
server to enable it as such.
Keep in mind when you designate an
Exchange server as a front-end server as
explained above that you are directing the
server to forward all HTTP, POP3, and IMAP4
traffic to the back-end server(s). The front-end
server can still host an information store and
even user mailboxes, but these mailboxes are
accessible only through MAPI. Because the
server forwards all HTTP, POP3, and IMAP4
traffic, you can’t access the front-end server’s
store through any of these protocols.
Conclusion
Sometimes your users need to access e-mail on
the network but don’t have access to Outlook
or Outlook Express to do so. To solve this
problem, Microsoft created Outlook Web
Access in Exchange 5.0. As with most things,
Microsoft improved the feature in Exchange
2000. In this article, I’ve given you a quick look
at OWA in Exchange 2000.
Enabling Web access of Exchange accounts
using Outlook Web Access
Jan 18, 2001
By Troy Thompson, MCSE
D
o you have traveling users who want
to access their Exchange e-mail from
the road, but you don’t want to go
through the trouble of setting up VPN access
for them? You can solve this problem by using
Microsoft’s Outlook Web Access (OWA) for
Exchange server. In this article, I’ll explain
some of the limitations of OWA, as well as
how to install it.
What does OWA do?
OWA provides secure access to e-mail on your
Microsoft Exchange server using a Web
browser. This allows your organization to have
identical clients on all platforms, including
UNIX workstations. It also makes it inexpen-
sive to access mail since you can download
browsers for free from the Web.
Although the Web browser performs some
processing on the client computer, the OWA
server handles most of the processing that’s
normally performed by the client. The server
processes includes MAPI sessions, client logic,
state information, address resolution, render-
ing, content conversion, and RPC communica-
tions with the Exchange server. Because of
this, the server on which you install OWA must
meet the following server requirements:
X Pentium 6/200 single or dual processor
X 256 MB of RAM, minimum
X High-speed network connection to the
Microsoft Exchange server
X Microsoft Windows NT Server 4.0 operat-
ing system with Service Pack 4 or later
X Microsoft Internet Information Server (IIS)
(Microsoft Exchange Server 5.0 supports
only IIS 3.0. Microsoft Exchange Server 5.5
supports IIS 3.0 and later.)
X Active Server Pages (ASP)
X Active Server components or Outlook Web
Access components
It’s a good idea to test your server’s configu-
ration by starting small. Give only about 100
users OWA and monitor your server to make
sure it can support them. You may need to add
more resources to the server or add more
servers to handle the full load.
Each client requires a compatible browser to
connect to the ASP on the OWA server. Inter-
net Explorer 3.02, 4.0, or later (or any browser
that supports frames, such as Netscape Naviga-
tor) will work, but it’s recommended that you
use Internet Explorer 5.0. Otherwise, you may
experience problems accessing your folder list.
OWA features
Outlook Web Access has many features,
including the following:
X Basic e-mail: You can use the Microsoft
Exchange Server global address book, send
and receive file attachments and hyperlinks,
set message priority, request delivery, read
receipts, and create folders.
X Calendar and group scheduling access:
You can create one-time and recurring
appointments in a personal calendar, access
day and week views, see free and busy times
for multiple users, and automatically send
and respond to meeting requests.
X Public folder access: You have access to
custom views in table format, and you can
group and sort messages in a folder.
OWA limitations
OWA will not allow you to use advanced
e-mail features. It isn’t supposed to replace
the Outlook client. The following are features
not available when using OWA:
X Offline use: You must be connected to
Microsoft Exchange Server to view infor-
mation.
X E-mail: You do not have access to personal
address books, spell checking, or digital
encryption.
Administration 137
 X Calendar and group scheduling: You are
without the monthly view and other cus-
tomized views of your calendar; you also
cannot view details with Free/Busy, drag
and drop to move appointments, or track
acceptance of meeting attendees.
X Public folder access: Outlook views are
not in table format.
X Collaboration applications: You cannot
use Outlook 97 forms, use Microsoft
Exchange Server digital encryption and sig-
natures, or synchronize local offline folders
with server folders.
Capacity planning
The number of ASP requests per second that
the server can process determines the load
placed on IIS by Outlook Web Access. Before
installing Outlook Web Access throughout
your organization, you should use Perfor-
mance Monitor to measure the overall number
of ASPs processed per second. If the Perfor-
mance Monitor counters are consistently too
high and users frequently get “server too busy”
messages, you should consider adding addi-
tional Outlook Web Access servers. Some
counters to keep track of in Performance
Monitor are listed below:
X The Requests Per Second counter for
Active Server Pages: This should be
between 10 and 15. When this counter
exceeds 15 ASP requests per second, the
server will respond more slowly to user
requests, it will start to queue incoming
user requests, and CPU usage will reach
100 percent.
X The Requests Executing counter for
Active Server Pages: If requests are exe-
cuting but the IIS server is idle, you should
restart the IIS server.
X The Requests Queued counter for
Active Server Pages: This should be
between one and 20.
X The Requests Total counter for Active
Server Pages: This shows the total number
of ASP requests started.
X The Active Sessions counter for Active
Server Pages: This shows the number of
138 Administrator’s Guide to VPN and Remote Access, Second Edition
ASP sessions that are open on the IIS/
Outlook Web Access Server.
X The Sessions Time Out counter for
Active Server Pages: This shows the num-
ber of ASP sessions that have timed out.
X The Messages Rendered counter for the
MSExchangeWEB component: This
shows the number of messages opened by
clients and helps classify the user profile.
Another recommendation is that you
should dedicate one or more servers, other
than your Microsoft Exchange Server, to IIS
and Outlook Web Access components. How-
ever, if Outlook Web Access and Microsoft
Exchange Server are not installed on the same
computer, Windows NT Challenge/Response
(NTLM) authentication is not supported.
The Outlook Web Access server will actu-
ally perform most of the work for connected
clients. Supporting one client connection is the
same as running an instance of Outlook on
the Outlook Web Access server. Because of
this, the Outlook Web Access server will run
many active MAPI sessions to Microsoft
Exchange Server. Even though a single con-
nection will not consume many resources,
many sessions will. If the number of clients
increases, you can always add more Outlook
Web Access servers to load balance.
Installing OWA
The installation of OWA is straightforward.
You use the Exchange Server CD to start the
installation. Choose to set up Exchange and its
components and then choose Add/Remove.
On the next screen you will be presented with
the components to install or uninstall, as
shown in Figure A.
Be sure that everything you want to install
or have already installed has its check box
selected. If you deselect any box, that compo-
nent will be uninstalled. Click Continue and
follow the directions that appear.
OWA security issues
If Outlook Web Access clients access Microsoft
Exchange Server over an Internet connection,
Microsoft recommends that you implement a
firewall. There are two ways to implement a
firewall with the OWA architecture:
X Between IIS/OWA and Microsoft
Exchange server
X Between the client and the IIS/Outlook
Web Access server
Outlook Web Access can be configured
to use the following methods of user
authentication:
X Anonymous
X Basic (clear text)
X Basic (clear text) over Secure Sockets
Layer (SSL)
X Windows NT Challenge/Response
(NTLM)
I’ll discuss each method and its advantages
and disadvantages below.
Anonymous
Anonymous authentication allows users to use
OWA without specifying a Windows NT user
account name and password. The user has the
rights of the default anonymous account,
which is usually named IUSR_ComputerName.
Anonymous authentication provides access
only to resources that are published anony-
mously, such as public folders and directory
content.
The advantages of this type of authentica-
tion are:
X All browsers support Anonymous authenti-
cation.
X Users are not prompted for credentials.
The disadvantages are:
X Anonymous authentication is not secure.
X Users can access only the Global Address
List and public folders that are configured
for anonymous access.
Basic (clear text)
Basic authentication requires the user to spec-
ify a valid Windows NT user account name
and password in order to use OWA. Both the
user name and password are transmitted as
clear text over the network to the IIS/Outlook
Web Access server.
The advantages of this type of authentica-
tion are:
X All browsers support Basic authentication.
Figure A
To add support for OWA, select Outlook Web Access from the Options list.
X Users can access an unlimited number of
resources, even if those resources are not
on the user’s OWA server.
The disadvantages are:
X Basic authentication is not secure because it
transmits passwords across the network as
unencrypted information. If you choose
this method of authentication, you should
also use Secure Sockets Layer, which
encrypts all information passing through IIS.
X Users are prompted for a username and
password.
X Users must be granted the Log On Locally
right on IIS.
Basic (clear text) over Secure
Sockets Layer
Basic authentication over SSL requires users to
specify a valid Windows NT user account name
and password before they can use OWA. The
username and password are then transmitted as
encrypted information over the network to the
IIS/OWA server. Using Basic over SSL authen-
tication also allows users to access resources
that are not on the user’s OWA server.
The advantages of this type of authentica-
tion are:
X Almost all browsers support Basic over SSL
authentication.
Administration 139
 X Users can access all Microsoft Exchange
Server resources.
X Basic over SSL authentication is much
more secure than Basic authentication
without SSL.
The disadvantages include:
X Due to the encryption, performance can
be reduced.
X Users must enter a valid username and
password.
X Users must be granted the Log On Locally
right on IIS.
Windows NT Challenge/Response
(NTLM) Authentication
NT Challenge/Response requires users to
specify a Windows NT user account name and
password before they can use OWA. The user-
name and password are sent from the browser
to the IIS server as encrypted information.
The limitation of NTLM is that all resources
the user can access must reside on the same
server as IIS and OWA. NTLM authentication
is not supported if IIS/OWA and Microsoft
Exchange Server are located on different
computers.
The advantages of this type of authentica-
tion include:
X NTLM authentication is relatively secure.
X Users are not prompted for a username or
password.
The disadvantages include:
X Users can access resources only on the
IIS/OWA server.
140 Administrator’s Guide to VPN and Remote Access, Second Edition
X Not all browsers support NTLM
authentication.
Other security issues
For increased security, you should not use the
Save Password feature in Internet Explorer—
especially if the computer is shared among
users. Also, it is a good idea to disable local
caching on the browser. If caching is not dis-
abled, the messages accessed during the previ-
ous OWA session may still remain on the local
disk, which makes it possible for someone to
see another user’s messages.
Users should be instructed to log off from
their OWA session instead of just closing their
browsers. If an OWA session is not properly
shut down when the client is finished connect-
ing to the server, the abandoned sessions will
continue to consume server resources until
they are timed out. Even if users log off from
their OWA sessions properly, the server may
still perform poorly because ASP memory
cleanup happens as a background process.
Conclusion
In this article, I’ve shown how Outlook Web
Access gives you additional functionality for
servicing your e-mail needs. It makes it easy
for users to check messages from anywhere in
the world using a browser—no additional
client software is needed. Since it is simple to
install and maintain, it is well worth the time
and effort required to set it up.
Enhance Exchange 2000 OWA using
front-end servers
Mar 20, 2002
By Del Smith, CCNA, CCA, MCSE
M
icrosoft Outlook Web Access
(OWA) is a tightly integrated com-
ponent of Exchange 2000. In fact,
as part of the default setup of Exchange 2000,
no customization is needed to run OWA.
However, if your organization requires more
performance, reliability, and security than an
“out of the box” OWA solution provides, a
front-end server may be just what you need.
I’m going to show you how to go beyond the
basic setup of Exchange 2000 OWA to
explore ways your organization can leverage
the key benefits of a front-end/back-end
(FE/BE) OWA architecture.
Using an FE/BE topology
Are you already running multiple Exchange
2000 servers in your organization? If so,
Microsoft recommends using the FE/BE
server architecture to deploy OWA. With this
topology, the front-end Exchange 2000 server
sends HTTP requests to a back-end Exchange
2000 server running OWA. The front-end
server first performs a lookup in AD to deter-
mine which back-end server should receive the
request and then relays the request to the
appropriate server.
The obvious benefit here is the single, con-
sistent namespace the front-end server pro-
Figure A
Laptop Exchange 2000
Firewall front-end server
An FE/BE topology
vides to users. Users don’t need to remember
URLs specifying exactly which servers their
mailboxes are on. Additionally, with a single
namespace, mailboxes can be moved between
back-end servers and users can still use the
same URL.
The other benefit is seen when allowing
OWA access via a secure firewall connection
or DMZ. As Figure A illustrates, only the front-
end server is exposed on port 80 to the Inter-
net. Since this server does not contact user
mailboxes or data, it provides an additional
level of security.
Any server running Exchange 2000 Enter-
prise Edition can become a front-end server.
The only change needed is the selection of the
This Is A Front End Server check box in the
server’s Properties dialog box, shown in Figure B.
After making the change, you must restart
the Exchange and IIS services or restart the
computer. The change essentially tells the
Exchange 2000 server to redirect all HTTP
traffic to a back-end server that contains the
user’s mailbox.
As a general rule, one front-end server is
recommended for every four back-end servers.
Of course this is just a rule of thumb. The
actual number of front-end servers needed
will depend on the number of users, the type
Active
Directory
Back-end servers
Firewall Exchange 2000
Server A
Exchange 2000 Exchange 2000
Server B Server C
Administration 141
 of users (light vs. heavy), and the average
length of sessions. Front-end servers do not
need large or particularly fast disk storage but
should have specs similar to a Web server,
including fast CPUs and adequate memory.
Securing communication
between servers
The front-end server handles authentication in
one of two ways. Either the server is config-
ured to authenticate users, or it is set up to for-
ward the request anonymously to the back-end
Exchange 2000 server. The recommended
configuration is to have the front-end server
authenticate users.
Exchange 2000 front-end servers support
only HTTP 1.1 basic authentication between
client computers and front-end servers, as well
as between front-end and back-end servers.
Basic authentication allows for just a weak
form of encoding when sending usernames
and passwords across the network, so the use
of SSL is highly recommended.
This is where another benefit of FE/BE
architecture comes in. When using SSL, front-
end servers can handle all encryption and
Figure B Figure C
Requiring SSL on the front-end servers
Configuring a front-end server
142 Administrator’s Guide to VPN and Remote Access, Second Edition
decryption processing, which improves net-
work performance by removing SSL process-
ing tasks from back-end servers. As an added
measure of security, you should make SSL
connections to the front-end server mandatory
by disabling access without it, as we’ve done in
Figure C.
You should also note that HTTP communi-
cation between the front-end and back-end
servers is not encrypted. Front-end servers do
not support Windows Integrated Security
(which includes both NTLM and Kerberos
authentication). They also do not support using
SSL to communicate with back-end servers. All
of these factors lead to the conclusion that SSL
on the front-end is the best solution.
OWA logon for front-end servers
Typically, users must enter their username in
the format domain\username when logging on to
a front-end server. However, you can config-
ure the front-end server to assume a default
domain so that users do not need to type their
domain name. Just modify the Exchange and
Public virtual directories and manually enter
the default domain name, as shown in Figure D.
 After making this change, make sure that Figure D
the System Attendant service is running so
that the configuration settings replicate from
the directory to the IIS metabase or simply
restart Exchange System Attendant to force
replication. After replication is complete, users
can log on with just their username and pass-
word; no domain name is required.
An additional option for authentication is to
configure a User Principal Name (UPN) logon
for users. This allows users to enter their e-mail
address as their username. To configure UPN,
Entering a default domain name for user logons
enter a backslash in the Default Domain text
box shown in Figure D. After you configure
this in the properties of the virtual directories pack, the control that the back-end server is
on all front-end and back-end servers, users referencing might not exist. As a result, OWA
can authenticate using user@domain.com as won’t work for users whose mailboxes are on
their username. (Note that Exchange SP1 is the upgraded back-end server. Just make sure
recommended if you decide to use this feature.) that you upgrade all front-end servers first so
that users see templates from the back-end
Service pack install order server. These templates reference the previous
The order in which you apply Exchange 2000 versions of the controls, which still exist on
service packs in an FE/BE OWA architecture the front-end server because the files are ver-
is important. Always remember to upgrade sioned and not removed in an upgrade.
every front-end server in the organization
before you upgrade any back-end servers. This Summary
is because of the way OWA’s templates and When deployed properly, an OWA solution
controls were designed. A problem arises using front-end/back-end architecture can be
when the servers run different versions of more reliable, result in greater performance,
service packs. and provide tighter security than the generic
If a template on a back-end server refer- setup offered by default on Exchange 2000.
ences a control on a front-end server, and the Use this topology to take your OWA to the
front-end server is running a previous service next level.

Implementing site-to-site VPN with

BorderManager 3.x
Feb 28, 2001
By Ron Nutter, MCSE, CNE, ASE

R
unning point-to-point data circuits
(also known as private lines) between
your company’s locations can be very
expensive, especially if one or more of those
locations are overseas. BorderManager is more
than just a firewall or a method of controlling
access to the Internet—you also have the abil-
ity to establish a virtual private network
(VPN), which will use the Internet to connect
your locations. All you will need to do is install

Administration 143
 a data circuit to a local ISP and a BorderMan-
ager server at each location.
In this article, we will walk through the
steps of setting up a site-to-site VPN. The first
step involves setting up a master VPN server
(each VPN configuration will have only one
master VPN server). Although we will be set-
ting up just a two-site VPN in this article, each
additional site you add to your VPN will be a
slave server. We will be using NetWare 5.1 with
Support Pack 2a applied and BorderManager
3.5 with BorderManager Support Pack 2
applied.
Before you start
One thing you will want to think about before
beginning to implement a site-to-site VPN is
whether to implement VPN services on your
existing BorderManager server or implement a
server dedicated solely to the VPN links
between locations. If you put the VPN serv-
ices on your existing BorderManager server,
you will need to be very careful about when
you reboot the server, as this will take your
entire VPN down. If you implement a dedi-
cated VPN server, you should be able to
reduce the amount of downtime from reboots,
as you shouldn’t be working with this server
significantly on a day-to-day basis.
A fault tolerant network (one that can han-
dle problems thrown at it and keep running
basically undisturbed) might be accomplished
by implementing a dedicated VPN server at
each location and then making the Border-
Manager server you already have a slave VPN
server. Before implementing this type of solu-
tion, I recommend setting up a proof of con-
cept system to make sure that everything will
work as expected.
Establishing site-to-site VPN on
the master server
At this point, we will assume that you already
have NetWare 5.1 and BorderManager installed
on the server that will be your master VPN
server and that the appropriate Support Packs
have been installed. Type LOAD VPNCFG at
the server’s console prompt and press [Enter].
When the VPNCFG main menu screen
appears, highlight and press [Enter] on the
144 Administrator’s Guide to VPN and Remote Access, Second Edition
Master Server Configuration option. A mes-
sage will appear indicating you can have only
one master VPN server in the network. High-
light Continue and press [Enter].
The first thing that you will need to do is tell
BorderManager what the TCP/IP addresses
are for the public card and for the VPN net-
work. Highlight Configure TCP/IP Addresses
and press [Enter]. You will need to enter the
TCP/IP address and subnet mask for both the
public and VPN tunnels. The public TCP/IP
address and mask are the same as the ones you
defined on your BorderManager server.
The VPN address and subnet mask will
take a little thought before you proceed. This
address has to be unique on your network; the
address in this range can be used anywhere
else on the network—anywhere, that is, except
on the other BorderManager server (which
will use a different address out of the range
defined by the subnet mask that you enter for
the VPN tunnel). Once you have entered the
required information, press [Esc], highlight
Yes, and press [Enter]. A series of messages
will shortly appear indicating the NDS schema
is being extended and the base VPN configu-
ration is set up.
In order for the VPN to work, you will need
to have some type of encryption setup. High-
light the Generate Encryption option and
press [Enter]. You will be prompted to enter a
random seed to be used to generate the key.
Enter a random string of letters and numbers
and press [Enter]. Don’t worry about remem-
bering this string. (This doesn’t have to be the
same on each server.)
When the encryption generation process is
complete, you will see a message on the server
screen to that effect. You will be returned to
the VPN master server screen. Highlight the
Authenticate Encryption Information option
and press [Enter].
You will see a screen on the server showing
a string of numbers and letters. This is known
as the digest, the information used by the
servers to set up the VPN between sites. You
will need to have this information ready for the
network administrator at the other end of the
VPN connection (if you aren’t going to do the
install yourself) so that the admin will know
that the setup is enabled correctly. Press [Enter] Figure A
to return to the main VPN menu screen.
You need to export the information neces-
sary so that the slave VPN server will know
how to talk to the master VPN server. Put a
blank floppy in the server’s A: drive. Highlight
the Copy Encryption Information option and
press [Enter] to continue. The default path
should be A:\. Unless your server’s floppy
drive is something other than A:, accept the
default and press [Enter].
Once the information is copied to a file,
you will see a message on the server’s console
screen. The name of the file it creates is
Minfo.vpn. You have the option of e-mailing
the Minfo.vpn file to the administrator at the
other end of the connection, mailing the You must configure TCP/IP on the slave server.
floppy, or going to that location yourself.

Setting up the site-to-site VPN will appear asking you to verify the path to the
Minfo.vpn file.
on the slave server Let’s assume you are doing the slave VPN
Now that the master VPN server is set up, we
install yourself and have brought this file on a
can move on to the slave VPN server. Load
floppy. Insert the floppy into the slave server’s
the VPNCFG NLM on the slave server. High-
floppy drive and press [Enter]. After the
light the Slave VPN Server Configuration
Minfo.vpn file copies, you will see a digest
option and press [Enter]. Highlight the Con-
screen displayed. This information should
figure TCP/IP Address option and press
match exactly what you saw on the master
[Enter] just as you did on the master VPN
VPN server. If this matches, highlight Yes
server. When you do, you’ll see the screen
and press [Enter].
shown in Figure A.
You will next be asked to enter information
As with the master VPN server, you will
to help randomize the Diffie-Hellman public
need to enter the TCP/IP address and subnet
and private keys that will be generated on this
mask for the public card and the VPN tunnel.
server. This information will be used on the
In the case of the slave VPN tunnel, you will
master VPN server to actually build the VPN
need to do something a little different. For
connection between servers. Enter the requested
example, if you entered a TCP/IP tunnel
information and press [Enter]. A screen will
address on the master VPN server of 10.10.1.1
appear when the VPN information has been
with a subnet mask of 255.255.255.0, you will
created, and another screen follows when
need to use the same subnet mask on the slave
NDS has been extended to handle this task.
VPN but with a different TCP/IP address. In
The next step involves copying the VPN
our example, we would use something like
information from the slave server to a floppy
10.10.1.2 for the TCP/IP address of the VPN
so that the master VPN server will know how
tunnel on the slave VPN server. Press [Esc],
to set up the VPN tunnel between servers.
highlight Yes, and press [Enter] to continue.
Highlight the Copy Encryption Information
Your next step will be to generate the
option and press [Enter]. You will be asked to
encryption information necessary for this
verify the drive and path to the Sinfo.vpn file
server to be able to participate in the VPN.
that will be created. Press [Enter] to continue.
Highlight the Generate Encryption Informa-
One thing to note at this point is that if you
tion option and press [Enter]. A pop-up box
will have multiple slave servers in your VPN

Administration 145
 configuration, you will want to rename the
Sinfo.vpn file to another name descriptive of
the site it is for. This will make the process eas-
ier if you have to tear down and recreate the
VPN for some reason. Once the VPN file has
been copied to the floppy, you will see a mes-
sage on the server telling you about renaming
the file.
Completing the VPN setup in
NetWare Administrator
To complete the site-to-site setup, you will need
to go into NetWare Administrator. Double-
click on the NDS server object that is running
BorderManager. Click on the BorderManager
Setup tab and then click on the VPN tab on the
BorderManager Setup properties screen. High-
light the Master Site To Site option and click on
the Details button. When the VPN Master
properties screen appears, click Control
Options. On the Control Options properties
screen, you will need to select what protocols
you want to cross the VPN.
You will also want to choose the topology
you want for your VPN, as shown in Figure B.
You have a choice of three topologies: Full
Mesh, Star, and Ring. With Full Mesh, all the
VPN sites can reach all of the other sites
directly without having to go to the master
VPN site first. With a Star topology, all slave
Figure B Figure C
You must choose your topology in NetWare
Administrator.
You can monitor your VPN on the VPN Member Activity screen.
146 Administrator’s Guide to VPN and Remote Access, Second Edition
sites will have to go through the master site
before they will be able to talk to other slave
sites. The disadvantage with this solution is
that it will produce additional traffic at your
master VPN site. With the Ring option, each
VPN site will have connections to two of its
neighbors. This solution is fine if most of the
traffic will be between adjacent systems but
could cause delay because of additional hops
produced by this configuration when the most
distant systems need to talk to each other.
Both the Star and Ring options could suffer
communication problems if a critical part of
the system were to go down. With the Full
Mesh option, you should still be able to talk
between systems even if one or two are down.
If the master VPN server is down, you should
still be able to talk, but you won’t be able to
add or remove slave VPN servers until the
master VPN server is back online.
Once you have selected the options on the
Control Options screen and clicked OK, you will
be presented with a screen that will allow you to
add the slave VPN server to your VPN network.
From the VPN Master Server properties screen,
click Add and browse the floppy containing
the Sinfo.vpn file. Double-click on Sinfo.vpn
(or the file name you have renamed it to).
After NetWare Administrator reads the file,
you will see a digest info screen containing a
series of letter and number combinations. The
information on this screen should match what
was displayed on the digest screen on the slave
server when you created the encryption infor-
mation. Click Yes to proceed. When the Adding
Server To VPN screen appears, click Yes to
enter the info read from the Sinfo.vpn file.
The VPN Members screen should now be
visible. TCP/IP RIP is enabled by default.
Leaving this option enabled will allow the
remote sites to seamlessly route over your net-
work without your having to enter static routes
within NetWare Administrator. If you will be
connecting other companies (and other NDS
trees) into your VPN, you may want to deselect
TCP/IP RIP and go with static route map-
pings to help prevent access to parts of your
network by the other companies that will be
connecting to you.
Click OK to save this configuration and
return to the VPN Master properties screen.
When the VPN Master screen appears, you
will see the slave VPN server you just added
appear in the list of VPN servers. Click on the
Status button and check the sync status of the
VPN servers. Any time you add another slave
VPN server or make significant changes to the
network and have what appear to be commu-
nications problems, this is a good screen to
check to make sure that all the servers are up-
to-date with the information about the rest of
the network. Congratulations, you now have a
VPN up and running.
Monitoring the VPN
Monitoring the VPN is something that should
be done periodically even if things are going
well. Any time you add a server to the VPN,
you will see a message appear on the master
VPN server console screen telling you that a
server has been added. A similar message will
appear on the slave VPN servers.
Depending on the way you have imple-
mented filtering in BorderManager, you may
need to temporarily unload the filters to do
this next series of tests. After you have added a
slave VPN server to your network, first try
pinging the TCP/IP address of the VPN tun-
nel on your end. Next, ping the TCP/IP
address of the VPN tunnel on the server you
just added and finally the TCP/IP address of
the private card on the slave VPN server. If
your pinging fails to get a response at any
point in this process, this indicates a communi-
cation problem that should be addressed
before proceeding.
Another screen to check periodically is the
VPN Member Activity screen, shown in Figure C.
This screen is reached from the sync status
screen mentioned earlier. Highlight the VPN
server that you want to check and click on the
Activity button. When the VPN Member
Activity screen appears, you will see what is
going on with a particular slave VPN server
(what protocols are being used, how many
packets are being sent/received, etc.).
Conclusion
As you can see, setting up a site-to-site VPN
isn’t that hard. As with any other network addi-
tion, take a few moments to document what
you have done and the TCP/IP addresses
being used for the VPN tunnel and make a
copy of the .VPN files you used to create the
VPN in case you need to tear down and
re-create the VPN. If you haven’t already
started doing so, have the individual responsi-
ble for the slave VPN servers keep a log of
changes made to the servers so that if things
stop working, you will have a base from which
to start when figuring out the problem.
Administration 147
 Setting up client-to-site VPN in
BorderManager 3.x
Jan 12, 2000
By Ron Nutter, MCSE, CNE, ASE
P
rotecting the data on your corporate
network is becoming more important
each day. For Web site access, you can
use SSL (Secure Socket Layer) on your Web
server to provide a layer of protection. How-
ever, you still need to find a way to allow
access to files on the network and access to
server-based services that don’t support SSL.
(Yes, Virginia, there are a few server-based
services that don’t support SSL.) In this article,
I’ll take you through the steps of setting up
the client-to-site VPN function in Border-
Manager 3.x.
Setting up the server side of VPN
The process of setting up client-to-site VPN
in BorderManager begins with establishing an
Rconsole session to the server that’s running
BorderManager. At the console command
prompt, type VPNCFG (or load VPNCFG if
you’re using NetWare 4.x) and press [Enter]. A
message will appear indicating that there can
be only one master server. Highlight Continue
and press [Enter]. When the Master Server
Configuration screen appears, highlight Con-
figure IP Address and press [Enter]. Highlight
Not Configured beside Public IP Address,
enter the IP address that is currently assigned
to the public card in your BorderManager
server, and press [Enter]. You also will need to
enter the subnet mask that matches the IP
address of the public card. Finally, enter the IP
address and subnet mask to be used for the
VPN tunnel of the configuration.
I’d like to point out two things that aren’t
made clear in the BorderManager documenta-
tion. You must use both the IP address and
subnet mask that are currently bound to the
public card in the server that’s running Bor-
derManager. Although it may be possible to
bind a secondary IP address to the public
card, this approach isn’t recommended; it may
result in sporadic operation of the client VPN
function of BorderManager, and Novell Sup-
148 Administrator’s Guide to VPN and Remote Access, Second Edition
port won’t be able to help if you call in with
a problem. You will want to assign an IP
address from a different range than the one
that is being used currently on the private
card(s) in your BorderManager server. For
example, if you have 10.0.1.1 and 10.0.2.1
using a subnet mask of 255.255.255.0 that’s
bound to private cards in your BorderManager
server, you should use something like 10.0.3.1
with a subnet mask of 255.255.255.0. It will
give the virtual private address that you are
assigning to the VPN tunnel part of the con-
figuration, which gives the client VPN traffic a
place to route. It also ensures that the traffic is
handled properly for the encryption and
decryption that occurs as a part of the client-
to-site VPN process. Once you have entered
the IP addresses and subnet masks for the
public and private side of the VPN part of
BorderManager, press [Esc], highlight Yes,
and press [Enter] to save the configuration.
If you haven’t progressed to the point with
BorderManager that you’ve configured packet
filters, you’ll probably receive an error message
saying that VPNCFG can’t configure packet
filters. This problem happens because the out-
going packet filters are disabled, but it’s a nor-
mal occurrence when packet filters haven’t
been configured or when packet filters have
been created. To clear this error, you’ll need
to load the filter configuration NLM
(FILTCFG.NLM) in order to check the exist-
ing filters, enable outgoing RIP filters, and
select the menu option that will update the
changes you made. Press [Enter] to acknowl-
edge the error screen. A secondary message
will follow to indicate that VPNCFG can’t add
the filters it needs in order to operate. Press
the [Enter] key to continue.
Change to the console command prompt
and type filtcfg (or load FILTCFG if you’re
using NetWare 4.x) and press [Enter]. High-
light Configure TCP/IP Filters and press
[Enter]. When the TCP/IP screen appears,
highlight Outgoing RIP (Routing Information
Protocol) Filters and press [Enter]. When you
see the Outgoing RIP Filter screen, highlight
Disabled beside the status options and press
[Enter]. Then, highlight the Enabled option
and press [Enter].
Now, press [Esc] until you are given the
option to exit FILTCFG; then highlight Yes
and press [Enter]. Return to VPNCFG.NLM’s
Master Server Configuration screen, highlight
the Generate Encryption Information option,
and press [Enter]. When you see the Enter
Random Seed box, enter a random string of
characters (maybe something like your Admin
password!) and press [Enter]. A screen will
appear and indicate that the encryption infor-
mation is being generated. Factors affecting
the amount of time that this process will take
include the length of the random key that you
entered, the speed of the processor on the
BorderManager server, and the number of
currently pending requests that the server is
processing. When the key generation is fin-
ished, a message will appear on the screen to
inform you of its completion. Press [Enter] to
proceed.
At this time, the VPN attributes will be
added to NDS. When that process is complete,
another message will appear. Press [Esc] when
the process is complete, and you’ll see a mes-
sage indicating that VPMASTER.NLM was
loaded successfully. Press [Enter] to proceed.
Next, highlight the Update VPN Filters option
in VPNCFG.NLM and press [Enter]. A series
of messages will tell you that the NLM is
checking to see if the filters it needs have been
set and that the NLM is updating the VPN fil-
ters. When this process has finished, press
[Enter]. Now, highlight the Display VPN
Server Configuration option and press [Enter].
Verify that all the information you entered is
correct and that all the key lines indicate Con-
figured. Press [Esc] until you’re prompted to
exit VPNCFG.NLM. Highlight Yes and press
[Enter] to continue. Now, you can terminate
the Rconsole session; the server side portion of
the client-to-VPN setup is pretty much com-
plete. The remainder of the VPN setup will
take place on a workstation running NWAD-
MIN and using the BorderManager snap-in.
After starting NWADMIN, double-click the
NDS server object that’s running BorderMan-
ager. Then, click the BorderManager Setup
button and click the VPN tab. The Master Site
To Site box should be checked. Click the box
beside Client To Site and click Details. To pass
IPX traffic over the VPN connection, enter a
unique IPX address; then click OK. A series of
messages will appear on the console prompt
screen of the BorderManager server. You
should see several waiting for timestamp messages.
Depending on the level of activity on your
BorderManager server, these messages may
repeat themselves several times before you see
a timestamp completed message for each NLM
(VPMASTER.NLM and BRDSRV.NLM).
After you see these messages, you can continue
with the BorderManager VPN configuration.
Before proceeding to the client portion,
you’ll want to restart the BorderManager
server and make sure that everything relating
to the VPN service loads and initializes cor-
rectly. Although restarting the program is a
requirement for BorderManager only when
you’re running on NetWare 5, it’s a good idea
to restart on NetWare 4, too—just to make
sure that everything is OK so far.
Setting up the client side of
client-to-server VPN
To minimize problems, you should use Novell
client version 3.1 or later. The latest VPN client
is BM3VPD04.EXE, which was released
around mid-September of 1999. After running
the self-extracting executable, go to the disk 1
directory and run SETUP.EXE. During the
installation, you will be asked to choose Dial-Up
VPN, LAN VPN, or both. You will use the
Dial-Up VPN when you come in over a regular
dial-up connection. The LAN VPN connection
is a recent addition to the client VPN portion of
BorderManager. It allows you to use an existing
connection, such as a DSL connection or cable
modem, to gain access to your network over an
encrypted connection instead of having to put
up with a slower async connection.
One quick check is in order before you try
to establish that first encrypted connection to
your network. Double-click on either of the
VPN options, which were added during the
Administration 149
 installation of the VPN client software. Now, give you an idea of what kind of changes to
click the NetWare Options tab. If you can click your container and/or personal login scripts
on only the Enable IPX check box and the may be necessary to allow users to get in and out
other options are not available, you have a of your network quickly.
client-level problem that will need to be Make sure that your users know that while
addressed. The best way to fix this problem is they are logged in, they won’t be able to
to uninstall the VPN client, uninstall the exist- browse the Internet or access resources that
ing NetWare client and network card driver, are off of your network. If you do, Border-
and reinstall the network card driver and Nov- Manager won’t have to field requests from the
ell client software first, followed by the VPN VPN users who are routed over the same con-
client software. After you reboot the software, nection on which they are coming into your
the problem should be resolved. If you still network.
have a problem, you’ll want to get a copy of When the users click OK to establish the
the Novell UNC32 executable, which will take VPN connection, they will see a progress box
the de-installation under the VPN
process one step fur- Status tab of the
ther by removing all You may find that you have more VPN client. As each
entries that were cre- demand for the VPN service than you step of the login/
ated in the Windows authentication
have resources to handle the need.
registry by the Nov- process is com-
ell client software. pleted, users will see
the following mes-
Establishing a connection with sages: Connecting For Authentication, Authenticating
the LAN VPN option NetWare User, Authenticated NetWare User,
The first time you invoke either of the VPN Enabled IP Encryption, Enabled IPX Encryption
options, you will have a few extra things to (which you’ll see only if you’re going to estab-
remember. You will need to enter your Net- lish an IPX connection to your network), and
Ware user name, password, context, and the Performing NetWare Login. Keep in mind that
public IP address of the BorderManager while you are using the LAN VPN client, you
server to which you will be connecting. In the won’t be able to access anything that is off
context field, don’t include a leading period your network. It’s actually a good thing, but
when you enter the specific NDS context of your users may become a little confused when
the user account that you are using to log in. they try to reach another Web site while they’re
While the software should be able to handle it, getting their e-mail from your Exchange or
I received error messages when I used a lead- Groupwise server.
ing period.
Before clicking OK to start the login process, Establishing a connection with
click the NetWare Options tab. Your options are the dial-up VPN option
Enable IPX, Login To NetWare, Clear Current Using the dial-up VPN is fairly simple. It can
Connection, Run Scripts, Display Results Win- use your existing setup to call your ISP and
dow, and Close Script Results Automatically. build an encrypted connection to your Border-
Before turning remote access over to your users, Manager server. You begin the process by
you may want to try logging in over a regular double-clicking the Dial-up VPN Client icon,
dial-up and a DSL-type connection. Testing which appears on the desktop next to the
them will help you determine how long it will VPN installation program. Click the NetWare
take your users to log in to the network and Login tab and fill in the NetWare user name,
allow you to anticipate the kinds of questions/ password, NDS contact, and server IP address.
calls that you will probably get when they start When entering the NDS context for this user,
using this access. One option that I would rec- don’t include a leading period before the con-
ommend you start with is Run Scripts. It will tainer name, or you may have a problem

150 Administrator’s Guide to VPN and Remote Access, Second Edition

logging in. As I mentioned earlier, you’ll want
to enter the public IP address of your Border-
Manager server.
Now, click the NetWare Options tab and
make sure that the Enable IPX option is
selected. For your first time dialing up, you may
want to leave all the options enabled in order to
get an idea of what you may want to deselect
when you put the client VPN process into pro-
duction use. You may want to think about not
using Novell’s Application Launcher if you have
a lot of icons for distributing available applica-
tions to your users. Since some dial-up users can
sometimes expect a response from the server
just as if they were attached directly to it, con-
trolling the applications that they can access
remotely may be worthwhile. You can use either
a separate NDS container or a special group to
limit the applications that are available to
remote users.
The next step is to click the Dial-up tab.
Click on the drop-down box beside the dial-up
entry name and make sure the correct Dial Up
Networking address book entry is selected.
Enter the correct dial-up user name and pass-
word for the Dial-up Networking (DUN) con-
figuration that you are using. If you normally
don’t use DUN but use software provided by
the ISP to establish your connection, you may
want to talk to your ISP’s tech support folks to
see if you need to do something differently.
For example, those who use Netcom as their
ISP would have to use us,ppp,username—instead
of just a user name if they used DUN to
establish the connection.
Now, click the VPN Status tab and click OK
to begin the process of establishing the con-
nection to your BorderManager server via your
ISP. The progress screen will flash the number
that is being dialed. Once the connection has
been made to the ISP’s modem pool, the mes-
sage will change to Authenticating Dial up user
(ISP) and then to Authenticating NetWare User. If
you get an NDS-309 message just after the
connection is made, you may want to recheck
your BorderManager server and make sure that
it has been restarted, as indicated in the Border-
Manager VPN installation instructions. Also,
make sure that the login name, password, and
NDS context have been entered correctly.
Once all the statements in the login script
have been processed and all the icons in the
NAL window have been displayed, try estab-
lishing a VPN connection and deselecting the
Process Login Script option. If your Border-
Manager server is running on NetWare 5, you
might consider deselecting the IPX Only
option to minimize the amount of negotiation
that occurs in setting up an encrypted link for
more than one protocol.
The first time that you establish a dial-up
connection to your BorderManager server, you
will be presented with an Authenticate VPN Client
message with a series of numbers and letters
that will look something like 4D DD F2 93 7A
CD CD BB 23 57 BB AA 23 3D F3. This infor-
mation should match what is available by click-
ing the Digest button in NWADMIN. If the
information doesn’t match, you may want to try
either reestablishing the connection or verifying
that everything is configured correctly on your
BorderManager server. Otherwise, the VPN
connection may not work correctly, if at all.
Suppose that you have users who want to
access the Internet before or after they use the
encrypted link into your network. In that case,
you may want to have them use the regular
DUN icon to establish the connection to the
ISP and then the LAN VPN icon to make and
break the connection to your corporate net-
work. That way, they won’t have to reestablish
a nonencrypted connection to use the remain-
der of the Internet.
Optimizing the client
VPN connection
If you’re using the Single Sign-on fea-
ture of BorderManager and loading the
CLNTRUST.EXE and DWNTRUST.EXE
files from the login script (a container, per-
sonal, or profile script), you might want to
consider having your users type in a special
login ID in order to bypass that part of the
login script. You also can make them part of
a group that bypasses that part of the login
script. Since they’re coming in over an
encrypted connection, there won’t be any
benefit to having them run these files.
Depending on how involved your login
scripts are at a container level, you may want to
Administration 151
 set up a special NDS context through which
the remote users will log in—thus minimizing
lengthy login times. It will give you a way to
administer ZEN application objects, too. (You
really don’t want your users to load the applica-
tions that they’ll use over a slower dial-up con-
nection while they’re on your network, do
you?) This approach can help you restrict
access into the network via BorderManager
VPN by modifying the rule that you set up ear-
lier, which limited use only to those who are in
the container that is eligible for VPN access.
Monitoring client VPN
connections
Now, double-click the NDS in NWADMIN
upon which BorderManager is running. When
the BorderManager screen appears, click the
BorderManager Setup button. Select the VPN
tab and click the Details button. A list of
servers currently configured for VPN will
appear, with each server listed by name and
public IP address.
To see what is happening with the VPN
function on a particular server, highlight the
name of the server in the list and click the Sta-
tus button. A synchronization status screen
will appear, and you’ll see the server you just
selected listed again with a status that should
show as up to date. To see the current VPN
connection status, click the Activity button on
the Synchronization Status page. You’ll see
several boxes of information on this screen
that cover everything from global parameters
relating to the overall VPN connection to
those items that are protocol specific. When
this screen comes up, it will show only server-
to-server-based connections by default. You’ll
need to click the Clients button to change the
view to the Client to Site VPN view. In the
upper left-hand corner of the VPN Member
Activity screen, you’ll see a listing of the cur-
rently active connections. Each connection will
show the user’s NDS login name with an up or
down arrow for both IP and IPX protocols.
This screen is good to watch while users are
trying to establish a VPN connection and are
complaining that they can’t get through. Since
this screen is somewhat static in nature, you’ll
need to use the Update button to make sure
152 Administrator’s Guide to VPN and Remote Access, Second Edition
that you are looking at the most current infor-
mation about the connection. Watch the up
and down arrows on this screen as connec-
tions are being made. Different colors are used
to indicate problems, progress in establishing
the connection, or activity levels on the
selected connections. Click the Help button to
learn what the colors mean and how to inter-
pret the information that they are giving you.
As you turn the VPN function into produc-
tion use, you may find that you have more
demand for the VPN service than you have
resources to handle the need. By default, the
idle time that a connection is allowed to have
before the connection is broken is 15 minutes.
You can change this amount of time by click-
ing the Timeout button and decreasing or
increasing the timeout value. Once the connec-
tion is dropped, users will have to restart the
VPN client function and log in again to the
network in order to continue their work. If
you want to see a step-by-step log of what
occurs as a connection is established, authenti-
cated, or broken, begin by clicking OK and
closing out the VPN Member Activity screen.
When you return to the previous screen, click
the Audit Log button.
When the Audit Log screen appears, the
end time will be the current time for the work-
station upon which NWADMIN is running,
and the start time will be approximately nine
hours before that time. Your only option in
this version of the BorderManager snap-in is
to use the up and down arrow on the time box
to adjust the date and time. Once you’ve
selected the desired date and time ranges, click
the Acquire button, and the information will
be extracted from the BorderManager logs.
You’ll see a step-by-step record of what
occurred while the connection was being
established or broken. Using the check boxes,
you can filter what is presented, and you won’t
have to suffer from information overload.
Several messages will appear on the server
console screen as connections are made and
broken. On incoming connections, you’ll see an
incoming WAN connection first as the request
comes through and then a message when the
connection is authenticated. The final message
will appear when the authenticated connection
is disconnected or stopped. These messages
give you a quicker view of VPN usage without
your having to go into NWADMIN and
drilling down to the view that you want.
Avoiding problems in
BorderManager
If you’re running BorderManager 3.0 on Net-
Ware 5, there are a couple of steps that you
need to take in order to keep things running
smoothly. You’ll want to copy these files:
X IPFLT31.NLM from the directory created
by the NetWare 5 SP3A—Products/
NOBM3.5/SYSTEM
X CSAUDIT.NLM from the Products/
NOBM/SYSTEM/CSAUDIT.NLM
directory
Place both NLMs in the SYS:SYSTEM
directory. Since BorderManager depends on
Serving up NetWare’s Web Manager
Aug 1, 2000
By Steven Pittsley, CNE
H
ow about a server management tool
that requires no installation, allows
you to perform administrative tasks
from any Web browser, and costs you
absolutely nothing? You say it sounds too
good to be true? Well, in this instance, it really
is true. The NetWare Web Manager is installed
automatically during NetWare 5.1 installation,
requires no initial configuration, allows you to
use a Web browser to perform management
tasks, and is a standard piece of NetWare 5.1.
In this article, you will learn about some of the
outstanding features of this great new utility.
The NetWare Web Manager consists of a
set of NLMs that run on the server. During
NetWare 5.1 installation, the command to load
the NLM is added to AUTOEXEC.NCF. To
CSAUDIT.NLM, you’ll need to restart the
server after the new NLMs are copied and in
place. You’ll have to update these NLMs so
that the filters needed by BorderManager and
the VPN function can be updated and accessed
correctly. Verify that you are using the latest
NetWare Service Pack and the latest service
pack for your version of BorderManager.
We’ve walked you through the basics of set-
ting up client-to-site VPN in BorderManager.
The service itself is fairly straightforward to
set up and should be trouble free—as long as
you take your time setting things up. Using the
client-to-site VPN function allows you to use
the ISP’s modem pool and national data net-
work without having to build your own.
manually load the Web Manager, type LOAD
NSWEB at the server console. Figure A shows
the Web Manager screen that’s displayed on
the server. As you can see, very little can be
accomplished here. Your only options are to
restart or shut down the Web Manager.
Accessing Web Manager
To access the NetWare Web Manager, launch
your Internet browser of choice and type a
URL that uses the following syntax:
https://servername:2200
An example of this would be https://
server1.novell.com:2200. The default IP port
is 2200, but you can change this. You can ver-
ify the IP port from the Web Manager screen
on the file server, which is shown in Figure A.
Administration 153
 Once you enter the URL, you must log in as
a user with Admin rights. After being authenti-
cated, the Web Manager General Administra-
tion screen will be displayed in the browser
and will look similar to Figure B.
Using Web Manager
You are given the following four choices under
the General Administration heading:
1. Admin Preferences will provide you with
Web Manager administration functions.
You can turn on/off SSL, shut down Web
Manager, change the IP port, set logging
options, and view access and error logs.
Figure A
The Web Manager screen enables you to restart and shut down the Web Manager.
Figure B
The Web Manager General Administration screen enables you to perform administrative
functions.
154 Administrator’s Guide to VPN and Remote Access, Second Edition
2. The Global Settings section allows you to
select where you obtain directory service.
Your choices are Local database, LDAP
directory server, and NDS.
3. The Users and Groups section provides
you with rudimentary NDS management
capabilities. NetWare Administrator still
has much more functionality, but this util-
ity works well for making basic changes.
4. Cluster Management provides you with
basic cluster administration capabilities.
Navigation
You can return to the Web Manager General
Administration screen by clicking the Server
Administration link in the upper-right corner
of any of these screens. From the Web Man-
ager’s main page, you have access to each of
the Web servers installed on the network, as
well as the NetWare Management Portal and
NDS management. If a server is running, the
On button will be lit, and if the server is
stopped, the Off button will be lit. Clicking
these buttons will either stop or start the
server.
You can access the Web server configura-
tion screens by clicking the button located next
to the On and Off buttons. The file server
name that is displayed on the button indicates
where the Web server is installed. The Web
server configuration pages are easy to navigate
and provide you with excellent functionality.
The most exciting feature of the NetWare
Web Manager is the ability to access it from
virtually any workstation on the network,
regardless of the client software that’s running
on the computer. Thus, if you are working in a
remote area that has an NT domain, you can
still manage your NetWare server. A traveling
administrator will love the easy access and
powerful capabilities of the NetWare Web
Manager.
Believe it or not: A Linux VPN without
kernel recompilation
Oct 26, 2001
By Jack Wallen, Jr.
Y
ou read correctly. Until today, I would
never have believed it myself. Having
dealt with the likes of FreeS/WAN
and PoPToP, I know how difficult it can be to
have to recompile a kernel, attempt to load in
the proper modules, and then (and only then)
hope the application will work with both your
client and your VPN server.
Just when you thought it was unsafe to
tread the VPN waters, along comes Cisco to
save the day for Linux client users. The new
Cisco vpnclient is not only amazingly simple to
use, but it’s also secure and reliable. In this arti-
cle, I’ll install, configure, and run an instance
of Cisco’s new vpnclient for Linux.
How to obtain and install
vpnclient
This VPN client package is included in the
VPN Solutions package and supports the Intel
version of Red Hat Linux 6.2 (or glibc >=
2.1.1-6 libraries) using kernel >= 2.2.12.
Unfortunately, you can’t get this package with-
out buying the VPN Solutions package, but it’s
well worth the purchase if you want both a
rock-solid VPN server and a killer client
application.
The first step of the installation is to
unpack the package. The release I tested was
vpnclient-linux-3.0.8-k9.tar .gz. To unpack this
file, run the command:
tar xvzf vpnclient-linux-3.0.8
-k9.tar.gz
which will create a new directory called, simply
enough, vpnclient.
The next step is to cd into the newly created
directory with the command:
cd vpnclient
Now you’re ready to run the install. The instal-
lation of this package is quite simple. As root,
run the command:
vpnclient_init
You’ll be asked a few questions regarding the
location of your kernel source, where you
would like the executable binary file to be
placed, and whether you’d like the VPN serv-
ice to start at boot time. It’s that simple.
Once you’ve installed the application, start
the VPN service with this command:
/etc/rc.d/init.d/vpnclient_init start
Configuration
Configuring Cisco’s vpnclient can be tricky if
you’re not sure where to put the configuration.
When you install the application, you’ll notice
a sample.pcf file in the vpnclient directory. (All
user profiles must have the .pcf format.) This
file is what you’ll base your configuration on
and is also mirrored in the /etc/CiscoSystemsVP-
NClient/Profiles/ directory. The latter file is the
one that the application actually uses. The file
is laid out in the MS Windows .ini format,
which is similar to other Linux configuration
formats, such as smb.conf. It looks like this:
[main]
Description=sample user profile
Host=10.7.44.1
AuthType=1
GroupName=monkeys
EnableISPConnect=0
ISPConnectType=0
ISPConnect=
ISPCommand=
Username=chimchim
SaveUserPassword=0
EnableBackup=0
BackupServer=
EnableNat=0
CertStore=0
CertName=
CertPath=
CertSubjectName=
CertSerialHash=0000000000000000000000
0000000000
DHGroup=2
ForceKeepAlives=0
The minimum configurations you’ll need in
your .pcf file are [main], Host, AuthType, Group-
Name, and Username. The [main] configuration
simply demarcates the main section of the
Administration 155
 configuration file. The Host option sets the IP
address (or URL) of the VPN server. The
AuthType configuration is set to either 1 (pre-
shared keys) or 3 (digital certificate that uses an
RSA signature). The GroupName is the name of
the IPSec group used on the VPN server. The
Username is the string that identifies the indi-
vidual user.
Other configuration options that can be
added are:
X UserPassword: This is the password used
for authentication.
X SaveUserPassword: A 0 means the pass-
word is displayed in clear text in the profile,
and a 1 means the password is encrypted
within the profile.
X EnableNAT: A 0 disables NAT, and a 1
enables NAT.
Once you’ve changed these configurations,
save the file and you’ll be ready to start up the
application.
Establishing a connection
Establishing a connection with Cisco’s vpnclient
is very simple. Let’s say you’re using the profile
named Mooch.pcf. To bring up a connection with
this profile, you’d run the command (as root):
vpnclient connect Mooch
Depending on your profile configuration, you
may be asked for the following:
X Group Password
X User Name
X User Password
X Domain
Eventually, your client will establish a con-
nection with the server, and your command
prompt will not come back to you.You can kill
this running connection in two ways. The first
method is to open another console, su to root,
and run this command:
vpnclient disconnect
The second method is to press [Ctrl]C. This
assumes the console window running the
command has focus. If that particular win-
dow does not have focus, put your cursor in
the window and click the left mouse button.
The client will disconnect from the server
with either of these methods.
156 Administrator’s Guide to VPN and Remote Access, Second Edition
Client statistics
The vpnclient application comes with a statis-
tics command that allows you to view infor-
mation about your connection. The
command syntax is:
vpnclient stat [reset] [traffic]
[tunnel] [route] [repeat]
The arguments offer the following information:
X reset: Restarts all connection counts from
zero
X traffic: Displays a summary of bytes
X tunnel: Displays IPSec information
X route: Displays configured routes
X repeat: Keeps a visible, continuously
refreshing display of various statistics,
including reset, traffic, tunnel, route, and
repeat
Hurdles
What would a network administrator’s job be
without hurdles? Actually, Cisco’s vpnclient
tool has only one small hurdle to get over.
When running any sort of security protocol,
such as ipchains or iptables, the vpnclient can
cause the Linux kernel to lock up tight. A
couple of situations cause this problem. The
first is when you have CONFIG_NETFIL-
TER enabled in your kernel. If you have
this enabled, you’ll have to recompile your
kernel and disable CONFIG_NETFILTER.
If you’re not sure whether CONFIG_NET-
FILTER is set, you can run the following
commands:
cd /usr/src/linux-2.4.2/arch/i386
grep CONFIG_NETFILTER defconfig
If you see this line:
# CONFIG_NETFILTER is not set
then you are good to go.
The second situation arises when you’re
running any sort of firewall on the client
machine. For stability’s sake, you’ll want to
shut down your firewall, flush both the input
and the output chains, change your input policy
to ACCEPT if it’s set to DENY, and then
start your connection.
To make this task quicker, I whipped up a
shell script that, when run as root, drops the
firewall, changes the input policy, and starts the
VPN connection. The script looks like this
(using the Mooch connection configuration):
#!/bin/sh
/sbin/ipchains -F
/sbin/ipchains -P input ACCEPT
vpnclient connect Mooch
I saved the file in the /etc/rc.d/ directory
with the name vpn_connect. To start the VPN
connection, I ran this command:
/etc/rc.d/vpn_connect
The connection started without locking up the
machine. Simple.
After your connection is made, you won’t
have to bring your firewall back up until the
session is over. This assumes that you trust
everyone on your VPN network. If you do
not trust everyone on your VPN network, use
caution when trying to start a firewall on the
host machine of the vpnclient application.
Notes
After gaining a secure connection to Tech-
Republic’s Cicso VPN server, I ran my
ip_chains_script, only to watch the machine
soundly lock up after the first few packets
passed through. The takeaway? Don’t worry
about your firewall while you’re using Cisco’s
vpnclient; it will only leave you rebooting your
machine over and over.
Conclusion
It’s about time Linux found itself with a simple-
to-use VPN solution. I’ve used this vpnclient to
connect to TechRepublic’s Cisco VPN server,
and it works like a charm. Other than the one
firewalling issue, it performs flawlessly. Kudos
to Cisco for finally offering a multi-platform
VPN solution that any mid-level computer
user can set up and run.
Administration 157
 Notes

158 Administrator’s Guide to VPN and Remote Access, Second Edition

Security
The articles in this chapter explain some of the issues you may encounter when configuring VPN
solutions to work within a network’s existing security infrastructure. You’ll learn to troubleshoot
problems that arise when configuring VPN servers to make connections through firewalls,
routers, and proxy servers.

Configuring VPN connections with firewalls ......................................................................................159

Securing the Edge: Windows 2000 Firewall/VPN and beyond: The firewall................................162
Securing the Edge: Windows 2000 Firewall/VPN and beyond: Tuning the security ..................164
Secure Shell: Protecting data in transit..................................................................................................165
Making the most of OpenSSH ..............................................................................................................170
Protect your VPN by keeping a tight rein on passwords ..................................................................173

Security
Configuring VPN connections with firewalls
Nov 8, 2000
By Jason Hiner, MCSE, CCNA
T
he process of setting up connections
or a virtual private network (VPN) has
been greatly enhanced and simplified
by software solutions for Windows NT/2000,
NetWare, and Linux/UNIX, as well as by
hardware solutions offered by vendors such as
Cisco and CheckPoint.
However, configuring VPN connections to
pass through firewalls, proxy servers, and
routers continues to bring many network
administrators to their knees in exasperation
and submission to the gods of the network
cloud. Thus, we are going to review how to
configure VPN servers to make connections in
concert with your stoic network defenders.
VPN server geography
One of the first decisions a network engineer
has to make when configuring a VPN server is
where to place it in relation to the network’s
firewall. As Figure A shows, there are essentially
three options for placing a VPN server.
The most common approach is to place the
VPN server behind the firewall, either on the
corporate LAN or as part of the network’s
“demilitarized zone” (DMZ) of servers con-
nected to the Internet.
Geography is extremely important when
configuring and troubleshooting VPN connec-
tions that pass through firewalls. It lets you
know which interfaces on the firewall will need
filters assigned to them to allow VPN traffic.
We’ll talk about filters at length in the next sec-
tion. The thing to understand about geography
and firewalls is that filtering occurs on the fire-
wall’s external interface—the interface that
connects to the Internet.
As I mentioned above, the most common
place for a VPN server is behind the firewall,
often in a DMZ with mail servers, Web
servers, database servers, and so on. The
advantage of this placement is that it fits
cleanly into the network’s current security
infrastructure. Also, the administrator is
already familiar with how to route traffic
through the firewall and only has to become
familiar with the ports needed by the VPN
server. However, the other two options have
benefits as well.
Placing a VPN server in front of the fire-
wall can lead to greater security in some cases.
Remember that a VPN allows users who are
external to the network to feel like they are sit-
ting on a machine inside the network. A hacker
who hijacks a connection to a VPN server that
is inside the firewall will be able to do some
serious damage. However, if you have a dedi-
cated VPN box that sits outside the firewall
and that is only capable of sending VPN traf-
fic through the firewall, you can limit the dam-
age a hacker can do by hacking the VPN box.
This option also allows you to limit the
resources authenticated VPN users can access
on the local network by filtering their traffic at
the firewall. However, one vulnerability with
this scenario is that the traffic between the fire-
wall and the VPN server is not encrypted.
The third option is to co-locate your VPN
server on the same box as your firewall. In this
Figure A
VPN Server in Front of the Firewall
VPN
Corporate VPN server client
LAN Firewall
VPN Server Co-Located with the Firewall
VPN
Corporate VPN server client
LAN and firewall
VPN Server Behind the Firewall
VPN
Corporate VPN server client
LAN Firewall
Security 159
 case, the VPN server is still logically behind the
firewall, but depending on its capability and uti-
lization, it can complement a firewall very well,
since both are essentially performing routing
functions. This works nicely, since in most
businesses, firewall/proxy services use more
resources during the daytime hours, and VPN
services use more resources during the
evenings. However, keep in mind that having
multiple services functioning on one box
always involves management and troubleshoot-
ing challenges.
Understanding firewall and
filter functionality
There are two types of filters and three types
of firewalls to be aware of when configuring
VPN connections. Filters come in two basic
flavors:
X Packet filtering
X Application filtering
A firewall can engage in packet filtering,
application filtering, or both. Filtering involves
accepting or denying TCP/IP traffic based on
source and destination addresses of packets,
TCP/UPD port utilization and other TCP/IP
headers information, and specific user and
computer details in advanced firewalls.
Packet filtering
A packet filtering firewall merely examines
traffic at the network layer (Layer 3 of the OSI
reference model) and accepts or rejects it
based mainly on source and destination
addresses. Although a packet filtering firewall
can do some blocking based on TCP and UDP
port numbers, in most cases, it isn’t the best
solution. However, packet filtering does pro-
vide speed, simplicity, and transparency.
Another important VPN troubleshooting tip
deals with network address translation. If the
Internet router or any router between the fire-
wall and the VPN server is providing NAT, it
will probably break the VPN tunnel and cause
your connection to fail. The VPN server should
have an Internet IP address on the external
interface and not an internal IP address assigned
by a DHCP server or hiding behind NAT. Most
of the time you will get this Internet IP address
from a subnet assigned to you by your ISP.
160 Administrator’s Guide to VPN and Remote Access, Second Edition
A packet filtering firewall is usually placed
on a router and is managed through basic
access control lists, which can be challenging
to configure and manage. Here’s a common
VPN problem to watch out for: Many admin-
istrators set up their VPN servers, configure
their firewalls, and discover that they still can’t
connect. They eventually realize that the ACL
on their Internet router is filtering the VPN
traffic and dropping the packets.
Application filtering
An application gateway firewall involves what
is commonly known as proxy services and
functions at the higher layers of the OSI refer-
ence model. This type of firewall offers more
extensive, customizable features, such as user-
level access control, time-of-day access con-
trol, and advanced auditing and logging.
It typically readdresses traffic so that it
looks like it’s coming from the firewall rather
than from the internal machine. In this man-
ner, these firewalls act as a “proxy” on behalf
of the internal network instead of providing a
direct connection between internal and exter-
nal networks, as you have with simple packet
filtering firewalls. It also focuses on managing
and controlling access to TCP/IP applications
such as FTP, HTTP, rlogin, and so on.
Packet filtering and application
filtering
Stateful inspection firewalls combine packet
filtering and application filtering. They also
employ a more secure firewall technique called
dynamic packet filtering. With regular packet
and application filtering, a port such as port
80 for HTTP is opened by the firewall and
remains open for incoming and outgoing traf-
fic. This presents a network vulnerability that
hackers can exploit.
However, stateful inspection firewalls open
and close ports as they are needed for traffic,
drastically decreasing vulnerability to external
attacks. Most popular firewalls, such as
Microsoft Proxy Server 2.0, Network Ice’s
ICEpac, and the leading UNIX solutions, use
dynamic packet filtering.
Allowing VPN traffic
Now that you can see how various firewalls
function, hopefully you can identify several
places on your network where your VPN con-
nection could be tripped up. Let’s see what fil-
ters you need to set up on these firewalls in
order for VPN traffic to pass through them. In
terms of protocols, we’ll cover VPN connec-
tions made using PPTP or L2TP over IPSec.
We will begin with VPN filters at Layer 3 of
the OSI reference model and work our way up
to Layer 7.
When we look at receiving VPN traffic at
Layer 3 we need to examine both the router
that provides Internet access and the VPN
server’s external interface. In some cases, the
VPN server may have an external interface
that connects directly to the Internet, such as
an ISDN adapter. The router and/or the
VPN external interface must be configured
to accept TCP/IP connections from the
VPN clients and/or VPN servers that will be
connecting to it from the Internet. Thus, the
access control lists (which manage filters at
Layer 3) must be configured to allow incom-
ing traffic from the IP addresses of these
clients and servers. For remote VPN servers
that are connecting, this will probably be a
real IP, which will be easy to configure. How-
ever, for remote clients who are probably
using a dial-up connection to an ISP and get-
ting a different IP address each time, this is
more challenging. If you have a restrictive IP
access policy in place, you can get the range
of IP addresses this client could use from his
or her ISP or figure it out by deduction after
a few connections. The other option is to
allow access to all IP addresses by default
and let upper-level filters accept or deny their
packets based on application criteria.
When we get to Layer 7 (the application
layer), we need to look at setting up filters to
allow PPTP or L2TP with IPSec traffic based
on the ports that they use. PPTP uses TCP
port 1723, as well as IP protocol ID 47 for
GRE (generic route encapsulation) tunnel
maintenance. For the most part, if you are
using a commercial firewall solution, you’ll
need to worry only about setting up the PPTP
filter for port 1723. But if you’re working with
more complex firewall systems and do-it-
yourself servers, such as Linux, you’ll need to
be aware of the GRE port. Microsoft solu-
tions such as Proxy Server 2.0 and the forth-
coming Internet Security and Acceleration
Server 2000 have predefined “PPTP receive”
and “PPTP call” filters. These generally work
pretty well.
Remember, you’ll need to be aware of the
geography of your VPN server in relation to
your firewall. For example, if your VPN server
is behind your firewall, which connects to the
Internet via a Cisco router, and you are receiv-
ing connections only from individual VPN
clients (and not from remote servers), you’ll set
up a firewall filter to accept incoming traffic on
port 1723 or simply select the predefined
“PPTP receive” with a Microsoft solution.
You’ll also need to go into the Cisco router and
make sure that there are no access control lists
filtering the VPN traffic.
As for L2TP with IPSec, the same princi-
ples apply, but it uses UDP port 1701 for
L2TP and UDP port 500 for IPSec’s IKE
(Internet key exchange). IPSec also uses IP
Protocol port 50 for ESP (encapsulation secu-
rity payload)—the equivalent of GRE for
PPTP—but it doesn’t require a filter because
the ESP header is typically removed by IPSec
during routing before it hits the firewall.
Conclusion
Hopefully, the principles we reviewed here will
enable you to better understand where your
VPN connection could be running into snags
in connecting through firewalls, proxy servers,
and routers. We didn’t try to provide a step-
by-step how-to on configuring firewalls and
filters because of the vast configuration dif-
ferences in the various hardware and software
platforms, as well as the myriad different net-
work typologies that are possible. However,
you should be able to locate information on
configuring filters and access control lists for
your specific hardware and software platforms
on the vendors’ Web sites. It also wouldn’t
hurt to offer a sacrificial NIC or 100baseT
cable to the networking gods before attempt-
ing your configuration.
Security 161
 Securing the Edge: Windows 2000
Firewall/VPN and beyond: The firewall
Jul 25, 2001
By Robert McIntire
W
hile companies continue to spend
money on higher speed Internet
connections, it’s only reasonable
that they should expect more for their budget
dollars. In an effort to stretch those dollars,
many companies are implementing VPNs for
remote access by employees. Also, they are
escalating the security on these connections
to ensure that only those who should have
access can actually gain access to their private
networks.
Although it may seem overly ambitious,
we’ll be tackling several different yet related
issues in this article. The overall topic envelops
a case study of a recent networking project in
which I was involved. The general idea was to
upgrade the client’s Internet security and pro-
vide for VPN remote access. Additionally, the
remote clients would then be connecting to a
terminal server inside the firewall on the LAN.
As if this weren’t enough, we also had to
address secure authentication schemes in a
rather custom fashion. We were fortunate to
find that Microsoft provided many of the fea-
tures and options that we required to complete
this project. You’ll see that, with a little ingenu-
ity and a bit of customization, you, too, can
secure your network.
Firewall upgrade process
In this first part, we’ll address the primary
piece in this puzzle: the firewall upgrade. For-
tunately, the client had decided to upgrade
from MS Proxy Server 2.0 to MS Internet
Security and Acceleration (ISA) Server 2000.
This fairly new product is actually a firewall/
cache server and is certified by ICSA. At the
time of this writing, you can download a time-
limited evaluation copy from the Microsoft
Web site (http://www.microsoft.com/
isaserver/evaluation/demonstration/). Now,
with the plugs out of the way, let’s turn our
attention to the installation considerations.
162 Administrator’s Guide to VPN and Remote Access, Second Edition
Since Internet connectivity had to be main-
tained throughout the process, we decided to
install a new server, rather than performing the
MS upgrade process on the previous Proxy
server. The LAN clients needing Internet
access would not be deterred during our
upgrade, as the old system would stay online
until the new system was installed and tested.
At that point, the LAN clients’ browsers would
simply need to be changed to point to the new
Proxy server. Fortunately, the client already
had a service network set up at the Internet
router with enough free public address space
to accommodate both gateways simultane-
ously. We installed two NICs in the new server,
one for the Internet connection and the other
for the internal LAN. Both NICs were stati-
cally addressed with appropriate addresses for
the respective networks.
When configuring the internal NIC, the
WINS and DNS info were provided, but the
default gateway was left blank. This is standard
operating procedure when configuring most
firewalls. Microsoft required that Service Pack
1 be installed prior to the ISA software. We
decided to apply Win2K Service Pack 2, as it
was the most current at the time. Then we
installed ISA. (You have the option of
installing just the firewall, just the caching
server, or integrated mode, which includes
both functions.) We chose to install it on a
member server so that we could utilize some
of the domain-based features to control con-
tent access. During the install, you’ll be asked
several questions. We went with the default
values, as most of them seemed appropriate
(and we could change them later, if necessary).
After completing the installation, we
checked for product updates on the Microsoft
ISA site. There was a security alert with a
patch, which we then applied. Although Win-
dows 2000 doesn’t seem to require a restart
after such operations, we recommend it after
installing the firewall software, as well as any
other OS patches. Essentially, the ISA install
did several things on our system. For one
thing, it installed and configured RRAS and
packet filters to allow only some basic ICMP
packets. Basically, it adheres to a deny-all
model (except for ICMP). The one oddity
about this is that the default, installed filters
seem to allow pings from internal clients to
pass through the firewall but do not allow a
response to outside sources attempting to ping
the external firewall interface. This may be a
bit of a problem when testing connectivity
with your ISP.
Configuring the firewall
After the initial installation was complete, it
was time to perform any custom configura-
tion for this site. We needed to allow traffic
appropriate to the client’s site (i.e., HTTP,
HTTPS, FTP, etc.). You’ll want to check the
routing tables on your server after the instal-
lation is complete to insure that no unex-
pected routes have been added. Locally
speaking, you’ll want to verify the LAT table,
especially if you allowed the install process to
generate the LAT. It’s automatically set up to
perform logging, so you’ll want to make sure
that enough disk space is available to do so.
You may also want to consider a separate
hard drive for logging.
The first thing we did to configure our fire-
wall was to create an opening for basic Web
and FTP traffic. To do so, we created a group
of users by internal IP address range. We then
created a rule allowing the aforementioned
traffic and associated our group with the rule.
Now that we have client access on the out-
bound, let’s look at how we can provide basic
inbound access. You can push e-mail through
ISA to your internal SMTP server and allow
external Internet clients access to internal Web
servers. In Microsoft terminology, this is
known as Publishing. Once you publish your
e-mail server, you’ll be able to receive e-mail
from the Internet. There are also packet filters
included that you can activate to funnel SMTP
and WWW traffic.
Testing the firewall
At this point, we wanted to ensure both con-
nectivity and security. We made sure that inter-
nal clients could ping Internet sites by address
and name. This ensures that NAT is working
correctly and that connectivity and name reso-
lution are functioning properly. After this, we
used a port scanner to check security at the
external interface. After scanning it, we felt
very good about the product, as it seemed to
be a black hole for TCP/IP packets. The only
thing that passed was specifically what we had
allowed.
Conclusion
The good thing about ISA Server 2000 is its
familiarity, as it seems quite similar to Proxy
Server 2.0. However, it is a true and tested fire-
wall platform, unlike Proxy Server. Unfortu-
nately, the ISA server appears to provide no
facility for printing a configuration report.
Microsoft does provide the ability to save the
configuration to a proprietary file type to use
in case a restoration of your ISA server is nec-
essary. All in all, the installation process is easy
and straightforward, and the default configura-
tion appears solid.
Security 163
 Securing the Edge: Windows 2000
Firewall/VPN and beyond: Tuning the security
Jul 30, 2001
By Robert McIntire
I
n the article “Securing the Edge: Windows
2000 Firewall/VPN and beyond: The fire-
wall” (page 162), we took an initial firewall
installation a step further and implemented a
client access VPN. We implemented authenti-
cation but, due to client requirements, we then
had to go above and beyond. The client’s con-
cerns about strong authentication led us
toward several potential solutions.
Extra strength authentication
One of the additional parameters designated
for securing the VPN was an extra level of
authentication. The client company wanted
not only the usual domain logon but also a
remote form of logon. We could have chosen
to use RADIUS (IAS, in Microsoft speak) to
authenticate users. In so doing, we could actu-
ally create the remote users in a local database
on the IAS server, rather than having the IAS
server refer to the domain database for user
verification. That would provide for the
remote logon, and then users would actually
log on to the domain during the second part of
the connection process—the terminal server
session.
Another option that was considered was to
perform the remote logon by having users log
on locally to the actual VPN server using a
specific remote access account. In so doing,
they would not be exposing the domain logon
process to prying eyes. At worst, exposure
would be limited to the VPN system. We
experimented with these and several other
combinations until we realized that we were
looking at things from the wrong angle. We
shelved these as secondary options because
they didn’t really give the client what they were
looking for.
It turns out that the reasoning behind the
extra level of authentication stemmed from an
underlying issue. The client was concerned
about users sharing passwords for remote
access. Now that the cat was out of the bag,
164 Administrator’s Guide to VPN and Remote Access, Second Edition
we began to move in the right direction. We
assisted the client in writing a security policy
that addressed the issue, but we all agreed that
the best manner in which to implement it was
at the system level. The bottom line was that
we had to authenticate the physical computers
gaining access to the VPN. After this initial
computer authentication process, the remote
PC would be connected to only the actual
VPN system. From here, they would need to
connect to the terminal server inside the
VPN/Firewall perimeter system. To do so, the
remote user would run the terminal client and
enter the IP address of the internal terminal
server. When connecting to this server, they
would then be confronted with the actual
domain logon. At this point, we had satisfied
the security constraints set by the client, at
least on paper. Now, how did we implement
this model?
Verifying the computer
The overriding concern when considering
how to verify the computer identity was
whether or not we wanted to deal with the
complexity of implementing MS Certificate
Services. This service is now provided with
Windows 2000. With it, you can generate your
own computer-based certificates for verifying
user and computer identity. To do so, we
would have to create our own root certificate
authority (CA) and then a subordinate CA.
Then the issue would arise about which
servers to install it on.
Since it’s a good idea to secure the root CA,
we decided to install it on a domain controller
well inside the network. Some experts recom-
mend taking the root CA offline so that there
is no chance of compromise, but we didn’t
have the luxury of an extra server. The subor-
dinate CA was installed on the Terminal
server. When deciding to use Certificate Ser-
vices, we had to determine how to use it in a
productive manner, yet provide only the features
we needed. With the myriad of features and
options available with MS Certificate Services,
this was no small task.
Eventually, we chose to install the CA as a
standalone. This configuration is used for gen-
erating certificates to external clients. And,
although the certificates were not external to
the company, we wanted to treat them as such
during the initial connection process. Then we
requested and issued certificates for each
remote client and the VPN server. Microsoft
provides a Web interface for CA servers that
allow other systems to request certificates by
simply connecting to the CA via a browser
using the http://ca_server_name/certsrv
URL. After installing the certificates, we next
had to modify the authentication method at
the VPN server. Extensible Authentication
Protocol (EAP) facilitates the use of certifi-
cates and thus had to be configured. On the
VPN system, we had to change the authentica-
tion method in the remote access policy that
was created by the VPN setup wizard. Under
the RRAS console, we simply edited the profile
to include EAP and then again in the local sys-
tem properties (within the Security tab). At
that point, we configured our test client to also
use EAP under the VPN connection icon’s
properties. Then came the moment of truth.
We tried to connect and were immediately
rejected. After double-checking the details
Secure Shell: Protecting data in transit
Mar 3, 2000
By Vincent Danen
I
f you’re a network or systems administra-
tor, one of your top considerations for any
computer should be security—whether it’s
local security or network security. Since Linux
is a networked operating system by design,
chances are that the computer is being used in
(and Q259880), we made a few adjustments
and successfully connected.
Conclusion
Keep in mind that this was not the only way to
fulfill the need for Internet access and security.
At each juncture in this overall process, we had
several options. One option was to use an
external CA like VeriSign. In this way, we
would have an internal CA, which would refer
to an external root CA provider for certificate
verification. Then again, we could have chosen
to use IAS for RADIUS authentication. But,
given the client’s specifications and preexisting
constraints, things turned out well as the proj-
ect evolved.
Looking back over the scope of the project,
I would make only a few recommendations.
Among these, I highly suggest supplementary
documentation, like the Windows 2000
Resource Kit. Unfortunately, the Microsoft
Web site is a little thin on specific information
regarding custom configurations like these.
And the Windows 2000 Help system does not
provide the depth needed to effectively com-
plete such a project. Last but not least, plan it
carefully. If you specify all of the needs and
requirements before you start the implementa-
tion phase, it’ll make the process much
smoother.
a network environment as a simple firewall or
as a server providing such services as HTTP,
FTP, and Telnet.
Why Secure Shell?
Often, it’s convenient to administer remotely,
and Linux supports remote administration.
Security 165
 With such programs as Telnet and rlogin, an
administrator staying at home can work on and
configure a remote Linux machine at the office
across the Internet. With more and more com-
panies choosing Linux as a server, as a compo-
nent of their Internet sites, or even as their
gateway to the Internet, remote administration
happens all the time.
Linux is very secure. With a little bit of
work and through the use of firewalls, IP mas-
querading, and TCP Wrappers (which prevent
unwanted guests from launching services), you
can make a computer that runs Linux virtually
invulnerable to any attacks across the Internet.
Unfortunately, the same cannot be said about
the Internet itself.
Most protocols transmit data in clear-text
format, which means that there is no encryp-
tion or “scrambling” of the network data.
Anyone who’s curious can “listen” to your net-
work traffic as it goes from point A (let’s say
the system administrator at home) to point C
(the server at work). Because of the nature of
the Internet, without a direct dial-in connec-
tion to your server, your network traffic will
probably be routed through point B (a host
out on the Internet) or even multiple point Bs.
It’s possible that you’ll have a few, or even a
few dozen, hops between your system and the
one you’re trying to reach. To find out how
many hops exist between you and any given
destination, give the program traceroute a try
(which is usually located in /usr/sbin). It will
tell you how many hops and how long of a
delay between hosts it will take to reach your
final destination.
Keep in mind that, if there are a dozen hops
to the machine you’re trying to reach, there are
also a dozen points of interception. Anyone
with a packet sniffer or other network-monitor-
ing tool can see and intercept your network
data. If this is the case, not only can they view
your network data, but they can maintain a
local copy of it, view it later, and possibly glean
passwords from it. If you think that you are
protected just because you require a password
for access, think again. Once this type of inter-
ception occurs and someone has obtained a
user password to your system, your entire sys-
166 Administrator’s Guide to VPN and Remote Access, Second Edition
tem could become compromised. As regular
users, they may not get very far, but once they
have access to your system, there are a number
of holes they may exploit, like programs that
have the suid or sgid bits set for other users (like
root). They may even make attempts to learn
the root password of the system. Once an
unwanted guest has access to your system, you
should view your entire system as compro-
mised. What if they installed a packet sniffer or
keyboard monitor on your system? The root
password could then be obtained quite easily.
But by then, it’s too late. You can plug the
hole and change the user’s password, but the
exposure has already occurred. Your system is
compromised. The best way to deal with this
situation is to prevent it from happening in the
first place. Clear transmission is fundamentally
a bad idea, and it should be avoided like the
plague. Conscientious system or network
administrators should avoid it even on local
networks. The Internet is not the only place
that harbors curious individuals.
Just what does Secure Shell do?
To guard against vulnerability and to protect
your day-to-day network data, I highly recom-
mend installing and using Secure Shell (SSH).
SSH is a client/server suite of programs that
encrypts data prior to sending it and that unen-
crypts data once it is received. Every packet in
transit, whether across a local LAN or from
point A to point C in the above illustration, is
encrypted and safe from packet sniffers and
other network monitors that may pose a secu-
rity risk to similar programs. SSH is a suitable
alternative for programs like Telnet, rlogin, rsh,
rcp, and rdist. SSH was designed to provide
strong authentication and secure communica-
tion over insecure networks (as noted in the
Secure Shell RFC).
Secure Shell supports a number of encryp-
tion algorithms, such as:
X BlowFish: A 64-bit encryption scheme
developed by Bruce Schneier
X Triple DES: The Data Encryption Stan-
dard, which was developed in 1974 by IBM
and is used by the U.S. government for
encrypting nonclassified data
X IDEA: The International Data Encryption
Algorithm, a powerful block-cipher
encryption algorithm that operates with a
128-bit key, which makes it far more secure
than Triple DES
X RSA: The Rivest-Shamir-Adelman algo-
rithm, a widely used public-key/private-key
cryptographic system
SSH’s multi-algorithm support is quite
extensive and user-definable. If you feel more
comfortable using IDEA than using RSA, you
can use IDEA quite easily without changing
how SSH works.
Besides providing encryption for network
data, SSH can also be used to protect against
IP Spoofing, which occurs when a remote host
sends out packets that pretend to come from
another (trusted) host. It can protect against IP
Source Routing, which involves a host pre-
tending that an IP packet comes from another
(trusted) host. It protects against DNS Spoof-
ing (when an attacker forges name server
records). It prevents manipulation of data by
people in control of intermediate systems (the
hosts through which IP packets “hop”). And
finally, it can also protect against attacks based
on listening to X authentication data and
spoofed connections to an X11 server.
Despite all of this functionality, using SSH
for remote connections does not require an
enormous learning curve. Using it is quite sim-
ilar to using simple Telnet. Authentication and
session encryption are completely transparent,
and there is no apparent slowdown of infor-
mation in transit beyond perhaps the seconds
when the session authenticates.
How does it work?
SSH is a suite of programs designed to secure
connections between two computers, one as
client and one as server. To accomplish this
task, it comes with a number of programs,
including the client program, ssh. The client
program is very much like a Telnet client in
every respect, and it allows you to perform any
console-based commands on the server. The
server itself, sshd, listens on TCP Port 22, and
when it receives a connection request from a
valid SSH client, it starts a new session. There
is also a copy program called scp. Secure Copy
provides a secure means to copy files from one
machine to another, much like the rcp program.
Since SSH is based on keys to authenticate
between client and server, it includes some key
management programs like ssh-add, which will
register new keys for the ssh-agent program.
This program is used to perform RSA-style
authentication over networks when you’re
using SSH. In other words, it allows remote
hosts to access and store your RSA private key.
Finally there is ssh-keygen, which is the key gen-
erator for SSH. It generates an RSA key that is
used by sshagent to authenticate both locally
and remotely.
As you can see, SSH can offer a complete
replacement for insecure programs like Telnet
and rlogin. In its most basic form, SSH pro-
vides a method to secure remote logins and in-
transit data and provides a way to protect files
and documents transmitted from one machine
to another. SSH is, however, quite versatile and
can be used for more than that task alone. SSH
can be used as an effective “tunneling” mecha-
nism and can secure far more than just remote
logins and file transfers. The only catch is that,
because SSH is client/server-based, both the
remote host and the local machine must use
SSH. SSH for Linux is a freely available pro-
gram. You can obtain the binary programs
from ZEDZ (ftp://ftp.zedz.net/pub/crypto/
redhat/i386) or the source code itself from
the SSH site (http://www.ssh.com/).
The benefits to compiling your own version
of SSH are the various options that you can
set during compilation and that you can cus-
tomize to secure your network further. A num-
ber of the compilation options can be set in
the configuration files if you choose to go with
a binary distribution.
An important configuration option that can
be specified only at compilation is whether or
not SSH will use TCP Wrappers. There are two
different schools of thought on this issue, but
it boils down to how your system is configured
and how you want to customize things. SSH
can be independent from the rest of your sys-
tem in terms of which hosts are allowed to
connect, or it can use TCP Wrapper support,
Security 167
 which enables SSH to allow and disallow con-
nections based on the hosts defined in
/etc/hosts.allow (specified authorized hosts)
and /etc/hosts.deny (specified unauthorized
hosts). TCP Wrappers is an excellent security
tool that works similarly to a firewall. The two
configuration files are used to select services
and to authorize or “unauthorize” specific
hosts or domains from using those services.
SSH can use this tool, or it can use its own
form of allow/deny authorization (when com-
piled without TCP Wrappers support).
What are the specifics?
Once you’ve decided which method you’re
going to use (source or binary) and you have
installed SSH, the suite of programs will
become available to you. To any systems
administrator, I recommend disabling all run-
ning Telnet servers completely. This disabling
can be done by commenting out the Telnet
field in /etc/inetd.conf so that the Inetd
super-daemon will never open a Telnet session
when an incoming request on TCP Port 23 is
received. By the same token, you should also
disable the rlogin and rsh suite of programs
(rshd, rlogind, rexecd, and rexd). The system will
not be secure until all of these programs are
disabled or, preferably, removed completely.
You can then decide whether sshd will be a
persistent service (started on its own and con-
tinually running) or whether Inetd will start it
upon request. If you want Inetd to start the
SSH daemon when required, add the following
to your /etc/inetd.conf (if you have TCP
Wrapper support enabled):
ssh stream tcp nowait root
/usr/sbin/tcpd sshd -i
or if you have TCP Wrapper support disabled:
ssh stream tcp nowait root
/usr/bin/sshd sshd -i
There is little real benefit to running sshd
from Inetd. The SSH daemon does not take
much memory or CPU when idle, so there is
no need to worry about wasted resources if it
is not used very often. The side effect to using
Inetd, however, is that SSH must generate a
server key prior to responding to the client,
and this action can take a few seconds because
168 Administrator’s Guide to VPN and Remote Access, Second Edition
it has to generate the key immediately before it
can authenticate a session. Consequently, the
session initiation will take a few seconds longer
than necessary. Normally, sshd keeps a gener-
ated RSA key in memory so that it can
respond to client requests immediately. The
RSA key is usually re-generated hourly (which
can be changed in the configuration), and it is
never written to the disk—so as to preserve
the key’s integrity. Because of this added
security, running the daemon stand-alone is
recommended.
There are a number of other options that
can be used by the SSH daemon on the com-
mand line. These options include the number
of bits to use in the server key (by default, it’s
768 bits), how often sshd regenerates the server
key (by default, it’s once an hour), alternate
ports to listen to (by default, it’s TCP Port 22),
and more. The configuration file for the dae-
mon, /etc/sshd_config, permits more options
to control how the daemon operates.
The SSH client program, ssh, also has a
number of command-line options, as well as
its own configuration file, /etc/ssh_config.
Some of the options on the command line
allow you to select which cipher (encryption
method) to use, which user to log in as (if not
the current user), and so forth. It will connect
to the remote SSH server and initiate an inter-
active Telnet-like session. In fact, it is so trans-
parent that, beyond the login, you will think
that you’re sitting in front of the server itself.
The Secure Copy program should be used
whenever you need to transfer one file to
another. It is not an interactive copying pro-
gram, like FTP, but it’s very similar to the cp
program that’s used locally. It allows you to
select which cipher you want to use on the
command line, but it uses a unique syntax to
copy files. The syntax is:
scp user@host1:[/path/filename]
user@host2:[/path/filename]
or it can be abbreviated to
scp [/path/filename]
user@host2:[/path/filename]
SSH can also be used as a tunneling pro-
gram to create rough Virtual Private Networks
or to allow remote users to access a remote
X11 server securely. Beyond that, however, the
uses for SSH are virtually endless because of
its built-in tunneling and forwarding capabili-
ties. It can be used to provide secure RPC ses-
sions, which are useful in securing NIS
services. It can be used to run encrypted PPP
sessions on top of a standard SSH session. It
can also be used to communicate with outside
entities from behind a firewall, because of its
TCP forwarding options. It can be used to
provide encrypted access to POP3 servers so
that, by tunneling it via SSH, you can securely
download e-mail that would otherwise be
transferred in clear-text (unless the server sup-
ports APOP or a similarly encrypted POP3
protocol and only if your client program sup-
ports the same protocols).
To Linux and beyond
For the Linux user, Secure Shell is an excellent
suite of programs. Unfortunately, in the real
world, not everyone uses Linux. So, does this
fact limit SSH’s usefulness at all? Definitely
not! Within a heterogeneous network, or even
for the administrator who uses Linux as a
server at work and runs Windows at home,
there are SSH clients for other platforms, as
well. You can obtain various commercial SSH
client implementations (called F-Secure SSH)
for Windows and Macintosh systems from
DataFellows (http://www.datafellows.com/).
However, commercial alternatives have an
associated cost. If you want free alternatives,
you can take a look at some of the programs
listed below.
For Windows, Tera Term Pro (http://hp.
vector.co.jp/authors/VA002416/teraterm.
html) is useful. It is a popular Telnet client for
Windows, but it doesn’t come with SSH sup-
port natively. Robert O’Callahan, however,
wrote an excellent SSH extension for Tera
Term Pro that makes the Telnet client fully
SSH-compliant. TTSSH (the SSH extension)
can be obtained from the TTSSH home site
(http://www.zip.com.au/~roca/ttssh.html).
There are also two ports of SSH (command
line) to Windows from the SSH site (http://
www.ssh.com/) and from Gordon Chaffee
(http://bmrc.berkeley.edu/people/chaffee/s
hnt). There is yet another SSH client for Win-
dows in the works, and it’s called Free FiSSH.
It is not currently available to the public but
should be soon. You can find more informa-
tion on the official FiSSH site (http://pgpdist.
mit.edu/FiSSH/index.html).
For Macintosh, there is NiftyTelnet, which
supports SSH natively and can be obtained
from Jonas Walldén (http://www.lysator.
liu.se/~jonasw/freeware/niftyssh/).
For those who use Java, there is also a Java-
based SSH client called MindTerm that can
run stand-alone or within a Web browser. It
would be useful for operating systems that
come without a direct version of SSH but that
use Java.
It should be apparent that SSH is not only a
useful solution to many security issues, but
almost a necessary one. SSH has been quite
popular for many UNIX and Linux system
administrators for years, and the ever-increasing
number of clients for other operating systems
proves that the usefulness of SSH is not lim-
ited to UNIX and Linux alone. Unfortunately,
there are no free servers for many operating
systems, so anyone who plans on using SSH
needs to do so with a UNIX or Linux server.
That is yet another reason for using a stable
and free platform, like Linux, in a networking
environment.
Security 169
 Making the most of OpenSSH
Mar 7, 2001
By Vincent Danen
I
f you run Linux in a networked environ-
ment and don’t yet know what OpenSSH
is, you have no idea what you’re missing. If
you use telnet and still don’t know what
OpenSSH is, then you are in dire need of a lit-
tle education. OpenSSH is an open source and
free implementation of the SSH (Secure Shell)
protocol. With it, you can connect to comput-
ers across a network or the Internet in a com-
pletely secure fashion, with everything from
passwords to the text you type encrypted. If
you’ve been using telnet and have never given
OpenSSH a try, you need to stop right now
and try it.
This article, however, is not about how to
install OpenSSH, or even about the basic uses
of OpenSSH. While in its most basic form
OpenSSH can be used for secure remote logins
and secure copying of files to and from remote
computers, there is far more that OpenSSH can
do. In this article, we will explore some of the
more advanced features of OpenSSH and dis-
cover how to make using it simpler and more
powerful.
Key-based authentication
Typically, when you connect to a remote site,
you need to supply a password. This is true for
remote logins and for copying files securely.
The password is required to authenticate you
so that the remote system knows that you are
who you say you are, and that you have appro-
priate access to the system.
OpenSSH also uses a key-based method of
authentication, which means that you can
make use of password-less connections to the
remote machine. If you connect to a remote
system often, this may be the best method for
you to make use of, because it offers the bene-
fit of fewer keystrokes and is just as secure as
using password authentication, especially if
you use strange and convoluted passwords
(which you should). Using this method, you
have to enter your password only once, at the
beginning of your session.
170 Administrator’s Guide to VPN and Remote Access, Second Edition
The first step is to create your private and
public keys. To do this, simply run the command:
ssh-keygen
This will work for any OpenSSH or SSH 1.x
server. If the remote server uses SSH 2.x, you
will want to run this command instead:
ssh-keygen -d
Because SSH 2.x uses a different algorithm,
it will create a DSA key instead. If you connect
to various servers, some using OpenSSH and
others using SSH 2.x, you can run both com-
mands. Since both keys are saved in different
files, they can peacefully coexist. SSH 1.x and
2.x are both commercial implementations of
SSH and are not free, unlike OpenSSH itself.
Once you have completed this command,
you will have a file called /home/user/.ssh/
identity and another called /home/user/.ssh/
identity.pub. The first is your private key, and the
second is your public key. If you use the -d
option, these files will be /home/user/.ssh/
id_dsa and /home/user/.ssh/id_dsa.pub.
Now that you have your keypair generated,
you need to secure your private key. (If your
private key ever becomes compromised, you
will have to recreate your private key, so take
pains to ensure it does not become so.) The
easiest way is to change the permissions of the
file so they are readable and writable only by
you and no one else. Run the following com-
mand to change the permissions:
chmod 600 ~/.ssh/identity
This will make sure that only the user who
created the keypair has access to the file. The
next step is to distribute your public key to the
servers you will be connecting to via SSH. This
is easily done since you should already have
access to the remote system. Simply copy your
new ~/.ssh/identity.pub to the remote system and
place it into the ~/.ssh directory on the remote
system. For instance, if your user name is joe,
but on the remote system it is joedoe, you will
have to copy /home/joe/.ssh/identity.pub on the
local system to /home/joedoe/.ssh/authorized_keys
on the remote system. Once you have done
this, you must make the authorized_keys file
world-readable and writable only by you by
doing:
chmod 644 ~/.ssh/authorized_keys
on the remote machine. Now, the
authorized_keys file can hold more than one
public key. If you connect to the remote
machine by multiple computers, you can
include the public key for each user on those
computers in the remote authorized_keys file
by inserting the contents of the local ~/.ssh/
identity.pub file into it.
Once this is completed, you are almost
ready to begin. The next step is to make use of
the ssh-add and ssh-agent programs. These
programs will allow you to store your key in
memory once you have entered the passphrase
that ssh-keygen prompted you for. If you did
not enter a password when you generated your
keypair, you will still need to run these pro-
grams; you simply won’t be asked for a pass-
word. The first thing you will need to do is run
the ssh-agent program using the shell’s eval
command. The ssh-agent program is an
authentication agent that will run in the back-
ground and seamlessly handle requests to con-
nect to remote sites. Run the following
command:
eval $(ssh-agent)
You will then see a message that displays
the ssh-agent’s PID number. Once that has
been printed to the screen, run the ssh-add
program:
ssh-add
This program must be run in the exact same
terminal that you ran ssh-agent in. It will load
the key into memory and ask you for your
password. Now you will be able to start SSH
sessions from that terminal alone without ever
having to enter your password again (until you
close or log off the terminal, of course).
If you want to have this capability in all ter-
minals you open, you will need to add the eval
command to your X startup files: ~/.xinitrc if
you start X from the console, or ~/.xsession if
you boot directly into X. Then you can run
ssh-add from any terminal, and any future ter-
minals you open during that login will be like-
wise authenticated. If you want to list the
key(s) that are currently stored in memory, you
can do so using:
ssh-add -l
and you can also remove an identity from the
system memory by using:
ssh-add -d
Port forwarding
OpenSSH also provides a method to tunnel
protocols securely using port forwarding. What
this means is that you can create a secure con-
nection to a remote computer and transfer
files, mail, or any other TCP/IP service
through the SSH connection by connecting to
a local port which travels through the SSH
“tunnel.” At the remote end, they will connect
from the secure SSH port to the unencrypted
(normal) port, and all data will be encrypted.
This entire operation is seamless for your
client connections. Of course, the remote
server must also run SSH in order for this to
work. You can easily determine whether the
remote system runs SSH either by trying to use
the SSH client to connect to it or by telneting
to the standard SSH port (22) on the remote
machine. If the connection is permitted, the
remote server runs SSH. If it is denied, the
remote server does not run SSH, and you will
not be able to connect to it securely.
The syntax for port forwarding is as fol-
lows, and it may seem a little complicated at
first glance:
ssh -f [user@remote] -L
[localport]:
[fqdn-of-remote]:[remoteport]
[command]
Let’s take a look at a commonly used exam-
ple. Many people use SSH tunneling to
retrieve their POP3 mail from their ISP or
other system. By using SSH tunneling for this,
you prevent people from sniffing your POP3
password, and you also prevent anyone from
sniffing the contents of your e-mail. OpenSSH
also provides an option to compress data,
which may help you get your mail faster. To use
compression, use the -c command-line option.
Let’s assume for a moment that your POP3
username is joe and that your POP3 account is
Security 171
 located at mail.somehost.com. To establish the
tunnel, use the following command:
ssh -f -c joe@mail.somehost.com -L
1110:mail.somehost.com:110 sleep 10
This command will start the port forward com-
mand with compression enabled. Our login on
the remote machine, mail.somehost.com, is
joe, so we provide that as the username and
the fully qualified domain name for the remote
host name on the command line. We then cre-
ate a tunnel from port 1110 on the localhost to
port 110 (the POP3 port) on the remote host.
We then run the command sleep 10 to keep the
connection alive long enough for the mail
client to connect to the remote server. You can
basically put anything here that produces some
activity, such as using tail on a log file, so that
some data keeps the connection alive.
Once you execute the command, you will be
prompted for your password on the remote
system. Once you’ve done this, you can then
point your mail client to port 1110 on the
localhost to retrieve your e-mail. To take the
example further, let’s take a quick look at the
fetchmail program and see how you would
have to configure fetchmail to make use of
this SSH tunnel.
If you use fetchmail, you will be aware of
the ~/.fetchmailrc configuration file that it uses.
Expanding upon the example above, let’s look
at a sample ~/.fetchmailrc file:
poll localhost with protocol pop3 and
port 1110:
preconnect "ssh -f -c
joe@mail.somehost.com -L
1110:mail.somehost.com:110 sleep 10"
password private;
And that’s it! What this does is tell fetchmail
to connect to port 1110 on the local system.
The preconnect command tells fetchmail to exe-
cute the command in quotes prior to making
the POP3 connection to download mail. The
last line provides the password for the POP3
account.
To take this one step further, combine
this with the ssh-agent and ssh-add commands
we looked at previously, and you will need
to enter your password only once. Or you
can use a BASH script similar to this, which
172 Administrator’s Guide to VPN and Remote Access, Second Edition
will run fetchmail every five minutes to
download mail:
#!/bin/sh
ssh-add
while true; do fetchmail —syslog
—invisible; sleep 5m; done
Then you can run the following command
when you log in to your system:
ssh-agent ~/bin/getmail
if you saved the above script as the executable
file ~/bin/getmail.
Now let’s take a look at another use for SSH
tunneling. Suppose you wanted to run X appli-
cations from a remote server and have them
displayed on your local computer. This is easily
done with OpenSSH as well and provides a
secure way to use remote applications. The
first step is to log in to the remote machine
and create a file called ~/.ssh/environment,
which contains the following line:
XAUTHORITY=/home/user/.Xauthority
The /home/user directory is, of course, the
home directory of the remote user. Once you
have done this, close the session and then start
another session using:
ssh -f -x -l [user] [remote host]
xterm
This will open up an xterm from the
remote machine onto your local computer.
You can do this with any application you like,
such as Netscape, xchat, or an administrative
program. As long as you have permission to
execute the program, you will be able to run it
in this manner.
Further configuration options
You can also configure OpenSSH to make it
easier and more convenient for you to use.
There are three ways that you can pass options
to OpenSSH, and they are, in order of priority:
command line, user configuration, and system-
wide configuration. By default, you will not
have a user configuration file, so you may want
to copy /etc/ssh/ssh_config to ~/.ssh/ssh_config.
To change system-wide configuration options,
simply edit the /etc/ssh/ssh_config file.
The configuration file is read from top to
bottom. It uses matching, so the first configu-
ration option that matches the situation is the
one that will be used. Because of this, your
specifics should be listed first and the more
general options specified last.
Let’s look at a quick example: Assume that
you have an account on somehost.com as the
user joe. You’re using the one-time password
authentication method discussed previously,
and you want to simply type sh instead of some-
host.com whenever you connect to the remote
machine. You also want to be able to use X11
forwarding to run remote applications on your
local machine. However, you still want to keep
the paranoid settings for every other host,
which are the default in the configuration file.
You might edit your ~/.ssh/ssh_config file to
look like this:
Host *sh
HostName somehost.com
User joe
ForwardAgent yes
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
Now all you need to do is type:
ssh sh
instead of:
ssh joe@somehost.com
to connect to the remote machine. OpenSSH
will look up the host name in the configuration
Protect your VPN by keeping a tight
rein on passwords
May 22, 2002
By Dana Norton
J oe Edwards knows what damage one per-
son can do to an organization by misusing a
virtual private network (VPN) password.
An employee at Edwards’ former workplace
was fired under questionable circumstances.
The employee went home, dialed into the
file, use your user name to log in, and authenti-
cate using your key. Simple, isn’t it? Connec-
tions to all other machines will continue to use
the default paranoid settings, which will pro-
tect you from untrusted hosts.
Conclusion
There are a number of shortcuts you can take
with OpenSSH without reducing security.
Using key-based authentication is a simple, yet
secure, means of making life a little easier.
Creating secure tunnels with SSH also has
many advantages. You can use tunneling for
anything from POP3 to SMTP, and even use it
for FTP and HTTP connections. Creating a
tunnel for FTP is unnecessary, however, as
you can use scp (secure copy) to transfer files
or use sftp, a secure FTP client and its associ-
ated secure FTP server, to make use of SSH-
enabled FTP.
With all the obvious advantages of using
OpenSSH, using other insecure options should
be considered a thing of the past. OpenSSH is
more than a simple secure shell. It can be used
to secure many aspects of your system and
generally make life easier and let network
administrators breathe easier. And since
OpenSSH is completely free, there is no rea-
son why it should not be used.
employer’s VPN, and deleted all of his docu-
ments off the network.
“So as a result, we basically had a situation
where we couldn’t get his current data that he
had done for the day,” said Edwards, now a
senior network administrator for eLink
Security 173
 Communications, Inc., an Internet serv-
ice provider (ISP) in Bethesda, MD
(http://www.elinkcommunications.com/).
Edwards also saw how an employee who dis-
liked another fired employee accessed a VPN
using the terminated employee’s password and
sent hateful e-mails to supervisors in the organ-
ization under the fired employee’s name.
These examples demonstrate why IT man-
agers must control VPN password use in their
organization and delete passwords when they
are no longer needed.
VPN use and risk increase
Passwords are necessary for secure access to a
VPN. They’re also one of the only ways an
organization can protect its VPN. “Passwords
really are the only line of defense today
between an intruder and your data,” said Tom
Rose, the vice president of marketing for
Courion, a provider of self-service identity
management solutions, in Framingham, MA
(http://www.courion.com/).
The need for secure passwords is increasing
simply because VPN use is rising. John Doyle,
the director of product marketing for Corpo-
rate Edge Services for Nortel Networks
(http://www.nortelnetworks.com/), said that
Nortel Networks sells VPN services to all types
of companies, government entities, and carrier
partners that offer managed VPN services.
This overall growth means that VPNs are
more important to an organization’s productiv-
ity. “There are two principle applications for
VPNs,” said Doyle. “One is remote access.
That would be the stuff that you’re doing
when you dial in from home. And then there’s
the branch-to-branch stuff. That would
describe most companies,” he said. He added
that users in an organization’s branch offices
need network access from anywhere, at any
time, and that VPNs meet this need.
Keep your organization safe
Protecting your network is one reason each user
in your organization needs a VPN password
and also the reason IT managers need to focus
on managing passwords to prevent abuse.
If the idea of turning over one password to
each user makes you shake in your boots, it
should. “With a VPN, you can access through
174 Administrator’s Guide to VPN and Remote Access, Second Edition
anybody’s ISP on basically anyone’s network,”
said Edwards. “So if an employee leaves, he
could very well go home and either still get
sensitive information off the network or still
send out e-mails basically using your com-
pany’s service for his own good,” he said.
In the wrong hands, a single VPN password
can open up an entire network to a malicious
user or hacker. “VPN passwords are the keys to
the kingdom,” said Marty Roesch, the president
and founder of Sourcefire, Inc., a provider of
network monitoring infrastructure solutions in
Columbia, MD (http://www.sourcefire.com/).
Staying on top of password use is the easi-
est way managers can protect VPNs. “You use
a VPN to secure your point-to-point commu-
nications, so if it’s secured via passwords and
you don’t have good password control mecha-
nisms, then you run the risk of a password get-
ting out,” said Roesch.
How to manage IT passwords
“For example, the problem scenarios I men-
tioned could have been avoided if the organi-
zation’s human resources department had told
the IT team when an employee was to be
fired,” said Edwards. “A bad thing to do is to
fire someone in the evening and not let us
know,” he said.
IT managers should establish a system to
track passwords to know when certain pass-
words are no longer needed. For example,
when an employee leaves the organization, you
should uninstall those passwords immediately.
Here are other password management tips:
X “Refresh passwords at least every 60 days,”
said Rose. “Obviously the more frequently
you refresh your passwords, the more diffi-
cult it becomes for a hacker to compromise
a password or obtain one,” he said.
X Explain to users why they must be careful
with VPNs. Tell them that it is impossible
to deploy security software to users outside
of an organization’s network and that they
cannot trust external computing platforms.
X Encourage users to use other forms of pro-
tection at home. For example, establish a
policy that states that users must use fire-
walls and other protection solutions that are
approved by the organization.
X Force users to create strong passwords.
Managers should especially encourage a
user with “12345” as a password, for exam-
ple, to change it for security reasons. Longer
passwords that are a mix of letters, num-
bers, and symbols are stronger than one-
word or number-string passwords.
X You can use an automatic solution. For
example, Courion makes and distributes
PasswordCourier (http://www.courion.
com/products/pwc/index.asp?Node=
PWC), an application that enables managers
to securely reset forgotten passwords or
Notes
automatically delete expired ones. The
application can also tie all of a user’s pass-
words together into one central location
where they can be changed or updated auto-
matically.
If you do not use an automatic system,
search your network for weak passwords. For
example, Edwards checks each password in his
organization twice a month. “That way if
someone’s using a password of, say, 123, which
is pretty common, we can actually make those
people change the password and force the
password length,” he said.
Security 175
 Notes

176 Administrator’s Guide to VPN and Remote Access, Second Edition

Protocols
When it comes to administering a VPN, you have to know your protocols. This chapter contains
the material you need to troubleshoot TCP/IP, PPTP, L2TP, and IPSec connections.

TechRepublic’s TCP/IP primer..............................................................................................................177

Troubleshoot your network errors with TechRepublic’s TCP/IP checklist ..................................180
Troubleshoot Novell TCP/IP network errors with TechRepublic’s checklist ..............................183
Putting the “private” in virtual private networking ............................................................................186
Configuring certificates for an L2TP/IPSec VPN ............................................................................191
Customize the security of L2TP/IPSec connections ........................................................................196
Troubleshooting L2TP/IPSec VPN connections in Win2K ............................................................199
The Windows NT 4.0 PPTP VPN client connection guide ............................................................202

Protocols
TechRepublic’s TCP/IP primer
Sep 1, 2000
By Jason Pachomski
W What is TCP/IP made of?
ith the explosion in the popularity
of the Internet, nearly all comput-
ers are connected to one another in
some fashion. From the mission-critical data-
base server in a large corporation to the old
clunker in your basement that the kids play
games on, the concept of a “stand-alone” PC
is quickly becoming obsolete. As IT profes-
sionals, we need to understand and implement
the functionality that fuels this technology. So
how does it all work? How is it that one com-
puter can “talk” to another no matter where
that computer is?
Simply put, networking drives the Internet.
Networking and computer networks are not
new concepts. The first indications of where
they would take us began to surface in the late
1960s with the U.S. Department of Defense.
It needed a way for employees and associated
institutions around the world to be able to
communicate large amounts of data quickly
and securely, so it contracted with a small com-
pany to develop the technology to accomplish
this. The result of this assignment has become
the most popular means for two computers to
communicate with each other. That technol-
ogy is called TCP/IP.
TCP/IP defined
What is TCP/IP and how does it work? TCP/
IP is defined as an industry standard suite of
protocols that computers use to find, access,
and communicate with each other over a trans-
mission medium. A protocol is a set of stan-
dards and rules that need to be followed. In
the case of networking computers, a protocol
is the set of standards and rules that a
machine’s hardware and software must follow
in order to be recognized and understood by
other computers. The protocol suite is imple-
mented via a software package most com-
monly known as the TCP/IP stack. This
functionality ships with all versions of Win-
dows from 95 and up and can be easily
installed using the network setup applets in the
Control Panel.
Under the hood, TCP/IP’s architecture con-
sists of several “layers” performing certain
functions. Each layer contains protocols. There
are four general layers of the TCP/IP stack:
1. Application layer
2. Transport layer
3. Internet layer
4. Physical or Network Interface layer
A full-scale description of each layer and its
underlying functionality is well beyond the
scope of this article. Whole courses are taught
on TCP/IP alone. However, here’s a brief
overview of the part each layer plays and how
they work together.
When you transmit over the Internet, you
are using your computer’s implementation of
TCP/IP. The data you send follows a certain
path and is transmitted in a specific way so that
when it arrives at its final destination, it can be
read, understood, and used by the receiving
machine without any problems. Common prac-
tices and functionality are the basis for which
all standards are produced, and TCP/IP is no
different. Let’s follow the path that a portion of
data, or a packet as it is commonly called, takes
when it travels the TCP/IP highway.
Application layer
The data you want to send starts off at the top
of the TCP/IP stack in the Application layer.
This layer contains network applications and
services that the user interfaces with in order to
use network communication. Also living in the
Application layer are utilities for things like file
and print services and name resolution. A good
example of this is NetBIOS, an application
programming interface (API) that supports a
desktop operating environment. Finally, all the
utilities that work with TCP/IP live in the
Application layer. These utilities provide the
user with connectivity, file transfer capabilities,
utilities for remote administration, and Internet
utilities. Examples of these include programs
like PING, TRACERT, FTP, and Telnet.
Protocols 177
 Transport layer
Once the Application layer is through with the
data, it passes the data down the line to the
Transport layer. The two major components of
the Transport layer are the Transfer Control
Protocol (TCP) and the User Datagram Proto-
col (UDP). Entire books are available on TCP,
UDP, and the Transport layer, but simply put,
the Transport layer is an interface that applica-
tions use for network connectivity. The design-
ers of TCP/IP wanted to make sure that the
data you send gets received by the right
machine, as well as the right application run-
ning on that machine. The Transport layer
provides this functionality. In the Transport
layer, there are mechanisms for error checking,
flow control, and verification ensuring the
integrity and completeness of the data it is
working with.
Although TCP and UDP are the main work-
horses of this layer, there is one very important
difference between the two. TCP is considered
a connection-oriented protocol, while UDP
is considered a connectionless protocol. A
connection-oriented protocol is one that estab-
lishes a connection with another machine and
maintains that connection for the entire dura-
tion of data transmission. A slew of functions
are built into TCP that check and recheck the
data while the two machines are connected.
This makes TCP a more reliable, albeit slower,
transmission. A connectionless protocol such
as UDP, however, does not establish a connec-
tion with the target machine at all. UDP is told
by the Application layer which machine it is
supposed to transmit to, with no questions
asked. This obviously makes UDP a much
faster protocol when it comes to data transmis-
sion. But UDP has rudimentary error checking
and flow control, as well as reliability issues.
That is why TCP is the most widely used pro-
tocol in Internet communications.
Internet layer
Beneath the Transport layer is the Internet
layer. Three key protocols reside in the Inter-
net layer: Internet Protocol (IP), Address Res-
olution Protocol (ARP), and Internet Control
Message Protocol (ICMP). Each of these
serves a specific purpose. There are also two
less-used protocols, Reverse Address Resolu-
tion Protocol (RARP) and Internet Group
Management Protocol (IGMP).
IP addressing and address resolution
occur within the Internet layer. IP addressing
is a scheme that standardizes how machines
are identified and differentiated from one
another. This scheme allows any computer
running TCP/IP to communicate with other
computers running TCP/IP anywhere in the
world. No matter what type of machine,
operating system, or network topology the
PCs live on, as long as both machines are
using TCP/IP, they’re speaking the same
language.
ARP’s job is to resolve a logical IP address,
such as www.mywebsite.com, into its physical
equivalent address. ICMP is mostly used by
routers to send information back to a source
computer about a transmission that computer
is trying to make. When you use the PING
utility, the information you receive was gath-
ered using ICMP.

Table A: Terms defined

API A message and language format that allows programmers to use functions within another program
NetBIOS A protocol that provides the underlying communication mechanism for some basic NT functions,
such as browsing and communication between network servers
PING A command used to verify the existence of and connection to remote hosts over a network
TRACERT A diagnostic utility that determines the route a packet has taken to a destination
FTP A protocol for transferring files to and from a local hard drive to an FTP server located on another
TCP/IP-based network
Telnet A remote terminal emulation application that has its own protocol for transport

178 Administrator’s Guide to VPN and Remote Access, Second Edition

Physical layer
The final layer on the TCP/IP stack is the
Physical layer. This layer is at the base of the
stack and is the last section a packet must go
through before it’s sent out across the trans-
mission medium. The Physical layer contains a
collection of services and specifications that
provide and manage access to the network
hardware. Its responsibilities include:
X Interfacing with the computer’s network
hardware
X Checking for errors in incoming packets
of data
X Tagging outgoing packets with error-
checking information
X Acknowledging the receipt of a packet
X Resending that packet if no acknowledg-
ment is returned by the recipient
This layer is almost totally invisible to the
everyday user, which, given this layer’s com-
plexity, is not such a bad idea.
Figure A
This diagram illustrates the layers of the OSI Model and how they map to different areas of Microsoft’s TCP/IP. It also shows
the four layers of the TCP/IP Reference Model and how they map to Microsoft’s TCP/IP.
The OSI reference model
The Open Systems Interconnected reference
model (OSI/RM) is the standard that all other
protocols follow. The OSI/RM provides a
framework that connects heterogeneous sys-
tems using a common protocol. It also gives
developers universal concepts so they can
develop and perfect protocols. As you can see
in Figure A, each layer of the TCP/IP reference
model corresponds to a part of the OSI model.
TCP/IP has transformed the way people
use computers. Although TCP/IP was origi-
nally developed to traverse heterogeneous net-
work environments, it has evolved due to its
nonproprietary standards. These standards
provide a framework for programmers who
develop protocols. Without it, we would still
be in the stone-age of networking.
Protocols 179
 Troubleshoot your network errors with
TechRepublic’s TCP/IP checklist
Jan 21, 2000
By David Mays
W
hether your systems are powered by
Windows or Linux, network config-
uration problems inevitably arise.
Often the problem can be traced to an
improperly configured TCP/IP setting, but
finding the culprit can be difficult. Use the fol-
lowing checklist to help identify and eliminate
network TCP/IP errors.
TechRepublic’s TCP/IP checklist
1. What stopped working? The client or the
server? Ask around before attacking
coworkers’ PCs; learn if the outage is
affecting others or just a single desktop.
2. If the server stopped working, you
should notice many office mates banging
their heads against their desks simultane-
ously. If this is the case, focus on fixing
the server.
3. If a single client PC has stopped respond-
ing to the network, ask the user whether
new software was just loaded or whether
any recent changes have been made to the
Listing A
C:\WINDOWS>PING 127.0.0.1
PINGing 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<10ms TTL=32
Reply from 127.0.0.1: bytes=32 time<10ms TTL=32
Reply from 127.0.0.1: bytes=32 time<10ms TTL=32
Reply from 127.0.0.1: bytes=32 time=1ms TTL=32
PING statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0
(0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
180 Administrator’s Guide to VPN and Remote Access, Second Edition
system, including the installation of service
packs, new Internet software, Elf Bowling
games, and so on.
4. Check the physical network. The physical
topology of your network is most prone to
failure. In fact, most network problems are
often due to Physical Layer failures.
5. Is it plugged in? Check all network cable
connections. Start at the NIC; is there a
green light? Check the wiring closet to see
if someone “borrowed” the patch cable.
Check the hub to see if the system is get-
ting a link across the cable.
6. If you don’t have a cable tester, get one.
Cabling is very susceptible to electricians,
cleaning people, HVAC personnel, and
so on.
7. Start PINGing. Both Windows and Linux
have the PING command. In a typical net-
work you have this order (client->gateway-
>server) or (client->gateway->internet).
First, attempt to PING yourself from
the Windows command prompt or use the
Linux shell. Your local “loopback” address
for such testing is 127.0.0.1. Windows
users should see the response shown in
Listing A, while Linux operators should see
the results shown in Listing B.
Note that in Linux you must add -c 4
to the command, which requests four
PINGs. Otherwise, you must stop the test
using [CTRL]C.
8. If you do not receive a successful PING
from yourself, in Windows, try re-installing
the TCP/IP protocol from the Network
Control Panel. In Linux, see if your
Ethernet card is loading properly by using
ifconfig. It should provide the information
shown in Listing C.
When you issue the interface configura-
tion (ifconfig) program, you’ll receive a list
 of your interfaces. If the loopback (lo) is
not listed, you may have an incorrectly
configured kernel or possible problems
with the loopback module. Try recompiling/
reinstalling to see if that resolves the
problem.
9. If PINGing your loopback worked fine,
then try PINGing someone who is on
the same subnet as you. In the ifconfig
example above, the IP address is set to
192.168.1.100. Thus, in this scenario you
should attempt to PING 192.168.1.1. Be
sure the target IP address being PINGed is
a valid IP address assigned to a system;
otherwise, you’ll receive errors. Use the
Start | Run | IPCONFIG command to
learn your NT machine’s IP configuration
(use the WINIPCFG command with Win-
dows 98).
In Linux, use ifconfig to learn your net-
work settings.
10. If you can PING someone on your local
subnet, move on to the next step. If you
can’t, you’re probably experiencing a Physi-
cal Layer failure. The usual suspects are
bad cables or a NIC gone bad (they do
that sometimes). With loopback, you were
just testing the inner workings of the
Listing B
[root@gateway /root]# PING -c 4 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=1.2 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.9 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.9 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.9 ms
—- 127.0.0.1 PING statistics —-
4 packets transmitted, 4 packets received,
0% packet loss
round-trip min/avg/max = 0.9/0.9/1.2 ms
TCP/IP protocol stack; with PINGing on
your local subnet you tested for failure on
the failing machine. Try replacing the net-
work card and using a new patch cable.
11. The next problem area is in the gateway.
Find the IP address of your gateway. You
can find this in the IPCONFIG screen
with NT systems (WINIPCFG for Win-
dows 98) or in Linux by running the
netstat-rn command, providing these
results shown in Listing D.

Listing C
[root@gateway /root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:11:22:33:44
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:219876 errors:0 dropped:0 overruns:0 frame:0
TX packets:153838 errors:0 dropped:0 overruns:0 carrier:0
collisions:77 txqueuelen:100
Interrupt:10 Base address:0x230

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

Protocols 181
 Listing D
[root@gateway /root]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask
127.0.0.0 0.0.0.0 255.0.0.0
0.0.0.0 192.168.1.254 0.0.0.0
The -rn prints the routing table and puts
everything in numeric format. In this
example, the default gateway (0.0.0.0) is
192.168.1.254.
If you don’t have a gateway config-
ured, then one will not show up in
WINIPCFG or when using netstat.
This is a problem.
In Windows, locate Start | Settings |
Control Panel | Network | TCP/IP |
Gateway and add your gateway. This is
your local interface on your router. In
Linux, use linuxconf or set up a temporary
route using:
route add default gw
gateway_ip_address
where gateway_ip_address is your gateway.
PING this address; this will prove a
solid connection from your PC to the gate-
way. If you have made it this far, the PC is
working, the cabling is working, and the
router (gateway) interface is working. You
can skip to the next section.
However, if you receive no response
from the gateway, and you have one con-
figured, it’s time to call in the big guns.
Your router is improperly configured. It
must have a local interface (IP address) on
your subnet to listen to the traffic on your
network. If there is no interface, have the
182 Administrator’s Guide to VPN and Remote Access, Second Edition
Flags MSS Window irtt Iface
U 0 0 0 lo
UG 0 0 0 eth0
router administrator add one. If it has one
but has stopped working, it could mean
you’re experiencing a router failure, and
others will be affected as well. Conversely,
the router administrator may have loaded
an old config; check with the administrator
to make sure this isn’t the case.
12. The final step is through the gateway.
PING something that is on the other side
of the gateway. In an intranet, PING a
printer on a remote subnet. On the Inter-
net, PING Yahoo! (204.71.200.68). If you
do so successfully, you should not have a
problem. If you can’t get to a particular
system in your network or on the Internet,
that resource may not be available. You
may want to tell the administrators of those
systems about this checklist! Certainly, you
can expect they’re working through the
same difficulties as you.
Remember, TCP/IP was designed to be
indestructible, even in a global thermonuclear
war. After you get past an initial install, it
should run for quite some time without any
trouble. Always look for the most obvious
problems first, and if in doubt, reboot your
system.
Troubleshoot Novell TCP/IP network errors
with TechRepublic’s checklist
Jun 21, 2000
By Steven Pittsley, CNE
J
ust as with Windows or Linux systems,
TCP/IP network configuration issues can
prove quite frustrating to solve on Novell
networks. Novell administrators can save time
by following a troubleshooting checklist.
Here’s a step-by-step guide that you can use
the next time your Novell network experiences
TCP/IP problems.
What changed last?
We do not live in a perfect world. Equipment
breaks or software changes are made, and it’s
up to us to resolve the ensuing problems.
When we’re faced with network troubles, our
first step should be to answer one simple ques-
tion: What changed?
Many times, the answer to this question will
provide the resolution to our problem. This
guide offers some straightforward trou-
bleshooting steps to help diagnose and resolve
problems on misbehaving Novell TCP/IP
networks.
Determine the scope of
the problem
When troubleshooting any problem, take a
moment to absorb the big picture. Is one user
or a single system affected, or does the prob-
lem have an impact on the entire department?
First, call the help desk to see if it is receiving
similar complaints. Determining the scope and
nature of a problem will allow you to diagnose
and resolve any issue correctly and efficiently.
Single-client problem
If a single client is having connectivity prob-
lems, you can follow these steps to restore net-
work service to your users and systems.
X Check physical connections. Sometimes
users move their computers and forget to
plug in the network connection. Occasion-
ally, the network connection is accidentally
removed. Reconnect both ends of the net-
work cable and check to see if the cable has
been severed or crushed by a heavy piece of
furniture.
X Reboot the computer. As simple as it may
be, rebooting the workstation resolves many
problems. NetWare 5 clients will automati-
cally reconnect if there’s a lapse in the net-
work signal, but older clients don’t have
this capability. Rebooting the workstation
shouldn’t make the problem worse, and it
will provide you with a good starting point
for troubleshooting configuration issues.
X Check the network signal. Verify that the
network card has a green light. This does
not always mean that the signal is good, but
it is a sign of connectivity. Using a line
tester, verify the physical cabling from the
communications closet to the wall jack.
X Verify the line speed. Using a line tester,
verify the speed of the connection. Switch
ports can be forced to slower speeds, and
network cards can be configured incor-
rectly. Also verify that the switch port and
the network card are not both configured
to auto sense the line speed. If they are,
neither one will be able to determine the
correct speed.
X Check the wiring closet. If you aren’t
receiving a signal at the client, head for the
wiring closet. Reconnect both ends of the
patch cable to ensure the connection is
good. Next, check for a link light on the
hub or switch port. If you don’t have a link
light, try another port. Finally, check for
error lights on the network device and con-
firm that the network feeds are securely
connected.
X Use PING to test connectivity. If every-
thing in the communications closet is good,
go back to the workstation and PING the
local loopback address of 127.0.0.1. This
will test the TCP/IP protocol stack and ver-
ify that it is working correctly. Next, try to
Protocols 183
 PING various locations on the network.
Start by PINGing a workstation on the
same network segment as the non-working
client. Finally, PING the default gateway,
followed by a device on the other side of
the gateway, such as a remote server or an
Internet address. A failure of any of these
devices should pinpoint the problem.
X Use TRACERT to test connectivity. If
you are unsure of the IP addresses of
various network devices, use the handy
command-line utility TRACERT. Select an
Internet address, such as 192.233.80.4,
which is Novell’s home page, or
208.49.160.19, which is TechRepublic’s site.
At a command prompt, type TRACERT
and then the IP address. For instance, to
check the route to TechRepublic, you would
type TRACERT 208.49.160.19. The results
will show each hop that the ICMP packet
takes to reach the destination address. A
failure of any of these devices should pin-
point the problem.
X Use WINIPCFG to release/renew the
IP address. Releasing and renewing the IP
address lease can eliminate problems with a
particular address. While the WINIPCFG
screen is displayed, take a moment to verify
the other settings.
X Try a different computer on the same
network connection. If you don’t know
whether the issue is a computer problem or
network problem, try using a different com-
puter on the “bad” network connection.
Using a laptop is probably the easiest
method, but you can also borrow a nearby
computer that is not in use. If the other
computer works normally, then look to the
nonfunctional computer to resolve the
problem.
X Reinstall the network drivers. Reinstalling
the network card driver will allow you to
start from scratch with the network soft-
ware. After doing this, you should have no
doubts about the configuration of the net-
work card.
X Install a new NIC. Network cards, like any
other device, can go bad. Install a brand-
184 Administrator’s Guide to VPN and Remote Access, Second Edition
new card, not one that has been sitting on
the shelf for the past six months, so that
you don’t introduce new problems into the
already fuzzy equation.
Department or area
connectivity problem
When one or more segments of a TCP/IP
network lose connectivity, the problem usually
lies with the network equipment. Here are
some troubleshooting tips that can help you
isolate the problem and restore connectivity to
your users and systems.
X Reboot at least one workstation. If
the outage is brief, the workstations may
regain connectivity after being rebooted.
NetWare 5 clients will be able to reconnect
automatically, but older clients will be
unable to do so.
X Check the wiring closet. Collect a few
data jack numbers and head to the com-
munications closet. First, determine if all
the devices in the closet are powered on.
A localized power outage is a common
cause of network failures. Next, determine
if all the data jack numbers are connected
to a single network device. If they are,
move a couple to a different device and
see if the problem goes away. Finally, look
for error lights on the switch or hub and
confirm that the network feeds are
securely connected.
X PING the network equipment from the
affected area. Try to PING the switch
from a workstation located in the affected
area. If that is successful, PING the default
gateway, followed by a device on the other
side of the gateway. A failure on any of
these devices should pinpoint the problem.
X Use TRACERT to test connectivity.
As described in the previous section, use
TRACERT to quickly test the network
devices from the affected area to the Inter-
net. If you use TRACERT from a working
area and then from the non-working area,
are both routes the same? If they aren’t,
the differences may help you pinpoint
the problem.
X Verify any router or network changes.
Because an entire area has been affected, it’s
possible that someone has made changes to
a router or network device. Ask someone
from the wide area network (WAN) team to
confirm that the device is configured cor-
rectly. If the connection is made through a
leased line, contact the provider’s support
desk to verify that the device is working
correctly.
File server TCP/IP problem
Once TCP/IP is configured and working on a
file server, you normally won’t have many
problems with it. However, occasionally some-
thing is changed and problems arise. Here are
some tips to help you troubleshoot these prob-
lems and restore network service to your users
or systems.
X Things to consider. Was any software
recently installed on the file server? Has the
server gone down lately? Why was it down?
Press the up arrow key to scroll back
through many of the recent commands that
have been executed and look for something
to be loaded, unloaded, set, or changed.
X Check the physical connections. While
it’s normally rare to find your server
unplugged from the network, you should
never overlook the obvious. An operator or
cleaning person could accidentally discon-
nect the network connection and not even
realize it.
X Check the network signal. Verify that the
network card has a green light to indicate
that a network signal is present. Using a line
tester, verify the physical cabling from the
communications closet to the wall jack.
X Verify the line speed. If your network
contains segments with differing speeds, use
the line tester to verify the speed of the
connection. Switch ports can accidentally be
forced to a slower speed and network cards
can be configured incorrectly.
X Check the wiring closet. Since most
servers are in a secured area, many of the
wiring closets are also well secured. How-
ever, if you’re not receiving a signal at the
server, head for the wiring closet. Check the
patch cable and reconnect both ends to
ensure the connection is good. Next, check
for a link light on the hub or switch port. If
you don’t have a link light, try another port.
Look for error lights on other ports and
verify that the network feed is securely con-
nected. You might also try a different port
on the network device, or even try a differ-
ent network device altogether. Before doing
so, verify that the new device is working
correctly.
If you aren’t receiving a signal at the client,
head for the wiring closet.
X Verify that other protocols are working
correctly. If your file server is running IPX
or another protocol, verify that it is working
correctly. If so, then you can begin to look
toward a TCP/IP configuration problem.
This is not always true, but it is very rare to
see a network card unable to pass a single
protocol.
X Are all network cards having problems?
If the file server has multiple network cards,
determine whether one of them is having a
problem or if they both have similar prob-
lems. It is rare for both network cards to
physically fail at the same time. If one is
working and the other one is not, check the
configuration of the failing card.
X Check CONFIG.NCF and
AUTOEXEC.NCF for changes. Verify
that all the settings in these two boot files
are correct. Someone may have recently
changed something that is causing the
problem you’re facing.
X Verify bindings and network card con-
figuration. Make sure that the network
card bindings and configuration are correct.
Using SET commands from the console,
unbind the protocol from the network card,
reload the driver, and bind the protocol
back to the card.
Protocols 185
 X Use PING to test connectivity. Using the
NetWare server’s PING utility, PING the
local loopback of the file server to verify
that the TCP/IP stack is working correctly.
If this test is successful, PING a device that
is on the same segment as the server, fol-
lowed by the default gateway and a device
on the other side of the gateway. A failure
on any of these devices should pinpoint the
problem.
X Use IPTRACE to test connectivity. A
NetWare server’s IPTRACE utility is very
similar to TRACERT. Choose an IP address
from a distant router or the Internet and at
the server console type: IPTRACE <IP
address>. You’ll be taken to a new screen
that shows the route that the ICMP packet
took to reach the destination.
X Verify that the server is not discarding
TCP/IP packets. From the server’s system
console screen, enter: SET TCP IP DEBUG
= 1. The console screen should immediately
start scrolling TCP/IP information. To stop
the log, enter: SET TCP IP DEBUG = 0,
and you shouldn’t see any packets being
DISCARDed.
X Use TCPCON to gather TCP/IP statis-
tics. NetWare 5.x includes a nifty utility
Putting the “private” in virtual private
networking
Apr 12, 2001
By Debra Littlejohn Shinder, MCSE
V
irtual private networks (VPNs) are
growing in popularity, and the reason
is obvious: The ability to connect to a
private LAN by “tunneling” through the pub-
lic Internet provides both convenience and
cost benefits. This is especially true if the con-
nections are of long duration or over very long
186 Administrator’s Guide to VPN and Remote Access, Second Edition
called TCPCON.NLM. You should be able
to see the values in the middle of the screen
changing as network traffic flows to and
from the server. Verify that IP routing is
enabled by selecting Protocol Information
-> IP -> IP Packet Forwarding. The IP
Packet Forwarding field should be set to
Router. TCPCON can also be used to verify
the IP Routing Table.
X Install a new network card. If you deter-
mine that the network card is bad, install a
new one. This will affect all your users and
systems, including ones that might be work-
ing and currently in use.
X Reboot the server. Because of the impact
that this solution will have on your users
and systems, rebooting the file server
should be used only as a last resort. On a
NetWare 5 server, you can issue the
RESTART SERVER command.
These troubleshooting steps may not solve
all your connectivity problems, but they
should provide you with a good starting point.
Hopefully, you will never need to use them.
But as we noted earlier, we do not live in a
perfect world.
distances. This is called an access VPN, and
can work across analog or ISDN dial-up lines,
DSL, or cable modems. Intranet and extranet
VPNs can be used to connect corporate
offices at different locations to one another
using a dedicated connection, or to link to the
sites of partners or customers.
 A great deal has been written about VPN
tunneling and popular tunneling protocols
such as Point-to-Point Tunneling Protocol
(PPTP), Layer 2 Forwarding (L2F), and Layer
2 Tunneling Protocol (L2TP). IPSec can also
perform tunneling, but it is more commonly
used to provide security for an L2TP tunnel.
These tunneling protocols make virtual net-
working possible.
Using a tunneling protocol, a client com-
puter anywhere in the world can connect to a
server running the same protocol and access
the entire company LAN on which the server
resides (provided both are configured appro-
priately). The key is that both the client and
the server are connected to the global Inter-
net. The network is virtual because there is
no direct connection from the client or
server.
What about the second part of the equa-
tion? A virtual network is useful and may save
money (because a client can dial up a local ISP
instead of making a long-distance call directly
to their company’s RAS server), but it’s not
secure. Data packets are traveling across a vast
public network and could be intercepted and
read or changed en route. Before virtual net-
working can be used for sensitive or mission-
critical communications, you must find a way
to make it private. That’s what VPN security
protocols are all about.
In this article, I will show you how VPN
security works, discuss the protocols that keep
the data private as it travels through the tunnel,
and address the question of “Just how safe is it
to send your data through a VPN?”
TIP
There are many ways to construct a
VPN tunnel, including both software- and
hardware-based implementations. Some
use open source software, such as
Secure Shell (SSH), and others—such
as CheckPoint’s FWZ Encapsulation—are
proprietary. Each VPN vendor can offer
its own solution, as there are no universal
standards.
Components of a secure
connection
The tunneling process is called encapsulation
because the tunneling protocol, also called the
encapsulating protocol, creates the tunnel
through which the passenger protocol (for
example, PPP in a dial-up connection) travels.
A carrier protocol carries the encapsulated
packet. IP is typically the carrier protocol, as it
routes packets across the Internet.
The tunnel is the conduit by which the data
travels over the public network, but it does not
secure the data itself. Security of data commu-
nications involves several issues, including:
X Verifying the origin of the data—making
sure that the apparent sender really sent it.
This is called authentication.
X Ensuring the integrity of the data—
making sure that it has not been modified
during its travel between sender and recipi-
ent. This is also called packet authentication.
X Providing confidentiality for the data—
making sure that if an unauthorized party
does intercept it, it cannot be read.
A secure VPN connection provides all three
of these services using security protocols.
Protocols protect privacy
Just as a VPN requires a tunneling protocol to
establish the virtual network, it also requires
separate protocols to provide the privacy.
These include:
X Authentication protocols
X Encryption protocols
Authentication protocols are used to vali-
date the identity of a user or computer and
ensure data integrity. Encryption protocols
provide confidentiality.
The authentication and encryption proto-
cols used for a VPN connection depend on
the particular implementation by the vendor of
the VPN solution and settings selected by the
VPN user (on the client side) and the network
administrator (on the server side).
For a VPN client and VPN server to estab-
lish a connection and communicate over an
internetwork, they must support at least one
Protocols 187
 common authentication protocol and one
common encryption protocol.
VPN authentication
There are different authentication levels asso-
ciated with VPNs. Two of them are user-level
authentication (PPP authentication) and
machine-level authentication, which uses the
Internet Security Association and Key Man-
agement Protocol (ISAKMP).
User-level authentication
When a VPN client attempts to make a con-
nection to a VPN server, the server will use a
PPP user-level authentication method to con-
firm the client’s identity based on the user’s
credentials (account name and password or
smart card and PIN). In addition, the VPN
server must verify that the client has the
proper permissions to establish the connec-
tion (this is called authorization or access
control).
With mutual authentication, the process
goes both ways; the client also authenticates
the server to verify its identity and protect
against server masquerading.
Some user-level authentication protocols
include:
X Password Authentication Protocol
(PAP), which uses plain text passwords to
authenticate the client’s identity.
X Shiva PAP (SPAP), which is used to
authenticate Shiva clients.
X Challenge Handshake Authentication
Protocol (CHAP), where the server “chal-
lenges” the remote client to supply authen-
tication credentials. Message Digest 5
(MD5) is used to hash the message, allow-
ing the hash value to be sent across the net-
work instead of the actual password.
X Microsoft CHAP (MS-CHAP), which is a
version of CHAP developed by Microsoft
to authenticate Windows clients. MS-CHAP
v2 is a mutual authentication protocol by
which both the client and the server prove
their identities to one another.
The first two are supported by Cisco’s L2F
implementation; the third is associated with
Microsoft’s PPTP.
188 Administrator’s Guide to VPN and Remote Access, Second Edition
TIP
Hashing is a nonreversible method of
applying an algorithm (formula) to a string
of characters, such as a password, to dis-
guise the original data. It is called nonre-
versible because you cannot reverse the
formula and recover the original data.
Authentication can also be provided by
Remote Authentication Dial-In User Service
(RADIUS), which is an industry-standard pro-
tocol that requires clients to send user and
connection information to a RADIUS server,
which authenticates the client and authorizes
the connection request.
PAP is the least secure authentication
method because if an unauthorized person
uses a packet sniffer (for example, the Net-
work Monitor software built into Windows
NT/2000) to capture the data as it travels
across the network, he or she will be able to
view the contents of the packets and read the
password. PAP is not recommended for VPN
authentication.
Machine-level authentication
When the IPSec encryption protocol is used,
the authentication of the client and server
machines is done using machine certificates.
The ISAKMP protocol is used to create a
security association, and the Oakley key-
generation protocol is used to generate and
manage the authenticated keys that are used to
secure the data.
TIP
Digital certificates use cryptography to ver-
ify identity, while making it difficult for an
unauthorized person to intercept, alter, or
spoof (forge) data. Certificates use public
and private keys (a key pair) to sign mes-
sages; the sender’s public key is included
in the certificate. The sender signs the
message using his or her private key.
Using the public key that matches it, the
recipient can verify the sender’s identity.
VPN encryption Figure A
The data that passes through a VPN tunnel is
encrypted to provide confidentiality. When it
reaches its destination, it is then decrypted so Authenti-
IP TCP/UDP Data
it can be read. If someone captures the data Header cation
Header
Header
packets in transit, he or she will not be able to
read the messages without access to the
encryption key. The key is used to lock the
data, and the longer the key is, the more secure
it is. Just as a ten-letter password is more diffi-
cult to guess than one with only three letters, a Entire packet is signed
128-bit key is more difficult to crack than a
AH signs the entire packet, providing authentication and integrity but not
40-bit key. confidentiality.
The protocol used to secure VPN data
depends on the encapsulation protocol that is Figure B
used to build the tunnel. For example,
Microsoft PPTP VPNs use the Microsoft
Point-to-Point Encryption (MPPE) protocol.
The specifications for Cisco’s L2F (see RFC Workstation Workstation Workstation Workstation
2341) do not specify an encryption protocol.
Both Microsoft and Cisco now support
L2TP as the preferred tunneling protocol. VPN tunnel
Both implementations operate in conjunction VPN server
(gateway)
with the IP Security Protocol (IPSec) to pro- Internet
vide encryption. VPN server
(gateway)
TIP
L2TP is an Internet standard, defined in
RFC 2661. IPSec is described in RFC
1825.

IPSec was developed to add security to data Workstation Workstation Workstation Workstation
that travels across a network (not only VPN
connections) and is capable of providing both When ESP is used between two gateways, data is encrypted only when
authentication and encryption. The compo- traveling over the Internet.

nents of IPSec are:

X Authentication Header (AH)
X Encapsulating Security Payload
X Security associations (SAs)
Let’s take a look at how these components
work.
IPSec Authentication Header (AH)
AH can provide authentication and integrity
between a set of hosts or between a set of
gateways. Both ends of the connection must
implement AH. It is important to understand
that AH does not provide confidentiality of
data; it can still be read if intercepted. How-
ever, it does provide protection from modifica-
tion. The packet is signed, and the signature
ensures that the identity of the sender is
known and that the data has not changed since
it left the sender.
The authentication header is placed
between the IP header and the TCP/UDP
header on the data packet. The entire packet is
signed (see Figure A).
IPSec Encapsulating Security Payload
Encapsulating Security Payload (ESP) can pro-
vide authentication, integrity, and confidential-
ity of data traveling between two or more
hosts or two or more gateways that have

Protocols 189
 implemented ESP. VPNs often utilize gateway-
to-gateway encryption, which protects the data
while it is traveling on the public Internet. In
this case, data is not encrypted while on the
private network (see Figure B).
ESP and AH can operate in two modes:
transport mode or tunnel mode. In tunnel
mode, ESP creates a tunnel to provide privacy
for tunneled packets. The packets can be
encrypted using Data Encryption Standard
(DES) or 3DES (also called Triple DES),
although encryption is not required if only
authentication and integrity are desired and
confidentiality is not required.
ESP in transport mode is used to provide
the security for a tunnel created by L2TP.
When used in transport mode, ESP does not
sign the entire packet. It protects the data, but
not the IP header (see Figure C).
IPSec security associations
IPSec creates a security association (SA) to
define the security services and keys that will
be used to secure a communication between
two hosts or gateways. The security associa-
tion is like a contract between the sending
and receiving computers (source and destina-
tion) that lays out the terms or rules for the
transaction.
Figure C
Data and ESP trailer
are encrypted
IP ESP ESP ESP
Header Header Data Trailer Authenti-
cation
ESP header, data, and
ESP trailer are signed
In transport mode, ESP does not sign the entire packet.
190 Administrator’s Guide to VPN and Remote Access, Second Edition
The Internet Engineering Task Force (IETF)
has established a standardized way for this
process to take place, using two technologies:
X ISAKMP
X Oakley
ISAKMP manages the security associations
and negotiates the security policies. Oakley
generates the authenticated keys that are used
to protect the data. ISAKMP/Oakley is known
as the Internet Key Exchange (IKE). Cisco
Systems prepared IETF drafts specifying stan-
dards for IKE and made a version of IKE
available at no charge via the Internet.
The security association is established by a
two-part process:
X Key exchange
X Data protection
During the key exchange step, the commu-
nicating computers create the ISAKMP SA.
Oakley protects the identities during this step.
Policy is negotiated, and the computers
exchange information that allows the genera-
tion of a shared secret key, which is generated
by the Diffie-Hellman protocol. The comput-
ers must then authenticate the key information
exchange (note that the keys themselves are
not exchanged; only the information that is
used to generate the shared “master” key).
The second step, data protection, begins
with the negotiation of a pair of SAs that are
called the IPSec SAs (to differentiate them
from the ISAKMP SA). Policies are negotiated
for the new SAs. There are two because one is
used for inbound communication and the
other for outbound. The ISAKMP SA protects
the negotiation. Multiple IPSec SAs can be
protected by one ISAKMP SA.
The IPSec authentication and
encryption process
Once the SAs have been established, the send-
ing computer will use the outbound IPSec SA
to sign the packets (to provide integrity) and
encrypt the data (for confidentiality). The
packets will then be transmitted through the
tunnel to the destination computer.
The destination computer will use the
inbound SA and corresponding key to verify
the integrity signature and decrypt the data,
and then the decrypted data will be passed by
TCP/IP to the appropriate application.
TIP
If there is a firewall, proxy server, or router
functioning as a security gateway between
the communicating computers, packet fil-
tering must be configured to allow the
IPSec packets to go through.
Summary
Security is a major concern for VPN imple-
mentations because the data passes across the
public Internet to reach the private network.
There are many ways to provide protection for
Configuring certificates for an
L2TP/IPSec VPN
Dec 14, 2001
By Carol Bailey, MCSE+I
M
uch has been written on the merits
of using a virtual private network
(VPN) connection for remote
access and how Windows 2000’s Routing and
Remote Access (RRAS) service has greatly
simplified the process. The main benefit of a
VPN is cost savings, since it allows corpora-
tions to use a persistent Internet connection
rather than a bank of modems, and calls are
cheaper for users because they incur only local
charges to their ISP rather than long-distance
costs.
Many of us have mastered the use of PPTP
connections for a VPN. However, Windows
2000 (and Windows XP) natively supports the
more secure form of VPN, L2TP/IPSec.
Unfortunately, little has been written about
how to configure L2TP/IPSec beyond saying,
“It’s more complicated.” So this three-part
series will provide a step-by-step tutorial on
tunneled data. One of the most common secu-
rity protocols in use today is IPSec. IPSec can
provide authentication, integrity, and confiden-
tiality. It can even be used in tunnel mode as
the encapsulation protocol that creates the vir-
tual tunnel, however, it is more often used in
transport mode to provide encryption of data
that passes through an L2TP tunnel. Microsoft
and Cisco, along with other vendors, support
L2TP and IPSec as the most secure and effec-
tive means of implementing VPNs.
In this article, I discussed how VPNs work
and went under the hood to examine the secu-
rity protocols that put the “private” into virtual
private networking.
how to get Windows 2000 Professional to
make an L2TP/IPSec connection to a Win-
dows 2000 VPN server, as well as how to cus-
tomize and maintain that connection. In this
installment, I’ll explain how to use the Win-
dows 2000 Certification Authority service to
achieve a connection. Then, my next two arti-
cles will focus on customizing and trou-
bleshooting L2TP/IPSec connections.
WIN2K VPN AND RRAS BASICS
For the basics on using and configuring
Windows RRAS with VPN connections,
see “Setting up a VPN with Windows
2000” (page 53).
It all starts with the certificates
The most likely reason that L2TP/IPSec
connections fail is because of problems with
Protocols 191
 certificates. In its default configuration, a valid
computer certificate is required on both the
client and the server. There are various ways of
obtaining a computer certificate for a
L2TP/IPSec connection, such as using a third-
party Certification Authority like VeriSign
(which should provide its own instructions on
this) or using Windows 2000 Active Directory
automatic certificate deployment.
However, this article will describe how to
use L2TP/IPSec connections by issuing your
own certificates—without Active Directory—
using the Windows 2000 Certification Author-
ity service in Stand-alone mode. This allows
anyone with a Windows 2000 Server to benefit
from L2TP/IPSec connections regardless of
whether they’re running Active Directory or
they have an NT 4.0 domain or even a simple
Windows Workgroup.
These instructions also hold good for using
just IPSec on your network, outside the VPN
environment, although we won’t describe the
IPSec policy configuration.
Preliminary configuration steps
Make the following checks before we begin:
X First, ensure that your Windows 2000 Pro-
fessional can successfully connect to your
Windows 2000 RRAS server using PPTP
with TCP/IP. This will verify that the basics
of RRAS are working, that associated hard-
ware (modem, router, cable modem, etc.) is
working, that the user is allowed remote
access, that remote access policies aren’t
preventing a successful connection, and that
IP address assignment is handled correctly.
X Second, ensure that your client’s Internet
connection is not going through a network
address translation (NAT) server.
Microsoft’s IPSec implementation has
known problems with NAT. If all your
clients’ Internet connections must go
through NAT (as opposed to having static
IP addresses), Microsoft’s L2TP/IPSec
implementation is probably not for you.
X Third, if you have a firewall between the
client and server, you may need to reconfig-
ure it to allow the L2TP/IPSec connection
through. Open UDP port 500 and IP port
50. If you suspect your firewall or another
192 Administrator’s Guide to VPN and Remote Access, Second Edition
intermediary device (e.g., NAT server) may
be preventing your L2TP/IPSec connec-
tions from working, my next article will
help. I’ll describe how to eliminate Internet
devices to confirm whether these are pre-
venting the L2TP/IPSec connections from
working.
Configuring the Certification
Authority service
Deploying your own certificates with an in-
house Certification Authority requires careful
planning. For example, you need to think
about the hierarchy you’ll be using (root CA,
subordinate and issuing servers), the certificate
lifetimes and key lengths, and how you will
secure this service. (Standard advice is to take
the root CA offline and physically secure it
until needed.) One of the best sources of
information on this is Microsoft’s white
paper Windows 2000 Certificate Services
(http://www.microsoft.com/technet/
treeview/default.asp?url=/TechNet/
prodtechnol/windows2000serv/deploy/
2000cert.asp).
To streamline the process for the testing
purposes of this tutorial, we will use only an
online root CA as the issuing certificate server.
Certificates will be requested and issued
through the Web browser, so IIS also needs to
be running on the certification server. How-
ever, these services will be on a different server
from the one running RRAS, just as they
should be on a production network.
On the Windows 2000 Server, you will be
installing the Certification Authority service.
First, double-check to make sure that the date
and time are correct on the server, because
certificates are based on timestamps. Then, go
to the Add/Remove Windows Components
and select Certificates Services. You’ll see a
warning dialog box telling you that after
installing this service, the computer cannot be
renamed, join a domain, or be removed from
one. Click Yes to continue and then click Next.
Now, you’ll be prompted to configure the
Certification Authority service. The first win-
dow prompts for Certification Authority
Type. Select Stand-alone Root CA (Figure A)
and click Next.
Figure A Figure B

Specifying the Certification Authority Type Specifying the CA details

The next prompt will ask for CA Identify- Figure C

ing Information, with some defaults already in
place. The defaults are for your country/
region, the validity time of the certificate (two
years), and the expiration date/time. Fill in the
other boxes with as much or little information
as you desire, although you must supply a CA
name. My example uses the CA Name of
MyCompany Root (reminding me that this is
root CA), as you can see in Figure B.
The next screen is for the Data Storage
Location, which refers to the certificate data-
base and log. Keep the defaults and click Next.
You should now see a warning box that IIS is The newly installed Certification Authority service
running on the computer and must be stopped
to proceed. Stopping IIS will allow us to create manually issue the computer certificate
the virtual directory we are going to use for requests.
deploying the certificates. Click OK, and the
CA virtual directory will install (prompting for Configuring the systems for your
the Windows 2000 source files, so have the Certification Authority
CD handy or have the files available locally or For the computer certificate element to work,
over a network connection). When the installa- both client and server need to have a Certifica-
tion is complete, click the Finish button and tion Authority in common. Then, both need to
then click Close. There’s no need to reboot. have a computer certificate issued by that CA.
You should now have Certification Author- If you are using one of the well-known third-
ity listed as one of your Administrative Tools party CAs (such as VeriSign), you won’t need
on this server. Load it up, and it should look to complete the additional step of retrieving
like Figure C. Under the CA, you’ll see folders the Certification Authority certificate. Win-
for Revoked Certificates, Issued Certificates, dows 2000 ships with these, as you will see if
Pending Requests, and Failed Requests. At the you run Internet Explorer, choose Internet
moment, all of these should be empty. Keep Options from the Tools menu, select the Con-
this console open, because you will need it to tent tab, click the Certificates button, and

Protocols 193
 select the Trusted Root Certification Authori-
ties tab.
You’ll need to complete the following steps
on both the Windows 2000 RRAS Server and
the Win2K Pro client machine. Again, before
you begin, verify the correct date and time on
these machines, as we did for the CA server.
Note that in this tutorial, the client workstation
and the RRAS server will need to connect to
Figure D
Connecting to the Microsoft Certificate Services Web site
Figure E
Installing the CA certificate over the network
194 Administrator’s Guide to VPN and Remote Access, Second Edition
the CA server. The workstation could com-
plete this step when it’s on the corporate net-
work (if it’s a laptop) or after connecting
through the VPN server using PPTP (if it’s a
remote workstation).
Open Internet Explorer and go to
http://<CA servername>/certsrv (where <CA
servername> is the name or IP address of the
CA server we just set up). In my example, this
would be http://w2kca/certsrv. You should see
the home page for Microsoft Certificate Ser-
vices with the name you gave the CA displayed
at the top, as shown in Figure D.
Instead of requesting a certificate immedi-
ately (the default option), select the top option,
Retrieve The CA Certificate Or Certificate
Revocation List, and click Next. The following
page allows you to install the CA path directly
from the server (possible because we are con-
necting to it over the network) or download the
CA certificate into a file (an approach you
should use when the CA server is not con-
nected to the network, as would be the case
with an offline CA). Click on the Install This
CA Certification Path link, as shown in Figure E.
This will result in a warning message asking
you to confirm that you want to add the cer-
tificate to your Root Store. You’ll then see
some information about the certificate, includ-
ing the name you gave it, the fact that it was
self-issued (because it is a root CA, there is no
higher server to sign this certificate), and other
information, such as the time validity, serial
number, and unique thumbprint. Click Yes.
The next screen should inform you that the
CA certificate has been successfully installed.
Requesting the certificate
Once you’ve installed the CA Certificate, click
Home or connect to the Certificate Web site
again. This time, we’re ready to request a cer-
tificate (the default option), so make sure this
option is selected and click Next.
The Choose Request Type screen will
appear with the default being User Certificate
Request For Web Browsing. Remember that
IPSec uses computer certificates and not user
certificates, so this default will not work for
our L2TP/IPSec connection. Instead, select
Advanced Request and click Next to display
the Advanced Certificate Requests screen. Figure F
Accept the default selection of Submit A Cer-
tificate Request To This CA Using A Form
and click Next.
Now you’ll be prompted to fill in the details
of the certificate you require. The information
you supply here is twofold. First, it allows the
CA administrator (who must manually inspect
each certificate request) to identify you and
check that the information you are supplying is
in accordance with acceptance policies. Sec-
ond, it dictates the certificate’s specification in
terms of its usage and security. Fill this in with
care. You will need to specify an identifying
name (e.g., RRAS Server), and the Intended
Purpose must be either Server Authentication
Certificate (e.g., for the RRAS server) or Client
Authentication Certificate (e.g., for the VPN Requesting a computer certificate for IPSec
client). You must also select both Create New
Key Set and Use Local Machine Store, as Figure G
shown in Figure F.
For a production environment, you might
need to change some of the other options for
security reasons (e.g., the key size), but these
settings will suffice for our test connection.
Click Submit, and the next screen will tell you
that your certificate is pending—waiting on the
administrator to issue it—and that you must
retrieve it within 10 days. Happily, since you
are the CA administrator, you don’t have to
wait that long.
The Pending Certificate request

Issuing a certificate from the

Certification Authority
In the Certification Authority console on
your server, you should now have an entry
under the Pending Requests folder, as shown
in Figure G.
If you scroll through the details pane so
you can see all the column information, you’ll
notice that this is where the administrator
would check the identification details before
issuing the certificate and use the e-mail
address supplied if necessary to check or verify
information. However, since we know this is
our certificate request, we can quickly issue it
by right-clicking on it in the details pane and
selecting All Tasks | Issue. The entry will dis-
appear from the Pending Requests folder and
will appear under Issued Certificates.
Installing the certificate
Back on the server or workstation, click on
Home or reconnect to the Certificate Web site
again. This time, select Check On A Pending
Certificate, and you will be prompted to select
the certificate you requested. Because it’s the
only one, it will be selected by default, so go
ahead and click Next. The following screen
will inform you that the certificate was issued.
Click on Install This Certificate, as shown in
Figure H. The final screen should tell you that
your certificate has been successfully installed,
and you can now close the browser.
Ready to connect
That’s it. When you’ve completed these steps
on both your client computer and RRAS

Protocols 195
 server, they should have your CA root certifi-
cate installed and have computer certificates
from this CA that allow them to use IPSec.
Figure H
Installing the certificate
Customize the security of
L2TP/IPSec connections
Dec 18, 2001
By Carol Bailey, MCSE+I
T
hose who are familiar with a PPTP
VPN in Windows 2000 will find that
an L2TP/IPSec VPN is quite similar
but contains some more complicated settings
and management. Along with configuring
computer certificates, which I discussed in
“Configuring certificates for an L2TP/IPSec
VPN” (page 191), an L2TP/IPSec connection
involves some in-depth work with the VPN
settings and other configuration options. This
article will introduce you to the more advanced
approaches that will enable you to customize
the security of your Win2K L2TP/IPSec con-
nections. This will include:
196 Administrator’s Guide to VPN and Remote Access, Second Edition
Because Windows 2000 automatically gen-
erates IPSec policies for L2TP/IPSec con-
nections, you should have nothing further to
do but stop and restart your RRAS service
and try a VPN connection from the client
machine. The defaults supplied with Win-
dows 2000 mean that an L2TP/IPSec con-
nection will be tried before a PPTP
connection. If your RAS client connects,
check the Ports listed in the RRAS console.
If it lists a WAN Miniport (L2TP) VPN
device as Active, you have an L2TP/IPSec
connection up and running.
Final word
This tutorial has explained how to achieve an
L2TP/IPSec VPN connection between a Win-
dows 2000 RAS client and Windows 2000
RRAS server using the Windows 2000 Certifi-
cation Authority service.
X How the default L2TP/IPSec policies work.
X How to monitor the IPSec connections.
X How to override the default IPSec settings.
How the default L2TP/IPSec
policies work
When you’re using Microsoft’s IP Security
(IPSec) outside a VPN environment, you must
assign a preconfigured IPSec policy to the
computers. The Security Policy console (under
Administrative Tools) allows you to view and
edit these IPSec policies. However, by default,
Microsoft uses a hidden, automatic IPSec pol-
icy for L2TP connections, which you won’t see
in the Security Policy console. It is called the
L2TP Rule, and you can see it only when it’s
in use.
The default L2TP Rule policy is in use on
the server when the RRAS server is listening
on L2TP ports and on the remote workstation
when the client tries to connect over L2TP/
IPSec. If you stop the IPSec policy agent on
the VPN server (for example, by typing net stop
policyagent) after RRAS has initialized, you will
delete this default policy. To re-create it, restart
the policyagent service and then the RRAS
service or reboot. The default L2TP Rule is
automatically deleted on the Windows 2000
client whenever the L2TP/IPSec connection is
terminated.
By default, a Windows 2000 client VPN
connection will try an L2TP/IPSec connection
first. If this fails, it then falls back to trying
PPTP. This is why there is no need to change
anything on the client’s connection properties
if the defaults are still in use when you try to
make an L2TP connection from the client.
However, you might want to change this for
security reasons so that only an L2TP/IPSec
connection will be tried. If so, you will need to
go into the connection’s Network properties
and change the Type Of VPN Server I Am
Calling setting from Automatic to Layer-2
Tunneling Protocol (L2TP).
You can check to see that an L2TP connec-
tion is being used on the VPN server by look-
ing at the Ports folder in the RRAS console on
the VPN server. Look for an Active status on
an L2TP WAN Miniport, as shown in Figure A.
The RRAS console will tell you that an
L2TP connection is being used, but it won’t
tell you anything about the IPSec side of the
connection. To see exactly what IPSec settings
are being used, you’ll have to delve a little
deeper.
How to monitor the IPSec
connections
You use some of Win2K’s standard IPSec
monitoring utilities to see what IPSec settings
are being used for your L2TP/IPSec connec-
tions. This article assumes that you have a
basic understanding of how IPSec connections
work, along with their basic components.
Figure A
RRAS showing an active L2TP connection
However, if you need some background infor-
mation, these two resources are a good place
to start:
X “IP Security for MS Windows 2000 Server”
white paper
(http://www.microsoft.com/technet/
treeview/default.asp?url=/TechNet/
prodtechnol/windows2000serv/
evaluate/featfunc/ipsecure.asp)
X “Internet Protocol security (IPSec)” from
the Windows 2000 Server Manual
(http://www.microsoft.com/
WINDOWS2000/en/server/help/
ipsec.htm)
You can see the L2TP policy in use with the
IP Security Monitor. When you have a success-
ful L2TP/IPSec connection, type ipsecmon
from a command prompt on the RRAS server,
and you’ll see the L2TP Rule policy. It should
look similar to Figure B.
This monitor gives you some (but not all) of
the information on the current IPSec connec-
tion. To see all the information, you’ll have to
use the Netdiag Windows 2000 Support tool
by typing netdiag /test:ipsec /v at the command
line. You’ll also have this level of information
recorded in your Security Event log if you
have enabled auditing for successful logons.
The policy filters on the VPN server are
sensible ones that you probably shouldn’t
change. You’ll find them under the Current
Phase 2 SAs section when you use the Netdiag
command. They are the source address(es) of
Protocols 197
 the VPN server’s Internet NIC to any destina-
tion address and any source port from the
VPN server to destination port UDP 1701.
However, what is interesting is that (as with
any IPSec connection) the remote access client
and VPN server can negotiate security options
that will be used for the connection. The
default L2TP Rule allows the VPN server to
offer 16 security preferences. (The equivalent
options can be found under the Security Meth-
ods tab when using the Security Policy con-
sole.) To see all offers, type netdiag /test:ipsec
/debug on the server.
The first match between client and server
will be used, so if your Windows 2000 client
and Windows 2000 VPN server offer the same
level of encryption (e.g., both support only 56-
bit encryption), the resulting security methods
used will be data encryption (ESP) with DES
and Cipher Block Chaining (CBC), together
with MD5 as the chosen algorithm method.
This matches the ESP DES/CBC HMAC
MD5 in Figure B. If both server and client
support strong encryption (i.e., they both have
Win2K SP2 installed), the resulting policy will
be ESP 3DES/CBC HMAC MD5.
If the encryption levels are not the same on
the server and the client, the lower one will be
used. So if you want the highest encryption
Figure B
The default L2TP/IPSec policy in use
198 Administrator’s Guide to VPN and Remote Access, Second Edition
level on your L2TP/IPSec connections, ensure
that both the server and all clients support
128-bit encryption. The easiest way to do this
is to install SP2 or to install the High Encryp-
tion Pack if you are running a pre-SP2
machine with 56-bit encryption. However, you
should realize that connections using 3DES
are slower and demand more processing on
the server.
You may be surprised when looking
through the full list of 16 “offers” in Netdiag
that there are more secure security methods
on the list that will not be used by default
because they are farther down the offer list.
For example, you can use both Authenticated
Headers (AHs) and ESP to ensure that the
header information (addresses) is not changed
in transit, and you can use SHA1, which is a
stronger algorithm than MD5. However, both
of these come with the overheads of addi-
tional processing, and if you use AH as well as
ESP, you will also need to open Protocol ID
51 on your firewall.
The least secure offer on the list has AHs
without encrypting the data at all. This is not
most people’s idea of a virtual private network,
but there may be times when this option is nec-
essary for political reasons—for example, when
the data is being transferred in a country where
encryption is banned. However, if you specifi-
cally want to ensure that all connecting remote
clients will encrypt their data, having this offer
automatically listed (albeit at the bottom of the
offer list) may worry you because you cannot
change this default offer list. Fortunately, you
can customize your IPSec settings to prevent
the possibility that this offer will be used.
How to override the default
IPSec settings
You may be wondering how it is possible to
use any of the other offers if a Windows 2000
remote client to Windows 2000 VPN server
uses the same policy, which always results in
matching ESP with 3DES and MD5. Because
the first match between client and server will
be used, a VPN client that doesn’t use the
Microsoft default L2TP Rule may be config-
ured with different security options, so you
can’t predict which of the 16 offers will be
used. Because of this uncertainty, or a desire to
use IPSec settings that are different from the
default, you may have good cause to change
the IPSec options on the VPN server.
For example, you may have deployed SP2
on all of your Windows 2000 computers for
the security patches but do not want the extra
processing of 3DES, and you want to use
DES instead. Or you may want to use the
strongest combination possible, AH and ESP,
using the SHA1 algorithm. Or you may decide
you don’t want the risk of potentially offering
a VPN connection that doesn’t encrypt data.
If you decide to go this route, you’ll need to
disable the default L2TP/IPSec policy and cre-
ate one manually that matches the security
options you want to use. To disable the default
policy, add a new registry key (REG_DWORD)
of ProhibitIpSec and set the value to 1 under
the Windows Registry key shown in Listing A.
Next, reboot the computer. You can do this
just on your VPN server to ensure that only
the security settings you want will be used and
then let the client work through its default
Listing A: Registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters
Troubleshooting L2TP/IPSec VPN
connections in Win2K
Dec 20, 2001
By Carol Bailey, MCSE+I
S
etting up and managing an L2TP/IPSec
VPN in Windows 2000 is quite different
in many respects from working with a
standard PPTP VPN. So it’s not surprising that
troubleshooting these connections also
requires some unique tactics, as this article will
demonstrate.
offer list until a match is found. Or you can do
the same on the client side so that both sides
use only one offer.
Now, you need to configure your own IPSec
policy and assign it. Make sure that you change
the default authentication from Kerberos to
certificates. Use the filters previously men-
tioned, select the security methods you want,
and use Netdiag to ensure that your options
are being implemented. Make sure you also
choose to rekey every so often and select your
own settings for this or use the sensible
defaults in the L2TP/IPSec policy, which are
every 3,600 seconds or every 250,000 bytes.
Summary
This article has provided information that
should help you understand, monitor, and tailor
Microsoft’s L2TP/IPSec connections for a
more secure VPN connection. You’ll find addi-
tional information on Microsoft’s VPN site
(http://www.microsoft.com/windows2000/
technologies/communications/vpn/).
Microsoft’s L2TP/IPSec connections usu-
ally fail for two main reasons:
X Problems with certificates
X Internet device problems (e.g., routers,
switches, firewalls, or NAT)
Other potential problems include:
Protocols 199
 X Straining server resources
X Interoperability with other systems
Problems with certificates
My article “Configuring certificates for an
L2TP/IPSec VPN” (page 191) worked
through an example of how to use your own
in-house CA to issue computer certificates
required for L2TP/IPSec connections in Win-
dows 2000. If you suspect that certificates may
be to blame for your L2TP/IPSec connections
failing to connect, try the steps in this article.
Alternatively, you can use Microsoft’s testing
site (http://sectestca1.rte.microsoft.com/)
to install a computer certificate from
Microsoft’s online CA.
Here are a few other things to check:
X Verify that the date/time is correct on the
client and the VPN server (and the issuing
CA, if using an in-house CA).
X Open the Certificates console on the client
and verify that the CA path is installed, if
using an in-house CA. You can confirm that
it exists under Trusted Root Certificates
Authority | Certificates or by checking that
the computer certificate is listed and valid
under Personal | Certificates.
If you still suspect that certificates may be
the problem, an option to confirm this is elim-
inating them and using password authentica-
tion instead of certificates. This is possible
only if you disable the default L2TP/IPSec
policy and configure your own IPSec settings.
One of the advantages of using your own
IPSec policy is that you can change the authen-
tication method from certificates to passwords.
You may decide that this is a configuration
you actually want to use all the time rather than
just for troubleshooting because it allows you
to use L2TP/IPSec and bypass all the over-
heads of installing, managing, and maintaining
your own Certificate Authority. Perhaps you
cannot justify the expense of using a third-
party Certificate Authority, or you have a non-
Microsoft L2TP/IPSec client that is
compatible but can use only passwords.
However, Microsoft does not endorse using
computer password authentication for
200 Administrator’s Guide to VPN and Remote Access, Second Edition
L2TP/IPSec connections. It argues that it is
not a secure implementation because pass-
words are always vulnerable to guessing and/or
cracking and will be stored in the registry or
Active Directory as part of the IPSec policy. So
remember that it is possible to use Microsoft’s
L2TP/IPSec connections with password
authentication instead of certificates, but you’re
unlikely to get a sympathetic hearing from
Microsoft if you report problems with them.
To use passwords instead of certificates for
your L2TP/IPSec connections, you’ll have to
disable the L2TP policy on both server and
clients and then configure and assign your own
IPSec policy as described in my article “Cus-
tomize the security of L2TP/IPSec connec-
tions” (page 196). But specify password
authentication and type in the password you
want to use. For production use, don’t forget all
the rules about choosing secure passwords (at
least eight characters, mixture of alphanumeric
and nonalphanumeric, mixture of cases, etc.).
If you need help setting up this policy,
there are step-by-step instructions in the
Microsoft Knowledge Base article Q240262,
“How to Configure a L2TP/IPSec Connec-
tion Using Pre-shared Key Authentication”
(http://support.microsoft.com/default.aspx
?scid=kb;EN-US;q240262). This article will
also help if you’re configuring your custom
L2TP/IPSec policy with certificates. For the
Authentication Method, instead of selecting a
preshared key, select Use A Certificate From
This Certificate Authority (CA) and select the
CA by browsing.
Internet device problems
Check any Internet device that might be block-
ing the connection or changing the packets.
Typically, this will be a firewall or a NAT
server but can also include a faulty switch that
is occasionally corrupting packets or a router
that isn’t forwarding Protocol ID 50.
In the first article in this series, we said
that Microsoft’s L2TP/IPSec is not compati-
ble with NAT. However, some L2TP imple-
mentations are NAT-friendly (e.g., Cisco’s
version) because they use a different imple-
mentation. See Microsoft’s VPN FAQs
(http://www.microsoft.com/windows2000/
techinfo/howitworks/communications/
remoteaccess/vpnfaq.asp) for more infor-
mation on the Microsoft implementation and
how it differs from other vendors’. With the
Microsoft implementation, it may be possible
for NAT to allow one client to connect with
L2TP/IPSec but not allow subsequent con-
nections, so you should always connect at least
two remote clients before celebrating.
Even if you’re not using NAT and think
you have configured your firewall correctly (to
allow UDP port 500 and Protocol ID 50), if
your L2TP/IPSec connections are not work-
ing, it may be a good idea to eliminate the
Internet side of the equation by trying to make
a VPN connection from a client machine on
your LAN. If your connections still don’t
work, at least you have narrowed it down to
something on the client or server rather than
attempting to verify all the possible Internet
issues (hardware devices, ISP services, band-
width, firewall, etc.).
To test this connection, you’ll need to tem-
porarily rearrange your network so that there’s
a standard Ethernet connection between the
VPN server’s Internet adapter and your testing
workstation. Assign the workstation a static IP
address in the same range as the VPN server
so that routing is not required and then make
sure that you can successfully ping between the
client and server.
Next, create a new VPN connection on the
Windows 2000 Professional machine that
doesn’t automatically dial the ISP connection
first. (This is not the default.) Attempt to con-
nect your newly created VPN connection.
PPTP and L2TP connections work just fine
over Ethernet since all they care about is a
valid underlying TCP/IP connection. So, if
your client and server are configured correctly,
you should have a good L2TP/IPSec connec-
tion. It’s important to verify that the connec-
tion is an L2TP connection. (On the server,
check the Active Ports under the RRAS con-
sole, or on the client, check the connection’s
Status Details). If you have a successful
L2TP/IPSec connection when connecting this
way but not when you connect a similar client
over the Internet, it’s time to start inspecting
your Internet devices.
Straining server resources
L2TP/IPSec connections consume more server
processing power—specifically, for the data
encryption—than PPTP connections. This will
be especially true if you are using strong
encryption, which will happen by default if
both client and server can support it. Keep an
eye on the VPN server’s CPU usage, either with
the Performance utility running as a service or,
more crudely, with Task Manager’s CPU Perfor-
mance figures. If you discover the processor
slowing down, you have several options, includ-
ing adding another processor, using a network
card that offloads some of the IPSec process-
ing, or disabling the default policy and specify-
ing DES encryption instead of 3DES.
Interoperability with
other systems
If you are hoping to use either the client side
or the server with a different vendor’s imple-
mentation of L2TP/IPSec, check for interop-
erability issues and determine whether they can
be configured to communicate, and when.
Check my previously mentioned article on cus-
tomizing security for information on the
default IPSec settings that will be tried, the
order they’ll be tried, and how you can disable
them and define your own policy if necessary.
However, you can’t change Microsoft’s
implementation of L2TP/IPSec, which uses
IPSec in Transport mode (not Tunnel mode),
and the UDP port number of 1701 cannot be
changed. If the third-party vendor’s implemen-
tation also uses Transport mode and port 1701
for the IPSec side of the connection, chances
are you can configure the custom IPSec set-
tings to match if the defaults do not work.
Additional guidance
L2TP/IPSec connections must establish an
IPSec connection before the tunnel (L2TP), so
if the IPSec connection fails, the tunnel is
never even attempted. Enable logon auditing
and check the Event Viewer’s Security log for
IPSec errors such as negotiation timeouts
(could be lack of a valid certificate or a packet
Protocols 201
 being blocked by network devices). Make a
note of the actual error logged and then
look it up on Microsoft’s Knowledge Base
(http://support.microsoft.com/default.aspx
?scid=fh;en-us;kbinfo). You may also find
these TechNet articles useful:
X “Basic IPSec Troubleshooting in Windows
2000” (Q257225)
(http://support.microsoft.com/default.
aspx?scid=kb;EN-US;q257225)
X “Basic L2TP/IPSec Troubleshooting in
Windows” (Q259335)
The Windows NT 4.0 PPTP VPN client
connection guide
Jun 10, 2002
By Dr. Thomas Shinder, MCSE
I
n the not so distant past, companies that
wanted to allow road warriors access to
resources on the corporate internal net-
work had to install modem banks and multiple
phone lines. The cost of installing multiple
dial-up RAS (Remote Access Service) servers
was compounded by long-distance charges. If
the company wanted to avoid long-distance
charges, it still had to shell out for a 1-800
number. VPN servers remove this capital-
intensive hardware/telco layer and allow you
to support dozens, sometimes hundreds, of
remote access calls with a single VPN server
and high-speed Internet connection.
I’ll look at how to make your Windows NT
4.0 computers VPN clients for Windows NT
4.0 VPN servers. You can use the same proce-
dures to connect Windows NT 4.0 clients to
Windows 2000 VPN servers. The only major
difference between Windows NT 4.0 and
Windows 2000 VPN servers is that the Win-
dows NT 4.0 VPN servers do not support
L2TP/IPSec VPN links. This situation doesn’t
pose much of a problem for our Windows NT
202 Administrator’s Guide to VPN and Remote Access, Second Edition
(http://support.microsoft.com/default.
aspx?scid=kb;EN-US;q259335)
Summary
I hope this article has provided some useful
tips to help troubleshoot your Microsoft
L2TP/IPSec connections and, combined with
my previous articles, has given you a good
basic understanding of how Microsoft’s imple-
mentation of L2TP/IPSec works.
4.0 VPN clients, because the only VPN proto-
col supported by Windows NT 4.0 is the
Point-to-Point Tunneling Protocol (PPTP).
PREREQUISITES
Before configuring your Windows NT 4.0
PPTP VPN client software, you should
install the latest service packets and secu-
rity hotfixes. If you haven’t updated the Win-
dows NT 4.0 computer you plan to make a
PPTP VPN client, visit the Microsoft Win-
dows Update for Windows NT Server Web
site (http://www.microsoft.com/
ntserver/nts/downloads/default.asp)
to get at least Windows NT 4.0 Service
Pack 6a. You’ll find all the security hotfixes
released since Service Pack 6a on this
page, too. I also recommend that you
install Internet Explorer 6.0; it includes a
number of features that improve the user
experience and automatically adds 128-bit
encryption support.
Figure A Figure B

Figure C

Creating the PPTP network

protocol VPN1 – RASPPTPM is the name of the VPN interface on
the VPN client.
Your first step in creating a Windows NT 4.0
PPTP VPN client is to install the PPTP net- Figure D
working protocol. Right-click on the Network
Neighborhood icon on the desktop and click
Properties. In the Network dialog box, click
the Protocols tab. On the Protocols tab, click
the Add button.
In the Select Network Protocol dialog box,
select the Point-to-Point Tunneling Protocol
(Figure A) and click OK. A Windows NT Setup
dialog box will appear and ask you for the loca-
tion of the setup files. You can type in the path
to a local or network location, or just put your The network interface is available on the VPN client computer.

Windows NT 4.0 CD in the tray. Click Continue.

In the PPTP Configuration dialog box Figure E
(Figure B), use the default entry (which is 1).
PPTP VPN clients aren’t going to connect to
more than one VPN server at a time. This
entry is used by the VPN Server to define how
many virtual VPN interfaces the server should
have available for VPN clients. (Windows NT
4.0 VPN servers support up to 256 PPTP
interfaces.) Click OK. At this point, you’ll see a Configure the interface to make outbound calls only.
dialog box that informs you that RAS will be
installed. Click OK to install and start RAS.
on a Windows NT 4.0 Server computer, the
The Add RAS Device dialog box (Figure C)
adapter is configured to allow outbound and
will appear and display the name of the single
inbound calls. To change this setting, click the
RAS device installed on the VPN client
Configure button in the Remote Access Setup
machine. Click OK.
dialog box (Figure D).
The VPN device is now added to RAS. On
Change the setting to Dial Out Only in the
a Windows NT 4.0 Workstation computer, the
Configure Port Usage dialog box (Figure E) to
VPN interface is automatically configured to
prevent the Windows NT 4.0 Server from
call out only. If you install the VPN interface
allowing incoming calls to the VPN interface.

Protocols 203
 Click on the Network button in the Remote
Access Setup dialog box (Figure D) to configure
the LAN protocols you want to support on the
VPN interface. Note that these are the LAN
protocols used over the PPTP link, and not the
WAN protocols used to contact the VPN
server. You’ll always use TCP/IP to connect to
the VPN interface on the VPN server (Figure F).
Click the Continue button in the Remote
Access Setup dialog box. The Point-to-Point
Tunneling Protocol will be added to the list of
protocols on the Protocols tab of the Network
dialog box. Click Close. Restart the computer
to complete the installation of the protocol.
Creating the ISP dial-up entry
VPN clients typically call an ISP to establish an unless you’re using a SLIP connection, and it’s
Internet connection before they establish their
VPN link. Creating RAS connections in Win-
dows NT 4.0 isn’t as intuitive as it is in
Windows 2000/XP, so let’s take a look at Figure G
how you configure a PPP connection to
an ISP.
Click Start | Programs | Accessories.
Click on Dial-Up Networking. You’ll be
asked for location information. Enter at least
your area code. If you have a number you need
to dial to access an outside line, enter that too.
Click Close to dispatch the dialog box after
entering the information.
A dialog box will appear informing you that
your phone book is empty. Click OK to create
a phone book entry for your ISP. This action
brings up the first page of the New Phone-
book Entry Wizard. Enter a name for the con-
nection (Figure G) and click Next.
The Server page will appear. Always select
the I Am Calling The Internet option (Figure H).
Check with your ISP to see what type of pass-
word authentication it requires. You won’t
need to use the third option in this dialog box
not likely you’ll bother with SLIP connections
these days. Click Next.

Figure F

Figure H Figure I

You can use alternate numbers when you use an ISDN terminal
adapter that uses different numbers for each line.

204 Administrator’s Guide to VPN and Remote Access, Second Edition

Figure J
Enter your POP access number on the
Phone Number page (Figure I). You can click
the Alternates button to add alternate numbers
to try if the first one fails. These numbers are
useful when your ISP gives you multiple POP
access numbers. Click Next, and then click
Finish on the last page of the wizard.
The new Phonebook entry will appear and
you can use it right away (Figure J). You don’t
need to restart the computer.
Creating the PPTP VPN
dial-up entry
If you use a dial-up connection to connect to
the ISP, you’ll need to activate that before con-
necting the VPN link. In other words, the
PPTP connection rides on top of the ISP con-
nection. The Windows NT 4.0 PPTP VPN
client can also take advantage of dedicated
Figure L
Figure K
Enter the FQDN or IP address of the VPN server.
links, such as T1, DSL, and cable connections.
In these cases, you don’t need to establish the
dial-up entry before firing up the VPN.
Click the New button in the Dial-Up Net-
working dialog box (Figure J) to create the
VPN connectoid. The same wizard you used to
create the dial-up connection creates the VPN
connection. The only difference is that you use
the IP address or Fully Qualified Domain
Name for the phone number and configure the
connection to use the VPN interface (Figure K).
After you create the VPN connectoid, click
on the More button in the Dial-Up Network-
ing dialog box’s phonebook area and click the
Edit Entry And Modem Properties entry to
bring up the Edit Phonebook Entry dialog
box. In the Dial Using drop-down list box,
you’ll need to select the VPN device you cre-
ated earlier (Figure L).
Figure M
Protocols 205
 Click on the Server tab and select the LAN
protocols you want to support in the VPN in
the Network Protocols frame. Select Enable
Software Compression and Enable PPP LCP
Extensions if your Windows NT 4.0 VPN
server supports them (Figure M).
Click the TCP/IP Settings button and you’ll
see what appears in Figure N. The default setting
is to allow IP address assignment automatically
from the VPN server. This is the most common
option, but if you need to specify a particular IP
address or DNS server, select the option to
specify and enter the appropriate IP address.
Use the Use IP Header Compression option if
your VPN server supports this option.
The Use Default Gateway On Remote Net-
work option is an extremely important one for
you to understand. When you select this
option, the VPN client uses the VPN interface
as its gateway for all non-local networks. Typi-
cally, when the client first dials into the ISP, the
ISP assigns the computer a default gateway,
which is one of the ISP’s routers to the Inter-
net. When the Use Default Gateway On
Remote Network option is enabled, the VPN
server assigns the VPN client a new default
gateway, which forwards all non-local packets
to the VPN server. The result is that the VPN
client cannot access the Internet once it con-
nects to the corporate VPN.
Figure N Figure O
206 Administrator’s Guide to VPN and Remote Access, Second Edition
If this option is disabled, the VPN client
will be able to access both the internal corpo-
rate network and the Internet at the same time.
This creates the possibility that the VPN client
will be able to route packets from the Internet
to the internal network. Click OK.
Click on the Security tab, and you’ll see the
screen shown in Figure O. The only option you
need to select is Accept Only Microsoft
Encrypted Authentication. Selecting this
option ensures that the PPTP VPN client uses
MS-CHAP version 2 to authenticate with the
Windows NT 4.0 Server. If the Windows NT
4.0 Server does not support MS-CHAP ver-
sion 2 (because it has not been updated with
the latest service pack), the client will fall back
to MS-CHAP version 1.
Use Windows NT 4.0 for secure
VPN connections
Configuring the VPN client on a Windows NT
4.0 computer is more challenging than it is on
Win9x computers with DUN1.4 installed. It’s
definitely not as easy to configure as the Win-
dows 2000/XP client. But once you get the
Windows NT 4.0 PPTP VPN client installed,
you’ll have solid and secure connections that
use MS-CHAP version 2 for authentication
and 128-bit data encryption.
IP HEADER
COMPRESSION
SUPPORT
Your Windows NT 4.0 VPN
Server will support this option,
but your Windows 2000 VPN
won’t if you haven’t upgraded
to at least SP4 on the VPN
client.
Solutions
The articles in this chapter highlight a handful of the available products and services designed to
safeguard remote-access computing. If your organization is planning to invest further in its securi-
ty infrastructure, you’ll want to read up on the capabilities of these products.

VPN services on a Cisco PIX firewall..................................................................................................207

Eight commonly overlooked troubleshooting tips for the Cisco PIX VPN..................................210
SonicWALL PRO-VX provides fast, simple firewall and VPN solution........................................213
The D-Link DI-704 cable/DSL gateway ............................................................................................215
Who said you can’t afford your own router? ......................................................................................220
Sharing Internet access with just one IP address................................................................................222
Share small office broadband pipes using a Linksys router and Win2K Pro ................................224
Check Point offers integrated firewall and VPN on Linux ..............................................................228
High marks for Mangosoft’s VPN alternative ....................................................................................230
More options for secure collaboration ......................................................................................CD-ROM

Solutions
VPN services on a Cisco PIX firewall
Jun 27, 2002
By Scott Lowe, MCSE
B How do remote-access
ecause of their flexibility, VPNs are
quickly becoming one of the most
popular methods for allowing remote
access to networks and for establishing secure
connections to small remote-office locations.
VPNs go hand in hand with firewall devices.
Couple that with the Cisco PIX firewall’s
inherently strong security architecture, and you
can see why the PIX is an ideal platform for
establishing this kind of service. In this article,
I’ll show you how to set up VPN services
using your existing PIX firewall.
My setup and some assumptions
For this article, I’ll use a Cisco PIX 515 firewall
running version 5.1 of the Cisco PIX manage-
ment software. My PIX firewall has 16 MB of
RAM with an 8-MB flash and is licensed for
VPN connections, which raises an important
point: In order to use these services on your
PIX, you’ll need to make sure your PIX soft-
ware license includes VPN capability. If it
doesn’t, contact your Cisco reseller to purchase
the appropriate licenses.
I’ll assume your PIX is either up and run-
ning in production or in a working state in a
lab where you can modify the configuration.
You should be able to pass traffic through the
firewall before embarking upon this VPN
journey.
About Cisco PIX VPN services
The Cisco PIX VPN services are based on IP
Security (IPSec), which is a vendor-neutral
standard that defines methods of setting up
virtual private networks. Clients that use the
VPN are able to see services on the host net-
work transparently, as if they were directly
connected to it. The Cisco PIX firewall sup-
ports both PIX-to-PIX and client-to-PIX
VPN configurations.
In this article, I’ll focus on client-to-PIX
VPN configurations, which will enable you to
provide remote network access to partners or
telecommuters. Cisco calls this a remote-
access VPN.
VPNs work?
Before setting up the VPN, it’s a good idea to
brush up on the basics of how VPNs work. A
little knowledge makes it easier to troubleshoot
in the event of a problem and easier to main-
tain the service overall.
The first order of business is to understand
the protocol at work: IPSec. In a remote-
access configuration, IPSec is generally config-
ured to allow Layer Two Tunneling Protocol
(L2TP) connections from Windows 2000 or
XP VPN clients. (These operating systems
come bundled with IPSec-enabled L2TP
clients. For Cisco PIX installations, Cisco pro-
vides a VPN client that will allow other operat-
ing systems, such as Windows 95, 98, and NT,
to access the VPN services as well.)
IPSec operates in two steps. Using either
manually configured keys or Internet Key
Exchange (IKE)—which I will discuss next—
step one handles the negotiation of security
information between client and host. Once the
negotiation is complete, step two uses this nego-
tiated security information to begin passing data.
The second step is the negotiation of param-
eters between client and host. You can negotiate
the parameters manually or via IKE. IKE is an
automated method that allows for additional
features such as dynamic authentication. Under
IKE, keys can change in midsession.
IKE configuration uses five parameters to
define its policy:
X The encryption algorithm IKE will use
X The hash algorithm it will use
X The method of authentication it will use to
identify IPSec peers
X The group identifier, which IKE uses to
derive a secret password without having to
transmit that secret password over the
connection
X The number of seconds for which the secu-
rity association will be valid (with a default
of 24 hours)
Solutions 207
 Now that we’ve covered the basics, you’re
ready to set up client VPN services on your PIX.
Setting it up
For the purposes of this article, I’ll show you
the configuration from a PIX running version
5.1(2) of the PIX firewall management soft-
ware. I’ve also tested this configuration on a
new PIX 501 firewall running version 6.1(2) of
the software.
For this configuration, I’ll use the PIX
command line. Note that I’m not including
my entire PIX configuration but only those
commands required to get the VPN services
up and running. The only parameter I’ve
changed is keyname. Other than that, this is a
complete configuration for a fully functional
Cisco PIX-based VPN, which allows remote
clients to access services on the network
behind the firewall.
X ip local pool vpnpool 172.16.2.1-
172.16.2.255—This command creates a local
pool of addresses named vpnpool. These
addresses will be used for VPN clients.
X sysopt connection permit-ipsec—This
command changes the system options to
allow IPSec connections.
X sysopt ipsec pl-compatible—This com-
mand allows IPSec to bypass the firewall’s
NAT settings, and it also allows incoming
IPSec packets to terminate at the outside
interface.
X crypto ipsec transform-set myset esp-
des esp-md5-hmac—This command cre-
ates a transform set named myset. A
transform set specifies one or both of the
IPSec security protocols, as well as the algo-
rithm to use for them. My configuration
uses esp-des, which is a 56-bit encrypted
security protocol, and esp-md5-hmac,
which uses the MD5 hashing scheme for
encoding. These transform sets come into
play during client negotiation to determine
what protocol the PIX will use to protect
the VPN traffic.
X crypto dynamic-map cisco 1 set trans-
form-set myset—This command allows
you to support secure connections with
208 Administrator’s Guide to VPN and Remote Access, Second Edition
unknown clients, which is essential if you
are to support remote users. One of the pri-
mary functions of this command is to spec-
ify a dynamic map named Cisco, a sequence
number of 1, followed by the only required
parameter, set transform-set, which defines the
transform set to be used with this mapping.
X crypto map dyn-map 20 ipsec-isakmp
dynamic cisco—This command specifies a
map name of dyn-map, followed by a
sequence number of 20. The ipsec-isakmp
parameter indicates that the PIX will use
IKE to establish IPSec security associations.
The dynamic keyword tells the PIX to add
the dynamic crypto map set to a static
crypto map. Cisco is the name of this map.
X crypto map dyn-map interface outside—
This command tells the PIX which interface
to use for the previous command.
X isakmp enable outside—This command
tells the PIX which interface to use to enable
isakmp negotiation for IPSec. ISAKMP
stands for Internet Security Association and
Key Management Protocol and is one of the
security protocols IKE supports. (The other
two are Oakley and Skeme.)
X isakmp key keyname address 0.0.0.0
netmask 0.0.0.0—This command config-
ures the PIX to use a wildcard, shared key.
The keyname defines the authentication key
to share between the PIX firewall and the
VPN client. The 0.0.0.0 for the IP address
and the netmask specify the wildcard nature
of the command.
X isakmp identity hostname—This com-
mand sets the isakmp identity for the firewall.
X isakmp client configuration address-
pool local vpnpool outside—This com-
mand tells the PIX which previously
configured pool of addresses to use and
which interface will be using them. With the
ip local pool vpnpool statement, we previously
configured the vpnpool address pool to range
from 172.16.2.1 to 172.16.1.255.
X isakmp policy 10 authentication pre-
share—This command assigns a priority
of 10 to the policy statements, using the
 isakmp policy command. You can set the
authentication subcommand to either
preshare or rsa-sig. If defined as preshare,
the PIX is to use preshared keys; rsa-sig tells
the PIX to use RSA signatures.
X isakmp policy 10 encryption des—This
command tells the PIX to use 56-bit DES
encryption. The other option is to specify
3des, which will enable the PIX to use triple
DES encryption for the IKE policy instead.
X isakmp policy 10 hash md5—This com-
mand specifies the hashing algorithm the
PIX will use, which can be either md5 or sha.
X isakmp policy 10 group 1—This com-
mand (group 1) tells the PIX to use the 768-
bit Diffie-Hellman in the IKE policy. The
other option is to specify group 2, which
enables the 1,024-bit Diffie-Hellman tech-
nique. Diffie-Hellman is the first published
technique for public key cryptography and
asymmetric encryption and is based on the
difficulty of calculating logarithmic values.
X isakmp policy 10 lifetime 1000—This
command specifies how long each security
association should stay valid (ranging in
value from 120 seconds to 84,600 seconds).
The client
Once you’ve set up the VPN services on the
server, you need to allow clients to connect.
Cisco provides a VPN client for just this
purpose.
The current version of the Cisco VPN client
is 3.5.1 and is available for download from the
Cisco Web site (http://www.cisco.com/),
assuming you have a current Cisco Service
Contract (http://www.cisco.com/register/).
If you have a service contract, you just need to
log in to the site to download the software. If
you don’t, you’ll need to purchase the client or
use the version that came with your PIX.
To install the client, double-click on the
installation file. If you install the client onto a
Windows XP workstation, you’ll get a message
indicating that you should change your driver
signing settings to avoid error messages during
the installation. I don’t recommend doing this;
rather, deal with the error messages by choos-
ing Continue Anyway when the messages
come up. The messages simply inform you
that Microsoft has not verified the drivers. The
actual software installation is straightforward
and asks you the standard Microsoft installa-
tion questions.
After the installation is complete, your sys-
tem may ask to reboot. Once it does so, run
the client by choosing Start | Programs |
Cisco Systems VPN Client Files | VPN Dialer.
This application will allow you to set up a con-
nection to your host VPN server if you pro-
vide it with the information requested.
Use careful planning and
strong keys
A VPN is a powerful tool. With a VPN, an
organization can provide secure remote access
to almost any internal equipment. As we’ve
shown in this article, you can configure your
existing Cisco PIX to provide these services,
but you’ll need to do your homework to get
the lay of the land before you start. Any keys
you use should be strong enough to withstand
brute-force attacks. When configuring a client
VPN system, you’ll need to allow for the pos-
sibility of unknown clients in the configura-
tion, as well as provide potential client users
with an appropriate client, such as the one pro-
vided by Cisco for use with the PIX.
Solutions 209
 Eight commonly overlooked troubleshooting
tips for the Cisco PIX VPN
Jun 14, 2002
By Scott Lowe, MCSE
T
he Cisco PIX stands on the market as a
high-end appliance that offers a num-
ber of solutions. One such solution is
that of remote access via VPN. Because of the
scale of the PIX appliance, troubleshooting
such a VPN can be very difficult.
In this article, I will identify eight of the
most commonly overlooked problems with
your PIX-based VPN and suggest some possi-
ble solutions for each.
An edge router is in the way
Many organizations use routers with access
control lists on the Internet connection to pro-
vide an added layer of security to the internal
network. Unfortunately, that added level of
security could also mean that your new PIX
VPN doesn’t work as it is supposed to. To make
it work effectively, you must make sure that cer-
tain types of traffic can get past the edge router
to their destination: your PIX firewall. You must
allow the following traffic past the router:
X UDP port 500 is the port that IPSec Inter-
net Key Exchange (IKE) uses to negotiate a
connection. IKE allows you to decide
whether or not to use automatic key man-
agement via Internet Security Association
and Key Management Protocol (ISAKMP)
or manual configuration to set up a VPN.
X TCP and UDP port 50 passes Encapsulating
Security Payload (ESP) traffic, which pro-
vides encryption and optional authentication.
X TCP and UDP port 51 passes Authentication
Header (AH) traffic, which provides authenti-
cation services for the VPN connection.
If you need to make these modifications on
your edge router, refer to your router documen-
tation. Note that ESP and AH require both
TCP and UDP ports for proper operation.
NAT at the client
Suppose you’ve completely configured your
PIX for VPN capability, and many of your
users are able to connect to the services and
210 Administrator’s Guide to VPN and Remote Access, Second Edition
make use of network resources, but others
aren’t. Upon further investigation, you find
that the users who are able to connect are
being assigned routable addresses from their
Internet service providers, but those who can’t
connect are being assigned RFC 1918
addresses. (RFC addresses are those in the
10.x.x.x, 172.16.x.x, and 192.168.x.x ranges.)
Therein lies the problem. At present, the
Cisco PIX code, which is not IOS, doesn’t sup-
port NAT with IPSec, which is used by the
PIX VPN services. The newest Cisco VPN
client has support for this feature, so when
Cisco releases an update to the Cisco PIX
code, this problem should be fixed. Unfortu-
nately, that’s the only answer at present.
Until Cisco corrects this problem, you can
make use of Point-to-Point Tunneling Proto-
col (PPTP) connections to a server set up to
accept PPTP connections behind your firewall.
One method of achieving a PPTP connection
is to use the Windows 2000 Server Remote
Access Services. Bear in mind that PPTP is not
as secure at L2TP/IPSec.
UDP client problem
Another problem that can occur at the client
side is when the client is behind a firewall and
attempting to use Edge Services Processor (ESP)
over UDP for negotiation. The Cisco VPN client
does have a check box to allow UDP for ESP,
but the PIX ignores it because neither the PIX
nor Cisco’s IOS support UDP pass-through,
which is a requirement for this scenario. This can
even occur with firewalls that don’t use NAT. As
with NAT at the client, one possible workaround
is to use PPTP instead of ESP over UDP,
which will provide the required connectivity.
The UDP check box is present in the cur-
rent version of the Cisco VPN client even
though the PIX doesn’t support this feature.
This is because the Cisco VPN Concentrator
product does support ESP/UDP connections
and both products use the same client. So
some features for one won’t work in the other.
Cisco expects to support ESP/UDP connec-
tions in IOS 12.2.14, but currently there are no
concrete plans to support it in the PIX.
Client firewalls
Many users have installed programs such as
BlackICE or Norton Internet Security on their
home computers. While these programs pro-
vide great security, they can also interfere when
trying to connect via a VPN. Before disabling
this security software, test your VPN connec-
tivity. If it works, leave the software enabled. If
it doesn’t, disable the software and try to con-
nect to the VPN. If it works, you’ll need to dis-
able the software while using the VPN.
Remote clients are unable to
browse the network
Suppose you’ve installed the PIX client soft-
ware on a remote system to allow your remote
clients access to specific network resources.
These users may also need to browse the net-
work to find the resources they need. How-
ever, they are unable to browse the network.
Before you even look at the firewall config-
uration, make sure you’ve installed the Client
for Microsoft Networks on the remote system.
Then, look at your firewall and make sure
you’ve allowed the WINS ports—ports 137 to
139—through your firewall. You can verify
this with the following commands:
access-list vpnclients permit ip
172.16.2.0 255.255.255.0 any any
access-group vpnclients in
interface outside
This creates an access list that allows all IP
traffic from the 172.16.2.0 network and binds
the access-list to the outside interface. You can
also open specific ports on a service-by-service
basis for additional security.
Clients connect but can’t ping
network resources
Suppose you’ve set up your PIX VPN and are
attempting to establish connectivity to your
internal network. You’re able to establish a con-
nection to the PIX and even get an IP address
Listing A
access-list outbound permit icmp 172.16.1.0 255.255.255.0 172.16.2.0 255.255.255.0
from the pool of addresses you’ve set up for
VPN use on the PIX. However, you can’t ping
any devices on your internal network.
One possible cause could be that your IP
address local pool statement on your PIX con-
tains addresses from your internal network. The
PIX interprets this mistake as an attempt to
spoof addresses. Also, to ping through the PIX,
you must enable Internet Control Message Pro-
tocol (ICMP) packets through the firewall. The
example below shows you two IP address
pools: the internal LAN pool and the pool of
addresses used to assign IP addresses to incom-
ing clients. Listing A shows a sample access list
statement that will accomplish the above.
X Internal LAN pool—Internal network IP
addresses 172.16.1.X mask 255.255.255.0
X Incoming client IP address pool—VPN
client subnet 172.16.2.X mask 255.255.255.0
Changes to the crypto map
statements result in error
messages
The crypto map statements in your PIX firewall
configuration set up your IPSec parameters,
including key exchange. If you’ve set up a new
VPN connection to either support a different
set of users or a new site-to-site VPN, and you
receive the error message IPSEC(ipsec_encap):
Crypto Map Check Deny, you may not have reap-
plied the crypto commands to the applicable
interface. Each time you either modify an existing
crypto map statement or add an additional one,
the mapping must be reapplied using the com-
mand crypto map mapname interface outside (where
mapname is the actual name of the defined map).
Error messages?
The PIX error logging capability is invaluable
for troubleshooting problems, especially VPN
problems. However, this debugging mode
should be used only when you encounter a
problem, because it places an additional load on
the processor and can disrupt its normal opera-
tion. It’s best to limit what you debug and try to
do it at a period of low activity, if possible.
Solutions 211
 The debug command syntax varies depend-
ing on what you’re debugging. Table A shows
the available debugging commands related to
the VPN on the PIX. These are updated with
new releases of the Cisco PIX operating sys-
tem. The PIX also provides the ability to view
the information related to many of these areas.
I have listed both commands in Figure A.
By reviewing these commands, you can see
that the PIX provides a number of ways to moni-
tor VPN services. The commands from Figure A
are also critical in the troubleshooting of the PIX.
When you use a debug command, you’ll see
the output on the console or on a syslog
server—a UNIX server set up to listen to
incoming syslog messages to UDP port 514—
depending on how your PIX is configured.
Below, you’ll see a sample output from a PIX
VPN server. This output indicates that there
was an error at some point in the configuration
related to the certificate authority.
CI thread sleeps!
Crypto CA thread wakes up!
CRYPTO_PKI: http connection opened
msgsym(GETCARACERT, CRYPTO)!
%Error in connection to Certificate
Authority: status = FAIL
CRYPTO_PKI: status = 266: failed to
verify
CRYPTO_PKI: transaction GetCACert
completed
Crypto CA thread sleeps!
If all else fails…
Troubleshooting the PIX VPN services can be
troublesome at times, but with some of these
tips and the use of the debug command, any
problem can be resolved. If you run across a
particularly perplexing problem, you may want
to consider turning to the Cisco Technical
Assistance Center for more help, or to their
discussion forums (http://forum.cisco.com/
eforum/servlet/NetProf?page=main), which
I find particularly helpful.

Table A: Each debugging command may not have an equivalent show command.
Debugging command Show command Description
debug crypto ca show crypt ca cert Displays debug messages exchanged with the Certificate Authority.
debug crypto engine Displays debug messages about crypto engines, which are
responsible for performing encryption and decryption.
debug crypto ipsec show crypto ipsec sa Displays IPSec-related events. (The show command will show
the current settings used by security associations.)
debug crypto isakmp show crypto isakmp sa Displays messages about IKE-related events. (The show version
will show you the security associations related to IKE.)
debug ppp error Displays protocol errors and error statistics associated with PPP
connection negotiation and operation.
debug ppp io Displays the packet information for the PPTP PPP virtual
interface.
debug ppp uauth show uauth Displays the PPTP PPP virtual interface AAA user authentication
debugging messages. (The show uauth command displays current
user authentication information.)
debug vpdn error Displays errors that prevent a PPP tunnel from being established
or errors that cause an established tunnel to be closed.
debug vpdn event Displays messages about events that are part of normal PPP
tunnel establishment or shutdown.
debug vpdn packet Displays L2TP errors and events that are a part of normal tunnel
establishment or shutdown for virtual private dialup networks
(VPDNs).
show vpdn pppinterface Displays PPP interface status and statistics.
show vpdn session Displays active L2TP/L2F sessions.
show vpdn tunnel Displays information about current L2TP/L2F tunnels in VPDN.

212 Administrator’s Guide to VPN and Remote Access, Second Edition

SonicWALL PRO-VX provides fast, simple
firewall and VPN solution
Apr 15, 2002
By Robert McIntire
A
recent network project that I worked
on combined several elements that
made it worthy of documenting. The
client already had in place a rather elegant
VPN solution for LAN-to-LAN connectivity,
which was designed by their ISP. But this was
only a starting point. The next phase of the
project was to implement a firewall/VPN solu-
tion for network security and remote user
access. The device chosen by the client was the
SonicWALL PRO-VX firewall VPN appliance.
It provided for firewall protection and VPN
connectivity, and among other things, had a
certain level of ease in the management cate-
gory through a Web-based configuration util-
ity. The SonicWALL solution is ICSA-certified,
meaning it would provide all the protection the
company would need for its private network.
In this article, I will tell you how we set up
the VPN and firewall quickly and easily.
Firewall features
The designers of the SonicWALL PRO-VX
provided for flexibility in configuration of the
firewall and its connectivity options. With only
three Ethernet interfaces—LAN, WAN, and
DMZ—and a GUI interface for software con-
figuration, setting up the SonicWALL PRO-
VX is quite simple. The SonicWALL even
includes default firewall rules that allow you to
get started immediately.
SonicWALL has simplified the SonicWALL
PRO-VX so that:
X All users on the internal LAN are allowed
access to the external network via the WAN
interface.
X All users have access to the DMZ.
X All users automatically have access to the
VPN when their accounts are created.
The designers have gone out of their way to
make installing and managing this box as sim-
ple as possible. It’s a good thing that ease of
configuration doesn’t equate with ease of com-
promising. In fact, with the SonicWALL, ease
of configuration is inversely related to its level
of security.
The SonicWALL has several varied and
sophisticated features to provide advanced
protection for networks. By default, it blocks
NetBIOS broadcasts, which is essential in a
Windows-centric desktop world. Some of the
other features provide for distributed denial of
service (DDoS) protection, content filtering,
antispoofing, and secure remote management.
Most features can be easily configured through
tabbed menus on the main configuration page.
Network design options
In most networks, it is simple to set up the
SonicWALL. With Ethernet interfaces, you
simply insert the firewall between your Inter-
net router and internal switch, and change the
default gateway at the workstations to point to
the LAN interface of the firewall.
However, our design was a bit more com-
plex because of the client’s existing VPN,
which had been customized by the ISP. In this
network, the data stream coming down the T1
to the central office router was twofold. The
T1 serial interface was logically split at the
Cisco router into two subinterfaces, with one
interface carrying Internet traffic and the other
interface carrying interoffice traffic from
remote LANs.
Of course, you would normally expect any
traffic entering the WAN interface of the fire-
wall to be external, rather than a mix of exter-
nal and private LAN traffic. It was our good
fortune to work with a device that gave us the
options necessary to successfully implement
such a design. This was possible in part,
because you can configure the SonicWALL to
perform NAT or not to perform it. If you use
NAT, the WAN interface of the SonicWALL is
publicly addressed and can be hit directly from
Solutions 213
 the Internet. If you don’t use NAT, the WAN
interface simply passes outbound traffic to the
Internet router, which then handles NAT. Keep
in mind that our network design is a little out of
the ordinary, since we have private LANs on
both sides of the firewall. Some of the steps
we took aren’t usually recommended by Son-
icWALL or most network administrators, but it
helps to know that they are available for use in
demanding environments.
Router configured for NAT
In this design scenario, we left the Cisco router
configured for NAT, as it had been previously.
We physically connected the firewall in-line
between the WAN and LAN with the WAN
port connected to the routers’ inside Ethernet
port and the LAN port to the local switch. In
this case, we assigned the 192.168.1.0 address
from the LAN subnet to the SonicWALL
LAN port and the router Ethernet port. How-
ever, this poses a problem, because the WAN
port doesn’t get a public IP address unless you
want the SonicWALL to handle the NAT
function.
With no public address on the WAN inter-
face, you might wonder how the VPN clients
connect to the SonicWALL. To make this hap-
pen, we used a separate, private subnet address
allocated by the ISP. This address was adver-
tised on the Internet using a static NAT map
statement on our Internet router, which
mapped all IP traffic from this address to the
LAN address of the firewall. For security pur-
poses, we applied an inbound Access Control
List (ACL) to the outside interface of the
router to allow only IPSec tunnel traffic to this
VPN-specific address. The NAT and ACL
statements are shown in Listing A.
VPN configuration on the firewall
The SonicWALL automatically inserted new
access rules to allow IPSec traffic through.
This was a nice touch that really simplified the
configuration. Other static mappings were
inserted at the router to map mail and Web
traffic from the router’s T1 interface to the
appropriate servers on the internal LAN. Once
we had the ISP insert MX and WWW records
for the domain, we were up and running. The
VPN clients could then access the Sonic-
WALL, because its address, 192.168.1.5, had
been mapped to a legal IP (200.200.210.2) on
the Cisco router. At this point, we had one
public IP address assigned to the external
router interface for connectivity to the Internet
and another public IP address dedicated solely
to remote VPN client access via redirection.
A fast, simple solution
Suffice it to say that this was the quick and
easy way to get the client up and running,
because it required the least amount of change
to the existing network configuration. But
sometimes, quick and easy solutions are a con-
sultant’s best friend. I know that if I’m ever in
need of another fast VPN fix, I’ll be heading
right back to the SonicWALL.

Listing A: NAT and ACL statements

Router(config)# ip nat inside source static 192.168.1.5 200.200.210.2
Router(config)# access-list 101 permit 50 any host 200.200.210.2
Router(config)# access-list 101 permit 51 any host 200.200.210.2
Router(config)# access-list 101 permit udp any host 200.200.210.2 eq 500

214 Administrator’s Guide to VPN and Remote Access, Second Edition

The D-Link DI-704 cable/DSL gateway
Jan 18, 2001
By Vincent Danen
T The network
he Linux operating system has long
been used as a firewall system because
it has the flexibility and capabilities to
perform both excellent firewalling and routing.
With Linux, you can transform your old 486
computer into a powerful gateway computer,
protecting your internal network from outside
intrusion and providing IP masquerading and
routing capabilities that will put your entire
LAN on the Internet with a single IP address.
Linux does this efficiently and well with low-
end hardware. All you really need is a small
hard drive, two network cards, and a 486
machine with about 8 MB of RAM. You can
even get away with not having a hard drive and
using one of the many Linux-based floppy dis-
tributions available, such as the Linux Router
Project. The cost for all of this? Realistically,
you should spend under $100. And for that,
you have an efficient firewall to protect your
sensitive LAN.
There has been a surge of firewall appliances
aimed at home users and small businesses.
While powerful routers such as those from
Cisco have always been available, they are quite
expensive and not at all ideal for the home user.
Recently, many companies, such as 3com,
Linksys, and D-Link have released a number of
firewall/gateway appliances for home users.
The rise of these appliances is due to the
greater availability of high-speed Internet access
through ADSL and cable access, which is cheap
enough for the home end user to afford.
Many people have wondered about these
products and where they might fit into their
network. You may already have a Linux
machine acting as a dedicated gateway for your
firewall and might be wondering why an appli-
ance such as this would be of any interest,
much less of benefit, to you.
I recently purchased a D-Link DI-704
cable/DSL gateway, and I’ll explain the bene-
fits of such an item. I’ll also give you an
overview of the features and configuration of
the appliance, as well as the speed with which I
installed it.
Let me first describe the network into which I
needed to insert this product. Because I run a
consulting business that provides domain-
hosting solutions, I had a few computers to
protect. My network includes three server
machines that need to be accessible by the
outside world. All three act primarily as Web
servers and e-mail servers, and they provide a
number of other services to the general public.
Two of those machines are DNS servers as
well. All three computers run Linux-Mandrake.
On the inside, I have two desktop machines
and one laptop. One of the desktop machines
runs Windows 98, while the other two
machines run Linux-Mandrake. Finally, I have
one internal print server that also runs Linux-
Mandrake. So in my scenario, I have three
computers that must be accessible by the pub-
lic and four that should not be. It’s not a large
network, but it’s larger than that of the average
home user and a little more complex.
Until now, I have relied on separate firewalls
for each machine, located on the server. The
Windows 98 machine used a native firewall
product, so each computer had a firewall
installed, but on the machine itself. This was
not an ideal situation, but it has worked for me
so far. However, being ever security-conscious,
I decided to take steps to further protect my
LAN. The three servers are quite secure
despite the lack of a removed firewall. Because
of this, I decided to set up the three servers in
a DMZ, or Demilitarized Zone, and protect
the rest of the LAN with the D-Link gateway.
The D-Link DI-704
The D-Link DI-704 is a switching gateway that
provides four 10/100 Ethernet ports. It can
handle cable and DSL modems via an RJ45
port at the back, or it can connect to a PSTN/
ISDN network via the COM port, also at the
back of the device. Here’s a brief rundown of
the features as described by D-Link:
X Protection of your computer from intruders
X Shared cable/DSL modem
Solutions 215
 X Firewall
X Easy-to-set-up Web-based configuration
X Broadband router
X Four-port Ethernet switch
X External modem port
X Web-based management
X Advanced security features
Quite a nice little feature list. The only
annoying thing I found about this product was
that the four Ethernet ports were located at
the front of the box instead of at the back.
Because of this, I could not easily hide my net-
work cables, but this is more of an aesthetic
problem than anything else.
The cost of the D-Link DI-704 was $230
Canadian, and the D-Link Web site sells it for
$149 U.S. It also sells a single-port edition,
called the D-Link DI-701, for $99 U.S. The
two devices are relatively similar in the look
and size of the appliance itself and the num-
ber of Ethernet ports for the internal LAN.
Hardware installation
Previously, I had my ADSL modem connected
to a D-Link DSS-8+ eight-port 10/100 switch.
My computers were then plugged directly into
the switch and shared the Internet directly. My
ISP provides me with seven static IP
addresses, so each machine had its own IP
address and was reachable through the Inter-
net. I don’t mind saying that this setup both-
ered me. Not so much for security reasons,
although that was definitely a factor, but
because I needed those IP addresses for the
other machines so that I could have more than
one SSL-enabled Web site available, since each
SSL-enabled Web site requires its own IP
address. Using this router, I could free up three
of those IP addresses for that purpose.
This time, I connected my ADSL modem
to a D-Link DE-809TC 10-MB hub, an older
hub I used when my network was only 10 MB.
I connected the three servers and the DI-704
router into the hub, where I had my DMZ. I
connected my DSS-8+ 10/100 switch into the
DI-704 router, and I connected the computers
belonging to my internal LAN into the switch.
Each of the three servers retained their old
216 Administrator’s Guide to VPN and Remote Access, Second Edition
static IP address, and I assigned another static
IP address to the router.
I chose to use the older 10-MB hub for the
DMZ instead of purchasing another 10/100
switch for a simple reason: The uplink port on
the DI-704 is only 10 MB because you will
never find (yet) a residential cable or DSL
modem that will give you greater than a 10-MB
Ethernet connection. Because of this, the
value of a 10/100 switch is negligible, as only
the three machines would be able to connect
to each other at 100 MB. Since the three
servers do not talk to each other very often,
having a 100-MB connection between them
would provide no greater performance than a
10-MB connection. And since my local net-
work would be able to connect to those com-
puters with only a 10-MB connection anyway,
due to the limitation of the uplink port, I
decided to reuse some old hardware and save
myself some money.
At this point, the network was connected
the way I wanted it. The three servers had an
open road to the Internet, so to speak, and
were quickly up and running. The time it took
was the time I spent plugging everything into
the various hubs, so the downtime on those
servers was less than five minutes.
Configuring the DI-704
Next I had to reconfigure my TCP/IP settings
on the local network. The D-Link gateway
gives you two choices: You can assign each
machine a static IP address, or you can allow
the gateway to act as a DHCP server as well.
Since I had only four computers behind the
firewall, and since I would be sharing printers
and hard drives among them, I decided to
assign each computer a static IP address.
First, however, I needed to configure the
gateway. I decided to use the Windows machine
to do this, so I went into the TCP/IP properties
and deleted the existing settings, which included
the static IP address, the subnet mask, the gate-
way address, and the DNS settings. I had to
reboot the computer in order for the settings to
take effect, but once it was back up, I could fire
up Internet Explorer and point it to the default
IP address of the router, which is 192.168.0.1. It
was slow to load, but once it did load, it greeted
me with a nice Web page and asked for an configure the IP address on each computer
administrator password. After entering the behind the firewall. If you enable the DHCP
default password, I was at the main configura- server, you can define the starting and ending
tion screen. addresses for the IP pool. By default, these
The first screen you will see is the informa- start at 100 and end at 199. You can also define
tion screen, which shows you the internal and a domain name for the LAN. This means that
external IP addresses of the gateway, as well as if you chose a LAN IP address of 192.168.5.1
the firmware revision number and the MAC and you kept the default settings, your internal
address. Click the Tools link, so you can LAN would be assigned an IP address between
change the default administrator password. 192.168.5.100 and 192.168.5.199. With this
Make sure it is something good and something default setting, you can have 100 computers
you will remember. The steps to reset the pass- running behind the gateway. The maximum
word are annoying at number of comput-
best and involve ers that can be sit-
pulling out a null The DI-704 is more than just a simple ting behind the
modem cable and fir- gateway and firewall product. firewall is 253, and
ing up a terminal to use them all you
dialer. Once you’ve would set your start-
changed the password, you can begin to con- ing range at 2 and your ending range at 254.
figure the rest of the appliance. You cannot use 1 because that should be the IP
Now click the Setup link, where you must address for the gateway, and you cannot use
indicate whether you have a dynamic or static 255 because that is the broadcast address for
IP address for the external connection. If you the LAN. But you can freely use any IP address
use DHCP with your provider, which most in between, up to that maximum of 253
residential cable and DSL services do, you’ll addresses.
want to leave it at the default. In my case, I This high number of available addresses
receive static IP addresses from my ISP, so I means that you can use the DI-704 for very
changed the WAN type to static IP. I also large networks if you wish. Because the gate-
modified the LAN IP address to suit my needs, way has four 10/100 switching ports, you can
changing it from 192.168.0.1 to 192.168.5.1. connect any number of 10/100 switches
There is not much of a difference, but I try to below it in such a way that you can easily have
avoid the defaults as much as possible. You can a full network of 253 computers connecting to
also use other private network classes here, each other at 100 MB. This makes the DI-704
including 10.x.x.x addresses. I could have just quite scalable and useful for many networks,
as easily made the IP address 10.5.100.1 if I ranging from small to large.
had wanted to. On this screen, you also define At this point, you should save all the
the WAN subnet mask, the WAN gateway, and changes and return to the Tools settings. Click
the primary and secondary DNS servers, pro- the Reboot button to reboot the gateway and
viding you use a static IP address. If you have commit all your changes permanently. This is
a dynamic IP address, the DHCP client in the necessary to make further use of the gateway
gateway will automatically determine this with your settings. Once you’ve rebooted the
information from the DHCP server of your gateway, close your browser.
ISP. Once you’ve finished with these settings,
commit your changes. Configuring the operating
Next, click the DHCP link, where you systems
determine whether the DI-704 will also act as Since I had done all the work using Windows, I
a DHCP server for the internal LAN. If you decided to configure Windows first. Opening
enable DHCP, you needn’t worry about assign- the TCP/IP properties, I gave Windows a new
ing static IP addresses to each computer on static IP address. In this case, I gave it
the LAN, but if you disable it, you’ll need to 192.168.5.11 with a subnet mask of

Solutions 217
 255.255.255.0. The IP address may differ in
your settings, but the subnet mask will remain
the same. If you enabled the DHCP server on
the DI-704, tell Windows to obtain the IP
address automatically. If you did not, go to the
Gateway tab and enter the IP address of the
gateway; in my case, it was 192.168.5.1. Finally,
go to the DNS tab and enter the DNS servers
you wish to use. Again, if you have the gate-
way serving the IP addresses, you needn’t
change anything here.
Finally, reboot Windows once again. When it
comes back up, you should be able to connect
to the Internet without a problem.
Linux is just as simple to reconfigure. On
both machines, I used the linuxconf tool and
changed the previous static IP addresses to
192.168.5.x and changed the subnet mask to
255.255.255.0. These settings are available
under Networking | Host Name And IP Net-
work Devices. Then go into Networking |
Routing And Gateways and enter your new
gateway address: 192.168.5.1. Our DNS infor-
mation hadn’t changed, so we left that alone.
Again, if you have the DI-704 serving the IP
addresses, you’ll need to change the manual IP
address to a DHCP address and leave the IP
address, subnet, gateway, and DNS informa-
tion blank.
Once you exit linuxconf, it will ask you if you
wish to perform the actions based on your
changes. If you tell linuxconf to activate the
changes, when you return to the command
line, you should be able to ping an outside
machine. You may also want to issue
/sbin/ifconfig just to ensure that your settings
are correct. I’ve found that some versions of
linuxconf do not properly reset the settings
when you tell it to activate the changes.
And that’s it! You should now be able to
connect to the outside world through your DI-
704 gateway. The only steps left are to change
IP addresses anywhere you may have previ-
ously defined them. For example, you might
want to edit your /etc/smb.conf file if you use
Samba, or your /etc/hosts file. If you run
Apache and plan to use it for an intranet Web
server, you’ll need to change your IP address
there as well. You may also want to rewrite or
remove some of your ipchains rules. I found
218 Administrator’s Guide to VPN and Remote Access, Second Edition
that on one machine I could not connect to the
Internet because my ipchains rules were depend-
ent on the old IP address. If you find that you
cannot connect to any sites on the Internet—
or even to your LAN or the gateway—try issu-
ing ipchains –F to flush all of your ipchains rules,
and you should be up and running.
Advanced DI-704 configuration
Now you may want to set up some of the
advanced configuration options. Remember,
the DI-704 is more than just a simple gateway
and firewall product. You’ll need to connect to
the local IP address of the gateway again (if
you changed it, you’ll need to connect to the
new address). In my case, I now must connect
to http://192.168.5.1/. Once you do this and
enter your new administrator password, click
the Advanced link.
The first items you’ll see are the Virtual
Server settings. Here you can forward certain
ports to various machines; you can specify up
to 10 ports to forward. You can use the con-
venient Well-Known Services button to inject
certain ports into the configuration, such as
FTP, HTTP, or DNS. This allows your
machines behind the firewall to be reached via
certain definable ports. In my case, I forwarded
port 22 to my primary Linux workstation to
allow SSH access into the LAN. I also for-
warded port 113 to the Linux machine for
AUTH connections, and I forwarded port 21
for FTP to the same machine. Note that you
cannot have the same port forwarded to differ-
ent machines since you can specify only one IP
address per port.
If you click the Special AP link, you’ll be
able to define special applications, allowing you
to use special programs such as video confer-
encing, Internet games, and so on that require
multiple ports. You can use the special Popular
Applications pull-down list to copy a series of
ports to one of the five definable IDs, or you
can specify your own port ranges. You can also
use it to open up a series of ports to a particu-
lar machine. Please note, however, that these
ports will be available and open to all machines
behind the firewall even though only one com-
puter at a time can use the application. For
instance, you can have only one machine doing
video conferencing at a time, but if you define
the application here, any computer can make
use of it, so it isn’t as restricted as with the Vir-
tual Server settings.
Under the Access Control link, you can
define access control for the internal network
making outbound connections. With this, you
can restrict certain groups of IP addresses from
being able to access certain outbound ports.
You could restrict all machines behind the fire-
wall or just a specific group from using applica-
tions such as telnet and FTP, if you so desire.
Finally, under the Misc Settings link, you
can define two important settings. The first is
the address of your DMZ host. If you want,
you could connect your cable or DSL modem
directly to the router and have one machine
behind the firewall act as your Web server or
e-mail server. Here you would enter the local
IP address for that machine, and the router
would allow all connections to any port on that
machine. This capability is useful only if you
have one server that needs open access to the
Internet, which is what the DMZ allows. In my
case, having three servers, it isn’t very useful,
which is why I opted to use the 10-MB hub
between the ADSL modem and the DI-704 to
establish my gateway.
The final option on this page is the Remote
Administrator Host. This option allows you
to configure the gateway from a remote IP
address. Unless you have a pressing need to
allow this, I strongly suggest you leave this set-
ting disabled. Enabling this setting allows a
point of entry into your gateway security.
When this is disabled, the Web server embed-
ded in the application listens to port 80 on the
internal IP address. When you enable it, it will
listen to port 88 on both the internal and
external IP addresses but will allow connec-
tions only from the specified host on the exter-
nal IP address. If you leave the IP address set
to 0.0.0.0, then any host on the Internet can
connect to the server on port 88 to configure
the gateway, providing they know the adminis-
trator password.
Conclusion
The D-Link DI-704 is, in my eyes, a gem. As
I’ve pointed out in this article, it’s slightly more
expensive than some other similar solutions,
but the fact that it provides four switching
10/100 ports is worth the cost if performance
is important. Other gateway appliances that
cost less act as a simple hub, without the bene-
fit of switching ports. And while it may cost
more than a Linux-based alternative on old
hardware, the benefit is worth the additional
expense. With this simple appliance, you don’t
have to deal with a complete operating system
if anything does go wrong. Also, in terms of
long-term costs, you’ll save on energy con-
sumption since the power usage of this appli-
ance is far less than the power requirements of
a computer.
All in all, this is a wonderful piece of hard-
ware. The total time it took me to configure
my LAN was perhaps half an hour. Indeed, it
took me longer to write about it than it did to
configure it.
One final piece of advice: Once you have
everything configured the way you want it,
print out all your settings and retain a hard
copy. At this time, there’s no firmware upgrade
for the DI-704, but there is for the DI-701.
Some ill-behaved appliances may wipe out
your settings when you attempt to upgrade the
firmware. A quick hard copy “backup” of your
settings will save you some time in the unlikely
event that this happens to you. One product
that apparently suffers from this problem is
the Linksys cable/DSL gateway product.
For more information on the D-Link DI-704,
read about it on the D-Link Web page at
www.dlink.com/products/broadband/di704,
and if you are interested in the one-port model,
the DI-701, you can read about it on its own
home page on the D-Link site at www.dlink.
com/products/broadband/di701.
Solutions 219
 Who said you can’t afford your own router?
Nov 3, 2000
By Erik Eckel, Network+, MCP+I, MCSE
H
ere’s a cool tool you might not be
able to do without. Imagine your
own LAN feeding off a single device
providing router, firewall, gateway, and switch
services. Then, imagine that device in use on
your home LAN, since it costs less than $200.
I know it sounds too good to be true, but
I’ve tested it, and it works. Beautifully, too, I
might add.
If you’re preparing for certification exams
or wanting to test network and server configu-
rations from the comfort of your own home,
Linksys makes a line of routers you need to
check out.
The official scoop
Officially, the Linksys four-in-one devices
are marketed as Instant Broadband EtherFast
Cable/DSL Routers. They are available in
single-port, four-port, and eight-port versions.
Figure A
You can configure WAN and LAN settings using a browser interface.
220 Administrator’s Guide to VPN and Remote Access, Second Edition
The single-port and four-port versions retail
for $129.99 and $179.99, respectively, at a
national brick-and-mortar chain. The new
eight-port version retails for approximately
$230. But I was able to purchase my four-
porter online for less than $155, including
overnight delivery. In fact, Outpost.com got it
to my door in about 12 hours. Not too shabby.
The biggest benefit
If you believe the marketing, the chief benefit
of these EtherFast routers is that they let you
share a single IP address among multiple com-
puters. That’s particularly handy if you’re using
a broadband connection at home. All that’s
required is a cable or DSL modem and high-
speed access.
If you ask me, the biggest benefit from the
router is the fact that I gain a firewall for my
“always on” connection, a 100-Mbps switch,
and the freedom to use whatever domain or
workgroup naming convention I want behind
my firewall. Previously, I had to use the
@Home workgroup name and a unique com-
puter name supplied by the ISP. When these
values were changed, I was unable to connect
to the Internet. No more.
How’s it work?
The router is simple to configure. The Linksys
device features an easy-to-use yet powerful
browser interface, as shown in Figure A.
Assuming you have network adapters in
each of your machines, installation and config-
uration is a snap. It took me nine minutes to
get the Linksys up and running on my test
LAN. And that was five minutes too long.
In an effort to save processor cycles, I’d
turned off many Windows 2000 services. As I
hadn’t been using DHCP, it had been turned
off. However, the EtherFast Cable/DSL
Router uses DHCP to feed 192.168.x.x
addresses to the LAN setup behind it. I dis-
covered the stopped DHCP service about five
minutes into the install, corrected it, and voilà:
I was up and running.
 Previously, I’d had two machines set up
using a plain vanilla 10-Mbps hub. Only one
had Internet access, and it was getting hit daily
by port scans and port probes. Now both
machines boast Internet access, they’re secure
from hacker attacks, and they can talk to one
another 10 times faster.
Using the device’s uplink port and hubs you
supply, the four-port EtherFast router can sup-
port up to 253 users. You probably wouldn’t
want to put that many users behind it on a
cable or DSL connection, but knowing you
can should make you feel good about using it
with three or four test machines.
If you’ve built a small LAN for testing soft-
ware and practicing for certification exams
such as the one shown in Figure B, you’ll find
the Linksys a welcome addition. It sports tradi-
tional RJ-45 jacks and supports both dynamic
and static IP addressing.
Using the Web-based interface, you can
configure port forwarding, PPPoE, and
IPSec connections. You can also elect to
place one of your machines outside the fire-
wall as a “DMZ host.”
Other options
Similar routing devices designed for cable and
DSL applications are available, but I haven’t
had a chance to try them. Your other options
include the following:
X Netgear’s RT311 and RT314
X Netopia’s R9100
X SMC Networks’ SMC7004VBR
Expect to pay $150 on up for any of these
models. You’ll find each offers similar features
and technology, as all of them rely upon Net-
work Address Translation (NAT) to extend
Internet access to additional machines using a
single IP address purchased from an ISP.

Figure B

192.168.1.102

Desktop One

ISP-provided
192.168.1.1 IP address Internet

EtherFast
192.168.1.101 Cable/DSL Router
Desktop Two

192.168.1.100

Laptop
This sample LAN configuration uses the Linksys EtherFast router.

Solutions 221
 Sharing Internet access with just
one IP address
Aug 8, 2000
By Matthew Mercurio, MCP
H
aving a constant, lightning quick con-
nection to the Internet in our homes
is an appealing idea for many of us.
After getting this type of rapid access to the
Web either through a cable modem or a DSL
Internet connection, the next thing on your
wish list might be to have multiple computers
in your home all sharing this high-speed access
through one IP address. Thanks to new prod-
ucts available from Linksys and Sybergen, it’s
now possible to make this dream a reality.
Linksys Cable/DSL Router
Linksys has made a device called the Linksys
Cable/DSL Router, shown in Figure A, that
distributes Internet access with a single IP
address. For about $189 retail, you can pur-
chase this hub to distribute your access
throughout your home. This is great if you
have that kind of budget, but what if you
need a simpler, cheaper solution?
Introducing SyGate
Sybergen’s SyGate product does almost the
same thing as the Linksys Cable/DSL Router
but is completely software-driven and is consid-
erably cheaper. SyGate allows multiple comput-
ers to access the Internet using one IP address.
Compared to the price of a Linksys hub,
Figure A Figure B
This is the Linksys Cable/DSL
Router.
SyGate's main console uses the familiar Windows tree design.
222 Administrator’s Guide to VPN and Remote Access, Second Edition
SyGate is fairly inexpensive. For about $30, you
can have three computers connected to the
Internet. The maximum number of computers
you can connect using SyGate is 10, for around
$100. SyGate’s concept is simple in design, its
interface is straightforward, and it’s easily con-
figured. Just load SyGate on your point of
Internet access computer, and it will do the rest.
Let’s take a closer look
SyGate comes with a main console, shown in
Figure B, where the entire configuration takes
place. From this screen, you can customize the
software to suit your needs. The left pane
describes the Internet access computer com-
plete with computer name, status of SyGate
server, network information, and log list. It’s
set up using the familiar Windows collapsing/
expanding folders tree design.
The log list is a particular favorite of mine.
As illustrated in Figure C, the log list displays
all the computers on the network and, by
enabling me to look at the IP addresses, allows
me to see where the users of these computers
have been surfing on the Web.
Configuring SyGate
The configuration process is fairly simple. As
many of you know, planning how to handle
the computer addresses is a big part of any Figure C
network implementation. With SyGate, the
process is the same for both a business and a
home network. Deciding on static or dynamic
IP addresses is all you really need to do. Once
that decision is made, the rest is relatively easy.
SyGate comes with the ability to either do
static IP addressing or issue IP addresses via its
own built-in DHCP server. The DHCP mod-
ule can be configured just like any other
DHCP server. Figure D shows SyGate’s DHCP
configuration page.

Other nice features

Using SyGate, you can automatically discon-
nect idle machines from the Web after a speci-
fied amount of time. In addition, you have the
ability to ban certain IPs from accessing the
Web. If you’re a parent and are concerned SyGate allows you to see where the users on your network have been surfing.
with your child accessing the Internet when
you’re not home, this is a great feature. The Figure D
software also comes with the ability to put a
password in place so none of the configura-
tions can be changed.

SyGate vs. Linksys

There are a few things you need to know about
SyGate before you decide to buy it. First of all,
when comparing SyGate to the Linksys Cable/
DSL Router, some of the shortcomings of
Sybergen’s product become clearer. One draw-
back is that SyGate does not have its own
built-in firewall. Sybergen does offer a firewall
product, but it is an additional purchase.
Another minus is that since SyGate is com-
pletely software-driven, there are some addi- The DHCP configuration page lets you issue IP addresses.
tional devices—such as a small hub, for
example—that you have to buy. The Linksys
Cable/DSL Router, on the other hand, comes budget you have or how sophisticated you
with a hub, router, firewall, and the distribution need to be. No matter which one you choose,
software built in. SyGate also requires you to you are sure of having your needs met because
place an additional NIC in your point-of- both the Linksys Cable/DSL Router and
access computer. The Linksys Cable/DSL Sybergen’s SyGate are great products if you
Router does not. want to have several computers sharing Inter-
net access through the same IP address.
In the final analysis
When choosing between Linksys and SyGate,
your decision could come down to how large a

Solutions 223
 Share small office broadband pipes using
a Linksys router and Win2K Pro
Dec 18, 2000
By Erik Eckel, Network+, MCP+I, MCSE
T
he Linksys line of EtherFast
Cable/DSL Routers can rescue you
from small office networking jams. For
less than $230, you can deploy one of Linksys’
multifunction network devices quickly and
efficiently.
Configuration is fairly straightforward. In
this article, I’ll show you how to configure
small office or branch office systems to work
with such devices, but first, let’s quickly review
the device’s features.
Linksys EtherFast Cable/DSL
Router features
If you’re supporting a small office or branch
location where you wish to share (or must
share) a single broadband Internet connection,
Linksys’ cable and DSL routers can do the
trick. The device is available in three versions:
X A single-port version (model number
BEFSR11)
X A four-port version (model number
BEFSR41), shown in Figure A
X An eight-port version (model number
BEFSR81)
Figure A
The Linksys four-port EtherFast Cable/DSL Router
device looks like this.
All three of the devices can be used with a
hub. Further, all three versions support up to
253 machines using a single Internet IP
address.
In addition to providing routing services,
the Linksys EtherFast Cable/DSL Routers
provide the following advantages:
224 Administrator’s Guide to VPN and Remote Access, Second Edition
X Firewall services, including port security and
packet filtering
X Switching services at 100 Mbps
X Gateway services, including port forwarding
X DHCP services, using an internal IP
address range (192.168.x.y)
The units require only a small amount of
desk or shelf space. The device’s footprint
measures 7.31 x 6.16 x 1.88 inches.
Other benefits include DMZ hosting (the
ability to place a machine outside the firewall),
local or remote browser-based administration,
SNMP-enabled internal user access filtering,
support for WinSock 2.0 and Windows 2000
Smart Applications, and support for PPPoE
(Point-to-Point Protocol over Ethernet).
The eight-port hub includes 10 RJ-45 ports.
One holds the RJ-45 EtherNet connection to
the WAN link. This port supports speeds of up
to 10 Mbps. Another port serves as an uplink
connection to a hub. It is used to add more sys-
tems than the eight physical ports support.
The other eight ports support 10BaseT
EtherNet or 100BaseTX Fast EtherNet ports
for LAN connections. It’s important to
remember that your LAN connections will be
only as fast as the cables and network interface
cards (NICs) that you use on your network. If
you’re using a 10-Mbps NIC in one machine
but 100BaseTX cabling and hubs, the data
transmission rate will be constrained to 10
Mbps by the NIC.
Before deploying a Linksys router, you’ll
want to ensure you can make use of these fea-
tures. Several items must be in place.
Your first step
The first thing you’ll want to do is ensure you
have a data circuit boasting sufficient band-
width to share. At a minimum, you’d want a
DSL or cable connection supporting a couple
hundred Kbps. You could go with less if you’re
supporting only a few machines. Ultimately, the
Figure B

You must configure each system’s networking settings.

bandwidth you’ll need is dependent on the

applications your users run and their needs for TIP
remote resources, e-mail, Internet access, etc. The TCP/IP listing may not appear. If that’s the case, you’ll have
Next, check all the systems that will be con- to install TCP/IP. You can do so in Windows 2000 by selecting
necting to the EtherFast Cable/DSL Router to Install, Protocol, and selecting Internet Protocol (TCP/IP) from the
ensure they possess functioning NICs. Each resulting menu.
system will also need a category 5 drop (you
can use category 3, but transmission speeds are WORKS WITH LINUX, TOO
slower) connecting it to the EtherFast router. The Linksys cable/DSL routers work with Linux as well as Win-
dows. In fact, don’t be surprised to find a copy of TurboLinux bun-
Secure an IP address dled with your router, should you purchase one. Using Linux,
You’ll need to reserve an Internet IP address you’d want to run the /SBIN/IFCONFIG command to identify your
for the Linksys router. Many ISPs serve up
Internet IP address. Alternatively, you can open an X terminal, run
Internet IP addresses on consumer plans using
LINUXCONF, and review the system’s network settings using that
DHCP. You can usually run an IPCONFIG
interface.
/ALL command from a Windows 2000 (or
Windows NT) command prompt, learn your
IP address, and then enter it using the Linksys Figure C
Web interface.
You’ll also need to know a few other IP
addresses, which I’ll cover in a moment. If
you’re still stuck using a Windows 9x machine,
go with WINIPCFG /ALL. It’d probably be
best to print the addresses out. Write them
down, at the least.
If you’re using a cable or DSL service for
business, however, you should be subscribing
to a business-based plan. In most cases, you’ll
then receive a static IP address.
Let’s look at how the router is configured
when using a single, static address, since that’s
what most small businesses are likely to use. In
the event you’re using a DHCP-provided Inter-
net IP address, don’t sweat it. There’s a single
check box to be toggled; that’s the only differ-
ence versus configuration with a static IP
You must specify that an address be obtained automatically.
address.

Solutions 225
 Linksys EtherFast Cable/DSL
Router hardware setup
The router’s setup is surprisingly easy. In case
you experience trouble, excellent documenta-
tion describing a quick installation is included.
You should start by powering down the sys-
tems you wish to support via the router. Next,
plug all your systems’ category 5 cables into
the router’s RJ-45 ports. If you’re using more
than eight (with the eight-port model), you’ll
plug the additional systems into a hub you sup-
ply and the hub into the uplink port.
After plugging your broadband modem into
the router, you’re ready to plug in the power
supply for the Linksys unit. Make sure you
start fresh by depressing the router’s reset but-
ton. You’ll need to keep it depressed for three
seconds.
Your hardware setup is now complete.
You’re ready to begin the software phase of
the setup process. Start by powering up one of
the systems you’ve connected to the router. In
this case, we’ll use a system running Windows
2000 Professional.
System configuration
After your machine boots, right-click My Net-
work Places and select Properties. This action
opens the Network And Dial-up Connections
applet. From this applet, select the network
connection you wish the router to use. The
connection in this example is named Linksys
(Internet), as can be seen in Figure B.
Right-click the connection you wish to use
and select Properties. Select Internet Protocol
(TCP/IP), as shown in Figure C, and click Prop-
erties. From the Internet Protocol (TCP/IP)
Properties box, ensure the Obtain An IP
Address Automatically radio button is selected.
Click OK twice to close both boxes.

Figure D Figure E

You must enter a valid user name and password to configure

the router.

TROUBLESHOOTING TIP
If you can’t access the Web administration
tool, ensure you’ve turned other Internet
sharing proxy services off. A proxy server
could have already taken the 192.168.1.1
address, which will prevent the Linksys
device from responding. You’ll have to wres-
tle that IP address back for use by the router
(at least until you can access it to change the
Linksys device’s default internal IP address).
The administration software is Web-based.

226 Administrator’s Guide to VPN and Remote Access, Second Edition

Linksys EtherFast Cable/DSL
Router configuration
After you reboot your system to trigger the
changes, you’re ready to set up and configure
the router. Fire up a browser and enter the fol-
lowing address:
http://192.168.1.1
The 192.x.y.z IP addresses are not Internet
IP addresses. By that, I mean they’re not
unique to the World Wide Web. This address
range has been preserved for internal, or pri-
vate, use.
You’ll be greeted with the screen shown in
Figure D. It requires that the router’s password
be entered.
Linksys includes the default value to be
entered. I recommend you change it the first
time you use the router. I’ll show you how to
do that a little later.
Enter the values Linksys provides, or pro-
vide the new entries you’ve specified, and click
OK. The next thing you see should be the
Linksys Setup screen, shown in Figure E.
(While I trust the router’s firewall, I don’t want
to encourage hacking it, hence the blocked-out
addresses.) If not, double-check to ensure your
system’s DHCP service hasn’t been stopped.
Enter the name you’d like to use for your
router in the Router Name box. Enter the
domain name you’d like to use. You may not
need to provide any values at all. Check with
your ISP if you’re not sure.
Unless an internal naming scheme already
in place interferes, you can leave the LAN IP
Address entered as is. It should read
192.168.1.1.
Remember I mentioned earlier that it’s easy
to set the router itself to request an IP
address? All you need to do is select the
Obtain An IP Address Automatically radio
button under WAN IP Address.
Most likely, you’ll want to enter a static IP
address. Select Specify An IP Address instead.
Next, enter the IP address you wish to use or
that you’ve been assigned by your ISP. This is
not, of course, the IP address for your system
but the IP address of the router that you’re now
configuring.
Next, you need to specify the subnet mask,
default gateway, and your ISP’s DNS servers.
These values would have been provided when
you executed the IPCONFIG /ALL com-
mand on the Windows 2000 Professional
machine earlier.
If you’re using PPPoE, you can enable it.
Just be sure to also provide the required user
name and password. Click Apply.
The next thing you need to do is select the
DHCP tab within the Web-based software
configuration tool. Select the Enable radio but-
ton and specify the first internal IP address the
DHCP service should start with when receiv-
ing a request. Don’t forget to specify the total
number of DHCP addresses the router should
provide.
Click Apply, and you’re finished with the
basic setup.
Change the default password
As I mentioned earlier, you should also change
the default password. Linksys includes the
password you must enter the first time you
access the Web-based administration tool.
After that, you’re on your own.
Don’t think there aren’t freaks searching for
these routers and trying the default security
account settings in an attempt to get in. Don’t
make their day. Change the password setting
the first time you use the router.
The password setting is easily changed.
Click the Password tab on the Linksys router’s
Web administration tool to reveal the screen
you see in Figure F.
Enter the password you wish to use. Re-
enter it and then click Apply. I recommend you
specify an alphanumeric password that’s not
related to any of the following:
X Your birth date X Kid names
X Your address X Pet names
X Your anniversary
Hackers try those first. Instead, choose some-
thing others wouldn’t be able to easily guess.
Check your configuration
Once you’ve specified the configuration you’d
like your router to use, check it. Select the Sta-
tus tab. It’ll display the following:
Solutions 227
 X Router name X WAN IP address Clicking the provided DHCP Clients Table
X LAN MAC address X WAN subnet mask button prompts a pop-up screen to appear. It
lists all the systems that have received an inter-
X LAN IP address X WAN DNS servers nal IP address from the router and displays the
X LAN subnet mask X Firmware version systems’ host names and MAC addresses. The
X LAN DHCP X PPPoE status table also lists the DHCP address each
server status machine is using.
X WAN MAC address Have at it
The Status tab also provides access to a Once you’ve specified the settings you wish
DHCP table, should you wish to review it. to use on the router and configured all your
clients, you’re good to go. Your systems, when
Figure F booted, will send a DHCP request to the
router. The router, in turn, will provide DHCP
addresses to the systems.
Then, knowing the address of the router,
the systems will be able to contact DNS
servers. These DNS servers will fulfill name
translation services, so the systems behind the
router will be able to access the Internet using
their internal IP addresses.
They won’t even know the router’s there.
Hackers will be able to see the router but not
the systems behind it. Isn’t that the way it’s all
supposed to work?
Use the Password tab to access the security account settings.

Check Point offers integrated firewall

and VPN on Linux
Oct 24, 2001
By Todd Underwood

C
heck Point FireWall-1 is the 800-pound
gorilla of the commercial firewall
industry. Check Point Software Tech-
nologies has ported its popular, sophisticated,
and relatively easy-to-administer firewall to the
Linux platform. FireWall-1 is further enhanced
with integrated VPN functionality that’s easy
to deploy and manage. Such integration sets
Check Point apart from both commercial
Linux firewall suites and open source security
alternatives.
Distributed security
Check Point divides the implementation of its
network security policy into three components:
a graphical interface for administration (see
Figure A); a management server that stores

228 Administrator’s Guide to VPN and Remote Access, Second Edition

security policies and logs; and an enforcement
point—a network gateway that actually imple-
ments that policy, blocking or allowing traffic
where appropriate. In smaller implementa-
tions, the management server resides on the
same box as the enforcement point.
In general, most firewalls perform a similar
combination of functions—storing, imple-
menting, and logging violations of a security
policy. Check Point’s approach is unique in that
it lets you define more than one enforcement
point. For example, suppose you have several
wide area network (WAN) connections: one to
the Internet, two more to satellite offices, and
another to a business partner’s network. In a
case such as this, you may want as many as
four enforcement points, one for each connec-
tion. To accomplish this with Check Point, you
must still develop a single security policy on
your management server. You can then install
the applicable parts of that security policy for
each of your enforcement points.
This kind of scalability is why many large
organizations with extremely complicated net-
works—GTE Internetworking, for instance—
use Check Point for their security needs.
How FireWall-1 inspects traffic
FireWall-1 blocks traffic by means of technol-
ogy that Check Point calls stateful inspection. As
traffic arrives at the firewall, Check Point
examines it and compares it to the set of exist-
ing, and allowed, network conversations
already underway. If a packet is part of an
existing conversation, it can pass. If the traffic
is unfamiliar but allowed, a new entry is cre-
ated in the list of existing conversations, and
the traffic can pass through the firewall. Other-
wise, it is blocked.
With stateful inspection, you can specify
rules more easily than you can with basic
packet filters. Stateful inspection describes traf-
fic according to who initiates the connection,
and other traffic can be allowed or denied
based on existing connections. Most popular
firewall packages implement similar technol-
ogy for tracking connections. Darren Reed’s IP
Filter package for various versions of BSD
UNIX and the new iptables software for Linux
are examples of firewalls that use stateful
Figure A
Check Point’s GUI displays security policies and provides a simple mechanism for
installing them on a gateway.
packet filtering. Check Point claims that its
stateful inspection technology is more sophis-
ticated because it builds state—entries in the
list of network conversations—by taking
advantage of much more information from
HTTP and other protocols higher in the net-
work protocol stack.
Virtual private networking
Check Point offers the most effective integra-
tion of VPN and firewall functionality we’ve
seen. Check Point’s VPN-1 is merely an
encryption add-on to FireWall-1; such tight
integration makes VPN setup much easier by
providing a common interface for both fire-
wall and VPN administration. It also lets you
apply security policies to traffic in the VPN—a
task that’s nearly impossible when using a sep-
arate VPN concentrator located inside a fire-
walled perimeter.
In addition to supporting network-to-
network VPNs, Check Point supports client-
to-network VPNs through its SecureClient and
SecuRemote applications. These two add-on
packages are Windows-based apps that let
users connect their systems to the firewall net-
work through an encrypted network tunnel to
access services on the network.
This terrific infrastructure facilitates afford-
able telecommuting. SecureClient offers the
Solutions 229
 added advantage of protecting a workstation
from attack so that remote users’ computers
cannot become platforms for attacking a com-
pany’s network. The SecuRemote add-on is
free; SecureClient costs $100 per seat, with dis-
counts for larger numbers of licenses.
Installation
Once you understand Check Point’s security
model, installation is a fairly simple process.
You run a text-mode script that installs some
RPM packages and runs cpconfig, Check
Point’s text-based configuration program.
During installation, you can choose to install
a distributed configuration (with the enforce-
ment point and the management server sepa-
rated), or you can install everything on a single
server. You can also specify how many nodes
to protect. Then you identify the external inter-
face and specify the security policy that should
be in place while the firewall is booting, and
which users at which client workstations should
be allowed to administer the firewall.
We were somewhat disappointed that Check
Point’s GUI does not run on Linux; currently,
it supports only Windows and commercial ver-
sions of UNIX (AIX, HP-UX, and Solaris).
However, this is more of an annoyance than a
serious hindrance, since any network large
enough to warrant a Check Point firewall is
likely to employ Windows-based workstations.
Licensing
Check Point is one of the only firewall ven-
dors that licenses its software based on the
number of protected devices (IP addresses for
High marks for Mangosoft’s VPN alternative
Dec 4, 2001
By Brian Hook
E
veryone knows that e-mailing data over
the Internet—specifically, sensitive
corporate documents—is a risky busi-
ness if there are no safety measures in place to
secure the transmission.
230 Administrator’s Guide to VPN and Remote Access, Second Edition
internal interfaces that are visible to the fire-
wall). Protected devices can include print
servers, virtual Web hosts, and routers (along
with all of the machines on a company’s net-
work). And in case you’re wondering, it is not
legal to hide IP addresses behind a proxy
server or network address translation (NAT)
device to circumvent the licensing scheme. If
you exceed the license maximum, all traffic is
still subject to the rules that are in place. You
cannot add new rules, however, and alerts are
sent to the administrator on a regular basis.
Bottom line
In porting Check Point FireWall-1 and VPN-1
to the Linux platform, this market-leading
security company lends significant credibility
to Linux as a viable security platform. How-
ever, it’s important to note that Check Point
FireWall-1 and VPN-1 are not for the faint of
heart. Installing and configuring the products
will involve some study and a fair bit of plan-
ning. But for organizations that believe they can
benefit from a scalable management infrastruc-
ture and integrated VPN functionality, Check
Point is unmatched on the Linux platform.
Pricing for FireWall-1/VPN-1 depends
upon the number of licenses purchased. A 25-
user license for FireWall-1 (standalone with
built-in management console) costs roughly
$4,000, which includes software, support, and
a year’s worth of upgrades. VPN-1 costs about
$500 more. The Check Point Command Cen-
ter Enterprise Management Bundle lists at
approximately $25,000.
The virtual private network (VPN) is rou-
tinely cited as a great mechanism for secure
file sharing via the Web, but it’s also often
described as hard to deploy, cumbersome to
manage, and a bit costly.
 Mangosoft, a Westborough, MA, services
provider, believes its technology, Mangomind
Business Internet File Service, erases those
deployment and maintenance headaches and
provides a simple and cost-effective alternative
for providing secure collaboration outside
today’s firewalls.
A simple, cost-effective solution
According to Mangosoft, Mangomind is
designed for businesses that frequently collab-
orate with partners, and it can be implemented
without traditional VPN hardware and mainte-
nance costs. And, because it offers a similar
Windows user interface, it also doesn’t require
extensive end-user training. Mangosoft sup-
ports Windows XP, 95/98, Me, NT, and 2000.
Security features include end-to-end 128-bit
encryption of transferred and stored files, user
authentication, and file access controls. Man-
gomind lets users set their own access permis-
sions for files and folders, and the software
automatically synchronizes files if a user is dis-
connected and then reconnects to the Internet.
According to one VPN expert, the Mango-
mind Business Internet File Service is a good
VPN alternative that CIOs should consider.
“One of (the) things that both a VPN and
Mangomind do well is let you securely share
files. But Mangomind is a much simpler thing
to use,” says Salvatore Salamone, principal
consultant at Salamone Research, based in
New York.
Scott Davis, Mangosoft’s CTO, said the
auto-synchronization feature is valuable, espe-
cially for road warriors conducting business
away from the corporate office.
“The data is all kept in sync, and they’re able
to take the data they need on a laptop. And
when they make modifications, it is synchro-
nized with everyone else. It’s an extremely
cost-effective way to operate,” noted Davis.
Not a security cure-all technology
Yet Davis admits that Mangomind can’t com-
pletely replace a VPN. For example, enter-
prises can’t use Mangomind for intranet-based
application use between companies. “A VPN is
required for that,” said Davis.
“Mangomind is really a best-of-breed file
service. It’s a file service and nothing more
than that,” he added.
But that doesn’t diminish its value, accord-
ing to Mangosoft, as the file service is still
regarded as an important tool. “It’s just hard
getting enterprises to switch over to a secure
sharing approach,” said Davis.
“People are in the habit of e-mailing docu-
ments, even though it is insecure,” said Davis.
Salamone, who recently participated in several
VPN focus-group efforts, said he was very
surprised to hear that many executives are still
e-mailing critical data without a VPN or file-
service product.
“They want to send stuff outside the com-
pany, and they just don’t think. It really opens a
liability if you are sending confidential finan-
cials. You are in trouble if someone happens
to get this before a disclosure date,” he noted.
In terms of cost, Mangomind is clearly
much less expensive than building a VPN.
According to a cost analysis review by eVision
Technologies, an e-business consulting firm,
using Mangomind for one year would be
nearly one-fifth the cost of a VPN. The firm
estimates that one year would cost a company
$2,994 with Mangomind vs. $15,580 with tra-
ditional VPN equipment. That cost difference
also does not take into account the additional
$5,100 a year for recurring maintenance associ-
ated with VPNs.
Cost savings can be a
critical factor
The lower cost factor is what prompted Greg
Baber, CTO for Internet Publishing Group,
Inc. in Newtown, PA, to choose Mangomind.
His company, which provides information
services to business customers, has no infra-
structure in-house.
Baber said setup was easy and that he rec-
ommends Mangomind because it eliminates
unnecessary costs.
“We delayed making a decision about build-
ing a VPN until Mangomind came along, and
we found it fit our needs almost perfectly. If
you can postpone a ‘build it’ decision, do so,”
said Baber.
Solutions 231
Builder.com | CNET.com | TechRepublic.com | ZDNet.com

e-mail: customerservice@techrepublic.com
Phone: 914-566-1866 • 800-217-4339
Product code: B038