Networking Tips

May 5, 2005

Seen at Interop: Networker's 5-in-1 Road Warrior Kit

A datacenter manager at Networld+Interop this week showed me one of the coolest little road warrior cable kits I've ever seen. He built it himself from off-the-shelf components, following instructions posted online by Michael Ossmann, a security administrator for Exempla Healthcare. The kit is ingenious in providing five data cables in one: ethernet cable, crossover ethernet cable, modem cable, null modem cable, and Cisco console cable. And you can build it yourself using just a few ordinary parts and an RJ-45 crimping tool.

My current road warrior kit consists of several Ethernet cables of various lengths, several crossover Ethernet cables, also of various lengths, a slew of serial cables for Cisco and other devices, along with a variety of DB9 and RJ-45 adapters, gender changers, and magic spells. This all takes up one half of my briefcase. Half the time I can never find that weird sky-blue flat Cisco console cable and adapter, so I'm wasting time with my EasyBOB (break-out-box) re-inventing that combo.

With Michael's clever kit, a single male-to-male CAT-5 cable serves as both serial and Ethernet cable, and various plug-on adapters convert that cable to different uses. The adapters alone are invaluable, because they let you turn somebody else's CAT-5 cable into the cable you need at the moment. I often find that the gear I want to connect to via serial cable is way over yonder. I don't carry a yonder-length serial cable, however, so I usually end up perched on a ladder precariously, balancing a notebook computer on one knee, trying to get close enough to the gear's serial port. If I could swap iany old Ethernet patch cable for my serial cable, my problems would be over; I can scrounge up CAT-5 patch cables of most any length.

The parts you and tools you need are available at any Radio Shack or Frys Electronics:


  • Two DB9 female to RJ-45 female modular adapters
  • Eight extra female pins for the DB9 connectors (just canabalize another adapter)
  • Four crimp-on RJ-45 modular plugs
  • One eight-wire RJ-45 modular coupler
  • RJ-45 crimp tool
  • Teeny screwdrivers
  • Diagnal wire cutters

Michael's site provides crystal clear, step-by-step instructions with beautiful color photos. Michael also explains how to use the kit in novel ways, such as plugging a network sniffer into an existing cable in receive-oly mode for quick-and-dirty traffic capture without interposing a small hub or switch.

You could have your kit built by lunchtime tomorrow. I'm making mine right now in my Interop hotel room.

http://www.ossmann.com/5-in-1.html

Posted by Mel Beckman on May 5, 2005 at 2:17 AM

March 31, 2005

Unplugging the Enterprise: The Ointment and the Fly

Enterprise IT administrators have their hands full maintaining control of corporate wireless gear, which may go roaming where it shouldn't, exposing sensitive corporate data to prying WiFi sniffers. Even if you employ the gold standard of WiFi security -- a VPN connection back to the ranch -- it's difficult to prevent users from connecting a corporate laptop at the neighborhood Starbucks, resulting in a potentially disasterous security compromise.

Another bane of WiFi administrators is the complexity of making roaming users' online experience equal to their wired one. A big difference for VPN client connections is the difficulty of accessing such network services as printers and file shares, which often expect to attach at login, but which can't because the user isn't on the WiFi network at login.

Fortunately, there is a fix, called Layer Two (2) Tunneling Protocol (L2TP). Also, there is a fly, named password encryption.

Normally a WiFi user must log in with a local computer account before activating a VPN client to gain secure WLAN access. This means maintaining two sets of login credentials, and leaves a window for user mischief between the local login and the VPN login. Worse, since the user isn't on the WLAN at login, startup scripts requiring enterprise LAN connectivity -- for example, those that mount file shares -- will fail. This makes WLAN behavior perplexingly different from the user's wired hookup.

The silver bullet workaround uses an L2TP VPN tunnel that can be initiated at logon time using a Windows network dialer -- the kind you create by going to Network Services and clicking on Add a New Network. L2TP is an extension to the PPP protocol that merges the best features of two other tunneling protocols: PPTP from Microsoft and L2F from Cisco Systems. It employs IPSEC encryption, so it's more secure than PPTP, but being PPP-oriented, it can work like a high-speed modem connection. Hence the L2TP dialer.

The procedure varies depending on the host WLAN VPN appliance you use, but the payoff is the same for all: a user can choose the L2TP VPN dialer right on the login screen. And no VPN client software is required either -- you can set up L2TP on any modern Windows machine right out of the box. Once the dialer is configured, you can lock the user out of the computer except when it's safely VPN'd into the WLAN and joined to the Windows domain.

But what bout that fly I mentioned? It's a subtle, but maddening one. To authenticate L2TP users, your VPN gateway appliance must be configured to pass login requests to a Windows domain controller using the RADIUS protocol. The problem is that passwords in the domain controller are encrypted using Windows' proprietary encryption, which isn't a supported L2TP IPSEC authentication method. So the VPN server must send the password in the clear to the RADIUS server, where Windows will compare it with the one stored in the DC. The problem with that is that Windows' native encryption is one-way by default, so you have to siwtch all WLAN users' Active Directory profiles to two-way encryption. The password the user enters is still encrypted over the VPN tunnel, so no undue WiFi password exposure exists, but there is a hidden glitch waiting to bite everyone when they first roll out L2TP.

Have you seen the fly yet? Here's another hint. If you're like most network admins (such as myself), you'll want to test your brand spanking new L2TP login with a test account that you freshly create. And it will work smashingly, wonderfully well. You'll be slapping yourself on the back over how cool it is to have L2TP working right from login.

Then, just before going home at 4:00 p.m. (a reward for your L2TP cunning), you'll try to enable one of your existing users for L2TP access. You'll switch their Windows profile to use reversible password encryption, and then try to log them in through the WLAN.

And it will fail.

It will fail at 4:30, at 5:30, at 7:30, at 9:30 and at midnight when your spouse calls to tell you not to make noise when you come home. Maybe by dawn the fly will hit you right between the eyes. Or maybe not until Saturday. For me, it was Saturday.

The fly is this: even though you switch a user profile from one-way to reversible password encryption, that doesn't make the password THAT IS ALREADY STORED reversibly encrypted. Think about it. Making the stored password reversibly encrypted would require being able to decrypt the current password and re-encrypt it, but since it's already one-way encrypted, that's impossible. A Catch 22 of the First Order.

To make it work, you must reset the user's password. That's it. That and 37 hours of overtime.

Note to Microsoft: A warning pop-up from Windows when changing a user profile to reversible password encryption would have been helpful here.

Posted by Mel Beckman on March 31, 2005 at 10:47 AM