When my boss, Rich Tehrani, asked me if he could access TMC’s LAN via the
Internet, my eyes lit up, a smile broke across my face, and I responded, “You
betcha!” I had been anticipating this question, ever since Rich installed a cable
modem in his home for high-speed Internet access. (Check out Rich’s column on his cable
modem installation).
My previous experience with VPNs had been limited to tests in TMC Labs. So, as you
might guess, I was eager to set up my first virtual private network (VPN) in a
“live” environment.
From my work in TMC Labs, I was already familiar with several of the VPN products on
the market. However, for ease of use, ease of administration, and because it’s free,
Microsoft’s implementation of PPTP (Point to Point Tunneling Protocol) got the nod
for this project. I elected to run Microsoft’s PPTP on an NT Server machine.
A DECEPTIVELY SIMPLE INSTALLATION
The installation, at both the server and the client, went so smoothly that I was
sure my VPN project was finished — but for the champagne toast, of course. But, as I
soon learned, I would be drinking coffee for some time to come.
The Server
First, I needed to install PPTP on an NT Server that was connected to both the
Internet and our corporate LAN. Adding PPTP was as simple as adding it to the Protocols
tab under the Control Panel, Network properties. Configuring PPTP required nothing more
than setting the maximum number of VPN connections.
Next, I added Remote Access Service to the Services tab and added a VPN device within
the RAS service. Configuring the VPN device (added to the RAS service) involved setting
the encryption settings, DHCP settings, and a couple of other parameters. Overall, setting
up the VPN on the server was easy and straightforward.
The Client
In this installation, the client was Rich’s laptop. It ran Windows 98, and
was connected to the Internet via a cable modem.
To add the VPN client software, I needed to open the Control Panel, Add/Remove
Programs, Windows Setup, Communications, and Details. Within Details, I checked Virtual
Private Networking. In doing so, I added “Dial-Up Adapter #2 (VPN Support)” and
“Virtual Private Networking Adapter” to the Network properties and bound them to
the network card as well as to the “Dial-Up Adapter” used for analog modem
Internet access.
After rebooting the laptop, I opened Dial-Up Networking and chose “Make A New
Connection.” This action prompted the launch of a wizard for adding a new connection.
Now, in addition to listing the modem as a device, the drop-down box displayed a new
device called “Microsoft VPN Adapter.”
After I chose this new device and clicked on “Next,” I noticed that the
screen was completely different from the traditional modem dial-up wizard. The screen
prompted me to enter the IP address of the VPN Server (running PPTP). After clicking on
“Finish,” I right-clicked on the icon, went to the Properties screen, and set
various parameters, such as encrypt password and encrypt data. Also, I was able to choose
which protocols I wished to use (NetBeui, IPX/SPX, and TCP/IP are all options). After
entering all this information, I was ready to test the VPN connection.
I double-clicked on the new dial-up networking icon I created, and entered the password
to the VPN Server’s domain. Then I was prompted for the user name, password, and
domain name for the main domain controller. After I entered this information, the laptop
was authenticated by the domain controller.
For my first test, I opened Windows Explorer and browsed the network. I was able to see
the Network Neighborhood computer names. Success!
A PROBLEM SURFACES
Excited over the trouble-free installation, I immediately invited Rich to come
over and give his new VPN a spin. Rich was delighted to access TMC’s LAN from his
house, and gratified by the speed delivered over the high-speed cable modem. But then he
then opened Internet Explorer and discovered he couldn’t browse the Internet while
the VPN was active.
My first thought? “Doh!” My second thought? “OK, this project isn’t
as easy as I thought it would be, but I enjoy a challenge.”
I noticed that if we closed the VPN connection, we could again access the Internet.
Essentially, we could get only one connection or the other, but not both at the same time.
INITIAL DIAGNOSIS
I searched Microsoft’s Web site, where I found various links to discussions
of VPNs. One of the links suggested upgrading to Dial-Up Networking 1.3. I tried it. But
it didn’t resolve the problem, so I had to dig deeper.
I opened a DOS box and tried “pinging” Web sites. I also executed the
“tracert” command. This command, I hoped, would help me determine where the
packets were going. Immediately, I realized that all the packets, including Web site
requests via the browser, were being routed to the VPN server.
This was bad. Of course, I wanted some of the packets to go through the VPN —
namely, the packets that were addressed to our corporate LAN (our primary LAN is
193.0.0.x; our secondary LAN, 193.0.1.x). However, I wanted the rest of the packets to go
directly to the ISP for regular Internet access.
To be sure I had correctly identified the problem, I executed the “route
print” command, which let me print the laptop’s routing table. I saw that the
default gateway was the VPN server, confirming that all packets were being routed through
the VPN server.
HOPING TO AVOID A HACK
I knew I could probably hack a solution, but I wanted to do the job right. (I was working
with my boss’s laptop after all.) So, I decided to learn more about my options. I
started by calling Microsoft for help. Microsoft confirmed my suspicion that the Internet
request packets were being routed through the VPN server. The Microsoft representative was
already familiar with my problem, which relates to a known limitation of the Win9x
platform (as compared to NT), with respect to persistent routes.
For Win9x, I was told, my best option was to work with a batch file that modifies the
route tables. I would have to add a route specifically for the target subnet to which I
was connecting, and I would have to remove the “Default Gateway” route for the
PPTP session.
This procedure would leave the default gateway directed to our ISP connection, allowing
direct routing for our non-VPN (Internet) traffic, and still maintain a specific route to
our corporate LAN over the VPN.
A HACK, THEN
Essentially, I would have to hack a solution after all, via a batch file.
Fortunately, I am well versed in DOS, since I grew up using it.
I was a little surprised that Microsoft hadn’t made it easier to set up a VPN on a
Windows 9x client. Using a DOS batch file to manually modify routing tables is not my idea
of user friendly! (Although I am writing a column, and not a product review, I would like
to suggest at least one “room for improvement” item: Please automate this
procedure!)
Anyway, I went ahead and wrote a batch file that would permit simultaneous access to
both the VPN and the Internet. (To see this file, please take a look at the sidebar
entitled “Batch File Hack.”)
Unfortunately, you must know the value of the client’s assigned Internet IP
address in advance, before you run the batch file. If the IP address is permanent,
it’s not too much of a problem, since you can hard code this value into the batch
file. However, if you’re using dial-up Internet connections to establish a VPN,
you’ll need to run winipcfg.exe to determine the dynamically allocated IP address
that changes each time you establish a dial-up Internet connection. Then you’ll have
to enter that value into the batch file. Again, this is a hack, and I would like to
reiterate that Microsoft should simplify this procedure, making it more automated.
Once I ran this batch file on Rich’s laptop, we were able to browse the Internet
and access TMC’s LAN at the same time. Rich was a happy camper. After several days of
using the VPN from home, he told me that he was just as productive at home as he was in
the office.
PARTING THOUGHTS
While telecommuting is nothing new, it pays to keep abreast of the latest developments.
Otherwise, you might rely on an outdated impression of telecommuting — that it’s
cost prohibitive, requiring arcane (and expensive) data solutions. You might overlook some
of the newer, more cost-effective options. For example, with VPN solutions, which utilize
inexpensive Internet access to connect to the corporate LAN, telecommuting can seem much
more practical.
The next stage in the evolution of VPNs will bring forth products that take advantage
of encryption, to transmit secure voice conversations across the Internet. This feature
could be used to route phone calls to an office extension across the Internet via a VPN to
an IP-based phone, such as Cisco’s Selsius IP phone or 3Com’s NBX IP phone.
I wouldn’t be surprised if Rich were to call me again in a few weeks. I imagine
he’ll ask if he can use an IP-based phone, situated in at his residence (or anywhere
else, for that matter), to take calls originally directed to his office phone number. If
he isn’t already thinking of such a project, he soon will be, after reading this
column!
Speaking of projects, I’ve got to run. The boss is calling. n
tom.tif
# CTI December 1999 Subscribe FREE online at www.ctimag.com
melita
Subscribe FREE online at www.ctimag.com CTI December 1999 #
CC: BY TOM KEATING
My first thought? “Doh!” My second thought? “OK, this project isn’t as
easy as I thought it would be, but I enjoy a challenge.”
|
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
