Using Linux as an L2TP/IPsec VPN client
Last update: Mar 12, 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 Linux as an
L2TP/IPsec client. It assumes you have already read this page (the
first
one in the list). Linux can be configured as an IPsec client without
L2TP, which is actually the preferred configuration. This page,
however, is about
using IPsec with L2TP.
There might be situations where you would want to use Linux as a
client
to connect to an L2TP/IPsec VPN server such as Windows 2000/2003, a
Cisco VPN server or Mac OS X Server.
First try to figure if you really need to use L2TP/IPsec. Can you use
pure IPsec instead? IPsec without L2TP is much easier to use for Linux
clients. Most Linux distributions support it out of the box. L2TP
complicates
things for Linux clients. But there might be situations where you
cannot
get around it, e.g. when there are political reasons: the administrator
of the L2TP/IPsec VPN server simply refuses to support pure IPsec.
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.1 Results
The following L2TP/IPsec servers have been tested with Linux
Openswan as a client (results may be different if NAT is involved, see below):
- Windows 2000 Server.
- Windows Server 2003.
- Linux server: Openswan with l2tpd.
- Mac OS X Server.
Not tested (yet) but assumed to be working:
- Windows 2000 Professional, Windows Vista, Windows XP
Professional and Windows
XP Home. These apparently have a limited built-in L2TP/IPsec server.
Unknown (but IPsec phase appears to work?):
- Cisco VPN 3000 Series Concentrator. Use Openswan 2.4.10 or higher
on your Linux client. The Cisco VPN concentrator sends a bad proposal
that does not match what Openswan sends. Use rightprotoport=17/1701
as you would normally do (see below); as a
side-effect this will also accept the Cisco's proposal (17/0).
Back
to Contents
4.1 Setting up a connection with a PSK
There are basically two methods of authenticating L2TP/IPsec
clients: Preshared
Keys (PSKs) and X.509
certificates. I
recommend that you start with a PSK. It should be easier to do than
setting up certificates. Once
you
got a basic setup working, you can proceed with 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.
4.2 IPsec phase
There are two distinct phases when you use Linux as an L2TP/IPsec
client. First you connect to the IPsec server and then you connect to
the L2TP server through the IPsec tunnel. On the Linux client you need
support for IPsec, L2TP and PPP. The IPsec
configuration
for using Linux as a client with PSK authentication is as follows (in
this example the VPN server you want to connect to has a public IP
address of 123.123.123.123):
# Configuration for connecting to an L2TP/IPsec server,
# for example Windows Server 2003. The Linux client can
# be behind NAT or not.
# Authentication is through a Preshared Key.
conn L2TP-PSK-CLIENT
#
#
----------------------------------------------------------
# Use a Preshared Key.
Disable Perfect Forward Secrecy.
# Initiate rekeying.
# Connection type _must_ be
Transport Mode.
#
authby=secret
pfs=no
rekey=yes
keyingtries=3
type=transport
#
#
----------------------------------------------------------
# The local Linux machine
that connects as a client.
#
# The external network
interface is used to connect to the server.
# If you want to use a
different interface or if there is no
# defaultroute, you can
use: left=your.ip.addr.ess
left=%defaultroute
#
leftprotoport=17/1701
#
#
----------------------------------------------------------
# The remote server.
#
# Connect to the server at
this IP address.
right=123.123.123.123
#
rightprotoport=17/1701
#
----------------------------------------------------------
#
# Change 'ignore' to 'add'
to enable this configuration.
#
auto=ignore
|
Enable this client
configuration by changing the parameter auto=ignore to
auto=add
and then initiate the IPsec connection with the command:
ipsec auto --up L2TP-PSK-CLIENT
|
If all goes well you should see something like this in the log file:
"L2TP-PSK-CLIENT" #1: initiating Main Mode
"L2TP-PSK-CLIENT" #1: ignoring Vendor ID payload [KAME/racoon]
"L2TP-PSK-CLIENT" #1: received Vendor ID payload [RFC 3947] method set
to=110
"L2TP-PSK-CLIENT" #1: enabling possible NAT-traversal with method RFC
3947 (NAT-Traversal)
"L2TP-PSK-CLIENT" #1: transition from state STATE_MAIN_I1 to state
STATE_MAIN_I2
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I2: sent MI2, expecting MR2
"L2TP-PSK-CLIENT" #1: ignoring Vendor ID payload [KAME/racoon]
"L2TP-PSK-CLIENT" #1: I did not send a certificate because I do not
have one.
"L2TP-PSK-CLIENT" #1: NAT-Traversal: Result using RFC 3947
(NAT-Traversal): no NAT detected
"L2TP-PSK-CLIENT" #1: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I3: sent MI3, expecting MR3
"L2TP-PSK-CLIENT" #1: Main mode peer ID is ID_IPV4_ADDR:
'123.123.123.123'
"L2TP-PSK-CLIENT" #1: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
"L2TP-PSK-CLIENT" #2: initiating Quick Mode PSK+ENCRYPT+DONTREKEY+UP
{using isakmp#1}
"L2TP-PSK-CLIENT" #1: ignoring informational payload, type
IPSEC_INITIAL_CONTACT
"L2TP-PSK-CLIENT" #1: received and ignored informational message
"L2TP-PSK-CLIENT" #2: ignoring informational payload, type
IPSEC_RESPONDER_LIFETIME
"L2TP-PSK-CLIENT" #2: transition from state STATE_QUICK_I1 to state
STATE_QUICK_I2
"L2TP-PSK-CLIENT" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x04d46325 <0xc851a16f xfrm=AES_0-HMAC_SHA1 NATD=none
DPD=none}
|
Incidentally, these are the log messages of a client connecting to a
Mac OS X server, but connecting to Windows 2000/2003 or Openswan will
show similar results.
4.3 L2TP/PPP phase
The next step is getting the L2TP connection to work. First, you need
to add a 'client' section to l2tpd.conf:
; Connect as a client to a server at 123.123.123.123
[lac L2TPserver]
lns = 123.123.123.123
require chap = yes
refuse pap = yes
require authentication = yes
; Name should be the same as the username in the PPP authentication!
name = jacco
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
|
The lns = parameter specifies the public IP address of the
server, i.e. it should match the right= parameter that you
have entered in the L2TP-PSK-CLIENT section of your ipsec.conf.
It appears that the parameter 'name' is required and this name should
be the same as
the
username in the PPP authentication, even though Windows and Mac
clients/server perform no L2TP
authentication. Also, you cannot use the same pppd /etc/ppp/options.l2tpd
file that is used when Linux is the server. You need to create a new
file /etc/ppp/options.l2tpd.client
which looks like this:
ipcp-accept-local
ipcp-accept-remote
refuse-eap
noccp
noauth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
#proxyarp
connect-delay 5000
|
The lines 'refuse-eap' and 'noauth' are only in options.l2tpd.client
and not in the file /etc/ppp/options.l2tpd that is used
by Linux
L2TP/IPsec servers. By
default, Windows 2000/2003 Server will try EAP first for PPP
authentication. If you don't (want to) use EAP (for example, you want
CHAP or
MS-CHAP
instead) you will have to refuse EAP since otherwise the
EAP authentication will start and fail. 'Noauth' is required
because the Windows server refuses to do PPP authentication itself.
Only the client has to authenticate. Optionally you could add the
parameter 'usepeerdns' so that two IP
addresses of DNS servers are retrieved from the remote PPP server (I'm
not sure if this works though). Also add your PAP/CHAP password to your
pap-secrets or chap-secrets file, as described here.
To start the L2TP/PPP connection you run
the following commands:
echo "c L2TPserver" > /var/run/l2tp-control
route add -net 0.0.0.0 dev ppp0
|
Or if you use xl2tpd instead of l2tpd:
echo "c L2TPserver" > /var/run/xl2tpd/l2tp-control
route add -net 0.0.0.0 dev ppp0
|
The second line sets the default
route to the VPN
server. This is a bit of a hack and perhaps a better solution is
needed. Using 'defaultroute' in /etc/ppp/options.l2tpd.client
did not work for me. If you prefer not to set a default to the VPN
server, don't run the 'route add' command. This is also known
as "split tunnelling". See this
section for more details about split tunnelling and its advantages
and disadvantages.
L2tpd now
connects as a client to the remote L2TP server.
The L2TP packets should go through the IPsec tunnel. Verify with a
network sniffer (e.g. tcpdump, Ethereal or Wireshark) located between
the client and
the server that the L2TP packets are indeed encrypted.
When you want to disconnect, you run the following commands:
echo "d L2TPserver" > /var/run/l2tp-control
ipsec auto --down L2TP-CERT-CLIENT
|
Consult the README included with l2tpd for more details on L2TP
connections ( less `rpm -ql l2tpd | grep \/README` ). By
default l2tpd listens on all interfaces. If you want to use Linux as an
L2TP/IPsec client, it seems unnecessary to run l2tpd as a server too.
You can reduce the exposure of the L2TP server to the outside world
by binding only to the internal interface or even localhost (127.0.0.1)
using the "listen-addr"
parameter,
as explained here.
(Perhaps l2tpd can be modified so that it does not listen to incoming
connections at all, when it is used as a client).
Back
to Contents
5.1 Setting up a connection with
certificates
If the remote L2TP/IPsec server requires certificate
authentication, the Openswan client configuration is slightly
different. This is discussed in the remainder of this section.
5.2 Obtaining a certificate
You need a valid client certificate to authenticate to the remote
L2TP/IPsec server. If you are the administrator of the VPN server and
you have not yet made certificates for your users, see my
other webpage. The minimum you need is a client certificate and the
corresponding
private key. These are unique for every user. Usually you also need
one or more CA (root or intermediate) certificates. These CA
certificates are shared by all users. For simplicity, in the following I refer to the combination of these items
as your 'client certificate'.
Your client certificate is probably in
one of these two formats:
- A PKCS#12 file containing private key and
certificate(s). You need to extract
these first from the PKCS#12 file because Openswan does not support
PKCS#12. You are also provided with a password for decrypting the
PKCS#12.
- A private key in a file in PEM (text, Base64 encoded) or DER
(binary) format,
plus corresponding certificate(s) in other PEM or DER file(s). In
this case you can skip the PKCS#12 extraction step and install the files directly to
Openswan.
If you own multiple PCs or PDAs, you
actually do not have to obtain different certificates. You can import
the same
certificate to all these devices, if you want. Of course different users
should obtain their own unique certificates.
5.3 Extracting from PKCS#12
If your client certificate is in PKCS#12 format, you need to extract the
components from the PKCS#12 file, for example with OpenSSL. PKCS#12 files often have
the extension .p12 or .pfx.
So, let's assume that your PKCS#12 file is called user.pfx.
If the name is different replace user.pfx with whatever the
name is of your PKCS#12 file. Execute the
following commands
(lines starting with '#'
are comments and should not be entered):
# (Tip: use copy and paste for these commands)
#
# Extract the user certificate contained within the PKCS#12 file:
openssl pkcs12 -in user.pfx -nokeys -clcerts -out usercrt.pem
# Extract the CA certificate(s)
contained within the
PKCS#12 file:
openssl pkcs12 -in user.pfx -nokeys -cacerts -out cacrt.pem
# Extract the private key contained within the PKCS#12 file.
openssl pkcs12 -in user.pfx
-nocerts -out
userkey.pem
|
5.4 Installing the
certificate files
At this stage you have three files: the client certificate usercrt.pem,
the
corresponding
private key userkey.pem and one or more CA (root or
intermediate) certificates in cacert.pem. Openswan supports
key files in both PEM (text) and DER (binary) formats but it is
recommended to use PEM. If your files are in DER format, you can
convert them with OpenSSL (see 'man rsa' and 'man x509',
especially the '-inform DER' and '-outform PEM'
parameters).
Copy or move the key files to the proper locations, for example:
mv cacrt.pem /etc/ipsec.d/cacerts/cacert.pem
mv usercrt.pem /etc/ipsec.d/usercrt.pem
mv userkey.pem /etc/ipsec.d/private/userkey.pem
Now you tell Openswan where to find the private key by editing /etc/ipsec.secrets:
: RSA /etc/ipsec.d/private/userkey.pem "thepassphrase"
This passphrase refers to the password that protects the private
key (if you extracted userkey.pem from a PKCS#12 file: this
is the
passphrase that you entered twice at the last openssl pkcs12
command). If you prefer not to store this passphrase on disk,
you can replace it with %prompt. Then use ipsec auto
--rereadsecrets to enter the passphrase on the command line. See 'man
ipsec.secrets'.
5.5 IPsec phase
The following example provides a connection definition for
authentication through certificates:
# Configuration for connecting to an L2TP/IPsec server,
# for example Windows Server 2003. The Linux client can
# be behind NAT or not.
# Authentication is through certificates.
conn L2TP-CERT-CLIENT
#
#
----------------------------------------------------------
# Use certificates. Disable
Perfect Forward Secrecy.
# Initiate rekeying.
# Connection type _must_ be
Transport Mode.
#
authby=rsasig
pfs=no
rekey=yes
keyingtries=3
type=transport
#
#
----------------------------------------------------------
# The local Linux machine
that connects as a client.
#
# The external network
interface is used to connect to the server.
# If you want to use a
different interface or if there is no
# defaultroute, you can
use: left=your.ip.addr.ess
left=%defaultroute
#
# The certificate of this
client.
#
leftcert=/etc/ipsec.d/usercrt.pem
leftrsasigkey=%cert
leftprotoport=17/1701
#
#
----------------------------------------------------------
# The remote server.
#
# Connect to the server with
this IP address.
right=123.123.123.123
#
# The server should the
present the following certificate.
rightcert=/etc/ipsec.d/certs/YourServerCertHere.pem
# (Alternatives for
rightcert= are also possible)
rightrsasigkey=%cert
rightca=%same
rightprotoport=17/1701
#
----------------------------------------------------------
#
# Change 'ignore' to 'add'
to enable this configuration.
#
auto=ignore
|
You authenticate to the VPN server with the client certificate.
Likewise, you want the server to authenticate to you, so that you are
certain that you are not dealing with a fake VPN server. There are
several methods of making sure that your client
is connecting to the correct server. One option is described in the
example above: you use the parameter rightcert= to tell
Openswan
that the server should present a certificate which has the exact same
ID as the ID contained in the
certificate file YourServerCertHere.pem. This method assumes
that
the client already has obtained the server's certificate in a file.
This
may not
always be the case, so there are other
methods of authenticating the server's certificate. One such
method is by using a parameter such as rightid="CN=vpnserver.example.com"
instead of the rightcert=
line. Another method is by using the parameter rightid=@vpnserver.example.com
(this is the method used by Windows
Vista and MacOS
X, incidentally).
Whatever identification method you have chosen, enable your client
configuration by changing the parameter auto=ignore to
auto=add
and then you initiate the IPsec connection with:
ipsec auto --up L2TP-CERT-CLIENT
|
If all goes well you should see something like this in the log file:
"L2TP-CERT-CLIENT" #1: initiating Main Mode
"L2TP-CERT-CLIENT" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY
00000004]
"L2TP-CERT-CLIENT" #1: ignoring Vendor ID payload [FRAGMENTATION]
"L2TP-CERT-CLIENT" #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
"L2TP-CERT-CLIENT" #1: enabling possible NAT-traversal with method RFC
3947 (NAT-Traversal)
"L2TP-CERT-CLIENT" #1: transition from state STATE_MAIN_I1 to state
STATE_MAIN_I2
"L2TP-CERT-CLIENT" #1: STATE_MAIN_I2: sent MI2, expecting MR2
"L2TP-CERT-CLIENT" #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
"L2TP-CERT-CLIENT" #1: I am sending my cert
"L2TP-CERT-CLIENT" #1: I am sending a certificate request
"L2TP-CERT-CLIENT" #1: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3
"L2TP-CERT-CLIENT" #1: STATE_MAIN_I3: sent MI3, expecting MR3
"L2TP-CERT-CLIENT" #1: Main mode peer ID is ID_DER_ASN1_DN:
'CN=vpnserver.example.com'
"L2TP-CERT-CLIENT" #1: no crl from issuer "CN=testca" found (strict=no)
"L2TP-CERT-CLIENT" #1: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4
"L2TP-CERT-CLIENT" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
"L2TP-CERT-CLIENT" #2: initiating Quick Mode
RSASIG+ENCRYPT+DONTREKEY+UP {using isakmp#1}
"L2TP-CERT-CLIENT" #2: IKE message has the Commit Flag set but Pluto
doesn't implement this feature; ignoring flag
"L2TP-CERT-CLIENT" #2: ignoring informational payload, type
IPSEC_RESPONDER_LIFETIME
"L2TP-CERT-CLIENT" #2: transition from state STATE_QUICK_I1 to state
STATE_QUICK_I2
"L2TP-CERT-CLIENT" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x08b18db6 <0x5575bf2b xfrm=3DES_0-HMAC_SHA1 NATD=none
DPD=none}
"L2TP-CERT-CLIENT" #2: IKE message has the Commit Flag set but Pluto
doesn't implement this feature; ignoring flag
"L2TP-CERT-CLIENT" #2: message ignored because it contains an
unexpected payload type (ISAKMP_NEXT_HASH)
"L2TP-CERT-CLIENT" #2: sending encrypted notification
INVALID_PAYLOAD_TYPE to 192.168.0.2:500
|
In the example above I was connecting to Windows Server 2003. There are
a
few error messages, but the IPsec
connection works.
5.6. L2TP/PPP phase
The L2TP/PPP phase for certificate authentication is the same as when a
PSK is used (see above).
Back
to Contents
6.1 NAT-Traversal
More information about NAT-T in general can be found here.
6.2 Status of NAT-T support with Linux as an
L2TP/IPsec
client
The following L2TP/IPsec servers have been tested with
Openswan as a client when NAT is involved.
Successfully tested:
- Openswan 2.4.5 or higher behind NAT.
Successfully tested with extra patch:
- Windows Server 2003 (when Openswan 2.4.10 or
higher is used as a client): these versions of Openswan support Windows
Server 2003 but you need to set #define
ALLOW_MICROSOFT_BAD_PROPOSAL. For example, by applying this patch
against the Openswan source code. If you don't apply the patch, or if
you use an older version of Openswan, you get the
error: "our client ID returned doesn't match my proposal" or "our
client subnet returned doesn't match my proposal - us:192.168.0.2/32 vs
them:234.234.234.234/32", followed by "INVALID_ID_INFORMATION".
Note: this is not
a complete fix.
Not working:
- Windows Server 2003 (when connecting with Openswan 2.4.9 or
lower). These old versions of Openswan do not contain the workaround
mentioned above, or they do not send the vendor ID draft-ietf-ipsec-nat-t-ike-02_n
that Windows Server 2003 requires. (This patch
was submitted to the Openswan team to correct the latter problem).
- Windows 2000 Server: it
does not support NAT-T at all. No clients can be used if NAT is
involved, be it Windows, Mac or Openswan.
- Mac OS X server: fails to interoperate
with Linux clients and also Windows 2000/XP, according to one report
that I received.
Mac clients do work. Status with Windows Vista clients unknown (Mac OS
X Server 10.4.4 and higher support RFC 3947). Errors reported are
"length of ISAKMP Notification Payload is
smaller than minimum" and "malformed payload in packet"
(or is this an
unrelated MTU problem?).
- Openswan 2.4.4 or lower behind NAT: if you are connecting to an
Openswan server behind NAT, you need to use Openswan
2.4.5 or higher on that server. More information about this can be
found here.
Unknown:
- Cisco VPN 3000 Series Concentrator: it appears that at least the
IPsec phase works. Use
Openswan 2.4.10 or higher. The Cisco VPN concentrator sends a bad
proposal that does not match what Openswan sends. Use rightprotoport=17/1701
as you would normally do (see above):
as a side-effect it will also accept the Cisco's proposal (17/0).
- Windows Server 2008: expected to be the same as Windows Server
2003 (see above).
Here is an example when the Openswan client is located behind a NAT
device and connects to a Cisco VPN 3000 Series Concentrator:
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I1: initiate
"L2TP-PSK-CLIENT" #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
"L2TP-PSK-CLIENT" #1: ignoring Vendor ID payload [FRAGMENTATION
c0000000]
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I2: sent MI2, expecting MR2
"L2TP-PSK-CLIENT" #1: received Vendor ID payload [Cisco-Unity]
"L2TP-PSK-CLIENT" #1: received Vendor ID payload [XAUTH]
"L2TP-PSK-CLIENT" #1: ignoring unknown Vendor ID payload
[e0973153befe1bf955f575d886dd7927]
"L2TP-PSK-CLIENT" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
"L2TP-PSK-CLIENT" #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I3: sent MI3, expecting MR3
"L2TP-PSK-CLIENT" #1: received Vendor ID payload [Dead Peer Detection]
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
"L2TP-PSK-CLIENT" #2: STATE_QUICK_I1: initiate
"L2TP-PSK-CLIENT" #2: our client subnet returned doesn't match my
proposal - us:192.168.0.2/32 vs them:234.234.234.234/32
"L2TP-PSK-CLIENT" #2: our client peer returned port doesn't match my
proposal - us:1701 vs them:0
"L2TP-PSK-CLIENT" #2: Allowing bad L2TP/IPsec proposal (see bug #849)
anyway
"L2TP-PSK-CLIENT" #2: NAT-Traversal: received 1 NAT-OA. ignored because
peer is not NATed
"L2TP-PSK-CLIENT" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x80d3bff0 <0x7a43977f xfrm=3DES_0-HMAC_SHA1
NATD=123.123.123.123:4500 DPD=enabled}
|
And in the following log I connect with a PSK to Windows Server 2003
(after having
applied the ALLOW_MICROSOFT_BAD_PROPOSAL patch, see above):
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I1: initiate
"L2TP-PSK-CLIENT" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY
00000004]
"L2TP-PSK-CLIENT" #1: ignoring Vendor ID payload [FRAGMENTATION]
"L2TP-PSK-CLIENT" #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I2: sent MI2, expecting MR2
"L2TP-PSK-CLIENT" #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I3: sent MI3, expecting MR3
"L2TP-PSK-CLIENT" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
"L2TP-PSK-CLIENT" #2: STATE_QUICK_I1: initiate
"L2TP-PSK-CLIENT" #2: ignoring informational payload, type
IPSEC_RESPONDER_LIFETIME
"L2TP-PSK-CLIENT" #2: our client subnet returned doesn't match my
proposal - us:192.168.0.2/32 vs them:234.234.234.234.234/32
"L2TP-PSK-CLIENT" #2: Allowing questionable proposal anyway
[ALLOW_MICROSOFT_BAD_PROPOSAL]
"L2TP-PSK-CLIENT" #2: peer client subnet returned doesn't match my
proposal - us:123.123.123.123/32 vs
them:234.234.234.234/32
"L2TP-PSK-CLIENT" #2: Allowing questionable proposal anyway
[ALLOW_MICROSOFT_BAD_PROPOSAL]
"L2TP-PSK-CLIENT" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x35cae86e <0x882d437a xfrm=3DES_0-HMAC_SHA1 NATD=123.123.123.123:4500
DPD=none}
|
Back
to Contents
7. Misc. remarks on using Linux as a
client
7.1 First IPsec, then L2TP
It may seem obvious, but make sure your IPsec connection is up before
you start the L2TP phase! If the IPsec tunnel is not up, you are
sending the L2TP packets in the clear (i.e. all your network traffic).
The VPN
server will probably reject unencrypted L2TP packets but bad guys could
intercept those packets and get their own L2TP server to respond
instead.
7.2. Perfect Forward
Secrecy
There are valid
reasons for
using Perfect Forward Secrecy
(PFS). If the server supports PFS, you should add pfs=yes to
your client configuration L2TP-CERT-CLIENT or L2TP-PSK-CLIENT
for extra security.
Most commercial servers do not support PFS but Openswan and other Open
Source servers such as racoon do. Windows Server 2008 might also
support PFS. An Openswan server configured with pfs=no will
still successfully negotiate PFS when an Openswan client that is
configured with pfs=yes connects. So, if you know for a fact
that the remote server supports PFS, or if you are willing to have a go
at it for the sake of security, try pfs=yes
first in your client configuration. And if that does not work (the
server replies with NO_PROPOSAL_CHOSEN and your client is
stuck at STATE_QUICK_I1, according to your Openswan logs),
switch to pfs=no.
Back
to Contents
7.3 Group PSK
Some organisations use L2TP/IPsec with Preshared Key authentication
but they are making the Preshared Key public knowledge (here is an
example). Obviously this completely compromises IPsec security, so
those organisations are relying on second stage PPP authentication and
encryption. In these cases you should force the use of MS-CHAPv2
instead of CHAP,
and the PPP connection should be encrypted with MPPE. Check out these
sections for information on how to
configure MS-CHAPv2 and MPPE. Your Linux kernel should contain
support for MPPE (see 'man pppd') and on some distributions may need to
recompile the kernel to enable MPPE.
If you use MPPE you should remove the option 'noccp' from options.l2tpd.client
because
MPPE is negotiated through the CCP (compression) protocol and not
through
LCP, as one would expect (blame Microsoft).
7.4 Client GUIs
A number of VPN graphical front-ends for Linux clients is available,
including:
Only Stinghorn and KVpnc support the L2TP/IPsec protocol.
7.5 Dead Pear Detection
Dead Peer Detection (DPD) is discussed on my other webpage. On Linux clients you
need to add parameters to enable DPD, for example:
conn L2TP-PSK-CLIENT
dpddelay=30
dpdtimeout=120
dpdaction=clear
7.6 Which L2TP client?
Several L2TP implementations are available. Some of them
cannot be used as a
client, for example l2tpns.
Back
to Contents
8. Troubleshooting
Examine the IPsec, L2TP and PPP logs, similar to when Linux is used as
a server (see my main
L2TP/IPsec page). For PPP troubleshooting you can find some
great tips on this PPTP
troubleshooting page.
Back to Contents
9. Revision history
Feb 24, 2008: Openswan 2.4.10+ resolves NAT problems with
Cisco VPN 3000 Concentrator and Windows Server 2003.
Aug 12, 2007: Should use rekey=yes for both PSK and
certs!
Jan 4, 2007: Incorrectly listed NATed Win2003 as working.
Requires a patch.
Nov 22, 2006: Section moved from main page to separate page.
Jacco de Leeuw
