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

[Axel Müller]

>> *** CLIENT routing table ***
>> root at pcamueller:/home/amueller/workspace.tinc/tinc/cabal > netstat -rn
>> Kernel IP routing table
>> Destination     Gateway         Genmask         Flags   MSS Window  irtt
>> Iface
>> 212.79.58.20    192.168.9.1     255.255.255.255 UGH       0 0          0
>> tap0
>
> Well, that isn't going to work. Tinc absolutely doesn't know anything
> about your real IP addresses, and therefore doesn't know where to send
> them to, as can be seen from:
>
>> Jun 27 09:10:33 pcamueller tinc[28155]: Trying to look up 212.79.58.20
>> in  connection list failed!
I agree that tinc doesn't need to kow about real IP addresss but if running 
in "IndirectData" mode I would expect tinc to send everything to its one 
and only uplink (like I patched the lookup in tinc 0.3.3).

> Tinc will only route packets if the destination IP matches one of the
> MyOwnVPNIP lines in other tincd's tinc.conf files. There is a dirty hack
> that might even work in your case, and that is setting the server's
> MyOwnVPNIP to 0.0.0.0/0.
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.

> Furthermore, adding a gateway for an interface that doesn't do ARP
> (ethertap devices normally don't) is quite meaningless.
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.

>> *** CLIENT tinc.conf ***
>> MyOwnVPNIP = 192.168.9.99/24
>
>> *** SERVER tinc.conf ***
>> MyOwnVPNIP = 192.168.9.1/24
>
> 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.

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

-
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/