Are there ready-made, off-the-shelf solutions for integrating WLAN technology into existing IP VPN product offerings. What are the key pitfalls relative to supporting VPNs riding on W-LAN infrastructures? Do WLANs lend themselves for supporting a form of mobile VPN-roaming?
There are many commercial products that combine VPN and WLAN technologies. For example, WLAN stations running Windows XP can use the built-in VPN client to secure frames sent over wireless, through an AP, to a VPN gateway somewhere upstream. VPN clients like those sold by SafeNet, Certicom, SSH Communications, and Funk can be used over wireless as well. Visit the website of nearly any VPN/firewall vendor and you'll find white papers or tech notes describing how to use VPN to secure wireless traffic.
There are also new products that focus exclusively on the challenges posed by wireless. Transport-layer VPN products from vendors like Columbitech and NetMotion enable secure roaming and session persistence for wireless devices that move between networks - for example, from GPRS to Wi-Fi. Network-layer WLAN gateways from vendors like Bluesocket, Cranite Systems, ReefEdge, and Vernier enable secure roaming between WLAN segments - for example, letting an IPsec tunnel persist when a station roams from AP#1 (802.11b) to AP#2 (802.11a).
From these descriptions, you can tell that one of the problems with combining VPN and wireless is persistence. IP-layer VPN tunnels are bound to IP addresses. When a station roams, it (at least briefly) loses the link. When link state changes, the station's IP address may change (DHCP renew.) Any IP-layer tunnel bound to the old address is broken, replaced by a new tunnel, bound to the new address. Tunnel reestablishment may be automated, but takes time and resources. TCP sessions may timeout or get disconnected. Users get frustrated, and if they get too frustrated, they turn off the VPN client.
Solutions fall broadly into two camps. WLAN gateways often act as distributed VPN gateways, using tricks to let the station keep its IP address as it roams. Higher-layer "mobile VPNs" make stations IP-independent by assigning persistent virtual addresses, proxying application sessions, and queueing traffic when stations go unreachable. These are gross generalizations - I strongly recommend visiting vendor Web sites to learn how each product really works. There are other challenges associated with combining VPNs and WLANs. Reusing your existing VPN client makes a lot of sense in a company network where every laptop already has a VPN client. But WLAN operators may have no control over software installed on guest or student laptops, and some wireless devices (i.e., PDAs) may not support your existing VPN client. VPN gateways are usually sized to support relatively low-speed client tunnels - 54 Kbps dial or 1 Mbps broadband - so 11 or 54 Mbps WLANs can require more horsepower per tunnel. Because WLANs are typically used as a network access link, they inherit common issues associated with remote access VPNs - for example, NAT traversal and user-level authentication limitations. This doesn't mean that VPN is not a useful tool for securing WLAN traffic. It just means that there is room for innovation to streamline VPN over wireless, making these VPNs more efficient, transparent, and manageable.