Consultants and systems integrators can get answers about the VPN's role in enterprise wireless, learn where to make best use of VPNs, and learn how to smooth over conflicts between WLAN roaming and VPN tunnels in this tip, courtesy of the Wireless Security Lunchtime Learning series on SearchNetworking.com.
How virtual private networks can helpVPN tunnels have long been used to provide confidentiality and integrity for data over untrusted networks like the Internet. Today, many companies use tunnels to secure traffic from remote workers to a VPN gateway at the edge of the company network. That gateway is responsible for authenticating users and controlling which destinations can be reached.
Today, VPNs are also being leveraged for endpoint security enforcement. Remote devices are checked for compliance before being granted network access. For example, a worker on a public PC may only be permitted to check email, while a worker on a company laptop may be given access to sensitive servers. A laptop missing patches or infected with a Trojan may be directed a quarantine server for remediation.
Wireless users can benefit from these same security measures.
- Like WEP or Wi-Fi Protected Access (WPA) version 1 or 2, VPN tunnels can obscure traffic sent over the air. WEP/WPA protect only the airlink, while VPN tunnels extend over any intervening network. That may not be important "on campus," but it is critical when using residential or hotspot WLANs.
- Like WPA-Enterprise, VPN gateways can authenticate wireless users, based on passwords, two-factor tokens, smart cards or certificates. But 802.1X provides all-or-nothing access to the LAN, while Layer 3 and 4 VPNs can limit reachable destinations and applications. More granular policies can be important in large WLANs with widely-varied user communities.
- Depending on the product, both WPA-Enterprise and VPNs may enforce endpoint security. However, a VPN can more easily enforce one consistent set of rules, using one agent platform, across all kinds of networks, local or remote.
- Finally, both technologies require client configuration, user identity management and (in some cases) software installation. VPN products have been around longer than 802.1X and many therefore have more extensive central policy administration and broader client OS/platform support.
For example, PPTP is the weakest common VPN protocol, but it is also easy to use. PPTP clients are embedded in many operating systems, including Pocket PC and Mac OS, and little configuration is required. At the opposite end of the spectrum, IPsec offers robust security, supported by complex configurations and installed VPN clients. In between lays SSL VPN -- more secure than PPTP, and easier to deploy than IPsec.
This diversity makes it hard to compare VPNs to each other, much less to WPA. But we can still make general observations about how VPNs hinder wireless.
- WEP and WPA protect all link layer data, including LAN broadcast and multicast. VPNs leave more traffic exposed, and it can be hard to prevent "leakage" before the tunnel is launched. This can be especially true for devices used in both trusted (on-campus) and untrusted (hotspot) WLANs, where different VPN policies may be needed.
- VPNs may dovetail with remote security measures, but tend to be picky about network topology. For example, WPA-Enterprise can assign VLAN tags to wireless stations, supporting LAN access controls that are location and subnet independent. VPNs often use virtual IPs for this purpose, which can require route and filter changes across your network.
- Although WPA-Enterprise incurs delay when wireless stations roam, VPN tunnels usually break when stations roam between IP subnets. Putting all wireless users in a single subnet can avoid this, but can be impossible in very large WLANs.
- IPsec VPNs that require specific client software can be impractical in WLANs with guests or devices that cannot run off-the-shelf clients (e.g., wireless scanners, smartphones, VoWi-Fi handsets). However, similar problems can face WPA-Enterprise installations that require a specific 802.1X supplicant.
So, how can you circumvent VPN challenges on your customers' wireless LANs?
- Combine your VPN client with endpoint security software that checks to make sure the VPN is running whenever a wireless link connects, and breaks the wireless connection if the VPN tunnel goes down. Configure personal firewalls to stop non-VPN traffic from entering or leaving through wireless.
- VPN disruption due to roaming may not be an issue for users at single-AP home WLANs and Internet cafÉs. Workers who need to stay connected when moving between locations may want a mobile VPN. Mobile VPN products, available from NetMotion, Columbitech, Ecutel and AppGate, provide tunnel and session persistence when clients move between networks. Some even queue traffic received when a device moves briefly out of range. Supporting technologies vary, but mobile VPNs typically require client software.
- When using a VPN to secure on-campus workers, use a wireless gateway or switch that provides "mobility" or "subnet roaming." Such features are proprietary, but often let VPN clients keep the same virtual IP when roaming between subnets. However, application disruption may still occur when stations leave wireless coverage (e.g., inside elevators, between buildings).
- Finally, to support guests and other devices that cannot run VPN client software, use an SSL VPN or captive portal. Captive portals don't encrypt data, but can be used to control and track network usage. SSL VPNs encrypt data by using Web browsers as client platforms, and may thus be feasible even on guest devices.
About the author
Lisa Phifer owns Core Competence Inc., a consulting firm specializing in network security and management technology. Core Competence produces The Internet Security Conference (TISC), an annual symposium for network security professionals. Phifer has been involved in the design, implementation, and evaluation of data communications, internetworking, security and network management products for nearly 20 years.
This tip originally appeared on SearchNetworking.com.