VPNs: Dial "T" for Troubleshooting

Rebecca Rohan continues her discussion of how to create a virtual private network without having a virtual nervous breakdown. Just because the thing is built, that doesn't mean that you're done: Next comes a little phase called "troubleshooting."

Like this article? We recommend

In our last
episode (part 1 of this series), IT superheroes learned to avert major disasters
by planning the company VPN with uncanny forethought. Yet, even if you've
done everything right (and that's a lot), you can still be confronted with
problems. Users will louse things up with patches, new software, or just plain
fiddling that overwrites your careful configurations on their end, from modem
settings to WINS. There are firewalls that won't allow GRE packets and
ISPs that block portsand all that can change on someone else's whim.
In short: Don't retire that red cape just yet.

Still, you don't have to fly around the world backward to fix VPN
problems. We'll show you how simple many fixes can be, when you know how to
look for the easy things first.

Your virtual private network is in place, and workers are attempting to tunnel
in securely to perform their jobs. What's that you heara cry for
help? In one of our favorite books on the topic, Implementing and Administering Security in a Windows 2000 Network Exam Cram 2 (Exam 70-214)
(Que, 2003, ISBN 0789729512), authors Roberta Bragg and Ed Tittle say that when
VPN connections aren't working, one simple test will probably rule out
50% of the rest of your entire VPN troubleshooting checklist: Simply find out
whether other (presumably nonVPN) clients can connect to the server. Well
done! It's much simpler to diagnose a VPN if you're not looking for
something esoteric on both sides of a network connectionor analyzing the
connection itself.

That's the kind of superhero you want to beswoop in and point out
a simple way to eliminate one huge vat of kryptonite, and then another. Point a
finger at the server, and villains may fall out of its power supply vent and run
cursing, "Drat! Foiled again!" when it can't perform normal
tasks. Or it may be the client, which can't reach its ISP on a normal
dial-up basis, let alone tunnel to work.

Match Game

Part 1 of this series talked about the buying decision between VPN products
with IPsec or PPTP security protocols (or both), since protocols at the
user's end and the company's end have to match. If the user is in
trouble, does he have the security protocol that's configured at the
server? Obviously, users need to match servers on network protocols (IPX or
NetBEUI) and on the level of encryption, and you should have WINS enabled on
both sides of the tunnel.

All these match points are places to recheck when things don't work
correctly, but there are other spots to check for mismatches, including the
authentication method for IPsec. AH and ESP encryption and authentication
headers also have to match under IPsec. A roundabout "match": PPTP
tunnels require MPPE encryption, so PPTP clients must be configured to use
MS-CHP, MSCHAPv2, or EAP/TLS.

In Virtual Private Networks, Second Edition (O'Reilly, 1998), Mike Erwin, Charlie Scott, and Paul
Wolfe remind IT superheroes of the simplest mismatch of all: "A mismatched
username or password, which occurs when either the connecting machine or the
far end thinks that the username or password is something other than what it
is. This is sometimes caused by a simple typographical error." Lots of
words for a short picture. This could also be the effect of a rollback on the
user's machine due to a System Restore, so the login doesn't match
information on the server. (See my article "Taking
Advantage of Windows XP's System Restore," right here on Inform
IT.) Just another nonVPN problem that can be isolated and fixed quickly
by turning your x-ray vision on the ordinary problems first.

Any time technologies compound and become potential troubleshooting
nightmares, the first principle of problem solving should always be going back
to the source-and-buggy checklist that starts with questions like, "Is it
plugged in?"