<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [Openswan Users] Setting leftsubnet stops xl2tpd from working</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>What is the reason you want the leftsubnet? It works just fine without it.<BR>
<BR>
What is the problem you are trying to solve?<BR>
<BR>
I have xl2tpd working just fine without a left/right subnet with multiple clients accessing everything on the server subnet.<BR>
<BR>
Regards,<BR>
Randy<BR>
<BR>
-----Original Message-----<BR>
From: porges@porg.es on behalf of George Pollard<BR>
Sent: Mon 8/9/2010 6:02 PM<BR>
To: Randy Wyatt<BR>
Cc: Willie Gillespie; users@openswan.org<BR>
Subject: Re: [Openswan Users] Setting leftsubnet stops xl2tpd from working<BR>
<BR>
On 10 August 2010 12:44, Randy Wyatt <rwyatt@nvtl.com> wrote:<BR>
> Is this with leftsubnet/rightsubnet removed?<BR>
<BR>
This is with leftsubnet specified, and connection failing.<BR>
<BR>
Here is the log without leftsubnet specified, and connection success:<BR>
<BR>
Running the logs through diff, the difference seems to be that the<BR>
client never gets to Start-Control-Connection-Connected in the<BR>
non-working version.<BR>
<BR>
setsockopt recvref[22]: Protocol not available<BR>
This binary does not support kernel L2TP.<BR>
xl2tpd version xl2tpd-1.2.5 started on MY_VPN PID:9758<BR>
Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.<BR>
Forked by Scott Balmos and David Stipp, (C) 2001<BR>
Inherited by Jeff McAdams, (C) 2002<BR>
Forked again by Xelerance (www.xelerance.com) (C) 2006<BR>
Listening on IP address 0.0.0.0, port 1701<BR>
network_thread: recv packet from MY_CLIENT_IP, size = 106, tunnel =<BR>
0, call = 0 ref=0 refhim=0<BR>
get_call: allocating new tunnel for host MY_CLIENT_IP, port 1701.<BR>
handle_avps: handling avp's for tunnel 51857, call 0<BR>
message_type_avp: message type 1 (Start-Control-Connection-Request)<BR>
protocol_version_avp: peer is using version 1, revision 0.<BR>
framing_caps_avp: supported peer frames: sync<BR>
bearer_caps_avp: supported peer bearers:<BR>
firmware_rev_avp: peer reports firmware version 1537 (0x0601)<BR>
hostname_avp: peer reports hostname 'MY_CLIENT'<BR>
vendor_avp: peer reports vendor 'Microsoft'<BR>
assigned_tunnel_avp: using peer's tunnel 6<BR>
receive_window_size_avp: peer wants RWS of 8. Will use flow control.<BR>
control_finish: message type is Start-Control-Connection-Request(1).<BR>
Tunnel is 6, call is 0.<BR>
control_finish: sending SCCRP<BR>
network_thread: recv packet from MY_CLIENT_IP, size = 106, tunnel =<BR>
0, call = 0 ref=0 refhim=0<BR>
get_call: allocating new tunnel for host MY_CLIENT_IP, port 1701.<BR>
handle_avps: handling avp's for tunnel 58013, call 0<BR>
message_type_avp: message type 1 (Start-Control-Connection-Request)<BR>
protocol_version_avp: peer is using version 1, revision 0.<BR>
framing_caps_avp: supported peer frames: sync<BR>
bearer_caps_avp: supported peer bearers:<BR>
firmware_rev_avp: peer reports firmware version 1537 (0x0601)<BR>
hostname_avp: peer reports hostname 'MY_CLIENT'<BR>
vendor_avp: peer reports vendor 'Microsoft'<BR>
assigned_tunnel_avp: using peer's tunnel 6<BR>
receive_window_size_avp: peer wants RWS of 8. Will use flow control.<BR>
control_finish: message type is Start-Control-Connection-Request(1).<BR>
Tunnel is 6, call is 0.<BR>
control_finish: Peer requested tunnel 6 twice, ignoring second one.<BR>
build_fdset: closing down tunnel 58013<BR>
network_thread: recv packet from MY_CLIENT_IP, size = 20, tunnel =<BR>
51857, call = 0 ref=0 refhim=0<BR>
handle_avps: handling avp's for tunnel 51857, call 0<BR>
message_type_avp: message type 3 (Start-Control-Connection-Connected)<BR>
control_finish: message type is<BR>
Start-Control-Connection-Connected(3). Tunnel is 6, call is 0.<BR>
Connection established to MY_CLIENT_IP, 1701. Local: 51857, Remote:<BR>
6 (ref=0/0). LNS session is 'default'<BR>
network_thread: recv packet from MY_CLIENT_IP, size = 70, tunnel =<BR>
51857, call = 0 ref=0 refhim=0<BR>
handle_avps: handling avp's for tunnel 51857, call 0<BR>
message_type_avp: message type 10 (Incoming-Call-Request)<BR>
message_type_avp: new incoming call<BR>
assigned_call_avp: using peer's call 1<BR>
call_serno_avp: serial number is 0<BR>
bearer_type_avp: peer bears: analog<BR>
result_code_avp: result code not appropriate for<BR>
Incoming-Call-Request. Ignoring.<BR>
control_finish: message type is Incoming-Call-Request(10). Tunnel is<BR>
6, call is 0.<BR>
control_finish: Sending ICRP<BR>
network_thread: recv packet from MY_CLIENT_IP, size = 48, tunnel =<BR>
51857, call = 36820 ref=0 refhim=0<BR>
handle_avps: handling avp's for tunnel 51857, call 36820<BR>
message_type_avp: message type 12 (Incoming-Call-Connected)<BR>
tx_speed_avp: transmit baud rate is 54000000<BR>
frame_type_avp: peer uses:sync frames<BR>
ignore_avp : Ignoring AVP<BR>
control_finish: message type is Incoming-Call-Connected(12). Tunnel<BR>
is 6, call is 1.<BR>
start_pppd: I'm running:<BR>
"/usr/sbin/pppd"<BR>
"passive"<BR>
"nodetach"<BR>
"192.168.100.127:192.168.100.128"<BR>
"refuse-pap"<BR>
"auth"<BR>
"require-chap"<BR>
"name"<BR>
"MY_VPNL2TP"<BR>
"debug"<BR>
"file"<BR>
"/etc/ppp/options.l2tpd"<BR>
"/dev/pts/2"<BR>
Call established with MY_CLIENT_IP, Local: 36820, Remote: 1, Serial: 0<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>