An internal conversation we’ve been having over the last couple of days… What do you call a plug-in that is not thin, but not really thick either? We’ve been kicking around ideas on how to best describe what the Citrix iPad Receiver is and does. A terminal service? A partially thick plug-in? Browser replacement? You get the drift – nothing fits quite right. Anyway, the iPad Receiver is pretty interesting in that it completely isolates the iPad from any direct network connectivity (the Access Gateway is talking to the network) while providing useful access to enterprise apps across nearly all link types (WAN, DSL, 3G, cable, etc.). It’s not a thin client, but not a thick one either.

Mobile device network connections represent several challenges to an IT department. Essentially, they are consumer devices that easily double as business tools. Because of the dual functionality, there are limitations that need to be understood and mitigated. But before that, let’s look at the remote network access options for a mobile device:

There are four basic ways to remotely access an enterprise network with a mobile device:
1. Direct connection to the network – hopefully through an authenticating firewall. In this case, network shares and Web apps are accessible to the remote user, usually communicating in cleartext. There are many options to fix this, all of which are a huge improvement including SSL VPN products that start at less than $1,000. If users are accessing your network with a direct connection… Stop! Now!

2. Clientless VPN (also called CVPN or Web VPN). This method uses an HTTPS browser session and a reverse proxy (proxy external to internal) to provide Web access to applications. Initially, this approach was considered the safe way to allow for home PCs to access OWA and Sharepoint since there never is a direct connection between the user device and the network. Unfortunately, simple HTML easily traverses the CVPN, and complex Web 2.0 technologies don’t, you need a…

3. Full VPN tunnel – LAN extension. In this case there is a full layer 2 or 3 tunnel to the network. This option offers the most flexibility – everything, including complex Web apps, just works with little configuration and management overhead. Yet, IT managers tend to shy away from opening up a full layer 3 tunnel to the network. The requirements for advanced authentication, data leak prevention and authorization limitations are expensive and tend to add significant administrative overhead. This becomes more dangerous if deployed as a disaster recovery strategy as users will access the network with home PCs and just domain credentials – unless the organization is willing to lay out a pile of cash for two-factor solutions.

4. Proxy connection. Create the experience that you are directly connected to the network, but aren’t. Tools like XenApp, Microsoft RDP, VNC, etc. allow the user to exchange screens, mouse and keyboard, but run the application remotely. Citrix SG, AG and MS TSGateway act as the “barrier” that prevent actual data from lingering on the mobile device.

Customers are telling us they definitely don’t want option 1 (and shouldn’t). Option 2 is workable only for simple Web apps and a few supported complex apps like Outlook Web Access and Sharepoint. Option 3 entails too much risk. Leaving option 4 as the safest choice (although it can be more expensive that the others). By using a proxy connection, you remove many of the traditional vulnerabilities and protections required with using a full VPN tunnel (memory protection and wipe, disabling Bluetooth, USB tethering, blocking internal data storage, etc.). Most of these features are found in mobile platform management products. Do you want your VPN provider to become your platform management vendor (or vice versa)? But that’s the topic for my next post. Stay tuned!

Full disclosure: I am a Citrix employee and as an Access Gateway product manager can definitely be accused of having an axe to grind here, but my intention is to maintain impartiality – feel free to point out any failings in my logic.