VPNs: Dial "T" for Troubleshooting
Like this article? We recommend
Like this article? We recommend
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?"