"Mode Switch" and "Tunnelserver Yes" cause unnecessary traffic to clients (proposed patch)

ZioPRoTo (Saverio Proto) zioproto at gmail.com
Fri Apr 23 14:26:05 CEST 2010


>> > I think it would be better if you set IndirectData = yes in the server's
>> > tinc.conf, that would force all traffic to go via the server.  TunnelServer is
>> > not really compatible with switch mode (unless you configure MAC Subnets
>> > statically).
>>
>> I'm reading here:
>> http://www.tinc-vpn.org/documentation/tinc_4.html#Configuration
>>
>> I don't understand this IndirectData option :( Maybe is a language problem.
>
> The name of that option is a bit unfortunate.
>
>> "IndirectData = yes" means that tincd will not try to make other VPN
>> connections than the ones specified with ConnectTo statements ?
>
> Yes. This was implemented mainly because old versions of tinc did not check
> itself whether it could make direct connections via UDP. For nodes behind
> firewalls or NAT devices, this would tell tinc to forward packets only via the
> nodes it had ConnectTo statements to.

Hi,

the IndirectData option is not working for me :(

I updated my testbed to tinc 1.0.13 and I configured "IndirectData =
yes" instead of "TunnelServer = Yes"

The config is very basic:
 * Name
 * Mode = switch
 * IndirectData = Yes
 * Two ConnectTo statements

However, the result is that I obtain a full mesh between the 10 nodes
I have in my testbed. So tincd establishes a VPN link even with the
nodes not specified in the ConnectTo statements.

Anyway I solved using "TunnelServer = yes" and patching commenting out
src/protocol_subnet.c from line 109 to 122, that is very similar to
what I did in tinc 1.0.12

I am a bit confused because I keep not understanding what is the
behaviour of the IndirectData option :) Anyway no problem because I
fixed my issue with a simple patch :)

Saverio


More information about the tinc mailing list