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
