I had exactly the same problem !! Never solved.
(super-freeswan 1.9.98 with l2tpd). IP SA established
but l2tpd never answering ... 

Then, i downloaded the source of l2tpd and work about on it for
see what happens. I discover l2tpd never receive request from
the client ! l2tpd stop at the select() stage in the network.c
source file and never return. It's why l2tpd never answer ...

Hope this help ...

P.S : How it couldn't be an IPSec bug ?


Le jeu 01/07/2004 à 11:45, Arya a écrit :
> on a tcpdump on the ipsec0 interface, the only thing I get is this:
> 
> 19:48:27.886094 client.domain.com.1701 > vpnserver.domain.com.1701:  l2tp:
> [TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) 
> *BEARER_CAP() |...
> 
> ..over and over again..
> I dont seem to be able to see any messages coming from vpnserver.domain.com to 
> client.domain.com
> 
> When I connect from a client on the same subnet, the packets are definitely 
> ESP protected (checked by sniffing on another box using a hub).
> 
> 
> 
> On Thursday 01 July 2004 18:25, Jean-Francois Dive wrote:
> > ah ok :) thought the l2tp session was established from your readings,
> > didn't looked at the logs .. ok, so it receive the request from the
> > win side, so we can assume ipsec is ok for rx (l2tp prospective).
> > Could you check that the l2tp reply from the l2tpd side goes trough the
> > tunnel back to the windows side (sniff from the ipsec0 interface or trough
> > the regular one and see if the packet is ESP protected). Othersise
> > sending us the l2tp packet trace would be the best.
> >
> > On Thu, Jul 01, 2004 at 05:35:16PM +1000, Arya wrote:
> > > No attempt is made by l2tp to actually initiate the ppp interface =\
> > > It cant be a routing issue, because an IPSec tunnel is successfully
> > > established...right?
> > >
> > > Arya
> > >
> > > On Thursday 01 July 2004 17:16, Jean-Francois Dive wrote:
> > > > i'd say that it works on the local lan by chance, probably. Take a look
> > > > to the traffic coming on your ppp inerface and see if you see the
> > > > client packets. Maybe it is simply a route problem on the client or
> > > > something like that.
> > > >
> > > > On Thu, Jul 01, 2004 at 11:36:03AM +1000, Arya wrote:
> > > > > G'day guys,
> > > > >
> > > > > OK, here's the go. We're trying to set up a roadwarrior config so
> > > > > that XP clients (without any major changes at the client end) can
> > > > > connect straight to an IPSec/L2TP server (and auth via ppp to a
> > > > > radius, etc).
> > > > >
> > > > > Everything works like a charm, if the client is on the same subnet as
> > > > > the server (ie, if direct delivery occurs), else (if it's routed), it
> > > > > breaks with this message (lets play spot the error!):
> > > > >
> > > > > ourtid = 30309, entropy_buf = 7665
> > > > > check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 30309, call 0
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > ourtid = 64760, entropy_buf = fcf8
> > > > > check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 64760, call 0
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > control_finish: Peer requested tunnel 8 twice, ignoring second one.
> > > > > ourtid = 2715, entropy_buf = a9b
> > > > > ourcid = 7944, entropy_buf = 1f08
> > > > > check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 2715, call 7944
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > ourtid = 64760, entropy_buf = fcf8
> > > > > check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 64760, call 0
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > control_finish: Peer requested tunnel 8 twice, ignoring second one.
> > > > > ourtid = 2715, entropy_buf = a9b
> > > > > ourcid = 7944, entropy_buf = 1f08
> > > > > check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 2715, call 7944
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8ourcid = 17982, entropy_buf
> > > > > = 463e check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 61457, call 17982
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > control_finish: Peer requested tunnel 8 twice, ignoring second one.
> > > > > control_xmit: Unable to deliver closing message for tunnel 30309.
> > > > > Destroying anyway.
> > > > > ourtid = 54363, entropy_buf = d45b
> > > > > check_control: control, cid = 0, Ns = 0, Nr = 0
> > > > > handle_avps: handling avp's for tunnel 54363, call 30309
> > > > > message_type_avp: message type 1 (Start-Control-Connection-Request)
> > > > > protocol_version_avp: peer is using version 1, revision 0.
> > > > > framing_caps_avp: supported peer frames: sync
> > > > > bearer_caps_avp: supported peer bearers:
> > > > > firmware_rev_avp: peer reports firmware version 1280 (0x0500)
> > > > > hostname_avp: peer reports hostname 'wisdom'
> > > > > vendor_avp: peer reports vendor 'Microsof'
> > > > > assigned_tunnel_avp: using peer's tunnel 8
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > control_xmit: Maximum retries exceeded for tunnel 54363.  Closing.
> > > > > call_close : Connection 8 closed to 192.168.0.57, port 1701 (Timeout)
> > > > > control_xmit: Unable to deliver closing message for tunnel 54363.
> > > > > Destroying anyway.
> > > > >
> > > > > receive_window_size_avp: peer wants RWS of 8.  Will use flow control.
> > > > > control_finish: Peer requested tunnel 8 twice, ignoring second one.
> > > > > control_xmit: Maximum retries exceeded for tunnel 30309.  Closing.
> > > > > call_close : Connection 8 closed to 192.168.0.57, port 1701 (Timeout)
> > > > > ourtid = 61457, entropy_buf = f011
> > > > >
> > > > > ...and it kinda keeps going, repeating the last set of lines.
> > > > >
> > > > > I dont suspect IPSec to be the cause, because it seems to be behaving
> > > > > the same way regardless of whether it is on the same subnet or not.
> > > > > (ie, IPsec SA established occurs on both occasions).
> > > > >
> > > > > Here's some config info:
> > > > >
> > > > > --/etc/l2tpd/l2tpd.conf--
> > > > > [global]
> > > > >
> > > > > [lns default]
> > > > > ip range = 10.0.0.128-10.0.0.254
> > > > > local ip = 10.0.0.1
> > > > > require chap = yes
> > > > > refuse pap = yes
> > > > > require authentication = yes
> > > > > name = VPN
> > > > > ppp debug = yes
> > > > > pppoptfile = /etc/l2tpd/options.pppd
> > > > > length bit = yes
> > > > >
> > > > > --/etc/ipsec.conf--
> > > > > version 2
> > > > >
> > > > > config setup
> > > > >         interfaces="ipsec0=eth0"
> > > > >         klipsdebug=all
> > > > >         #plutodebug=all
> > > > >         uniqueids=yes
> > > > >         plutostderrlog=/tmp/pluto.log
> > > > >         nat_traversal=yes
> > > > >         dumpdir=/var/tmp
> > > > >
> > > > > include ipsec.L2TP-RSA.conf
> > > > > include ipsec.no-oe.conf
> > > > >
> > > > > --/etc/ipsec.L2TP-RSA.conf--
> > > > > conn L2TP-RSA
> > > > >         authby=rsasig
> > > > >         pfs=no
> > > > >         type=transport
> > > > >         left=%any
> > > > >         leftid="C=AU, O=My Company Pty Ltd, CN=vpnserver.domain.net"
> > > > >         leftrsasigkey=%cert
> > > > >         leftcert=/etc/ipsec.d/certs/mypublic.crt
> > > > >         leftprotoport=17/0
> > > > >         right=%any
> > > > >         rightid="C=AU, OU=Something Here, CN=*, E=*"
> > > > >         rightrsasigkey=%cert
> > > > >         rightcert=%any
> > > > >         rightprotoport=17/1701
> > > > >         rightsubnetwithin=0.0.0.0/0
> > > > >         auto=add
> > > > >         keyingtries=3
> > > > >
> > > > > --/etc/l2tpd/options.pppd--
> > > > > ms-dns  A.B.C.D
> > > > > auth
> > > > > crtscts
> > > > > idle 1800
> > > > > mtu 1400
> > > > > mru 1400
> > > > > mss 1400
> > > > > nodefaultroute
> > > > > debug
> > > > > lock
> > > > > proxyarp
> > > > > connect-delay 5000
> > > > >
> > > > > --end--
> > > > >
> > > > > Here's what I've tried:
> > > > > I've tried lowering the MTU on all interfaces to 1200. I dont suspect
> > > > > this to be MTU related because I configured a my workstation (a
> > > > > linuxbox) to be a router which was the only hop between the vpn
> > > > > server and the client. I then did an ethereal capture on both of my
> > > > > interfaces and the L2TP packets that are being transmitted are well
> > > > > under 1Kb.
> > > > > I've searched the archives of the mailinglist and haven't been able
> > > > > to find a solution to my problem.
> > > > >
> > > > > What would cause it to break if the client is on a different subnet
> > > > > to the server, but allow it to work fine if the client is on the same
> > > > > subnet, and how can I fix it?
> > > > >
> > > > > Thanks a lot guys, love your work.
> > > > >
> > > > > Arya
> 
> 


Reply via email to