Using a Linux L2TP/IPsec VPN server with Windows Mobile and Pocket PC 2003

Last update: May 21, 2008



1.1 Introduction

I have made the following webpages on using L2TP/IPsec with Linux:

The page you are now reading describes how you can use the built-in VPN client of Windows Mobile 6, Windows Mobile 5.0 and Windows Mobile 2003 for Pocket PC devices to connect to a Linux Openswan server. The remainder of this text will refer to "Windows Mobile", "Pocket PC" or "PPC". I assume you are already familiar with setting up Openswan with L2TP/IPsec. If you are not, it's probably a good idea to start with reading this page. It includes information on setting up the Linux side. The other pages contain specifics on several L2TP/IPsec clients which are available for desktop Windows versions and Mac OS X.

Preshared keys are easy to configure on Windows Mobile but certificates are much more secure. I have made a program P12imprt that can import a certificate from a file. It greatly simplifies the process. Unfortunately it seems that Openswan has a problem with large certificates when a Windows Mobile client connects. Windows Server 2003 does not have this problem (more information).

I have tested with the Windows Mobile emulator. I have also received reports of people who can connect with an actual Windows Mobile device to an Openswan server. If you too used this information, let me know if it worked or not, because I do not own a Windows Mobile device myself!

1.2 Author

The author of this document is Jacco de Leeuw. Corrections, additions, extra information etc. are much appreciated.



2. Contents

3. Background information

The following platforms ship with a built-in VPN client that supports both L2TP/IPsec and PPTP:

These platforms only support PPTP and do not support L2TP/IPsec:

IPsec is generally regarded to be more secure than PPTP. There is a catch though: the IPsec client included with Windows Mobile can only be used in combination with another protocol called L2TP. With the built-in client it is probably not possible to use 'pure' IPsec without L2TP. If you really need pure IPsec (for instance when your VPN server does not support L2TP/IPsec) or when your Windows Mobile version does not support L2TP/IPsec, then you should buy a third-party IPsec client.

Windows Mobile supports certificates and Preshared Keys (PSKs) as authentication methods. Although certificates are more difficult to use than Preshared Keys (PSKs), they provide additional security (through RSA) and they do not require fixed IP addresses or a PSK that has to be shared by all users (see also this overview).

Most VPN clients support importing certificates through PKCS#12. Windows Mobile 6 supports this but older Windows Mobile versions do not. The "Certificates" application in the System menu can only delete(!) certificates, not install them. The only approved way (according to Microsoft) to install certificates and private keys on Windows Mobile 2003 and 5.0 is through Windows 2000/2003 Server's Certificate Services in a process called "web enrolment". This is not a very attractive option if you want to generate your certificates on a non-Windows Certificate Authority (CA) or if you use a non-Windows VPN server such as Linux Openswan. So I had to write a program (P12imprt) which allowed me to import a certificate (and private key) from a file. Besides, the procedure for installing a certificate on Windows Mobile through web enrolment is not very user friendly.

I used the "Microsoft Device Emulator", not an actual Windows Mobile device. The Windows Mobile emulator uses NAT to piggyback on the network connection of the host computer. The NAT-T patch for FreeS/WAN (and Openswan / Strongswan) does not support PSKs, but the native IPsec implementation included with kernel 2.6 ("NETKEY") works. Connecting to a Windows  Server 2003 also works.

Back to Contents



4. L2TP discussion

The big question of course is: why would you want to use L2TP with the Windows Mobile? Why is pure IPsec not enough. The answer is that you need a mechanism to acquire virtual IP addresses from the internal network, so that the client appears to be the internal network. Examples of such a mechanism are: DHCP, manual configuration, and L2TP/IPsec.

There are several reasons why one would choose L2TP over pure IPsec. Most versions of Windows Mobile ship with a built-in L2TP/IPsec client, so it is free. Another reason is that L2TP/IPsec is an official IETF standard. Other users may prefer a third-party client, because the vendor will provide support.

Back to Contents


5. Linux configuration

Configuration of the Linux side is basically the same as described on my main L2TP/IPsec webpage. There is one gotcha. Windows Mobile only supports MS-CHAPv1 and MS-CHAPv2 as authentication methods for PPP when used with L2TP/IPsec. It does not support PAP or CHAP (at least for L2TP/IPsec; I don't know about PAP/CHAP support for modems). However, some (older) Linux distributions do not support MS-CHAP. More information about this issue can be found here.

Windows Mobile uses leftprotoport=17/1701 and not leftprotoport=17/0 (as explained here).

Back to Contents



6. Configuration with Preshared Key

The next three sections apply to Pocket PC 2003 / Windows Mobile.

Windows Mobile supports both Preshared Keys (PSKs) and certificates. Below is the procedure for PSKs. It is reasonably straightforward because PSKs are fairly easy to use. (Note that if you use the Windows Mobile emulator to connect to a Linux VPN server, you should use a Linux kernel with NAT-T support).

First, you will have to have access to the network, e.g. the Internet. On an actual Windows Mobile device this may be different or not even needed. On the Windows Mobile emulator I had to do the following:

At this stage you should be able to access the Internet (or at least your network), for instance, you can surf to websites with Pocket IE. Now it's time to actually add the VPN connection:
The configuration for Windows Mobile based Smartphones is slightly different. You enter the same details but the user interface is different due to the Smartphone paradigm. There are also two extra configuration options: you have to indicate which network is the "Source network" and which one is the "Destination network". According to Microsoft, these are typically "The Internet" and "The Work network".

There might be a way to configure all this automatically using a CAB file or an XML template for the Connection Manager. I have not looked into this.

Back to Contents



7. Starting a VPN connection


Any hostname with a dot in it is considered to be on the local network. In many cases (testing for instance) this is not want you want. In such cases, you will need to add the IP address to exceptions, as mentioned above.

Here's how to set up the L2TP/IPsec connection on Pocket PC 2003 (see below for Windows Mobile 5.0, Windows Mobile 6 and Smartphone):
The VPN client will also dial out automatically when you use a network application. For instance, when you enter a URL address in Pocket Internet Explorer. Or use the Terminal Server client, etc.

The procedure for Windows Mobile 5.0 and Windows Mobile 6 is slightly different (it also works on Pocket PC 2003):
The procedure for Windows Mobile based Smartphones is again different:
If the connection fails or a time-out occurs you get a fairly generic error window: "VPN server problems. Verify your username and password, and try again. If the problem continues, turn the device off and try again". (Typical for Microsoft! :-) This is a catch-all error message and its cause can be anything: a missing certificate, wrong username, wrong password, VPN server cannot be found, incorrect IP address, hostname does not resolve etc. There is very little logging and error reporting on Windows Mobile devices. It's probably easier to start by examining the logs on the VPN server. You could even follow Microsoft's advice and turn the device off and on. One user reported that soft-resetting the Windows Mobile device may resolve the problem (remember: a hard reset wipes all your data so that is probably not what you are looking for).

If you find that the VPN is disconnected immediately after you try to access network resources on the VPN, you may have got to fiddle with your device's Connection Manager settings. The Connection Manager that Microsoft implemented has a flawed logic and defies Internet routing standards. It has led many people to despair. Some tips are available on the Pocket PC Magazine website.

Back to Contents



8. Configuration with certificates

8.1
Pocket PC 2003, Windows Mobile 5.0 and Windows Mobile 6

Configuring an L2TP/IPsec connection with authentication based on certificates works nearly the same as with a PSK. The difference is that you need to install a personal certificate and a root certificate on the client. You also need to install a server certificate and a root certificate on the Openswan server. The VPN connections on both the client and the server have to be configured for authentication based on these certificates.

In the settings of your VPN connection, set "Authenticate IPSec/L2TP connections using:" to "A certificate on this device". The VPN client will figure out automatically which certificate to use, should you have installed multiple certificates. The Openswan server has to be configured for certificate authentication as well.

Next, you will need to install a certificate to your Windows Mobile device. There are three ways of installing private keys and personal certificates on Windows Mobile:
Back to Contents



9. No AES, DPD or IPCOMP

Pocket PC 2003 and Windows Mobile 5.0 do not support AES. They will propose ISAKMP and IPsec SAs with 3DES encryption.

Windows Mobile 6 has added support for AES. It is supported with SSL/TLS, WiFi (WPA2), Storage Card (i.e. external flash memory) encryption and "Data Protection Application Programming Interface" (DPAPI). Alas, Microsoft did not see it fit to support AES with L2TP/IPsec VPNs...

DPD and IPCOMP are also not supported.

Back to Contents



10. Network ActiveSync and connecting to Exchange

Once your VPN connection is working you can use it as if you were connected directly to your internal network. For instance, you could use it for ActiveSync or Exchange.

You can probably use the L2TP/IPsec connection to Activesync with a server on the internal network. I have not tested this. According to Certicom, it should work. There is also an article by Al Jarvi that describes how to do it over a PPTP VPN. The procedure for an L2TP/IPsec VPN should be very similar.

You can also use the L2TP/IPsec tunnel to connect to an Exchange server (or any other messaging server) behind the Linux VPN server. In my opinion this is more secure than forwarding SSL (port 443) to the webserver / mailserver for webmail / ActiveSync / Outlook Web Access / Outlook Mobile Access / whatever.

Back to Contents



11. Windows Networking (WINS etc.)

Windows Mobile supports the SMB / CIFS protocol ("Windows Networking"). It has a built-in client which can be used through the L2TP/IPsec tunnel. For instance, if you open File Explorer and connect to a network path (e.g. "\\SERVER\share") then the client will contact the fileserver SERVER and connect to its share.

I have not done extensive testing. When I used the VPN to connect to a remote Windows Server 2003 the Windows Mobile device showed the filenames in File Explorer but it got into some kind of endless loop.

If you don't intend to use Windows Networking you will find that Windows Mobile generates quite a bit of SMB network traffic. If you have to pay for this traffic (e.g. because you are on a GPRS or UMTS connection) then it appears that you can disable this spurious Windows Networking traffic by removing all ms-wins parameters in /etc/ppp/options.l2tpd. I did not see an option in Windows Mobile itself to disable it (on desktop Windows you remove the "Client for Microsoft Networks").

See also the general remarks on Windows Networking on my main VPN page.

Back to Contents



12. Discussion


12.1 The x86 Windows Mobile emulator

There is an older Windows Mobile emulator, the one included with eMbedded Visual C++ 4.0. It has a feature to save the emulator's state, so that you can continue later (e.g. when you want to save the certificate that you got through web enrolment). However, this is badly implemented. When you close the emulator, you should select "Save emulator state" instead of "Turn off emulator", which is the default. A saved state file with the extension .vsv will then be created in "/Documents and Settings/yourusername/Application Data/". Reloading this state, however, is more difficult than it should be. You need to edit the emul.cmd command included with the Windows Mobile SDK and add a parameter /VMID to the (already very long) command line:

PBEmulator.exe /LOTS /OF /PARAMETERS /VMID "{BA6E5257-4322-4343-ABE9-3D8328399F9C}"

Where the number BA6... is the GID of the saved state file with extension .vsv. Fortunately, this has been fixed in the emulator included with Visual Studio 2005 and the Microsoft Device Emulator which is also available separately. In the new emulator it is much easier to load and save emulator states.

12.2 MTU problem?

I had the following problem in the x86 based Windows Mobile 2003 emulator. It appears that this issue has been resolved in either the Microsoft Device Emulator or Windows Mobile 5.0. I don't own a real Windows Mobile device so if you have this problem with certificates, let me know.
The IPsec connection fails in some instances when connecting to Openswan or the kernel 2.6 IPsec implementation in combination with certificates. Windows Server 2003 does not have this problem. I have not yet been able to pinpoint the exact cause. Factors that probably contribute to this problem:
The sample certificate included in my P12imprt zipfile contains very short "Distinguished Names" (USR, CACN etc.). With this particular certificate the connection is set up without problem. Larger names (say, about 75 characters in the CA name, which is 105 bytes in ASN.1 encoding) do not work. However, I am using NAT-Traversal because that is what the Windows Mobile emulator uses. It may well be that the problem does not occur on a real Windows Mobile  2003 device when it is not behind a NAT device. The problem seems to occur when the packets sent by Windows Mobile 2003 are fragmented. Windows Mobile 2003 does not send these to UDP port 4500 on the Openswan but a floating port to which Openswan is not listening. When the same (large) certificate is used on Windows 2000 Professional, the L2TP/IPsec connection works fine: Windows 2000 sends all fragments to port 4500 and it floats its own sender port. This shows that there is nothing wrong with the certificate itself. It tried Openswan's "overridemtu=" parameter but it did not seem to have any effect.

The symptions that you may see are for instance reports of "no suitable connection" and "malformed packet". Because of the fragmentation, Openswan receives only parts of the packet. Thus the CA certificate name in the Certificate Request payload may for instance be garbled. When you increase the debuggin by setting plutodebug="parsing" in ipsec.conf, you might see the actual error message: "error in DN parsing: RDN is not a SET". Openswan tries to decode the ASN.1 string sent by Windows Mobile 2003 but the string is garbled, so it fails.

The problem described above occurs both with FreeS/WAN and NETKEY+Openswan (i.e. pluto). I have not tried NETKEY with the KAME utilities (racoon). So I don't know if the cause of the problem is in the IKE daemon or somewhere else.

12.3 Assorted remarks

The web enrolment procedure mentioned above is very convoluted. The import utility approach seems better (if you prefer to use a non-Windows CA and VPN server).

One final remark: after the Windows Mobile L2TP/IPsec client has logged in, I noticed that it tries repeatedly to resolve the hostname isatap. ISATAP is an IPv6 tunnelling mechanism for IPv4 networks (kudos to Microsoft for supporting IPv6 in Windows Mobile). But if you don't use IPv6 this may generate a bit of network traffic. Perhaps adding a dummy ISATAP hostname to your DNS will fix this?

One interesting thing I noticed is that Windows Mobile 5.0 and higher stop their IPsec daemon after a disconnect or a timeout. Nmap confirms that nothing is listening on UDP port 500 and 4500, which increases security. Not even Windows XP does this!

Back to Contents



13. Third-party clients for Windows Mobile

There are other VPN clients for Windows Mobile. None of them support L2TP/IPsec. Pocket PC 2003 and/or later Windows Mobile versions are not always supported. Some clients may have the restriction that they are only to be used with a VPN server of a particular vendor. Using a third-party client may have advantages over the built-in client. Getting technical support from a specialised vendor, for instance.

Open source clients:
Closed source clients:

Back to Contents



14. Revision history

May 24, 2007: Added some info on Windows Mobile 6. No AES with L2TP/IPsec.
Oct 29, 2006: Saw no MTU/fragmentation problem with WM5, NAT, large certs and the new 2.0 emulator.
Oct 17, 2006: Successfully tested on WM5 emulator (got a faster CPU). Added references to NetMotion and Bluefire.
May 2, 2006: There is now an OpenVPN port for Windows Mobile under development.
Mar 21, 2006: Finally I found out how to connect on WM5.0 (thanks Kiko!). It times out on the emulator, though.
Feb 9, 2006: P12imprt available. Import PKCS#12 certificates to Pocket PC 2003 or Windows Mobile 5.0!
Feb 5, 2006: PFXimprt available. Import PKCS#12 certificates from a file to Windows Mobile 5.0!
May 12, 2005:
Windows Mobile 5.0 announced. Supports PFXImportCertStore(). New emulator released.
Oct 14, 2004: Certicom Movian will be discontinued.
Jun 12, 2004:
NAT-T with PSK may work when the native kernel 2.6 IPsec is used.
Jun 9, 2004: New MS-CHAP parameter.
Feb 23, 2004:
Professional Edition (iPAQ 1900 series, upgraded PPC2002 models) does not support L2TP/IPsec.
Feb 3, 2004: Pocket PC 2003 probably does support PAP/CHAP for dial-up Internet, but not for L2TP/IPsec.
Jan 17, 2004: Problem does not occur with Windows Server 2003. Fragmentation/NAT-T problem? PPC sends packets to floating port(!)
Jan 7, 2004: Problem does not occur when certificate is used for user auth in Pocket IE. Makes a bug in Crtimprt less likely.
Dec 28, 2003:
Everything works! But a problem occurs when the DN in the CA cert is longer than about 75 characters. Bug? MTU problem?
Dec 23, 2003: Managed to import client and CA certificates. But PPC sends a partly mangled Certificate Request payload :-(
Nov 22, 2003: Managed to import private key (PVK). Importing certificates remains to be done.
Nov 9, 2003: Received reports from 2 different persons who have implemented key import programs but they are not allowed to release them :-(.
Nov 8, 2003: Described outline for private key import program.
Nov 7, 2003: Forgot to mention how to copy over certificates from Windows Server to Openswan.
Nov 6, 2003: Page created. Initial success with certificate obtained through web enrolment.

Jacco de Leeuw