[Openswan Users] Dropped Connection Help

Steven Lokie steven.lokie at imemories.com
Mon Apr 1 22:52:10 UTC 2013 

Help, 
I'm trying to open an l2tp connection and it doesn't connect.  I'm lost
as to why this is failing so badly - any help anyone can provide?

xl2tpd -D 

[root@ ~]# xl2tpd -D
xl2tpd[11273]: setsockopt recvref[30]: Protocol not available
xl2tpd[11273]: This binary does not support kernel L2TP.
xl2tpd[11273]: xl2tpd version xl2tpd-1.3.1 started on vpn02 PID:11273
xl2tpd[11273]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[11273]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[11273]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[11273]: Forked again by Xelerance (www.xelerance.com) (C) 2006
xl2tpd[11273]: Listening on IP address 64.211.xxx.xxx, port 1701

secure.log
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
received Vendor ID payload [RFC 3947] method set to=109 
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set
to=110 
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but
already using method 110
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but
already using method 110
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but already using method 110
Apr  1 15:11:20 l2tp pluto[2207]: packet from 64.211.xxx.rec:18935:
received Vendor ID payload [Dead Peer Detection]
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
responding to Main Mode from unknown peer 64.211.xxx.rec
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
STATE_MAIN_R1: sent MR1, expecting MI2
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer
is NATed
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
STATE_MAIN_R2: sent MR2, expecting MI3
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
ignoring informational payload, type IPSEC_INITIAL_CONTACT
msgid=00000000
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
Main mode peer ID is ID_IPV4_ADDR: '10.69.18.91'
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[13] 64.211.xxx.rec #13:
switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
deleting connection "L2TP-PSK-NAT" instance with peer 64.211.xxx.rec
{isakmp=#0/ipsec=#0}
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
new NAT mapping for #13, was 64.211.xxx.rec:18935, now
64.211.xxx.rec:64113
Apr  1 15:11:20 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
the peer proposed: 64.211.xxx.xxx/32:17/1701 -> 10.69.18.91/32:17/0
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
responding to Quick Mode proposal {msgid:c8030e82}
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
us: 64.211.xxx.xxx<64.211.xxx.xxx>[+S=C]:17/1701
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
them: 64.211.xxx.rec[10.69.18.91,+S=C]:17/58382===10.69.18.91/32
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Apr  1 15:11:21 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #14:
STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x0145a385
<0x958cc9d9 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=64.211.xxx.rec:64113
DPD=none}
Apr  1 15:11:41 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
received Delete SA(0x0145a385) payload: deleting IPSEC State #14
Apr  1 15:11:41 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
received and ignored informational message
Apr  1 15:11:41 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec #13:
received Delete SA payload: deleting ISAKMP State #13
Apr  1 15:11:41 l2tp pluto[2207]: "L2TP-PSK-NAT"[14] 64.211.xxx.rec:
deleting connection "L2TP-PSK-NAT" instance with peer 64.211.xxx.rec
{isakmp=#0/ipsec=#0}
Apr  1 15:11:41 l2tp pluto[2207]: packet from 64.211.xxx.rec:64113:
received and ignored informational message



ppp.log
Mon Apr  1 15:40:18 2013 : L2TP connecting to server
'64.211.xxx.xxx' (64.211.xxx.xxx)...
Mon Apr  1 15:40:18 2013 : IPSec connection started
Mon Apr  1 15:40:18 2013 : IPSec phase 1 client started
Mon Apr  1 15:40:18 2013 : IPSec phase 1 server replied
Mon Apr  1 15:40:19 2013 : IPSec phase 2 started
Mon Apr  1 15:40:19 2013 : IPSec phase 2 established
Mon Apr  1 15:40:19 2013 : IPSec connection established
Mon Apr  1 15:40:19 2013 : L2TP sent SCCRQ
Mon Apr  1 15:40:39 2013 : L2TP cannot connect to the server


ipsec.conf

version 2.0 # conforms to second version of ipsec.conf specification

config setup
    dumpdir=/var/run/pluto/
    #in what directory should things started by setup (notably the Pluto
daemon) be allowed to dump core?
    nat_traversal=yes
    #whether to accept/offer to support NAT (NAPT, also known as "IP
Masqurade") workaround for IPsec
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    #contains the networks that are allowed as subnet= for the remote
client. In other words, the address
    #ranges that may live behind a NAT router through which a client
connects.
    protostack=netkey
    #decide which protocol stack is going to be used.
    oe=off
    #Disable Opertunistic Encryption.

conn L2TP-PSK-NAT
    rightsubnet=vhost:%priv
    also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
    authby=secret
    #shared secret. Use rsasig for certificates.
    pfs=no
    #Disable pfs
    auto=add
    #start at boot
    keyingtries=8
    #Only negotiate a conn. 3 times.
    ikelifetime=8h
    keylife=1h
    type=transport
    #because we use l2tp as tunnel protocol
    left=64.211.xxx.xxx
    #fill in server IP above
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any


-- 
_______________________
Steven Lokie
iMemories
Steven.Lokie at iMemories.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20130401/da0003aa/attachment.html>

More information about the Users mailing list