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
