"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