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
--
--
-> Jean-Francois Dive
--> [EMAIL PROTECTED]
I think that God in creating Man somewhat overestimated his ability.
-- Oscar Wilde
