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
