Known Issues with OpenVPN for PocketPC

Smartphone Stuff

The OpenVPN for Pocket PC works on PocketPC Phone Edition, but not on Smartphone.  The marketing literature for devices is sometimes ambiguous, but you can tell you have a Smartphone because there is no touchscreen.  Instead, there are only softkeys for navigation of menus.  Smartphones typically have smaller, square screens.

The challenge with Smartphone is twofold:  the UI will have to be reworked for that device's UI motif (not terribly difficult), the devices are typically locked-down by the mobile operator to prevent loading 3rd party software, and preventing the device driver from loading (this is difficult/expensive).

That being said; one intrepid user has managed to make OpenVPN for PocketPC work on a Smartphone device through a system of shortcut files (.lnk), as discussed on the forum here.

Connecting through Phone networks

There was an interaction with the Windows Connection Manager in previous builds.  Some configuration features have been provided that should help with this problem.  The key is to specify your connection provider explicitly, and to use an 'exclusive' connection.  These parameters are found on the new settings page.  I have also found that with some devices, when you need to use the 'exclusive' option, that you will be required to use the redirect-gateway config file option.  The reason appears to be that other apps which use the connection manager (e.g. Pocket IE) will sit waiting for the availability of the exclusive connection being used by the VPN, and never get it until the VPN shuts down.  The redirect-gateway appears to coax those apps to use the VPN connection instead of the direct connection (which it cannot acquire).

WindowsMobile 2003 (and 2003SE)

Should work just fine as this is mainly what I'm testing with now.  I can foresee maybe some sort of weirdness with an OEM's NIC driver or support app.  They are probably not tested in the scenario where new NICs come and go and with some on-the-fly network config changes.  Then again I haven't had any problems so maybe there won't really be any.

WindowsMobile 2005 (WM5) Stuff

WM5 included some additional security models that might present a problem with some devices.  Also I've discovered some differences in API behaviour between WM5 and 2003 (!).  I have done some spot testing on WM5 up to now, however it is difficult for me to do my primary testing on that platform because of the change to ActiveSync 4, and my lack of a copy of VS2005.  Both of these are required if I want to do any single-step debugging.  I do intend to shift my focus more strongly to WM5 as I get more of the kinks out and I'm eager to hear any feedback from the field even prior to that.

The intent is that for a low-level application you have to participate in a program that ultimately gets your code signed as 'trusted' so you can use 'trusted' APIs.  Some of this is as mundane as writing to some registry keys but it's all in the name of security.  To complicate matters, the specific model and how the device behaves is up to the OEM rather than Microsoft.  So there could well be some highly locked-down devices that will just not be able to be supported.  This could manifest itself by virtue of the TAP driver not being able to load.

WindowsMobile 6 Stuff

WM6 represents a significant rearchitecture of the operating system.  I expected this to cause the TAP driver to break, but was surprised (shocked, actually) when folks reported success (I don't have a unit with which to develop, alas).  About a year later, though, reports did come in of failures.  It seems there are two 'flavors' -- one with some undocumented 'legacy' support, and another without.  I am working on this, however. 


I have had a few requests to support the older Handheld PC devices (e.g. Jornada 720).  I would sincerely like to (I have two of these units myself), and it is technically possible, however there is a challenge in that these devices provide Winsock 1.x APIs.  The openvpn.exe uses Winsock 2, and in particular it uses overlapped sockets.  This is a significant rearchitecture of the openvpn.  I'll probably never have time to do this versus tending to bugs/features with the present code (which these days I scarcely have time for, either).

No Scripting

Windows CE does not support the notion of environment variables and some other stuff.  PocketPC does not come with a console, or command-line shell.  Consequently, the scripting options normally in OpenVPN are not supported.  I don't imagine this to be a loss, but if anyone thinks this is a show-stopper loss of functionality let me know, and why, so an alternative can be produced.  The connection manager app does a sanity check on the config file and will issue a warning if it things there are some scripting options specified.

Config Dir and Log Dir

I need to implement some sanity checking code, and the browse buttons (...) don't do anything.  I would leave them at the default, but if you must change them, the Config dir is the location where config files are expected, and is used to populate the menu.  The Log dir is used only when there is not a log option already specified in the config file.  In that case a log option is automatically provided which places a log file in this directory, based on the config file's base name, with the extension changed to .log.

Using ActiveSync Internet pass-through for tunnel

This works, but you must keep in mind that this connection only forward TCP connections, not UDP.  So you will need to use 'proto tcp' for this style connection.  This is a limitation imposed by ActiveSync, rather than openvpn.