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?
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?
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?
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 ...
