tinc - Apr 2010 - "Mode Switch" and "Tunnelserver Yes" cause unnecessary traffic to clients (proposed patch)

The following is maybe a bug report, and a proposed patch.

Using latest stable tinc 1.0.12.

I have a central server and a few clients connecting to this server.

I don't want clients to speak directly, but I want all the
communications to pass by the server.

My configuration is:
Mode = switch
TunnelServer = Yes

I need layer2 because of some ethernet stuff on the clients.

When you have these two things set up it happens that the tincd damon
will ignore any Subnet add request, if not allowed in the
configuration file.
This means that, because tincd is working on L2, it will not learn the
MAC addresses of the other peers, and will send any packet to every
peer.

Because I am working with "switch" it not not enough to add the subnet
used into the VPN with a statement like:

Subnet = 10.0.0.0/8

But I should add every Mac address of the tap interfaces of the clients.
This is not feasible, because I also guess these mac addresses change
everytime a tap interface is created.

What I did to fix my problem was to patch this file at line 109:
src/protocol_subnet.c:109

deleting the if statement that was preventing to add "Subnets"

So I just deleted from line 109 to 130. Of course this is a dirty hack
that works in my particular setup.

Now the ARP lookup on the server works fine. before the server was
sending the traffic to ALL the clients, so working as a hub.

I understand that mine is a unusual setup and that tunnelmode is experimental.

If we understand together the intended behavior of tinc in this case,
I can code a proper and clean patch and submit it to the mailing list.

Let me know !

Saverio

On Tue, Apr 06, 2010 at 06:43:30PM +0200, ZioPRoTo (Saverio Proto) wrote:
> I don't want clients to speak directly, but I want all the
> communications to pass by the server.
> 
> My configuration is:
> Mode = switch
> TunnelServer = Yes
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 need layer2 because of some ethernet stuff on the clients.
Tinc needs to announce the MAC addresses it learns, so you cannot use
TunnelServer then.
> But I should add every Mac address of the tap interfaces of the clients.
> This is not feasible, because I also guess these mac addresses change
> everytime a tap interface is created.
You can change the MAC address of an interface to a static one.
> I understand that mine is a unusual setup and that tunnelmode is
experimental.
> 
> If we understand together the intended behavior of tinc in this case,
> I can code a proper and clean patch and submit it to the mailing list.
Check if the IndirectData option works for you.

Anyway, why do you want to prevent clients from communicating directly to each
other? That would be more efficient.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20100410/36484f3c/attachment.pgp>