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