Picture a well-dressed woman standing in your company's lobby, chatting with your receptionist. Now imagine her laptop equipped with wireless sniffer software, sucking up all of your confidential documents and email messages. Or picture an enterprising young man who, just for kicks, has decided to set up on his laptop a rogue DHCP server, which diligently hands out invalid IP addresses to all of your desktop clients. With just a few thousand dollars worth of off-the-shelf computer hardware and software, an intruder can wreak havoc on your wireless network if you haven't taken the appropriate precautions to secure it properly. And after someone has gotten inside your network, you can't do much except unplug your wireless Access Point (AP) and clean up the damage.
Anyone can install wireless APs—even people outside your IT organization. If your organization is large, you might never know that some manager purchased a wireless AP from a discount store and hooked it into the network, just so his employees can wander around the office with their laptops. And this scenario might not even be happening in your building; it might be happening in a remote office, creating a gaping security hole in your organization's network. By nature, APs are a security problem—unless they're still in the box, wrapped in plastic and Styrofoam. However, by using your AP's security capabilities in conjunction with Microsoft Routing and Remote Access Service (RRAS), you can protect yourself from the inherent risks.
Wireless Security with Existing Equipment
You'll find many documents on the Internet about how to secure a wireless network by using nothing more than the equipment that your wireless manufacturer provides. Procedures for doing so vary from manufacturer to manufacturer, but a couple of common techniques are worth mentioning. Primarily, you should consider implementing both Wired Equivalent Privacy (WEP) and authorized media access control (MAC) lists, if your equipment offers these features.
WEP. Wireless networks' built-in encryption capabilities have been broken. Regardless of whether you use 40-bit WEP or 128-bit WEP, an intruder can decode the WEP key that you use for your network. As shocking as that revelation might be, even more shocking is the number of wireless networks that don't even use WEP. During a recent exercise in Washington, DC, I spent a mere 20 minutes worth of scanning for wireless networks and found more than 40 wireless APs, as Figure 1, page 60, shows—and hardly any of them were using encryption. Most people take the time to name their wireless network, simplifying even further the task of determining who's running an open network. I've obscured most of the network names in Figure 1, but 90 percent of the general public would recognize some of the names that I saw. (No, I didn't go past the White House.) If you don't plan to use WEP, you should at least avoid giving your network a descriptive name.
Although WEP has been broken, you can use it as a starting point for your network security to discourage people from attempting to enter your network. Some newer firmware revisions from wireless equipment manufacturers improve WEP security, making your WEP key much more difficult—if not impossible—to decode. So don't forget to upgrade the firmware on all your devices.
Authorized MAC lists. Some wireless APs let you build a table of authorized MAC addresses—the unique fingerprints of wireless NICs—into the AP. If an unauthorized wireless NIC attempts to associate with your wireless AP, the AP rejects it. This extra step takes a bit of effort because you'll need to manually add each card to the authorized MAC table. However, doing so adds an extra layer of security to your wireless implementation.
Security
Wireless networking's core deficiencies are in the areas of authentication and encryption. Wireless APs generally perform very little, if any, user authentication. If a user is within range of your AP and you're not using any type of security, he or she is connected to your network. WEP provides some value but has numerous inherent flaws. So here's a pop quiz: Which type of networking technology can authenticate users coming from an untrusted space and encrypt their communication so that someone listening can't intercept it? The answer is a VPN.
A VPN solves wireless networking's current deficiencies. Granted, getting connected becomes a bit more difficult for your users. But if you've already invested time in building a VPN infrastructure for your mobile users to access your organization's network, installing a VPN to authenticate wireless users is a relatively simple process.
Let's take a look at a fictional corporate network, before and after using a VPN to secure wireless connections. Figure 2 shows a network diagram of a typical wireless implementation, with the wireless AP behind the corporate firewall. Even after you spend tens of thousands of dollars on firewall equipment to keep untrusted connections out of the network, this type of implementation opens up a big hole within the trusted network space. Imagine a bank vault door at your front entrance but a rickety old screen door at your side entrance. Guess which point of entry an intruder will choose?
Figure 3 shows a secure method of implementing a wireless AP: behind a VPN server. This type of implementation provides high security for your wireless network implementation without adding significant overhead for your users. For extra protection, you might try moving the VPN server to sit in front of your firewall, but because APs are typically location-dependent, this approach won't work for everyone.
If you have more than one wireless AP in your organization, I recommend running them all into a common switch, then connecting the VPN server to the same switch. Then, your desktop users won't need to have multiple VPN dial-up connections configured on their desktops. They'll always be authenticating to the same VPN server no matter which wireless AP they've associated with.
VPN Server Setup
Ready to get started? Let's talk about the hardware you'll need to complete this project. First, you'll need a server to act as your VPN gateway device and control who gets into your trusted network. The machine doesn't need to be a super-powerful server. A high-end desktop might even suffice (depending on the number of wireless users you plan to support), although for such a crucial function, I prefer to use a low-end server-class device.
You need to install two NICs on the VPN gateway server, one for your untrusted wireless network and one for the trusted internal network. If you've implemented a VPN for Internet-based users, you'll be familiar with this process. Plug the wireless AP—and nothing else—directly into the untrusted network interface. Anyone associating with your wireless AP will be able to reach only your VPN server's untrusted interface and any client workstations associated with the AP. The VPN server becomes the gateway into your internal network, deciding who passes through and who gets rejected.
To communicate with your VPN server's untrusted interface, your wireless users must have an untrusted IP address assigned to them. If your wireless AP has DHCP server capabilities, you can configure the AP to hand out untrusted IP addresses to anyone who associates with it. (I recommend this approach.) If your wireless AP doesn't have DHCP server capabilities, you can install the DHCP service on your VPN server and configure it to hand out untrusted IP addresses only on the untrusted interface.
For example, let's assume that the untrusted network comprises the range of IP addresses from 172.16.30.0/24 (with a mask of 255.255.255.0) and that the wireless AP will freely hand out an IP address in this range to any device that asks for one. Also, assume that your VPN server's untrusted network interface has an IP address of 172.16.30.10.
For your internal network, assume that your organization has used the IP address range of 10.100.0.0/16 throughout the organization (with a mask of 255.255.0.0). For the network segment to which the VPN server is connected, assume that the IP addresses are in the 10.100.30.0/24 range and that the VPN server will have an IP address of 10.100.30.10 assigned to the trusted interface.
At this point, if you've inserted the VPN server between your wireless AP and the rest of your network, a wireless user can associate with your wireless AP—and that's about all. The next step is to configure the VPN server so that it can properly authenticate your users and permit authenticated users into your internal network.
To begin installing VPN capabilities on the server, select Start, Programs, Administrative Tools, Routing and Remote Access. When the Microsoft Management Console (MMC) Routing and Remote Access snap-in appears, right-click the server name in the left pane and select Configure and Enable Routing and Remote Access. Doing so will start the Routing and Remote Access Server Setup Wizard.
Microsoft has simplified the installation of a VPN server (compared with what Windows NT 4.0 involves), so walking through the wizard's screens is fairly easy. Let's take a look at each screen, starting with the Common Configurations screen, which Figure 4 shows. Choose to set up a VPN server by selecting Virtual private network (VPN) server. Click Next to proceed to the Remote Client Protocols screen, which Figure 5 shows. This screen is a bit puzzling—it doesn't serve much purpose. The wizard provides a list of protocols and asks you to ensure that all the protocols you need to support for your clients are installed on the server. If you select No, I need to add protocols, the wizard doesn't let you reconfigure your network settings. It simply quits. You also can't deselect protocols on this screen—for example, to disallow IPX over your VPN. So, if you have the correct protocols installed on your system, select Yes, all of the available protocols are on this list and click Next.
You typically implement VPNs with the Internet acting as the untrusted connection. Therefore, the next wizard screen, Internet Connection, which Figure 6 shows, asks which NIC points to your Internet connection. In this case, consider Internet to be synonymous with wireless and select the appropriate network interface. In this example, I've chosen the interface with the IP address 172.16.30.10, which is the address I defined for the connection to my untrusted (wireless) network. Click Next.
To let your wireless users communicate on your internal network, you'll need to give them an IP address within your internal network space. Some administrators like to use their primary DHCP server for this task—with or without the use of the DHCP relay agent—but I prefer to have my VPN server hand out addresses. Doing so simplifies troubleshooting should problems arise down the road.
If you want your VPN gateway server to allocate internal IP addresses to your wireless users, select From a specified range of addresses on the IP Address Assignment screen, which Figure 7 shows, then click Next. Selecting this option takes you to a wizard screen on which you can define ranges of addresses that your VPN server can hand out. Click New on that screen to access a dialog box in which you can add the appropriate IP address range to use, as Figure 8 shows. Click Next to go to the final wizard screen, which asks whether you want to use a Remote Authentication Dial-In User Service (RADIUS) server for authentication. Assuming you want to use your standard Active Directory (AD) or legacy NT domain database for authentication, answer No, I don't want to set this server up to do RADIUS now, then click Next. You've now finished your VPN server setup.
VPN Client Setup
To test your new VPN server implementation, you'll want to set up a wireless workstation or laptop and test each part of your connectivity—from the wireless AP to the VPN server on the untrusted side to your organization's trusted network.
If you boot your test station with the wireless NIC connected, you should associate with your AP. You can check your wireless manufacturer's drivers to see which AP you've associated with. Or, if you're using Windows XP, the OS should tell you which wireless AP you're connected to. Verify that your test workstation is receiving an untrusted TCP/IP address from either the DHCP service in your AP (if you've configured it to do so) or from your VPN server (if you installed DHCP).
If your test workstation has successfully obtained an untrusted IP address, you can ping the VPN server's untrusted interface by using the Ping command at a command prompt. Doing so verifies proper wireless connectivity from the workstation, through the wireless AP, and to the VPN server's untrusted interface. If you get a successful ping response, everything is working properly so far. If you don't get a ping response, troubleshoot the problem before going any further.
Now is the time to establish a VPN connection into your internal network. From the XP or Windows 2000 desktop, select Start, Settings, Network and Dial-up Connections, then double-click Add New Connection. Doing so launches the Network Connection Wizard, which prompts you for information about the connection you want to make. On the Network Connection Type screen, which Figure 9 shows, you specify a VPN connection by selecting Connect to a private network through the Internet. Click Next.
The next wizard screen prompts you for the DNS name or IP address of the VPN server you want to connect to. You probably won't have DNS name resolution available to a wireless user who hasn't been properly authenticated yet, so use the IP address of your VPN server's untrusted interface—172.16.30.10, in my example—and click Next.
The final two wizard screens are simple, asking whether you want to make this connection available only for yourself or for all users, and whether you want to share the connection with other users. Answer the questions appropriately for your situation.
Now, the fun begins. Start the DUN connection and provide an appropriate set of username and password credentials in the logon box. (The VPN server needs to verify that your user account has been granted dial-in access.) Your system establishes the VPN tunnel to your VPN server, which in turn authenticates you against the AD database or against the local accounts database. After you're properly authenticated, the VPN server allocates your test workstation a trusted IP address and starts routing your traffic to the internal network. You can verify this routing by running Ipconfig on your test workstation and checking the IP addresses that have been assigned. You should see one untrusted address and one trusted address.
Congratulations! You now have a fully functional VPN-protected wireless network that you can start rolling out to your end-user community.
Mobile Madness
You might wonder what happens to laptop users who move around the office and move from one AP to another. Because each AP gives out a specific scope of untrusted addresses, the untrusted IP address of a user who changes APs will also change. RRAS attempts to set up a secure VPN tunnel for communication with your user's device, so it won't be too keen on a device that suddenly changes its IP address. Therefore, the VPN tunnel will break. However, if you select the Redial if line is dropped option when you define your client VPN connection profile, you can be sure that Windows will try to reestablish the connection whenever it's lost.
Don't Just Plug It In
Wireless networks require particularly careful implementation. Because they're so easy to set up, the temptation is to simply plug them in and walk away. However, you should never connect a wireless AP to your network and leave it in its default configuration. If you do so, you might as well run some Ethernet cables out your office windows into the street, because you're effectively opening up your network to anyone within a few hundred feet of your office who has a wireless NIC.
Can you rest assured that your wireless data is secure within the type of implementation this article has described? I've spoken with some extremely security-conscious organizations—you know, the kind with armed guards who carry real guns and are trained to use them—and those organizations are using a VPN to protect their wireless networks. Of course, every situation is different, but if companies like that trust a VPN to secure their wireless communication, that's good enough for me.
