[Openswan Users] xl2tpd not responding - why?

[Troy Telford]

Short answer:  It was the firewall.  Thanks for anybody who looked!

On 2010-09-06 13:14:06 -0600, Troy Telford said:

> 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