As I wrote last month, Mobile VPNs help workforces connect to company networks not just securely but also persistently. Unlike conventional VPNs, Mobile VPNs let users keep the same virtual IP address when roaming from hot spot to cellular to office, preserving application and login state. In this tip, I explore the business problems addressed by Mobile VPNs and share my experience using NetMotion Mobility XE on a Motorola Q Smartphone.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Who uses Mobile VPNs?
Mobile VPNs target workers who spend most of the day away from a desk. Typical users include public safety (e.g., police, fire), field service (e.g., delivery, repair), medical professionals (e.g., doctors, nurses) and salesforces. These mobile professionals require persistent access from numerous locations that change throughout the workday.
Mobile VPNs can survive wireless gaps, roaming delays, and interface changes that wreak havoc on conventional VPNs. They cannot work magic -- for example, a repairman cannot search a database back at the office while standing in a wireless coverage hole. But he can drive through many dead-spots while uploading his last work order and downloading the next, a feat that would require repeated tunnel restarts, logins, and application reconnects with a conventional VPN. Mobile VPNs give users a good shot at picking up where they left off when their device lost connectivity or hibernated.
Mobile VPNs can also help optimize use of available connectivity. For example, a saleswoman at a hotel with Wi-Fi and 1xRTT may prefer using Wi-Fi because it is faster. She may also save time by automating hot spot login instead of stopping her VPN for manual login. While she taxis to her next stop, she may compress Web graphics over 1xRTT to reduce latency and wireless data usage. Support for such features varies, but Mobile VPNs aim to make secure mobile access not merely feasible but more usable.
Today, expanded device capabilities and high-speed wireless are generating broader interest in Mobile VPNs. Office workers are spending more and more time connected to the company network, from checking email on a smartphone to working from home. If your workforce is starting to feel pinched by mobility constraints of other VPNs, a Mobile VPN may help to reduce frustration and improve productivity.
Taking a test drive
I believe in using trials to learn what technologies can and cannot do -- whether they will really benefit a business and precisely how they should be deployed. So, last month, I decided to take NetMotion Mobility XE out for a 30-day test drive.
This is not the first time I have tried a Mobile VPN, but I have not really needed one -- until now. 3G has finally reached the point where I use both Wi-Fi and EV-DO regularly. On a laptop, I waste time deciding which to use and restarting my security session as I move between public and private networks. Furthermore, I recently replaced my older GPRS/Wi-Fi Pocket PC with a Motorola Q Smartphone. I could have used the Q's embedded IPsec client but did not relish restarting my VPN whenever I peeked at my email. A Mobile VPN might help me address both issues while providing consistent security across all of my mobile devices.
Mobile VPNs are available from many vendors, but my needs narrowed the field to those with Windows Mobile 5.0 Smartphone support. I chose NetMotion from that short list to conduct a 30-day trial. Before making any significant network investment, I strongly recommend testing multiple candidates. But trying one product is a good way to get your feet wet before launching an RFP and larger comparative field trial.
NetMotion is composed of three required components: a central Mobility Warehouse that stores policies, one or more Mobility Servers that relay tunneled traffic, and a Mobility Client on each user's device.
- Warehouse and Server software run on Windows 2000 or 2003 Servers, sized for the number of clients. I co-located both on a Windows Server 2003, setting up a minimum system for 100 clients in about 30 minutes. I spent another 30 minutes tweaking my network infrastructure: adding a "NetMotion Users" group to Active Directory, adding a NetMotion IP pool to my DHCP server, and configuring my firewall and access router to let NetMotion's UDP tunnels reach my server. A trial can take shortcuts for quick testing while helping you evaluate how servers should really integrate into your network. For example, I reused Windows accounts for trial password authentication, but I would probably interface NetMotion with RADIUS/802.1X or ACE/SecurID in a permanent deployment.
- Client software runs on Windows XP/2000 laptops or tablets and mobile devices that run Windows Mobile 2003 or 5.0 for Pocket PC and Mobile 5.0 for smartphone. I installed NetMotion clients on a pair of XP laptops, my old iPAQ Pocket PC, and my new Q smartphone. The only details the user must supply are public-facing IP address(es) used to reach your NetMotion Server. (When using NetMotion inside your own LAN, a DHCP server can supply this tidbit.) I did not encounter any client software conflicts, but this was a very small trial and I did not try to stray beyond NetMotion's published compatibility list.
My laptop connections to local Ethernet and Wi-Fi LANs were successful from the start. The client can relay Windows username and password for single sign-on, but I chose to be prompted for login. A tray icon turns green whenever the client detects a usable connection and establishes an AES-encrypted tunnel to the server. It changes to yellow when connectivity is lost. The client and server then try to keep application sessions alive and resume tunneling at the earliest opportunity.
I started a continuous ping, telnet, and ftp while plugged into Ethernet; started an 802.11g connection; then unplugged Ethernet without missing a beat. When I moved out of Wi-Fi range, my laptop lost a few pings, but telnet and ftp sessions continued without complaint when Wi-Fi resumed. Those sessions remained alive as I moved between access points; I could even remove and replace my Wi-Fi card. But if I stayed away long enough, some application inactivity timers were tripped -- NetBIOS shares seemed especially sensitive.
When I tried NetMotion on my Q, I ran into a few puzzles. Through tech support, I learned that NetMotion behaves somewhat differently on smartphones. On a laptop, NetMotion (re)connects as soon as a network interface is available. On the Q, NetMotion waits to reconnect until the first application tries to send data (i.e., initiates a wireless data connection). This conserves precious battery power on smartphones that are on all the time but send data only intermittently. But it can also cause your first Web, email or other request to time out. I found this tradeoff reasonable -- tricks to save power are quite popular among smartphone users, but I did find NetMotion less transparent on the Q as a result.
This aside, I could reliably start file downloads and streaming audio/video sessions while connected to EV-DO, moving through dead-spots without session loss. Downloads continued after each pause, and shorter gaps were even hidden by video buffering. But I stumbled into one scenario where downloads did not auto-resume. When exiting flight mode, any suspended download does not resume until a new application sends data, triggering wireless network and tunnel reconnect. I would rather see the Q return automatically to the state it was in before flight mode, but full resumption is easy once the user understands what is required.
Recall that I wanted a Mobile VPN to apply consistent security across all of my devices and help me deal more efficiently with multiple networks. To accomplish this, I used NetMotion's Web console to configure settings, applied to servers, devices and users.
For example, I used server settings to supply DHCP and DNS addresses, require NTLM authentication, and permit access by everyone in the NetMotion Users group. I used global client settings to require 128-bit AES and select the fastest available interface. I created a separate class to selectively enable Web acceleration on my PDAs. I created two groups to give one set of users more discretionary control over VPN use, including permission to invoke bypass mode and use pass-throughs. These are just a few of many settings that can be applied using the console and stored in the NetMotion Warehouse.
Many VPN users are familiar with bypass and pass-through. Bypass is often used to log into a hot spot before launching a VPN tunnel. Pass-throughs permit cleartext to/from selected IP/port pairs (i.e., split tunneling). Pass-throughs are initialized by config files installed with the client, then customized through the console. However, static IP/port filters go only so far. Some companies prefer filters that adapt to current conditions -- for example, allowing port 443 to a given URL when associated to a known hot spot, and then only when the VPN tunnel fails to connect. An optional Policy Management module provides this more advanced control over VPN tunnel filters. I did not use this during my trial, but I encountered hot spots where such policies would have been useful.
Instead, most of my trial time was spent poring through NetMotion's monitoring screens. Server status let me eyeball the number of connected clients and login failure logs. Client provided searchable real-time access to individual connection and device status, including quarantined devices and users. For example, I used the New Device list to review what NetMotion learned about each new device before moving it to another registered device class to enforce appropriate security and traffic policies. I also used client status to immediately disconnect and persistently quarantine selected devices and users. Quarantine can be helpful when a device is lost, stolen or otherwise retired -- for example, when I had to return a defective Q (it refused to boot) to the factory without wiping it clean. Quarantine can also be helpful to depreciate a user account while monitoring login attempts to see whether anyone tries to use it.
Even though I have been following Mobile VPNs for years, this roadtest gave me fresh insight into current capabilities and deployment considerations for new mobile devices. I hope that sharing my trial experiences will help others get a better feel for what Mobile VPNs like NetMotion have to offer. To learn more about this topic, consult the links included in last month's tip.