Using a Linux L2TP/IPsec VPN server with Windows 2000/XP

Last update: Mar 10, 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 Windows 2000/XP with Openswan. It assumes 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 (the first one in the list). It includes information on setting up the Linux side. The other pages contain specifics on several L2TP/IPsec clients which are available for Windows and Mac OS X.

As mentioned on one of those webpages, Windows 2000/XP can be configured to use IPsec without L2TP. See Nate Carlson's webpage for that. This page, however, is about using IPsec with L2TP.

There are basically two methods of authenticating Windows 2000/XP clients in IPsec VPNs: Preshared Keys (PSKs) and X.509 certificates. If you have at least one Windows XP client, I recommend that you start with a PSK and test it with that Windows XP client. It should be easier to do than setting up certificates. Once you got a basic setup working, you can proceed with certificates. On Windows 2000 clients, however, it is more difficult to configure a PSK. So if you only have Windows 2000 clients, I suggest that you skip PSKs altogether and use certificates. Note that if you want to use PSKs then either each client shares this single PSK (not recommended for security reasons!) or each client has its own PSK but is also required to have a fixed IP address. For testing purposes this should not be a problem. Fixed IP addresses are not required for clients which use certificates. Don't forget to disable the PSK configuration files once you switch to certificates! Openswan will get confused if there are PSK and certificate configuration files for the same client / IP address. The PSK configuration will get the upper hand.

There is a snag, however. Microsoft believes that certificates should only be used for authenticating computers, not users (never mind that third-party clients such as SSH Sentinel and PGPNet authenticate users with certificates just fine!). This means that the certificate of the user has to be imported as a 'local computer certificate' (requires Administrator privileges). The result is that the certificate is shared by all users on the client machine (if there is only one user this should not be a problem of course). You can use different usernames and PAP/CHAP passwords to distinguish the users on a client, but passwords provide weaker security than user certificates. One final remark: I believe it is not possible to store the 'local computer certificate' on a smartcard or USB token, unfortunately (please correct me if I am wrong!).

You can import a certificate to Windows 2000/XP manually (through MMC) but it can also be automated. See the "Advanced" section for that.

1.2 Author

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

Back to Contents

2. Contents

3. Installation and configuration (Windows 2000/XP)

The L2TP/IPsec client is installed on Windows 2000 and XP by default. If you use an export version of Windows 2000, you will need to increase its encryption strength, otherwise Windows 2000 will try to use DES instead of 3DES. Single DES is not supported by Openswan because its strength is considered insufficient. So either install the Windows 2000 High Encryption Pack, or install Service Pack 2 or higher. Any version of Windows XP already supports 3DES.

In case you previously used the Linsys IPsec Tool (lsipsectool) or Marcus Müller's IPSEC.EXE tool or some other third-party IPsec client, be advised that these clients disable the "automatic L2TP/IPsec policy" in Windows. This policy sets up the proper IPsec rules when you "dial-up" an L2TP/IPsec VPN connection from Network Connections. To (re)enable the automatic L2TP/IPsec policy you need to remove the registry key HKLM\System\CurrentControlSet\Services\Rasman\Parameters\ProhibitIpSec or change the value of this key to 0. The L2TP/IPsec policy will then be enabled after you reboot Windows. Without the automatic L2TP/IPsec policy the VPN client will try to set up a pure L2TP connection, which is not protected by IPsec encryption. Microsoft Knowledge Base article Q310109 describes how the policy is disabled, but you need to do the reverse, i.e. enable it.

3.1 Personal firewall issues

If you use a Windows XP version pre-ServicePack 2 there may be a problem with its built-in firewall ("Internet Connection Firewall"). If you encounter this problem, you may have to open ports in ICF (probably UDP ports 500 and 4500), or disable it completely, or get another personal firewall such as ZoneAlarm or BlackICE. Jim Carter suggested the latter solution because he believes that there is in fact a bug in ICF.

The new firewall in XP's ServicePack 2 is called "Windows Firewall" and it replaces ICF. Windows Firewall works fine with L2TP/IPsec. There is one issue that you have to keep in mind: the default settings block incoming "ping" requests (ICMP echo). This is a bit annoying if you are testing and troubleshooting connections. Fortunately, ping can be enabled (see Knowledge Base article Q320855).

Back to Contents

4. Setting up a connection with a Preshared key (Windows XP only)

We will start with Preshared Keys (PSKs) under Windows XP. The routine for authenticating Windows 2000/XP through certificates is almost the same, so I recommend you read this section either way.

The IPsec client included with Windows XP supports PSKs out of the box. Windows 2000 does not (not easily, that is). You could add the PSK manually (requires changing the Windows 2000 registry) and then configure the IPsec policy by hand, but this is very complicated and error prone. So if you use Windows 2000 clients exclusively, you are probably better off with certificates. Or you could use IPsec without L2TP. If you decide to stick with L2TP/IPsec for Windows 2000, I suggest you read this part anyway, so that you get an idea of how things are configured.

PSKs are easier to use than certificates but they have the disadvantage that in practice you can use them only for clients which have fixed IP addresses. Preferably, the PSK is distributed out-of-band, e.g. you write it down on a piece of paper and walk to the other machine.

Here is the procedure for configuring a Preshared Key based L2TP/IPsec connection on Windows XP. Click on the links for Windows 2000 screenshots. (There are some small GUI differences with Windows XP. Alan Whinery has made screenshots for the various Windows XP styles).

On the Linux server you should successively get an IPsec connection, L2TP connection and then a PPP connection. Check /var/log/secure and /var/log/messages on the Linux server for errors. If everything works fine, you might want to consider upgrading to certificates. See below.

Back to Contents

5. Importing certificates (Windows 2000/XP)

At this point I assume you have made certificates for your users. If not, see my other webpage.

In most cases certificates come in the form of PKCS#12 files. These files contain the user's certificate, the corresponding private key and one or more CA root certificates. There are two ways of importing certificates: manual and automated. If you want to do an automated import, you need to download and install a utility on the client (see below).

Here is 's how you can do a manual import to Windows 2000 or XP. (For an automated import of the certificate, see below).

*) If the root certificate is available in "User account" but not in "Computer account" then "Certificate Information" will confusingly show that the personal certificate is valid. However, the personal certificate cannot be used for IPsec because IPsec only looks in "Computer account" for root certificates. You can prevent this by always including the root certificate in the PKCS#12 file. This will make sure that a valid root cert is always installed in the root cert store of "Computer account".

Back to Contents

6. Setting up a connection with certificates (Windows 2000/XP)

Once you have imported the user certificate, you can configure an L2TP/IPsec connection which uses this certificate to authenticate against a Linux Openswan server.

The procedure for creating an L2TP/IPsec connection which uses a certificate is almost the same as the procedure for PSKs mentioned above. On Windows XP the difference is this:
You cannot select which certificate to use for a particular L2TP/IPsec connection. How does the Windows 2000/XP client know what certificate to use if multiple certificates have been imported? Well, the client requires the certificates on both sides to be signed by the same Certificate Authority (CA). The PKCS#12 file contains the user's private key, the corresponding certificate and one or more CA certificates. The Linux server's certificate is not included in the PKCS#12 file. Windows 2000/XP will accept the certificate from the server itself once the IPsec negotiations start. It then verifies the validity of the server's certificates with the CA certificate it has in its certificate store. (I don't know if it checks a CRL if one is specified in the CA certificate).

Back to Contents

7. NAT-Traversal

Windows 2000 Professional and Windows XP pre-SP2 do not support NAT-Traversal out of the box. You need to install an update (MS KB Q818043) or a ServicePack containing this update:

More information about NAT-T in general can be found here.

7.1 Issues with Windows XP SP2 and server-side NAT

When ServicePack 2 has been applied to XP and the VPN server is behind a NAT device, you need to take notice of an issue discovered by George Ou. Microsoft changed the default behaviour of NAT-T in SP2 and initially did not tell anyone about it. Windows XP SP2 does not support IPsec connections to servers behind NAT. Apparently Microsoft considers this a security risk because of an (uncommon) scenario which is described here. This caused them to change the default behaviour of the L2TP/IPsec client in Windows XP with SP2. Microsoft even says that a VPN server behind NAT is "not recommended" (see also KB Q885348), although the NAT-T RFC described it as a normal setup that should be supported. The original behaviour as introduced by NAT-T update Q818043 for Windows 2000 and XP SP1 is restored by adding a special registry key ("AssumeUDPEncapsulationContextOnSendRule"). This is described in Microsoft Knowledge Base article Q885407. More information and a script for changing the registry can be found in this article by George Ou.

Windows Vista requires a similar change if the server is behind NAT.

7.2 Issues with server-side NAT

You need to use Openswan 2.4.5 or higher when the Openswan server is behind NAT. More information about this  here.

Back to Contents

8. Troubleshooting: Perfect Forward Secrecy

The MSL2TP client can be hacked to enable Perfect Forward Secrecy. But I don't know how to do this in Windows 2000/XP, that is, when the "New Connection Wizard" is used to create an L2TP/IPsec connection. There is no "PFS" setting in the "New Connection Wizard". Perhaps the default security policy of the Wizard can be hacked so that PFS is enabled, but I haven't tried that.

There are valid reasons for using PFS. If you really need it, you might have to use IPsec without L2TP (e.g. through a third-party IPsec client, the Linsys IPsec Tool (lsipsectool) or Marcus Müller's IPSEC.EXE program). Then it's possible to enable PFS.

Back to Contents

9. Troubleshooting: Dial-Up Networking error messages

The error messages generated by Windows are often not terribly clear. I discuss some of the L2TP related messages in this section. If you get an error message not listed here or if you just want more information on why a particular connection fails, check out the IKE log and/or PPP log on Windows.

9.1 "Error 624: Cannot write the phone book file

You get the following error message:
"Error 624: Cannot write the phone book file"
This probably means that you are modifying the settings of your L2TP/IPsec connection (e.g. you want to set the IPsec Preshared Key) while you are logged in as a user with restricted rights. This operation requires Administrator rights.

9.2 "Error 629: Disconnected by remote machine"

You get the following error message:
"Error 629: The port was disconnected by the remote machine"
You will have to check the PPP error messages on the Openswan server. For instance, the range of allowed IP addresses in /etc/ppp/chap-secrets has to agree with the range set in l2tpd.conf. If it doesn't, the connection is rejected with the following error in /var/log/messages:
pppd[15406]: Peer is not authorized to use remote address
pppd[15406]: sent [IPCP TermReq id=0x3 "Unauthorized remote IP address"]

9.3 "Error 678: No answer"

You get the following error message:
"Error 678: There is no answer."
You will have to check the IPsec error messages on the Openswan server. It's difficult to say what could be wrong: the VPN server cannot be found, incorrect IP address, hostname does not resolve, authentication fails because of incorrect certificate or PSK, incorrect connection parameters in ipsec.conf ("but no connection has been authorized")  etc. There is very little logging and error reporting on Windows client. It's probably easier to start by examining the logs on the VPN server. See also Error 792.

9.4 "Error 732: PPP not converging"

You get the following error message:
"Error 732: The PPP negotiation is not converging."
This error may occur if you are using an incorrect "local ip" parameter in l2tpd.conf. It should specify an IP address on your internal (protected) network, not an external (public) IP address. See also this paragraph.

Yet another uninformative error message from Microsoft...

"Error 734: PPP terminated"

You get the following error message:
"Error 734: The PPP link control protocol terminated."
This error may occur when callback is enabled on the Windows client. It should not use callback for VPN connections but apparently it does sometimes. (Perhaps the error also occurs if you remove TCP/IP from the available protocols, but who would do that anyway). At the Linux server you might see the following in /var/log/messages:
rcvd [LCP ConfReq id=0x1 <magic 0xdeadbeef> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint [local:xx.xx.xx.xx.xx.xx.xx.xx.xx]>]
sent [LCP ConfRej id=0x1 <pcomp> <accomp> <mrru 1614>]
sent [CHAP Challenge id=0x1 <xxxxxxxxxxxxxxx>, name = "LinuxVPNserver"]
rcvd [CHAP Response id=0x1 <xxxxxxxxxxxxxx>, name = "jacco"]
sent [CHAP Success id=0x1 "Welcome to LinuxVPNserver."]
sent [IPCP ConfReq id=0x1 <addr>]
CHAP peer authentication succeeded for jacco
sent [IPCP ConfReq id=0x1 <addr>]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x4 "No network protocols running"]
rcvd [LCP TermAck id=0x4 "No network protocols running"]
As far as I know you can disable callback for an L2TP/IPsec connection through this procedure: open the "Networking" tab of your L2TP/IPsec connection, click the "Settings" button near "Type of VPN" and disable the LCP extensions.

9.6 "Error 737: loopback detected"

You get the following error message:

"Error 737: Loopback detected"

... then chances are that you are using an outdated l2tpd RPM. The problem has been resolved by Damion de Soto. My l2tpd RPMs (versions 0.69-5jdl and higher) contain Damion's patch.

The other L2TP daemons may not have this problem. In fact, Ulrich Holeschak reported that rp-l2tp works fine. Dossy Shiobara also reported that rp-l2tp works.

9.7 "Error 781: no valid certificate"

You get the following error message:
"Error 781: Encryption failed because no valid certificate was found."

Obviously there is something wrong with the client certificate that you imported. This error may occur when you use the MMC certificate snap-in to import the certificate and the snap-in was mistakenly configured for "My user account" instead of "Computer account". Or perhaps the imported certificate did not contain a private key (check the properties of the certificate in MMC: it should report that it has a corresponding private key). Remove the certificate(s) that you imported and make a new Certificate snap-in for "Computer account", following the instructions mentioned above. Then import the certificate again.

Check the clocks on both the Windows client and the Linux server. Have they been set to the correct time and date? If not, the certificate may be rejected because the computer mistakingly thinks that the certificate is not yet valid or has already expired.

Knowledge Base article Q247231 also mentions Error 781, but that article concerns Windows 2000 Server.

9.8 "Error 786: no valid machine certificate"

You get the following error message:

"Error 786: The L2TP connection attempt failed because there is no valid machine certificate on your computer for security authentication."

See the remarks under Error 781. These two error messages appear to be telling the same thing but I don't know exactly the difference between them.

9.9 "Error 789 encountered processing error"

You get the following error message:

"Error 789: The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer."
This error may occur in the following cases: In the first case, try to import the certificate again following the instructions. Verify in MMC that certificates actually have been installed for both the CA and for the user, including the private key. When you view the details of your certificate, you should see the message "This certificate has a corresponding private key". When MMC asks where you want to store the certificate, be sure to select "Local Computer", and not "My user account". Verify that the certificates are valid, not expired (check the start and end dates) and issued by the exact same CA as used on your Openswan box. Any (chained) root certificates should also be valid. Check the internal clock of your computer: if it is set to a strange date (say, 1970 or so), your computer will think that the certificate is not (yet) valid.

In the second case, you can re-enable the Windows IPsec service as follows. Click Start -> Programs -> Administrative Tools -> Services. Select "IPSec Policy Agent" from the list and check if the Startup type is set to "Automatic". If it is not, this is the problem. Set Startup type to "Automatic", click Apply and then Start.

Microsoft's error message is misleading. The user may easily get the impression that the Linux server is at fault. However, the error pops up immediately after clicking "Dial". I also sniffed the network communication between the client and the server: there was no network traffic. If there are no packets exchanged between Windows 2000/XP and the Linux server then it is impossible that the server is to blame. It seems to me that other error messages would have been more appropriate, for instance the error 781 mentioned above.

Removing SSH Sentinel is described here (unfortunately these instructions have not been updated for version 1.4 but you'll get the idea).

The third case is a bit atypical and I am only mentioning it for the sake of completeness. Q326751 says this is a known problem in Windows 2000 Server. According to Oleksander Darchuk the problem does not occur if you use VNC or any other remote administration tool, as long as it is not RDP. Alternatively, you could make a VPN connection from the client itself, bypasssing Windows 2000 Server. Or perhaps the problem has been fixed in Windows 2003. Either way, the L2TP/IPsec VPN server is not to blame.

(Parts of this paragraph were copied without attribution on 2003-11-20 by a Microsoft India employee. An archived copy of this page shows that I am the original author of this paragraph. Way to go, Microsoft..)

9.10 "Error 792: Time out"

You get the following error message:

"Error 792: The L2TP connection attempt failed because security negotiation timed out."

The client did not hear anything back from the server. A lot of things can cause this. The IP address or hostname of the VPN server could be incorrectly entered. Openswan could not be running. The L2TP daemon could not be running. A firewall could be blocking packets (or packet fragments). The client could be using a preshared key instead of a certificate or vice versa. Etc. etc.

Can you ping the VPN server? If that does not work, it could indicate a problem with reaching the client (although some VPN servers are blocking ICMP echo packets which is a bit silly if you ask me). Also, check the logs on the VPN server and on the Windows client.

Back to Contents

10. Troubleshooting: "OAKLEY_GROUPs supported"

You may get the following warning:
This is just a harmless message and not an error. You probably installed the IPsec update for Windows 2000/XP or XP ServicePack 2. These contain support for Diffie-Hellman MODP2048 (group 14) which is not supported by your version of Openswan. Both sides will agree upon either MODP1024 (group 2) or MODP1536 (group 5). Nothing to worry about.

Back to Contents

11. Troubleshooting: Windows 2000/XP picks the wrong certificate

Some people reported the following problem. They have a Windows 2000 or XP client that should connect to 2 or more Openswan L2TP/IPsec servers that each have their own CA. Different certificates were installed on the client. But when the client connects to a server, it always presents the same certificate to the server. So the client can connect correctly to one server but not to the other VPN server(s). This is not what you want. The client should be able to connect to all servers. Quick solution: add rightca=%same to your configuration.

The long story is as follows. The messages exchanged in an L2TP/IPsec authentication are described in this Microsoft 'Cable Guy' article (see table 4). The server sends a 'Certificate Request' (CR) payload in Main Mode message 4. This is basically a string of characters containing the name of the CA that issued the server's certificate. I suspect that the problem mentioned above occurs when the server does not send this CR payload. Then Windows 2000/XP just seems to pick the first certificate that it can find in its certificate store.

Windows' IPsec implementation requires that both the client and server certificates were issued by the same CA. The X.509 support in Openswan is much more flexible (see Strongsec's documentation). But in some cases this flexibility leads to a misconfiguration so that Openswan does not know which CA to request in the CR payload. There are several methods to solve this misconfiguration.

  1. Use a rightcert=/etc/ipsec.d/userCERT.pem statement (such as in the example configuration files in my l2tpd RPM). Then Openswan can extract the CA's name (or Distinguised Name, in X.509 jargon) from the userCERT.pem certificate. It will then send this CA name in the CR payload because rightcert=/etc/ipsec.d/userCERT.pem automically sets:

        rightid=<subject DN of client cert>
        rightca=<subject DN of CA that issued the client and server certs>

  2. Another option is to specify these 3 parameters explicitly without using rightcert.

  3. Probably the easiest option to solve the problem is to add the following parameter to your configuration:


    In this case, Openswan will simply extract the name of the CA that issued the server's certificate (as specified in leftcert=/etc/ipsec.d/localCERT.pem) and expect the client to use the same CA.
Back to Contents

12. Troubleshooting: examining the Windows logs

It may not not be very obvious in the Windows 2000/XP L2TP/IPsec client but there are two phases: the IPsec phase and the L2TP/PPP phase. Each phase has its own logs.

Alternatively, you could use Windows 2000 Professional's Network Monitor to examine the communication between the client and the server. Windows XP does not ship with Network Monitor but you can install the Network Monitor Driver and then use Netcap to write the communication to a file. This file can be examined with Network Monitor on a Windows 2000 machine or programs such as Ethereal.

Information about troubleshooting on the Linux side can be found on my main L2TP/IPsec page.

12.1 Oakley logs

The following Microsoft Knowledge Base article describes how to enable IKE logging in Windows 2000/XP:
After you enable IKE logging, you obtain a file called OAKLEY.LOG. Sadly, it's difficult to find good info on the messages logged in OAKLEY.LOG. For instance, I once wanted to connect to a Windows server but failed. After enabling IKE tracing, the OAKLEY.LOG showed this error:

 7-26: 13:50:20:656:1e4 Policy mismatch on offer method 1 policy method 1
 7-26: 13:50:20:656:1e4 Attribute Phase II Diffie-Hellman group descriptor
 7-26: 13:50:20:656:1e4      Expected: 0
 7-26: 13:50:20:656:1e4      Received: 2

In retrospect, it simply meant that Windows did not want PFS but the other side is using PFS (DH Group 2). Once I disabled PFS on the other side, it worked fine. Where can you find this kind of troubleshooting information? You tell me...

The following Knowledge Base articles may also be of use: 12.2 PPP logs

The following Microsoft Knowledge Base article describes how to enable PPP logging on Windows 2000/XP:
After you enable PPP logging, you obtain a file called PPP.LOG. The PPP.LOG is not always useful because many details are logged as a hexdump.

Back to Contents

13. IPSec Policy Agent update for Windows 2003/XP

Microsoft has released a 'hotfix' for Windows XP and 2003 Server (KB907865). It updates the 'IPSec Policy Agent' which manages the rules that Windows uses to make IPsec connections. It is not clear what this hotfix does or why it is needed. Microsoft only writes:
Microsoft has released a hotfix that corrects the behavior of the IPSec Policy Agent. After you apply this hotfix, the RPC-based interfaces return the correct status code that other Windows components require.
That is not much information. I found out that it also slightly changes the IPsec proposal that a Windows Server 2003 sends (when used as a client). Before applying the hotfix Windows 2003 sends OAKLEY_GROUP_MODP2048 and afterwards it proposes OAKLEY_GROUP_MODP1024, which is a lower encryption strength. Not a big deal, and they have probably done this to increase compatibility with non-Windows clients, but what else has changed in this hotfix that Microsoft does not talk about? Microsoft sometimes fixes security vulnerabilities through hotfixes without telling anyone, so could this hotfix plug some holes that we don't know about?

Back to Contents

14. Advanced

14.1 Automated certificate installation

There are ways of automating some of the work. Installing a certificate through MMC is tricky and error-prone. I assume it can be done through system management software such as Microsoft SMS or Novell Zenworks but these are expensive. Fortunately there are simpler dedicated tools for importing a certificate:
All programs mentioned above require Administrator privileges to import the certificate.

14.2 Automated L2TP/IPsec configuration on Windows 2000/XP

Installing a certificate is only the first step. You also need to configure the L2TP/IPsec connection. Unfortunately, Microsoft's IPsec policy creation API is undocumented. This means you can only create L2TP/IPsec connections through the following Microsoft tools: 14.3 IPsec without L2TP in Windows 2000/XP

You can only create IPsec connections through the following Microsoft tools:

These Microsoft tools are cumbersome to use or difficult to automate. The following wrappers around these tools have been made:

14.4 Misc.

The remainder of this section discusses methods that have not actually been tested. If you know whether they work and/or any other good solutions, let me know.

Back to Contents

15. Split tunnelling

If you don't want to send regular Internet traffic through the VPN tunnel you may want to enable split tunnelling. See this section for more details about split tunnelling and its advantages and disadvantages.

On Windows 2000/XP, you enable or disable split tunnelling by modifying the 'Advanced' TCP/IP settings of the VPN connection you created. You have to uncheck the box called "Use default gateway on remote network" to enable split tunnelling.

Back to Contents

16. Revision history

Jan 7, 2006: pfxMachineImport no longer on original website. Copy available here.
Jun 24, 2005: Added reference to lsipsectool.
Jun 14, 2005: Added reference to the Securepoint Personal Firewall & VPN Client.
Mar 17, 2005: NAT-OA bug in Openswan when the server is behind NAT.
Dec 5, 2004: XP SP2 may require a registry modification when the server is behind NAT.
Sep 8, 2004: Added OAKLEY_GROUPS warning.
Jun 11, 2004
: Added error 732.
Jun 3, 2004:
Added error 734 after sifting through a PPP.LOG.
Jan 4, 2004: Added error 781 text (thanks, Skip!).
Aug 12, 2003
: NAT-T update re-released.
Mar 31, 2003: Updated IPsec clients by Microsoft released for Windows 2000/XP.
Mar 14, 2003: Extended text on error 789.
Mar 8, 2003: Better info about "IPSec Settings" button.
Feb 27, 2003: Windows 2000 Professional does work! Added remark on storing certificate on token.
Jan 17, 2003: Windows 2000 Professional does not work.
Dec 21, 2002: Forgot to link to screenshot #11.
Dec 19, 2002: Added Windows 2000 logfile snippet.
Dec 14, 2002: Page created.

Jacco de Leeuw