[Openswan Users] xl2tpd not responding - why?
Troy Telford
ttelford.groups at gmail.com
Mon Sep 6 15:14:06 EDT 2010
I wanted to make sure I had my IPsec connection operating first before
worrying about why xl2tpd isn't responding...
I'm running:
* Debian (sid)
* kernel 2.6.32-5
* openswan 2.6.28
* xl2tpd 1.2.7
(openswan and xl2tpd are from debian packages)
My "internal" network is set up to run at 192.168.1.0/26; I'm wanting
my VPN clients to have 192.168.1.64/26 (Not sure if that's going to be
a problem, but...)
/etc/ipsec.conf:
version 2.0
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/26,%v4:!192.168.2.0/24
protostack=netkey
interfaces=%defaultroute
conn
%default
ike=aes-sha1;modp1536
phase2alg=aes-sha1;modp1536
compress=yes
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
leftcert=myCert.pem
left=%defaultroute
rightsubnet=vhost:%no,%priv
right=%any
rightid="C=??, ST=??, O=??, OU=?? CN=*, E=*"
pfs=yes
conn roadwarrior-l2tp
type=transport
compress=no
leftprotoport=17/1701
rightprotoport=17/1701
pfs=no
auto=add
conn roadwarrior-l2tp-oldwin
compress=no
leftprotoport=17/0
rightprotoport=17/1701
pfs=no
auto=add
I'm using RSA-1024 byte certificates.
As far as I can tell, IPsec is up and running in transport mode (some
details obfuscated):
pluto[11170]: packet from www.xxx.yyy.zzz:59693: received Vendor ID
payload [RFC 3947] method set to=109
pluto[11170]: packet from www.xxx.yyy.zzz:59693: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike] method set to=110
pluto[11170]: packet from www.xxx.yyy.zzz:59693: ignoring unknown
Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
pluto[11170]: packet from www.xxx.yyy.zzz:59693: ignoring unknown
Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
pluto[11170]: packet from www.xxx.yyy.zzz:59693: ignoring unknown
Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
pluto[11170]: packet from www.xxx.yyy.zzz:59693: ignoring unknown
Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
pluto[11170]: packet from www.xxx.yyy.zzz:59693: ignoring unknown
Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
pluto[11170]: packet from www.xxx.yyy.zzz:59693: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using
method 110
pluto[11170]: packet from www.xxx.yyy.zzz:59693: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using
method 110
pluto[11170]: packet from www.xxx.yyy.zzz:59693: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using
method 110
pluto[11170]: packet from www.xxx.yyy.zzz:59693: received Vendor ID
payload [Dead Peer Detection]
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: responding to
Main Mode from unknown peer www.xxx.yyy.zzz
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: transition
from state STATE_MAIN_R0 to state STATE_MAIN_R1
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: STATE_MAIN_R1:
sent MR1, expecting MI2
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: NAT-Traversal:
Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: transition
from state STATE_MAIN_R1 to state STATE_MAIN_R2
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: STATE_MAIN_R2:
sent MR2, expecting MI3
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: Main mode peer
ID is ID_DER_ASN1_DN: 'C=??, ST=??, O=??, OU=??, CN=??, E=??'
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: no crl from
issuer "C=??, ST=??, L=??, O=??, OU=??, CN=??, E=??" found (strict=no)
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: I am sending my cert
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: transition
from state STATE_MAIN_R2 to state STATE_MAIN_R3
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: new NAT
mapping for #11, was www.xxx.yyy.zzz:59693, now www.xxx.yyy.zzz:59116
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: STATE_MAIN_R3:
sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: ignoring
informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: received and
ignored informational message
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #11: the peer
proposed: ipaddr/32:17/1701 -> locaddr/32:17/1701
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12: responding to
Quick Mode proposal {msgid:67d068f5}
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12: us: ip
addr[C=??, ST=??, O=??, OU=Home, CN=??, E=??,+S=C]:17/1701
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12: them:
www.xxx.yyy.zzz[C=??, ST=??, O=??, OU=Home, CN=??,
E=??,+S=C]:17/1701===locaddr/32
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12: transition
from state STATE_QUICK_R0 to state STATE_QUICK_R1
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12:
netlink_raw_eroute: WARNING: that_client port 59883 and that_host port
59116 don't match. Using that_client port.
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12: transition
from state STATE_QUICK_R1 to state STATE_QUICK_R2
pluto[11170]: "roadwarrior-l2tp"[6] www.xxx.yyy.zzz #12:
STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x0eb8209b
<0x0f34300b xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=www.xxx.yyy.zzz:59116 DPD=none}
So, it seems to me that the IPsec part of the connection is working --
if that's not the case, I'd love to hear what I'm doing wrong.
That being said, my xl2tpd config is as follows:
[global]
auth file = /etc/xl2tpd/l2tp-secrets
debug tunnel = yes
[lns default]
ip range = 192.168.1.64-192.168.1.127
local ip = 192.168.1.1
require chap = yes
refuse pap = yes
require authentication = yes
name = pilot
ppp debug = yes
pppoptfile = /etc/xl2tpd/options.l2tpd
/etc/xl2tpd/options.l2tpd is:
pcp-accept-local
ipcp-accept-remote
ms-dns 192.168.1.1
auth
crtscts
idle 1800
mtu 1200
mru 1200
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
When I run 'xl2tpd -D'
the only output I ever see is:
xl2tpd[20075]: setsockopt recvref[22]: Protocol not available
xl2tpd[20075]: This binary does not support kernel L2TP.
xl2tpd[20075]: xl2tpd version xl2tpd-1.2.6 started on pilot PID:20075
xl2tpd[20075]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[20075]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[20075]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[20075]: Forked again by Xelerance (www.xelerance.com) (C) 2006
xl2tpd[20075]: Listening on IP address 0.0.0.0, port 1701
I'm suspicious it's a firewall configuration problem - no packets seem
to be getting to xl2tpd at all. But I wanted to check to see if there
was anything else that needed to be fixed first.
Thanks,
--
Troy Telford
More information about the Users
mailing list