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