I have made the following webpages on using L2TP/IPsec with Linux:
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.
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.
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).
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).
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).
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: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:
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.
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.
"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.
"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 192.168.1.1289.3 "Error 678: No answer"
pppd[15406]: sent [IPCP TermReq id=0x3 "Unauthorized remote IP address"]
"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.
"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.
"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]>]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.
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 192.168.1.128>]
CHAP peer authentication succeeded for jacco
sent [IPCP ConfReq id=0x1 <addr 192.168.1.128>]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x4 "No network protocols running"]
rcvd [LCP TermAck id=0x4 "No network protocols running"]
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""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.
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 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..)
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.
"only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION"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.
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.
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
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?
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.
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.
