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,
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
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
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
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
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
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
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
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
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
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
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,
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
On 2004.04.30, David F. Skoll [EMAIL PROTECTED] wrote:
Hi, Dossy.
Is what's currently in CVS suitable for tagging as v0_4? If so, I could
tag and upload to the SF Files section if I have the necessary privs ...
Yes, I think so, and you should have the privileges.
Three months late, but
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,
15 matches
Mail list logo
