[Openswan Users] Windows Mobile 6.5 connects, but loses connection

Tue Sep 7 11:17:04 EDT 2010

Sorry for the last message, I misunderstood. The logs go to
/var/log/messages,
it looks like there is ipv6?

here it is:
Sep  7 17:03:01 gateway pppd[9494]: Plugin
/usr/local/lib/pppd/2.4.5/radius.so loaded.
Sep  7 17:03:01 gateway pppd[9494]: RADIUS plugin initialized.
Sep  7 17:03:01 gateway pppd[9494]: pppd 2.4.5 started by root, uid 0
Sep  7 17:03:02 gateway pppd[9494]: Using interface ppp0
Sep  7 17:03:02 gateway pppd[9494]: Connect: ppp0 <--> /dev/pts/4
Sep  7 17:03:02 gateway pppd[9494]: Unsupported protocol 'IPv6 Control
Protocol' (0x8057) received
Sep  7 17:03:02 gateway pppd[9494]: found interface eth1 for proxy arp
Sep  7 17:03:02 gateway pppd[9494]: local  IP address 172.28.1.1
Sep  7 17:03:02 gateway pppd[9494]: remote IP address 172.28.1.10
Sep  7 17:03:02 gateway dnsmasq-dhcp[967]: DHCPINFORM(ppp0) 172.28.1.10
00:53:45:00:00:00
Sep  7 17:03:02 gateway dnsmasq-dhcp[967]: DHCPACK(ppp0) 172.28.1.10
00:53:45:00:00:00
Sep  7 17:04:09 gateway pppd[9494]: Terminating on signal 15
Sep  7 17:04:09 gateway pppd[9494]: Modem hangup
Sep  7 17:04:09 gateway pppd[9494]: Connect time 1.2 minutes.
Sep  7 17:04:09 gateway pppd[9494]: Sent 890 bytes, received 650 bytes.
Sep  7 17:04:09 gateway pppd[9494]: Connection terminated.
Sep  7 17:04:09 gateway pppd[9494]: Exit.
Sep  7 17:14:27 gateway pppd[9941]: Plugin
/usr/local/lib/pppd/2.4.5/radius.so loaded.
Sep  7 17:14:27 gateway pppd[9941]: RADIUS plugin initialized.
Sep  7 17:14:27 gateway pppd[9941]: pppd 2.4.5 started by root, uid 0
Sep  7 17:14:27 gateway pppd[9941]: Using interface ppp0
Sep  7 17:14:27 gateway pppd[9941]: Connect: ppp0 <--> /dev/pts/4
Sep  7 17:14:27 gateway radiusd: nss_ldap: could not search LDAP server -
Server is unavailable
Sep  7 17:14:27 gateway pppd[9941]: Unsupported protocol 'IPv6 Control
Protocol' (0x8057) received
Sep  7 17:14:27 gateway pppd[9941]: found interface eth1 for proxy arp
Sep  7 17:14:27 gateway pppd[9941]: local  IP address 172.28.1.1
Sep  7 17:14:27 gateway pppd[9941]: remote IP address 172.28.1.10
Sep  7 17:14:27 gateway dnsmasq-dhcp[967]: DHCPINFORM(ppp0) 172.28.1.10
00:53:45:00:00:00
Sep  7 17:14:27 gateway dnsmasq-dhcp[967]: DHCPACK(ppp0) 172.28.1.10
00:53:45:00:00:00
Sep  7 17:15:11 gateway pppd[9941]: LCP terminated by peer
Sep  7 17:15:11 gateway pppd[9941]: Connect time 0.8 minutes.
Sep  7 17:15:11 gateway pppd[9941]: Sent 890 bytes, received 650 bytes.
Sep  7 17:15:11 gateway pppd[9941]: Terminating on signal 15
Sep  7 17:15:11 gateway pppd[9941]: Modem hangup
Sep  7 17:15:11 gateway pppd[9941]: Connection terminated.
Sep  7 17:15:11 gateway pppd[9941]: Exit.

2010/9/7 Bart Smink <bartsmink at gmail.com>

> Thank you for your response Paul,
>>
>> This is Openswan-2.6.28 using Netkey. I have added debug to
>> /etc/ppp/options.xl2tpd and I ran xl2tpd -D
>> Things work when I use the mobile phone as a modem, so there has to be
>> something wrong on the phone, or the authentication goes wrong.
>>
>> The output of xl2tpd -D is:
>>
>> [root at gateway ppp]# xl2tpd -D
>> xl2tpd[9444]: setsockopt recvref[22]: Protocol not available
>> xl2tpd[9444]: This binary does not support kernel L2TP.
>> xl2tpd[9444]: xl2tpd version xl2tpd-1.2.6 started on gateway.helios.lan
>> PID:9444
>> xl2tpd[9444]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
>> xl2tpd[9444]: Forked by Scott Balmos and David Stipp, (C) 2001
>> xl2tpd[9444]: Inherited by Jeff McAdams, (C) 2002
>> xl2tpd[9444]: Forked again by Xelerance (www.xelerance.com) (C) 2006
>> xl2tpd[9444]: Listening on IP address 0.0.0.0, port 1701
>> xl2tpd[9444]: control_finish: Peer requested tunnel 15 twice, ignoring
>> second one.
>> xl2tpd[9444]: Connection established to 62.140.137.125, 1701.  Local:
>> 12003, Remote: 15 (ref=0/0).  LNS session is 'default'
>> xl2tpd[9444]: start_pppd: I'm running:
>> xl2tpd[9444]: "/usr/sbin/pppd"
>> xl2tpd[9444]: "passive"
>> xl2tpd[9444]: "nodetach"
>> xl2tpd[9444]: "172.28.1.1:172.28.1.10"
>> xl2tpd[9444]: "auth"
>> xl2tpd[9444]: "name"
>> xl2tpd[9444]: "Helios.Lan"
>> xl2tpd[9444]: "debug"
>> xl2tpd[9444]: "file"
>> xl2tpd[9444]: "/etc/ppp/options.xl2tpd"
>> xl2tpd[9444]: "/dev/pts/4"
>> xl2tpd[9444]: Call established with 62.140.137.125, Local: 57733, Remote:
>> 1, Serial: 0
>> xl2tpd[9444]: Maximum retries exceeded for tunnel 12003.  Closing.
>> xl2tpd[9444]: Terminating pppd: sending TERM signal to pid 9494
>> xl2tpd[9444]: Connection 15 closed to 62.140.137.125, port 1701 (Timeout)
>>
>>
>> 2010/9/7 Paul Wouters <paul at xelerance.com>
>>
>> On Tue, 7 Sep 2010, Bart Smink wrote:
>>>
>>>  I am trying to get Windows Mobile 6.5 to work with Openswan in
>>>> combination with XL2TPD which is connected to freeradius. When
>>>> I am trying to send data through the tunnel, the connection goes down,
>>>> when I wait for 3 minutes, the connection goes down.
>>>>
>>>> What I notice is that I get "ignoring informational payload, type
>>>> INVALID_COOKIE msgid=00000000" messages. Openswan sees it as
>>>> information messages, but I think it is the client trying to
>>>> communicate.
>>>>
>>>> I am using the example config file l2tp-cert.conf. I have not configured
>>>> "esp=", because I would like Openswan to find out
>>>> what encryption methods can be used, but this is not working.
>>>>
>>>> Can someone help me?
>>>>
>>>
>>> Is this a recent openswan 2.6.x?
>>>
>>>
>>>  Sep  7 15:50:31 gateway pluto[1749]: "l2tp-X.509"[11] 62.140.137.125
>>>> #14: STATE_MAIN_R2: sent MR2, expecting MI3
>>>> Sep  7 15:50:32 gateway pluto[1749]: "l2tp-X.509"[11] 62.140.137.125
>>>> #14: discarding duplicate packet; already STATE_MAIN_R2
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[11] 62.140.137.125
>>>> #14: Main mode peer ID is ID_DER_ASN1_DN: 'C=NL,
>>>> ST=Utrecht, L=Utrecht, O=Testing Corporation, OU=Research and
>>>> Development, CN=Left1024, E=admin at testingcorporation.nl'
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[11] 62.140.137.125
>>>> #14: switched from "l2tp-X.509" to "l2tp-X.509"
>>>>
>>>
>>> This is a little odd.
>>>
>>>
>>>  Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: I am sending my cert
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: deleting connection "l2tp-X.509" instance with peer
>>>> 62.140.137.107 {isakmp=#0/ipsec=#13}
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509" #13: deleting state
>>>> (STATE_QUICK_R2)
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: transition from state STATE_MAIN_R2 to state
>>>> STATE_MAIN_R3
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: new NAT mapping for #14, was 62.140.137.125:29237,
>>>> now 62.140.137.125:29528
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: STATE_MAIN_R3: sent MR3, ISAKMP SA established
>>>> {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha
>>>> group=modp2048}
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: peer client type is FQDN
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: Applying workaround for MS-818043 NAT-T bug
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: IDci was FQDN: U\221\224j, using
>>>> NAT_OA=10.66.108.51/32 as IDci
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #14: the peer proposed: 85.145.148.106/32:17/1701 ->
>>>> 10.66.108.51/32:17/0
>>>>
>>>
>>> There might be confusion between the two instances.
>>>
>>>
>>>  O=Testing Corporation, OU=Research and Development, CN=Left1024, E=
>>>> admin at testingcorporation.nl,+S=C]:17/0===10.66.108.51/32
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #16: transition from state STATE_QUICK_R0 to state
>>>> STATE_QUICK_R1
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #16: STATE_QUICK_R1: sent QR1, inbound IPsec SA
>>>> installed, expecting QI2
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #16: netlink_raw_eroute: WARNING: that_client port 0 and
>>>> that_host port 29528 don't match. Using that_client port.
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #16: transition from state STATE_QUICK_R1 to state
>>>> STATE_QUICK_R2
>>>> Sep  7 15:50:34 gateway pluto[1749]: "l2tp-X.509"[12] 62.140.137.125
>>>> #16: STATE_QUICK_R2: IPsec SA established transport mode
>>>> {ESP=>0x00bc42b0 <0x44d1a644 xfrm=3DES_0-HMAC_SHA1 NATOA=10.66.108.51
>>>> NATD=62.140.137.125:29528 DPD=none}
>>>> Sep  7 15:50:37 gateway pluto[1749]: "l2tp-X.509"[11] 62.140.137.125
>>>> #15: ignoring informational payload, type INVALID_COOKIE
>>>> msgid=00000000
>>>>
>>>
>>> This looks like the phone started a new attempt from scratch (hence the
>>> null cookie)
>>>
>>>
>>>  The output of xl2tpd -D:
>>>>
>>>> xl2tpd[1808]: control_finish: Peer requested tunnel 14 twice, ignoring
>>>> second one.
>>>> xl2tpd[1808]: Connection established to 62.140.137.125, 1701.  Local:
>>>> 15271, Remote: 14 (ref=0/0).  LNS session is 'default'
>>>> xl2tpd[1808]: start_pppd: I'm running:
>>>> xl2tpd[1808]: "/usr/sbin/pppd"
>>>> xl2tpd[1808]: "passive"
>>>> xl2tpd[1808]: "nodetach"
>>>> xl2tpd[1808]: "172.28.1.1:172.28.1.10"
>>>> xl2tpd[1808]: "auth"
>>>> xl2tpd[1808]: "name"
>>>> xl2tpd[1808]: "Helios.Lan"
>>>> xl2tpd[1808]: "debug"
>>>> xl2tpd[1808]: "file"
>>>> xl2tpd[1808]: "/etc/ppp/options.xl2tpd"
>>>> xl2tpd[1808]: "/dev/pts/4"
>>>> xl2tpd[1808]: Call established with 62.140.137.125, Local: 38486,
>>>> Remote: 1, Serial: 0
>>>> xl2tpd[1808]: control_finish: Connection closed to 62.140.137.125,
>>>> serial 0 ()
>>>> xl2tpd[1808]: Terminating pppd: sending TERM signal to pid 6365
>>>> xl2tpd[1808]: control_finish: Connection closed to 62.140.137.125, port
>>>> 1701 (), Local: 15271, Remote: 14
>>>>
>>>
>>> Is there any pppd logs? add "debug" to /etc/ppp/options.xl2tpd and look
>>> there? This might simply be an
>>> authentication error, and the logs at the openswan end just show the
>>> phone trying again from scratch.
>>>
>>> Paul
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100907/6fa16c54/attachment-0001.html 