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, i
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
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, whi
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 re
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");
>
>
Arya wrote:
Also, Jacco, rightsubnet=vhost:%no,%priv seems to break IPSec (says no
authorized connection). That's OK, this one I can work out myself :-)
Did you add a line to ipsec.conf, e.g.:
virtual_private=%v4:172.16.0.0/12,%v4:192.168.0.0/16
Otherwise the rightsubnet= might not be loaded, so n
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
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*
Arya
On Friday 02 July 2004 11:21, Arya wrote:
> OK, just added another NIC.
>
> new routing table is:
>
> Kernel
OK, just added another NIC.
new routing table is:
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 0
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, Ja
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"
I had exactly the same problem !! Never solved.
(super-freeswan 1.9.98 with l2tpd). IP SA established
but l2tpd never answering ...
Then, i downloaded the source of l2tpd and work about on it for
see what happens. I discover l2tpd never receive request from
the client ! l2tpd stop at the select()
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,
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*
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
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 Lee
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
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 misunde
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
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 work
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
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 wi
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.
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
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,
>
25 matches
Mail list logo
