Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Don't know if it same but i suceed too when i added a second default route to the eth used by ipsec (but the previous one was no used anymore). The problem about the select() stage comes because i have two DSL connection : one for multi-usage (Internet) and one for the VPN traffic only. If i don't put the VPN DSL in default, l2tpd nerver receive the packets (btw, tcpdump saw theses ones !) and stall at the select() stage. But i can't stay in this configuration since everybody use the DSL dedicated for the VPN for internet connection, it was not acceptable. I break my brain since two days about this, try source routing etc etc ... never succeed. For keep a bit of mental health i migrate to OpenVPN ;-). I'm happy for you :) Le ven 02/07/2004 à 07:40, Arya a écrit : New development: YEEHAW! It would appear that the problem was indeed the internal routing table. route add -net 0.0.0.0 netmask 0.0.0.0 dev ipsec0 That fixed it :D *celebrates*
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Le ven 02/07/2004 à 11:21, Jacco de Leeuw a écrit : When I read your reply, I almost wet myself. I added the printf statements to the source, (l2tpd: network.c / around line 327) printf(select\n); select (max + 1, readfds, NULL, NULL, NULL); printf(select ok\n); I don't get it. This is normal behaviour, right? l2tpd waits for packets received on a socket. Don't think it's a l2tpd bug (everybody use select() :). Perhaps its no bug at all but i think there is one somewhere. I had really strange behaviour ... Everything was configured to work but it don't ... At this time i read a post of a guy which have strictly the same problem than mine ... Really strange :-/
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Le ven 02/07/2004 à 12:15, Arya a écrit : It's not select() that's the problem. It's the default routing table :) ipsec will add a route for the netmask of eth0 to be 'redirected' to the ipsec interface, but it wont add any other routes. Thus, if the packet isn't from the same subnet, it gets routed through the usual default gateway, which is likely external to the box. That's true but you can do source routing for that (reply to the same interface where the request come from) As i remember my box was configured as follow : eth0 (10.0.0.10) - DSL for multipurpose eth1 (81.255.xxx.xxx) - DSL for VPN eth2 (192.168.3.1)- local subnet default route was to eth0 (internet access) i added source routing : packet which come from 81.255.xxx.xxx are routed to eth1 (ip add route from 81.255.xxx.xxx lookup etc ...) i try to connect with ssh from external box to 81.255.xxx.xxx : successfull. i try to connect with L2TP/IPSec frow Windows XP machine to 81.255.xxx.xxx : IPSec SA established but l2tpd not responding (the select() problem). i try to send UDP packet to 81.255.xxx.xxx using port of l2tpd (don't remember) : select() detect these and l2tpd is answering. So, no problem. I think this isn't a VPN configuration problem since when i change the default route to use eth1 (VPN dedicated DSL) in place of eth0 (internet) all works like a charm. Am i clear enought ? What do you think ?
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
On Fri, Jul 02, 2004 at 08:15:38PM +1000, Arya wrote: It's not select() that's the problem. yes that i was sure already :) It's the default routing table :) ipsec will add a route for the netmask of eth0 to be 'redirected' to the ipsec interface, but it wont add any other routes. Thus, if the packet isn't from the same subnet, it gets routed through the usual default gateway, which is likely external to the box. It might just be a slackware thing. Either way, it works like a charm now :) (albeit, now i've configured it in reverse, so clients on the same subnet CANNOT connect to the VPN, but clients external to the subnet CAN *chuckle*). the problem is that you use KLIPS (the freeswan kernel side) which is kind of strange. you should update to openswan with the linux native ipsec stack which is really better. Arya On Friday 02 July 2004 19:57, Jean-Francois Dive wrote: select is the way 99% of the daemon are built on. Not saying there is a bug and by the way, if you have a way to reprduce it, i'll be happy to fix it. On Fri, Jul 02, 2004 at 11:24:24AM +0200, Yannick Lecaillez wrote: Le ven 02/07/2004 ? 11:21, Jacco de Leeuw a ?crit : When I read your reply, I almost wet myself. I added the printf statements to the source, (l2tpd: network.c / around line 327) printf(select\n); select (max + 1, readfds, NULL, NULL, NULL); printf(select ok\n); I don't get it. This is normal behaviour, right? l2tpd waits for packets received on a socket. Don't think it's a l2tpd bug (everybody use select() :). Perhaps its no bug at all but i think there is one somewhere. I had really strange behaviour ... Everything was configured to work but it don't ... At this time i read a post of a guy which have strictly the same problem than mine ... Really strange :-/ -- -- - Jean-Francois Dive -- [EMAIL PROTECTED] I think that God in creating Man somewhat overestimated his ability. -- Oscar Wilde
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
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:
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
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:
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Arya wrote: 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 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. nat_traversal=yes leftprotoport=17/0 rightprotoport=17/1701 rightsubnetwithin=0.0.0.0/0 Are you using NAT somewhere? Then you would need to use leftprotoport=17/1701 and apply the NAT-T update on your Windows client. I would also recommend to use rightsubnet=vhost:%no,%priv instead of rightsubnetwithin=0.0.0.0/0 which is not really secure. And are you using kernel 2.6? I had a problem with l2tpd on kernel 2.6 when NAT was used. I have not been able to solve it. Jacco -- Jacco de Leeuw mailto:[EMAIL PROTECTED] Zaandam, The Netherlands http://www.jacco2.dds.nl
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
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
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Nope, everything is fully public (ie, there is no NAT). For the sake of testing, we're using 10.0.0.0/8 IPs as the IPs pppd assigns (after contacting radius), and a NAT server running on the VPN server. There is no NAT between the VPN server and the VPN client. With regard to 'rightsubnetwithin=0.0.0.0/0' being insecure, we want the entire world to be able to access the VPN server. The security is established by requiring an RSA key pair (generated by our CA) and a known username/ password to a radius. If we use rightsubnet=vhost:%no,%priv instead, would the box be open to the world? Current kernel 2.4.22 (distro is slackware 9.1) Thanks a lot for your help (and well done on the freeswan/l2tpd documentation. I wouldn't be this far without it :)) Arya On Thursday 01 July 2004 18:10, Jacco de Leeuw wrote: Arya wrote: 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 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. nat_traversal=yes leftprotoport=17/0 rightprotoport=17/1701 rightsubnetwithin=0.0.0.0/0 Are you using NAT somewhere? Then you would need to use leftprotoport=17/1701 and apply the NAT-T update on your Windows client. I would also recommend to use rightsubnet=vhost:%no,%priv instead of rightsubnetwithin=0.0.0.0/0 which is not really secure. And are you using kernel 2.6? I had a problem with l2tpd on kernel 2.6 when NAT was used. I have not been able to solve it. Jacco
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Yep, packets being sent both ways can be seen (i put a hub between the client and the router and plugged another workstation in to capture packets). There is no ppp interface, as pppd hasn't been called yet... 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
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
on a tcpdump on the ipsec0 interface, the only thing I get is this: 19:48:27.886094 client.domain.com.1701 vpnserver.domain.com.1701: l2tp: [TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() |... ..over and over again.. I dont seem to be able to see any messages coming from vpnserver.domain.com to client.domain.com When I connect from a client on the same subnet, the packets are definitely ESP protected (checked by sniffing on another box using a hub). On Thursday 01 July 2004 18:25, Jean-Francois Dive wrote: 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
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Arya wrote: There is no NAT between the VPN server and the VPN client. Then you need to remove the rightsubnetwithin line. (Perhaps this is ruining your routing?). With regard to 'rightsubnetwithin=0.0.0.0/0' being insecure, we want the entire world to be able to access the VPN server. You misunderstand this parameter. right=%any already does this for you. password to a radius. If we use rightsubnet=vhost:%no,%priv instead, would the box be open to the world? rightsubnet=vhost:%no,%priv is only needed when (some of the) clients are NATed. Current kernel 2.4.22 (distro is slackware 9.1) Never tested with Slackware myself, so YMMV. Thanks a lot for your help (and well done on the freeswan/l2tpd documentation. I wouldn't be this far without it :)) No problem! Jacco -- Jacco de Leeuw mailto:[EMAIL PROTECTED] Zaandam, The Netherlands http://www.jacco2.dds.nl
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Worth a shot :) rightsubnetwithin line is gone. ipsec restarted. no difference. same tcpdump info as before, same l2tpd debug info as before, same ipsec info as before. Heres my routing table: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface localnet* 255.255.255.192 U 0 00 eth0 localnet* 255.255.255.192 U 0 00 ipsec0 loopback* 255.0.0.0 U 0 00 lo default real-router-here 0.0.0.0 UG1 00 eth0 Arya On Thursday 01 July 2004 20:02, Jacco de Leeuw wrote: Arya wrote: There is no NAT between the VPN server and the VPN client. Then you need to remove the rightsubnetwithin line. (Perhaps this is ruining your routing?). With regard to 'rightsubnetwithin=0.0.0.0/0' being insecure, we want the entire world to be able to access the VPN server. You misunderstand this parameter. right=%any already does this for you. password to a radius. If we use rightsubnet=vhost:%no,%priv instead, would the box be open to the world? rightsubnet=vhost:%no,%priv is only needed when (some of the) clients are NATed. Current kernel 2.4.22 (distro is slackware 9.1) Never tested with Slackware myself, so YMMV. Thanks a lot for your help (and well done on the freeswan/l2tpd documentation. I wouldn't be this far without it :)) No problem! Jacco
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Also, added rightsubnet=vhost:%no,%priv (because there is always the possibility of some of the clients being NATed) Slackware is basically just plain vanilla linux with packages. The base linux kernel works fine with a slackware distribution. Arya On Thursday 01 July 2004 20:02, Jacco de Leeuw wrote: Arya wrote: There is no NAT between the VPN server and the VPN client. Then you need to remove the rightsubnetwithin line. (Perhaps this is ruining your routing?). With regard to 'rightsubnetwithin=0.0.0.0/0' being insecure, we want the entire world to be able to access the VPN server. You misunderstand this parameter. right=%any already does this for you. password to a radius. If we use rightsubnet=vhost:%no,%priv instead, would the box be open to the world? rightsubnet=vhost:%no,%priv is only needed when (some of the) clients are NATed. Current kernel 2.4.22 (distro is slackware 9.1) Never tested with Slackware myself, so YMMV. Thanks a lot for your help (and well done on the freeswan/l2tpd documentation. I wouldn't be this far without it :)) No problem! Jacco
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
hehe, this is true :) theoretically though, that shouldn't be the reason why l2tpd breaks if (and only if) the client is on a different subnet... Arya On Thursday 01 July 2004 20:17, Jacco de Leeuw wrote: Heres my routing table: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface localnet* 255.255.255.192 U 0 0 0 eth0 localnet* 255.255.255.192 U 0 0 0 ipsec0 loopback* 255.0.0.0 U 0 00 lo default real-router-here 0.0.0.0 UG1 00 eth0 Where is your eth1? The internal and external net are on the same interface? This is not how a VPN server is supposed to work. Jacco
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
from everything we have seen, it looks clear that the l2tp traffic that l2tpd send does not goes trough the tunnel. As you use KLIPS, you require that routing is properly set. You should find the l2tpd reply on your lan unprotected, if this is the case, then you have your problem. On Thu, Jul 01, 2004 at 08:06:11PM +1000, Arya Abdian wrote: Also, added rightsubnet=vhost:%no,%priv (because there is always the possibility of some of the clients being NATed) Slackware is basically just plain vanilla linux with packages. The base linux kernel works fine with a slackware distribution. Arya On Thursday 01 July 2004 20:02, Jacco de Leeuw wrote: Arya wrote: There is no NAT between the VPN server and the VPN client. Then you need to remove the rightsubnetwithin line. (Perhaps this is ruining your routing?). With regard to 'rightsubnetwithin=0.0.0.0/0' being insecure, we want the entire world to be able to access the VPN server. You misunderstand this parameter. right=%any already does this for you. password to a radius. If we use rightsubnet=vhost:%no,%priv instead, would the box be open to the world? rightsubnet=vhost:%no,%priv is only needed when (some of the) clients are NATed. Current kernel 2.4.22 (distro is slackware 9.1) Never tested with Slackware myself, so YMMV. Thanks a lot for your help (and well done on the freeswan/l2tpd documentation. I wouldn't be this far without it :)) No problem! Jacco -- -- - Jean-Francois Dive -- [EMAIL PROTECTED] I think that God in creating Man somewhat overestimated his ability. -- Oscar Wilde
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
In precision of my previous post : this is what i added to the network.c for see the problem : (l2tpd: network.c / around line 327) printf(select\n); select (max + 1, readfds, NULL, NULL, NULL); printf(select ok\n); Sure, it's really simple ... But permit to discover the problem : select is displayed but select ok not ... Moreover, when i send UDP packet on the public interface (not throught IPSEC) l2tpd receive these without problem. For finish, i think it's not a routing porblem since the IP Sec SA was established (but i'm not an IP Sec specialist :)). Again, hope this can help ...
Re: L2TPD/openswan with XP/2000 clients only works in same subnet?
Hi, When I read your reply, I almost wet myself. I added the printf statements to the source, as you said, however when the client on a different subnet connects it would appear that it continues past that select() statement (ie, select ok is seen). Therefore the cause cant be this =| Also, Jacco, rightsubnet=vhost:%no,%priv seems to break IPSec (says no authorized connection). That's OK, this one I can work out myself :-) I'm going to try to add another nic to the PC. I'll let you know what happens :) Arya On Thursday 01 July 2004 22:26, Yannick Lecaillez wrote: In precision of my previous post : this is what i added to the network.c for see the problem : (l2tpd: network.c / around line 327) printf(select\n); select (max + 1, readfds, NULL, NULL, NULL); printf(select ok\n); Sure, it's really simple ... But permit to discover the problem : select is displayed but select ok not ... Moreover, when i send UDP packet on the public interface (not throught IPSEC) l2tpd receive these without problem. For finish, i think it's not a routing porblem since the IP Sec SA was established (but i'm not an IP Sec specialist :)). Again, hope this can help ...
