[CVS] humbolt:/tinc/cabal/src net.c netutl.c protocol.c

Guus Sliepen guus at sliepen.warande.net
Tue Jun 27 12:50:14 CEST 2000


On Tue, 27 Jun 2000, [ISO-8859-1] Axel Müller wrote:

> I have ONE VPN 192.168.9.0/24 which includes the VPN server (192.168.9.1) 
> and all VPN clients (i.e. 192.168.9.99).
> If a client runs in proxy mode it should send everything to the VPN server 
> - there shouldn't be a need to add a MyOwnVPNIP in order to make every 
> possible destination outside the VPN a part of VPN.

That is not the behaviour we intended for tinc.

> There is no need for ARP - all that is needed is actually already done
> by tinc 0.3.3. The gateway routing entries shown in my previous mail
> work perfectly using tinc 0.3.3 and the lookup patch.

They don't act as gateway entries, but as normal entries. They would work
the same if you omitted the "gw 192.168.9.1" part.

> > That is certainly very bad! Those subnets overlap! No wonder things don't
> > work. I think you need to clean up some things first :)!

> I don't think it is bad. It worked with tinc 0.3.3 and the lookup patch.
> As described above I have ONE VPN consisting of a server and some clients. 
> They are in the SAME subnet. This is not an overlap - it is intention.

Tinc makes a distinction between the complete VPN network, which you call
the subnet, and subnets inside the VPN network. Each tincd serves it's own
VPN subnet. The latter shouldn't overlap, or tinc's behaviour is
undefined.

> I think that the current development of the "IndirectData" feature
> goes into the wrong direction not suited for real-life scenarious. The

Not for *your* scenario you mean :).

> feature does fit with the rest of tinc (simple & clear). I should
> probably stay with tinc 0.3.3 but sometimes the SEGVs are annoying.

The only problem you have is that tinc at this moment can only serve one
subnet per tinc daemon. We will implement a feature to allow multiple
address spaces of any type (so, multiple subnets, but also IPv6, IPX, and
other protocols). If we'd have this, you could simply add a
212.79... subnet to the "server" tincd, so that everything would work as
desired again. But first we want a stable 1.0 release.

-------------------------------------------
Met vriendelijke groet / with kind regards,
  Guus Sliepen <guus at sliepen.warande.net>
-------------------------------------------
See also: http://tinc.nl.linux.org/
          http://www.kernelbench.org/
-------------------------------------------



-
Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://ftp.nl.linux.org/pub/linux/tinc/



More information about the Tinc mailing list